Newsgroup: it.comp.os.linux.iniziare
Titolo: dhcp supera il firewall

# iptables -F
# iptables -A INPUT -j DROP
# dhcpd start
Mi aspetto che nessun client vada in rete. Eppure riescono tutti a
prendere un indirizzo ip e questo viene loggato sia sul messages che
nel dhcpd.leases
Chi mi svela l'arcano?
Matteo

 Davide
francamente pure io sono stupito. 
senza raginare troppo, se il server dhcp ha questa regola attiva
        iptables -A INPUT -j DROP
come puo' ricevere una richiesta di indirizzo??
tra l'altro qst regola blocca pure i processi che devono dialogare con 
localhost. quindi anche 
        ping localhost 
dovrebbe non funzionare.
perdonate se dico boiate, ma sono a stomaco vuoto.
 
-- 
---------------------------------------
linux slackware
tutto il resto e' inutile
---------------------------------------


e non solo... blocca anche la possibilità di uscire (il server remoto
sente le richieste ma non ha la possibilità di rispondere)
comunque eccolo accontentato:
iptables -A INPUT -j DROP
iptables -A FORWARD -j DROP
iptables -A OUTPUT -j DROP
    DHCPDISCOVER from 00:90:dc:05:71:1a via eth0
    DHCPACK on 192.168.173.16 to 00:90:dc:05:71:1a via eth0
iptables -t nat -A PREROUTING -j DROP
iptables -t nat -A POSTROUTING -j DROP
iptables -t nat -A OUTPUT -j DROP
    DHCPDISCOVER from 00:90:dc:05:71:1a via eth0
    DHCPACK on 192.168.173.16 to 00:90:dc:05:71:1a via eth0
iptables -t mangle -A PREROUTING -j DROP
iptables -t mangle -A INPUT -j DROP
iptables -t mangle -A FORWARD -j DROP
iptables -t mangle -A OUTPUT -j DROP
iptables -t mangle -A POSTROUTING -j DROP
    DHCPDISCOVER from 00:90:dc:05:71:1a via eth0
    DHCPACK on 192.168.173.16 to 00:90:dc:05:71:1a via eth0
Più chiuso di così credo che esista solamente un computer senza scheda
di rete...
Eppure il server dhcp continua a ricevere richieste e fornire
indirizzi ip. Tutti gli altri pacchetti vengono bloccati (infatti non
funziona un tubo).
Matteo

mmm...
ho dato un netstat:
# netstat -anp|grep 4727
udp        0      0 
0.0.0.0:67
0.0.0.0:*                           4727/dhcpd
raw        0      0 
0.0.0.0:1
               0.0.0.0:*
7           4727/dhcpd
unix  2      [ ]         DGRAM                    14739  4727/dhcpd
e lsof da
dhcpd   4672 dhcpd    3u  unix 0xc13e0500           14614 socket
dhcpd   4672 dhcpd    4u   raw                      14619
00000000:0001->00000000:0000 st=07
dhcpd   4672 dhcpd    5u  IPv4      14623             UDP *:bootps
dhcpd   4672 dhcpd    6u   REG        3,3    1064 1157510 /var/lib/
dhcp/db/dhcpd.leases
dhcpd   4672 dhcpd    7u  sock        0,5           14622 can't
identify protocol
ok, è vero, ci sono anche altri due protocolli. Ma netfilter non
gestisce anche quelli? come li blocco?
Matteo

Matteo Rossini wrote:

]zac[
A parte errori e sviste nell'impostazione del firewall (che solo chi
gestisce il sistema può scoprire), potrebbe essere il fatto che il server e
il client dhcp comunicano attraverso il MAC address delle schede di rete e
in broadcast e non sono ne comunicazioni tcp ne udp, e quindi non sono
gestite dal firewall.
In sintesi probabilmente il firewall non filtra perché non c'è
''''nessun'''' traffico da filtrare.
Presumo, sempre a parte errori e sviste di cui sopra, che una ricerca su
www.google.com
 con dhcp + firewall potrebbe essere utile.

 ''''nessun'''' traffico da filtrare.
]zac[
Sbagliato, è traffico udp, infatti da un esempio:
$IPTABLES -N udp_packets
$IPTABLES -A INPUT -p UDP -i $INET_IFACE -j udp_packets
#
# UDP ports
#
$IPTABLES -A udp_packets -p UDP -s 0/0 --source-port 53 -j ACCEPT
if [ $DHCP == "yes" ] ; then
 $IPTABLES -A udp_packets -p UDP -s $DHCP_SERVER --sport 67 \
 --dport 68 -j ACCEPT
fi
#
# If we get DHCP requests from the Outside of our network, our logs will
# be swamped as well. This rule will block them from getting logged.
#
#$IPTABLES -A udp_packets -p UDP -i $INET_IFACE -d 255.255.255.255 \
#--destination-port 67:68 -j DROP