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