Exerpts from the "Packet Filter Troubleshooting and Solutions Guide"
Articles and Tips: article
01 Jul 2001
Technical Information Document
#10018659
The Technical Information Document (TID) #10018659 contains the Packet Filter Troubleshooting and Solutions Guide, which gives information about the IP Filter Netware Loadable Module (NLM) version 3.1 (IPFLT31.NLM). The Guide provides some debugging information, functionality and tuning guidelines that may be used to address packet filtering issues within BorderManager.
This Network Troubleshooter column takes some exerpts from the Solutions Guide to give you a flavor of what's in it. To download the complete text from the support.novell.com URL, click on the link below:
http://support.novell.com/cgi-bin/search/searchtid.cgi?/10018659.htm
IPFLT31 Discard Debug Commands
Note: The debug commands and SET parameters are only listed here but are explained in the actual Guide material.
IPFLT31.NLM ships with various debug commands available to help customers troubleshoot their own packet filtering problems.
In most cases the problem lies with the fact that an application protocol is not being allowed through the firewall. The solution to the problem is to add an exception filter to allow the specific application traffic through. Such debug commands allow users to identify the various packet types on the network, and modify their filters accordingly to pass or block the traffic.
IPFLT31 exports a number of commands, which may be used to help debug packet filtering issues. These commands can be global i.e. turn on all debug settings, or individual i.e. turn on only a few required settings. Globally, the following list of commands exist:
ipflt_debug_help ipflt_debug_on ipflt_debug_off ipflt_route_debug
It is also possible to set individual filters on to troubleshoot filter problems at specific levels. Below is a list of individual set commands, and examples of how they may be used to troubleshoot problems.
Note: NOTE that the "Set Filter Debug=on" must first be set at the server console for any of these individual SET commands to have an effect.
When the SET commands are enabled, the system console will display the state of the packet as seen by the IPFLT31 module i.e. it will display a message indicating that the packet has been 'discarded' by the filter if the discard SET command is enabled, or 'forwarded' by the filter if the forward SET command is enabled. To see both discarded and forwarded packets for a specific protocol, both SET commands for that protocol must be enabled.
Set IP Discard Filter Debug=1/0 Set IP Forward Filter Debug=1/0 Set TCP Forward Filter Debug=1/0 Set TCP Discard Filter Debug=1/0 Set UDP Forward Filter Debug=1/0 Set UDP Discard Filter Debug=1/0 Set ICMP Forward Filter Debug=1/0 Set ICMP Discard Filter Debug=1/0 Set SKIP Forward Filter Debug=1/0 Set SKIP Discard Filter Debug=1/0 Set Others Forward Filter Debug=1/0 Set Others Discard Filter Debug=1/0 Set Route Filter Debug=1/0 Set Route Allow Filter Debug=1/0 Set Route Deny Filter Debug=1/0
Order Filters Actually Get Processed
IP Packet filtering calls take place within TCPIP.NLM under three separate scenario's:
a) When an incoming packet is processed and the final destination is our local IP address;
b) When an incoming packet is processed and the final destination is not our local address i.e. the packet needs to be routed by our stack and;
c) When an outgoing packet is being transmitted and our local IP address is the source IP address.
In each of the above cases, control is temporarily passed to the IPFLT31 module to verify whether the incoming, outgoing or forwarded packet must be allowed through, or discarded. The IPFLT31 modules sole job is to communicate to TCPIP.NLM that the packet should be allowed or discarded. TCPIP in turn proceeds with it's transmit, receive or forward routines if an allow is returned by IPFLT31, or drops the packet if the deny was returned.
IPFLT31.NLM's processing goes as follows:
1. Check if the "SET Filter Local Loopback Packets" command is enabled. As Netware 5 is running on top of TCPIP, all local loopback traffic must be allowed (return allow to TCPIP) even if there exists a deny ALL filter so that local service or application can still function normally. Forward only locally generated packets or loopback IP addresses. NOTE that source and destination IP address are always the same.
2. Check if the "SET Filter Packets With IP Header Options" is enabled and if so, drop all packets contain "options" in IP header by returning a discard to TCPIP.
3. Check for fragmentation attacks where the fragmentation fields are enabled (fragmentation offset not equal to zero, or the more fragments flag set in the IP header) and TCPs SYN/FIN/RST are also enabled. If this is the case, return a discard to TCPIP.
4. Check for illegal source IP addresses and return discard if found. Examples include 255.255.255.255, xxx.255.255.255, xxx.xxx.255.255, xxx.xxx.xxx.255, xxx.xxx.xxx.0, multicast. NOTE that it's ok to drop destination IP address of 0.0.0.0 but do not drop source of 0.0.0.0 (DHCP client). Some implementations of TCP/IP are vulnerable to packets that are crafted in a particular way (a SYN packet in which the source address and port are the same as the destination i.e. the LAND attack). In order to defend against LAND attack, we must drop all SYN packets in which both the source IP and port are the same as the destination i.e. spoofed. UDP can also be used to similar attack TCPIP stacks. NOTE that Novell's TCPIP stack does not suffer from this land attack.
5. Check if the "SET Filter Subnet Broadcast Packets" parameter is enabled and if so, drop all IP forwarding broadcast address with the xxx.xxx.xxx.255 or xxx.xxx.xxx.0.
6. Check if anyone is trying to spoof our local source IP address. This is done by first verifying if we're in forwarding or Local delivery mode (not transmit) and secondly, if the source IP address belongs to this router but the packet originated from external source (spoof). If this is the case, drop it.
7. Check if we're being 'smurf' attacked. The smurf attack relies on the router serving a large multi-access broadcast network to frame an IP broadcast address (such as 10.255.255.255) into a layer 2 broadcast frame (for Ethernet, FF:FF:FF:FF:FF:FF). Generally, with IP providers and IP applications as we know them today, this behavior should not be needed. It is recommended that directed-broadcasts be turned off via TCPCON, to suppress the effects of this attack. This is off by default.
8. Search the filter cache or filter database to see if the packet we're processing has a specific rule that could be applied to it. NOTE that at this stage, we have all the details about the packet (ip addresses, interface information, protocol, port numbers, etc) from TCPIP and we know the corresponding information from the configured filters. The filters are processed in the following order to check for hits:
a) Check the exception filter list to see whether a rule exists that matches our IP packet. If the default action is to DENY packets in the filter list, the exception list lists packets that should be allowed. If we get a hit here, send an allow message to TCPIP so that the stack continues processing the packet. If the default action is to ALLOW packets in the filter list, send a deny message to TCPIP so that it will drop the packet.
b) Assuming that the exception rule failed to provide a hit, the filters are then processed in sequence for a hit. If no filters match the packet being processed, we check for the default ACTION specified.
c) If the default ACTION specified is to PERMIT packets not in filter list, then an allow will be sent back to TCPIP to continue processing the packet. If on the other hand the default action is to DENY packets not in filter list, the deny message will be sent back to TCPIP so that it drops the packet.
Note: If a match exists, and the default policy is to permit packets in the filter list, we check to see if stateful filtering is enabled.
* If it is, we create a reverse filter and return allow to TCPIP * If it isn't return a discard message for TCPIP to drop the packet
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.