"POSSIBILE TENTATIVO DI ROTTURA!" In / var / log / secure - cosa significa?


96

Ho una scatola CentOS 5.x in esecuzione su una piattaforma VPS. Il mio host VPS ha interpretato erroneamente una richiesta di supporto che avevo sulla connettività e cancellato efficacemente alcune regole di iptables. Ciò ha comportato l'ascolto di ssh sulla porta standard e il riconoscimento dei test di connettività delle porte. Fastidioso.

La buona notizia è che ho bisogno di chiavi autorizzate SSH. Per quanto ne so, non credo che ci sia stata alcuna violazione riuscita. Sono comunque molto preoccupato per quello che vedo in / var / log / secure:


Apr 10 06:39:27 echo sshd[22297]: reverse mapping checking getaddrinfo for 222-237-78-139.tongkni.co.kr failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 10 13:39:27 echo sshd[22298]: Received disconnect from 222.237.78.139: 11: Bye Bye
Apr 10 06:39:31 echo sshd[22324]: Invalid user edu1 from 222.237.78.139
Apr 10 06:39:31 echo sshd[22324]: reverse mapping checking getaddrinfo for 222-237-78-139.tongkni.co.kr failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 10 13:39:31 echo sshd[22330]: input_userauth_request: invalid user edu1
Apr 10 13:39:31 echo sshd[22330]: Received disconnect from 222.237.78.139: 11: Bye Bye
Apr 10 06:39:35 echo sshd[22336]: Invalid user test1 from 222.237.78.139
Apr 10 06:39:35 echo sshd[22336]: reverse mapping checking getaddrinfo for 222-237-78-139.tongkni.co.kr failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 10 13:39:35 echo sshd[22338]: input_userauth_request: invalid user test1
Apr 10 13:39:35 echo sshd[22338]: Received disconnect from 222.237.78.139: 11: Bye Bye
Apr 10 06:39:39 echo sshd[22377]: Invalid user test from 222.237.78.139
Apr 10 06:39:39 echo sshd[22377]: reverse mapping checking getaddrinfo for 222-237-78-139.tongkni.co.kr failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 10 13:39:39 echo sshd[22378]: input_userauth_request: invalid user test
Apr 10 13:39:39 echo sshd[22378]: Received disconnect from 222.237.78.139: 11: Bye Bye

Che cosa significa esattamente "TENTATIVO DI BREAK-IN TENTATIVO"? Che ha avuto successo? O che non gli è piaciuto l'IP da cui proveniva la richiesta?

Risposte:


78

Purtroppo questo ora è un evento molto comune. È un attacco automatizzato su SSH che utilizza nomi utente "comuni" per tentare di entrare nel tuo sistema. Il messaggio significa esattamente quello che dice, non significa che sei stato violato, solo che qualcuno ci ha provato.


Grazie Lain. Mi fa sentire meglio. Sono davvero contento di aver richiesto le chiavi autorizzate per ssh. =)
Mike B,

28
"inversione della mappatura per il controllo di getaddrinfo per" riguarda di più l'IP di origine / nome host elaborato. Lo stesso traffico predisposto sta provando nomi utente errati, ma nomi utente errati non generano il messaggio "POSSIBLE BREAK-IN TENTATIVO".
poisonbit

11
@MikeyB: potresti voler esaminare l'aggiunta di fail2ban al tuo sistema. Questo può essere configurato per bloccare automaticamente gli indirizzi IP di questi aggressori.
user9517

9
Si noti che il "mapping inverso non riuscito" può semplicemente significare che l'ISP dell'utente non ha configurato correttamente il DNS inverso, il che è abbastanza comune. Vedi la risposta di @Gaia.
Wilfred Hughes,

1
Questo è inaccurato, significa solo che il DNS inverso non corrisponde al nome host che il client ha inviato per identificarsi. È probabilmente contrassegnato poiché potrebbe essere stato un tentativo di interruzione per le persone che utilizzano .rhostso l' .shostsautenticazione (non l'ho mai visto usato). Le scansioni avvengono, ma questo non è ciò di cui tratta questo messaggio (anche se qualsiasi connessione può attivarlo) (Per le scansioni, è meglio cercare i messaggi utente non autorizzati / sconosciuti)
Gert van den Berg

52

In particolare, la parte "POSSIBLE BREAK-IN TENTATIVO" è correlata alla parte "inversione del controllo che verifica getaddrinfo non riuscita". Significa che la persona che si stava connettendo non aveva il DNS forward e reverse configurato correttamente. Questo è abbastanza comune, specialmente per le connessioni ISP, che probabilmente provengono dall'attacco.

