Application layer con Iptables

[Dânêl]

Ciao a tutti,
sono da circa un mese passato a debian e volevo cominciare ad occuparmi seriamente della sicurezza. Diciamo che non ho particolari necessità ma "esagerare" anche se per un pc domestico è un buon modo per imparare.
Su windows ero abituati a firewall come Jetico e nell'ultimo periodo Comodo, volendo piuttosto avanzati e con la possbilità di impostare regole a livello applicativi.

È possibile fare una cosa del genere con iptables? Cercando su google non ho trovato molto a parte qualche richiesta senza risposta.
Possibile che cosi potente, Iptables non abbia questa capacità? Sarebbe utile soprattutto se è necessario aprire specifiche porte per specifiche applicazioni (vedi p2p o particolari servizi).
Dato che per il momento devo prendere ancora confidenza con Debian e Iptables (vuol dire che ho pacchi di guide e manuali da leggere ) utilizzo fwbuilder per la gestione...se eventualmente può essere d'aiuto.

Grazie per qualsiasi intervento

[sasa83]

con guarddog puoi settare tutto quello ke vuoi tramite interfaccia grafica e senza impazzire...

[Dânêl]

Ciao sasa83,
grazie della risposta ma guarddog non è la soluzione adeguata perchè innanzitutto è per kde e io invece uso gnome...
Ad ogni modo lo avevo provato ma non mi aveva soddisfatto più di tanto.
Oltretutto non permette un controllo a livello applicativo ma semplicemente uno sblocco dei servizi (alias apertura porte ma senza alcun filtraggio sulle applicazioni che possono utilizzarle). Non sarebbe tanto diverso dall'aprire le porte necessarie tramite i comandi da terminale di iptables...e poi se sono passato a linux e soprattutto per imparare evitando per quanto possibile gui utilissime e rapide ma che "nascondono" ciò che si dovrebbe fare e sapere. Da questo punto di vista fwbuilder è leggermente diverso....e comunque non appena imparerò per bene l'utilizzo di iptables lo lascerò.

Grazie comunque...

[Red`XIII]

Ciao,
se intendi un filtraggio applicativo alla ZoneAlarm credo che per Linux non siano diffusi firewall che mirino a filtrare determinati programmi rispetto ad altri (a parità di impostazioni tcp). Ad es., in Windows, volendo, posso consentire ad un client ftp di uscire sulla porta 21, e contemporaneamente vietarlo ad un altro client ftp.
Ecco, se intendi *questo* tipo di filtraggio, secondo me non c'è tanta roba in giro.
Diversamente, se intendi un filtraggio a livello di protocollo applicativo, esiste un modulo per iptables (in realtà una patch per il kernel + patch per l'eseguibile /sbin/iptables) che ti consente di poter definire delle regole che filtrino alcuni tra i protocolli più famosi (ad es msn, gnutella, edonkey, etc.).
Ti posso garantire che funziona abbastanza bene (ci ho messo le mani per un progetto d'esame consegnato l'altro ieri ).
Tieni presente cmq che per questo tipo di filtraggio è consigliato il traffic shaping più che il blocking delle connessioni, perchè purtroppo si può sempre in qualche modo aggirare i filtri.
Trovi tutto qui http://l7-filter.sourceforge.net/

Considera poi che in linux gli applicativi tendono ad essere molto meno invasivi rispetto a quelli windows: difficilmente ti ritroverai un editor di testi che cerca di accedere ad internet, se non per fare il checking degli aggiornamenti
Di conseguenza, monitorare accuratamente le connessioni in uscita su base applicativa non è così fondamentale.


Ciao!

[Dânêl]

Bhe si più o meno intendevo un filtraggio "alla zone alarm", certo non per controllare che il mio editor di testo si connetta o meno ad internet ma per controllare le connessioni in entrata soprattutto nel caso in cui sia "obbligato" in particolari situazioni a mantenere delle porte aperte.
Faccio un esempio:

Emule necessita di una porta TCP e UDP aperta per le connessioni in entrata.
Ora perchè tenerle aperte sempre anche quando non servono o farle utilizzare per connessioni in entrata non desiderate verso altri programmi?

Non so se ora sono riuscito ad essere più chiaro...

Comunque forse ottengo lo stesso risultato con un filtraggio a livello di protocollo...correggetemi se sbaglio, ma se quella patch è in grado di identificare i protocolli allora è in grado di "filtrare" dalle porte aperte solo i protocolli da me desiderati.

Es.
Le porte aperte per emule non potrebbero mai essere usate da bittorrent essendo protocolli diversi.

è cosi o sono in errore?
Ultima domanda e poi la smetto (lo giuro ).
E se qualche "anima pia" mascherasse dei pacchetti malevoli con il protocolo di amule, anche se questo fosse chiuso, verrebbe filtrato o passerebbe indenne?

[W.S.]

Per l'esempio hai ragione

Se controlli il protocollo e i pacchetti lo rispettano il firewall lo lascia passare.

Questo e altri problemi li puoi aggirare controllando anche il processo che prende in carico la connessione, prova a dare un occhio al match owner anche se vale solo per OUTPUT torna comodo.

[vampirodolce1]

Originariamente inviato da W.S.

Per l'esempio hai ragione

Se controlli il protocollo e i pacchetti lo rispettano il firewall lo lascia passare.

Questo e altri problemi li puoi aggirare controllando anche il processo che prende in carico la connessione, prova a dare un occhio al match owner anche se vale solo per OUTPUT torna comodo.

Per quanto riguarda --pid-owner, --sid-owner, --cmd-owner, una nota alla pagina man di iptables dice:
pid, sid and command matching are broken on SMP. Come mai nessuno si e' mai occupato di sistemare questo problema? --cmd-owner (matches if the packet was created by a process with the given command name) e' l'equivalente del classico 'personal firewall' di Windows.

[W.S.]

Vero, da tempo (in effetti da più di un anno ) mi riprometto di verificarne il comportamento/problemi su SMP ma non l'ho ancora fatto, non so a che punto siano..
Qualche esperienza personale? Funziona?

[vampirodolce1]

Su debian stable (iptables v1.3.6) non funziona, ossia restituisce un errore.

[Red`XIII]

