diff --git a/handbook/Makefile b/handbook/Makefile index 9906e21f7e..fe676e8e48 100644 --- a/handbook/Makefile +++ b/handbook/Makefile @@ -1,14 +1,15 @@ -# $Id: Makefile,v 1.5 1995-10-07 04:31:10 jfieber Exp $ +# $Id: Makefile,v 1.6 1995-10-14 21:49:43 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 SRCS+= porting.sgml ports.sgml ppp.sgml printing.sgml relnotes.sgml SRCS+= routing.sgml scsi.sgml sections.sgml SRCS+= skey.sgml slipc.sgml slips.sgml submitters.sgml sup.sgml SRCS+= troubleshooting.sgml userppp.sgml .include diff --git a/handbook/firewalls.sgml b/handbook/firewalls.sgml new file mode 100644 index 0000000000..7cf9288fe3 --- /dev/null +++ b/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/handbook/handbook.sgml b/handbook/handbook.sgml index 96f9812f23..5f33593a99 100644 --- a/handbook/handbook.sgml +++ b/handbook/handbook.sgml @@ -1,158 +1,158 @@ - + %authors; %sections; ]> FreeBSD Handbook <author> <name>The FreeBSD Documentation Project</name> </author> - <date>October 6, 1995</date> + <date>October 14, 1995</date> <abstract>Welcome to FreeBSD! This handbook covers the installation and day to day use of <bf>FreeBSD Release 2.0.5</bf>. This manual is a <bf>work in progress</bf> and is the work of many individuals. Many sections do not yet exist and some of those that do exist need to be updated. If you are interested in helping with this project, send email to the FreeBSD Documentation Project mailing list <tt><htmlurl url="mailto:doc@freebsd.org" name="<doc@freebsd.org>"></tt>. The latest version of this document is always available from the <url url="http://www.freebsd.org/" name="FreeBSD World Wide Web server">. </abstract> <toc> <!-- ************************************************************ --> <part><heading>Basics</heading> <chapt><heading>Introduction</heading> &nutshell; &history; &relnotes; &install; &basics; <chapt><heading>Installing applications</heading> <sect><heading>* Installing packages</heading> &ports; &porting; <!-- ************************************************************ --> <part><heading>System Administration</heading> &kernelconfig; <chapt><heading>Users, groups and security</heading> &crypt; &skey; &kerberos; - <sect><heading>* Firewalls</heading> + &firewalls; &printing; <chapt><heading>The X-Window System</heading> <p>Pending the completion of this section, please refer to documentation supplied by the <url url="http://www.xfree86.org/" name="The XFree86 Project, Inc">. <chapt><heading>Managing hardware</heading> <sect><heading>* Adding and reconfiguring disks</heading> &scsi; &esdi; <sect><heading>* Tapes and backups</heading> <sect><heading>* Serial ports</heading> <sect><heading>* Sound cards</heading> <!-- ************************************************************ --> <part><heading>Network Communications</heading> <chapt><heading>Basic Networking</heading> <sect><heading>* Ethernet basics</heading> <sect><heading>* Serial basics</heading> <sect><heading>* Hardwired Terminals</heading> &dialup; <chapt><heading>PPP and SLIP</heading> <p>If your connection to the internet is through a modem, or you wish to provide other people with dialup connections to the internet using FreeBSD, you have the option of using PPP or SLIP. Furthermore, two varieties of PPP are provided: <em>user</em> (sometimes referred to as iijppp) and <em>kernel</em>. The procedures for configuring both types of PPP, and for setting up SLIP are described in this chapter. &userppp; &ppp; &slipc; &slips; <chapt><heading>Advanced networking</heading> <!-- <sect><heading>Gateways and routing</heading> <p>This section is in progress. Please contact Coranth Gryphon <htmlurl url="mailto:gryphon@healer.com" name="<gryphon@healer.com>"> for more information. --> &routing; &nfs; &diskless; <sect><heading>* Yellow Pages/NIS</heading> <sect><heading>* ISDN</heading> <chapt><heading>* Mail</heading> <!-- ************************************************************ --> <part><heading>Advanced topics</heading> ¤t; &ctm; ⊃ &kerneldebug; &submitters; &troubleshooting; <!-- ************************************************************ --> <part><heading>Appendices</heading> &mirrors; &bibliography; &eresources; &hw; <chapt><heading>Assorted technical topics</heading> &booting; &memoryuse; &dma; &contrib; <!-- &glossary; --> </book> </linuxdoc> diff --git a/handbook/sections.sgml b/handbook/sections.sgml index 84d08b661c..b98430ec85 100644 --- a/handbook/sections.sgml +++ b/handbook/sections.sgml @@ -1,44 +1,45 @@ -<!-- $Id: sections.sgml,v 1.5 1995-10-07 04:31:53 jfieber Exp $ --> +<!-- $Id: sections.sgml,v 1.6 1995-10-14 21:49:54 jfieber Exp $ --> <!-- The FreeBSD Documentation Project --> <!-- Entities containing all the pieces of the handbook are --> <!-- defined here --> <!ENTITY bibliography SYSTEM "bibliography.sgml"> <!ENTITY basics SYSTEM "basics.sgml"> <!ENTITY booting SYSTEM "booting.sgml"> <!ENTITY contrib SYSTEM "contrib.sgml"> <!ENTITY ctm SYSTEM "ctm.sgml"> <!ENTITY current SYSTEM "current.sgml"> <!ENTITY crypt SYSTEM "crypt.sgml"> <!ENTITY dialup SYSTEM "dialup.sgml"> <!ENTITY diskless SYSTEM "diskless.sgml"> <!ENTITY dma SYSTEM "dma.sgml"> <!ENTITY eresources SYSTEM "eresources.sgml"> <!ENTITY esdi SYSTEM "esdi.sgml"> +<!ENTITY firewalls SYSTEM "firewalls.sgml"> <!ENTITY glossary SYSTEM "glossary.sgml"> <!ENTITY history SYSTEM "history.sgml"> <!ENTITY hw SYSTEM "hw.sgml"> <!ENTITY install SYSTEM "install.sgml"> <!ENTITY kerberos SYSTEM "kerberos.sgml"> <!ENTITY kernelconfig SYSTEM "kernelconfig.sgml"> <!ENTITY kerneldebug SYSTEM "kerneldebug.sgml"> <!ENTITY memoryuse SYSTEM "memoryuse.sgml"> <!ENTITY mirrors SYSTEM "mirrors.sgml"> <!ENTITY nfs SYSTEM "nfs.sgml"> <!ENTITY nutshell SYSTEM "nutshell.sgml"> <!ENTITY porting SYSTEM "porting.sgml"> <!ENTITY ports SYSTEM "ports.sgml"> <!ENTITY ppp SYSTEM "ppp.sgml"> <!ENTITY printing SYSTEM "printing.sgml"> <!ENTITY relnotes SYSTEM "relnotes.sgml"> <!ENTITY routing SYSTEM "routing.sgml"> <!ENTITY scsi SYSTEM "scsi.sgml"> <!ENTITY skey SYSTEM "skey.sgml"> <!ENTITY slipc SYSTEM "slipc.sgml"> <!ENTITY slips SYSTEM "slips.sgml"> <!ENTITY submitters SYSTEM "submitters.sgml"> <!ENTITY sup SYSTEM "sup.sgml"> <!ENTITY troubleshooting SYSTEM "troubleshooting.sgml"> <!ENTITY userppp SYSTEM "userppp.sgml">