Sì, sembra che tu stia subendo un attacco di forza bruta. L'autore dell'attacco si trova su un indirizzo privato di classe B, quindi è probabile che sia qualcuno con accesso alla rete della tua organizzazione che sta conducendo l'attacco. Dai nomi utente sembra che stiano eseguendo un dizionario di nomi utente comuni.

Dai un'occhiata a 'Come fermare / prevenire SSH bruteforce' (Serverfault) e "Prevenzione degli attacchi SSH di forza bruta" (Rimu Hosting) su come adottare misure per mitigare alcuni dei rischi relativi agli attacchi di forza bruta SSH.

Sì, sembra esattamente un attacco di forza bruta e dopo aver cercato su Google admins phoenix piglet rainbow sembra che questo sia l'elenco di parole utilizzato dall'aggressore: https://github.com / hydrogen18 / kojoney / blob / master / fake_users
Dai un'occhiata alla riga 116 in poi. L'elenco di parole viene utilizzato nello stesso identico ordine.
Sembra essere un elenco di parole generico poiché è presente anche su altri siti. per esempio. http://src.gnu-darwin.org/ports/net/kojoney/work/kojoney/fake_users

@TheJulyPlot ha fornito alcune buone informazioni su cosa fare per mitigare questo attacco.

Aggiunta rapida nota su fail2ban , come molte persone lo hanno menzionato: il front-end è un firewall aziendale, il back-end vede solo il reindirizzamento / proxy / indirizzo interno fornito dal firewall.

Quindi no, 172.25.1.1 non è una macchina interna compromessa (e sia il commento nella risposta, sia altre risposte qui che affermano che si tratta di una macchina interna sono sbagliati quando lo commentano). È uno degli indirizzi IP interni del firewall.

Fail2ban nel back-end bloccherebbe solo tutte le possibilità di utilizzare SSH per tratti alla volta poiché vede solo i tentativi falliti da 172.25.1.1. Quindi, per favore, continua a leggere per la mia risposta.

Non ci sono dubbi, come menzionano altri post, è dolorosamente ovvio che sei sotto un attacco di forza bruta.

Tuttavia, questo non significa affatto che tu sia compromesso in alcun modo dai log che ci hai mostrato. Ahimè, oggigiorno gli attacchi di forza bruta ssh sono fin troppo comuni. Il più delle volte sono realmente automatizzati e non sei necessariamente preso di mira.

Come racconto di avvertimento aneddotico, alcuni anni fa, il primo giorno in cui ho installato nuovi server in un provider ISP, quello ssh aperto a Internet ha ottenuto più di 200k ssh di sonde di scansione in una sola notte.

Per quanto riguarda l '"indirizzo IP interno", o stai utilizzando SNAT o un reindirizzamento proxy 22 / TCP al massimo, e gli IP Internet di origine non mostrare (che non è la migliore pratica), o nel peggiore dei casi il tuo router / modem via cavo è compromesso.

Se hai davvero una configurazione SNAT / proxy SSH, ti consiglio di pensarci su . Vuoi i log degli indirizzi IP reali e non della tua rete.

Per quanto riguarda le misure, ne consiglio alcune:

1. Non consentire password in SSH; solo accessi utilizzando certificati RSA;
2. Non aprire ssh per l'esterno; limitalo alla tua rete interna;
3. Per l'accesso dall'esterno, accedi tramite VPN; non esporre SSH a Internet in generale;
4. SYN limitanti la velocità dall'esterno.

Se insisti assolutamente per avere ancora Internet SSH aperto all'esterno, tieni presente che cambiare la porta SSH predefinita dà solo un falso senso di sicurezza, e il blocco temporaneo degli indirizzi IP rallenta solo l'attacco come spesso si parla di fattorie coordinate di macchine zombie.

Potresti voler dare un'occhiata a fail2ban se modifichi la tua configurazione per ricevere direttamente indirizzi IP pubblici che si connettono a te; tuttavia, tieni presente che se effettivamente un IP esterno arriva con l'indirizzo IP del tuo gateway, stai effettivamente bloccando tutti gli accessi SSH esterni che lo utilizzano.

Ci sono anche altri avvertimenti; tieni presente che al giorno d'oggi gli zombi / malware prendono in considerazione fail2ban e torneranno dopo il periodo di timeout predefinito o si alterneranno con indirizzi IP diversi. (L'ho visto accadere.) Anche se si utilizza l'autenticazione del certificato RSA obbligatoria, gli attacchi alla password verranno comunque registrati e bruceranno I / O, spazio su disco e cicli della CPU.

