From 1bd0b728966c01badea300904240b6f9f07a3063 Mon Sep 17 00:00:00 2001 From: jfieber Date: Sat, 14 Oct 1995 21:49:54 +0000 Subject: New section: firewalls. Submitted by: Gary Palmer --- share/doc/handbook/Makefile | 5 +- share/doc/handbook/firewalls.sgml | 525 ++++++++++++++++++++++++++++++++++++++ share/doc/handbook/handbook.sgml | 6 +- share/doc/handbook/sections.sgml | 3 +- 4 files changed, 533 insertions(+), 6 deletions(-) create mode 100644 share/doc/handbook/firewalls.sgml diff --git a/share/doc/handbook/Makefile b/share/doc/handbook/Makefile index 86bf210..17d7295 100644 --- a/share/doc/handbook/Makefile +++ b/share/doc/handbook/Makefile @@ -1,8 +1,9 @@ -# $Id: Makefile,v 1.4 1995/10/01 04:43:11 jfieber Exp $ +# $Id: Makefile,v 1.5 1995/10/07 04:31:10 jfieber Exp $ SRCS= authors.sgml basics.sgml bibliography.sgml boothelp.sgml SRCS+= booting.sgml contrib.sgml crypt.sgml ctm.sgml current.sgml dialup.sgml -SRCS+= diskless.sgml dma.sgml eresources.sgml esdi.sgml glossary.sgml +SRCS+= diskless.sgml dma.sgml eresources.sgml esdi.sgml +SRCS+= firewalls.sgml glossary.sgml SRCS+= handbook.sgml history.sgml hw.sgml install.sgml kerberos.sgml SRCS+= kernelconfig.sgml kerneldebug.sgml memoryuse.sgml SRCS+= mirrors.sgml nfs.sgml nutshell.sgml diff --git a/share/doc/handbook/firewalls.sgml b/share/doc/handbook/firewalls.sgml new file mode 100644 index 0000000..6a63a53 --- /dev/null +++ b/share/doc/handbook/firewalls.sgml @@ -0,0 +1,525 @@ + + + +Firewalls + +

Contributed by &a.gpalmer;.4th of October 1995 + +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 FreeBSD kernel to impliment them. + +Note: People often think that having a firewall between +your companies internal network and the ``Big Bad Internet'' will +solve all your security problems. It may help, but a poorly setup +firewall system is more of a security risk than not having one at all. +A firewall can only add another layer of security to your systems, but +they will not be able to stop a really determined hacker from +penetrating your internal network. If you let internal security lapse +because you believe your firewall to be impenetrable, you have just +made the hackers job that bit easier. + +What is a firewall? + +

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, where the kernel on a +multi-homed machine chooses whether to forward or block packets +based on a set of rules. The second type, known as proxy +servers, rely on daemons to provide authentication and to +forward packets, possibly on a multi-homed machine which has +kernel packet forwarding disabled. + +

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. + +

FreeBSD 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 FreeBSD from third party software, but there +is such a vareity of proxy servers available that it would be +impossible to cover them in this document. + +Packet filtering routers + +

A router is a machine which forwards packets between two or more +networks. A packet filtering router has an extra piece of code in it's +kernel, which compares each packet to a list of rules before deciding +if it should be forwarded or not. Most modern IP routing software has +packet filtering code in it, which defaults to forwarding all +packets. To enable the filters, you need to define a set of rules for +the filtering code, so that it can decide if the packet should be +allowed to pass or not. + +

To decide if a packet should be passed on or not, the code looks +through it's set of rules for a rule which matches the contents of +this packets 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''. + +

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). + +Proxy servers + +

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). + +

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 instantly +expires. 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. + +

Proxy servers often have ways of restricting access further, so +that only certain hosts can gain access to the servers, and often they +can be set up so that you can limit which users can talk to which +destination machine. Again, what facilities are available depends +largely on what proxy software you choose. + +What does IPFW allow me to do? + +

IPFW, the software supplied with FreeBSD, is a packet +filtering and accounting system which resides in the kernel, and has a +user-land control utility, ipfw(8). Together, they +allow you to define and query the rules currently used by the kernel +in its routing decisions. + +

