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