Newsgroup: it.comp.os.linux.sys
Titolo: iptables again

Salve a tutti,
 
riguardo la "sicurezza" di un firewall,
supponendo di voler permettere una
connessione ssh solo da un certo range
di indirizzi IP, on iptables si avrebbe:
 
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -s x.y.z.0/24 -j
ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j LOG
--log-prefix "sshd: " --log-level 4
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j DROP
 
Ora mi chiedevo, e` sufficiente "--state NEW",
oppure sarebbe meglio (log a parte) usare
"--state NEW,ESTABLISHED"?
 
Perche` nel caso il firewall venga "resettato",
vi e` una potenziale finestra dove una connessione
potrebbe stabilirs, di conseguenza non risulta piu`
"NEW" (quando il firewall riparte), quindi non viene
piu` rimossa.
 
Ha senso dal punto di vista della sicurezza?
Sbaglio? Se si, dove?
 
bye,
 
-- 
 
piergiorgio

 piu` rimossa.
 
  No, se iptables è svuotato (flushed), non tiene più traccia delle
vecchie connessioni instaurate.  Il problema potrebbe insorgere da
quello che succede tra il flush e il caricamento delle nuove regole: se
le regole di default (la policy) dopo il flush è ACCEPT, allora potrebbe
arrivare qualche pacchetto che inauguri una nuova sessione TCP/IP prima
che siano caricate le nuove regole che imporranno le restrizioni volute.
 La procedura corretta da seguire per la massima sicurezza è:
 
1) si imposta la policy delle catene da ricaricare a DROP:
   iptables -P INPUT DROP
 
2) si svuotano le catene da reinizializzare:
  iptables -F INPUT # La policy resta invariata!
 
3) si caricano le nuove regole:
   iptables -A INPUT -p tcp --dport 22 -s "$IP" -m state --state
NEW,RELATED -j ACCEPT
   iptables -A INPUT -p tcp --dport 22 -j REJECT
   (ecc.)
 
4) si reimposta la policy della catena all'azione desiderata:
   iptables -P INPUT ACCEPT
 
 
 
  Ciao,
 
 
-- 
Alessandro Selli 
http://alessandro.route-add.net
 
AVVERTENZA: i messaggi inviati a "trappola" non mi arriveranno.
WARNING: messages sent to "trappola" will never reach me.

 NEW,RELATED -j ACCEPT
 
  Scusa, NEW,ESTABLISHED.


   Errore di sintassi: invece di -m tcp devi usare -p tcp.
 
Allora, "-p tcp" c'e` ed e` all'inizio, ma "-m tcp",
che ho copiato da un'altra regola (non mia), a cosa
serve? O servirebbe?
 
Grazie in anticipo,
 
bye,
 
pg

piergiorgio

 Grazie in anticipo,
 
  Prego in posticipo!  :-)


    iptables -P INPUT ACCEPT
 
Io la farei piu' semplice: ;-)
 
iptables -P INPUT DROP
 
iptables -F INPUT
 
# regola ESTABLISHED, RELATED in cima alla catena
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
 
iptables -A INPUT -p tcp -s x.y.z.w/24 --dport ssh -j ACCEPT
(o, quest'ultima, se proprio si e' paranoici: iptables -A INPUT \
-p tcp -m state --state NEW -s x.y.z.w/24 --dport ssh -j ACCEPT)
 
(stessa cosa per FORWARD e, se si vuole, OUTPUT)
 
bye G.L.
-- 
Da i.d.c.tutela:
P.S. Quando ci sarà lo switch-off, avrò problemi anche col
monitor del PC? Ho visto che è collegato in modalità analogica.

 (stessa cosa per FORWARD e, se si vuole, OUTPUT)
 
  Manca la iptables -P INPUT ACCEPT.  L'OP non ha chiesto di fare un
firewall che seghi tutto tranne il servizio SSH in ingresso.  Ha solo
richiesto che il servizio SSH in ingresso passi se proveniente da una
gamma di IP precisi.


 una gamma di IP precisi.
 
Questo lo capisco, ma e' la costruzione del firewall in se' che
inizia male e finisce peggio con la default policy in ACCEPT.
IMHO, eh. :-)


 -p tcp -m state --state NEW -s x.y.z.w/24 --dport ssh -j ACCEPT)
 