There are two related parts to IPFW. The firewall section +allows you to perform packet filtering. There is also an IP accounting +section which allows you to track usage of your router, based on +similar rules to the firewall section. This allows you to see (for +example) how much traffic your router is getting from a certain +machine, or how much WWW (World Wide Web) traffic it is forwarding. + +

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. + +Enabling IPFW on FreeBSD + +

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 + for more +details on how to recompile your kernel. + +

There are currently three kernel configuration options +relevant to IPFW: + + +syslogd. Without this option, even if you +specify that packets should be logged in the filter rules, nothing +will happen. + + + +Configuring IPFW + +

The configuration of the IPFW software is done through the +ipfw(8) utility. The syntax for this command looks +quite complicated, but it is relatively simple once you understand +it's structure. + +

There are currently two different command line formats for the +utility, depending on what you are doing. The first form is used when +adding/deleting entries from the firewall or accounting chains, or +when clearing the counters for an entry on the accounting chain. The +second form is used for more general actions, such as flushing the +rule chains, listing the rule chains or setting the default policy. + +Altering the IPFW rules + +

The syntax for this form of the command is: + +ipfw [-n] command action protocol addresses + + +

There is one valid flag when using this form of the command: + + + + +The command given can be shortened to the shortest unique +form. The valid commands are: + + + + + +If no command is given, it will default addfirewall or +addaccounting depending on the arguments given. + +

Currently, the firewall support in the kernel applies a set of +weights to the rule being added. This means that the rules will +not be evaluated in the order that they are given to the +system. The weighting system is designed so that rules which are very +specific are evaluated first, and rules which cover very large ranges +are evaluated last. In other words, a rule which applies to a specific +port on a specific host will have a higher priority than a rule which +applies to that same port, but on a range of hosts, or that host on a +range of ports. + +

The weighting system is not perfect, however, and can lead to +problems. The best way to see what order it has put your rules in is +to use the list command, as that command lists the rules in +the order that they are evaluated, not the order that they were fed to +the system. + +

The actions available depend on which rule chain the +entry is destined for. For the firewall chain, valid +actions are: + + + +reject, but also log the packet details. + +deny, but also log the packet details. + +accept. + + + +For the accounting chain, valid actions are: + + + + + +

Each action will be recognized by the shortest unambigious +prefix. + +The protocols which can be specified are: + + + + + +

The address specification is: + +[from <address/mask>[port]] [to + <address/mask>[port]] [via <interface>] + + +

You can only specify port in conjunction with +protocols which support ports (UDP, TCP and SYN). + +

The order of the from, to, and +via keywords is unimportant. Any of them can be omitted, +in which case a default entry for that keyword will be supplied which +matches everything. + +

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. The +keyword via can be substituted by on, for +readability reasons. + +

The syntax used to specify an <address/mask> is: + +<address> + +or + +<address>/mask-bits + +or + +<address>:mask-pattern + + +

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''. +

The port numbers to be blocked are specified as: + +port[,port[,port[...]]] + +to specify either a single port or a list of ports, or + +port:port + +to specify a range of ports. The name of a service (from +/etc/services) can be used instead of a numeric port value. + +Listing/flushing the IPFW rules + +

The syntax for this form of the command is: + +ipfw [-ans] command [argument] + + +

There are three valid flags when using this form of the command: + + + +-s. + +-a +to see accounting counters. The short form listing is incompatible +with the input syntax used by the ipfw(8) utility. + + + +The command given can be shortened to the shortest unique +form. The valid commands are: + + + +-s flag is +given, the format is compatable with the command line syntax. + + + +The list and flush commands may optionally be passed +an argument to specify which chain to flush. Valid arguments are: + + + + + +

The policy command can be given one of two arguments: + + + + + +As usual, the arguments can be shortened to the shortest unique form +(in this case, the first letter). + +Example commands for ipfw + +

This command will deny all packets from the host +evil.hacker.org to the telnet port of the host +nice.people.org by being forwarded by the router: + + +ipfw addf deny tcp from evil.hacker.org to nice.people.org telnet + + +

