[Top] [Prev] [Next] [Bottom]
This chapter describes how to configure input and output packet filters. IP, IPX, and Service Advertising Protocol (SAP) rules are reviewed, and filter examples are given. You can also use the ChoiceNet application to filter IP packets by lists of sites rather than by individual IP addresses. For more information on ChoiceNet, see the ChoiceNet Administrator's Guide.
This chapter discusses the following topics:
Packet filters can increase security and decrease traffic on your network. Filters can be used to limit certain kinds of internetwork communications by permitting or denying the passage of packets through network interfaces. By creating appropriate filters, you can control access to specific hosts, networks, and network services.
Security on your network can be increased if you limit the authorized activities to certain hosts. For example, you can limit the DNS and SMTP interchange with the Internet to a well-secured host on your network. All Internet hosts can then access only this single server for those services. If you have several name servers or mail servers, you can use additional rules to allow access to these servers.
Ethernet filters control the types of packets that are allowed to pass through the local Ethernet port. Filters are set on asynchronous ports configured for hardwired operation when security with another network is an issue.
The packet filtering process analyzes the header information contained in each packet sent or received through a network interface. The header information is evaluated against a set of rules, which allow the packet to pass through the interface or cause the packet to be discarded. If a packet is discarded by a filter, an appropriate "ICMP unreachable" message is returned to the source address. This message provides immediate feedback to the user attempting the unauthorized access. Packets permitted or denied can optionally be logged to a host.
Filters can also be used for packet selection-for example, you can use a packet trace filter to do troubleshooting. The packets permitted by the ptrace filter are displayed, while packets not permitted by the filter are not displayed. For more information about the ptrace facility, see "Tracing Packets" on page 20-8.
Table 9-1 shows different filter options.
Filter Options
| |
|---|
|
Restricting packet traffic
|
Each user, location entry, and network hardwired port can be assigned both an input packet filter and an output packet filter. Having both input and output filters can decrease the number of rules needed and can provide better tuning of your security policy.
|
|
Restricting access based on source and destination address
|
You can create filters that evaluate both the source and destination addresses of a packet against a rule list. The number of significant bits used in IP address comparisons can be set, allowing filtering by a specific host, subnet, network number, or group of hosts whose addresses are within a given bit-aligned boundary.
|
|
Restricting access to particular protocols
|
Packets of certain protocols can be permitted or denied by a filter, including IPX, SAP, TCP, UDP, and ICMP packets.
|
|
Restricting access to network services
|
You can create filters that use the source and destination port numbers to control access to certain network services. The evaluation can be based upon whether the port number is less than, equal to, or greater than a specified value.
|
|
Restricting access based on TCP status
|
You can create filters that use the status of TCP connections as part of the rule set. This feature can allow network users to open connections to external networks without allowing external users access to the local network.
|
Filters are stored in a filter table in the PortMaster nonvolatile configuration memory. Filters can be created or modified at any time, and the changes are not applied to an active use of the filter. Each filter has a name of between 1 and 16 characters.
Each packet filter can contain three sets of rules: IP, IPX, and SAP. Within each set, the rules are numbered starting at one. Newly created packet filters contain zero rules, or an empty set of rules.
An empty set of rules is equivalent to the permit rule. If a filter contains one or more rules in the set, any packet not explicitly permitted by a rule is denied at the end of the rule set.
IP and IPX packet filters are attached to users, locations, Ethernet interfaces, or network hardwired ports as either input or output filters. SAP filters are attached as output filters only. The Ethernet interface filter is enabled as soon as the name of the input or output filter is set.
Input and output are defined relative to the PortMaster interface. As shown in Figure 9-1, an input filter is used on packets entering the PortMaster and an output filter is used on packets exiting the PortMaster.
Input and Output Filters
All packets entering a PortMaster through an interface with an input filter are evaluated against the rules in the filter. As soon as a packet matches a rule, the action specified by that rule is taken. If no rules match the specific packet, the packet is denied and is discarded. Whenever an IP packet is discarded, the PortMaster generates an "ICMP Host Unreachable" message back to the originator.
For interfaces with output filters attached, all packets exiting the interface are evaluated against the filter rules and only those packets permitted by the filter are allowed to exit the interface.
You construct a filter by creating the filter and then adding rules that permit or deny certain types of packets. Packets are evaluated in the same order as the rules are listed. Therefore, the rules representing the highest security concern should be specified early in the list of rules, followed by a rule limiting the volume of traffic.
User filters are attached to users configured for dial-in SLIP or PPP access. When a user makes a PPP or SLIP connection, the designated filters are attached to the network interface created for that connection.
Location filters are attached to dial-out locations using SLIP or PPP connections. When the connection is established to a remote site, the designated filters are attached to the network interface used.
You can attach filters for incoming packets, or for outgoing packets or for both. It is usually more effective to filter incoming packets so that you can protect the PortMaster itself.
For more detailed instructions on using the filter commands, see the Command Line Administrator's Guide.
To create a filter, use the following command:
You must then use the appropriate set command to add rules that permit or deny packets. See the following sections for instructions:
You can create a rule that filters IP packets according to their source and destination IP addresses. For more information on the command syntax for creating filters, see the Command Line Administrator's Guide.
To create an IP filter rule that filters by address, use the following command-entered on one line:
You can replace protocol Number with one of the following keywords:
Internet Control Message Protocol (ICMP) packets-commonly known as ping packets-report errors and provide other information about IP packet processing. You can filter ICMP packets by source and destination IP address, or by ICMP packet type. Packet types are identified in RFC 1700.
To create an ICMP filter rule, use the following command-entered on one line:
You can filter TCP packets by source and destination IP address, or by TCP port number. Appendix B, "TCP and UDP Ports and Services," lists port numbers commonly used for UDP and TCP port services. For a more complete list, see RFC 1700.
To create a TCP filter rule, use the following command-entered on one line:
You can filter UDP packets by source and destination IP address, or by UDP port number. Appendix B, "TCP and UDP Ports and Services," lists port numbers commonly used for UDP and TCP port services. For a more complete list, see RFC 1700.
To create a UDP filter rule, use the following command-entered on one line:
You can filter IPX packets in the following ways:
The Service Advertising Protocol (SAP) is an IPX protocol used over routers and servers that informs network clients of available network services and resources. SAP packets can be filtered only on output. You can filter SAP packets according to the following information about the server that is advertising the service via SAP:
To display the filter table, use the following command,:
To display a particular filter, use the following command:
To delete a filter, use the following command:
Because filters are very flexible, you must carefully evaluate the types of traffic that a specific filter permits or denies through an interface before attaching the filter. If possible, a filter should be tested from both sides of the filtering interface to verify that the filter is operating as you intended. Using the log keyword to log packets that match a rule to the loghost is useful when you are testing and refining IP filters.
Some of the following examples use the 192.168.1.0 network as the public network. You should substitute the number of your network or subnetwork if you use these examples.
Note ¯ 
Any packet that is not explicitly permitted by a filter is denied, except for the special case of a filter with no rules, which permits everything.
A simple filter can consist of the following rules:
Table 9-2 shows the description of the filter.
The filter in this example is designed as an input filter for a network hardwired port that connects to the Internet. You can use this filter for a dial-on-demand connection by attaching it to the location entry. The rules for the filter are set as follows:
Table 9-3 describes the filter.
Filters can be used to either permit or deny File Transfer Protocol (FTP) packets. You must understand how this protocol works before you develop FTP filters.
FTP uses TCP port 21 as a control channel, but it transfers data on another channel initiated by the FTP server from TCP port 20 (FTP-data). Therefore, if you want to allow your internal hosts to send out packets with FTP, you must allow external hosts to open an incoming connection from TCP port 20 to a destination port above 1023. Allowing this type of access to your network can be very risky if you are running Remote Procedure Call (RPC) or X Windows on the host from which you are transmitting FTP packets. As a result, many sites use FTP proxies or passive FTP, neither of which is discussed in this guide.
Consult Firewalls and Internet Security: Repelling the Wily Hacker by Cheswick and Bellovin and Building Internet Firewalls by Chapman and Zwicky for information on FTP proxies and passive FTP.
Likewise, if you want to allow external hosts to connect to your FTP server and transfer files, you must allow incoming connections to TCP port 21 on your FTP server and allow outgoing connections from TCP port 20 of your FTP server.
In the following examples, ftp.edu.com is the name of your FTP server and proxy.edu.com is the name of the host from which you allow outgoing FTP.
Caution ¯ 
This configuration is not recommended if you run any of the following protocols on any of the hosts from which you allow FTP access: NFS, X, RPC, or any other service that listens on ports above 1023.
The rules for the input filter are as follows:
The rules for the output filter are as follows:
If you allow any internal host to send out packets with FTP, replace proxy.edu.com/32 with 0.0.0.0/0 or your network_number/24. Take appropriate precautions to reduce the risk this configuration creates.
If the DNS name server for your domain is outside your local network, you should add the following rule to your input filter:
This rule permits DNS replies into your local network.
To permit incoming RIP packets, add the following rule to your input filter:
In the above example, rt.isp.net/32 is the other end of the Internet connection and gw.edu.com/32 is the local address of the connection.
To allow authentication queries used by some mailers and FTP servers, add the following rule to your input filter:
For more information about these types of queries, refer to RFC 1413.
To allow some other network to have complete access to your network, add the following rule. In the example below, 172.16.12.0 is granted full access to 192.168.1.0/24:
Caution ¯ 
Beware of associative trust. If you allow a network complete access to your network, you might unknowingly allow other networks complete access, as well. Any network that can access a network having complete access privileges to your network, also has access to your network. For example, if Network 1 trusts Network 2 and Network 2 trusts Network 3, then Network 1 trusts Network 3.
This example filter allows any kind of outgoing connection from the server, but blocks all incoming traffic to any host but your designated Internet server. This filter also limits incoming traffic on your Internet server to: SMTP, Network News Transfer Protocol (NNTP), DNS, FTP, and ICMP services.
Note ¯ 
Even if you have the latest versions of the daemons ftpd, httpd, and sendmail you may be vulnerable to attacks through these services. Check the latest CERT Coordination Center advisories, available on ftp.cert.org, for the vulnerabilities of these services.
If you use the following example, replace the name server with the IP address or hostname of your Internet server.
Table 9-4 describes the filter.
To log all packets that are denied add the following rule to the end of your filter:
Access filters enable you to restrict Telnet or rlogin connections to a specific host or network, or a list of hosts or networks. You can create an access filter that restricts user access to particular hosts.
Access filters work as follows:
-
1. The user specifies a host.
-
2. The host address is compared against the access filter.
-
3. If the address is permitted by the filter, the connection is established.
-
4. If the address is not permitted, the connection is denied unless access override is enabled.
If you want a user to be able to override a port's access filter, enable access override on that port. In this case, the process is as follows:
-
1. Access is denied by the access filter.
-
2. The user is prompted for a user name and password.
-
3. The user is verified by the user table or RADIUS.
-
4. The access filter defined for this user is used to determine if the user has permission to access the specified host.
To enable a user to override a port's access filter with his or her own filter, use the following command:
-
[Top] [Prev] [Next] [Bottom]
spider@livingston.com
Copyright © 1998, Livingston Enterprises, Inc. All rights
reserved.