Jimmy's weblog

I’ve been pretty busy this week working on a presentation titled “Firewalls by example” for The University of Melbourne’s SecureCon conference tomorrow.

It’s a ninety minute presentation that will cover the features of Windows XP’s Internet Connection Firewall, Mac OS X’s (client and server) ipfw and Linux’s iptables. I will also be discussing typical traffic patterns for workstations and servers, and giving ipfw and iptables configuration files for two workstations and two servers. I would have like to also give examples for ICF but I will be presenting from my OS X notebook and Windows tends not to be too friendly for remote administration using the command line.

Overview:

This paper provides:

• An overview of firewalls: What is a firewall? Why would you want one? What types of firewalls exist? Where should you put your firewall? What can a firewall do?
• Windows XP Internet Connection Firewall (ICF): What features does it have? What changes to the firewall will be made in SP2? How is it configured?
• Mac OS X firewall for both Client and Server operating systems: What features does it have? What is the difference between the Client and Server version? How is it configured?
• Linux’s IP Tables firewall: What features does it have? How is it configured?
• Examples of typical traffic that a workstation or server machine might receive, and how you would block or let that traffic through your firewall
• Firewall rules for OS X and Linux that allow and disallow the typical traffic already mentioned

Introduction to firewalls

Firstly, what is firewall? A firewall is a program, or set of programs, that protects the resources of a network or computer from external visitors. Firewalls, which can also be known as packet filters, do this by inspecting data packets as they pass through the machine. Most firewalls can check packets for validity, source and destination addresses, the type of traffic and a range other characteristics.

So why would anyone want a firewall? The obvious answer is to stop unwanted traffic from reaching your computer. When you are using a firewall, it is your computer’s first point of contact for any network traffic. All traffic coming in and going out is passed to the firewall for inspection and processing. The firewall then decides what to do with the traffic.

Generally, a firewall will do one of four things with network traffic:

• Pass it on to either to the network or computer (depending on the direction of traffic) without modification.
• Modify the traffic and pass it on. The most common modification is changing the source address to prevent spoofing or for masquerading purposes.
• Deny the traffic and report back to the sending host
• Drop the traffic without notifying the sending host

This paper will not cover modifying traffic, which is more properly a routing function, but rather focus on the three other things a firewall can do to data packets.

Firewalls are typically referred to as either stateless, or stateful. Stateless firewalls view each packet as an isolated entity, completely unrelated to any other traffic. They make the decision on what to do with each piece of data, based only on information that can be obtained from the single packet. Stateful firewalls, on the other hand, are able to view traffic as a collection of data packets and make a decision based on traffic that has already passed through the firewall.

As an example, imagine a user sitting at a workstation who clicks on a link to www.google.com. Her browser makes a request to port 80 of the Google website which receives the request and returns data to the client on different ports, typically much higher than 1024.

A stateless firewall would have to be programmed to be open for outbound traffic on port 80 (no problems there), as well as being open to all inbound traffic on a range of higher ports (more of a security concern).

In contrast, a stateful firewall would simply need to be open for outbound traffic on port 80, and set to accept all inbound traffic for established connections. With this setting, it will keep track of outbound traffic and then allow inbound traffic that is in response to earlier requests.

Firewalls can be used to protect a single machine (host-based), or a network range of machines (perimeter based). This paper will be focus host-based firewalls but the principles and examples can easily be extended to perimeter-based firewalls. One of the major differences is that configuring a perimeter-based firewall will require more work when trying to understand the types of traffic that should be allowed through.

Generally, you will know what traffic your workstation or server can expect (and if you don’t, a few hours of experimentation should be enough) but if you are configuring a firewall for 100 / 1000 workstations or servers, this step is going to be a lot more involved. Imagine trying to figure out what traffic should be allowed or disallowed for a Fortune 500 company.

Windows XP firewall

Windows XP Internet Connection Firewall (ICF) is designed for use on individual workstations, though it can be used with Internet Connection Sharing to protect several computers, however it is not designed for complex roles protecting a number of computers. Microsoft’s stated goal is to “Provide a basic intrusion detection mechanism for Windows”.

ICF is a stateful firewall with rules designed to protect home and small business users from the most likely threats. Although ICF is currently off by default, in an attempt to increase Windows XP’s level of security, Microsoft has decided that Service Pack 2 (SP2) will turn ICF on by default, as well as making a number of other changes including adding boot time firewall protection to Windows.

