SSHD: Diferența dintre „conexiune închisă...” și „deconectat de la...” în fișierul jurnal

Serviciul sshd de pe serverul meu Ubuntu este atacat constant pentru diverse IP și ID-uri de utilizator.

Conform /var/log/auth.log fișier, există trei tipuri diferite de erori de la ID necunoscut și adresa IP:

• Deconectat de la utilizator nevalid...
• Conexiune închisă de un utilizator nevalid...
• Conexiune închisă de xxx.xxx.xxx.xxx

Care este diferența dintre cele trei? Sugerează vreuna dintre acestea o conectare reușită (neautorizată)? mai ales ultimul...

Sunt presupunând toate acestea sunt încercări eșuate, pe baza faptului că am configurat serverul SSH pentru a solicita pubkey de la IP non-LAN și autentificare restricționată la un singur ID de utilizator, non-root.

Dar, de fapt, nu știu cum să verific dacă aceste măsuri de securitate sunt setate corect, dacă cheia mea pub nu a fost compromisă sau dacă mecanismul de autentificare a parolei serverului meu nu a fost compromis. Deci nu pot spune cu siguranță că toate acestea sunt încercări eșuate.

Am încercat să folosesc fail2ban pentru a bloca atacurile repetate de la anumite IP, dar aceasta a fost un eșec major. În primul rând, nu mai repede de 24 de ore mai târziu, atacatorii au trecut la rotație prin sute de adrese IP unice. În al doilea rând (și mai îngrijorător) fail2ban nu pare să recunoască încercările repetate care au ca rezultat Conexiune închisă de xxx.xxx.xxx.xxx.

În acorduri cu @tilman-schmidt, doar câțiva cenți din partea mea (referitor la fail2ban etc)...

Oamenii OpenSSH modifică continuu comportamentul de înregistrare, astfel încât acesta nu poate fi luat în considerare de fail2ban în mod implicit (depinde și de locul în care are loc deconectarea, de ex.în faza de preautentificare sau după ce numele de utilizator este furnizat, precum și ce metode de autentificare sunt permise în sshd-ul dvs., precum și pe comportamentul „intrusului”.

Cel puțin aș seta LogLevel VERBOSE în sshd_config, așa cum este descris în /etc/fail2ban/filter.d/sshd.conf

De asemenea, rețineți acest răspuns la întrebare similară - https://unix.stackexchange.com/questions/662946/fail2ban-regex-help-for-banning-sshd-connection-attempts/663002#663002

nu mai repede de 24 de ore mai târziu, atacatorii au trecut la rotație prin sute de adrese IP unice

Acest lucru nu are nimic de-a face cu utilizarea fail2ban - scanerele, așa cum au găsit ascultătorul sshd, l-au „publicat” într-o listă dintre ele, astfel încât scanarea mai profundă (de exemplu, cu rețele botnet distribuite) ar putea începe. Aceasta este soarta jalnică a oricărui server cu porturi deschise spre exterior.

Puteți încerca să schimbați portul ssh cu altceva, dar ar evita doar jumătate de script kiddies (dacă ați interzice încercările de scanare porturi) și practic nu este un panaceu deloc. Dar ai putea reduce drastic numărul de intruși cel puțin pentru o perioadă scurtă de timp, până la câteva luni. Ceea ce poate ajuta cu siguranță este activarea bantime.increment în fal2ban (pentru închisoare sshd sau implicit).

fail2ban nu pare să recunoască încercările repetate care au ca rezultat închiderea conexiunii de

Acest lucru nu este chiar corect. Trebuie să setați mod = agresiv pentru sshd închisoare în închisoare.locală pentru a permite fail2ban luați în considerare orice tip de „atac” (nu numai problemele de autentificare), care apar și de către scanere de porturi și lucruri similare DoS.

Și puteți vedea ce anume ar fi găsit de fail2ban cu filtrul dvs. actual cu această comandă (notă potrivite în ultimul rând din rezultat):

fail2ban-regex /var/log/auth.log 'sshd[mode=agresiv]'