Newsgroup: it.comp.os.linux.sys
Titolo: Problemini con iptables

Ho un firewall di sto tipo:
---------------
#!/bin/sh
iptables="/sbin/iptables"
WAN="bond0"
LAN="eth0"
RULE_NAME="CUSTOMER-171-7"
IP="192.168.171.7"
$iptables -F
$iptables -X
$iptables -t nat -F
$iptables -t nat -X
$iptables -t mangle -F
$iptables -t mangle -X
$iptables -P INPUT ACCEPT
$iptables -P FORWARD ACCEPT
$iptables -P OUTPUT ACCEPT
$iptables -A FORWARD -i $WAN -o $LAN -m state --state
ESTABLISHED,RELATED -j ACCEPT
$iptables -A FORWARD -i $WAN -o $LAN -p icmp --icmp-type echo-reply -j
ACCEPT
$iptables -N $RULE_NAME-IN
$iptables -N $RULE_NAME-OUT
$iptables -A FORWARD -i $WAN -o $LAN -d $IP -j $RULE_NAME-IN
$iptables -A FORWARD -i $LAN -o $WAN -s $IP -j $RULE_NAME-OUT
$iptables -A $RULE_NAME-IN -p tcp -m multiport --dport 21,80 -j ACCEPT
$iptables -A $RULE_NAME-IN -j DROP
$iptables -A $RULE_NAME-OUT -j ACCEPT
$iptables -A FORWARD -i $WAN -o $LAN -p icmp -j DROP
----------------
Nulla di complesso.
In ingresso il traffico funziona, solo per le porte attive (21,80) ma
se da dentro il server cerco di raggiungere una porta 80 remota, non
ricevo risposta.
Nei log vedo che il traffico avente porta 80 come SORGENTE viene
bloccato, ma non dovrebbe, invece, essere autorizzato dalla regola:
$iptables -A FORWARD -i $WAN -o $LAN -m state --state
ESTABLISHED,RELATED -j ACCEPT
essendo traffico inerente una connessione già stabilita generata
dall'interno?

 come default ha DROP.
Immaginavo, ma la deviazione nella catena "RULE_NAME-IN" viene
effettuata DOPO.

 effettuata DOPO.
Giusto per fare una prova, ora ho qualcosa di sto tipo:
$iptables -A $RULE_NAME-IN -m state --state ESTABLISHED,RELATED -j
ACCEPT
$iptables -A $RULE_NAME-IN -p tcp -m multiport --dport 21,80 -j ACCEPT
$iptables -A $RULE_NAME-IN -j LOG --log-prefix "DROP INGRESSO: "
$iptables -A $RULE_NAME-IN -j DROP
Il traffico sulla 21 e 80 in ingresso viene autorizzato, e tutto il
resto viene loggato, il che significa che la regola
ESTABLISHED,RELATED non viene presa in considerazione (ed infatti non
si naviga).
Deve esserci qualcosa che mi sfugge perchè ho fatto firewall così
semplici decine decine e decine di volte, magari è uno stupido errore
di typo boh...

 si naviga).
sicuro che il modulo di conntrack sia caricato?

 sicuro che il modulo di conntrack sia caricato?
