Newsgroup: it.comp.sicurezza.varie
Titolo: FIREWALL - Discutiamo insieme su cosa filtrare ??

Ciao All...
Vogliamo discutere un po' insieme su cosa filtrare e su cosa non
filtrare su un Firewall??
Da cosa iniziamo?? Lasciamo perdere le classiche porte 137, 138 e 139 di
Winzozz...
Parliamo piuttosto di nuke IRC & C.
Idee, consigli, suggerimenti??
Bye
(CriCri)

 filtrare su un Firewall??
Io inizierei al contrario.... "cosa NON filtrare ?"
per quanto mi riguarda la mia procedura e' la seguente:
1) IP-options: tutti i pacchetti con IP options e' meglio perderli
   che trovarli, IP-options = source routing e normalmente 
   source-routing == IP spoofing fatto ad arte per aggirare
   i router piu' furbi (quelli configurati bene che non lasciano
   passare i pacchetti nella direzione sbagliata...).
   A meno che non ci sia un motivo specifico per lasciarlo fare, 
   restringendo ai soli pacchetti che hanno ben determinate 
   caratteristiche.. fuori !
2) ICMP: IP e TCP *possono* vivere senza ICMP, personalmente il mio
   server un pacchetto ICMP non l'ha mai visto.... certo quando
   qualcosa va male e' tutto un po' piu' lento perche' invece
   che dagli errori ICMP le connessioni vengono chiuse da dei 
   timeout.. ma e' meglio che chiuderle per degli errori che non
   esistono....
3) UDP: cosa ? dove ? quali servizi abbiamo sul server che girano 
   su UDP ? Lasciamo entrare solo i pacchetti che sono diretti a 
   servizi che davvero la macchina offre, al piu' lasciamo entrare
   i pacchetti che sono in risposta a un pacchetto uscito per nostra
   iniziativa. La funzione "keep state" di IP-Filter (NetBSD) e'
   un gioiello a tal proposito. Per cio' che "lasciamo passare"
   chiediamoci sempre chi/perche' puo' usare quel "servizio", un
   server IRC risponde sulla porta 7007 di UDP per il protocollo 
   UPING ma.... *solo* ai server con cui ha potenzialmente un link,
   un local nameserver cache deve rispondere alle richieste del DNS
   ma *solo* dalla LAN, eccetera...
4) TCP: Leggi tutto quanto sopra detto per UDP, ovviamente lasciamo 
   entrare verso le porte dei servizi che abbiamo attivi (ma se
   un servizio serve solo che sia aperto per una certa macchina
   o un insieme di macchine... restringiamolo a quello, non lasceremo
   mica Telnet aperto a tutti ?), usiamo sempre il "save state" per 
   lasciare passare le connessioni aperte da noi, e fuori il resto.
5) RAW IP: E tutti i protocolli su IP che non usiamo o non 
   conosciamo nemmeno ? Semplice: resta fuori !
La logica comunque per me resta quella: non "vietare cio' che
e' pericoloso" ma solo e sempre "autorizzare SOLO cio' che 
usiamo, lasciando fuori *tutto* il resto"
Un'altra cosa sacrosanta e' avere come router/firewall una 
macchina con un OS robusto all'"esterno" della rete (OS robusto
non e' certo Windows... ma anche su linux ho delle perplessita',
mi fido di piu' di NetBSD...) che faccia la ricostruzione dei
pacchetti frammentati e passi solo pacchetti "puliti" alla rete.
L'IP fragmentation e' la base di lavoro di gran parte dei nukes
di penultima generazione (l'ultima generazione lavora sugli indirizzi
broadcast, ma per quelli c'e' poco da fare... ci vuole un po' di
educazione globale della rete perche' gli altri la smettano di fare
da megafono ai puffetti vari...lo so, questa e' in codice ;)
Byez,
-- 
Andrea

   esistono....
Tempo fa ho notato che lo faceva anche Flashnet; all'improvviso non
funzionava ne' ping ne' traceroute al di la' del confine
Interbusiness-Flashnet.
Pero' era un po' seccante non poter verificare dove si trovava il
problema quando non riuscivo a raggiungere un host di Flashnet.
Ora non lo fanno piu', chissa perche'?


no ip directed-broadcast ?

> Io inizierei al contrario.... "cosa NON filtrare ?"
Uhh.. come sei pessimista...
Pero'... adesso che ci penso ricordo una cosina...
"Il pessimista, e' un ottimista che conosce il mondo..."

Per fare una similitudine con i cartoni animati dei Puffi....
"Se conosci il Grande Puffo (Interbusiness) lo eviti"..
Bye
(CriCri)

nu...@tin.it
 wrote:
 >   che trovarli, IP-options = source routing e normalmente 
 >   source-routing == IP spoofing fatto ad arte per aggirare
Ma ci sono ancora sistemi operativi che di default onorano il source routing?
Linux non lo fa, e immagino neppure i *BSD.
 >2) ICMP: IP e TCP *possono* vivere senza ICMP, personalmente il mio
