Newsgroup: it.comp.os.linux.sys
Titolo: Ancora Firewall

Sto in questi giorni scrivendo un firewall con iptables lurkando un po
su quello di mrshark. Pero' piu vado avanti e piu ho dei dubbi...
Se io imposto la policy DROP, che senso ha aggiungere delle regole con
target DROP nella chain? Ho notato nel firewall di shark che ci sono
molti DROP, anche se si lavora con la *policy* già a DROP. Perche'
succede questo? Non è un qualcosa di inutile? Una cosa 'in più' che si
potrebbe evitare? Perche se io non ho nessuna regola, solo la policy a
DROP nessun paccketto puo' passare da quanto ho capito io, giusto?
So che le regole vengono processate a catena, come succede con procmail
per intenderci, se un pacchetto arriva dall'esterno e trova la policy
drop quindi non viene scartato, si cominciano a processare tutte le
regole nella chain e se non viene trovata nessuna corrispondenza il
pacchetto segue la policy, o sbaglio? Se cosi' una regola con taget drop
nella chain non fa altro che scartare il pacchetto prima di quanto venga
fatto dalla policy, ma non ha molto senso...
Chi mi spiega perche' è necessario specificare un target alla policy
uguale alle regole nella chain?
Seconda cosa, io da un pc in lan faccio un portscanning verso l'IP della
connessione dial-up del firewall-mascheratore, è normale che il
portscanning riesca? Che percorso fa il mio pacchetto?
Ultima cosa, se io mando un pacchetto ad una porta che non esiste, se il
firewall del computer a cui manco il pacchetto è impostato per loggare i
pacchetti a quella porta se ne accorge del pacchetto?
PC 1: iptables -A INPUT -p tcp --dport 31337 -j LOG
PC 2: telnet pc1 31337
-pc1 con porta 31337 che non esiste, non è aperta-
Domanda: Sul PC1 io non ottengo il LOG del pacchetto spedito dal pc2, è
normale? Sempre policy DROP alla chain INPUT.
Se il pacchetto non arriva a essere loggato vuol dire che non ha passato
la policy DROP? Se si, perche' non l'ha passata? Se i pacchetti non
"passassero" la policy non avrebbe senso avere delle regole nella chain
perche non verrebbero esaminate, giusto? E allora perche' non viene
loggato?
Come avrete notato ho molta confusione in testa anche se mi leggo il piu
possibile la doc (aimè mastico poco l'inglese, capisco *abbastanza* ma
per queste "finezza", non basta quell' abbastanza ;) ).
C'è qualche anima pia che mi da un po di chiarimenti?? Grazie di cuore:)
-- 
(N) (a) (i) (l) (m) (a) (n)
  ] - remove (dot) from my email address to reply - [
      ] - 