In its original form, ICF does not offer any protection during boot. SP2 ICF will introduce “Boot time policies” which will allow traffic like DNS and DHCP through but will drop all other traffic. These policies will not be configurable, but will only last until Windows has fully booted.

Having the firewall on by default is likely to break some applications, and administrators should do some research before installing SP2 on all their computers (after the SP is released of course!). One example of application problems occurs with an Outlook / Exchange set up. When an email arrives, Exchange tries to send an RPC to the Outlook client to notify the user that mail has arrived. When ICS is running, this RPC connection will not get through, and users will be required to check their email manually.

ICF can be used on different connections, with different settings for each. You can have a wireless network connection to the Internet and block nearly all traffic, as well as a having a wired connection to your Local Area Network, and allow all traffic through. Remote Access Services like dialup and Virtual Private Networks can have their own customised firewall rules.

It is also possible to use group policies to switch off ICF in a domain setting where the assumption is that there will be a secure permitter firewall protecting the internal network. When using a dialup or broadband connection from home, ICF would be switched on, and when the computer joined the corporate domain, ICF would be switched off by group policy.

By default ICF will:

• Accept inbound packets that match an established connection
• Drop inbound packets that are not in response to established connections.
• Create a connection tracking entry for new outbound packets
• Perform structural checks on TCP packets and drops malformed ones

ICF does very limited outbound packet inspections and will be of no use if the computer is already compromised. Outbound inspection is limited to preventing IP address spoofing by dropping all spoofed packets.

These rules are designed for normal workstation activities such as web browsing and email, and will need to be modified for running servers where other clients initiate the connections. Note that the firewall is not designed for use on server systems.

• W32.Mydoom.A – ICF will have no effect on the propagation of viruses transmitted via email. In this case, it will block the backdoor port that Mydoom opens on infected computers.
• W32.MSBlaster.Worm – Spread via a port 135 exploit and would have been stopped by ICF which blocks all non-established inbound traffic.
• W32.Sobig.F – Spread by email and ICF will have no effect on propagation.
• W32.Bugbear – Also spread by email.

Mac OS X firewall

Mac OS X’s firewall is included in both the Client and Server version of the operating system, though with different configuration interfaces. OS X is based on BSD so it is not too surprising that the firewall is based on a BSD application, in this case ipfw. By default, ipfw is stateless, but by using the option “keep-state”, it can be made to be stateful.

ipfw has a command line interface that is used to enter firewall rules in the format of:

[prob match_probability] action [log [logamount number]] proto from src to dst [interface-spec] [options]

Each packet can be filtered based on:

• Transmit and receive interface, referenced by name or address
• Direction of packet, whether inbound or outbound
• Source and destination, specified by address or netmask
• Source and destination port
• Protocol, generally one of TCP, UDP or ICMP

“prob” can allow matches to be made based on a probability and is not used much in practice. It could be useful if you wanted to drop packets randomly for some reason.

“action” can be one of:

• allow – Allow packets matching this rule, and terminate parsing of rules. You can also use pass, permit and accept as aliases for allow.
• deny – Discard packets matching this rule and terminate. Drop can be used as an alias for deny.
• reject – Discard packet and send a host unreachable ICMP packet in return. This is used commonly with the Linux firewall but is deprecated in ipfw.
• unreach – Discard packets and send an ICMP unreachable notice with a code number, where code is a number from 0 – 255 or an alias for one of the code numbers. unreach is now used in place of reject.
• check-state – Checks the packet against a dynamic rule. If a match is found, the search terminates.

There are other actions, but these are the most common ones. Typing “man ipfw” at an OS X command prompt will bring up the manual page listing all the options.

“proto” should be an IP protocol specified either by number or name (as listed in /etc/protocols). Using “ip” or “all” here will match all protocols.

“from” and “to” refer to IP addresses and may be specified as:

• A single IP number which will only match the exact number.
• An IP number with a mask in the form of 1.2.3.4/24, which will match 1.2.3.0 through to 1.2.3.255.
• An IP number with a mask in the form of 1.2.3:255.255.240.0, which will match 1.2.0.0 through to 1.2.15.255.

“not” can be used to match the inverse, and a port number or range may be included when matching the TCP and UDP protocols.

“interface-spec” can include:

• in – To only match incoming packets
• out – To only match outgoing packets
• via – In conjunction with an interface, to match packets going through that interface

OS X uses ipfw without modification, though it does offer a GUI interface to configure the firewall. The Client operating system includes a basic interface for configuration of common services, while the Server version offers a wide variety of configuration options including:

• One click to allow or deny of common network services
• The ability to apply rules to groups of related machines
• Easy modification of logging rules and locations

