Linux Router: Iptables rules and dhcp server on eth1
Installed new linux router for use today, Monday: Slackware 13, 2 nics.
eth0 - to the internet eth1 - to the LAN (dhcp server is set to listen on this interface) My iptables policies for INPUT OUTPUT and FORWARD are set to DROP. I've got about 30 users and all day long, at any given time, about 10% of the LAN clients (Win XP Pro Boxes) had difficulty obtaining ip addresses from the dhcp server. I've been logging packets and it appears I've found the problem, but I'm wondering if there's a better solution than the one I've implemented. More specifically, I've been logging like this, and dropping whatever doesn't come from the allowed subnet range: $IPT -t filter -A INPUT -i $LAN1 ! -s $SUBNET1 -j LOG --log-prefix "SPOOFED PKT" $IPT -t filter -A INPUT -i $LAN1 ! -s $SUBNET1 -j DROP And I've been ending up with lots of this in the log: Sep 21 17:19:16 joejoe kernel: SPOOFED PKTIN=eth1 OUT= MAC=(deleted to protect the innocent here)SRC=0.0.0.0 DST=255.255.255.255 LEN=332 TOS=0x00 PREC=0x00 TTL=128 ID=1 PROTO=UDP SPT=68 DPT=67 LEN=312 It seems like these dhcp requests are seen as spoofed packets, and it's happening as part of the natural course of a dhcp client calling out for an ip address, but not yet possessing a an address within the specified address range stated in the iptables rule. The only thing that appears to have eased the problem is changing the second rule stated above to: $IPT -t filter -A INPUT -i $LAN1 -j ACCEPT and also adding the following rule in the OUTPUT chain: $IPT -t filter -A OUTPUT -o $LAN1 -j ACCEPT However, both of these cause me some security concerns and I'm not sure if it's good practice to open up the LAN interface to all incoming data. Is there a better way? - - - - - - - - - - Also, a subsequent but related question: In order to facilitate dhcp clients obtaining ip addresses from LAN-side dhcp server, do I need to enable certain rules on the FORWARD chain? Currently, I have these enabled but I don't know if they are even necessary (remember, my FORWARD policy is set to DROP): $IPT -t filter -A FORWARD -m state --state INVALID -j LOG --log-prefix "DROP INVALID" --log-ip-options --log-tcp-options $IPT -t filter -A FORWARD -m state --state INVALID -j DROP $IPT -t filter -A FORWARD -i $LAN1 -p udp -s $SUBNET1 --dport 67 -j ACCEPT $IPT -t filter -A FORWARD -i $LAN1 -p udp -s $SUBNET1 --dport 68 -j ACCEPT $IPT -t filter -A FORWARD -i $LAN1 -m state --state NEW -p tcp -s $SUBNET1 --dport 67 -j ACCEPT $IPT -t filter -A FORWARD -i $LAN1 -m state --state NEW -p tcp -s $SUBNET1 --dport 68 -j ACCEPT $IPT -t filter -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT $IPT -t filter -A FORWARD -i $LAN1 ! -s $SUBNET1 -j DROP Thanks for your time and help. |
It's quite obvious why all the dhcp request are logged by your "not-our-subnet" rule cause the come from 0.0.0.0 which sure is not in your subnet ;)
You could just build a rule to get them before reaching the "not our subnet" rule like this Code:
iptables -A INPUT -s 0.0.0.0 -d 255.255.255.255 -p udp --sport 67 --dport 68 -j DHCP-rule-chain For the question where to put the Code:
$IPT -t filter -A FORWARD -i $LAN1 -p udp -s $SUBNET1 --dport 67 -j ACCEPT I always helped my self out with something like this to see how packages traverse the iptables rules and chains. Code:
iptables -A INPUT -j LOG --log-prefix="INPUT chain" Somewhere in /proc/net/ there is a file with all the legal targets and chains for iptables. (I'm just to lazy to look for it). Cheers Zhjim |
Zhjim, thanks for your thoughtful help.
Here's the solved,functional, and simplified result: $IPT -t filter -A INPUT -i $LAN1 ! -s $SUBNET1 -j LOG --log-prefix "SPOOFED PKT" $IPT -t filter -A INPUT -i $LAN1 -j ACCEPT echo "ouput" $IPT -t filter -A OUTPUT -m state --state INVALID -j LOG --log-prefix "DROP INVALID" --log-ip-options --log-tcp-options $IPT -t filter -A OUTPUT -m state --state INVALID -j DROP $IPT -t filter -A OUTPUT -o $SKYWAY -j ACCEPT $IPT -t filter -A OUTPUT -o $LAN1 -j ACCEPT echo "forward" $IPT -t filter -I FORWARD -i $SKYWAY -s 127.0.0.0/8 -j DROP $IPT -t filter -I FORWARD -i $SKYWAY -s 192.168.0.0/16 -j DROP $IPT -t filter -I FORWARD -i $SKYWAY -s 10.0.0.0/8 -j DROP $IPT -t filter -A FORWARD -m state --state INVALID -j LOG --log-prefix "DROP INVALID" --log-ip-options --log-tcp-options $IPT -t filter -A FORWARD -m state --state INVALID -j DROP $IPT -t filter -A FORWARD -i $LAN1 -p udp -s $SUBNET1 --dport 137 -j ACCEPT $IPT -t filter -A FORWARD -i $LAN1 -p udp -s $SUBNET1 --dport 138 -j ACCEPT $IPT -t filter -A FORWARD -i $LAN1 -p tcp -s $SUBNET1 --dport 139 -j ACCEPT $IPT -t filter -A FORWARD -i $LAN1 -p tcp -s $SUBNET1 --dport 445 -j ACCEPT $IPT -t filter -A FORWARD -i $SKYWAY -o $LAN1 -j ACCEPT $IPT -t filter -A FORWARD -i $LAN1 -o $SKYWAY -j ACCEPT the last two FORWARD rules facilitate destination routing to a few servers behind the firewall. They are needed to deal with my overall DROP policy in the FORWARD chain. I'm definitely going to follow up on the tail -f logging example. Great stuff. Thanks for your time. |
Hm I don't see now DHCP rules ;)
I'd also say your Forward rules for the machine itself are a bit to open. There should be no need to forward traffic coming from the local interface (127.0.0.1). Also you should accept traffic coming from there. I just diged up one of my favorite iptables script on the net http://homelansecurity.sourceforge.net/index.php This really help me to get the hang on good, paranoid but also simple iptable rules. Cheers Zhjim |
Quote:
Quote:
$IPT -t filter -I FORWARD -i $SKYWAY -s 127.0.0.0/8 -j DROP I like that HLS site, very good stuff to help follow the logic of chain statements from beginning to end. Thanks. |
Quote:
|
All times are GMT -5. The time now is 08:33 PM. |