Novell BorderManager 3.8 implements packet filtering in teh following ways:
Static packet filtering systems, such as the one used in earlier releases of Novell BorderManager 3.8, examine each packet that crosses the border between your private network (intranet) and the public network (Internet). Static packet filters parse the header field of each packet to identify a set of characteristics:
These characteristics determine whether the packet should be forwarded in accordance with fixed sets of outbound and inbound rules. Each filter set handles traffic coming to the firewall over a specific interface. Port numbers are used to filter traffic. Connections for various services, such as e-mail, FTP, Telnet, and so on, are denied by filtering the packets attempting to use that service or port number.
Firewalls based on static packet filtering are Network-layer devices that cannot process higher-layer information. They cannot check for application requests, nor can they keep track of application state information. A static packet filtering firewall cannot determine, simply by examining the header of an incoming packet, whether the packet is the first packet from an external client to an internal server or a response from an external server to an internal client. The level of protection provided by this type of firewall is limited.
Three advanced IP packet filtering features are introduced in this release of Novell BorderManager 3.8 to enhance firewall security:
TCP is a connection-oriented and reliable transport protocol. A connection is always initiated using the well-known three-way handshake, as follows:
Packet 1: Client -> ServerFlag: SYN
(The client wants to initiate a connection or synchronization.)
Packet 2: Server -> ClientFlags: SYN, ACK
(ACK: The client's connection request [SYN] is being acknowledged.)
Packet 3: Client -> ServerFlag: ACK
(ACK: The server's connection request [SYN] is being acknowledged.)
When TCP ACK bit filtering is enabled, only response packets (packets with the TCP ACK bit set) are allowed through. This effectively blocks all connection attempts from being initiated through this filter rule. TCP ACK bit filtering is often applied to all TCP inbound filters to prevent external hosts from initiating TCP connections to internal hosts; however, it should not be used in the following circumstances:
IMPORTANT: Stateful packet filtering is a superset of ACK bit filtering; however, they cannot be configured on the same filter.
Dynamic, or stateful, packet filtering, as implemented in Novell BorderManager 3.8, is designed to overcome the limitations of static packet filtering. Dynamic packet filtering tracks the outgoing packets it has allowed to pass and allows only the corresponding response packets to return. When the first packet is transmitted to the public network (Internet), a reverse filter is dynamically created to allow the response packet to return. To be counted as a response, the incoming packet must be from the host and port to which the outbound packet was sent.
Stateful packet filtering supports both connection and connectionless protocols (TCP, UDP, ICMP, and so on). Dynamic packet filtering monitors each connection and creates a temporary (time-limited) inbound filter exception for the connection. This allows you to block incoming traffic originating from a particular port number and address while still allowing return traffic from that same port number and address. The reverse filter is created by extracting the following packet information:
This information is stored in a table, which is compared against the reply. If an incoming message is not a reply to the original request, then it is dropped. This dynamically created filter set is used to determine the subsequent packet transfers until the connection is closed.
For connection-oriented protocols, such as TCP, the incoming (reverse) filter is created only when the first outgoing packet is detected. TCP ACK bit filtering is automatically enabled on the reverse filter to prevent any connection attempts by intruders from being initiated through that filter.
For ICMP, only the reply ICMP messages are allowed. All ICMP requests and ICMP redirect messages that attempt to return through a reverse filter are dropped. All other ICMP error reply messages are handled internally by stateful packet filtering.
Without stateful packet filtering, you would need to create two ICMP filters: one to allow an ICMP error message to go out and the other to allow it to return. With stateful packet filtering, you no longer need to create these ICMP filters. Without stateful packet filtering, you would need four sets of outbound and inbound filters (a total of at least eight separate filters) to establish FTP service.
The following four tables list the settings for each outbound and inbound filter.
With stateful packet filtering, you need only one outbound filter to establish FTP service, as shown in the following table.
Stateful packet filtering supports active FTP sessions by monitoring the PORT command. The client application sends this command over the FTP command channel (port 21) to signal the server on which port the client is listening for the server to open the data channel. Stateful packet filtering creates a temporary (time-limited) exception rule to allow the server to open the data channel (usually from port 20) to the client.
The difference between the passive FTP and the active FTP modes is that in the passive mode the client is allowed to open both the FTP command (port 21) and FTP data channels to the server. The passive FTP client always initiates the connection to the server's command and data channels, and the server only needs to signal the client on which port to connect back to the server's data port, which is normally above 1023.
Stateful packet filtering monitors the PASV command instead of the PORT command, and it creates a temporary (time-limited) exception filter to allow the client to communicate to the server on a designated high port (above 1023). With stateful packet filtering, all data and ICMP channels and the reverse path for the control channel are created (and eliminated) dynamically.
NOTE: For FTP service, you can choose which mode of FTP to allow: PORT, PASV, or ENABLED (which allows both PORT and PASV modes). Some companies do not allow internal users to use the active FTP (PORT) service.
When an IP datagram is fragmented, only the first packet has the complete header and transport information. All subsequent packets do not have the transport information, such as the port number. Formerly, it was safe to allow these fragments to pass through the firewall unchecked, as long as the first packet was dropped. The target host would eventually drop all subsequent packets, and reassembly could not be completed without the first packet.
This is no longer true today. Fragmented packets can be used to launch denial-of-service attacks by continuously flooding the network with fragment packets to consume network bandwidth and resources on the target host. Tiny fragments can also be used to bypass the firewall with overlapped fragments or by manipulating the fragment flags.
For example, if a firewall does not impose its security on packet fragments, then all packets with the fragment bit set can pass through unchecked. A nonfragmented packet with the more fragment bit set can be used to perform a port scan on the target host. To prevent such attacks, all fragments must be checked based on source and destination addresses, inbound and outbound interfaces, and a combination of TCP/IP and fragment flags.
To protect against fragment attacks with manipulation of the fragment flags, Novell BorderManager 3.8 has added automatic fragmented packet filtering. Fragmented packet filtering discards the first packet, which carries the complete header and transport information, and all subsequent fragmented packets if they have the same source and destination IP addresses and interfaces.
Defenses have been built into the Novell BorderManager 3.8 software for various attack programs that currently exist on the Internet. The following additional commands can also be enabled (or disabled) on the server console through SET commands under the COMMUNICATION category, or they can be included in your autoexec.ncf startup file. By default, they are set to ON.
When set to ON, all packets with a destination IP broadcast address are dropped.
The address 255 is used for broadcasts. A broadcast is a message that is sent to every system on the network. It is often easier to send a single broadcast message than it is to send individual datagrams to each host. Subnet broadcast messages are sent using an address that consists of the network address with 255 in the subnet number portion of the address. For example, if you are on network 140.120.8, the IP address 140.120.8.255 would be used for subnet broadcasts.
When set to ON, all local loopback packets are dropped.
This command has been added to support local applications that use the local loopback address to run locally on the server, such as the interfaces on the NetWare 5 software, NDPSTM Broker, and the ConsoleOne® software.
When set to ON, all packets with an IP header option enabled are dropped.
This command has been added to prevent the forwarding of packets to unauthorized hosts through the source routing option, which lists the IP addresses to which the packet must be forwarded.