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

or just accept them. (-j ACCEPT).

For the question where to put the
you have I'd go for the INPUT part. See the forward rule is used when you forward packages, but I think you need to accept the packages on the very server.
I always helped my self out with something like this to see how packages traverse the iptables rules and chains.

and tail -f the logfile.
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

Ya true, I only posted the relevant portions that needed work; it's not the whole firewall.

No worries, the rule is a DROP, not accepting the forward --
$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.

Ups my bad. Go ahead