glug:firewall: questo rompicapo

[Paolo Gaggini]

Giocando con iptables mi sono crollate delle certezze.
Ecco la situazione: Domuegressio è collegato al modem ADSL e quindi a 
Internet, inoltre tramite un'altra scheda di rete alla LAN interna e 
funziona da gateway.
Ho impostato il forwarding per il masquerading dei client e il port 
forwarding per i vari servizi su Sempervirens. Fin qui ok.
Il problema è quando cerco di costruirmi da solo il firewall.
Ho provato a impostare la catena INPUT a DROP, con l'effetto che 
Domuegressio diventa totalmente irraggiungibile. Il forwarding e il 
port forwarding invece continuano a funzionare bene. Perfetto. Il passo 
successivo è aprire le porte ssh e sunrpc, che uso per collegarmi al 
server in remoto. Il comando:
iptables -A INPUT -p tcp --sport 22 -j ACCEPT
per esempio, dovrebbe aprirmi la porta ssh MA invece non funziona, 
sebbene con il comando iptables -L la regola sembra essere stata 
recepita correttamente.
Ho provato allora a impostare di nuovo la policy di INPUT ad ACCEPT e ad 
aggiungere il comando:
iptables -A INPUT -p tcp -j REJECT
In questo modo la policy è ACCEPT, ma di fatto con quel filtro non passa 
nulla sul solo tcp. I ping, infatti, funzionano.
La porta 22, comunque, rimane totalmente chiusa. Ho provato anche a 
invertire l'ordine delle regole: prima ho messo la regola di apertura 
di ssh, poi la chiusura di tutto il tcp. E viceversa. Ma la porta 22 
rimane sempre e comunque chiusa. 

Impostando la policy ad ACCEPT potrei chiudere tutte le porte tranne la 
22 con un paio di comandi, ma a parte che un lavoro del genere non mi 
pare molto furbo, mi chiedo allora a cosa serva la "policy". Leggendo 
l'iptables-howto è scritto chiaramente che prima vengono valutate le 
regole di filtro, poi se nessuna matcha allora il pacchetto fa la fine 
indicata dalla policy. Ovvero: impostando INPUT a DROP, tutti i 
pacchetti sono scartati a meno che una regola di filtro non dica il 
contrario. Che è proprio quello che volevo fare con la porta 22. 

Com'è la faccenda?

Altro aspetto didatticamente interessante: il classico filtro su 
microsoft.com. 

Situazione: regola di iptables su Domuegressio, mentre io navigo con 
Cerebellum (la mia workstation, che accede a internet tramite 
Domuegressio).
Se filtro microsoft.com sulla catena di INPUT non ho alcun effetto, 
mentre se lo filtro sulla catena di FORWARD funziona. E' suggestivo 
impostare e cancellare la regola relativa di REJECT durante la 
navigazione: con un comando da console riesco a bloccare o permettere 
la navigazione sui siti Microsoft in diretta!!

Però, mi chiedo: poichè i pacchetti tcp:80 che arrivano da microsoft.com 
sono in ingresso, cioè in INPUT, perchè il filtro su INPUT non funziona 
mentre su FORWARD si?? Ho letto sull'iptables-howto che i pacchetti in 
forward comunque passano prima da INPUT (o forse ho capito male?)

Più che la catena di INPUT, nel caso microsoft, comunque credo mi 
convenga filtrare quella di OUTPUT..... soprattutto usando client 
windows, o sbaglio? ;-) Domandona: se da un mio pc nella lan parte un 
pacchetto verso microsoft questo viene visto come OUTPUT o come 
FORWARD? 

(ma perchè non c'è un bel sole caloroso così oggi facevo il barbecue 
invece di torturarmi così??? :))))))

----------
Paolo Gaggini
gse@libero.it  --   email pubblica
http://www.gseserver.net  -- GSE Network
http://www.biologiafacile.net -- Portale Universitario
http://www.linux-at-home.net   -- LINUX@HOME

#220216 Linux Registered User