Come determinare da dove provengono i tentativi di accesso ssh?

Question

Come determinare da dove provengono i tentativi di accesso ssh?

#1 da (1 voti)
#2 da (1 voti)

1

Stavamo testando un'istanza AWS che accede a un server interno Ubuntu 10.04.3, quindi avevamo modificato il nostro firewall per consentire a tutte le porte da quel specifico indirizzo IP al server. Abbiamo quindi rilasciato l'istanza AWS ma abbiamo dimenticato di rimuovere la regola del firewall.

Ieri, qualcuno ha notato tentativi falliti di login in auth.log che provenivano da varie località della Cina e della Corea (secondo whois.sc). Quindi abbiamo rimosso la regola del firewall e i tentativi di accesso sono stati interrotti.

Ecco una sezione di auth.log che mostra un tentativo di accesso fallito:

Feb 23 12:33:15 TestServer1 sshd[18822]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=117.21.226.10  user=root
Feb 23 12:33:15 TestServer1 sshd[18822]: pam_winbind(sshd:auth): getting password (0x00000388)
Feb 23 12:33:15 TestServer1 sshd[18822]: pam_winbind(sshd:auth): pam_get_item returned a password
Feb 23 12:33:15 TestServer1 sshd[18822]: pam_winbind(sshd:auth): request wbcLogonUser failed: WBC_ERR_AUTH_ERROR, PAM error: PAM_USER_UNKNOWN (10), NTSTATUS: NT_STATUS_NO_SUCH_USER, Error message was: No such user
Feb 23 12:33:17 TestServer1 sshd[18822]: Failed password for root from 117.21.226.10 port 2539 ssh2

Ovviamente, poiché la regola del firewall era ancora in vigore per l'istanza AWS, lasciava passare il traffico per quell'IP, ma mi chiedo come l'IP esterno 117.21.226.10 abbia avuto accesso al nostro server interno. È forse un IP falsificato, e non il vero mittente? Se è vero, non significa che Amazon consente pacchetti di spoofing sulla loro rete?

Non sono il tipo di configurazione di rete qui e mi sto chiedendo per il mio vantaggio, quindi scusami se questa è una domanda noob.

ssh

posta Alan 26.02.2014 - 19:01

fonte

2 risposte

1

Come diceva Ladadadada, l'IP registrato da SSH era effettivamente l'indirizzo del sistema di attacco.

Ho parlato con il nostro operatore di rete e ha configurato una mappatura Individuale dell'indirizzo IP dell'istanza AWS su un IP esterno nel nostro firewall che indicava il nostro server interno.

192.168.30.36 <-- 123.123.123.123 (our external ip) <-- Internet <-- Amazon IP

Crede che quando abbiamo rilasciato l'istanza di AWS qualcuno abbia successivamente ottenuto una nuova istanza con quello stesso IP. Hanno usato l'istanza come gateway per i robot per sondare la rete e hanno trovato il nostro server.

risposta data 26.02.2014 - 20:22

fonte

Leggi altre domande sui tag ssh

Cronologia delle password con PBKDF2 Prevenire l'interazione tra l'applicazione web su un account di hosting condiviso

score 1 · Accepted Answer

No, le connessioni TCP non possono essere falsificate ^[*]. TCP richiede la comunicazione bidirezionale, quindi i pacchetti di risposta devono tornare alla fonte e essere riconosciuti prima che la connessione possa continuare. Conoscendo con certezza che il traffico ti è stato inviato da quell'indirizzo.

Detto questo, non è possibile garantire che il traffico sia originario all'indirizzo in questione. Devi solo sapere che l'indirizzo che hai trovato è "l'ultimo salto" che il traffico impiega prima di arrivare a te. Gli hacker spesso rimbalzano le loro connessioni da server compromessi o utilizzano server compromessi in altri data center per condurre attacchi automatici.

Quindi l'indirizzo che vedi in genere rappresenta un'altra vittima dello stesso aggressore, le cui risorse vengono ora utilizzate per creare la posizione dell'aggressore.

^[*] Tecnicamente puoi spoofare i pacchetti TCP, ma per farlo devi essere da qualche parte sulla rotta che i pacchetti TCP avrebbero altrimenti preso. Quindi, ad esempio, il tuo ISP può violare il traffico da qualsiasi luogo, ma un server in Brasile che comunica con te ad Amsterdam avrebbe problemi a spoofingare un indirizzo in Cina.