SYNACK
Just Firewall It
Premium,Mod
join:2001-03-05
Venice, CA
 ·Comcast Formerly ..
Host:
Networking
Virtual Private Ne..
Netgear
ZyXEL
| reply to NetWatchMan
Re: Common Firewall False Positives
Thanks, this is a good summary. Typically, the firewall timeout is much longer that a few seconds (e.g. on the ZyWALL 10 it is a minute, but adjustable). I have encountered late DNS responses up to three minutes after the outgoing request.
(people with NAT router and NO ports forwarded will still see those with the LAN IP as destination. The NAT timeout is much longer than the firewall timeout and NAT still treats them as return traffic.)
Another case that often seem to create false positives in personal firewalls are broadcasted DHCP replies (from your-DHCP-server:67 to 255.255.255.255:68).
Quote from RFC 1541:Normally, DHCP servers and BOOTP relay agents attempt to deliver DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using unicast delivery. The IP destination address (in the IP header) is set to the DHCP 'yiaddr' address and the link-layer destination address is set to the DHCP 'chaddr' address. Unfortunately, some client implementations are unable to receive such unicast IP datagrams until the implementation has been configured with a valid IP address (leading to a deadlock in which the client's IP address cannot be delivered until the client has been configured with an IP address).
A client that cannot receive unicast IP datagrams until its protocol software has been configured with an IP address SHOULD set the BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or DHCPREQUEST messages that client sends. The BROADCAST bit will provide a hint to the DHCP server and BOOTP relay agent to broadcast any messages to the client on the client's subnet. A client that can receive unicast IP datagrams before its protocol software has been configured SHOULD clear the BROADCAST bit to 0. The BOOTP clarifications document discusses the ramifications of the use of the BROADCAST bit.
Note that personal firewall correctly ignore DHCP requests of other LAN users. Suppressing broadcast replies seems however not implemented in most personal firewalls.
In general, anything that contains a broadcast or multicast address (224.0.0.0-239.255.255.255) as destination should be summarily ignored!
Of course the firewall programmers are reluctant to add a little bit of AI to clean up/limit the logs, because every log generated justifies their existence to the user.
All this also underscores the need to discourage reporting by new users directly to ISPs. Your service is very valuable in this respect, because it can weed out all the meaningless garbage and focus on the rare gems that might require attention. |