The next example denies and logs any TCP traffic from the entire +hacker.org network (a class C) to the nice.people.org +machine (any port). + + +ipfw addf ldeny tcp from evil.hacker.org/24 to nice.people.org + + +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: + + +ipfw addf deny syn to my.org/28 6000 + + +To allow access to the SUP server on sup.FreeBSD.ORG, use the +following command: + + +ipfw addf accept syn to sup.FreeBSD.ORG supfilesrv + + +To see the accounting records: + +ipfw -sa list accounting + +or in the short form + +ipfw -sa l a + + +Building a packet filtering firewall + +

Note: The following suggestions are just that: +suggestions. The requirements of each firewall are different and I +cannot tell you how to build a firewall to meet your particular +requirements. + +

When initially setting up your firewall, unless you have a test +bench setup where you can configure your firewall host in a controlled +environment, I 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 of `deny' as it allows tracing of +possible attacks and also modification of the firewall rules if your +requirements alter. + +Note: If you use the logging versions of the +accept command, it can generate large ammounts +of log data as one log line 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 with 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. + +

As currently supplied, FreeBSD does not have the ability to +load firewall rules at boot time. My suggestion is to put a call +to a shell script in the /etc/netstart script. Put the +call early enough in the netstart file so that the firewall is +configured before any of the IP interfaces are configured. This +means that there is no window during which time your network is +open. + +

The actual script used to load the rules is entirely up to +you. There is currently no support in the ipfw utility for +loading multiple rules in the one command. The system I use is to use +the command: + + +# ipfw list + + +to write a list of the current rules out to a file, and then use a +text editor to prepend ``ipfw '' before all the lines. This +will allow the script to be fed into /bin/sh and reload the rules into +the kernel. Perhaps not the most efficient way, but it works. + +

The next problem is what your firewall should actually DO! +This is largely dependant 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: + + + + Block all incoming access to ports below 1000 for TCP. This is +where most of the security sensitive services are, like finger, smtp +(mail) and telnet. + + Block incoming SYN connections to ports between 1001 and 1024 +(this will allow internal users to rsh/rlogin to the outside). If you +do not want to allow rsh/rlogin connections from the inside to the +outside, then extend the above suggestion to cover ports 1-1024. + + 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 outoing 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'll 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. + + 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 habbit 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. + + Check what ports any internal servers use (e.g. SQL servers, +etc). It's probably a good idea to block those as well, as they +normally fall outside the 1-1024 range specified above. + + + +

Of course, if you want to make sure that no un-authorised traffic +gets through the firewall, change the default policy to ``deny''. This +will mean that any traffic which is allowed through has to be +specified explicitly in an ``accept'' or ``allow'' filter rule. Which +ports you allow through is again something that you will have to +decide for yourself. If you do set the default policy to be deny, you +will probably want to install proxy servers, as no traffic will be +able to get OUT either unless you allow TCP SYN connections going form +the inside out. + +

As I said above, these are only guidelines. You will have +to decide what filter rules you want to use on your firewall +yourself. I cannot accept ANY responsibility if someone breaks into +your network, even if you follow the advice given above. diff --git a/share/doc/handbook/handbook.sgml b/share/doc/handbook/handbook.sgml index 012bde1..400f7b2 100644 --- a/share/doc/handbook/handbook.sgml +++ b/share/doc/handbook/handbook.sgml @@ -1,4 +1,4 @@ - + The FreeBSD Documentation Project - October 6, 1995 + October 14, 1995 Welcome to FreeBSD! This handbook covers the installation and day to day use of FreeBSD Release @@ -70,7 +70,7 @@ Web server">. &crypt; &skey; &kerberos; - * Firewalls + &firewalls; &printing; The X-Window System diff --git a/share/doc/handbook/sections.sgml b/share/doc/handbook/sections.sgml index 33011b3..9551e46 100644 --- a/share/doc/handbook/sections.sgml +++ b/share/doc/handbook/sections.sgml @@ -1,4 +1,4 @@ - + @@ -16,6 +16,7 @@ + -- cgit v1.1