http://setiathome.ssl.berkeley.edu
 - [

normale? Sempre policy DROP alla chain INPUT.
gia` risposto sopra, il log funziona diversamente con iptablez
-- 
    Pardo 
 
www.pardo.cjb.net

gia` risposto sopra, il log funziona diversamente con iptablez
No il log è giusto;
iptables -A INPUT -p tcp -s pc2 --dport 31337 -j LOG
...il risultato è che non logga niente, come mai?
Ri-specifico che la porta non esiste, pero se un pacchetto tenta di
andar la' (telnet pc1 31337 dal pc2), me lo dovrebbe loggare in teoria.
Grazie per l'attenzione:=)


andar la' (telnet pc1 31337 dal pc2), me lo dovrebbe loggare in teoria.
Premessa, ci capisco una fava di reti ma, dove vorresti leggere il
log ?.. lo hai specificato in syslog.conf ?
# Log all kernel messages to the console.
# Logging much else clutters up the screen.
kern.info
						/var/log/kernel
===========================
[root@mario mario]# ipchains -A input -p tcp -s 0/0 --dport 12345 -j DENY -l
[root@mario mario]# telnet localhost 12345
Trying 127.0.0.1...
 
[root@mario mario]# egrep 12345 /var/log/kernel
Feb  5 00:31:55 mario kernel: Packet log: input DENY lo PROTO=6 
127.0.0.1:1081
127.0.0.1:12345
 L=60 S=0x00 I=3683 F=0x4000 T=64 SYN (#2)
-- 
Ciao, Mario.
http://digilander.iol.it/mccmario/

log ?.. lo hai specificato in syslog.conf ?
Che devo specificare? Io quello l'ho come Debian l'ha creato, ma il
fatto è che certi log me li creava e certi no, ora ti spiego com'è
andata (premessa, ho risolto):
Ero certo che loggasse perche nel firewall che mi sono scritto mi
loggava i tentativi di connessione. _MA_ sapendo che se un pacchetto
soddisfa una rule nella chain viene automaticamente scartato, avevo
messo _prima_ il LOG (che è un target che non scarta il pacchetto) e
_poi_ il DROP o ACCEPT. Mentre per questa prova avevo il firewall attivo
e la regola per il log si era aggiunta alla fine visto che non avevo
specificato diversamente. Ecco quindi che i pacchetti _verso_ localhost
vengono assegnati a target ACCEPT su una delle prime regole e quindi
scartati, ecco quindi che il pacchetto non 'arrivava' alla regola di
LOG, cosi ho provato :
router:/home/matteo# iptables -F
router:/home/matteo# iptables -P INPUT ACCEPT
router:/home/matteo# iptables -A INPUT -p tcp -s 0/0 --dport 12345 -j
LOG --log-level 7
router:/home/matteo# telnet localhost 12345
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
router:/home/matteo# egrep 12345 /var/log/syslog
Feb  5 02:13:09 router kernel: IN=lo OUT=
MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1
DST=127.0.0.1 LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP
SPT=4453 DPT=12345 WINDOW=11592 RES=0x00 SYN URGP=0
E il log si creò. =)
Quindi _questo_ l'ho capito. Pian piano qualcosa riesco a fare, il
target è riuscire a capire a fondo come opera un firewall :))
Per il resto, pacchetto dalla lan verso ip connessione dialup tramite
masquerading, e la faccenda dell'inutilità del target DROP in una chain
con policy DROP, c'è qualcuno che puo' darmi altre delucidazioni?
Grazie Mario :)



Secondo me il pacchetto arriva al pc1, il quale si accorge che l'ip
cercato e` quello suo, e quindi lo ferma li`.
Risultato, il pacco non esce in internet, quindi non entra neanche mai
dall'interfaccia ppp0, e il firewall non e` coinvolto.
Comunque se vai su 
http://grc.com
 ti fanno loro un portscan, cosi` vedi
se il fw sta funzionando (ti scrivono `stealth' in tutte le porte).
Oppure vai in irc ed entra sul canale della tua citta` o su
#italia; dovresti loggare subito un bel po' di tentativi su porte 1080
12345 e tutte quelle li`...
L'inutilita` del drop con la policy su drop e`... inutile! Che altro
c'e` da dire?
-- 
    Pardo 
 
www.pardo.cjb.net

12345 e tutte quelle li`...
Ci provero' :=)
Grazie di tutto
Ciao


 con iptables, bene era quello che mi volevo sentire dire:)
io non direi. Non sono un esperto di firewall, ma secondo me puo'
avere un senso una cosa del genere:
(ora butto giu' un paio di regole senza testarle, non linciatemi se
ho sbagliato la sintassi, spero solo che il concetto sia giusto)
# 1) di default, policy a DROP
iptables -P INPUT DROP
# 2) non accettare nulla verso la porta 6000, indipendentemente dagli
# accept che ci sono dopo
iptables -A INPUT -p tcp --dport 6000 -j DROP
# 3) accetta le connessioni dati di ftp
iptables -A INPUT -p tcp --sport ftp-data --dport 1024: -j ACCEPT
Supponi che non ci sia la regola 2). Se mi arriva un pacchetto dalla
porta ftp-data destinato alla porta 6000, non viene applicata la
policy di default perche' il pacchetto viene accettato dalla regola 3).
Siccome io invece non voglio che mi arrivi niente sulla porta 6000
(server X), indipendentemente da tutti gli accept che ci sono dopo,
metto un drop proprio all'inizio.
-- 
addio, e grazie per tutto il pesce


ineccepibile ;-)
-- 
    Pardo 
 
www.pardo.cjb.net

metto un drop proprio all'inizio.
Giustissimo, tnx :)
Ciao


fatto è che certi log me li creava e certi no,
<Sergio Vastano mode ON>
"ma, nnniente", puoi specificare il nome del file dove far finire il
log, ma a quanto pare e' gia' a posto. :-)
