5 ***Contributed by Gary Palmer and Alex Nash. ***
\r
7 Firewalls are an area of increasing interest for people who are connected to the Internet, and are even finding applications on private networks to provide enhanced security. This section will hopefully explain what firewalls are, how to use them, and how to use the facilities provided in the DragonFly kernel to implement them.
\r
9 **Note:** People often think that having a firewall between your internal network and the ***Big Bad Internet*** will solve all your security problems. It may help, but a poorly set up firewall system is more of a security risk than not having one at all. A firewall can add another layer of security to your systems, but it cannot stop a really determined cracker from penetrating your internal network. If you let internal security lapse because you believe your firewall to be impenetrable, you have just made the crackers job that much easier.
\r
11 ### 10.7.1 What Is a Firewall?
\r
13 There are currently two distinct types of firewalls in common use on the Internet today. The first type is more properly called a ***packet filtering router***. This type of firewall utilizes a multi-homed machine and a set of rules to determine whether to forward or block individual packets. A multi-homed machine is simply a device with multiple network interfaces. The second type, known as a ***proxy server***, relies on daemons to provide authentication and to forward packets, possibly on a multi-homed machine which has kernel packet forwarding disabled.
\r
15 Sometimes sites combine the two types of firewalls, so that only a certain machine (known as a ***bastion host***) is allowed to send packets through a packet filtering router onto an internal network. Proxy services are run on the bastion host, which are generally more secure than normal authentication mechanisms.
\r
17 DragonFly comes with a kernel packet filter (known as IPFW), which is what the rest of this section will concentrate on. Proxy servers can be built on DragonFly from third party software, but there is such a variety of proxy servers available that it would be impossible to cover them in this section.
\r
19 #### 10.7.1.1 Packet Filtering Routers
\r
21 A router is a machine which forwards packets between two or more networks. A packet filtering router is programmed to compare each packet to a list of rules before deciding if it should be forwarded or not. Most modern IP routing software includes packet filtering functionality that defaults to forwarding all packets. To enable the filters, you need to define a set of rules.
\r
23 To decide whether a packet should be passed on, the firewall looks through its set of rules for a rule which matches the contents of the packet's headers. Once a match is found, the rule action is obeyed. The rule action could be to drop the packet, to forward the packet, or even to send an ICMP message back to the originator. Only the first match counts, as the rules are searched in order. Hence, the list of rules can be referred to as a ***rule chain***.
\r
25 The packet-matching criteria varies depending on the software used, but typically you can specify rules which depend on the source IP address of the packet, the destination IP address, the source port number, the destination port number (for protocols which support ports), or even the packet type (UDP, TCP, ICMP, etc).
\r
27 #### 10.7.1.2 Proxy Servers
\r
29 Proxy servers are machines which have had the normal system daemons ( **telnetd** , **ftpd** , etc) replaced with special servers. These servers are called ***proxy servers***, as they normally only allow onward connections to be made. This enables you to run (for example) a proxy **telnet** server on your firewall host, and people can **telnet** in to your firewall from the outside, go through some authentication mechanism, and then gain access to the internal network (alternatively, proxy servers can be used for signals coming from the internal network and heading out).
\r
31 Proxy servers are normally more secure than normal servers, and often have a wider variety of authentication mechanisms available, including ***one-shot*** password systems so that even if someone manages to discover what password you used, they will not be able to use it to gain access to your systems as the password expires immediately after the first use. As they do not actually give users access to the host machine, it becomes a lot more difficult for someone to install backdoors around your security system.
\r
33 Proxy servers often have ways of restricting access further, so that only certain hosts can gain access to the servers. Most will also allow the administrator to specify which users can talk to which destination machines. Again, what facilities are available depends largely on what proxy software you choose.
\r
35 ### 10.7.2 What Does IPFW Allow Me to Do?
\r
37 IPFW, the software supplied with DragonFly, is a packet filtering and accounting system which resides in the kernel, and has a user-land control utility, [ipfw(8)](http://leaf.dragonflybsd.org/cgi/web-man?command#ipfw§ion8). Together, they allow you to define and query the rules used by the kernel in its routing decisions.
\r
39 There are two related parts to IPFW. The firewall section performs packet filtering. There is also an IP accounting section which tracks usage of the router, based on rules similar to those used in the firewall section. This allows the administrator to monitor how much traffic the router is getting from a certain machine, or how much WWW traffic it is forwarding, for example.
\r
41 As a result of the way that IPFW is designed, you can use IPFW on non-router machines to perform packet filtering on incoming and outgoing connections. This is a special case of the more general use of IPFW, and the same commands and techniques should be used in this situation.
\r
43 ### 10.7.3 Enabling IPFW on DragonFly
\r
45 As the main part of the IPFW system lives in the kernel, you will need to add one or more options to your kernel configuration file, depending on what facilities you want, and recompile your kernel. See "Reconfiguring your Kernel" ([kernelconfig.html Chapter 9]) for more details on how to recompile your kernel.
\r
47 **Warning:** IPFW defaults to a policy of `deny ip from any to any`. If you do not add other rules during startup to allow access, ***you will lock yourself out*** of the server upon rebooting into a firewall-enabled kernel. We suggest that you set `firewall_type=open` in your `/etc/rc.conf` file when first enabling this feature, then refining the firewall rules in `/etc/rc.firewall` after you have tested that the new kernel feature works properly. To be on the safe side, you may wish to consider performing the initial firewall configuration from the local console rather than via **ssh** . Another option is to build a kernel using both the `IPFIREWALL` and `IPFIREWALL_DEFAULT_TO_ACCEPT` options. This will change the default rule of IPFW to `allow ip from any to any` and avoid the possibility of a lockout.
\r
49 There are currently four kernel configuration options relevant to IPFW:
\r
51 `options IPFIREWALL`:: Compiles into the kernel the code for packet filtering.`options IPFIREWALL_VERBOSE`:: Enables code to allow logging of packets through [syslogd(8)](http://leaf.dragonflybsd.org/cgi/web-man?command#syslogd§ion8). Without this option, even if you specify that packets should be logged in the filter rules, nothing will happen.`options IPFIREWALL_VERBOSE_LIMIT=10`:: Limits the number of packets logged through [syslogd(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=syslogd§ion=8) on a per entry basis. You may wish to use this option in hostile environments in which you want to log firewall activity, but do not want to be open to a denial of service attack via syslog flooding.
\r
52 When a chain entry reaches the packet limit specified, logging is turned off for that particular entry. To resume logging, you will need to reset the associated counter using the [ipfw(8)](http://leaf.dragonflybsd.org/cgi/web-man?command#ipfw§ion8) utility:
\r
56 Where 4500 is the chain entry you wish to continue logging.`options IPFIREWALL_DEFAULT_TO_ACCEPT`:: This changes the default rule action from ***deny*** to ***allow***. This avoids the possibility of locking yourself out if you happen to boot a kernel with `IPFIREWALL` support but have not configured your firewall yet. It is also very useful if you often use [ipfw(8)](http://leaf.dragonflybsd.org/cgi/web-man?command#ipfw§ion8) as a filter for specific problems as they arise. Use with care though, as this opens up the firewall and changes the way it works.
\r
58 ### 10.7.4 Configuring IPFW
\r
60 The configuration of the IPFW software is done through the [ipfw(8)](http://leaf.dragonflybsd.org/cgi/web-man?command#ipfw§ion8) utility. The syntax for this command looks quite complicated, but it is relatively simple once you understand its structure.
\r
62 There are currently four different command categories used by the utility: addition/deletion, listing, flushing, and clearing. Addition/deletion is used to build the rules that control how packets are accepted, rejected, and logged. Listing is used to examine the contents of your rule set (otherwise known as the chain) and packet counters (accounting). Flushing is used to remove all entries from the chain. Clearing is used to zero out one or more accounting entries.
\r
64 #### 10.7.4.1 Altering the IPFW Rules
\r
66 The syntax for this form of the command is:
\r
68 `ipfw` [-N] command [index] action [log] protocol addresses [options]
\r
70 There is one valid flag when using this form of the command:
\r
72 -N:: Resolve addresses and service names in output.
\r
74 The ***command*** given can be shortened to the shortest unique form. The valid ***commands*** are:
\r
76 add:: Add an entry to the firewall/accounting rule listdelete:: Delete an entry from the firewall/accounting rule list
\r
78 Previous versions of IPFW used separate firewall and accounting entries. The present version provides packet accounting with each firewall entry.
\r
80 If an ***index*** value is supplied, it is used to place the entry at a specific point in the chain. Otherwise, the entry is placed at the end of the chain at an index 100 greater than the last chain entry (this does not include the default policy, rule 65535, deny).
\r
82 The `log` option causes matching rules to be output to the system console if the kernel was compiled with `IPFIREWALL_VERBOSE`.
\r
84 Valid ***actions*** are:
\r
86 reject:: Drop the packet, and send an ICMP host or port unreachable (as appropriate) packet to the source.allow:: Pass the packet on as normal. (aliases: `pass`, `permit`, and `accept`)deny:: Drop the packet. The source is not notified via an ICMP message (thus it appears that the packet never arrived at the destination).count:: Update packet counters but do not allow/deny the packet based on this rule. The search continues with the next chain entry.
\r
88 Each ***action*** will be recognized by the shortest unambiguous prefix.
\r
90 The ***protocols*** which can be specified are:
\r
92 all:: Matches any IP packeticmp:: Matches ICMP packetstcp:: Matches TCP packetsudp:: Matches UDP packets
\r
94 The ***address*** specification is:
\r
96 from `***address/mask***` [`***port***`] to `***address/mask***` [`***port***`] [via `***interface***`]
\r
98 You can only specify `***port***` in conjunction with ***protocols*** which support ports (UDP and TCP).
\r
100 The `via` is optional and may specify the IP address or domain name of a local IP interface, or an interface name (e.g. `ed0`) to match only packets coming through this interface. Interface unit numbers can be specified with an optional wildcard. For example, `ppp*` would match all kernel PPP interfaces.
\r
102 The syntax used to specify an `***address/mask***` is:
\r
111 `***address***`/`***mask-bits***`
\r
117 `***address***`:`***mask-pattern***`
\r
120 A valid hostname may be specified in place of the IP address. ' **mask-bits** ' is a decimal number representing how many bits in the address mask should be set. e.g. specifying `192.216.222.1/24` will create a mask which will allow any address in a class C subnet (in this case, `192.216.222`) to be matched. ' **mask-pattern** ' is an IP address which will be logically AND'ed with the address given. The keyword `any` may be used to specify ***any IP address***.
\r
122 The port numbers to be blocked are specified as:
\r
124 `***port***` [,`***port***` [,`***port***` [...]]]
\r
126 to specify either a single port or a list of ports, or
\r
128 `***port***`-`***port***`
\r
130 to specify a range of ports. You may also combine a single range with a list, but the range must always be specified first.
\r
132 The ***options*** available are:
\r
134 frag:: Matches if the packet is not the first fragment of the datagram.in:: Matches if the packet is on the way in.out:: Matches if the packet is on the way out.ipoptions `***spec***`:: Matches if the IP header contains the comma separated list of options specified in `***spec***`. The supported IP options are: `ssrr` (strict source route), `lsrr` (loose source route), `rr` (record packet route), and `ts` (time stamp). The absence of a particular option may be specified with a leading `!`.established:: Matches if the packet is part of an already established TCP connection (i.e. it has the RST or ACK bits set). You can optimize the performance of the firewall by placing ***established*** rules early in the chain.setup:: Matches if the packet is an attempt to establish a TCP connection (the SYN bit is set but the ACK bit is not).tcpflags `***flags***`:: Matches if the TCP header contains the comma separated list of `***flags***`. The supported flags are `fin`, `syn`, `rst`, `psh`, `ack`, and `urg`. The absence of a particular flag may be indicated by a leading `!`.icmptypes `***types***`:: Matches if the ICMP type is present in the list `***types***`. The list may be specified as any combination of ranges and/or individual types separated by commas. Commonly used ICMP types are: `0` echo reply (ping reply), `3` destination unreachable, `5` redirect, `8` echo request (ping request), and `11` time exceeded (used to indicate TTL expiration as with [traceroute(8)](http://leaf.dragonflybsd.org/cgi/web-man?command#traceroute§ion8)).
\r
136 #### 10.7.4.2 Listing the IPFW Rules
\r
138 The syntax for this form of the command is:
\r
140 `ipfw` [-a] [-c] [-d] [-e] [-t] [-N] [-S] list
\r
142 There are seven valid flags when using this form of the command:
\r
144 -a:: While listing, show counter values. This option is the only way to see accounting counters.-c:: List rules in compact form.-d:: Show dynamic rules in addition to static rules.-e:: If `-d` was specified, also show expired dynamic rules.-t:: Display the last match times for each chain entry. The time listing is incompatible with the input syntax used by the [ipfw(8)](http://leaf.dragonflybsd.org/cgi/web-man?command#ipfw§ion8) utility.-N:: Attempt to resolve given addresses and service names.-S:: Show the set each rule belongs to. If this flag is not specified, disabled rules will not be listed.
\r
146 #### 10.7.4.3 Flushing the IPFW Rules
\r
148 The syntax for flushing the chain is:
\r
152 This causes all entries in the firewall chain to be removed except the fixed default policy enforced by the kernel (index 65535). Use caution when flushing rules; the default deny policy will leave your system cut off from the network until allow entries are added to the chain.
\r
154 #### 10.7.4.4 Clearing the IPFW Packet Counters
\r
156 The syntax for clearing one or more packet counters is:
\r
158 `ipfw` zero [`***index***`]
\r
160 When used without an `***index***` argument, all packet counters are cleared. If an `***index***` is supplied, the clearing operation only affects a specific chain entry.
\r
162 ### 10.7.5 Example Commands for **ipfw**
\r
164 This command will deny all packets from the host `evil.crackers.org` to the telnet port of the host `nice.people.org`:
\r
167 # ipfw add deny tcp from evil.crackers.org to nice.people.org 23
\r
170 The next example denies and logs any TCP traffic from the entire `crackers.org` network (a class C) to the `nice.people.org` machine (any port).
\r
173 # ipfw add deny log tcp from evil.crackers.org/24 to nice.people.org
\r
176 If you do not want people sending X sessions to your internal network (a subnet of a class C), the following command will do the necessary filtering:
\r
179 # ipfw add deny tcp from any to my.org/28 6000 setup
\r
182 To see the accounting records:
\r
188 or in the short form
\r
194 You can also see the last time a chain entry was matched with:
\r
200 ### 10.7.6 Building a Packet Filtering Firewall
\r
202 **Note:** The following suggestions are just that: suggestions. The requirements of each firewall are different and we cannot tell you how to build a firewall to meet your particular requirements.
\r
204 When initially setting up your firewall, unless you have a test bench setup where you can configure your firewall host in a controlled environment, it is strongly recommend you use the logging version of the commands and enable logging in the kernel. This will allow you to quickly identify problem areas and cure them without too much disruption. Even after the initial setup phase is complete, I recommend using the logging for `deny' as it allows tracing of possible attacks and also modification of the firewall rules if your requirements alter.
\r
206 **Note:** If you use the logging versions of the `accept` command, be aware that it can generate ***large*** amounts of log data. One log entry will be generated for every packet that passes through the firewall, so large FTP/http transfers, etc, will really slow the system down. It also increases the latencies on those packets as it requires more work to be done by the kernel before the packet can be passed on. **syslogd** will also start using up a lot more processor time as it logs all the extra data to disk, and it could quite easily fill the partition `/var/log` is located on.
\r
208 You should enable your firewall from `/etc/rc.conf.local` or `/etc/rc.conf`. The associated manual page explains which knobs to fiddle and lists some preset firewall configurations. If you do not use a preset configuration, `ipfw list` will output the current ruleset into a file that you can pass to `rc.conf`. If you do not use `/etc/rc.conf.local` or `/etc/rc.conf` to enable your firewall, it is important to make sure your firewall is enabled before any IP interfaces are configured.
\r
210 The next problem is what your firewall should actually ***do***! This is largely dependent on what access to your network you want to allow from the outside, and how much access to the outside world you want to allow from the inside. Some general rules are:
\r
213 * Block all incoming access to ports below 1024 for TCP. This is where most of the security sensitive services are, like finger, SMTP (mail) and telnet.
\r
215 * Block ***all*** incoming UDP traffic. There are very few useful services that travel over UDP, and what useful traffic there is, is normally a security threat (e.g. Suns RPC and NFS protocols). This has its disadvantages also, since UDP is a connectionless protocol, denying incoming UDP traffic also blocks the replies to outgoing UDP traffic. This can cause a problem for people (on the inside) using external archie (prospero) servers. If you want to allow access to archie, you will have to allow packets coming from ports 191 and 1525 to any internal UDP port through the firewall. **ntp** is another service you may consider allowing through, which comes from port 123.
\r
217 * Block traffic to port 6000 from the outside. Port 6000 is the port used for access to X11 servers, and can be a security threat (especially if people are in the habit of doing `xhost +` on their workstations). X11 can actually use a range of ports starting at 6000, the upper limit being how many X displays you can run on the machine. The upper limit as defined by RFC 1700 (Assigned Numbers) is 6063.
\r
219 * Check what ports any internal servers use (e.g. SQL servers, etc). It is probably a good idea to block those as well, as they normally fall outside the 1-1024 range specified above.
\r
221 Another checklist for firewall configuration is available from CERT at http://www.cert.org/tech_tips/packet_filtering.html
\r
223 As stated above, these are only ***guidelines***. You will have to decide what filter rules you want to use on your firewall yourself. We cannot accept ANY responsibility if someone breaks into your network, even if you follow the advice given above.
\r
225 ### 10.7.7 IPFW Overhead and Optimization
\r
227 Many people want to know how much overhead IPFW adds to a system. The answer to this depends mostly on your rule set and processor speed. For most applications dealing with Ethernet and small rule sets, the answer is ***negligible***. For those of you that need actual measurements to satisfy your curiosity, read on.
\r
229 The following measurements were made using FreeBSD 2.2.5-STABLE on a 486-66. (While IPFW has changed slightly in later releases of DragonFly, it still performs with similar speed.) IPFW was modified to measure the time spent within the `ip_fw_chk` routine, displaying the results to the console every 1000 packets.
\r
231 Two rule sets, each with 1000 rules, were tested. The first set was designed to demonstrate a worst case scenario by repeating the rule:
\r
234 # ipfw add deny tcp from any to any 55555
\r
237 This demonstrates a worst case scenario by causing most of IPFW's packet check routine to be executed before finally deciding that the packet does not match the rule (by virtue of the port number). Following the 999th iteration of this rule was an `allow ip from any to any`.
\r
239 The second set of rules were designed to abort the rule check quickly:
\r
242 # ipfw add deny ip from 1.2.3.4 to 1.2.3.4
\r
245 The non-matching source IP address for the above rule causes these rules to be skipped very quickly. As before, the 1000th rule was an `allow ip from any to any`.
\r
247 The per-packet processing overhead in the former case was approximately 2.703 ms/packet, or roughly 2.7 microseconds per rule. Thus the theoretical packet processing limit with these rules is around 370 packets per second. Assuming 10 Mbps Ethernet and a ~1500 byte packet size, we would only be able to achieve 55.5% bandwidth utilization.
\r
249 For the latter case each packet was processed in approximately 1.172 ms, or roughly 1.2 microseconds per rule. The theoretical packet processing limit here would be about 853 packets per second, which could consume 10 Mbps Ethernet bandwidth.
\r
251 The excessive number of rules tested and the nature of those rules do not provide a real-world scenario -- they were used only to generate the timing information presented here. Here are a few things to keep in mind when building an efficient rule set:
\r
254 * Place an `established` rule early on to handle the majority of TCP traffic. Do not put any `allow tcp` statements before this rule.
\r
256 * Place heavily triggered rules earlier in the rule set than those rarely used (***without changing the permissiveness of the firewall***, of course). You can see which rules are used most often by examining the packet counting statistics with `ipfw -a l`.
\r
261 CategoryHandbook-security
\r
projects / ikiwiki.git / blob