Suportul ajunge mâine. Aștept. Acum nu știu dacă buba e la mine și la cum am utilizat server-ul sau e ceva ce îi privește în mod special pe proprietarii serviciului.
Nu știu, întreb și eu. Mă gândeam că poate există protecții / firewall. Sunt dator cu un pic de studiu. Prima mea curiozitate este cum de un astfel de bot a reușit să imi opreasă ambele site-uri. Am oprit și repornit containerele de docker și functionează ok.
Asta a fost și recomandarea venită de la suport. După restartul docker-ului funcționează ok dar nu am încredere că totul este 100% sigur.
Deși statusul containerelor era ok serviciile web erau căzute. Poate succesiunea rapidă de requesturi a cauzat. Mă tem de posibilitatea unui fișier de configurație (sau ceva asemănător) de pe server alterat.
Din punct de vedere al securitatii, restaurand niste backup-uri activezi de fapt acelasi vulnerabilitati.
O solutie ar fi, refacut masina cu ultimile versiuni ale aplicatiilor, in cazul asta phpmyadmin si securizate bine, pe urma dat jos masina curenta, pus masina noua in loc si investigat ce se petrece cu masina veche. Unele exploituri sunt si bagate si in bazele de date si cand se “restaureaza” o aplicatie de fapt se reinstaleaza, verificati si dump-uri de db cu chestii ce n-ar trebui sa fie acolo, exemplu: MySQL creaza fisier PHP, etc.
Foarte rapid cautati pe google phpmyadmin versiunea vulnerabilities, exemple, dar fiind system LAMP/LEMP probabil trebuie sa va uitati la mai multe, gen versiunea de PHP folosita daca mai este suportata. Vulnerabilitatile trebuiesc gestionate pe intregul stack OSI.
Aici nu folosesc php (python+javascript în Docker). Dar da, o să fac o mică inspecție în directoare și baza de date.
Când am pus stăpânire pe aceste VPS-uri am instalat Docker, am clonat repo-ul am dat build și asta a fost. Un pas în plus a fost dezactivarea serviciului apache din cauza că împiedica accesul la Ngnix. Să mai fie lucruri de făcut în host care mă pot proteja?
Te panichezi degeaba. Asa cum vezi si in log-uri, bot-ul respectiv cauta niste foldere/fisiere.
Daca nu le-a gasit, sanatate.
Daca stii ca ai pe server fisierele pe care bot-ul le cauta, atunci arunca un ochi si vezi ce se poate face.
It is just a hole finder script. The requests made are typically the following ones, if your servers answers all with a 404 error, you do not have anything to worry about.
Verifica in python ce faci si cum faci, gen ai un functional de upload, verifica ce fisiere poti uploada acolo (nu doar dupa extensia fisierului, ci dupa mime-type-ul folosit. Dupa ce fisierul este uploadat temporal, scaneaza-l de visuri/mallware, etc, sunt multe de verificat.
Daca e doar un scan (poate sa fie un atac de “identificare” gen Dirbuster daca nu folosesti phpmyadmin-ul) atunci poti folosi cu un oarecare success fail2ban, spun asta pe ca din requesturile tale, chiar daca nu exista tu trimiti 301 (permanent redirect) in loc de 404 si atunci va fi greu sa vezi ce requesturi sunt legitime si care nu sunt.
Am avut problema asta în perioada în care aveam apache de pe local public: la un moment dat îmi dau seama că internetul a devenit lent, extrem de lent. Când mă uit la utilizare, era aproape de 100%
Așa cum s-a spus mai sus, cel mai probabil ești scanat în căutarea de fișiere … să le zicem uzuale.
Poate că ar trebui să editezi titlul, să scoți numele providerului? Nu cred că are legătură.
Da, poate nu are legătură providerul. Mă gândeam totuși. Sunt 2 vps-uri, unul expune un API celălalt este un React ce consumă acel Api. Presupun că scriptul acela de spam a nimerit pe domeniul înregistrat pentru frontend, a făcut ceva crawl și a găsit link către Api, pentru că ambele servere au fost atacate similar.
Ca IP ele sunt apropriate (xx.yy.zz.1n, xx.yy.zz.2n). Daca scriptul lucrează citind secvențial un range de IP-uri atunci poate și alte servere au fost afectate, nu doar ale mele, caz în care numele providerului in titlu face ceva sens. Greșesc?
Doamne ferește. Și cele câteva minute au fost suficiente că sa îmi blocheze serviciile. Astăzi am observat iar atacuri dar serviciile au rezistat (:
Pare că react-routerul de pe frontend răspunde cu 200 și o pagină fără componente in body când scriptul ăla incerca diverse pagini. De asta cred că insistă și nu mă lăsa în pace.
Nu te ajuta doar firewall-ul daca ti se blocheaza serverul, iti trebuie un cookie challenge (captcha de la toti utilizatorii daca serverul e peste un anumit load) ca sa blochezi un scanner fara sa maresti resursele serverului.
Ai grija ca nu cumva sa iti pice din cauza sesiunilor anonime care se duc direct la baza de date cand acceseaza fisiere php.
Partea bună: sunt servere de dezvoltare, pot sa distrug tot fără să regret nimic. Lucrez doar eu și încă o persoană, load foaaaarte mic din partea noastră.
Partea rea: daca se intampla pe un server de producție? E drept aici am doar 1gb RAM, poate asta a dus la picaj… dar chiar și așa, scriptul ăla tot mai scanează din când în când și îmi blochează release-urile ((:
Totul este in docker, am certificate pentru https, nu am decât să pun regului in nginx conform rutelelor din React, poate la un moment dat atacatorul va fi descurajat sa mai atace.
Partea neutră: Prima grijă acum este sa înțeleg ce se întâmplă și să aplic din recomandarile acestui thread. Este o experiență până la urmă și câștig ceva cunoștințe. Între timp atacatorul își consumă ceva resurse cu mine și nu cu altă persoană/adresa care chiar ar putea fi exploatată. Câștig mic dar asta este. Yupi-ye!
