[CONSEAL-Appendice] - Varie ed eventuali sull'uso del programma omonimo [KEYWORDS:conseal:firewall:regole:filtro:pacchetto:porta:protocollo] Max ringrazia i fantastici Buttha e Wiz, per aver scritto nei loro post pressoche' tutto cio' che e' riportato in questo file. Ancora, poiche' i post da cui e' stato messo insieme questo file sono abbastanza datati, e' possibile che allo stato attuale ci siano delle differenze con quanto qui riportato. Fermi restando i concetti di base, eventuali correzioni o aggiornamenti sono i benvenuti [ M.Baldinelli@agora.it ] INDICE: [CFW-01] Conseal mi chiede in continuazione se accettare un pacchetto. [CFW-02] Perche' e' meglio disattivare il learning mode? [CFW-03] Come blocco una connessione telnet da un certo IP? Con una regola apposita? [CFW-04] Come faccio a loggare i tentativi falliti? [CFW-05] Come blocco uno e un solo IP? [CFW-06] Come si aggiunge una regola? [CFW-07] Come faccio a bloccare i ping dall'esterno senza bloccare i miei? [CFW-08] E gli altri tipi di pacchetti ICMP ? Siamo sicuri che sia un bene bloccarli ? [CFW-09] Come permettere il traceroute. [CFW-10] Cosa sono i pacchetti diretti a 224.0.0.2? [CFW-11] A quali altri attacchi e' vulnerabile Conseal? [CFW-12] Come gestisco NetBIOS con Conseal? [CFW-13] Perche' Conseal dev'essere affiancato da @guard per una migliore protezione? [CFW-01] Conseal mi chiede in continuazione se accettare un pacchetto. Sicuramente stai lavorando in "learning mode", cioe' la modalita' in cui se il firewall "sente" una connessione per la quale non possiede una regola cioe' una connessione che non ha mai gestito ti chiede "la vuoi bloccare oppure la lascio passare ?". Tale modalita' di comportamento e' utile se non si una dimestichezza tale con i protocolli di rete da poter impostare manualmente le regole per il filtraggio dei pacchetti, e permette a Conseal di crearle da solo, chiedendo appunto all'utente cosa deve fare ogni volta che riceve dei dati per cui non esiste gia' una regola. Una volta trascorso un "tempo di autoapprendimento" sufficiente, pero', conviene disattivarla in modo che il programma continui a svolgere il suo lavoro nell'ombra, senza piu' interferire con le attivita' dell'utente. Nelle impostazioni del programma si attiva mettendo la spunta su "automatic rule learning". [CFW-02] Perche' e' meglio disattivare il learning mode? Perche' se ti arriva un mare di tentate connessioni su porte diverse rischi che il sistema si blocchi. In effetti questo e' un vero e proprio attacco di tipo DoS (Denial of Service - vedi il Glossario), che porta al crash del computer attaccato per esaurimento delle risorse. [CFW-03] Come blocco una connessione telnet da un certo IP? Con una regola apposita? Per default *tutto* e' bloccato, vale a dire che se non hai scritto delle regole, niente passa. Se non hai regole, e non sei in learning mode, non puoi comunicare, se invece sei in learning mode, allora il firewall ti chiede cosa fare. [CFW-04] Come faccio a loggare i tentativi falliti? Aggiungi una regola esplicita che blocchi il tipo di tentata connessione che vuoi loggare. Se invece sei in learning mode la logghi comunque. [CFW-05] Come blocco uno e un solo IP? Supponi di avere una regola che consenta connessioni a tutti gli IP remoti su certe porte tcp, ma di volerle negare a un certo IP. Allora lascia la regola che consente le connessioni a tutti gli IP, e ne aggiungi un'altra che blocca solo l'IP specifico a te sgradito. La seconda regola deve avere priorita' maggiore rispetto alla prima (questo, con Conseal, si traduce in un numero piu' piccolo di priorita': maggiore priorita' <-> valore numerico priorita' minore). [CFW-06] Come si aggiunge una regola? Schematicamente: add rule service = telnet /*** inserire il servizio che interessa ***/ on match = block direction = inbound A dire il vero, non serve che spefichi il servizio: basta che specifichi il protocollo tcp/ip; poi nella finestra degli indirizzi e delle porte remote address= IP che mi sta antipatico mask = 255.255.255.255 ports = da 0 a 65535 /*** o da 1024 a 5000 (temporary) ***/ local address = 127.0.0.1 mask= 255.255.255.255 ports= 23 [CFW-07] Come faccio a bloccare i ping dall'esterno senza bloccare i miei? Il ping funziona con due tipi di ICMP: il 0 e l'8. L'ICMP di tipo 0 e' echo reply: il computer risponde al ping; l'ICMP di tipo 8 e' echo request: il computer fa un ping. Per poter fare in modo che tu possa pingare gli altri ma che gli altri non pinghino te, servono due rule: la prima, con priorita' 200, che blocca tutti gli ICMP sia in inbound che in outbound (l'outbound serve affinche' il tuo computer non risponga ad un ping altrui). La rule e': per il protocollo ICMP, direzione inbound e outbound, blocca (priorita' 200), tutti i remote address (255.255.255.255 con mask 0.0.0.0) e tutti i tipi di icmp (0-255), e come local address il tuo (127.0.0.1 mask 255.255.255.255) e tutti i tipi ICMP. Puoi anche mettere come local address tutti gli indirizzi: 255.255.255.255 con mask 0.0.0.0: le rule di default di conseal fanno proprio cosi'. Anzi, fallo anche tu, cosi' blocchi strani broadcast o routing. Ora ti serve una rule che ti permette di pingare gli altri: devi permettere un tuo outbound icmp di tipo 8 (echo request), e un inbound ICMP di tipo 0 (echo reply). Questa rule deve avere priorita' maggiore della precedente, perche' deve passare al vaglio prima dell'altra. Se fosse applicata prima l'altra, allora tutti gli ICMP sarebbero bloccati. Quindi, daremo una priorita' 100 (che rappresenta una priorita' maggiore di 200) a questa rule: per il protocollo ICMP, permetti in e out (metti anche un bel block incoming fragments), con priorita' 100, verso tutti i remote address (255.255.255.255 mask 0.0.0.0) e per il solo tipo 0, mentre il local address e' il tuo (127.0.0.1 mask 255.255.255.255) per il solo tipo 8. Volendo, puoi permettere a te stesso di mandare tutti in outbound tutti i tipi di ICMP. [CFW-08] E gli altri tipi di pacchetti ICMP ? Siamo sicuri che sia un bene bloccarli ? se usi irc, e' meglio di si': ci sono simpatici personaggi che li sfruttano per sconnetterti dal server. [CFW-09] Come permettere il traceroute. Per il protocollo ICMP, direzione inbound, permettere (priorita' 100) tutti i remote address (255.255.255.255 con mask 0.0.0.0) e gli ICMP di tipo 11, e come local address il proprio (127.0.0.1 mask 255.255.255.255) e gli ICMP di tipo 11. [CFW-10] Cosa sono i pacchetti diretti a 224.0.0.2? Puo' capitare che il firewall blocchi un pacchetto ICMP tipo 10 destinato a 224.0.0.2; che cosa sono questi pacchetti? Probabilmente il tuo ISP ha il supporto per il multi-casting; li si puo' bloccare senza problemi. [CFW-11] A quali altri attacchi e' vulnerabile Conseal? Il "Firewall kill 2" del 'Meliksah nuke', che parrebbe essere una sorta di SYN flood (vedi Glossario) su tutte le porte. Quando il conseal e' colpito da quell'attacco, per un po' lo subisce senza far nulla, poi gli parte la malsana idea di tentare di collegarsi all'IP dell'attaccante, provando dalla porta 1 per finire alla 65535. Inutile dire che se ti attacca qualcuno con una banda maggiore della tua ti butta giu' come niente, altrimenti ti satura la banda comunque. Attivare/disattivare il learning mode non cambia nulla: nel caso di questo attacco l'unica e' chiudere il Conseal (sperando che non caschi la linea), aspettare che l'attaccante si stufi e poi riaprirlo. Insomma... non e' una bella cosa per un firewall :) Nel caso di questo attacco, tutti i pacchetti in uscita sono diretti alla porta 1024 di chi ti attacca (con una regola che blocca i pacchetti in uscita verso la 1024 si puo' neutralizzare l'attacco... ma anche bloccare cose utili). I motivi per cui dico che e' un bug del Conseal sono: 1. senza Conseal non succede nulla: ti ritrovi un po' la banda in entrata occupata dal flood, ma in uscita non parte nulla 2. c'e' scritto nei doc del Meliksah :) (##) "Meliksah Nuke use OOB Bug and ConSeal Firewall Bugs. A lot of nuke programs use OOB Bug but Conseal Firewall Bug was only used by Meliksah Nuke v2.5 [...] * If user use another firewall, maybe this program don't work. * If user don't use firewall, this program don't work." Trad.: "Il nuke Meliksah utilizza il bug OOB e quello del firewall Conseal. Molti programmi nuke usano il bug OOB, ma quello del Conseal e' stato usato solo da Meliksah Nuke v. 2.5. [...] * Se l'utente usa un altro firewall, forse questo programma non funzionera'. * Se l'utente non usa firewall, questo programma non funzionera'." [##] Nota: il bug OOB era un vecchissimo bug che affliggeva le prime versioni di Windows 95. E' ormai stato corretto da tempo, e la sua citazione in queste note rivela l'anzianita' di alcune parti delle stesse. [CFW-12] Come gestisco NetBIOS con Conseal? Se ConSeal Firewall ti ha segnalato "outgoing data" (dati in uscita) via NetBIOS, significa che hai il Client per le Reti installato con relativo supporto per NetBT (NetBIOS su TCP/IP). Quest'ultimo apre le porte UDP/TCP 137 e 138 (anche la 139, se si stabilisce una comunicazione), che fanno parte delle "well known ports": la 137 e' dedicata al NetBIOS Name Service, la 138 al NetBIOS Datagram Service e la 139 al NetBIOS Session Service. In una delle "rules" di ConSeal viene specificato che certi protocolli notificano la presenza del client connesso sulla rete inviando dei pacchetti (UDP e ICMP) su indirizzi broadcast (*.*.*.0 o *.*.*.255), questo comportamento e' utile in una rete locale, ma puo' risultare pericoloso su Internet, oltre che inutile. Grazie al filtro di un Virtual Device Driver dinamico (FW13.VXD) che interagisce con VxD del NDIS (Network Driver Interface Specification), ConSeal e' in grado di intercettare questa operazione, filtrata da una "rule" impostata per default, e quindi la blocca impedendo al tuo PC (o, meglio, al NetBT) di notificare la sua presenza sulla rete. *** (C) Paolo Monti *** [CFW-13] Perche' Conseal dev'essere affiancato da @guard per una migliore protezione? *** N.B. @Guard non esiste piu' con questo nome, essendo stato acquisito dalla Norton che l'ha incluso nel pacchetto NIS. *** Il limite di Conseal e' quello di essere un firewall packet filtering, quindi il non poter controllare in maniera rigorosa la singola applicazione. Conseal, quindi, permette di rendere una rule attiva quando una applicazione e' in esecuzione, ma non permette di specificare che quella rule deve valere *solo* per quella applicazione, cioe' che i pacchetti che passano grazie a quella rule devono provenire da o andare verso quella specifica applicazione. Per esempio, la classica rule per icq (a parte quelle per il server) deve concedere inbound e outbound verso tutti gli IP quando la applicazione icq e' attiva. Il guaio e' che quando l'applicazione icq.exe e' attiva, allora la rule vale, ma vale indiscriminatamente per tutti le applicazioni attive: la conseguenza e' che il firewall viene praticamente bypassato. Si puo' allora scaricare posta senza rule che lo permettono, navigare, fare qualunque cosa sul tcp. Con @guard, invece, che lavora sia a livello di pacchetti che a livello di applicazione, si crea la rule che permette in e out per l'applicazione icq, ma cosi' la *solo* icq puo' comunicare con tutti gli ip, mentre le altre applicazioni non sono toccate da questa rule (per altre applicazioni, si puo' anche pensare ad una backdoor ;) ). Cosi', per es, si puo' fare un rule che permette a telnet in e out verso qualsiasi IP, ma il solo fatto di avere telnet in esecuzione non implica che da quel momento in poi qualsiasi applicazione possa fare in e out verso qualsiasi IP, cosa che succederebbe con Conseal (peccato solo che non gestisca i pacchetti ICMP...). Ecco allora che usando i due firewall insieme, si ottiene un controllo totale e molto piu' selettivo. Per esempio, con Conseal si puo' controllare qualche nuke, i pacchetti icmp e bloccare i protocolli sconosciuti; tutti gli altri pacchetti tcp/ip e udp/ip si lasciano passare e saranno processati da @guard (che lavora ad un livello superiore). Saranno quindi le rule di @guard a dire l'ultima parola: agent sta comunicando con il mio news server? Se si, allora permetti la comunicazione. C'e' un pacchetto che arriva da un qualsiasi IP ed e' diretto a icq? Allora fallo passare. ecc... ecc... *** (C) Buttha ***