Per quanto riguarda la VPN, non hai bisogno di hardware dedicato; è banale configurare una VPN in un server Linux o FreeBSD.

Se non ti senti a tuo agio nell'impostarne uno da zero, consiglio una VM con pfSense. per FreeBSD ; strongSwan per configurare una VPN in un server Linux.

Se il tuo server front-end è Linux, un'altra alternativa è il port knocking. Tuttavia a causa del suo funzionamento intrinseco, lo consiglio solo per ambienti domestici. Come correttamente sottolineato da @GroundZero, "il port knocking è protetto dall'oscurità e un utente malintenzionato può monitorare attivamente il tuo traffico di rete per scoprire la sequenza di knocking."

How To Usa il Port Knocking per nascondere il tuo demone SSH agli aggressori su Ubuntu

Come misura aggiuntiva, puoi anche limitare la velocità con le regole firewall / iptables SYN sulla porta 22. In questo modo, non limiterai la velocità delle tue connessioni legittime, e iptables in Linux o la maggior parte dei firewall commerciali lo consentono configurazione. Ho visto brutti trucchi come bot che attaccano alcuni demoni il più velocemente possibile prima che le regole di sicurezza entrino in vigore. Tuttavia credo che in realtà ssh abbia difese integrate contro questo.

Per risponderti sulla scansione dilagante, sì, davvero. Hai molti cattivi attori, reti zombie e malware che scansionano costantemente lo spazio degli indirizzi IP per trovare server con versioni compromesse di sshd, versioni vulnerabili / vecchie di sshd, server con password predefinite / errate / backdoor conosciute e semplicemente server con openssh da guadagnare un punto d'appoggio in un utente non privilegiato tramite attacchi di forza bruta o doppi attacchi tramite phishing.

Dopo tre attacchi riusciti tramite phishing (in eventi separati) nel mio host bastione nel mio lavoro attuale, ho deciso di fare una doppia configurazione ssh in quanto a tutti gli utenti viene richiesto un certificato RSA in sshd_config , e solo la rete interna consente l'autenticazione della password, aggiungendo alla fine del file di configurazione come tale:

  # configurazione sshd che consente solo certificati RSA Indirizzo di corrispondenza 10.0.0.0/8,172.16.0.0/12,192.168.0.0/24PasswordAuthentication sì  

Come un'altra storia spaventosa aneddotica, prima di passare ai certificati RSA obbligatori , uno dei compromessi di phishing è stato eseguito in t Nella settimana esatta ci sono stati due aggiornamenti del kernel per le vulnerabilità che hanno consentito l'escalation dei privilegi a root, e se non avessi aggiornato sul posto, sarei stato root compromesso. (e se la mia memoria non mi viene a mancare, era intorno al 4 luglio ... gli hacker adorano salvare quei brutti attacchi per i periodi di vacanza)

Per quanto riguarda i grafici degli attacchi live effettivi in ​​tempo reale, uno sguardo a:

• L'interfaccia grafica del progetto Norse. È molto istruttivo.
• Una mappa degli attacchi DDOS.
• Una vista gratuita della rete di monitoraggio della sicurezza centrale di Checkpoint, dove gli agenti sono i loro clienti.

Per finire la risposta:

No, probabilmente non sei compromesso in alcun modo.

Sì, devi prendere misure per aumentare il tuo livello di sicurezza. Consiglierei un tunnel / client VPN dall'esterno al tuo server VPN aziendale. È quello che sto facendo in realtà.

Ho anche un ultimo e importante consiglio: per assicurarti che un account normale non sia compromesso, controlla il tuo /var/log/auth.log log di autenticazione per un'autenticazione riuscita. Esistono modi per accedere a openssh con qualsiasi account senza che sia registrato in / var / log / wtmp e di conseguenza non compaia nel comando last .

Inutile dire che se un account normale viene compromesso in una vecchia macchina senza aggiornamenti, tutte le scommesse vengono annullate. E nello sfortunato caso di escalation dei privilegi a root, anche i log possono essere compromessi.

Sì, vieni forzato. Ma non penso che dovresti preoccuparti di qualsiasi forza bruta che rilevi proveniente da Internet. Tuttavia, dovresti essere preoccupato per gli attacchi di forza bruta provenienti dalla tua rete.