No, non lo era.
Ora lo è.
E non va uguale.
(mi dimentico fisso di caricare il modulo, solitamente lo compilo
statico ma a 'sto giro il kernel non è 'mio')

 sicuro che il modulo di conntrack sia caricato?
# lsmod | egrep "ipt_|nf_"
nf_nat_snmp_basic      11140  0
nf_nat_irc              3712  0
nf_conntrack_irc        7832  1 nf_nat_irc
nf_nat_amanda           3456  0
nf_conntrack_amanda     6016  1 nf_nat_amanda
ipt_ttl                 2816  0
ipt_tos                 2560  0
ipt_recent             10264  0
ipt_owner               2944  0
ipt_iprange             2816  0
ipt_ecn                 3200  0
ipt_ah                  2944  0
ipt_addrtype            2816  0
ipt_ULOG                9348  0
ipt_TTL                 3328  0
ipt_TOS                 3200  0
ipt_SAME                3328  0
ipt_REJECT              5632  0
ipt_REDIRECT            2944  0
ipt_NETMAP              2944  0
ipt_MASQUERADE          4736  0
ipt_ECN                 3968  0
ipt_CLUSTERIP           9604  0
ipt_LOG                 7424  1
nf_conntrack_ipv4      19336  3 iptable_nat
nf_nat_pptp             4608  0
nf_conntrack_pptp       8064  1 nf_nat_pptp
nf_conntrack_proto_gre     7168  1 nf_conntrack_pptp
nf_nat_h323             8576  0
nf_conntrack_h323      51292  1 nf_nat_h323
nf_nat_sip              5760  0
nf_conntrack_sip       10132  1 nf_nat_sip
nf_nat_proto_gre        3844  1 nf_nat_pptp
nf_nat_tftp             2816  0
nf_nat_ftp              4352  0
nf_nat                 20524  13
nf_nat_irc,nf_nat_amanda,ipt_SAME,ipt_REDIRECT,ipt_NETMAP,ipt_MASQUERADE,iptable_nat,nf_nat_pptp,nf_nat_h323,nf_nat_sip,nf_nat_proto_gre,nf_nat_tftp,nf_nat_ftp
nf_conntrack_tftp       6036  1 nf_nat_tftp
nf_conntrack_ftp       10272  1 nf_nat_ftp
nf_conntrack           66880  24
nf_nat_snmp_basic,nf_nat_irc,nf_conntrack_irc,nf_nat_amanda,nf_conntrack_amanda,ipt_MASQUERADE,ipt_CLUSTERIP,xt_conntrack,iptable_nat,xt_state,nf_conntrack_ipv4,xt_NOTRACK,nf_nat_pptp,nf_conntrack_pptp,nf_conntrack_proto_gre,nf_nat_h323,nf_conntrack_h323,nf_nat_sip,nf_conntrack_sip,nf_nat_tftp,nf_nat_ftp,nf_nat,nf_conntrack_tftp,nf_conntrack_ftp
ipt_rlsnmpstats        11904  0
x_tables               16260  29
ipt_ttl,ipt_tos,ipt_recent,ipt_owner,ipt_iprange,ipt_ecn,ipt_ah,ipt_addrtype,ipt_ULOG,ipt_TTL,ipt_TOS,ipt_SAME,ipt_REJECT,ipt_REDIRECT,ipt_NETMAP,ipt_MASQUERADE,ipt_ECN,ipt_CLUSTERIP,arpt_mangle,arp_tables,xt_conntrack,iptable_nat,ipt_LOG,xt_tcpudp,xt_multiport,xt_state,xt_NOTRACK,ip_tables,ipt_rlsnmpstats
ipv6                  266340  31 nf_conntrack_h323
Non ho altri moduli.

 wrote:
Se può interessare, queste sono le regole:
# iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  
0.0.0.0/0
 
0.0.0.0/0
           state
RELATED,ESTABLISHED
ACCEPT     icmp --  
0.0.0.0/0
 
0.0.0.0/0
           icmp type
0
CUSTOMER-171-7-IN  all  --  
0.0.0.0/0
192.168.171.7
CUSTOMER-171-7-OUT  all  --  192.168.171.7
0.0.0.0/0
DROP       icmp --  
0.0.0.0/0
 
0.0.0.0/0
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
Chain CUSTOMER-171-7-IN (1 references)
target     prot opt source               destination
LOG        all  --  
0.0.0.0/0
 
0.0.0.0/0
           state
RELATED,ESTABLISHED LOG flags 0 level 4 prefix `ESTABLISHED: '
ACCEPT     tcp  --  
0.0.0.0/0
 
0.0.0.0/0
           multiport
dports 21,80
LOG        all  --  
0.0.0.0/0
 
0.0.0.0/0
           LOG flags
0 level 4 prefix `INGRESSO: '
DROP       all  --  
0.0.0.0/0
 
0.0.0.0/0
Chain CUSTOMER-171-7-OUT (1 references)
target     prot opt source               destination
ACCEPT     all  --  
0.0.0.0/0
 
0.0.0.0/0

 sicuro che il modulo di conntrack sia caricato?
Credi di aver capito il problema.
Sto usando una distro (vyatta) su cui non ho il controllo del kernel.
Ho questo alias:
alias ip_conntrack nf_conntrack_ipv4
quindi quando do modprobe "ip_conntrack" mi si carica
"nf_conntrack_ipv4".
Su una debian 'standard' non ho tale alias ed esiste il modulo
"ip_conntrack.ko" mentre su vyatta
ho solo nf_conntrack_ipv4.ko
Che sia quello il problema?

Alessandro ha scritto:
Ho provato a svuotare totalmente il firewall ed a mettere una singola
regola di log.
se faccio
"-m state --state NEW"
mi vengono loggate le nuove connessioni, mentre se faccio
"-m state --state ESTABLISHED"
non mi logga niente.
Sembra proprio non riesca a tenere traccia delle connessioni.
Sia "/proc/net/ip_conntrack" che "/proc/net/nf_conntrack" sono
completamente vuoti.
Ne sto uscendo matto.
Avete qualche idea?

ESTABLISHED,RELATED -j ACCEPT
Da dentro il server intendi il firewall? Perché se è così non vedo la regola
equivalente al forward che indichi relativa all'INPUT
Ciao
 Nameci

 equivalente al forward che indichi relativa all'INPUT
No, intendevo un server esterno a valle del firewall.
Ma ho risolto, quei biricchini di vyatta tengono caricato perennemente
un modulo xt_NOTRACK che serve proprio a disabilitare il connection
tracking.
Blacklistando il modulo ha iniziato a funzionare tutto.