Newsgroup: it.comp.os.linux.sys
Titolo: iptables ACCEPT/DROP

Salve,
che differenza c'e`, con iptables, tra ACCEPT di una sottorete,
rispetto al DROP del ! sottorete?
Cioe` tra:
-A INPUT -s 
192.168.0.0/24
 -p tcp -m state --state NEW -m tcp \
-j ACCEPT
-A INPUT -s ! 
192.168.0.0/24
 -p tcp -m state --state NEW -m tcp \
-j DROP
Thanks,
bye,
-- 
piergiorgio

 -j DROP
I pacchetti che contengono segmenti TCP provenienti da indirizzi non
appartenenti a 
192.168.0.0/24
 sono droppati; tutti gli altri pacchetti
(quelli provenienti da 
192.168.0.0/24
 oppure non TCP) passano alla regola
successiva (o al default).
La differenza principale e' che nel primo caso sei sicuro una certa
tipologia di pacchetti e' accettata; nel secondo caso, per la stessa
tipologia di pacchetti, non si puo' dire nulla. Molto dipende dalle altre
regole e/o dalla policy di default.

 regole e/o dalla policy di default.
Per prima cosa grazie della risposta.
Mi chiedevo se avesse senso, allora, combinare le regole,
cioe` prima DROP e poi ACCEPT, invece che solo ACCEPT.
Intendo, dal punto di vista della sicurezza.
Thanks again,
bye,
-- 
piergiorgio

 Intendo, dal punto di vista della sicurezza.
Dal punto di vista della sicurezza no. Dal punto di vista delle performance 
s� o per evitare il log di certi pacchetti s�.
-- 
Flavio Visentin
Scientists have finally discovered what's wrong with the female brain:
On the left side, there is nothing right, and on the right side, there
is nothing left.




Se la policy di default e' DROP, la prima regola e' superflua. pero', se la
policy di default e' ACCEPT, allora la prima regola ci vuole (e la seconda
e' superflua). 
Supponendo di avere solo quelle regole e di ricevere solo pacchetti tcp con
syn, cosa alquanto irreale, la sicurezza e' la stessa (in termini di cosa
viene accettato e cosa no). Cambia solo quando vengono fatte le cose. 
La differenza penso piu' che altro stia sta nell'efficienza; se tra la prima
riga e la seconda ci sono 500 regole, allora e' meglio anticipare il piu'
possibile i pacchetti che si vogliono droppare, in modo da risparmiarsi la
valutazione di tutte le altre regole prima di arrivare al default (che
comunque le dropperebbe, vero?   ;)

 comunque le dropperebbe, vero?   ;)
Grazie a tutti e due delle risposte.
Credo che il default sia REJECT, non DROP.
L'ultima regola (di INPUT) e`:
-A INPUT -j REJECT --reject-with icmp-host-prohibited
Immagino DROP sia meglio, o no?
bye,
-- 
piergiorgio

 Immagino DROP sia meglio, o no?
Dipende dall'effetto che vuoi ottenere. DROP semplicemente scarta il
pacchetto (e nmap e compagnia rilevano che la porta e' filtered). REJECT
invece lo scarta, ma invia anche al mittente un messaggio ICMP o TCP del
tipo che specifichi con --reject-with. Questo e' un po' piu' simile a cio'
che accade se arriva una connessione e non c'e' nulla in ascolto sulla
porta.
Pero' nota che REJECT non fa parte dei target base di iptables, deve essere
incluso a parte nel kernel (direttamente o tramite modulo), e quindi non e'
accettabile come policy di default (quella che imposti con iptables -P). 
Ovvio pero' che se metti un'ultima regola come quella che mostri, allora di
fatto diventa come se fosse il default e il vero default non viene mai
usato.

 usato.
Ah! OK, ora mi e` piu` chiaro.


 Pero` l'ultima regola e` appunto quel REJECT...
Si', e' la policy. In questo specifico caso comunque, come detto, non viene
mai usata perche' immediatamente prima c'e' una regola catch-all.

 appartenenti a 
192.168.0.0/24
 
... e per i quali non esiste uno stato nella tabella di conntrack...
Fabio

 (e solo quello, a voler essere precisi) per essere NEW.
Esatto, basta che sia un pacchetto per il quale iptables non ha visto
precedente traffico e non ha quindi uno stato. Mi sembrava un po' troppo
pedante e poco rilevante specificarlo esattamente nell'esempio.

 pedante e poco rilevante specificarlo esattamente nell'esempio.
Ecco... sono il solito pedante :-)

 Immagino DROP sia meglio, o no?
Con quella dichiari apertamente "salve, sono un firewall, probabilmente
redhat" :-)
Io preferisco, piuttosto, chiudere la catena con un reject-with tcp-reset 
per il tcp e il DROP come policy di catena.