Quale tipo di attacchi verrà affrontato da un server SMTP se non ha la ratelimitazione durante l'invio di e-mail?

2

Assumi un sito web con qualche tipo di opzione mailer, che non imponga alcuna limitazione della velocità: questo consente agli utenti di inviare una quantità illimitata di email al secondo.

SMTP affronterà possibili attacchi DoS per questo? O qualsiasi tipo di problema? Qualcuno può spiegarlo?

    
posta Arun 07.07.2014 - 07:15
fonte

2 risposte

0

Non importa se usi la limitazione della velocità o meno. Se stai utilizzando un server pubblico, che accetta connessioni in entrata, è sempre e ovunque vulnerabile per un DDoS. La limitazione della velocità può essere utile per non congestionare il sistema, potrebbe essere una possibile contromisura contro il DoS ma, di gran lunga, non protegge completamente contro un attacco DoS.

    
risposta data 07.07.2014 - 10:35
fonte
2

Una delle difficoltà nel mettere in sicurezza SMTP risiede nel protocollo stesso, in particolare le ammonizioni in RFC 5321 che forniscono le proscrizioni sulla tempistica di una sessione. Un'implementazione fedele non offre alcuna possibilità di programmare una sessione. Idealmente si vorrebbe ignorare tali raccomandazioni e impostare un timeout della sessione per la sessione di posta. Ciò impedirà ad esempio eventuali attacchi in cui vengono utilizzati lunghi ritardi per l'invio di dati carattere per carattere con grandi dimensioni della posta. Ad esempio, se si dispone di un server di posta con un limite di dimensioni della posta di 10 MB, è abbastanza facile scrivere uno script che recapita una mail falsa sul server e scrive un messaggio Lorem Ipsum, un carattere alla volta fino al limite di 10 MB, ma ritardare ogni carattere di 1 - 2 minuti. In teoria, senza un limite di sessione, una tale sessione di posta elettronica potrebbe durare circa 10 milioni di minuti. Quindi ora esegui uno script che avvia semplicemente i robot che fanno questo da centinaia di punti sul web, e molto presto i robot avranno tutte le connessioni legate (supponendo che tu abbia dei limiti di connessione, o stiano usando un pool di connessioni).

Idealmente, si dovrebbe impostare un timer dal momento in cui il comando DATA è stato emesso al momento in cui è stato emesso il "CRLF .CRLF". Qualcosa come 5 minuti o così per l'intera trasmissione dei dati dovrebbe essere ragionevole. E violare la RFC e semplicemente rilasciare la connessione se supera questo timeout. I clienti ben educati non si avvicinano mai a questo limite e anche le persone che usano il terminale a riga di comando dovrebbero essere in grado di inviare dati entro quel lasso di tempo presumendo che sappiano come digitare.

    
risposta data 22.02.2018 - 05:49
fonte

Leggi altre domande sui tag