<div id="reply-content">Mi sento più ricco, grazie.
</div>
<div id="0DB7FB15C2554BC29C3D213B4B5D20DD"><div><br></div>-- <br>Federico Ravasio<br><div>Sent with <a href="http://www.sparrowmailapp.com/?sig">Sparrow</a></div><div><br></div></div>
<p style="color: #A0A0A8;">On Friday, 8 February 2013 at 19:16, Dario Bertini wrote:</p>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<div id="quoted-message-content"><div><div>Nell'incontro di settimana scorsa, ho scoperto mio malgrado che è</div><div>parecchio diffusa l'opinione che sia più "sicuro" impostare il proprio</div><div>firewall per DROPpare le connessioni, invece che chiuderle</div><div>propriamente con un semplice REJECT</div><div><br></div><div>Visto che di materiale che spieghi esattamente la situazione in</div><div>italiano, ce n'è poco, sto scrivendo queste righe per esaminare tutte</div><div>le possibili ragioni di questa scelta:</div><div><br></div><div>Possibile ragione#1 si è "completamente invisibili" (oppure il</div><div>firewall è "invisibile"):</div><div><br></div><div>Falso: ci sono almeno 4 possibili risposte quando si prova ad aprire</div><div>una connessione TCP:</div><div>1-SYN/ACK: porta aperta</div><div>2-RST/ACK: porta chiusa/nessun servizio</div><div>3-ICMP destination unreachable (host unreachable: host offline/non</div><div>esistente, network unreachable: tutta la rete è offline, questo ci</div><div>verrà comunicato da un router a monte del nostro target,</div><div>administratively prohibited: chiusa da un firewall...)</div><div>4-(niente): porta con policy DROP</div><div><br></div><div>Il fatto che non si ritorni niente, è già un'informazione che si sta</div><div>fornendo... ok, la controparte non è (ancora) a conoscenza di dove sia</div><div>il firewall, ma non abbiamo guadagnato nulla</div><div><br></div><div>In compenso pare che si possano impostare dei firewall per ritornare</div><div>"host unreachable", ma questo ha senso solo se non hostate nessun</div><div>servizio sulla vostra macchina</div><div><br></div><div>Possibile ragione#2 rende più difficile/lungo/oneroso rilevare quali</div><div>servizi sono effettivamente disponibili:</div><div><br></div><div>Falso: non siamo più negli anni 90, e se anche il vostro attaccante</div><div>vuole ottenere subito una risposta (inusuale: è più pratico fare</div><div>girare gli scanner nottetempo su un grande numero di host) e se il</div><div>vostro attaccante scrive un tool di scanning in casa, non sarà così</div><div>sprovveduto da non sapere nemmeno come sfruttare il protocollo che</div><div>state usando</div><div><br></div><div>dal manuale di nmap:</div><div><br></div><div> SYN scan is the default and most popular scan option for</div><div>good reasons. It can be performed quickly, scanning thousands</div><div> of ports per second on a fast network not hampered by</div><div>restrictive firewalls. It is also relatively unobtrusive and</div><div> stealthy since it never completes TCP connections. SYN scan</div><div>works against any compliant TCP stack rather than depending</div><div> on idiosyncrasies of specific platforms as Nmap's</div><div>FIN/NULL/Xmas, Maimon and idle scans do. It also allows clear,</div><div> reliable differentiation between the open, closed, and</div><div>filtered states.</div><div><br></div><div> This technique is often referred to as half-open scanning,</div><div>because you don't open a full TCP connection. You send a SYN</div><div> packet, as if you are going to open a real connection and</div><div>then wait for a response. A SYN/ACK indicates the port is</div><div> listening (open), while a RST (reset) is indicative of a</div><div>non-listener. If no response is received after several</div><div> retransmissions, the port is marked as filtered. The port</div><div>is also marked filtered if an ICMP unreachable error (type 3,</div><div> code 1, 2, 3, 9, 10, or 13) is received. The port is also</div><div>considered open if a SYN packet (without the ACK flag) is</div><div> received in response. This can be due to an extremely rare</div><div>TCP feature known as a simultaneous open or split handshake</div><div> connection (see http://nmap.org/misc/split-handshake.pdf).</div><div><br></div><div>Ovviamente, non ha senso aspettare di ricevere una risposta, sapendo</div><div>che questa può non arrivare... ed nmap saggiamente può quindi</div><div>procedere in parallelo su tante diverse porte</div><div><br></div><div>Mi sono finalmente deciso di fare 2 o 3 prove, a sostegno di questa</div><div>tesi, in fondo potete trovare l'output completo, ma in sintesi:</div><div><br></div><div>nmap riesce a restituire le stesse informazioni in entrambi i casi, in</div><div>circa 19 secondi sia con DROP che con REJECT</div><div><br></div><div>Per essere esaustivi: il tempo può variare sensibilmente, sopratutto</div><div>se è la prima volta che vi collegate all'host (ho notato che anche</div><div>soltanto aver provato ad aprire una connessione ssh ed averla lasciata</div><div>fallire/andare in timeout cambia la prima misurazione, immagino che</div><div>questo sia dovuto al fatto che dei pacchetti sono già stati trasmessi</div><div>e che quindi da questi il kernel o nmap può ricavare informazioni sul</div><div>timeout/latenza da aspettarsi), e per assurdo... impostando la mia</div><div>macchina con policy REJECT, ed eseguendo nmap senza privilegi di root,</div><div>l'esecuzione risultava molto più lenta che non con policy DROP</div><div>(immagino che questo sia dovuto al fatto che con DROP, nmap è forzato</div><div>a passare alla porta successiva appena nota che la risposta non</div><div>arriva, mentre con REJECT, visto che la risposta arriva, e non ha la</div><div>possibilità di craftare i pacchetti come vuole, è "costretto" ad</div><div>aspettare)</div><div><br></div><div>Ancora: visto che m'era parso che alcune persone pensassero al</div><div>problema in certi termini: ci tengo a sottolineare che le informazioni</div><div>ritornate sono le stesse in entrambi i casi, e non aveva senso</div><div>aspettarsi altrimenti... pensare di essere più "vulnerabili" in un</div><div>modo o nell'altro, per quanto riguarda i servizi forniti, è</div><div>completamente assurdo</div><div>Se avete un demone senza le ultime patch di sicurezza, o se ssh è</div><div>aperto sulla porta di default-22 -o peggio- permettete</div><div>l'autenticazione ssh tramite password... queste cose sono quelle</div><div>veramente importanti</div><div><br></div><div>Possibile ragione#3 non siete vulnerabili ai DOS:</div><div><br></div><div>Falso (se usate la vostra macchina per hostare un qualunque tipo di servizio)</div><div><br></div><div>Ammettendo che esponiate un web server sulla porta 80, non potete</div><div>DROPpare bellamente la connessione a prescindere dai dettagli, ed a</div><div>questo punto la cosa più semplice è adottare la stessa regola sia per</div><div>tutte le porte:</div><div><br></div><div>Ovvero, rate-limiting (globale o discriminando sugli IP)... non ho</div><div>esperienza in quest'ambito, ma mi rendo comunque conto che potrebbe</div><div>non essere la scelta migliore:</div><div><br></div><div>Degradare intenzionalmente la qualità del servizio, potrebbe</div><div>facilitare il lavoro di un DOSer... a questo punto, sperando che</div><div>invece il vostro server regga al carico, potrebbe convenire non</div><div>limitare nulla</div><div><br></div><div>...O se invece avete tipi diversi di accessi alla macchina (anche solo</div><div>ssh per amministrazione), potrebbe invece convenire impostarli proprio</div><div>per salvaguardare gli usecase prioritari, insomma: _misurate_, e YMMV</div><div><br></div><div>Ok, questo spiega come mai DROP non sia l'idea fantastica che</div><div>pensavate fosse, ma ragioni _positive_ per fare altrimenti?</div><div><br></div><div>Beh, prima di tutto: il REJECT è il modo nel quale la gente si aspetta</div><div>che le cose funzionino, dall' RFC1122:</div><div><br></div><div> 3.3.8 Error Reporting</div><div><br></div><div> Wherever practical, hosts MUST return ICMP error datagrams on</div><div> detection of an error, except in those cases where returning an</div><div> ICMP error message is specifically prohibited.</div><div><br></div><div>Quando voi DROPpate, in pratica state mostrando un GIGANTESCO dito</div><div>medio, al client che ha provato a connettersi a voi...</div><div><br></div><div>e il client, potreste essere voi stessi nell'arco di qualche mese/anno</div><div>(o i vostri colleghi), quando illudendovi di aver esposto un servizio</div><div>sulla vostra macchina, trovate che il vostro script sta impiegando un</div><div>numero di secondi inusualmente superiore a quello che vi aspettavate,</div><div>finchè non realizzate infine che è andato in timeout</div><div><br></div><div>Un'altra ragione per evitare DROP, è un attacco SYN flood, nel quale</div><div>viene fatto lo spoofing dell'indirizzo IP della vostra macchina</div><div><br></div><div>Difatti, quando il server sotto attacco riceve il SYN e prova a</div><div>rispondere all'indirizzo IP spoofato, se quest'ultimo corrisponde ad</div><div>una macchina offline la connessione verrà chiusa in pochi secondi</div><div>se corrisponde ad una macchina la cui porta è sia aperta oppure</div><div>chiusa, la connessione terminerà in pochi ms</div><div>se invece questa macchina attua un DROP per ogni richiesta, il server</div><div>sotto attacco per rispondere proverà a mantenere la connessione aperta</div><div>per _decine di secondi_ (da moltiplicare per ogni pacchetto SYN che la</div><div>botnet che vi sta attaccando riesce a generare)</div><div><br></div><div><br></div><div>Fatemi sapere se c'è un qualche motivo per il quale ancora dissentite</div><div>o se ho commesso un qualche madornale errore nella mia analisi</div><div><br></div><div>-----------------------</div><div><br></div><div>Qui sotto potete vedere l'output del test di cui ho scritto prima:</div><div><br></div><div>dario@uberc50 ~> # with DROP</div><div>dario@uberc50 ~> sudo nmap --top-ports 4000 -sV 192.168.1.24</div><div><br></div><div>Starting Nmap 5.21 ( http://nmap.org ) at 2013-02-08 17:18 CET</div><div>Nmap scan report for 192.168.1.24</div><div>Host is up (0.0059s latency).</div><div>Not shown: 3998 filtered ports</div><div>PORT STATE SERVICE VERSION</div><div>80/tcp open http Cherokee httpd 1.2.101 (Debian)</div><div>443/tcp closed https</div><div>MAC Address: 00:1D:4F:FC:AF:FC (Apple Computer)</div><div>Service Info: OS: Linux</div><div><br></div><div>Service detection performed. Please report any incorrect results at</div><div>http://nmap.org/submit/ .</div><div>Nmap done: 1 IP address (1 host up) scanned in 18.96 seconds</div><div>dario@uberc50 ~> # now with REJECT on</div><div>dario@uberc50 ~> sudo nmap --top-ports 4000 -sV 192.168.1.24</div><div><br></div><div>Starting Nmap 5.21 ( http://nmap.org ) at 2013-02-08 17:13 CET</div><div>Nmap scan report for 192.168.1.24</div><div>Host is up (0.0056s latency).</div><div>Not shown: 3998 filtered ports</div><div>PORT STATE SERVICE VERSION</div><div>80/tcp open http Cherokee httpd 1.2.101 (Debian)</div><div>443/tcp closed https</div><div>MAC Address: 00:1D:4F:FC:AF:FC (Apple Computer)</div><div>Service Info: OS: Linux</div><div><br></div><div>Service detection performed. Please report any incorrect results at</div><div>http://nmap.org/submit/ .</div><div>Nmap done: 1 IP address (1 host up) scanned in 19.45 seconds</div><div><br></div><div>-----------------------</div><div><br></div><div>e questo invece è l'iptables della macchina target:</div><div><br></div><div>root@macbook ~# iptables -L -v</div><div>Chain INPUT (policy DROP 0 packets, 0 bytes)</div><div> pkts bytes target prot opt in out source</div><div>destination</div><div> 790 46769 ACCEPT tcp -- any any anywhere</div><div>anywhere tcp dpt:http</div><div> 324 17680 ACCEPT tcp -- any any anywhere</div><div>anywhere tcp dpt:https</div><div>10173 6912K ACCEPT all -- any any anywhere</div><div>anywhere ctstate RELATED,ESTABLISHED</div><div>10227 917K ACCEPT all -- lo any anywhere</div><div>anywhere</div><div> 532K 169M LOGGING all -- any any anywhere</div><div>anywhere</div><div><br></div><div>Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)</div><div> pkts bytes target prot opt in out source</div><div>destination</div><div><br></div><div>Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)</div><div> pkts bytes target prot opt in out source</div><div>destination</div><div><br></div><div>Chain LOGGING (1 references)</div><div> pkts bytes target prot opt in out source</div><div>destination</div><div> 683 168K LOG all -- any any anywhere</div><div>anywhere limit: avg 2/min burst 5 LOG level debug prefix</div><div>"IPTables Packet Dropped: "</div><div>root@macbook ~# iptables -A LOGGING -j REJECT</div><div>root@macbook ~# iptables -L -v</div><div>Chain INPUT (policy DROP 0 packets, 0 bytes)</div><div> pkts bytes target prot opt in out source</div><div>destination</div><div> 817 48143 ACCEPT tcp -- any any anywhere</div><div>anywhere tcp dpt:http</div><div> 352 18912 ACCEPT tcp -- any any anywhere</div><div>anywhere tcp dpt:https</div><div>11076 6978K ACCEPT all -- any any anywhere</div><div>anywhere ctstate RELATED,ESTABLISHED</div><div>11126 983K ACCEPT all -- lo any anywhere</div><div>anywhere</div><div> 556K 170M LOGGING all -- any any anywhere</div><div>anywhere</div><div><br></div><div>Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)</div><div> pkts bytes target prot opt in out source</div><div>destination</div><div><br></div><div>Chain OUTPUT (policy ACCEPT 1214 packets, 90322 bytes)</div><div> pkts bytes target prot opt in out source</div><div>destination</div><div><br></div><div>Chain LOGGING (1 references)</div><div> pkts bytes target prot opt in out source</div><div>destination</div><div> 711 170K LOG all -- any any anywhere</div><div>anywhere limit: avg 2/min burst 5 LOG level debug prefix</div><div>"IPTables Packet Dropped: "</div><div> 7992 352K REJECT all -- any any anywhere</div><div>anywhere reject-with icmp-port-unreachable</div><div><br></div><div>-- </div><div>Sito BgLUG: http://www.bglug.it</div><div>Mailing list: http://lists.linux.it/listinfo/bglug</div></div></div>
</blockquote>
<div>
<br>
</div>