Non correlato al messaggio "POSSIBLE BREAK-IN ATTENT", la persona sta effettivamente tentando di violare usando nomi utente e password comuni. Non utilizzare password semplici per SSH; in effetti l'idea migliore per disabilitare del tutto le password e usare solo le chiavi SSH.


1
Se è generato da una connessione (valida) tramite un ISP, puoi aggiungere una voce al tuo file / etc / hosts per eliminare questo errore di mappatura inversa. Ovviamente lo faresti solo se sapessi che l'errore è benigno e desideri ripulire i tuoi registri.
artfulrobot

32

"Che cosa significa esattamente" POSSIBILE TENTATIVO DI ROTTURA "?"

Ciò significa che il proprietario del netblock non ha aggiornato il record PTR per un IP statico nel suo intervallo e che tale record PTR è obsoleto, O un ISP non imposta record inversi adeguati per i suoi clienti IP dinamici. Questo è molto comune, anche per i grandi ISP.

Finisci per ricevere il messaggio nel tuo registro perché qualcuno proveniente da un IP con record PTR impropri (a causa di uno dei motivi sopra) sta provando a usare nomi utente comuni per provare SSH nel tuo server (possibilmente attacco bruteforce o forse un errore onesto ).

Per disabilitare questi avvisi, hai due possibilità:

1) Se si dispone di un IP statico , aggiungere la mappatura inversa al file / etc / hosts (vedere ulteriori informazioni qui ):

10.10.10.10 server.remotehost.com

2) Se hai un IP dinamico e vuoi davvero far sparire quegli avvisi, commenta il "GSSAPIAuthentication yes" nel tuo file / etc / ssh / sshd_config.


2
commentare GSSAPIAuthenticationnon aiuta nel mio caso (
SET

UseDNS noè probabilmente l'impostazione migliore per sbarazzarsi di esso (e degli accessi lenti quando il server ha problemi DNS ...)
Gert van den Berg

15

È possibile semplificare la lettura e il controllo dei registri disattivando le ricerche inverse in sshd_config (UseDNS no). Ciò impedirà a sshd di registrare le righe "noise" contenenti "POSSIBLE BREAK-IN TENTATIVO" che consente di concentrarsi sulle righe leggermente più interessanti contenenti "Utente non valido UTENTE da IPADDRESS".


4
Qual è lo svantaggio di disabilitare le ricerche inverse sshd su un server connesso a Internet pubblico? C'è qualche vantaggio a lasciare questa opzione abilitata?
Eddie,

2
@Eddie Non credo che le ricerche DNS eseguite da sshd abbiano alcuno scopo utile. Esistono due buoni motivi per disabilitare le ricerche DNS. Le ricerche DNS possono rallentare l'accesso se le ricerche scadono. E i messaggi "POSSIBLE BREAK-IN TENTATIVO" nel registro sono fuorvianti. Tutto quel messaggio significa davvero che il client ha un DNS configurato male.
Kasperd,

1
Non sono d'accordo @OlafM - "UseDNS no" dice a sshd di non eseguire il controllo del mapping inverso e quindi non aggiungerà alcuna riga contenente "POSSIBLE BREAK-IN ATTENT" nei registri di sistema. Come effetto collaterale, può anche velocizzare i tentativi di connessione da parte di host che non hanno DNS DNS configurato correttamente.
Orario

1
Sì, ho fatto @OlafM, circa 4-5 anni fa su Linux. Accorciò notevolmente i miei registri e smise di logcheckinfastidirmi con inutili rapporti e-mail.
TimT

1
L'uso principale di UseDNSè per (cattiva idea da usare) .rhostse .shostsautenticazione ( HostbasedAuthentication). (E l' Fromopzione di corrispondenza nella configurazione SSHD e authorized_keys) (Esiste HostbasedUsesNameFromPacketOnlytuttavia un'impostazione separata che potrebbe essere necessaria per cambiare le ricerche inverse anche per l'autenticazione basata su host, idea peggiore rispetto all'utilizzo dell'autenticazione basata su host ...)
Gert van den Berg

5

Non è necessario un login riuscito, ma ciò che dice "posible" e "tentativo".

Un ragazzaccio o un kiddie di script ti sta inviando traffico elaborato con un IP di origine falso.

Puoi aggiungere limiti IP di origine alle tue chiavi SSH e provare qualcosa come fail2ban.


2
Grazie. Ho iptables impostato per consentire la connettività ssh solo da fonti selezionate. Ho anche Fail2ban installato e funzionante.
Mike B,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.