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