Newsgroup: it.comp.sicurezza.varie
Titolo: iptables da .sh (parte 2)

bene, ho creato uno script .sh per iptables, cercando di capire dove 
mettere le mani, ma evidentemente devo studiare ancora.
http://boycottbabies.altervista.org/ipt/01.txt
pareri/correzioni/info/ecc?
-- 
boycottbabies::at::altervista::org
site: 
boycottbabies.altervista.org
ma secondo te davvero il canarino ha le ali perchè desidera volare?? 
altro che Walt Disney qui...
pure l'uomo ha sempre desiderato volare...ma io le ali non le ho!!
Le ali sono semplicemente frutto della selezione 
naturale...dell'evoluzione e via dicendo...

 pareri/correzioni/info/ecc?
Vogliamo cominciare da qui?
$ipt -t nat -P POSTROUTING DROP
$ipt -t nat -A POSTROUTING -s ! $GWY -o 192.168.0.10 -j MASQUERADE
Primo: se la tabella si chiama nat e non filter, un perche' ci sara', non
credi?
Quella tabella serve a fare natting, non filtering.
Ergo, non si capisce perche' tu debba fare dropping li'.
Secondo: visto che ci hai tenuto a fare dropping nella tabella di nat,
vogliamo valutare cosa comporta quel che hai scritto?
La catena di POSTROUTING, tabella nat, e' l'ultima in assoluto ad essere
attraversata dai pacchetti provenienti dal FORWARD e dall'OUTPUT e diretti
verso "fuori".
Dunque tutti i pacchetti uscenti dal firewall, siano essi pacchetti
provenienti da altre box (FORWARD) che pacchetti locali (OUTPUT) beccano
inesorabilmente la policy DROP della catena POSTROUTING della tabella di
nat, visto che dubito fortemente che tu abbia un'interfaccia  che si
chiama 192.168.0.10 
-- 
Per non dimenticare:
http://snipurl.com/SdC_ed_il_vino
Le sigarette a volte danno buoni consigli:
http://snipurl.com/sigarette

 chiama 192.168.0.10 
mh.... si, spiegato cosi' lo afferro meglio :)
e' corretto specificare anche -s ! $GWY ?
altra domanda: come vedi avrei l'intenzione di usare MZ e DMZ.
in una rete mista windows/unix+samba, non so come debba far comportare 
il firewall per le richieste NetBios.
mi spiego: se nella DMZ metto due server con directories condivise e 
nella MZ ci sono le ws su windows, come devo impostare il firewall in 
modo che le  postazioni win vedano i due server ognuno con i loro netbios?
o forse non sono stato molto chiaro.


 modo che le  postazioni win vedano i due server ognuno con i loro netbios?
Ad occhio, con le regole che vedo dovresti gia' riuscirci:
$ipt -A mz_dmz -s $MZ -j ACCEPT
$ipt -A dmz_mz -m state --state ESTABLISHED,RELATED -j ACCEPT
Un paio di osservazioni ulteriori:
$ipt -A FORWARD -i eth2 -o eth1 -l gwy_dmz
Credo che ci sia un typo.
$ipt -A INPUT -m limit --limit 10/min -p tcp --syn -s $MZ --dport ssh -j ACCEPT
Qui, se qualcuno ci si mette di punta, ti fa un denial of service niente male. <g>


 Qui, se qualcuno ci si mette di punta, ti fa un denial of service niente male. <g>
ouch....
anche se l'ssh gira sul solo ip della MZ ?


 anche se l'ssh gira sul solo ip della MZ ?
Il problema è che tu non limiti in alcun modo l'interfaccia da cui ti
aspetti di veder arrivare le richieste che incocciano quella regola.
Quindi basta che qualcuno mantenga un rate costante di 10 syn/min
spoofando l'ip sorgente (e mettendocene uno appartenente a $MZ) e il tuo
SSH smette di accettare connessioni da chiunque...
Questo, posto che precedentemente tu non abbia regole di esplicito DROP
degli ip spoofati sulla singola interfaccia (cosa che non son andato a
vedere, ho pigliato il thread da qui..)
-- 
cat: .signature: No such file or directory

 anche se l'ssh gira sul solo ip della MZ ?
Vedi considerazioni del compagno bofh Skull. <g>

 vedere, ho pigliato il thread da qui..)
umh.... io tendenzialmente toglierei quella regola la', e in fin dei 
conti un firewall non e' che lo si debba toccare ogni santo giorno, 
tanto da dovergli tenere sempre aperta la 22, anzi ero partito con 
un'idea cosi'.
pero', visto che sto cercando anche di capire come gestire iptables via 
script, mi interessa comunque trovare una "soluzione", anche se poi non 
la applico.
dunque, dovrei specificare esplicitamente che l'ssh lo accetti solo 
sulla eth0 (mz) o ho capito male?


 sulla eth0 (mz) o ho capito male?
Si, diciamo che è il "male minore", se proprio vuoi mantenere quel rate.
Alle limitazioni alla grezza di quel tipo lì ci credo poco, comunque; le
ho viste creare più problemi che altro. Se proprio temi qualche attacco
massivo verso ssh, pensa ad altre soluzioni: contro i bruteforce puoi
loggare le autenticazioni fallite e segare tramite qualche regoletta
dinamica gli ip che le generano per X minuti tramite qualche scriptino;
verso SYN flood usa piuttosto i SYN-cookies, ecc...


 verso SYN flood usa piuttosto i SYN-cookies, ecc...
uhm..... sono un fifone, tolgo l'ssh :-)
grz.
