On the Internet, packet filtering is the process of passing or blocking packets at a network interface based on source and destination addresses, ports, or protocols. The process is used in conjunction withpacket mangling and Network Address Translation (NAT). Packet filtering is often part of a firewall program for protecting a local network from unwanted intrusion.
In a software firewall, packet filtering is done by a program called a packet filter. The packet filter examines the header of each packet based on a specific set of rules, and on that basis, decides to prevent it from passing (called DROP) or allow it to pass (called ACCEPT).
* see ACL
There are three ways in which a packet filter can be configured, once the set of filtering rules has been defined. In the first method, the filter accepts only those packets that it is certain are safe, dropping all others. This is the most secure mode, but it can cause inconvenience if legitimate packets are inadvertently dropped. In the second method, the filter drops only the packets that it is certain are unsafe, accepting all others. This mode is the least secure, but is causes less inconvenience, particularly in casual Web browsing. In the third method, if the filter encounters a packet for which its rules do not provide instructions, that packet can be quarantined, or the user can be specifically queried concerning what should be done with it. This can be inconvenient if it causes numerous dialog boxes to appear, for example, during Web browsing.
IP Packet Filter Firewall
An IP packet filter firewall allows you to create a set of rules that either discard or accept traffic over a network connection. The firewall itself does not affect this traffic in any way. Because a packet filter can only discard traffic that is sent to it, the device with the packet filter must either perform IP routing or be the destination for the traffic.
A packet filter has a set of rules with accept or deny actions. When the packet filter receives a packet of information, the filter compares the packet to your pre-configured rule set. At the first match, the packet filter either accepts or denies the packet of information. Most packet filters have an implicit deny all rule at the bottom of the rules file.
Packet filters usually permit or deny network traffic based on:
- Source and destination IP addresses
- Protocol, such as TCP, UDP, or ICMP
- Source and destination ports and ICMP types and codes
- Flags in the TCP header, such as whether the packet is a connect request
- Direction (inbound or outbound)
- Which physical interface the packet is traversing
All packet filters have a common problem: the trust is based on IP addresses. Although this security type is not sufficient for an entire network, this type of security is acceptable on a component level.
Most IP packet filters are stateless, which means they do not remember anything about the packets they previously process. A packet filter with state can keep some information about previous traffic, which gives you the ability to configure that only replies to requests from the internal network are allowed from the Internet. Stateless packet filters are vulnerable to spoofing since the source IP address and ACK bit in the packet’s header can be easily forged by attackers.
i5/OS™ lets you specify packet filter rules on interfaces and remote access service profiles. See the following topics for more details:Create IP filter rules and Remote Access Services: PPP connections. If you are using either an external packet filter firewall or packet filter rules on the i5/OS and your Universal Connection data passes through these filters, you must change the filter rules to allow the connection to the IBM® VPN Gateway as follows:
|IP filter rules||IP filter values|
|UDP inbound traffic filter rule||Allow port 4500 for VPN gateway addresses|
|UDP inbound traffic filter rule||Allow port 500 for VPN gateway addresses|
|UDP outbound traffic filter rule||Allow port 4500 for VPN gateway IP addresses|
|UDP outbound traffic filter rule||Allow port 500 for VPN gateway IP addresses|
|ESP inbound traffic filter rule||Allow ESP protocol (X’32’) for VPN gateway IP addresses|
|ESP outbound traffic filter rule||Allow ESP protocol (X’32’) for VPN gateway IP addresses|
For those Universal Connection applications that use HTTP and HTTPs for a transport, you must change the filter rules to allow connections to the IBM service destinations as follows:
|IP filter rules||IP filter values|
|TCP inbound traffic filter rule||Allow port 80 for all service destination addresses|
|TCP inbound traffic filter rule||Allow port 443 for all service destination addresses|
|TCP outbound traffic filter rule||Allow port 80 for all service destination addresses|
|TCP outbound traffic filter rule||Allow port 443 for all service destination addresses|
Part of changing the filter rules involves specifying an actual IBM VPN Gateway address. You can determine these addresses as described in Determining the IBM VPN Gateway addresses.
In addition, for HTTP and HTTPs traffic, part of changing the filter rules may involve specifying actual service destination addresses. You can determine these addresses as described in Determining the IBM Service Destination addresses.