Facebook  -  Twitter      

Questo forum fa uso dei cookie
Questo forum utilizza i cookie per memorizzare i dettagli del tuo login o della tua ultima visita. I cookie sono piccoli files di testo salvati nel computer; i cookie da noi utilizzati sono relativi unicamente ai servizi da noi forniti direttamente o dai banner pubblicitari. I cookie su questo forum salvano inoltre i dettagli relativi alle discussioni lette e alle tue preferenze personali. Sei pregato di selezionare il tasto OKAY se sei consapevole della presenza di questi files e ci autorizzi ad utilizarli per le informazioni specificate.

Indipendentemente dalla tua scelta un cookie verrà salvato per memorizzare nel tuo pc la risposta a questo form. Puoi modificare le impostazioni relative ai cookie nelle preferenze del tuo browser.

  • 0 voto(i) - 0 media
  • 1
  • 2
  • 3
  • 4
  • 5
Guida: Drop VS Reject?

#1
Molti firewall hanno come impostazione predefinita il drop silente dei pacchetti al posto del reject per le regole di negazione del traffico.
[hide]
Qual è la differenza? E' veramente meglio il drop del reject?

I firewall normalmente mettono a disposizione tre opzioni per il controllo del traffico:

Pass o Accept: lascia che il traffico passi;
Block o Drop: scarta il pacchetto in modo silente senza generare messaggi di risposta;
Reject: rifiuta il pacchetto e risponde con un pacchetto ICMP type3, code 13 (type=Destination Unreachable, Code=Communication administratively prohibited).

Ma durante un port scan?

Uno scanner di rete identifica gli host collegati in base alla risposta che danno durante l'interrogazione.
Le risposte che può ricevere sono due:

TCP SYN/ACK: la porta è aperta;
TCP RST/ACK: la porta è chiusa.

Quindi per rendere tutto più semplice:

host off-line: viene restituito un pacchetto ICMP host unreachable dal router a monte;
la rete a cui è collegato l'host è off-line: viene restituito un pacchetto ICMP network unreachable dal router a monte;
un host o un firewall effettuano un reject: viene restituito un pacchetto ICMP communication administratively prohibited;
un host o un firewall effettuano un drop/block: non viene restituito alcun pacchetto.

Fate attenzione agli ultimi due comportamenti, perchè riguardano proprio il drop e il reject di un pacchetto.
Se viene effettuato un drop, lo scanner non riceve nulla in risposta ai pacchetti sonda, mentre se viene effettuato un reject allora riceve un pacchetto ICMP di risposta.

Perchè i costruttori di firewall preferiscono il drop o block?

La motivazione più comune per preferire il drop è:

permette di nascondere meglio il firewall e il suo IP;
permette un minor consumo di banda;

Apparentemente queste due affermazioni sembrano avere un senso e sembrano essere vere, ma ora vi mostrerò come invece risultino essere decisamente false.

Il firewall è realmente nascosto con il drop?

La prima affermazione deriva dalla logica che se il firewall non restituisce alcun pacchetto a un possibile attaccante, questo non sarà in grado di sapere che esiste.
Se riguardiamo le quattro casistiche viste precedentemente vediamo che l'unico caso in cui uno scanner di rete non riceve risposte di ritorno è quando c'è un firewall che effettua un drop.
Quindi il drop dei pacchetti non aiuta affatto a nascondere il firewall, ma comunica in modo inequivocabile che c'è un firewall.
Per questo motivo tool come NMAP quando non ricevono pacchetti di risposta indicano come filtered l'host su cui stavano attuando la scansione.
L'affermazione che il drop nasconde l'IP del firewall è solo parzialmente corretta perchè una volta scoperto che esiste un firewall che sta effettuando il drop dei pacchetti si può agevolmente sfruttare il trace route per scoprire l'IP del firewall.

Il drop permette realmente un minor consumo di banda?

Se si considera il fatto che il firewall che effettua il drop dei pacchetti non genera direttamente traffico, l'affermazione sembra vera, ma non tiene conto della natura e del protocollo TCP/IP basato sull'inaffidabilità della rete.
Pertanto per ogni pacchetto che il nostro firewall blocca ne vengono ritrasmessi altri generando più traffico di un semplice pacchetto di RST/ACK.

Il drop favorisce lo spoofing

Uno dei maggiori problemi generati dall'uso del drop è il fatto di rendere il range dei vostri IP più attraenti per lo spoofing.
Consideriamo un tipico attacco SYN flood dove un attaccante cerca di sovraccaricare di richieste un server con richieste illegittime facendo in modo che questo non possa più rispondere alle richieste legittime.
L'attaccante, per mantenere occupato il server, crea delle connessioni che vuole lasciare pendenti per tenere il server in attesa di risposta.
Il modo migliore per raggiungere questo obiettivo è inviare dei pacchetti spoofed (pacchetti in cui l'IP del mittente è contraffatto) che consentono anche di mantenere l'identità dell'attaccante nascosta.

Quali IP sono più attraenti per effettuare spoofing?

Sicuramente gli IP corrispondenti a firewall che effettuano drop, perchè non rispondendo ai pacchetti SYN/ACK che vedranno arrivare, manterranno il server attaccato in attesa di risposte che non arriveranno mai.

[Immagine: syn%20flood.png]
Drop VS Reject

Quindi, ricapitolando, abbiamo visto come possa tornare comodo a un attaccante individuare e sfruttare dei firewall che fanno uso di drop per:

nascondere la vera entità dell'attaccante (anche se l'attacco avviene da host zombie è utile proteggerli);
far sì che l'IP "spoffato" non risponda e si renda parte attiva dell'attacco.
A queste due motivazioni ne aggiungiamo una terza:

