[ Home | Liste | F.A.Q. | Risorse | Cerca... ]


[ Data: precedente | successivo | indice ] [ Argomento: precedente | successivo | indice ]


Archivio: Novembre 2005 ml@sikurezza.org
Soggetto: Re: [ml] Problema con Iptables
Mittente: Fabio Panigatti
Data: Wed, 23 Nov 2005 11:54:41 +0100 (CET)
Osservazioni generali. Se i problemi che sollevo possono o meno
rendere piu' o meno Sicure(TM) le tue macchine puoi saperlo tu,
e basta. Sicuramente questo ruleset e' un po'... pasticciato, e
non pretendo d'aver esaurito l'elenco di quelle che mi sembrano
delle "magagne": ho dato solo un'occhiata di massima, visto che
dovra' essere riscritto :-P (IMHO, eh?).

Inoltre mi pare che questo ruleset tenti di fare anche altro in
aggiunta a quelle che hai citato come necessita' (<< Con questo
vorrei che... >>). Se non sei chiaro in quello che ti serve, e'
difficile fare delle osservazioni, anche generiche.

> echo "1" > /proc/sys/net/ipv4/ip_dynaddr

Hai un ip pubblico dinamico? Non mi sembra, visto che usi SNAT.

> # LOGGIN GENERAL
> iptables -I INPUT -p icmp --icmp-type echo-request -j ULOG
> --ulog-nlgroup 1 --ulog-prefix "ICMP_DROP: "
> iptables -I INPUT -m state --state INVALID -j ULOG
> --ulog-nlgroup 1 --ulog-prefix "INVALID: "
> iptables -I INPUT -p tcp ! --syn -m state --state NEW -j ULOG
> --ulog-nlgroup 1 --ulog-prefix "NEW_INCORRECT: "

Le regole di logging legate a traffico scartato andrebbero un po'
piu' vicine a dove viene scartato il traffico cui si riferiscono,
per semplicita' di consultazione e di manutenzione dello script.

Specie quando il traffico dici che lo scarti ma poi... dimentichi
di scartarlo davvero ;-)

> iptables -A INPUT -i $INET -m state --state NEW -p tcp -j ACCEPT

Con questa accetti tutte le connessioni tcp sull'interfaccia eth1
pubblica. E' quello che vuoi? Scommetterei di no :-)

> iptables -A INPUT -i $INET -p tcp --dport ssh -j ULOG
> --ulog-nlgroup 1 --ulog-prefix="SSH: "

Perche' mai??? Soprattutto considerando che non verra' mai usata.

> iptables -A INPUT          -p tcp --dport ssh -j ACCEPT

Le connessioni ssh le hai gia' accettate con le regole precedenti.

> iptables -A INPUT -i $LAN  -p tcp --sport domain -j ACCEPT

Questa mi risulta totalmente incomprensibile (neanche la sfera di
cristallo mi e' d'aiuto).

> iptables -A INPUT          -p icmp -j ACCEPT

Accetti anche gli echo request che, pero', verranno loggati come
scartati ("ICMP_DROP") per le regole di logging messe in cima.

> iptables -A INPUT          -p tcp --dport 80 -j ACCEPT
> iptables -A INPUT          -p tcp --dport 81 -j ACCEPT
> iptables -A INPUT -i $INET -p tcp --dport 9898 -j ULOG
> --ulog-nlgroup 1 --ulog-prefix="WEBMIN: "
> iptables -A INPUT          -p tcp --dport 9898 -j ACCEPT

Tutte queste sopra non verranno mai raggiunte. E' tutto traffico
gia' accettato in precedenza.

In ogni caso, non capisco bene perche' vorresti loggare anche il
traffico che accetti. Non che sia sbagliato in _assoluto_, ma mi
chiedo se non ti basterebbero le informazioni che avresti dentro
i log di sshd o di webmin.

> iptables -A INPUT          -p tcp -m tcp --sport 1024:65535
> --dport 20:21 -m state --state NEW -j ACCEPT

1) le sessioni ftp DATA sono gestite come RELATED e non necessitano
   di ulteriori "perforazioni" nel tuo firewall;
2) in ogni caso, la porta 20/tcp e' una porta _sorgente_, e non di
   destinazione.

> iptables -A INPUT -i $INET -p tcp --dport 1220 -j ULOG
> --ulog-nlgroup 1 --ulog-prefix="DARWIN: "
> iptables -A INPUT          -p tcp --dport 1220 -j ACCEPT
> iptables -A INPUT          -p tcp --dport 554 -j ACCEPT

Non verranno mai raggiunte.

> iptables -A INPUT          -p udp --dport 1024:65533 -j ACCEPT

Perche' mai???

> iptables -A INPUT          -p tcp --dport 143 -j ACCEPT

Questa non verrebbe mai raggiunta per due motivi e, in ogni caso,
non capisco a che cosa pensavi che potesse servirti, visto che il
server imap e' in lan (hai visto bene come funziona netfilter, in
confronto al vecchio ipchains?).

> iptables -A FORWARD -i $LAN -m state --state NEW -j ACCEPT

Pur non conoscendo il contesto, questa mi sembra un po' azzardata
per due motivi, primo tra tutti che non stai SNATando il traffico
originato dalla tua lan, inviando, tra l'altro, parecchia monezza
al resto del mondo. L'altro e' che fare passare tutto tutto puo',
in molti casi, non essere desiderabile (vedi porte tipo 139/tcp o
445/tcp o 25/tcp o 137/udp o...). Vedi tu, ma almeno fai lo SNAT.

> iptables -A FORWARD -i $LAN -o $INET -j ACCEPT

Questa e' sostanzialmente inutile, se c'e' quella sopra.

> iptables -t nat -A PREROUTING -p tcp -d 80.XXX.XXX.XXX
> --dport 143 -j DNAT --to 192.168.0.3

Ok, ma ora ti manca di permettere il traffico in ingresso, usando
un -j ACCEPT in una regola FORWARD con dei match coordinati.

> iptables -t nat -A POSTROUTING -s 192.168.0.3 -j SNAT
> --to 80.XXX.XXX.XXX

Inutile: le risposte del server imap sono traffico ESTABLISHED, e
verranno gia' SNATtate correttamente.

Questo firewall scartera' tantissimo traffico di cui non avrai la
registrazione nei log. E' intenzionale o e' che non c'hai pensato
bene? Considera che registrare traffico ssh e webmin (immagino su
ssl) e' sostanzialmente inutile e, in ogni, caso non lo puoi fare
li'. Se decidi di loggare traffico non scartato per monitoraggio,
valuta di farlo su un socket netlink diverso, su cui poi metterai
in ascolto un secondo processo di ulogd (oppure un secondo socket
specter) configurato per registrare in formato pcap, altrimenti i
log che otterrai saranno sia confusi, sia inutili (e il "confusi"
sarebbe gia' di per se' un preludio ad "inutili"). Valuta bene lo
spazio disco.

Riprova, ripensa e riposta la nuova configurazione (IMHO), magari
specificando meglio se e dove ti servono il server web, rtsp, dns
ecc ecc ecc.


Fabio




[ Home | Liste | F.A.Q. | Risorse | Cerca... ]

www.sikurezza.org - Italian Security Mailing List
(c) 1999-2005