Linux firewall

As an operating system that has gained a strong market share in the server environment, firewall applications have always been important to Linux, and Linux kernels have had packet filtering since the 1.1 series.

In 1994, Alan Cox created ipfwadm, the first firewall for Linux, which was based on ipfw from BSD and was enhanced for Linux 2.0. BSD has a reputation for conservative development and is still using ipfw many years later while Linux is now on to its second replacement. The second generation, ipchains, was introduced to Linux 2.2 in 1998, and iptables took its place during 1999, in the 2.4 kernel series.

iptables is included by default in all Linux distributions and is a sophisticated, stateful firewall which can be used on workstations and servers alike. It is far more powerful than Windows XP’s ICF, and (in my opinion) more powerful than BSD / OS X’s ipfw, though it is less user friendly than both.

The function of the iptables tool is to add rules to the ruleset, examine them, and if necessary, modify them. The rulesets themselves are kept in memory by the kernel and are not directly editable.

The syntax of the iptables command is:

iptables [command-type] [pattern-match-options] –j [target]

“command-type” can include

• -L – List rules in all chains.
• -F [chain] – Flush all rules from [chain]
• -P [chain] – Set policy for [chain]. The policy can be “ACCEPT” or “DROP”
• -A [chain] – Append a rule to [chain].
• -D [chain] [rulenum] – Delete rule [rulenum] from chain [chain]
• -N [chain] – Create a new chain with name [chain]

“pattern-match-options” can include

• -p [protocol] – Where protocol is tcp, udp or icmp.
• -d [address / mask], -s [address / mask] – Specifies the destination / source name or address of the packet.
• –dport [port], –sport [port] – The destination / source port (can also be designated by protocol).
• -i [interface], -o [interface] – Specifies which input / output interface the rule applies to ( eth0 ,   ppp0 ).
• –icmp-type [typename] – Allows specification of the ICMP type, which can be a numeric ICMP type, or one of the ICMP type names.

Note that most these patterns can include ! as a negation.

The rulesets used by iptables are organised in a series of tables, each of which consists of a number of chains. By far the most important table is the filter table. As the name suggests, this is where the rules for filtering are kept. Because of its importance, it is the default table and need not be referred to explicitly. All commands refer to this table unless otherwise stated.

A chain is simply a list of rules, read from the top down. This simple organisation makes things easier because, unlike some other tools, there is no need to worry about which rule takes precedence – rules are simply applied in the order they are listed.

iptables has three built-in chains. These have the self-explanatory titles INPUT, OUTPUT and FORWARD. When a packet arrives at a network interface, the rules in the INPUT chain are applied one by one in order. Each rule describes a particular pattern that might be present in a header such as from an address range, to an address, source sport, destination port or the like.

If the pattern matches a certain action is specified and no further rules are read. If a pattern match does not occur, the next rule is considered. The order in which rules are listed is therefore critical: once a packet has been accepted or rejected, rules lower down on the list will not be considered.

In a similar fashion, the OUTPUT chain examines packets being sent from the machines. The FORWARD chain is relevant only when the computer is being used as a router, as packets passing through a machine are examined by this ruleset.

For simple firewalls, these three built-in chains are normally sufficient. When the rulesets are getting large, it is generally useful to set up additional user defined chains. These can be considering to be subchains.

For example, the main input chain might examine incoming packets to see if they involve a particular protocol, in this case ftp. If they do, the action would be to pass the packets to a user defined ftp-packet chain, which would contain a series of patterns relevant to ftp packets. If a match is found, the indicated action is taken and processing stops. If the end of the subchain is reached without match, a return is made to the next rule in the calling chain.

Use defined chains have two advantages. The first is that they provide a clearer view of the rulesets by allowing rules dealing with similar packet types to be grouped together, which increases the likelihood of a coherent and effective final firewall. The second is that user of these rulesets increases processing efficiency.

In the above example, only one step is required to determine that a packet is ftp. It can then be examined by an ftp specific ruleset. Time will not be wasted attempting to compare it with rules designed for other types of packets.

Typical traffic

The easiest workstation policy allows all outbound traffic, all established inbound traffic and blocks all other inbound traffic. This is what the Windows XP and the OS X Client firewall do by default when they are turned on. It is possible to selectively block outbound traffic to help contain virus infected machines, but this requires a high degree of understanding of how the workstation is used and can be difficult unless network use is restricted.

