Am un sql server instalat pe un vps cu linux. Incercand sa caut ceva loguri pentru un rest api scris in c#, am dat peste fisierul var/log/syslog. Vad ca de azi dimineata, de la ora 00 (si probabil si in zilele trecute, dar s-au suprascris), pare ca sunt incercari de conectare la serverul sql, cu nume de utilizator random (Araceli, Viliana, sa - de cele mai multe ori).
Nu cred ca-s requesturi din api, deoarece n-am pe nicaieri acei useri :))) Imi pare ca se incearca accesul, dar de cine, nu stiu, ca de aplicatie nu stie nici naiba. Oare am dat de primul script nenorocit care incearca sa fure datele? Poate sa fie providerul hackuit si asa sa incerce sa fure bazele de date ale clientilor? ca loguri obisnuite de linux nu-mi par, atata timp cat userii sunt random. Si nici fisier de logs comun cu al altora n-are cum sa fie, din moment ce-i pe vps-ul meu
Si daca-i hack … are cineva idee cum pot stopa aceste requesturi? vad ca se scriu incontinuu, performeaza, acum sunt cate 3 4 pe secunda
yep, “sa” este userul default al sql serverului. cel mai probabil este expus pe internet, n-am activat nici un firewall pentru ca ultima data cand am incercat asta am blocat accesul pe toate porturile si a trebuit sa reinstalez sistemul
dar probabil ar trebui ca sql-ul sa poata fi accesat doar din intern (api-ul fiind gazduit pe acelasi server)
// edit: din moment ce la acel sql ma conectez si eu de pe local prin sql server management studio, clar au si altii acces. Curiozitatea mea e, cum naiba afla de asta, scaneaza ip-urile de la 0 la 999, si porturile la fel, sa afle ce-i acolo?
Si avand in vedere ca porturile sunt cunoscute, nu este greu sa isi dea seama ca acolo este un server sql.
Daca este la tine la munca, atunci treaba aia ar cam trebui sa stea intr-un DMZ
sau daca este pt tine, vezi cum se configureaza un firewall. Nu ma pricep la configurat firewall-uri, dar poate te ajuta cinva mai priceput de pe forum
am gasit un tutorial pe intelesul oricui, am reusit sa configurez regulile firewallului astfel incat sql-ul sa fie accesat doar de backend. requesturile din afara apar blocate, insa trebuie sa vad limita maxima a acelui fisier syslog (pana la rescriere), sa nu ajunga la zeci de gb.
eu cred ca asta este doar una din problemele tale. Vezi daca ai sau configureaza-ti log rotationul ca sa eviti problema log-urilor. Apoi configureaza un firewall pentru toate serviciile, de fapt, porneste de la un Deny all si deschizi doar ce ai nevoie pentru Internet. Din ce ai zis ai nevoie sa ai deschise doar 80 si 443, SSH e bine sa ii schimbi portul default si activeaza logarea cu chei. Verifica toate listening ports si inchide ce nu ai nevoie
si probabil cea mai mica problema…omul a dat drumul la servere si are active servicii direct pe net fara fw fara regului fara documentatie, dar cu mult entuziasm. dragule, iti ia maxim o saptamana sa citesti cat de cat despre cum sa configurezi corect un serviciu si te rog, pentru binele tau si al celorlalti, fa-o cat de curand. Multa bafta!
Hai sa pastram un pic de profesionalism. Omul e aici pentru ca il intereseaza, cauta, invata. E un pas in directia buna.
Ontopic, ip-urile VPS-urilor sunt constant scanate de boti si cum ai un port cunoscut deschis, cum incepe bombardamentul cu credentiale. Daca vrei sa faci un experiment, ridica un nod nou nout si fa log la incoming sa vezi ce rapid incep sa te caute baietii. Eu n-as tine server de DB expus direct la internet. Daca n-ai incotro, schimba portul default si pune un whitelist.
e prima data cand ridic un server de linux. Am mai lucrat cu IIS, dar acesta fiind pe windows, firewallul era deja activat.
prima data cand am incercat sa activez firewallul, am urmarit un tutorial random si am dat deny tuturor porturilor. Inclusiv ssh-ului (care am vazut ca-i pe 22 default), nu ma mai puteam conecta nici prin mobaxterm si a trebuit sa reinstalez sistemul. Dupa incercarea asta, l-am lasat dezactivat.
Dupa povestea din topicul asta, l-am activat corect si dat allow doar pentru porturile aplicatiei web, iar pentru sql, deoarece vreau sa ma conectez de pe local (sql server management studio), allow doar ip-ului propriu. Activand firewallul, ma astept ca toate porturile sa fie blocate acum si doar cele specificate in rules sa fie disponibile. Continui sa ma documentez, dar e un pas mare inainte, fata de ce era in urma cu 2 zile.
Useri nu am inca, insa ma gandesc sa criptez toate fieldurile ce tin de ei (nu doar parola, cum vine default un rest api de .NET)
Mie-mi place ca marii provideri de cloud ofera firewall implicit.
De exemplu in Azure e Deny All by default si trebuie sa-i pui tu regula daca vrei SSH de exemplu. Si e separat de masina virtuala asa ca nu risti sa ramai blocat.
Pacat ca nu ofera si providerul tau ceva similar.
A 2-a problema ce-o remarc e: de ce asculta SQL Server pe toate IPurile si nu doar pe localhost by default? Cand il instalam pe Windows imi aduc aminte ca nici nu era activat sa asculte pe TCP/IP dupa o instalare standard.
Pe un sistem Linux in momentul in care ridici un serviciu sau un server care asculta un port expui acel port local sau catre exterior. De regula serverele de baze de date, si nu numai, pornesc by default ascultand doar interfata localhost si trebuie sa le reconfigurezi daca vrei sa asculte si alta interfata de retea. Prin urmare nu ai nevoie de acel firewall decat in situatii relativ rare in care sa blochezi de exemplu tot si sa lasi anumite porturi expuse.
In momentul in care ai expus catre exterior un port pe un VPS acel port va fi atacat de toata lumea, asta e clar. In aceste cazuri firewall-ul clasic nu te ajuta ci alte solutii (tunel VPN, tunel SSH, etc).
aici sunt aproape sigur ca n-am facut vreo prostie, pentru ca imediat dupa instalare, am putut sa ma conectez la sql de pe ip-ul propriu.
In momentul de fata ar trebui sa am doar 3 porturi accesibile din afara, 22 (pentru ssh), 80 (pentru aplicatia web) si 53466 (random, pentru backend).
Pentru ca tot incearca sa acceseze sqlul, fisierul syslog se umple de loguri cu rejectarea acestor requesturi de catre firewall. Intre timp, instalasem si fail2ban, dar pare ca trimite requesturi de pe ip-uri diferite, si n-are efect (apoi am vazut postarea lui Sebastian). O sa incerc Wireguard, pentru ca ma gandesc ca ar trebui sa fie un layer in plus intre exterior si server, si in cazul asta, sa nu mai fie nevoie nici macar de logurile de rejectare, practic ar fi primul gardian al serverului care-ti va spune daca ai voie sau nu sa-l accesezi pe portul x.
443 este pentru https, momentan n-am nici domeniu pus ca nu m-am decis asupra unuia, accesez siteul prin ip, si l-am lasat pe 80.
Sa filtrez ip-urile pentru 22, te referi sa pun regula cu ip-ul propriu? Daca da, am facut asta doar pentru sql, insa n-as vrea sa fac si pentru ssh pentru ca in momentul in care mi se va schimba ip-ul (cred ca periodic), o sa ma trezesc fara acces pe server.
Pentru backend, am pus un port random, folosit si pe localhost.
George, lista de network.ipaddress din sql conf n-ar trebui sa faca acelasi lucru ca regula din firewall pusa pe portul sql-ului? ar fi o dubla verificare daca le am pe ambele.
Network address este adresa ip pe care serverul asculta cererile (o mai gasesti sub denumirea de bind address prin alte servere), in plus mai este undeva si un port default pe care nu e nevoie sa il schimbi (vezi aici). Asta inseamna ca poti configura serverul tau sa asculte pe localhost si acel port. Backendul il pui sa lucreze cu serverul de pe localhost si portul default iar astfel aplicatia ta e izolata de exterior.
Pe de alta parte, o regula in firewall ar putea avea rolul sa blocheze accesul din exterior pe portul serverului si pe adresa interfetei de retea a serverului, insa, cata vreme serverul nu asculta pe aceasta adresa ci pe localhost nu ai nevoie de o astfel de regula. Mai departe expui doar forontendul.
Pentru management, incearca acces pe ssh cu cheie public privata (parola de root o lasi un random complicat) iar pentru baza de date tunel prin ssh. Cel putin eu asa as proceda…
LE: portul ssh fiind expus se va da in el mereu. Daca ai o parola random strong nu iti face probleme, atacurile pe ssh sunt numai brute force deci sansele sa iti ghiceasca cineva parola cu dictionare sunt minime. Parerea mea e sa il lasi asa, atacurile oricum incarca logurile, daca te apuci sa filtrezi cererile pe ssh nu faci decat sa incarci si mai mult niste loguri si sa incarci masina cu o procesare inutila.
Poate sa fie providerul hackuit si asa sa incerce sa fure bazele de date ale clientilor? ca loguri obisnuite de linux nu-mi par, atata timp cat userii sunt random. Si nici fisier de logs comun cu al altora n-are cum sa fie, din moment ce-i pe vps-ul meu 
