I helped set up a firewall at my brother''s church and we are running shorewall 1.4.6b on a redhat 9 box. Works well. [root@fumcbafw shorewall]# uname -r 2.4.20-19.9 [root@fumcbafw shorewall]# iptables --version iptables v1.2.7a The box also serves as a dhcp server for the church offices and there is one box that apparently still has the old firewall config (zone alarm) on it since it tries every 10 seconds or so to get an ipaddress bit never completes the process. we saw this behavior when we switched to the new firewall. The issue is that dhcpd fills /var/log/messages with all the tries: Sep 28 04:05:12 fumcbafw dhcpd: DHCPDISCOVER from 00:04:e2:83:7c:75 via eth1 Sep 28 04:05:12 fumcbafw dhcpd: DHCPOFFER on 192.168.10.242 to 00:04:e2:83:7c:75 via eth1 Sep 28 04:05:12 fumcbafw dhcpd: DHCPDISCOVER from 00:04:e2:83:7c:75 via eth1 Sep 28 04:05:12 fumcbafw dhcpd: DHCPOFFER on 192.168.10.242 to 00:04:e2:83:7c:75 via eth1 4 lines every 10 seconds or so really hurts. So... I thought, since they can''t/won''t find the box with the trouble, I will simply block all this crap from being seen by the dhcp server. I added blacklist to the interface: [root@fumcbafw shorewall]# grep ''eth1.*blacklist'' interfaces loc eth1 detect blacklist I added the mac address to blacklist [root@fumcbafw shorewall]# tail -5 blacklist #ADDRESS/SUBNET PROTOCOL PORT ~00-04-e2-83-7c-75 #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE I even tried cranking up the logging for the blacklist in shorewall.conf [root@fumcbafw shorewall]# grep BLACKLIST shorewall.conf # BLACKLIST LOG LEVEL BLACKLIST_LOGLEVEL=debug # BLACKLIST DISPOSITION BLACKLIST_DISPOSITION=DROP shorewall has been restarted and iptables-save shows the rule [root@fumcbafw shorewall]# grep ''blacklst'' /tmp/iptables.save :blacklst - [0:0] [0:0] -A blacklst -m mac --mac-source 00:04:E2:83:7C:75 -j LOG --log-prefix "Shorewall:blacklst:DROP:" --log-level 7 [0:0] -A blacklst -m mac --mac-source 00:04:E2:83:7C:75 -j DROP [1260:97713] -A eth1_fwd -j blacklst [1086:255521] -A eth1_in -j blacklst the blacklst rull has not bee triggered but the log entries continue :( I thought I had a handle on this stuff but I guess that is what I get for thinking. There is obviously something I am missing here but I am stumped ohyeah, [root@fumcbafw shorewall]# lsmod |grep mac ipt_mac 1144 2 (autoclean) ip_tables 14488 13 [ipt_mac ipt_TOS ipt_MASQUERADE ipt_REJECT ipt_LOG ipt_state ipt_multiport ipt_conntrack iptable_filter iptable_mangle iptable_nat] Any tips appreciated. Bret
On Tue, 2003-09-30 at 15:26, Bret Hughes wrote:> > the blacklst rull has not bee triggered but the log entries continue :( > > I thought I had a handle on this stuff but I guess that is what I get > for thinking. There is obviously something I am missing here but I am > stumped >DHCP requests are accepted before the blacklist is processed. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Tue, 2003-09-30 at 15:32, Tom Eastep wrote:> On Tue, 2003-09-30 at 15:26, Bret Hughes wrote: > > > > > the blacklst rull has not bee triggered but the log entries continue :( > > > > I thought I had a handle on this stuff but I guess that is what I get > > for thinking. There is obviously something I am missing here but I am > > stumped > > > > DHCP requests are accepted before the blacklist is processed.In other words, you won''t be able to stop the messages using the blacklist (or any other "standard" Shorewall mechanism). You can use /etc/shorewall/start to insert a rule into the head of the eth1_in chain that drops traffic from the offending device. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Tue, 30 Sep 2003, Tom Eastep wrote:> > > > DHCP requests are accepted before the blacklist is processed. > > In other words, you won''t be able to stop the messages using the > blacklist (or any other "standard" Shorewall mechanism). You can use > /etc/shorewall/start to insert a rule into the head of the eth1_in chain > that drops traffic from the offending device. >If you are willing to install 1.4.7 RC1 then you can replace the /usr/share/shorewall/firewall script with the one from CVS (/Shorewall project). That version moves blacklist processing before DHCP processing (or the change to your own firewall script is pretty trivial). -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Tue, 2003-09-30 at 17:26, Bret Hughes wrote:> I helped set up a firewall at my brother''s church and we are running > shorewall 1.4.6b on a redhat 9 box. Works well. > > [root@fumcbafw shorewall]# uname -r > 2.4.20-19.9 > > [root@fumcbafw shorewall]# iptables --version > iptables v1.2.7a > > > The box also serves as a dhcp server for the church offices and there is > one box that apparently still has the old firewall config (zone alarm) > on it since it tries every 10 seconds or so to get an ipaddress bit > never completes the process. we saw this behavior when we switched to > the new firewall.After Tom''s reply, (I read it on the web since I have not resub''ed to this list) that these packet are accepted before the blacklist, I did some different googles and found that dhcpd evidently listens on a raw socket and the packets never make it to the regular tcp stack and therefore never get processed by iptables. FYI I was able to solve the logging problem with the following addition to /etc/dhcpd.conf: host foo { hardware ethernet 00:04:e2:83:7c:75; ignore booting; } no more log messages yeah. Learned something to boot. Never heard of raw sockets before. Bret