Several third party Windows firewalls attempt to overcome this problem by asking you what to do each time an outbound connection is attempted. You can choose to allow once, allow permanently, disallow once or disallow permanently for each application. After a few hours’ use of the computer, the firewall has enough knowledge of your typical usage patterns that it does not need to keep questioning you.

The workstation firewall policy previously described will obviously not work well on a server computer. Servers are expected to allow inbound traffic and to respond to connections attempted on a range of ports. Configuration is made easier by the fact that you are more likely to have knowledge of which ports your server should be listening and responding on.

Firewall rule examples

Below are ipfw and iptables firewall rules for four hypothetical computers.

• W1 – A workstation connected to the Internet via modem. All outbound and established inbound connections are permitted while other traffic is dropped.
• W2 – A workstation connected to the Internet via an ethernet connection. Only web browsing, email, as well as essential network traffic like DHCP are allowed outbound, and inbound connections are limited to established connections and SSH for workstation management.
• S1 – A web and file server connected via a single ethernet device. Inbound FTP, SSH, HTTP, HTTPS, SMB, AFP and established connections are allowed while outbound connections are not restricted.
• S2 – An email server connected via dual ethernet devices. The server allows inbound connections for SSH, SMTP, POP3, IMAP, POP3 via SSL, IMAP via SSL and established traffic. Outbound connections are not restricted.

The firewall rules also include rules to allow pings and several other types of essential traffic.

ipfw

To create an ipfw firewall, you should save your firewall rules in /etc/ipfw.conf and load them with the command ipfw –q /etc/ipfw.conf.

OS X server will allow you to use serveradmin start ipfilter and serveradmin stop ipfilter to start and stop the firewall.

ipfw list displays a list of the current rulesets, including any ones created dynamically to retain state.

W1 firewall configuration

# Flush all rules
flush

# Add stateful behaviour and allow established connections
add check-state 

# Allow all loopback (lo0) traffic
# Drop all traffic to 127/8 that doesn't use lo0
add allow ip from any to any via lo0
add reject ip from any to 127.0.0.0/8 

# Allow all outbound packets via the dialup interface
add allow all from any to any out keep-state via ppp0 

# Reject and log all remaining traffic
add reject log all from any to any

W2 firewall configuration

# Flush all rules
flush

# Add stateful behaviour and allow established connections
add check-state 

# Allow all loopback (lo0) traffic
# Drop all traffic to 127/8 that doesn't use lo0
add allow ip from any to any via lo0
add reject ip from any to 127.0.0.0/8 

# Allow DHCP
add allow udp from any 67-68 to any 67-68 

# Allow DNS
add allow udp from any to any 53 out keep-state
add allow tcp from any to any 53 out setup keep-state 

# Allow HTTP, HTTPS
add allow tcp from any to any http out setup keep-state
add allow tcp from any to any https out setup keep-state 

# Allow inbound and outbound SSH
add allow tcp from any to any ssh keep-state 

# Allow a wide variety of email access
add allow tcp from any to any smtp out setup keep-state
add allow tcp from any to any pop3 out setup keep-state
add allow tcp from any to any imap out setup keep-state
add allow tcp from any to any pop3s out setup keep-state
add allow tcp from any to any imaps out setup keep-state 

# Drop and log all remaining traffic
add reject log all from any to any

S1 firewall configuration

# Flush all rules
flush 

# Add stateful behaviour and allow established connections
add check-state 

# Allow all loopback (lo0) traffic
# Drop all traffic to 127/8 that doesn't use lo0
add allow ip from any to any via lo0
add drop ip from any to 127.0.0.0/8 

# Allow DNS
add allow udp from any to any 53 out keep-state
add allow tcp from any to any 53 out keep-state 

# Allow NTP
add allow udp from any to any ntp out keep-state 

# Allow inbound and outbound SSH
add allow tcp from any to any ssh keep-state 

# Allow HTTP, HTTPS
add allow tcp from any to any http
add allow tcp from any to any https 

# Allow SMB file sharing to 15.20. range
add allow udp from 15.20.0.0/16 to any 137-138
add allow tcp from 15.20.0.0/16 to any 139
add allow tcp from 15.20.0.0/16 to any 445 

# Allow Apple file sharing to 15.20. range
add allow udp from 15.20.0.0/16 to any 548
add allow tcp from 15.20.0.0/16 to any 548 

# Allow all outbound traffic
add allow all from any to any out keep-state 

# Reject and log all remaining traffic
add reject log all from any to any

S2 firewall configuration

# Flush all rules
flush 

# Add stateful behaviour and allow established connections
add check-state 