Ahem... Se seghi *tutto* ICMP allora non funziona piu` il path MTU
discovery. Bloccare indiscriminatamente tutto ICMP e` una cosa da non fare
mai, mai, mai (cfr gli archivi della mailing list nanog dalle parti di
www.nanog.org
 o 
www.merit.edu
). Se hai solo client win95 il problema non
c'e` ancora, visto che l'algoritmo compare solo in win98.
Se hai paura dei flood puoi bloccare gli echo-reply, ma oltre mi sembra
proprio eccessivo.
 >3) UDP: cosa ? dove ? quali servizi abbiamo sul server che girano 
Gli unici protocolli che ha senso lasciar passare mi sembra che siano
talk e fsp. Se gli utenti non li usano si possono bloccare anche questi.
 >   o un insieme di macchine... restringiamolo a quello, non lasceremo
 >   mica Telnet aperto a tutti ?), usiamo sempre il "save state" per 
Telnet non lo lasciamo aperto proprio a nessuno, se qualcuno ne ha
bisogno c'e` ssh...
 >La logica comunque per me resta quella: non "vietare cio' che
 >e' pericoloso" ma solo e sempre "autorizzare SOLO cio' che 
 >usiamo, lasciando fuori *tutto* il resto"
Tenendo comunque presente che ormai una enorme quantita` di roba
pericolosa (macrovirus, activex, html "interessante") entra via http...
 >non e' certo Windows... ma anche su linux ho delle perplessita',
A questo rigurdo non ho mai sentito controindicazioni, per quanto ne so
la deframmentazione forzata funziona.
 >broadcast, ma per quelli c'e' poco da fare... ci vuole un po' di
 >educazione globale della rete perche' gli altri la smettano di fare
 >da megafono ai puffetti vari...lo so, questa e' in codice ;)
Hai visto la blacklist di Karl Denninger? Trovi anche quella nell'archivio
di nanog, sospetto che tu abbia un po' di voci da contribuire. :-)
-- 
ciao, | [Per rispondere togli "toglimi" dal mio indirizzo.]
Marco | * The Internet is full. Go away.  -- Joel Furr *

 no ip directed-broadcast ?
Si ma....
farlo tu sulla tua subnet e' *sacrosanto*, *dovuto* eccetera
eccetera, non farlo e' quasi criminale.
Il problema e' che per evitare il problema in questione *tutte*
le subnet dovrebbero farlo... il dramma e' proprio quello, chi
non lo fa diventa un "amplificatore di puffi" [copyright by Marco
D'Itri se ricordo bene] per attaccare gli altri.
E' un discorso simile, dal punto di vista gestionale, al
problema spammer/forwarding: finche' non si riesce a convincere
*tutti* a non fare da relay a cio' che non ha senso "forwardare"
ci sara' sempre il modo di spammare; finche' non si convince
*tutti* a filtrare il traffico broadcast ai border-router, ci
sara' sempre il modo di attaccare qualcuno con Smurf.
Per gli spammer sta rivelandosi efficace la "Realtime BlackList"
di Paul Vixie.... inventare qualcosa del genere per le subnet che
hanno gli indirizzi broadcast aperti ? Un feed BGP che blocca
a livello IP i pacchetti di costoro verso mezzo mondo ?
Beh certo... per un po' gente come Interbusiness diventerebbe un
"sistema autonomo", tanto autonomo che parla solo con se stesso,
praticamente un "sistema autarchico" [o autoerotico ?] :-), ma
poi sbattendo violentemente la faccia contro un muro di.. "silenzio"
capiscono :)
Ciao,
-- 
Andrea

 "Se conosci il Grande Puffo (Interbusiness) lo eviti"..
RUTL
[Rolling Under the Table Laughing], creato or ora ;)
Ciao,
-- 
Andrea

nu...@tin.it
 wrote:
 >222.222.222.222 verso 212.216.224.119". Un protocollo molto
 >simile come natura a BGP se vogliamo ma piu' flessibile.... 
 >ci sarebbe da pensarci.... Idee ? Proposte ?
Usare un terminal server intelligente (cioe` un PC con linux o un *BSD e
una multiseriale) e farci girare un qualcosa che individua i flood (questo
AFAIK dovresti poterlo riciclare da ircd :-) ). Il qualcosa comunica con
un protocollo semplice ("BLOCCA IP/bit IP/bit perquantisecondi") ma
autenticato (Net::SSLeay?) con un demone su un server che si occupa di
rigenerare il file di configurazione per il ruoter o per il firewall e
di farne l'upload.
La parte piu` difficile e` il terminal server, visto che AFAIK K56 e cose
simili possono essere gestite solo con uno dedicato.
(Veramente la parte piu` difficile e` convincere chi ti vende la banda a
collaborare...)
L'alternativa e` creare un gruppo di lavoro di IETF, discuterne per un
po' per migliorare l'idea (questi due punti sono opzionali), far uscire
un RFC e quindi pregare che i produttori di terminal server implementino
l'idea.