Originariamente inviato da Dânêl

Faccio un esempio:

Emule necessita di una porta TCP e UDP aperta per le connessioni in entrata.
Ora perchè tenerle aperte sempre anche quando non servono o farle utilizzare per connessioni in entrata non desiderate verso altri programmi?

A mio avviso potresti lasciarle anche sempre aperte sul firewall, dal momento che per esporre una vulnerabilità deve esserci un processo in ascolto su quelle porte. Se emule è chiuso, nessun problema. Che qualche altro processo vi si metta in listening è possibile, però cmq controllabile.
Un'alternativa è quella di utilizzare le funzionalità UPnP delle ultime versioni di emule per consentire l'apertura dinamica delle porte necessarie sul router.

Comunque forse ottengo lo stesso risultato con un filtraggio a livello di protocollo...correggetemi se sbaglio, ma se quella patch è in grado di identificare i protocolli allora è in grado di "filtrare" dalle porte aperte solo i protocolli da me desiderati.

Certamente. Nel progetto che ho presentato coesistevano sulla stessa macchina un ftp server e un web server, entrambi in ascolto sulla porta 80 (con conseguenti conflitti di binding, ma lasciamo perdere ). Il firewall lasciava passare connessioni solo su questa porta (e sulla porta per i dati dell'ftp passivo), e con il matching a layer 7 bloccavo le connessioni ftp, mentre le http continuavano a funzionare. Ovviamente il tutto era una proof of concept del filtraggio layer 7, nulla più.
Considera ad ogni modo che il filtraggio layer 7 si basa sul confronto di tutti i pacchetti in transito con specifici pattern, disponibili per un numero elevato ma finito di protocolli: in sostanza non puoi decidere arbitrariamente quale protocollo fargli filtrare, a meno che non esista un pattern predefinito per esso oppure che tu non individui un'espressione regolare che lo caratterizzi.
Resta però sempre e comunque un tipo di filtraggio mooooooooooolto pesante, computazionalmente parlando.

Es.
Le porte aperte per emule non potrebbero mai essere usate da bittorrent essendo protocolli diversi.

è cosi o sono in errore?

Questo è errato, una porta non caratterizza in alcun modo il protocollo applicativo che vi transita (vedi sopra, ftp e http sulla 80), si tratta solo di convenzioni (peraltro ristrette alle porte <=1024). Pertanto del traffico bittorrent potrebbe essere tranquillamente veicolato su una porta usata da emule.

Tieni sempre presente questa regola: una connessione tcp è caratterizzata (e univocamente identificata) da 4 aspetti:
- ip sorgente
- ip destinatario
- porta sorgente
- porta destinataria

E se qualche "anima pia" mascherasse dei pacchetti malevoli con il protocolo di amule, anche se questo fosse chiuso, verrebbe filtrato o passerebbe indenne?

Si, passerebbe indenne. Ad ogni modo, per far danno, dovrebbe esserci una vulnerabilità da exploitare, altrimenti quei pacchetti finirebbero nel vuoto

byebye!

[Dânêl]

ok Grazie mille delle risposte.

Originariamente inviato da Red`XIII

Questo è errato, una porta non caratterizza in alcun modo il protocollo applicativo che vi transita (vedi sopra, ftp e http sulla 80), si tratta solo di convenzioni (peraltro ristrette alle porte <=1024). Pertanto del traffico bittorrent potrebbe essere tranquillamente veicolato su una porta usata da emule.

Tieni sempre presente questa regola: una connessione tcp è caratterizzata (e univocamente identificata) da 4 aspetti:
- ip sorgente
- ip destinatario
- porta sorgente
- porta destinataria

ops scusa non sono stato chiaro e mi hai frainteso. Intendevo dire che se sulle porte utilizzate da amule impostassi un filtraggio consentendo solo al suo protocollo di passare anche se bittorrent usasse le stesse non funzionerebbe

Originariamente inviato da Red`XIII

Si, passerebbe indenne. Ad ogni modo, per far danno, dovrebbe esserci una vulnerabilità da exploitare, altrimenti quei pacchetti finirebbero nel vuoto

ok grazie è proprio quello che volevo sapere. Non esiste dunque al momento la possibiità di una verifica anche a quale applicazione siano destinati i pacchetti ( a parte cmd-owner ecc...ho trovato qualcosa cercandolo)...va be poco male ci ho provato

Sapete come è.... una volta imparata la sicurezza con Windows vecchie "abitudini" rimangono...e poi ora che con linux posso davvero fare tutto (o quasi) ne voglio approfittare

[Red`XIII]

Originariamente inviato da Dânêl

ok Grazie mille delle risposte.

ops scusa non sono stato chiaro e mi hai frainteso. Intendevo dire che se sulle porte utilizzate da amule impostassi un filtraggio consentendo solo al suo protocollo di passare anche se bittorrent usasse le stesse non funzionerebbe

Si si, questo è corretto


Ad ogni modo buon divertimento!

[psimem]

Scusatemi ma vorrei anch'io chiarirmi un attimo le idee:
quindi per poter bucare un sistema sono necessari 3 fattori indispensabili, che sono: 1) porta aperta 2) processo in ascolto su tale porta 3) vulnerabilita' di tale processo
Corretto? O sto vaneggiando?

[W.S.]

Originariamente inviato da psimem

Scusatemi ma vorrei anch'io chiarirmi un attimo le idee:
quindi per poter bucare un sistema sono necessari 3 fattori indispensabili, che sono: 1) porta aperta 2) processo in ascolto su tale porta 3) vulnerabilita' di tale processo
Corretto? O sto vaneggiando?

Corretto, anche se tra i processi in ascolto rientra anche tutto lo stack di rete del sistema operativo che si trova a gestire la connessione in entrata anche senza processi utente in ascolto. Quindi se quella parte di kernel è vulnerabile può non servire un processo in ascolto.

[psimem]

Grazie per la risposta;
ancora una cosa: se chiudo tutte le porte tramite iptables le vulnerabilita' dello stack di rete del sistema operativo sono ancora esposte? In altre parole: lo stack di rete sta "davanti" al firewall o "dietro"? (scusate i termini poco tecnici )

[W.S.]

La presenza di una vulnerabilità li è estremamente remota comunque, iptables funziona "agganciandosi" al percorso che i pacchetti fanno nel kernel (detta brutale). Se chiudi una porta tramite iptables il pacchetto percorre meno strada ma ne percorre comunque un pochino, se la vulnerabilità si trova in quel breve percorso è comunque sfruttabile.
Stiamo comunque parlando di una cosa teorica, è ben difficile che esista. Già è improbabile che ci sia nel resto del percorso.

[psimem]

Capito grazie