xref: /freebsd/share/man/man7/firewall.7 (revision 4f8f43b06ed07e96a250855488cc531799d5b78f)
1.\" Copyright (C) 2001 Matthew Dillon. All rights reserved.
2.\"
3.\" Redistribution and use in source and binary forms, with or without
4.\" modification, are permitted provided that the following conditions
5.\" are met:
6.\" 1. Redistributions of source code must retain the above copyright
7.\"    notice, this list of conditions and the following disclaimer.
8.\" 2. Redistributions in binary form must reproduce the above copyright
9.\"    notice, this list of conditions and the following disclaimer in the
10.\"    documentation and/or other materials provided with the distribution.
11.\"
12.\" THIS SOFTWARE IS PROVIDED BY AUTHOR AND CONTRIBUTORS ``AS IS'' AND
13.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
14.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
15.\" ARE DISCLAIMED.  IN NO EVENT SHALL AUTHOR OR CONTRIBUTORS BE LIABLE
16.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
17.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
18.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
19.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
20.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
21.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
22.\" SUCH DAMAGE.
23.\"
24.Dd May 26, 2001
25.Dt FIREWALL 7
26.Os
27.Sh NAME
28.Nm firewall
29.Nd simple firewalls under FreeBSD
30.Sh FIREWALL BASICS
31A Firewall is most commonly used to protect an internal network
32from an outside network by preventing the outside network from
33making arbitrary connections into the internal network.
34Firewalls
35are also used to prevent outside entities from spoofing internal
36IP addresses and to isolate services such as NFS or SMBFS (Windows
37file sharing) within LAN segments.
38.Pp
39The
40.Fx
41firewalling system also has the capability to limit bandwidth using
42.Xr dummynet 4 .
43This feature can be useful when you need to guarantee a certain
44amount of bandwidth for a critical purpose.
45For example, if you
46are doing video conferencing over the Internet via your
47office T1 (1.5 MBits/s), you may wish to bandwidth-limit all other
48T1 traffic to 1 MBit/s in order to reserve at least 0.5 MBits
49for your video conferencing connections.
50Similarly if you are
51running a popular web or ftp site from a colocation facility
52you might want to limit bandwidth to prevent excessive bandwidth
53charges from your provider.
54.Pp
55Finally,
56.Fx
57firewalls may be used to divert packets or change the next-hop
58address for packets to help route them to the correct destination.
59Packet diversion is most often used to support NAT (network
60address translation), which allows an internal network using
61a private IP space to make connections to the outside for browsing
62or other purposes.
63.Pp
64Constructing a firewall may appear to be trivial, but most people
65get them wrong.
66The most common mistake is to create an exclusive
67firewall rather than an inclusive firewall.
68An exclusive firewall
69allows all packets through except for those matching a set of rules.
70An inclusive firewall allows only packets matching the ruleset
71through.
72Inclusive firewalls are much, much safer than exclusive
73firewalls but a tad more difficult to build properly.
74The
75second most common mistake is to blackhole everything except the
76particular port you want to let through.
77TCP/IP needs to be able
78to get certain types of ICMP errors to function properly - for
79example, to implement MTU discovery.
80Also, a number of common
81system daemons make reverse connections to the
82.Sy auth
83service in an attempt to authenticate the user making a connection.
84Auth is rather dangerous but the proper implementation is to return
85a TCP reset for the connection attempt rather than simply blackholing
86the packet.
87We cover these and other quirks involved with constructing
88a firewall in the sample firewall section below.
89.Sh IPFW KERNEL CONFIGURATION
90You do not need to create a custom kernel to use the IP firewalling features.
91If you enable firewalling in your
92.Pa /etc/rc.conf
93(see below), the ipfw kernel module will be loaded automatically
94when necessary.
95However,
96if you are paranoid you can compile IPFW directly into the
97.Fx
98kernel by using the
99.Sy IPFIREWALL
100option set.
101If compiled in the kernel, ipfw denies all
102packets by default, which means that, if you do not load in
103a permissive ruleset via
104.Pa /etc/rc.conf ,
105rebooting into your new kernel will take the network offline.
106This can prevent you from being able to access your system if you
107are not sitting at the console.
108It is also quite common to
109update a kernel to a new release and reboot before updating
110the binaries.
111This can result in an incompatibility between
112the
113.Xr ipfw 8
114program and the kernel which prevents it from running in the
115boot sequence, also resulting in an inaccessible machine.
116Because of these problems the
117.Sy IPFIREWALL_DEFAULT_TO_ACCEPT
118kernel option is also available which changes the default firewall
119to pass through all packets.
120Note, however, that using this option
121may open a small window of opportunity during booting where your
122firewall passes all packets.
123Still, it is a good option to use
124while getting up to speed with
125.Fx
126firewalling.
127Get rid of it once you understand how it all works
128to close the loophole, though.
129There is a third option called
130.Sy IPDIVERT
131which allows you to use the firewall to divert packets to a user program
132and is necessary if you wish to use
133.Xr natd 8
134to give private internal networks access to the outside world.
135If you want to be able to limit the bandwidth used by certain types of
136traffic, the
137.Sy DUMMYNET
138option must be used to enable
139.Em ipfw pipe
140rules.
141.Sh SAMPLE IPFW-BASED FIREWALL
142Here is an example ipfw-based firewall taken from a machine with three
143interface cards.
144fxp0 is connected to the 'exposed' LAN.
145Machines
146on this LAN are dual-homed with both internal 10.\& IP addresses and
147Internet-routed IP addresses.
148In our example, 192.100.5.x represents
149the Internet-routed IP block while 10.x.x.x represents the internal
150networks.
151While it is not relevant to the example, 10.0.1.x is
152assigned as the internal address block for the LAN on fxp0, 10.0.2.x
153for the LAN on fxp1, and 10.0.3.x for the LAN on fxp2.
154.Pp
155In this example we want to isolate all three LANs from the Internet
156as well as isolate them from each other, and we want to give all
157internal addresses access to the Internet through a NAT gateway running
158on this machine.
159To make the NAT gateway work, the firewall machine
160is given two Internet-exposed addresses on fxp0 in addition to an
161internal 10.\& address on fxp0: one exposed address (not shown)
162represents the machine's official address, and the second exposed
163address (192.100.5.5 in our example) represents the NAT gateway
164rendezvous IP.
165We make the example more complex by giving the machines
166on the exposed LAN internal 10.0.0.x addresses as well as exposed
167addresses.
168The idea here is that you can bind internal services
169to internal addresses even on exposed machines and still protect
170those services from the Internet.
171The only services you run on
172exposed IP addresses would be the ones you wish to expose to the
173Internet.
174.Pp
175It is important to note that the 10.0.0.x network in our example
176is not protected by our firewall.
177You must make sure that your
178Internet router protects this network from outside spoofing.
179Also, in our example, we pretty much give the exposed hosts free
180reign on our internal network when operating services through
181internal IP addresses (10.0.0.x).
182This is somewhat of security
183risk: what if an exposed host is compromised?
184To remove the
185risk and force everything coming in via LAN0 to go through
186the firewall, remove rules 01010 and 01011.
187.Pp
188Finally, note that the use of internal addresses represents a
189big piece of our firewall protection mechanism.
190With proper
191spoofing safeguards in place, nothing outside can directly
192access an internal (LAN1 or LAN2) host.
193.Bd -literal
194# /etc/rc.conf
195#
196firewall_enable="YES"
197firewall_type="/etc/ipfw.conf"
198
199# temporary port binding range let
200# through the firewall.
201#
202# NOTE: heavily loaded services running through the firewall may require
203# a larger port range for local-size binding.  4000-10000 or 4000-30000
204# might be a better choice.
205ip_portrange_first=4000
206ip_portrange_last=5000
207\&...
208.Ed
209.Bd -literal
210# /etc/ipfw.conf
211#
212# FIREWALL: the firewall machine / nat gateway
213# LAN0	    10.0.0.X and 192.100.5.X (dual homed)
214# LAN1	    10.0.1.X
215# LAN2	    10.0.2.X
216# sw:	    ethernet switch (unmanaged)
217#
218# 192.100.5.x represents IP addresses exposed to the Internet
219# (i.e. Internet routeable).  10.x.x.x represent internal IPs
220# (not exposed)
221#
222#   [LAN1]
223#      ^
224#      |
225#   FIREWALL -->[LAN2]
226#      |
227#   [LAN0]
228#      |
229#      +--> exposed host A
230#      +--> exposed host B
231#      +--> exposed host C
232#      |
233#   INTERNET (secondary firewall)
234#    ROUTER
235#      |
236#    [Internet]
237#
238# NOT SHOWN:  The INTERNET ROUTER must contain rules to disallow
239# all packets with source IP addresses in the 10. block in order
240# to protect the dual-homed 10.0.0.x block.  Exposed hosts are
241# not otherwise protected in this example - they should only bind
242# exposed services to exposed IPs but can safely bind internal
243# services to internal IPs.
244#
245# The NAT gateway works by taking packets sent from internal
246# IP addresses to external IP addresses and routing them to natd, which
247# is listening on port 8668.   This is handled by rule 00300.  Data coming
248# back to natd from the outside world must also be routed to natd using
249# rule 00301.  To make the example interesting, we note that we do
250# NOT have to run internal requests to exposed hosts through natd
251# (rule 00290) because those exposed hosts know about our
252# 10. network.  This can reduce the load on natd.  Also note that we
253# of course do not have to route internal<->internal traffic through
254# natd since those hosts know how to route our 10. internal network.
255# The natd command we run from /etc/rc.local is shown below.  See
256# also the in-kernel version of natd, ipnat.
257#
258#	natd -s -u -a 208.161.114.67
259#
260#
261add 00290 skipto 1000 ip from 10.0.0.0/8 to 192.100.5.0/24
262add 00300 divert 8668 ip from 10.0.0.0/8 to not 10.0.0.0/8
263add 00301 divert 8668 ip from not 10.0.0.0/8 to 192.100.5.5
264
265# Short cut the rules to avoid running high bandwidths through
266# the entire rule set.  Allow established tcp connections through,
267# and shortcut all outgoing packets under the assumption that
268# we need only firewall incoming packets.
269#
270# Allowing established tcp connections through creates a small
271# hole but may be necessary to avoid overloading your firewall.
272# If you are worried, you can move the rule to after the spoof
273# checks.
274#
275add 01000 allow tcp from any to any established
276add 01001 allow all from any to any out via fxp0
277add 01001 allow all from any to any out via fxp1
278add 01001 allow all from any to any out via fxp2
279
280# Spoof protection.  This depends on how well you trust your
281# internal networks.  Packets received via fxp1 MUST come from
282# 10.0.1.x.  Packets received via fxp2 MUST come from 10.0.2.x.
283# Packets received via fxp0 cannot come from the LAN1 or LAN2
284# blocks.  We cannot protect 10.0.0.x here, the Internet router
285# must do that for us.
286#
287add 01500 deny all from not 10.0.1.0/24 in via fxp1
288add 01500 deny all from not 10.0.2.0/24 in via fxp2
289add 01501 deny all from 10.0.1.0/24 in via fxp0
290add 01501 deny all from 10.0.2.0/24 in via fxp0
291
292# In this example rule set there are no restrictions between
293# internal hosts, even those on the exposed LAN (as long as
294# they use an internal IP address).  This represents a
295# potential security hole (what if an exposed host is
296# compromised?).  If you want full restrictions to apply
297# between the three LANs, firewalling them off from each
298# other for added security, remove these two rules.
299#
300# If you want to isolate LAN1 and LAN2, but still want
301# to give exposed hosts free reign with each other, get
302# rid of rule 01010 and keep rule 01011.
303#
304# (commented out, uncomment for less restrictive firewall)
305#add 01010 allow all from 10.0.0.0/8 to 10.0.0.0/8
306#add 01011 allow all from 192.100.5.0/24 to 192.100.5.0/24
307#
308
309# SPECIFIC SERVICES ALLOWED FROM SPECIFIC LANS
310#
311# If using a more restrictive firewall, allow specific LANs
312# access to specific services running on the firewall itself.
313# In this case we assume LAN1 needs access to filesharing running
314# on the firewall.  If using a less restrictive firewall
315# (allowing rule 01010), you do not need these rules.
316#
317add 01012 allow tcp from 10.0.1.0/8 to 10.0.1.1 139
318add 01012 allow udp from 10.0.1.0/8 to 10.0.1.1 137,138
319
320# GENERAL SERVICES ALLOWED TO CROSS INTERNAL AND EXPOSED LANS
321#
322# We allow specific UDP services through: DNS lookups, ntalk, and ntp.
323# Note that internal services are protected by virtue of having
324# spoof-proof internal IP addresses (10. net), so these rules
325# really only apply to services bound to exposed IPs.  We have
326# to allow UDP fragments or larger fragmented UDP packets will
327# not survive the firewall.
328#
329# If we want to expose high-numbered temporary service ports
330# for things like DNS lookup responses we can use a port range,
331# in this example 4000-65535, and we set to /etc/rc.conf variables
332# on all exposed machines to make sure they bind temporary ports
333# to the exposed port range (see rc.conf example above)
334#
335add 02000 allow udp from any to any 4000-65535,domain,ntalk,ntp
336add 02500 allow udp from any to any frag
337
338# Allow similar services for TCP.  Again, these only apply to
339# services bound to exposed addresses.  NOTE: we allow 'auth'
340# through but do not actually run an identd server on any exposed
341# port.  This allows the machine being authed to respond with a
342# TCP RESET.  Throwing the packet away would result in delays
343# when connecting to remote services that do reverse ident lookups.
344#
345# Note that we do not allow tcp fragments through, and that we do
346# not allow fragments in general (except for UDP fragments).  We
347# expect the TCP mtu discovery protocol to work properly so there
348# should be no TCP fragments.
349#
350add 03000 allow tcp from any to any http,https
351add 03000 allow tcp from any to any 4000-65535,ssh,smtp,domain,ntalk
352add 03000 allow tcp from any to any auth,pop3,ftp,ftp-data
353
354# It is important to allow certain ICMP types through, here is a list
355# of general ICMP types.  Note that it is important to let ICMP type 3
356# through.
357#
358#	0	Echo Reply
359#	3	Destination Unreachable (used by TCP MTU discovery, aka
360#					packet-too-big)
361#	4	Source Quench (typically not allowed)
362#	5	Redirect (typically not allowed - can be dangerous!)
363#	8	Echo
364#	11	Time Exceeded
365#	12	Parameter Problem
366#	13	Timestamp
367#	14	Timestamp Reply
368#
369# Sometimes people need to allow ICMP REDIRECT packets, which is
370# type 5, but if you allow it make sure that your Internet router
371# disallows it.
372
373add 04000 allow icmp from any to any icmptypes 0,3,8,11,12,13,14
374
375# log any remaining fragments that get through.  Might be useful,
376# otherwise do not bother.  Have a final deny rule as a safety to
377# guarantee that your firewall is inclusive no matter how the kernel
378# is configured.
379#
380add 05000 deny log ip from any to any frag
381add 06000 deny all from any to any
382.Ed
383.Sh PORT BINDING INTERNAL AND EXTERNAL SERVICES
384We have mentioned multi-homing hosts and binding services to internal or
385external addresses but we have not really explained it.
386When you have a
387host with multiple IP addresses assigned to it, you can bind services run
388on that host to specific IPs or interfaces rather than all IPs.
389Take
390the firewall machine for example: with three interfaces
391and two exposed IP addresses
392on one of those interfaces, the firewall machine is known by 5 different
393IP addresses (10.0.0.1, 10.0.1.1, 10.0.2.1, 192.100.5.5, and say
394192.100.5.1).
395If the firewall is providing file sharing services to the
396windows LAN segment (say it is LAN1), you can use samba's 'bind interfaces'
397directive to specifically bind it to just the LAN1 IP address.
398That
399way the file sharing services will not be made available to other LAN
400segments.
401The same goes for NFS.
402If LAN2 has your UNIX engineering
403workstations, you can tell nfsd to bind specifically to 10.0.2.1.
404You
405can specify how to bind virtually every service on the machine and you
406can use a light
407.Xr jail 8
408to indirectly bind services that do not otherwise give you the option.
409.Sh SEE ALSO
410.Xr dummynet 4 ,
411.Xr ipnat 5 ,
412.Xr rc.conf 5 ,
413.Xr smb.conf 5 Pq Pa ports/net/samba ,
414.Xr samba 7 Pq Pa ports/net/samba ,
415.Xr config 8 ,
416.Xr ipfw 8 ,
417.Xr ipnat 8 ,
418.Xr jail 8 ,
419.Xr natd 8 ,
420.Xr nfsd 8
421.Sh ADDITIONAL READING
422.Bl -tag -width indent
423.It Nm Ipfilter
424.Xr ipf 5 ,
425.Xr ipf 8 ,
426.Xr ipfstat 8
427.It Nm Packet Filter
428.Xr pf.conf 5 ,
429.Xr pfctl 8 ,
430.Xr pflogd 8
431.El
432.Sh HISTORY
433The
434.Nm
435manual page was originally written by
436.An Matthew Dillon
437and first appeared
438in
439.Fx 4.3 ,
440May 2001.
441