- Building an Adaptable Infrastructure
- The Tao of Security: Simplicity
- Service Assessment
- Rules, Rulesets, and Rulebases
- Turning Security Policy into Security
Rules, Rulesets, and Rulebases
Generically, a rule is a set of criteria to match against a packet's properties and an action to take if the criteria and properties match. The criteria might be as vague and all-encompassing as "all packets," or it might be as specific as "any inbound fragmented TCP packet arriving on interface eth0, with the IP source routing option and TCP flag FIN set, destined for port 143 on host 192.168.7.25, originating from network 172.16.30.0/24."
The table of actions of a rule generally are composed of one of the possibilities shown in Table 2.
Table 2: Generic Firewall Rule Actions
|
Action |
Action Description |
|
accept |
Accept the packet, and pass or forward it on to its final destination. |
|
drop |
Drop the packet on the floor. Do not pass go. Do not even acknowledge the fact that the packet ever existed. Don't let the sending machine know the packet has been discarded. What packet? |
|
reject |
Do not accept the packet, but alert the sending machine that the packet has been rejected. This is normally done for TCP by sending a packet with the reset (RST) flag set. For UDP, because it has no concept of state, an ICMP is returned with the type destination port unreachable. |
|
Action Modifiers |
Modifier Description |
|
log |
Log the action applied to the packet and all pertinent information. This could be date/time, source/destination IP addresses, source/destination ports, rule number that triggered the action, and the action itself. Some log modifiers allow you to log part or all the packet itself for later inspection. |
|
map |
Rewrite the packet address and possibly port information. This is normally used to do Network Address Translation (NAT), or Network Address Port Translation (otherwise known as IP Masquerading). |
|
redirect |
Redirect the packet to reroute it from one IP address and port to another. This is useful for implementing transparent proxies. |
Rule Order
In most firewalls, the packets are inspected and matched against the rules in the rulebase in a sequential order. This means that the packet is compared to the first rule, and then the second rule, and then the third rule, and so on until a match is made. After the packet is matched to a rule, no additional actions or comparisons of the packet to the rulebase are made. One notable exception to this rule is the IP Filter firewall that is native to OpenBSD, FreeBSD, and NetBSD, but also available for Linux and several other UNIX systems. IP Filter normally processes packets in rule groups, and maintains status of the last matching rule. You have the flexibility in IP Filter to stop the process of matching further rules by using a special command in the rule. However, unless configured differently, the decision to drop or pass the packet is not made until the last rule in the group has been compared to the packet.
To better illustrate the difference, take the following sample rulebase:
block all inbound traffic pass all inbound traffic
For most firewalls, including CheckPoint's FireWall-1 and native Linux ipchains firewalling, the first rule to match applies to the packet. In the sample rulebase, an incoming packet matches rule #1. The packet is then immediately dropped by rule #1, and no further comparison takes place.
IP Filter and firewalls like it apply the action on the status of last matching rule. In the sample rulebase, the incoming packet matches rule #1. At this point, IP Filter sets the state for that packet to "matched rule #1, drop packet," but continues to compare the packet to the remaining rules in the ruleset group. The incoming packet in the example also matches rule #2, so the state of the packet is now "matched rule #2, pass packet." Because there is no rule #3, the packet is actually passed rather than blocked by IP Filter.
If you want to make IP Filter act more like other firewalls, you can apply the quick modifier to an individual rule. The quick modifier halts the packet comparison process of a ruleset on a match. The following IP Filter rules then mimic the actions of ipchains and FireWall-1:
block in quick all pass in all
Performance-Tuning Your Firewall
Knowing what traffic is passing through your firewall and how your firewall applies rulesets in a rulebase will help you tune your firewall for performance. For example, you can increase the performance of a firewall that processes a packet on the first matching rule by moving your most commonly matched rules to the beginning. In effect, this causes the firewall to do less work per packet. Firewall performance tuning should only be attempted after you have a working rulebase, and special attention should be made to the order. Do not misconfigure your firewall by placing accept rules before rules that would otherwise deny those packets. The importance of ordering rules in a rulebase is illustrated better in the examples in the following sections.
Remote Administration of Firewalls and DMZ Servers
SSH is a suite of applications that includes the ssh program, which replaces rlogin and telnet; and scp, which replaces rcp and ftp. Also included is sshd, which is the server side of the package. SSH encrypts all traffic (including passwords) to effectively eliminate eavesdropping, connection hijacking, and other network-level attacks. Additionally, SSH provides many secure tunneling capabilities. There are several implementations of the SSH suite and protocols. SSH is available in many implementations and formats:
SSH is a commercial product from SSH Communications Security (http://www.ssh.com/) that supports the Windows Win32 platforms (Windows 9x/NT/2000), Linux, and several UNIX flavors including MacOS X.
F-Secure SSH is another commercial implementation for cross-platform environments available from F-Secure Corporation. F-Secure SSH supports Windows Win32 platforms (Windows9x/NT/2000), Macintosh, and most major UNIX platforms. F-Secure SSH can be found at http://www.datafellows.com/products/ssh/.
OpenSSH is a free implementation maintained by the OpenBSD team at http://www.openssh.com. It supports SSH protocol versions 1.3, 1.5, and 2.0. It runs on many versions of UNIX and UNIX variants. Versions for other platforms can also be found there.
NiftyTelnet is a free software implementation of SSH available for MacOS. It includes support for scp and SSH protocol version 1.5. NiftyTelnet can be found at http://www.lysator.liu.se/~jonasw/freeware/niftyssh/.
MindTerm is a 100% pure Java implementation of SSH 1.5 from MindBright, an IT consulting company in Sweden. MindTerm runs on just about any platform that has a recent Java Runtime Environment. It can be executed on the command line or launched from within a browser. MindTerm can be found at http://www.mindbright.se/mindterm/.
With the various commercial and free implementations of SSH available, there is no reason not to install it on your servers. Unless you are using hardwired serial consoles to manage your servers, it would be otherwise irresponsible for an administrator to not be using SSH for remote administration.
Managing your Windows NT/2000 servers securely is slightly more difficult because of the primary "ease-of-use" feature: the GUI. There are a plethora of "remote desktop" utility programs available. The main difficulty you will have is in ensuring the security of the product, and gauging the time-to-fix from the vendor for any exposed exploits.
Windows NT 4.0 has a Terminal Server Edition, which allows remote clients to "natively" control desktop sessions. Unfortunately, the release of both service packs and hotfixes from Microsoft are delayed weeks to months behind the normal Windows NT 4.0 releases. The additional risk assumed during the delayed release window for intruders to take advantage of known exploits is high enough that you should not consider this option.
pcAnywhere from Network Associates is a commonly implemented remote control utility. It allows network traffic to be encrypted (through the Microsoft Crypto API), and file transfer so you can also replace FTP.
Obviously, you will have to evaluate your current remote management strategy and ensure that it makes sense to control your DMZ servers or remote servers at the colocation facility. Criteria to compare include the following:
File transfer capabilities. Transfer of files both to and from the remote server. Compression of files is useful, especially over lower bandwidth links. Delta file transfer will only transmit the changes to files, which can save time and bandwidth as well.
Data encryption. Encrypting the data over the wire is important; otherwise, intruders may be able to sniff account, password, or other critical information. Strong encryption of 3DES, TwoFish, Rijndael, Serpent, or CAST is preferred.
Configurability. Security through obscurity isn't security at all. But it certainly may help keep out the script kiddies. Look for the ability to reconfigure the listening ports for the remote administration service.
Many intruders use a remote administration tool known as Back Orifice 2000, found at http://www.bo2k.com/. It is normal for management and most administrators to feel uneasy about using a tool created by a group of hackers known as the Cult of the Dead Cow. However, the tool is quite flexible, easy on resources, and is open source. Utilizing a plug-in architecture, it can easily be expanded to support additional encryption technologies or authentication methods, for example. Because the source is available, it can easily be audited and patched for discovered vulnerabilities.