Uhm, allora, quello che mi sfugge e` il
discorso NEW/ESTABLISHED.
Cioe`, capisco (credo) la differenza, ma
la domanda era se e` piu` sicuro, nella
regola per ssh, avere NEW,ESTABLISHED,
ovvero NEW da solo va bene lo stesso?
 
Quello che pensavo era, se il firewall
viene momentaneamente disabilitato, per
es. per un update delle regole, e` possibile
che venga stabilita una connessione ssh non
autorizzata, a quel punto, quando il firewall
riparte, la connessione e` ESTABLISHED, quindi
la connessione non viene piu` rimossa.
 
Grazie di nuovo,
 
bye,
 
-- 
 
piergiorgio

 la connessione non viene piu` rimossa.
 
Si'.


 ovvero NEW da solo va bene lo stesso?
 
  Senza ESTABLISHED e con una policy a DROP semplicemente non funziona.
 La connessione si instaura, ma poi i pacchetti che tentano di
utilizzarla (che non sono piï¿œ NEW, avendo la connessione fatto
transitare a quel punto pacchetti in entrambe le direzioni) no, sono
scartati.  Ottieni l'effetto di aprire connessioni inutilizzabili.


 qualcosa sia sfuggito e quindi accessibile...).
 
Allora, da quello che vedo & capisco io, la
regola "REJECT" e` l'ultima della catena.
La prima, pero`, e` "ACCEPT", con state
"ESTABLISHED,RELATED"
La policy sembra essere ACCEPT.
 
E` il default di fedora, che mette, poi, le
regole "custom" in mezzo, secondo l'ordine
dell'amministratore.
 
Gli esempi che ho trovato, per esempio per poter
usare un server NFS, considerano lo stato "NEW",
ma non "ESTABLISHED".
 
Cioe`, per l'INPUT:
 
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
... regole custom ...
-A INPUT -s x.y.z.0/24 -d x.y.z.0/24 -p udp -m state --state NEW -m udp
--dport 111 -j ACCEPT
... fine INPUT ...
-A INPUT -j REJECT --reject-with icmp-host-prohibited
 
Quello che io capisco e`:
1) accetta tutte le connessioni gia` esistenti o "RELATED".
2) accetta le connessioni"x.y.z.*" sulla porta 111 (NFS, ci
sono anche le altre, che ho saltato, per RPC, mountd, etc.).
3) rifiuta con errore tutto quello che arriva (sopravvive)
fino alla fine.
 
Ora, nella mia ignoranza, per prima cosa chiedo
cosa mi cambia se metto "-P INPUT DROP" (ammesso
che sia possibile senza troppe conseguenze).
 
Secondo, anche a me sembra un po' "convoluto" il
default, pero` avra` un senso, o no? Quale?
 
Grazie ancora a tutti e due,
 
bye,
 
-- 
 
piergiorgio

 usando la procedura di sistema (cioe` system-config-firewall)?
 
forse ti conviene un: vi /etc/sysconfig/iptables
 

 forse ti conviene un: vi /etc/sysconfig/iptables
 
Eh, in effetti, pensavo anche io.
 
Il problema (diciamo cosi`) e` che il tool di
configurazione aggiunge qualche default forse
essenziale.
 
Vorrei evitare di fare piu` pasticci del dovuto :-)
 
bye,
 
-- 
 
piergiorgio


sicuramente ti da delle dritte, per poi successivamente estendere il set 
di regole iniziali.
Ma in fase di installazione ti viene proposto di creare queste regole 
iniziali... o forse hai saltato questo step.

 iniziali... o forse hai saltato questo step.
 
Ci sono delle regole iniziali di default.
 
Le ho estese per NFS ed altro.
 
Il tool di configurazione e` in grado di usare file esterni
per customizzazioni particolari, ma "wrappa" sempre il tutto
con delle cose sue.
 
Non e` che sia difficile da capire, ma in /etc/sysconfig/iptables
e` chiaramente menzionato che non conviene cambiare questo file a
mano (e` scoraggiato).
Presumo che la ragione sia che se poi si usa il tool, i cambiamenti
"particolari" spariscono...
 
bye,
 
-- 
 
piergiorgio