# Allow all loopback (lo0) traffic
# Reject all traffic to 127/8 that doesn't use lo0
add allow ip from any to any via lo0
add reject ip from any to 127.0.0.0/8 

# Allow DNS
add allow udp from any to any 53 out keep-state
add allow tcp from any to any 53 out keep-state 

# Allow NTP
add allow udp from any to any ntp out keep-state 

# Allow inbound and outbound SSH
add allow tcp from any to any ssh keep-state 

# Allow inbound access to smtp via first ethernet device
add allow tcp from any to any smtp in via en0 

# Allow access to other mail services via second ethernet device
add allow tcp from any to any pop3 in via en1
add allow tcp from any to any imap in via en1
add allow tcp from any to any pop3s in via en1
add allow tcp from any to any imaps in via en1 

# Allow all outbound traffic
add allow all from any to any out keep-state 

# Reject and log all remaining traffic
add reject log all from any to any

IP Tables

iptables can be started using the command service iptables start and by default reads its configuration from the /etc/sysconfig/iptables file. This file also needs *filter at the beginning and COMMIT as the last line.

To view the current rules, type iptables –L.

Workstation 1

# Flush chains
-F 

# Allow all loopback (lo0) traffic
# Drop all traffic to 127/8 that doesn't use lo0
-A INPUT –i lo –j ACCEPT
-A INPUT –i ! lo –d 127.0.0.0/8 REJECT 

# Allow all established inbound traffic
-A INPUT –m state --state ESTABLISHED,RELATED –j ACCEPT 

# Allow all outgoing traffic
-A OUTPUT –j ACCEPT 

# Drop and log all other traffic
-A INPUT –j REJECT --log
-A FORWARD –j REJECT --log

Workstation 2

# Flush chains
-F 

# Allow all loopback (lo0) traffic
# Drop all traffic to 127/8 that doesn't use lo0
-A INPUT –i lo –j ACCEPT
-A INPUT –i ! lo –d 127.0.0.0/8 –j REJECT 

# Allow all established inbound traffic
-A INPUT –m state --state ESTABLISHED,RELATED –j ACCEPT 

# Allow all outgoing traffic
-A OUTPUT –j ACCEPT 

# Drop and log all other traffic
-A INPUT -j LOG
-A INPUT -j REJECT
-A FORWARD -j LOG
-A FORWARD -j REJECT

Server 1

# Allow all loopback (lo0) traffic
# Drop all traffic to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT
-A INPUT -i ! lo -d 127.0.0.0/8 -j REJECT 

# Accept all established connections
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT 

# Accept all SSH and Web server connections
-A INPUT -p tcp --dport 22 -j ACCEPT
-A INPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT 

# Samba (accept connections from 15.20.)
-A INPUT -p udp -s 15.20.0.0/16 --dport 137:138 -j ACCEPT
-A INPUT -p tcp -s 15.20.0.0/16 --dport 139 -j ACCEPT
-A INPUT -p tcp -s 15.20.0.0/16 --dport 445 -j ACCEPT 

# AFP (accept connections from 15.20.)
-A INPUT -p udp -s 15.20.0.0/16 --dport 548 -j ACCEPT
-A INPUT -p tcp -s 15.20.0.0/16 --dport 548 -j ACCEPT 

# Allow all outbound traffic
-A OUTPUT -j ACCEPT 

# Reject and log all other inbound
-A INPUT -j LOG
-A INPUT -j REJECT
-A FORWARD -j LOG
-A FORWARD -j REJECT

Server 2

# Allow all loopback (lo0) traffic
# Drop all traffic to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT
-A INPUT -i ! lo -d 127.0.0.0/8 -j REJECT 

# Accept all established connections
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT 

# Accept inbound SSH connections
-A INPUT -p tcp --dport 22 -j ACCEPT 

# Allow inbound access to smtp via first ethernet device
-A INPUT –p tcp --dport smtp –i eth0 –j ACCEPT 

# Allow access to other mail services via second ethernet device
-A INPUT –p tcp --dport pop3 –i eth1 –j ACCEPT
-A INPUT –p tcp --dport imap –i eth1 –j ACCEPT
-A INPUT –p tcp --dport pop3s –i eth1 –j ACCEPT
-A INPUT –p tcp --dport imap2 –i eth1 –j ACCEPT 

# Allow all outbound traffic
-A OUTPUT -j ACCEPT 

# Reject and log all other inbound
-A INPUT -j LOG
-A INPUT -j REJECT
-A FORWARD -j LOG
-A FORWARD -j REJECT