diff options
Diffstat (limited to 'static/freebsd/man7/firewall.7 3.html')
| -rw-r--r-- | static/freebsd/man7/firewall.7 3.html | 377 |
1 files changed, 0 insertions, 377 deletions
diff --git a/static/freebsd/man7/firewall.7 3.html b/static/freebsd/man7/firewall.7 3.html deleted file mode 100644 index da348df4..00000000 --- a/static/freebsd/man7/firewall.7 3.html +++ /dev/null @@ -1,377 +0,0 @@ -<table class="head"> - <tr> - <td class="head-ltitle">FIREWALL(7)</td> - <td class="head-vol">Miscellaneous Information Manual</td> - <td class="head-rtitle">FIREWALL(7)</td> - </tr> -</table> -<div class="manual-text"> -<section class="Sh"> -<h1 class="Sh" id="NAME"><a class="permalink" href="#NAME">NAME</a></h1> -<p class="Pp"><code class="Nm">firewall</code> — <span class="Nd">simple - firewalls under FreeBSD</span></p> -</section> -<section class="Sh"> -<h1 class="Sh" id="FIREWALL_BASICS"><a class="permalink" href="#FIREWALL_BASICS">FIREWALL - BASICS</a></h1> -<p class="Pp">A Firewall is most commonly used to protect an internal network - from an outside network by preventing the outside network from making - arbitrary connections into the internal network. Firewalls are also used to - prevent outside entities from spoofing internal IP addresses and to isolate - services such as NFS or SMBFS (Windows file sharing) within LAN - segments.</p> -<p class="Pp">The <span class="Ux">FreeBSD</span> firewalling system also has - the capability to limit bandwidth using <a class="Xr">dummynet(4)</a>. This - feature can be useful when you need to guarantee a certain amount of - bandwidth for a critical purpose. For example, if you are doing video - conferencing over the Internet via your office T1 (1.5 MBits/s), you may - wish to bandwidth-limit all other T1 traffic to 1 MBit/s in order to reserve - at least 0.5 MBits for your video conferencing connections. Similarly if you - are running a popular web or ftp site from a colocation facility you might - want to limit bandwidth to prevent excessive bandwidth charges from your - provider.</p> -<p class="Pp">Finally, <span class="Ux">FreeBSD</span> firewalls may be used to - divert packets or change the next-hop address for packets to help route them - to the correct destination. Packet diversion is most often used to support - NAT (network address translation), which allows an internal network using a - private IP space to make connections to the outside for browsing or other - purposes.</p> -<p class="Pp" id="auth">Constructing a firewall may appear to be trivial, but - most people get them wrong. The most common mistake is to create an - exclusive firewall rather than an inclusive firewall. An exclusive firewall - allows all packets through except for those matching a set of rules. An - inclusive firewall allows only packets matching the ruleset through. - Inclusive firewalls are much, much safer than exclusive firewalls but a tad - more difficult to build properly. The second most common mistake is to - blackhole everything except the particular port you want to let through. - TCP/IP needs to be able to get certain types of ICMP errors to function - properly - for example, to implement MTU discovery. Also, a number of common - system daemons make reverse connections to the - <a class="permalink" href="#auth"><b class="Sy">auth</b></a> service in an - attempt to authenticate the user making a connection. Auth is rather - dangerous but the proper implementation is to return a TCP reset for the - connection attempt rather than simply blackholing the packet. We cover these - and other quirks involved with constructing a firewall in the sample - firewall section below.</p> -</section> -<section class="Sh"> -<h1 class="Sh" id="IPFW_KERNEL_CONFIGURATION"><a class="permalink" href="#IPFW_KERNEL_CONFIGURATION">IPFW - KERNEL CONFIGURATION</a></h1> -<p class="Pp">You do not need to create a custom kernel to use the IP - firewalling features. If you enable firewalling in your - <span class="Pa">/etc/rc.conf</span> (see below), the ipfw kernel module - will be loaded automatically when necessary. However, if you are paranoid - you can compile IPFW directly into the <span class="Ux">FreeBSD</span> - kernel by using the - <a class="permalink" href="#IPFIREWALL"><b class="Sy" id="IPFIREWALL">IPFIREWALL</b></a> - option set. If compiled in the kernel, ipfw denies all packets by default, - which means that, if you do not load in a permissive ruleset via - <span class="Pa">/etc/rc.conf</span>, rebooting into your new kernel will - take the network offline. This can prevent you from being able to access - your system if you are not sitting at the console. It is also quite common - to update a kernel to a new release and reboot before updating the binaries. - This can result in an incompatibility between the <a class="Xr">ipfw(8)</a> - program and the kernel which prevents it from running in the boot sequence, - also resulting in an inaccessible machine. Because of these problems the - <a class="permalink" href="#IPFIREWALL_DEFAULT_TO_ACCEPT"><b class="Sy" id="IPFIREWALL_DEFAULT_TO_ACCEPT">IPFIREWALL_DEFAULT_TO_ACCEPT</b></a> - kernel option is also available which changes the default firewall to pass - through all packets. Note, however, that using this option may open a small - window of opportunity during booting where your firewall passes all packets. - Still, it is a good option to use while getting up to speed with - <span class="Ux">FreeBSD</span> firewalling. Get rid of it once you - understand how it all works to close the loophole, though. There is a third - option called - <a class="permalink" href="#IPDIVERT"><b class="Sy" id="IPDIVERT">IPDIVERT</b></a> - which allows you to use the firewall to divert packets to a user program and - is necessary if you wish to use <a class="Xr">natd(8)</a> to give private - internal networks access to the outside world. If you want to be able to - limit the bandwidth used by certain types of traffic, the - <a class="permalink" href="#DUMMYNET"><b class="Sy" id="DUMMYNET">DUMMYNET</b></a> - option must be used to enable - <a class="permalink" href="#ipfw"><i class="Em" id="ipfw">ipfw pipe</i></a> - rules.</p> -</section> -<section class="Sh"> -<h1 class="Sh" id="SAMPLE_IPFW-BASED_FIREWALL"><a class="permalink" href="#SAMPLE_IPFW-BASED_FIREWALL">SAMPLE - IPFW-BASED FIREWALL</a></h1> -<p class="Pp">Here is an example ipfw-based firewall taken from a machine with - three interface cards. fxp0 is connected to the 'exposed' LAN. Machines on - this LAN are dual-homed with both internal 10. IP addresses and - Internet-routed IP addresses. In our example, 192.100.5.x represents the - Internet-routed IP block while 10.x.x.x represents the internal networks. - While it is not relevant to the example, 10.0.1.x is assigned as the - internal address block for the LAN on fxp0, 10.0.2.x for the LAN on fxp1, - and 10.0.3.x for the LAN on fxp2.</p> -<p class="Pp">In this example we want to isolate all three LANs from the - Internet as well as isolate them from each other, and we want to give all - internal addresses access to the Internet through a NAT gateway running on - this machine. To make the NAT gateway work, the firewall machine is given - two Internet-exposed addresses on fxp0 in addition to an internal 10. - address on fxp0: one exposed address (not shown) represents the machine's - official address, and the second exposed address (192.100.5.5 in our - example) represents the NAT gateway rendezvous IP. We make the example more - complex by giving the machines on the exposed LAN internal 10.0.0.x - addresses as well as exposed addresses. The idea here is that you can bind - internal services to internal addresses even on exposed machines and still - protect those services from the Internet. The only services you run on - exposed IP addresses would be the ones you wish to expose to the - Internet.</p> -<p class="Pp">It is important to note that the 10.0.0.x network in our example - is not protected by our firewall. You must make sure that your Internet - router protects this network from outside spoofing. Also, in our example, we - pretty much give the exposed hosts free reign on our internal network when - operating services through internal IP addresses (10.0.0.x). This is - somewhat of security risk: what if an exposed host is compromised? To remove - the risk and force everything coming in via LAN0 to go through the firewall, - remove rules 01010 and 01011.</p> -<p class="Pp">Finally, note that the use of internal addresses represents a big - piece of our firewall protection mechanism. With proper spoofing safeguards - in place, nothing outside can directly access an internal (LAN1 or LAN2) - host.</p> -<div class="Bd Pp Li"> -<pre># /etc/rc.conf -# -firewall_enable="YES" -firewall_type="/etc/ipfw.conf" - -# temporary port binding range let -# through the firewall. -# -# NOTE: heavily loaded services running through the firewall may require -# a larger port range for local-size binding. 4000-10000 or 4000-30000 -# might be a better choice. -ip_portrange_first=4000 -ip_portrange_last=5000 -...</pre> -</div> -<div class="Bd Pp Li"> -<pre># /etc/ipfw.conf -# -# FIREWALL: the firewall machine / nat gateway -# LAN0 10.0.0.X and 192.100.5.X (dual homed) -# LAN1 10.0.1.X -# LAN2 10.0.2.X -# sw: ethernet switch (unmanaged) -# -# 192.100.5.x represents IP addresses exposed to the Internet -# (i.e. Internet routeable). 10.x.x.x represent internal IPs -# (not exposed) -# -# [LAN1] -# ^ -# | -# FIREWALL -->[LAN2] -# | -# [LAN0] -# | -# +--> exposed host A -# +--> exposed host B -# +--> exposed host C -# | -# INTERNET (secondary firewall) -# ROUTER -# | -# [Internet] -# -# NOT SHOWN: The INTERNET ROUTER must contain rules to disallow -# all packets with source IP addresses in the 10. block in order -# to protect the dual-homed 10.0.0.x block. Exposed hosts are -# not otherwise protected in this example - they should only bind -# exposed services to exposed IPs but can safely bind internal -# services to internal IPs. -# -# The NAT gateway works by taking packets sent from internal -# IP addresses to external IP addresses and routing them to natd, which -# is listening on port 8668. This is handled by rule 00300. Data coming -# back to natd from the outside world must also be routed to natd using -# rule 00301. To make the example interesting, we note that we do -# NOT have to run internal requests to exposed hosts through natd -# (rule 00290) because those exposed hosts know about our -# 10. network. This can reduce the load on natd. Also note that we -# of course do not have to route internal<->internal traffic through -# natd since those hosts know how to route our 10. internal network. -# The natd command we run from /etc/rc.local is shown below. See -# also the in-kernel version of natd, ipnat. -# -# natd -s -u -a 208.161.114.67 -# -# -add 00290 skipto 1000 ip from 10.0.0.0/8 to 192.100.5.0/24 -add 00300 divert 8668 ip from 10.0.0.0/8 to not 10.0.0.0/8 -add 00301 divert 8668 ip from not 10.0.0.0/8 to 192.100.5.5 - -# Short cut the rules to avoid running high bandwidths through -# the entire rule set. Allow established tcp connections through, -# and shortcut all outgoing packets under the assumption that -# we need only firewall incoming packets. -# -# Allowing established tcp connections through creates a small -# hole but may be necessary to avoid overloading your firewall. -# If you are worried, you can move the rule to after the spoof -# checks. -# -add 01000 allow tcp from any to any established -add 01001 allow all from any to any out via fxp0 -add 01001 allow all from any to any out via fxp1 -add 01001 allow all from any to any out via fxp2 - -# Spoof protection. This depends on how well you trust your -# internal networks. Packets received via fxp1 MUST come from -# 10.0.1.x. Packets received via fxp2 MUST come from 10.0.2.x. -# Packets received via fxp0 cannot come from the LAN1 or LAN2 -# blocks. We cannot protect 10.0.0.x here, the Internet router -# must do that for us. -# -add 01500 deny all from not 10.0.1.0/24 in via fxp1 -add 01500 deny all from not 10.0.2.0/24 in via fxp2 -add 01501 deny all from 10.0.1.0/24 in via fxp0 -add 01501 deny all from 10.0.2.0/24 in via fxp0 - -# In this example rule set there are no restrictions between -# internal hosts, even those on the exposed LAN (as long as -# they use an internal IP address). This represents a -# potential security hole (what if an exposed host is -# compromised?). If you want full restrictions to apply -# between the three LANs, firewalling them off from each -# other for added security, remove these two rules. -# -# If you want to isolate LAN1 and LAN2, but still want -# to give exposed hosts free reign with each other, get -# rid of rule 01010 and keep rule 01011. -# -# (commented out, uncomment for less restrictive firewall) -#add 01010 allow all from 10.0.0.0/8 to 10.0.0.0/8 -#add 01011 allow all from 192.100.5.0/24 to 192.100.5.0/24 -# - -# SPECIFIC SERVICES ALLOWED FROM SPECIFIC LANS -# -# If using a more restrictive firewall, allow specific LANs -# access to specific services running on the firewall itself. -# In this case we assume LAN1 needs access to filesharing running -# on the firewall. If using a less restrictive firewall -# (allowing rule 01010), you do not need these rules. -# -add 01012 allow tcp from 10.0.1.0/8 to 10.0.1.1 139 -add 01012 allow udp from 10.0.1.0/8 to 10.0.1.1 137,138 - -# GENERAL SERVICES ALLOWED TO CROSS INTERNAL AND EXPOSED LANS -# -# We allow specific UDP services through: DNS lookups, ntalk, and ntp. -# Note that internal services are protected by virtue of having -# spoof-proof internal IP addresses (10. net), so these rules -# really only apply to services bound to exposed IPs. We have -# to allow UDP fragments or larger fragmented UDP packets will -# not survive the firewall. -# -# If we want to expose high-numbered temporary service ports -# for things like DNS lookup responses we can use a port range, -# in this example 4000-65535, and we set to /etc/rc.conf variables -# on all exposed machines to make sure they bind temporary ports -# to the exposed port range (see rc.conf example above) -# -add 02000 allow udp from any to any 4000-65535,domain,ntalk,ntp -add 02500 allow udp from any to any frag - -# Allow similar services for TCP. Again, these only apply to -# services bound to exposed addresses. NOTE: we allow 'auth' -# through but do not actually run an identd server on any exposed -# port. This allows the machine being authed to respond with a -# TCP RESET. Throwing the packet away would result in delays -# when connecting to remote services that do reverse ident lookups. -# -# Note that we do not allow tcp fragments through, and that we do -# not allow fragments in general (except for UDP fragments). We -# expect the TCP mtu discovery protocol to work properly so there -# should be no TCP fragments. -# -add 03000 allow tcp from any to any http,https -add 03000 allow tcp from any to any 4000-65535,ssh,smtp,domain,ntalk -add 03000 allow tcp from any to any auth,pop3,ftp,ftp-data - -# It is important to allow certain ICMP types through, here is a list -# of general ICMP types. Note that it is important to let ICMP type 3 -# through. -# -# 0 Echo Reply -# 3 Destination Unreachable (used by TCP MTU discovery, aka -# packet-too-big) -# 4 Source Quench (typically not allowed) -# 5 Redirect (typically not allowed - can be dangerous!) -# 8 Echo -# 11 Time Exceeded -# 12 Parameter Problem -# 13 Timestamp -# 14 Timestamp Reply -# -# Sometimes people need to allow ICMP REDIRECT packets, which is -# type 5, but if you allow it make sure that your Internet router -# disallows it. - -add 04000 allow icmp from any to any icmptypes 0,3,8,11,12,13,14 - -# log any remaining fragments that get through. Might be useful, -# otherwise do not bother. Have a final deny rule as a safety to -# guarantee that your firewall is inclusive no matter how the kernel -# is configured. -# -add 05000 deny log ip from any to any frag -add 06000 deny all from any to any</pre> -</div> -</section> -<section class="Sh"> -<h1 class="Sh" id="PORT_BINDING_INTERNAL_AND_EXTERNAL_SERVICES"><a class="permalink" href="#PORT_BINDING_INTERNAL_AND_EXTERNAL_SERVICES">PORT - BINDING INTERNAL AND EXTERNAL SERVICES</a></h1> -<p class="Pp">We have mentioned multi-homing hosts and binding services to - internal or external addresses but we have not really explained it. When you - have a host with multiple IP addresses assigned to it, you can bind services - run on that host to specific IPs or interfaces rather than all IPs. Take the - firewall machine for example: with three interfaces and two exposed IP - addresses on one of those interfaces, the firewall machine is known by 5 - different IP addresses (10.0.0.1, 10.0.1.1, 10.0.2.1, 192.100.5.5, and say - 192.100.5.1). If the firewall is providing file sharing services to the - windows LAN segment (say it is LAN1), you can use samba's 'bind interfaces' - directive to specifically bind it to just the LAN1 IP address. That way the - file sharing services will not be made available to other LAN segments. The - same goes for NFS. If LAN2 has your UNIX engineering workstations, you can - tell nfsd to bind specifically to 10.0.2.1. You can specify how to bind - virtually every service on the machine and you can use a light - <a class="Xr">jail(8)</a> to indirectly bind services that do not otherwise - give you the option.</p> -</section> -<section class="Sh"> -<h1 class="Sh" id="SEE_ALSO"><a class="permalink" href="#SEE_ALSO">SEE - ALSO</a></h1> -<p class="Pp"><a class="Xr">dummynet(4)</a>, <a class="Xr">ipnat(5)</a>, - <a class="Xr">rc.conf(5)</a>, <a class="Xr">smb.conf(5)</a> - (<span class="Pa">ports/net/samba</span>), <a class="Xr">samba(7)</a> - (<span class="Pa">ports/net/samba</span>), <a class="Xr">config(8)</a>, - <a class="Xr">ipfw(8)</a>, <a class="Xr">ipnat(8)</a>, - <a class="Xr">jail(8)</a>, <a class="Xr">natd(8)</a>, - <a class="Xr">nfsd(8)</a></p> -</section> -<section class="Sh"> -<h1 class="Sh" id="ADDITIONAL_READING"><a class="permalink" href="#ADDITIONAL_READING">ADDITIONAL - READING</a></h1> -<dl class="Bl-tag"> - <dt><code class="Nm">Ipfilter</code></dt> - <dd><a class="Xr">ipf(5)</a>, <a class="Xr">ipf(8)</a>, - <a class="Xr">ipfstat(8)</a></dd> - <dt><code class="Nm">Packet Filter</code></dt> - <dd><a class="Xr">pf.conf(5)</a>, <a class="Xr">pfctl(8)</a>, - <a class="Xr">pflogd(8)</a></dd> -</dl> -</section> -<section class="Sh"> -<h1 class="Sh" id="HISTORY"><a class="permalink" href="#HISTORY">HISTORY</a></h1> -<p class="Pp">The <code class="Nm">firewall</code> manual page was originally - written by <span class="An">Matthew Dillon</span> and first appeared in - <span class="Ux">FreeBSD 4.3</span>, May 2001.</p> -</section> -</div> -<table class="foot"> - <tr> - <td class="foot-date">May 26, 2001</td> - <td class="foot-os">FreeBSD 15.0</td> - </tr> -</table> |