I have spent an embarassingly large number of hours today trying to get Apache to serve stuff through iptables as configured by Shorewall. After much logging, shorewall reloading, and packet sniffing, I found that my router (192.168.254.254) is sending ICMP packets back to me when big files are requested by some (but not all?!?!?) clients: Mar 12 19:45:51 [kernel] DEBUG:IN IN=eth1 OUT= MAC=<whatever> SRC=192.168.254.254 DST=192.168.254.1 LEN=56 TOS=0x00 PREC=0x00 TTL=64 ID=22404 DF PROTO=ICMP TYPE=3 CODE=4 [SRC=192.168.254.1 DST=69.57.157.43 LEN=1520 TOS=0x00 PREC=0x00 TTL=63 ID=54196 FRAG:64 PROTO=TCP ] MTU=1492 The type and code mean "Fragmentation needed but no frag. bit set." Shorewall drops ICMP packets, so I had to add the following to /etc/shorewall/start: iptables -I INPUT -i eth1 -s 192.168.254.254 -p icmp --icmp-type 3 -j ACCEPT Presumably, no one will be able to make my router send malicious ICMP packets of type 3, all codes of which look pretty benign. Not really asking for any help here, but curious if anyone knows of a fix for the ICMP junk and if anyone has ever heard of this. -- Ed Suominen Registered Patent Agent Open Source Developer (Yes, both...) Web Site: http://www.eepatents.com
On Fri, 12 Mar 2004, Ed Suominen wrote:> I have spent an embarassingly large number of hours today trying to get > Apache to serve stuff through iptables as configured by Shorewall. > > After much logging, shorewall reloading, and packet sniffing, I found that > my router (192.168.254.254) is sending ICMP packets back to me when big > files are requested by some (but not all?!?!?) clients: > > Mar 12 19:45:51 [kernel] DEBUG:IN > IN=eth1 OUT> MAC=<whatever> SRC=192.168.254.254 DST=192.168.254.1 > LEN=56 TOS=0x00 PREC=0x00 TTL=64 ID=22404 DF > PROTO=ICMP TYPE=3 CODE=4 [SRC=192.168.254.1 DST=69.57.157.43 LEN=1520 > TOS=0x00 PREC=0x00 TTL=63 ID=54196 FRAG:64 PROTO=TCP ] > MTU=1492 > > The type and code mean "Fragmentation needed but no frag. bit set." > > Shorewall drops ICMP packets, so I had to add the following > to /etc/shorewall/start: > > iptables -I INPUT -i eth1 -s 192.168.254.254 -p icmp --icmp-type 3 -j ACCEPT > > Presumably, no one will be able to make my router send malicious ICMP > packets of type 3, all codes of which look pretty benign. > > Not really asking for any help here, but curious if anyone knows of a fix > for the ICMP junk and if anyone has ever heard of this. >What you are doing is a hack to work around some more fundimental problem. My guess is that the real problem is either that: a) You need CLAMPMSS=Yes in shorewall.conf but have CLAMPMSS=No ; or b) On your internal network, the firewall has an MTU that is different from the MTU configured in the client systems. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Fri, 12 Mar 2004, Tom Eastep wrote:> On Fri, 12 Mar 2004, Ed Suominen wrote: > > > > > Shorewall drops ICMP packets, so I had to add the following > > to /etc/shorewall/start: > >And by the way, the above is complete FUD.... -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Tom Eastep wrote:>> Shorewall drops ICMP packets, so I had to add the following >> to /etc/shorewall/start:Tom, this was not meant as any sort of criticism (is that what you meant by "FUD"?). It was merely a neutral observation about what Shorewall does -- doubtless out of good design practice for security''s sake. Please don''t misunderstand -- I''m a big fan of your work!> What you are doing is a hack to work around some more fundimental problem. > My guess is that the real problem is either that: > > a) You need CLAMPMSS=Yes in shorewall.conf but have CLAMPMSS=No ; orTried that, after ensuring that my kernel is properly configured. But it didn''t help -- still didn''t work without my "--proto icmp" hack.> b) On your internal network, the firewall has an MTU that is different > from the MTU configured in the client systems.Excellent tip! I changed the MTU of my Internet NIC to 1492 and it works without the hack. (I left "CLAMPMSS=Yes" alone, figuring that''s probably the right setting whether it matters for this or not.) I noticed during my packet sniffing that the "shorewall clear" (worked OK) setup was sending 8 fewer bytes per packet than the "shorewall start" (bad HTTP) setup, which is interesting given that 1500-1492=8. Tom, thanks for your help. -- Ed Suominen Registered Patent Agent Open Source Developer (Yes, both...) Web Site: http://www.eepatents.com
On Friday 12 March 2004 08:29 pm, Tom Eastep wrote:> On Fri, 12 Mar 2004, Tom Eastep wrote: > > On Fri, 12 Mar 2004, Ed Suominen wrote: > > > Shorewall drops ICMP packets, so I had to add the following > > > to /etc/shorewall/start: > > And by the way, the above is complete FUD.... >I should elaborate. Shorewall relies on Netfilter''s connection tracking to handle ICMP (with the exception of ''ping''). ICMP packets that are related to a connection are expected to be handled by an ACCEPT rule that matches state ESTABLISHED and state CONNECTED. Example: gateway:~# shorewall show fw2dmz Shorewall-2.0.0-RC2 Chain fw2dmz at gateway.shorewall.net - Sat Mar 13 06:34:28 PST 2004 Counters reset Wed Mar 10 16:14:45 PST 2004 Chain fw2dmz (1 references) pkts bytes target prot opt in out source destination 29062 2519K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED ... gateway:~# So when an ICMP packet such as a fragmentation-needed gets dropped it is because Netfilter cannot relate the packet to an established connection. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Saturday 13 March 2004 06:37 am, Tom Eastep wrote:> On Friday 12 March 2004 08:29 pm, Tom Eastep wrote: > > On Fri, 12 Mar 2004, Tom Eastep wrote: > > > On Fri, 12 Mar 2004, Ed Suominen wrote: > > > > Shorewall drops ICMP packets, so I had to add the following > > > > to /etc/shorewall/start: > > > > And by the way, the above is complete FUD.... > > I should elaborate. > > Shorewall relies on Netfilter''s connection tracking to handle ICMP (with > the exception of ''ping''). ICMP packets that are related to a connection are > expected to be handled by an ACCEPT rule that matches state ESTABLISHED and > state CONNECTED.That of course should have been RELATED. ------- -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net