Qual è il tentativo di hacking in corso quando vedo: non ha rilasciato MAIL / EXPN / VRFY / ETRN durante la connessione a MTA

Question

Qual è il tentativo di hacking in corso quando vedo: non ha rilasciato MAIL / EXPN / VRFY / ETRN durante la connessione a MTA

#1 da (3 voti)
#2 da (2 voti)
#3 da (0 voti)

0

Quando guardo i miei registri di sendmail, di gran lunga l'errore più comune che vedo è il seguente:

22 novembre 16:49:50 MyHostname sendmail [18832]: rAMMnj2u018832: [ indirizzo IP redatto per nascondere il colpevole ] non ha emesso MAIL / EXPN / VRFY / ETRN durante la connessione a MTA

Questo non proviene da MUA mal configurati all'interno della mia piccola rete. Viene sempre da fuori dalla mia rete, da dove solo i MTA dovrebbero comunicare con il mio sendmail. La stragrande maggioranza, la principale fonte di questi indirizzi IP è la Cina, ma molti altri paesi ne sono la fonte.

Suppongo che questo debba far parte di una sorta di tentativo di hackeraggio, ma non riesco a capire di cosa si tratta. Proviene da hacker / script che si collegano alla porta 25, capisco che il mio sendmail non è una combinazione di MTA / OS / versione in cui possono entrare e disconnettersi senza fare nulla? (Se è così, perché si collegano ripetutamente?) Oppure sta succedendo qualcos'altro? Mentre ho fail2ban in esecuzione, e vedo verificarsi divieti regolari, c'è altro da fare al riguardo? Per il contesto, il sistema operativo è Fedora 19.

Nota: ciò che mi confonde in particolare è che di solito vedo molti di questi in fila dallo stesso indirizzo IP. Non lo vedo quasi mai solo una volta da un dato indirizzo IP. Sono persino stato "attaccato" in questo modo, prima, da più server nella stessa sottorete ... dopo che ognuno è stato bannato (tramite fail2ban), si spostano semplicemente sul server successivo nella stessa / 24 sottorete. Alla fine ho cambiato la mia regola send2ban di sendmail per mettere al bando un'intera / 24 subnet invece di un solo indirizzo IP - solo per ridurre il rumore. Se questo fosse solo un "check-in per vedere se potevamo sfruttare" allora mi aspetterei un singolo bussare alla porta, non tali ripetuti tentativi.

In realtà sono tentato di mettere un ascolto di 24 ore sulla porta 25 - ricevo abbastanza posta che questo non mi ucciderebbe - solo per cercare di capire cosa sta succedendo in queste connessioni. Alcuni giorni ottengo dozzine di queste connessioni dallo stesso indirizzo IP.

linux smtp attacks

posta Eddie 23.11.2013 - 00:21

fonte

3 risposte

Leggi altre domande sui tag linux smtp attacks

Confronto tra bcrypt e scrypt Utilizzo della stessa stringa di base per una password in diversi accessi diversi [duplicato]

score 3 · Answer 1

SMTP si aspetta i comandi nella seguente sequenza:

HELO o EHLO nomeserver
MAIL FROM: < indirizzo >
RCPT TO: < indirizzo >
DATA

Sebbene tecnicamente anziché MAIL FROM , il server potrebbe inviare EXPN , VRFY o ETRN , anche se nessuno lo fa mai.

A quanto pare il tuo server ha ricevuto il saluto di HELO o EHLO , ma poi niente, o qualcosa dopo quello che non era previsto.

Spesso provengono da agenti di monitoraggio o altri scanner che non sono interessati a inviare effettivamente mail, ma piuttosto a testare per vedere cosa sta ascoltando. Inoltre, è probabile che stiano tentando di sfruttare alcune vecchie vulnerabilità, che sono (correttamente) semplicemente interpretate come spazzatura e che interrompono la connessione.

Tipicamente, quando un server prende alcuni passi insoliti (come quello di interrompere prematuramente una conversazione) farà sì che una voce di log noti il fatto, nel caso in cui sia necessario eseguirne il debug in seguito.

score 2 · Answer 2

did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA

Ciò accade a volte quando il client non ha emesso alcun comando relativo all'invio effettivo di posta al server (MTA). Questo potrebbe significare che sei stato scansionato e che stanno semplicemente afferrando il tuo banner per vedere quale versione del server stai usando. Potrebbe quindi essere parte di una fase di raccolta delle informazioni, e quindi un preavviso dello spam in entrata.

score 0 · Answer 3

Ho avviato WireShark sulla porta 25 ed è in corso da quasi 24 ore. Ho visto tre diverse varianti di questo finora. Suppongo che ce ne siano molti altri. Questo mi ha anche aiutato a capire che il mio sendmail sta dando il suo nome esatto (sendmail al posto di postfix o qualcos'altro) e la versione. Ho modificato la risposta di 220 di seguito.

Ci sono gli "attacchi" che ho visto finora:

Il client ha emesso FIN prima che l'evento del server SMTP emettesse il 220. In altre parole, ho visto l'handshake a tre vie, seguito da un pacchetto FIN che chiudeva il lato client, seguito dal mio sendmail che emetteva la sua linea di identificazione 220 , seguito da FIN / ACK e chiusura della presa. Non ho idea di quale fosse il punto di tale connessione! Rilasciando FIN prima che sendmail avesse effettivamente inviato il 220, il client ha rinunciato alla possibilità di interagire con esso in qualsiasi modo. Se succedesse un gruppo di questi, penserei che forse è stato un DoS, ma è successo esattamente una volta. Strano.
Un client ha rilasciato HELO con un nome di dominio non valido, quindi EHLO con lo stesso nome di dominio non valido, in cui sendmail apparentemente non registra il fatto che sta restituendo denunce 501 "nome di dominio non valido". Ha registrato solo che non ha mai ricevuto MAIL / EXPN / VRFY / ETRN, che è fuorviante. Di seguito è riportata una trascrizione SMTP modificata da WireShark, in cui i nomi sono stati soppressi per nascondere il colpevole ei numeri in [ ] sono i valori esadecimali di ciò che è stato inviato come parte del nome host. soppresso è dove sto sopprimendo il nome host effettivo inviato.

220 MyHostname ESMTP Sendmail versione / versione ; Sun, 24 Nov 2013 04:05:22 -0400
EHLO [c7 cf bf b5 c1 f8]. soppressa .co.kr
501 5.0.0 Invalid domain name
HELO [c7 cf bf b5 c1 f8]. soppresso .co.kr
501 5.0.0 Invalid domain name

Quindi in pratica ha inviato sei caratteri con il set di bit più alto, quindi quello che è effettivamente un dominio valido dopo. Forse un po 'di soffocamento del MTA sui personaggi falsi?

Questo è un tentativo di "bussare", immagino. ad es. che vede la versione sbagliata e si arrende.

220 MyHostname ESMTP Sendmail versione / versione ; Sun, 24 Nov 2013 09:52:59 -0400
RSET
250 2.0.0 Stato di reset
QUIT
221 2.0.0 MyHostname chiusura della connessione

O questo stava bussando, o forse alcuni MTA fanno qualcosa di divertente dopo aver ottenuto RSET ?

La morale della storia? Sendmail fornisce questo registro per una serie di comportamenti malevoli o bizzarri diversi del client.