Essere forzati è molto comune e fintanto che non usi password per SSH (o usi password valide) , l'attacco non avrà assolutamente successo (specialmente con una supposizione ogni 3-4 secondi).

Tuttavia, l'IP (172.25.1.1) è sulla stessa rete di te. Questo è il vero problema e dovresti verificare se questa macchina è compromessa il prima possibile .

Stai sopravvivendo all'attacco, dalle apparenze. SSH sta facendo quello che dovrebbe fare. Tuttavia, vedi sotto per alcuni passaggi da eseguire al più presto per garantire la sopravvivenza.

Inoltre, e sfortunatamente, un sistema all'interno della rete è stato compromesso. Troppo comune in questi giorni. Dovresti accertare la natura di questo attacco apparentemente interiore, ma non dare per scontato che questo sistema sia compromesso semplicemente sulla base di questo file di log . Chiunque gestisca un SSHD con connessione web lo ha visto prima, più e più volte, per anni. Correggi l'installazione di SSHD su questo host, quindi esamina il sistema su 172.25.1.1.

Segui le migliori pratiche SSHD come queste ...

Disattiva l'autenticazione della password a favore di autenticazione basata su chiave:

  # grep PasswordAuth sshd_config | grep noPasswordAuthentication no  

Come accennato, disabilita i login di root:

  PermitRootLogin no  

Aggiungi utenti autorizzati a sshd_config:

  AllowUsers myusername the_other_sysop_guy  

Se esegui l'ultimo, il messaggio di log cambierà da "utente non valido" a "utente illegale".

A seconda della situazione aziendale, puoi anche pensare a firewallare la porta SSHD (consentire SSH solo da indirizzi IP autorizzati) o cambiarlo utilizzando una porta diversa (che è davvero sicurezza per oscurità, ma la maggior parte degli attacchi di questa natura sono in realtà script). Purtroppo, il fatto che l'aggressore sembri essere all'interno della tua LAN potrebbe far sì che questi non offrano tanto aiuto quanto avrebbero altrimenti.

Per inciso, il fatto che il dispositivo sia a 1.1 mi fa chiedere se " sei entrato nel tuo router? ;-)

L'aspetto standard dei log sembra essere un comune attacco di forza bruta poiché i nomi inseriti nei log provengono da un dizionario standard utilizzato. Anche gli elenchi di parole comuni li considerano come i nomi utente di destinazione principale. Inoltre, l'iniezione proviene da un IP privato di classe B. Non preoccuparti, però, fintanto che le password che hai applicato sono abbastanza forti e hai un bilanciamento del carico per gestirlo, non sarà un problema per te. Cerca misure per proteggerlo nelle misure di protezione della forza bruta SSH in SSH.

Poiché tutti gli accessi SSH al tuo server vengono reindirizzati tramite lo stesso indirizzo IP locale, ti consiglio di usare fail2ban con attenzione, se decidi di usarlo. L'installazione di fail2ban sullo stesso server di sshd comporterà il blocco dell'IP 172.25.1.1 sul posto. Dopodiché, nessuno sarà in grado di accedere tramite SSH al tuo server.

Se puoi installare fail2ban sul server che reindirizza il traffico SSH, fallo. Uso fail2ban sul mio server SSH pubblico e fa un ottimo lavoro limitando l'attaccante a 3 tentativi in ​​10 minuti. La maggior parte degli script "cracking" utilizzati dagli script kiddies andranno semplicemente in timeout dopo questi 3 tentativi e non mi daranno più fastidio per giorni.

Puoi anche rallentare la password che indovina l'attaccante abbastanza facilmente.

Nel file /etc/pam.d/sshd , puoi aggiungere una riga come questa:

  auth optional pam_faildelay.so delay = 7000000  

Ad ogni tentativo di accesso sshd fallito, il modulo PAM attenderà 7 secondi. Potresti voler aumentare o diminuire il ritardo, perché se imposti la tua password, aspetti 7 secondi per ricevere un altro prompt. Azzardo l'ipotesi che la maggior parte dei programmi per indovinare la password SSH siano così poco sofisticati da non avere un timeout per l'attesa di un nuovo prompt, ma è possibile che un ritardo molto lungo causi il timeout di programmi di indovinazione migliori a un certo punto. / p>