nu...@tin.it
 wrote:
 >ci sara' sempre il modo di spammare; finche' non si convince
 >*tutti* a filtrare il traffico broadcast ai border-router, ci
 >sara' sempre il modo di attaccare qualcuno con Smurf.
La blacklist c'e`, basta usarla.
 >hanno gli indirizzi broadcast aperti ? Un feed BGP che blocca
 >a livello IP i pacchetti di costoro verso mezzo mondo ?
Non funge, l'annuncio di un route puo` bloccare solo il traffico in
uscita. Bisogna necessariamente fare gli aggiornamenti a mano (cioe`
perdere dieci minuti di tempo a scrivere qualche script che crei la
configurazione del router a partire da un template e dati esterni).
 >Beh certo... per un po' gente come Interbusiness diventerebbe un
 >"sistema autonomo", tanto autonomo che parla solo con se stesso,
Le reti di alcuni clienti di IBS ci sono gia` dentro, basta fare un piccolo
script e mandargli anche le altre...


 l'idea.
Infatti.
Il problema e' questo: ipotizziamo che io implementi la "cosa" a casa
mia sul mio computerino, poi convinco un provider a implementarla
sui suoi AS (problematico, se sono delle machine dedicate), poi a
implementarlo sui suoi border routers... (il tutto gia' ai limiti
dell'impossibile).
Dopo apro una shell sulla macchinetta che gestisco in inghilterra
(per capirci sta in LAN con 
sunsite.org.uk
 ... 34 MBit secca sul
bakcbone universitario inglese....) e scrivo "sudo ping -f 
a-ba1-1.tin.it
",
invece che andare giu' il mio modem va giu' il POP di Bari, seguito da
TIN, seguito da IBS al completo....
Se invece si potesse implementare la cosa a livello di _standard_
sarebbe piu' facile, col tempo, tirarsi dietro i produttori di routers,
di AS, e a seguitre i provider e i backbones... piu' la cosa si
diffonde e piu' "a monte" vengono bloccati i pacchetti.
Un gruppo di lavoro IETF dici eh ? A parte che IETF mi ha sempre 
puzzato di longa manu della M$ (ci sarebbe molto da dire in proposito...)
per me ci starei anche.... un'altra ventina di volontari ?
Ciao,
-- 
Andrea
[Mi e' morto il server IRC... neppure un hacker puo' niente
contro un hard disk che inizia a emettere fumo, ci si risente
quando ho finito di resuscitarlo.... :-\]

 di nanog, sospetto che tu abbia un po' di voci da contribuire. :-)
Questo lo ignoro ! (o meglio, lo ignoravo finora....),
Quanti GB hanno per memorizzare la blacklist che ho messo insieme in
soli 20 giorni di funzionamento del server IRC ? :-)
Ciao,
-- 
Andrea

nu...@tin.it
 wrote:
 >Mi preoccupano i classici ICMP ERROR (HOST UNREACH, PROTOCOL UNREACH,
 >e chi piu' ne ha piu' ne metta) che vanno tanto bene (spoffando un IP
Ok, ma ora come ora (=con gli stack TCP/IP moderni che generano sequence
number non prevedibili) quanto e` facile riuscire a fare danni a TCP?
 >che sono e' meglio che le chiuda. Ovviamente bisogna lasciare aperto 
 >DNS :)
Mica tanto ovvio. Un name server di caching lo si tiene comunque, e a
quel punto la porta si apre solo per quell'host.
 >Bonk e' nato per uccidere Linux....
Chi non e` mai stato vulnerabile a qualcosa? :-)
L'importante e` che al massimo entro il giorno dopo sia pronto il fix.
 >Questo lo ignoro ! (o meglio, lo ignoravo finora....),
Mi raccomando, contribuisci...