far in modo che l'attaccato rimanga occupato più a lungo possibile con un singolo pacchetto.
Per comprendere questa affermazione dobbiamo ricorrere all'elenco iniziale integrato con ulteriori informazioni

Host on-line: invia RST/ACK, tempo di risposta 50 ms o inferiore;
Host off-line: invia host unreachable, tempo di risposta 3 ms o inferiore;
Network off-line: invia network unreachable, tempo di risposta 50 ms o inferiore;
Regola di reject: invia communication administratively prohibited, tempo di risposta 50 ms o inferiore;
Regola di drop/block: non invia nulla, tempo di attesa 30 s o superiore.

Cosa dice lo standard?

Per ora ci siamo limitati a fare delle considerazioni di convenienza, ma cosa dicono gli standard?
Riferendoci al RFC 1122 (Requirements for Internet Hosts - Communication Layers) troviamo la seguente affermazione:

[Immagine: RFC%201122.png]
Con "specifically prohibited" si fa riferimento al fatto che non è ammesso rispondere a un pacchetto di errore con un altro pacchetto di errore per non creare dei loop.
Quindi possiamo affermare che anche lo standard vorrebbe che venissero impiegati dei pacchetti di risposta piuttosto che dei drop silenti.

I vantaggi del reject

Finora abbiamo smontato le false credenze sui vantaggi del drop, abbiamo visto che può essere utile per chi fa attacchi SYN flood con spoofing, e abbiamo preso in considerazione cosa dice lo standard; ora vedremo quali possono essere i vantaggi che il reject può offrire.
Essenzialmente i vantaggi offerti dal reject possono essere i seguenti:

facilita il lavoro di troubleshooting in caso di problemi;
riduce il traffico di rete;
riduce i tempi di risposta (per questo motivo molti, pur rimanendo legati al drop, lo utilizzano per le regole interne alla lan per evitare agli host perdite di tempo in attesa di risposte che non giungeranno mai);
è meno sfruttabile per attacchi SYN flood con spoof.

Conclusioni

Con questo articolo spero di avervi convinto che il drop non è sicuramente meglio del reject o, perlomeno, spero di avervi messo qualche dubbio che vi induca ad approfondire l'argomento anche con dei test sul campo, o sarebbe meglio dire sulla rete.
Sul web troverete delle vere e proprie guerre di religione legate all'argomento, pertanto questo articolo può essere considerato un mio punto di vista con qualche dato a dimostrazione della tesi.
Se proprio non potete far a meno di utilizzare il drop potete almeno provare a usare il reject sull'interfaccia LAN e potrete verificare voi stessi i primi tre vantaggi riportati sopra.
Siccome la mediazione è sempre la strada migliore potreste trovare firewall in cui, utilizzando il reject, i messaggi di risposta possono essere configurati in modo da ingannare l'attaccante e spacciare il firewall per un router intermedio o meglio ancora per sovraccaricarlo mettendo in atto il tarpit per mitigare gli attacchi DDoS.
[/hide]
Cita messaggio

#2
molto interessante!!!
Cita messaggio

#3
Ottimo chiarimento ... Per chi ha tempo , sarebbe interessante fare appunto dei test su campo , come suggerisci tu giustamente ..
Cita messaggio

#4
li farei io ben volentieri....ma per ora mi limito a collegarmi con winbox.....sono moooolto alle prime armi..! ci do dentro e mi faccio risentire in questa sezione!
Cita messaggio

#5
(30-11-2014, 12:10)riccardo bossio Ha scritto: li farei io ben volentieri....ma per ora mi limito a collegarmi con winbox.....sono moooolto alle prime armi..! ci do dentro e mi faccio risentire in questa sezione!

a che punto sei?
MTCNA Certified
MTCRE Certified
------------------------------
www.routerositalia.it
www.ubntitalia.it
Cita messaggio


[-]
Condividi/Segnala (Mostra tutti)
Facebook Linkedin Twitter

Discussioni simili
Discussione Autore Risposte Letto Ultimo messaggio
  Guida: Creare server RADIUS su Debian hamtarociaoo 9 4'197 16-07-2015, 14:04
Ultimo messaggio: melllinz
  Guida: Attivare UPnP su Windows 7, Vista, XP hamtarociaoo 0 3'264 22-11-2013, 22:37
Ultimo messaggio: hamtarociaoo
Lightbulb Guida: Problemi comuni hamtarociaoo 0 1'273 04-11-2013, 18:13
Ultimo messaggio: hamtarociaoo
Lightbulb Guida: Mettere in sicurezza un computer hamtarociaoo 0 1'192 24-10-2013, 16:56
Ultimo messaggio: hamtarociaoo
Information Guida: I messaggi di DHCP cisco88 0 1'109 12-09-2013, 16:41
Ultimo messaggio: cisco88
  Guida: Numeri utili in networking cisco88 2 1'380 11-09-2013, 14:56
Ultimo messaggio: cisco88
  Guida: Primi passi nel subnetting Ipv4 cisco88 0 1'264 11-09-2013, 11:54
Ultimo messaggio: cisco88
  Guida: Connettere tutti gli apparecchi di casa ad internet hamtarociaoo 0 1'155 23-08-2013, 13:40
Ultimo messaggio: hamtarociaoo
Information Guida: Gestire da remoto stampante su Server Microsoft hamtarociaoo 0 967 23-08-2013, 11:39
Ultimo messaggio: hamtarociaoo
  Guida: Sicurezza a 360° hamtarociaoo 0 894 19-08-2013, 19:33
Ultimo messaggio: hamtarociaoo

Digg   Delicious   Reddit   Facebook   Twitter   StumbleUpon  


Utenti che stanno guardando questa discussione:
1 Ospite(i)


Powered by MyBB, © 2002-2017 MyBB Group.