From 73c10cce602b166f024a69f23b8d5af0d19b3998 Mon Sep 17 00:00:00 2001 From: Dru Lavigne Date: Tue, 18 Feb 2014 22:23:51 +0000 Subject: [PATCH] White space fix only. Translators can ignore. Sponsored by: iXsystems --- .../books/handbook/firewalls/chapter.xml | 1178 ++++++++--------- 1 file changed, 578 insertions(+), 600 deletions(-) diff --git a/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml b/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml index c475936377..3bfbf61bd2 100644 --- a/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml +++ b/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml @@ -143,7 +143,7 @@ in a normal session conversation. For a good introduction, refer to Daryl's - TCP/IP Primer. + TCP/IP Primer. @@ -628,15 +628,16 @@ pass proto udp to any port $udp_services keep state A Simple Gateway with NAT This section demonstrates how to configure a &os; system - running PF to act - as a gateway for at least one other machine. The gateway - needs at least two network interfaces, each connected to a - separate network. In this example, xl1 is connected to the - Internet and xl0 is connected to the internal network. + running PF to act as a gateway + for at least one other machine. The gateway needs at least + two network interfaces, each connected to a separate + network. In this example, xl1 is + connected to the Internet and xl0 is + connected to the internal network. - First, enable the gateway in order to let the - machine forward the network traffic it receives on one - interface to another interface. This sysctl + First, enable the gateway in order to let the machine + forward the network traffic it receives on one interface to + another interface. This sysctl setting will forward IPv4 packets: &prompt.root; sysctl net.inet.ip.forwarding=1 @@ -645,74 +646,71 @@ pass proto udp to any port $udp_services keep state &prompt.root; sysctl net.inet6.ip6.forwarding=1 - To enable these settings at system boot, add the following - to - /etc/rc.conf: + To enable these settings at system boot, add the + following to /etc/rc.conf: gateway_enable="YES" #for ipv4 ipv6_gateway_enable="YES" #for ipv6 - Verify with ifconfig that - both of the interfaces are up and - running. + Verify with ifconfig that both of the + interfaces are up and running. Next, create the PF rules to - allow the gateway to pass traffic. While the following rule allows stateful traffic to - pass from the Internet - to hosts on the network, the to keyword does not - guarantee passage all the way from source to destination: + allow the gateway to pass traffic. While the following rule + allows stateful traffic to pass from the Internet to hosts + on the network, the to keyword does not + guarantee passage all the way from source to + destination: pass in on xl1 from xl1:network to xl0:network port $ports keep state - That rule only lets the traffic pass in to the gateway on - the internal interface. To let the packets go further, a + That rule only lets the traffic pass in to the gateway + on the internal interface. To let the packets go further, a matching rule is needed: pass out on xl0 from xl1:network to xl0:network port $ports keep state While these two rules will work, rules this specific are - rarely needed. For a busy network admin, a readable ruleset is a safer - ruleset. The remainder of this section demonstrates how to - keep the rules as simple as possible - for readability. For example, those two rules could be + rarely needed. For a busy network admin, a readable ruleset + is a safer ruleset. The remainder of this section + demonstrates how to keep the rules as simple as possible for + readability. For example, those two rules could be replaced with one rule: pass from xl1:network to any port $ports keep state - The - interface:network notation can be - replaced with a macro to make the ruleset even - more readable. For example, a $localnet macro could - be defined as the network directly attached to the + The interface:network notation can be + replaced with a macro to make the ruleset even more + readable. For example, a $localnet macro + could be defined as the network directly attached to the internal interface ($xl1:network). Alternatively, the definition of $localnet could be changed to an IP address/netmask notation to denote - a network, such as 192.168.100.1/24 for - a subnet of private addresses. + a network, such as 192.168.100.1/24 for a + subnet of private addresses. If required, $localnet could even be defined as a list of networks. Whatever the specific needs, a sensible $localnet definition could be - used in a - typical pass rule as follows: + used in a typical pass rule as follows: pass from $localnet to any port $ports keep state - The following sample ruleset allows all traffic initiated by - machines on the internal network. It first defines two - macros to represent the external and internal 3COM interfaces of - the gateway. - - - For dialup users, the external interface will use - tun0. For an - ADSL connection, specifically those - using PPP over Ethernet (PPPoE), the correct external - interface is tun0, - not the physical Ethernet - interface. - + The following sample ruleset allows all traffic + initiated by machines on the internal network. It first + defines two macros to represent the external and internal + 3COM interfaces of the gateway. + + + For dialup users, the external interface will use + tun0. For an + ADSL connection, specifically those + using PPP over Ethernet + (PPPoE), the correct external + interface is tun0, not the physical + Ethernet interface. + ext_if = "xl0" # macro for external interface - use tun0 for PPPoE int_if = "xl1" # macro for internal interface @@ -722,20 +720,20 @@ nat on $ext_if from $localnet to any -> ($ext_if) block all pass from { lo0, $localnet } to any keep state - This ruleset introduces the nat rule which is used to - handle the network address translation from the - non-routable addresses inside the internal network to the IP address - assigned to the external interface. The parentheses surrounding the last part of the nat - rule ($ext_if) is included - when the IP address of the external - interface is dynamically assigned. It - ensures that network traffic runs without serious - interruptions even if the external IP address - changes. + This ruleset introduces the nat rule + which is used to handle the network address translation from + the non-routable addresses inside the internal network to + the IP address assigned to the external + interface. The parentheses surrounding the last part of the + nat rule ($ext_if) is included when the + IP address of the external interface is + dynamically assigned. It ensures that network traffic runs + without serious interruptions even if the external + IP address changes. - Note that this ruleset probably allows more - traffic to pass out of the network than is needed. - One reasonable setup could create this macro: + Note that this ruleset probably allows more traffic to + pass out of the network than is needed. One reasonable + setup could create this macro: client_out = "{ ftp-data, ftp, ssh, domain, pop3, auth, nntp, http, \ https, cvspserver, 2628, 5999, 8000, 8080 }" @@ -751,27 +749,24 @@ pass from { lo0, $localnet } to any keep state pass in inet proto tcp to $ext_if port ssh This macro definition and rule allows - DNS and NTP for internal - clients: + DNS and NTP for + internal clients: udp_services = "{ domain, ntp }" pass quick inet proto { tcp, udp } to any port $udp_services keep state - Note the quick keyword in this - rule. Since the ruleset consists of - several rules, it is important to understand the - relationships between the rules in a ruleset. Rules - are evaluated from top to bottom, in the sequence they are - written. For each packet or - connection evaluated by PF, + Note the quick keyword in this rule. + Since the ruleset consists of several rules, it is important + to understand the relationships between the rules in a + ruleset. Rules are evaluated from top to bottom, in the + sequence they are written. For each packet or connection + evaluated by PF, the last matching rule in the ruleset - is the one which is applied. However, - when a packet matches a rule which - contains the quick keyword, - the rule processing stops and the packet is treated - according to that rule. This is very - useful when an exception to the general rules - is needed. + is the one which is applied. However, when a packet matches + a rule which contains the quick keyword, + the rule processing stops and the packet is treated + according to that rule. This is very useful when an + exception to the general rules is needed. @@ -781,7 +776,8 @@ pass quick inet proto { tcp, udp } to any port $udp_services keep stateFTP protocol. FTP pre-dates firewalls by several decades and is insecure in its design. The most - common points against using FTP include: + common points against using FTP + include: @@ -800,52 +796,49 @@ pass quick inet proto { tcp, udp } to any port $udp_services keep state - All of these points present security challenges, - even before considering any potential security weaknesses in client - or server software. More - secure alternatives for file transfer exist, such as &man.sftp.1; - or &man.scp.1;, which both feature authentication and data - transfer over encrypted connections.. + All of these points present security challenges, even + before considering any potential security weaknesses in + client or server software. More secure alternatives for + file transfer exist, such as &man.sftp.1; or &man.scp.1;, + which both feature authentication and data transfer over + encrypted connections.. For those situations when FTP is required, PF provides redirection of FTP traffic to a small - proxy program called - &man.ftp-proxy.8;, which is included in the base system of &os;. - The role of - the proxy is to dynamically insert and delete rules in the ruleset, using - a set of anchors, in order to correctly handle + proxy program called &man.ftp-proxy.8;, which is included in + the base system of &os;. The role of the proxy is to + dynamically insert and delete rules in the ruleset, using a + set of anchors, in order to correctly handle FTP traffic. - To enable the FTP proxy, add this line to - /etc/rc.conf: + To enable the FTP proxy, add this + line to /etc/rc.conf: ftpproxy_enable="YES" - Then start the proxy by running - service ftp-proxy start. + Then start the proxy by running service + ftp-proxy start. - For a basic configuration, three elements need to - be added to /etc/pf.conf. First, the - anchors which the proxy will use to insert the rules it generates for the - FTP sessions: + For a basic configuration, three elements need to be + added to /etc/pf.conf. First, the + anchors which the proxy will use to insert the rules it + generates for the FTP sessions: nat-anchor "ftp-proxy/*" rdr-anchor "ftp-proxy/*" - Second, a pass rule is - needed to allow FTP traffic in to the - proxy. + Second, a pass rule is needed to allow + FTP traffic in to the proxy. Third, redirection and NAT rules need - to be defined before the - filtering rules. Insert this rdr rule immediately - after the nat rule: + to be defined before the filtering rules. Insert this + rdr rule immediately after the + nat rule: rdr pass on $int_if proto tcp from any to any port ftp -> 127.0.0.1 port 8021 - Finally, allow the redirected traffic to - pass: + Finally, allow the redirected traffic to pass: pass out proto tcp from $proxy to any port ftp @@ -882,78 +875,74 @@ rdr-anchor "ftp-proxy/*" Managing <acronym>ICMP</acronym> - Many of the tools used for debugging or - troubleshooting a TCP/IP network rely on the - Internet Control Message Protocol (ICMP), which + Many of the tools used for debugging or troubleshooting + a TCP/IP network rely on the Internet + Control Message Protocol (ICMP), which was designed specifically with debugging in mind. - The ICMP protocol sends and - receives control messages between - hosts and gateways, mainly to provide feedback to a sender - about any unusual or difficult conditions enroute to the - target host. + The ICMP protocol sends and receives + control messages between hosts and + gateways, mainly to provide feedback to a sender about any + unusual or difficult conditions enroute to the target host. Routers use ICMP to negotiate packet sizes and other transmission parameters in a process often referred to as path MTU discovery. - From a firewall perspective, some ICMP - control messages are vulnerable to known attack vectors. - Also, letting all diagnostic traffic pass unconditionally - makes debugging easier, but it also makes it - easier for others to extract information about - the network. For these reasons, the following rule may not be + From a firewall perspective, some + ICMP control messages are vulnerable to + known attack vectors. Also, letting all diagnostic traffic + pass unconditionally makes debugging easier, but it also + makes it easier for others to extract information about the + network. For these reasons, the following rule may not be optimal: pass inet proto icmp from any to any - One solution is to let all - ICMP traffic from the local network through - while stopping all probes from outside the network: + One solution is to let all ICMP + traffic from the local network through while stopping all + probes from outside the network: pass inet proto icmp from $localnet to any keep state pass inet proto icmp from any to $ext_if keep state - Additional - options are available which demonstrate some of - PF's flexibility. For example, - rather than allowing all ICMP messages, - one can specify the messages used by &man.ping.8; and - &man.traceroute.8;. Start by defining a macro for - that type of message: + Additional options are available which demonstrate some + of PF's flexibility. For + example, rather than allowing all ICMP + messages, one can specify the messages used by &man.ping.8; + and &man.traceroute.8;. Start by defining a macro for that + type of message: - icmp_types = "echoreq" + icmp_types = "echoreq" - and a rule which uses the macro: + and a rule which uses the macro: - pass inet proto icmp all icmp-type $icmp_types keep state + pass inet proto icmp all icmp-type $icmp_types keep state - If other types of ICMP packets - are needed, expand icmp_types - to a list of those packet types. Type - more /usr/src/contrib/pf/pfctl/pfctl_parser.c - to see the list of ICMP message - types supported by PF. Refer to - If other types of ICMP packets are + needed, expand icmp_types to a list of + those packet types. Type more + /usr/src/contrib/pf/pfctl/pfctl_parser.c to see + the list of ICMP message types supported + by PF. Refer to http://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml - for an explanation of each message type. + for an explanation of each message type. - Since Unix traceroute uses UDP - by default, another rule is needed to allow Unix - traceroute: + Since Unix traceroute uses + UDP by default, another rule is needed to + allow Unix traceroute: - # allow out the default range for traceroute(8): + # allow out the default range for traceroute(8): pass out on $ext_if inet proto udp from any to any port 33433 >< 33626 keep state - Since TRACERT.EXE on Microsoft Windows systems - uses ICMP echo request messages, - only the - first rule is needed to allow network traces from those systems. Unix traceroute - can be instructed to use other protocols as well, and will - use ICMP echo request messages if - is used. Check the &man.traceroute.8; - man page for - details. + Since TRACERT.EXE on Microsoft + Windows systems uses ICMP echo request + messages, only the first rule is needed to allow network + traces from those systems. Unix + traceroute can be instructed to use other + protocols as well, and will use ICMP echo + request messages if is used. Check the + &man.traceroute.8; man page for details. Path <acronym>MTU</acronym> Discovery @@ -962,66 +951,62 @@ pass out on $ext_if inet proto udp from any to any port 33433 >< 33626 kee independent, and one consequence of device independence is that the optimal packet size for a given connection cannot always be predicted reliably. The main constraint on - packet size is the - Maximum Transmission Unit - (MTU) which sets the upper limit on the - packet size for an interface. Type ifconfig to view the - MTUs for a system's network interfaces. + packet size is the Maximum Transmission + Unit (MTU) which sets the + upper limit on the packet size for an interface. Type + ifconfig to view the + MTUs for a system's network + interfaces. - TCP/IP uses a process known as path - MTU discovery to - determine the right packet size for a connection. This - process sends packets of - varying sizes with the Do not fragment flag - set, expecting an ICMP return packet - of type 3, code 4 when the upper + TCP/IP uses a process known as path + MTU discovery to determine the right + packet size for a connection. This process sends packets + of varying sizes with the Do not fragment + flag set, expecting an ICMP return + packet of type 3, code 4 when the upper limit has been reached. Type 3 means destination unreachable, and code 4 is short for fragmentation needed, but the do-not-fragment flag is set. To allow path MTU discovery in order - to support connections to other MTUs, add - the - destination unreachable type to the - icmp_types macro: + to support connections to other MTUs, + add the destination unreachable type to + the icmp_types macro: icmp_types = "{ echoreq, unreach }" - Since - the pass rule already uses that macro, it does not need to - be modified in order to support the new + Since the pass rule already uses that macro, it does + not need to be modified in order to support the new ICMP type: pass inet proto icmp all icmp-type $icmp_types keep state PF allows filtering on all variations of ICMP types and codes. - The list of possible - types and codes are documented in &man.icmp.4; and - &man.icmp6.4;. + The list of possible types and codes are documented in + &man.icmp.4; and &man.icmp6.4;. Using Tables - Some types of data - are relevant to filtering and redirection at a given time, - but their definition is too long to be included in the ruleset file. + Some types of data are relevant to filtering and + redirection at a given time, but their definition is too + long to be included in the ruleset file. PF supports the use of tables, - which are defined lists that can be - manipulated without needing to reload the entire ruleset, - and which can provide fast lookups. Table names are - always enclosed within < >, like - this: + which are defined lists that can be manipulated without + needing to reload the entire ruleset, and which can provide + fast lookups. Table names are always enclosed within + < >, like this: table <clients> { 192.168.2.0/24, !192.168.2.5 } - In this example, the 192.168.2.0/24 network - is part of the table, except for the address - 192.168.2.5, which is excluded using - the ! operator. It is - also possible to load tables from files where each item is - on a separate line, as seen in this example + In this example, the 192.168.2.0/24 + network is part of the table, except for the address + 192.168.2.5, which is excluded using the + ! operator. It is also possible to load + tables from files where each item is on a separate line, as + seen in this example /etc/clients: 192.168.2.0/24 @@ -1036,33 +1021,34 @@ pass out on $ext_if inet proto udp from any to any port 33433 >< 33626 kee pass inet proto tcp from <clients> to any port $client_out flags S/SA keep state - A table's contents can be manipulated live, using pfctl. - This example adds another network to the table: + A table's contents can be manipulated live, using + pfctl. This example adds another network + to the table: &prompt.root; pfctl -t clients -T add 192.168.1.0/16 - Note that any changes made this way will take affect now, - making them ideal for testing, - but will not survive a power - failure or reboot. To make the changes permanent, modify the - definition of the table in the ruleset or edit the file that the - table refers to. One can maintain the on-disk copy of the table - using a &man.cron.8; job which dumps the table's contents to - disk at regular intervals, using a command such as - pfctl -t clients -T show + Note that any changes made this way will take affect + now, making them ideal for testing, but will not survive a + power failure or reboot. To make the changes permanent, + modify the definition of the table in the ruleset or edit + the file that the table refers to. One can maintain the + on-disk copy of the table using a &man.cron.8; job which + dumps the table's contents to disk at regular intervals, + using a command such as pfctl -t clients -T show >/etc/clients. Alternatively, - /etc/clients can be updated with - the in-memory table contents: + /etc/clients can be updated with the + in-memory table contents: &prompt.root; pfctl -t clients -T replace -f /etc/clients - Using Overload Tables to Protect <acronym>SSH</acronym> + Using Overload Tables to Protect + <acronym>SSH</acronym> - Those who run SSH on an external interface - have probably seen something - like this in the authentication logs: + Those who run SSH on an external + interface have probably seen something like this in the + authentication logs: Sep 26 03:12:34 skapet sshd[25771]: Failed password for root from 200.72.41.31 port 40992 ssh2 Sep 26 03:12:34 skapet sshd[5279]: Failed password for root from 200.72.41.31 port 40992 ssh2 @@ -1072,29 +1058,26 @@ Sep 26 03:12:44 skapet sshd[24703]: input_userauth_request: invalid user admin Sep 26 03:12:44 skapet sshd[24703]: Failed password for invalid user admin from 200.72.41.31 port 41484 ssh2 This is indicative of a brute force attack where - somebody or some program - is trying to discover the - user name and password which will let them - into the system. + somebody or some program is trying to discover the user name + and password which will let them into the system. If external SSH access is needed for legitimate users, changing the default port used by - SSH can offer some protection. - However, PF provides a more - elegant solution. Pass rules can contain - limits on what connecting hosts can do and - violators can be banished to a table of - addresses which are denied some or all access. It - is even possible to drop all existing connections from - machines which overreach the limits. + SSH can offer some protection. However, + PF provides a more elegant + solution. Pass rules can contain limits on what connecting + hosts can do and violators can be banished to a table of + addresses which are denied some or all access. It is even + possible to drop all existing connections from machines + which overreach the limits. - To configure this, create this table in the tables section - of the ruleset: + To configure this, create this table in the tables + section of the ruleset: table <bruteforce> persist - Then, somewhere early in the ruleset, add rules - to block brute access while allowing legitimate access: + Then, somewhere early in the ruleset, add rules to block + brute access while allowing legitimate access: block quick from <bruteforce> pass inet proto tcp from any to $localnet port $tcp_services \ @@ -1110,18 +1093,20 @@ pass inet proto tcp from any to $localnet port $tcp_services \ simultaneous connections allowed from one host. max-src-conn-rate is the rate of new - connections allowed from any single host (15) - per number of seconds (5). + connections allowed from any single host + (15) per number of seconds + (5). overload <bruteforce> means that any host which exceeds these limits gets its address - added to the bruteforce table. The ruleset - blocks all traffic from addresses in the bruteforce - table. + added to the bruteforce table. The + ruleset blocks all traffic from addresses in the + bruteforce table. Finally, flush global says that when - a host reaches the limit, that all (global) of that host's connections will be - terminated (flush). + a host reaches the limit, that all + (global) of that host's connections will + be terminated (flush). These rules will not block slow @@ -1129,10 +1114,10 @@ pass inet proto tcp from any to $localnet port $tcp_services \ xlink:href="http://home.nuug.no/~peter/hailmary2013/">http://home.nuug.no/~peter/hailmary2013/. - This example ruleset - is intended mainly as an illustration. For example, if a generous number of connections in - general are wanted, but the desire is to be more - restrictive when it comes to + This example ruleset is intended mainly as an + illustration. For example, if a generous number of + connections in general are wanted, but the desire is to be + more restrictive when it comes to ssh, supplement the rule above with something like the one below, early on in the rule set: @@ -1146,481 +1131,474 @@ pass inet proto tcp from any to $localnet port $tcp_services \ It May Not be Necessary to Block All Overloaders - It is worth noting that the - overload mechanism is a general - technique which does not apply exclusively to - SSH, and it is not always - optimal to entirely block all traffic from offenders. + It is worth noting that the overload mechanism is a + general technique which does not apply exclusively to + SSH, and it is not always optimal to + entirely block all traffic from offenders. For example, an overload rule could be used to protect a mail service or a web service, and the overload table could be used in a rule to assign offenders to a - queue with a minimal bandwidth allocation or - to redirect to a specific web page. + queue with a minimal bandwidth allocation or to redirect + to a specific web page. - Over time, tables will be filled by - overload rules and their size - will grow incrementally, taking up more memory. - Sometimes an IP address that is blocked - is a dynamically assigned - one, which has since been assigned to a host who - has a legitimate reason to communicate with hosts in - the local network. + Over time, tables will be filled by overload rules and + their size will grow incrementally, taking up more memory. + Sometimes an IP address that is blocked + is a dynamically assigned one, which has since been assigned + to a host who has a legitimate reason to communicate with + hosts in the local network. - For situations like these, - pfctl provides the ability to - expire table entries. For example, this - command will remove <bruteforce> - table entries which have not been referenced for 86400 - seconds: + For situations like these, + pfctl provides the ability to + expire table entries. For example, this command will remove + <bruteforce> table entries which + have not been referenced for 86400 + seconds: - &prompt.root; pfctl -t bruteforce -T expire 86400 + &prompt.root; pfctl -t bruteforce -T expire 86400 - Similar functionality is provided by - security/expiretable, which - removes table entries which have not been accessed for a - specified period of time. + Similar functionality is provided by + security/expiretable, which removes table + entries which have not been accessed for a specified period + of time. - Once installed, - expiretable can be run to remove - <bruteforce> table entries older - than a specified age. This example removes all entries - older than 24 hours: + Once installed, expiretable + can be run to remove <bruteforce> + table entries older than a specified age. This example + removes all entries older than 24 hours: - /usr/local/sbin/expiretable -v -d -t 24h bruteforce + /usr/local/sbin/expiretable -v -d -t 24h bruteforce - - Protecting Against <acronym>SPAM</acronym> + + Protecting Against <acronym>SPAM</acronym> - Not to be confused with the - spamd daemon which comes - bundled with spamassassin, the - PF companion - spamd was designed to run on a - PF gateway to form part of the outer defense against spam. - spamd hooks into the - PF configuration via a set of - redirections. + Not to be confused with the + spamd daemon which comes + bundled with spamassassin, the + PF companion + spamd was designed to run on a + PF gateway to form part of the outer defense against spam. + spamd hooks into the + PF configuration via a set of + redirections. - The main point underlying the - spamd design is the fact that - spammers send a large number of messages, and the - probability that you are the first person receiving a - particular message is incredibly small. In addition, - spam is mainly sent via a few spammer friendly networks - and a large number of hijacked machines. Both the - individual messages and the machines will be reported to - blacklists fairly quickly, and this is the kind of data - spamd can use to our advantage - with blacklists. + The main point underlying the + spamd design is the fact that + spammers send a large number of messages, and the + probability that you are the first person receiving a + particular message is incredibly small. In addition, + spam is mainly sent via a few spammer friendly networks + and a large number of hijacked machines. Both the + individual messages and the machines will be reported to + blacklists fairly quickly, and this is the kind of data + spamd can use to our advantage + with blacklists. - What spamd does to SMTP - connections from addresses in the blacklist is to - present its banner and immediately switch to a mode - where it answers SMTP traffic one byte at the time. This - technique, which is intended to waste as much time as - possible on the sending end while costing the receiver - pretty much nothing, is called - tarpitting. The specific - implementation with one byte SMTP replies is often - referred to as stuttering. + What spamd does to SMTP + connections from addresses in the blacklist is to + present its banner and immediately switch to a mode + where it answers SMTP traffic one byte at the time. This + technique, which is intended to waste as much time as + possible on the sending end while costing the receiver + pretty much nothing, is called + tarpitting. The specific + implementation with one byte SMTP replies is often + referred to as stuttering. - This example demonstrates the basic procedure for setting up - spamd with automatically - updated blacklists: + This example demonstrates the basic procedure for + setting up spamd with + automatically updated blacklists: - - - Install the mail/spamd/ port. - In particular, be sure to read the package message - and act upon what it says. Specifically, to use - spamd's greylisting - features, a file descriptor file system (see fdescfs(5)) - must be mounted at /dev/fd/. - Do this by adding the following line to - /etc/fstab: + + + Install the mail/spamd/ port. + In particular, be sure to read the package message + and act upon what it says. Specifically, to use + spamd's greylisting + features, a file descriptor file system (see fdescfs(5)) + must be mounted at /dev/fd/. + Do this by adding the following line to + /etc/fstab: - fdescfs /dev/fd fdescfs rw 0 0 + fdescfs /dev/fd fdescfs rw 0 0 - Make sure the fdescfs code - is in the kernel, either compiled in or by loading - the module with &man.kldload.8;. - + Make sure the fdescfs code + is in the kernel, either compiled in or by loading + the module with &man.kldload.8;. + - - Next, edit the ruleset to include + + Next, edit the ruleset to include - table <spamd> persist + table <spamd> persist table <spamd-white> persist rdr pass on $ext_if inet proto tcp from <spamd> to \ { $ext_if, $localnet } port smtp -> 127.0.0.1 port 8025 rdr pass on $ext_if inet proto tcp from !<spamd-white> to \ { $ext_if, $localnet } port smtp -> 127.0.0.1 port 8025 - The two tables <spamd> and - <spamd-white> are essential. SMTP traffic - from the addresses in the first table plus the ones - which are not in the other table are redirected to a - daemon listening at port 8025. - + The two tables <spamd> and + <spamd-white> are essential. SMTP traffic + from the addresses in the first table plus the ones + which are not in the other table are redirected to a + daemon listening at port 8025. + - - The next step is to set up - spamd's own configuration - in /usr/local/etc/spamd.conf - supplemented by rc.conf - parameters. + + The next step is to set up + spamd's own configuration + in /usr/local/etc/spamd.conf + supplemented by rc.conf + parameters. - The supplied sample file offers quite a bit of - explanation, and the man page offers additional - information, but we will recap the essentials - here. + The supplied sample file offers quite a bit of + explanation, and the man page offers additional + information, but we will recap the essentials + here. - One of the first lines without a - # comment sign at the start - contains the block which defines the - all list, which specifies the - lists actually used: + One of the first lines without a + # comment sign at the start + contains the block which defines the + all list, which specifies the + lists actually used: - all:\ + all:\ :traplist:whitelist: - Here, all the desired black lists are added, - separated by colons (:). To use - whitelists to subtract addresses from the blacklist, - add the name of the whitelist immediately after the - name of each blacklist, i.e., - :blacklist:whitelist:. + Here, all the desired black lists are added, + separated by colons (:). To use + whitelists to subtract addresses from the blacklist, + add the name of the whitelist immediately after the + name of each blacklist, i.e., + :blacklist:whitelist:. - Next up is a blacklist definition: + Next up is a blacklist definition: - traplist:\ + traplist:\ :black:\ :msg="SPAM. Your address %A has sent spam within the last 24 hours":\ :method=http:\ :file=www.openbsd.org/spamd/traplist.gz - Following the name, the first data field - specifies the list type, in this case - black. The - msg field contains the message to - display to blacklisted senders during the SMTP - dialogue. The method field - specifies how spamd-setup fetches the list data, - here http. The other options are - fetching via ftp, from a - file in a mounted file system or - via exec of an external program. - Finally the file field specifies - the name of the file spamd expects to - receive. + Following the name, the first data field + specifies the list type, in this case + black. The + msg field contains the message to + display to blacklisted senders during the SMTP + dialogue. The method field + specifies how spamd-setup fetches the list data, + here http. The other options are + fetching via ftp, from a + file in a mounted file system or + via exec of an external program. + Finally the file field specifies + the name of the file spamd expects to receive. - The definition of a whitelist follows much the - same pattern: + The definition of a whitelist follows much the + same pattern: - whitelist:\ + whitelist:\ :white:\ :method=file:\ :file=/var/mail/whitelist.txt - but omits the message parameters since a - message is not needed. + but omits the message parameters since a + message is not needed. - - Choose Data Sources with Care + + Choose Data Sources with Care - Using all the blacklists in the sample - spamd.conf will end up - blacklisting large blocks of the Internet, - including several Asian nations. Administrators - need to edit the file to end up with an optimal - configuration. The administrator is the judge of - which data sources to use, and using lists other - than the ones suggested in the sample file is - possible. - + Using all the blacklists in the sample + spamd.conf will end up + blacklisting large blocks of the Internet, + including several Asian nations. Administrators + need to edit the file to end up with an optimal + configuration. The administrator is the judge of + which data sources to use, and using lists other + than the ones suggested in the sample file is + possible. + - Put the lines for spamd and any startup - parameters desired in - /etc/rc.conf, for - example: + Put the lines for spamd and any startup + parameters desired in /etc/rc.conf, + for example: - spamd_flags="-v" # for normal use: "" and see spamd-setup(8) + spamd_flags="-v" # for normal use: "" and see spamd-setup(8) - When done with editing the setup, - reload the ruleset, start - spamd with the options - desired using the - /usr/local/etc/rc.d/obspamd - script, and complete the configuration using - spamd-setup. Finally, create a - &man.cron.8; job which calls - spamd-setup to update the tables - at reasonable intervals. - - + When done with editing the setup, reload the + ruleset, start spamd with the + options desired using the + /usr/local/etc/rc.d/obspamd + script, and complete the configuration using + spamd-setup. Finally, create a + &man.cron.8; job which calls + spamd-setup to update the tables + at reasonable intervals. + + - On a typical gateway in front of a mail server, - hosts will start getting trapped within a few seconds to - several minutes. + On a typical gateway in front of a mail server, + hosts will start getting trapped within a few seconds to + several minutes. - - Adding Greylisting to the Setup + + Adding Greylisting to the Setup - spamd also supports - greylisting, which works by - rejecting messages from unknown hosts temporarily with - 45n codes, letting messages - from hosts which try again within a reasonable time - through. Traffic from well behaved hosts, that is, - senders which are set up to behave within the limits set - up in the relevant RFCs - The relevant RFCs are mainly RFC1123 - and RFC2821., will be let - through. + spamd also supports + greylisting, which works by + rejecting messages from unknown hosts temporarily with + 45n codes, letting messages + from hosts which try again within a reasonable time + through. Traffic from well behaved hosts, that is, + senders which are set up to behave within the limits set + up in the relevant RFCs + The relevant RFCs are mainly RFC1123 + and RFC2821., will be let + through. - Greylisting as a technique was presented in a 2003 - paper by Evan Harris - The original - Harris paper and a number of other useful articles - and resources can be found at the greylisting.org - web site., and a number of - implementations followed over the next few months. - OpenBSD's spamd acquired its - ability to greylist in OpenBSD 3.5, which was released - in May 2004. + Greylisting as a technique was presented in a 2003 + paper by Evan Harris + The original + Harris paper and a number of other useful articles + and resources can be found at the greylisting.org + web site., and a number of + implementations followed over the next few months. + OpenBSD's spamd acquired its + ability to greylist in OpenBSD 3.5, which was released + in May 2004. - The most amazing thing about greylisting, apart - from its simplicity, is that it still works. Spammers - and malware writers have been very slow to adapt. + The most amazing thing about greylisting, apart + from its simplicity, is that it still works. Spammers + and malware writers have been very slow to adapt. - The basic procedure for adding greylisting to your - setup follows below. + The basic procedure for adding greylisting to your + setup follows below. - - - If not done already, make sure the - file descriptor file system (see &man.fdescfs.5;) is - mounted at /dev/fd/. Do this - by adding the following line to - /etc/fstab: + + + If not done already, make sure the + file descriptor file system (see &man.fdescfs.5;) is + mounted at /dev/fd/. Do this + by adding the following line to + /etc/fstab: - fdescfs /dev/fd fdescfs rw 0 0 + fdescfs /dev/fd fdescfs rw 0 0 - and make sure the &man.fdescfs.5; code is in the - kernel, either compiled in or by loading the module - with &man.kldload.8;. - + and make sure the &man.fdescfs.5; code is in the + kernel, either compiled in or by loading the module + with &man.kldload.8;. + - - To run spamd in - greylisting mode, /etc/rc.conf - must be changed slightly by adding + + To run spamd in + greylisting mode, /etc/rc.conf + must be changed slightly by adding - spamd_grey="YES" # use spamd greylisting if YES + spamd_grey="YES" # use spamd greylisting if YES - Several greylisting related parameters can be - fine-tuned with spamd's command - line parameters and the corresponding - /etc/rc.conf settings. Check - the spamd man page to see - what the parameters mean. - + Several greylisting related parameters can be + fine-tuned with spamd's command + line parameters and the corresponding + /etc/rc.conf settings. Check + the spamd man page to see + what the parameters mean. + - - To complete the greylisting setup, restart - spamd using the - /usr/local/etc/rc.d/obspamd - script. - - + + To complete the greylisting setup, restart + spamd using the + /usr/local/etc/rc.d/obspamd + script. + + - Behind the scenes, rarely mentioned and barely - documented are two of spamd's - helpers, the spamdb database - tool and the spamlogd - whitelist updater, which both perform essential - functions for the greylisting feature. Of the two - spamlogd works quietly in the - background, while spamdb has - been developed to offer some interesting - features. + Behind the scenes, rarely mentioned and barely + documented are two of spamd's + helpers, the spamdb database + tool and the spamlogd + whitelist updater, which both perform essential + functions for the greylisting feature. Of the two + spamlogd works quietly in the + background, while spamdb has + been developed to offer some interesting + features. - - Restart <application>spamd</application> to - Enable Greylisting + + Restart <application>spamd</application> to + Enable Greylisting - After following all steps in the tutorial - exactly up to this point, - spamlogd has been started - automatically already. However, if the initial - spamd configuration did not - include greylisting, - spamlogd may not have been - started, and there may be strange symptoms, such as - greylists and whitelists not getting updated - properly. + After following all steps in the tutorial + exactly up to this point, + spamlogd has been started + automatically already. However, if the initial + spamd configuration did not + include greylisting, + spamlogd may not have been + started, and there may be strange symptoms, such as + greylists and whitelists not getting updated + properly. - Under normal circumstances, it should not be - necessary to start spamlogd - by hand. Restarting spamd - after enabling greylisting ensures - spamlogd is loaded and - available too. - + Under normal circumstances, it should not be + necessary to start spamlogd + by hand. Restarting spamd + after enabling greylisting ensures + spamlogd is loaded and + available too. + - spamdb is the - administrator's main interface to managing the black, - grey and white lists via the contents of the - /var/db/spamdb database. + spamdb is the + administrator's main interface to managing the black, + grey and white lists via the contents of the + /var/db/spamdb database. - - Network Hygiene + + Network Hygiene - This section describes how - block-policy, scrub, - and antispoof can be used to make the - ruleset behave sanely. + This section describes how + block-policy, scrub, + and antispoof can be used to make the + ruleset behave sanely. - block-policy is an option which - can be set in the options part of the - ruleset, which precedes the redirection and filtering - rules. This option determines which feedback, if any, - PF will give to hosts which - try to create connections which are subsequently - blocked. The option has two possible values, - drop, which drops blocked packets - with no feedback, and return, which - returns with status codes such as - Connection refused or - similar. + block-policy is an option which + can be set in the options part of the + ruleset, which precedes the redirection and filtering + rules. This option determines which feedback, if any, + PF will give to hosts which + try to create connections which are subsequently + blocked. The option has two possible values, + drop, which drops blocked packets + with no feedback, and return, which + returns with status codes such as + Connection refused or + similar. - The correct strategy for block policies has been the - subject of rather a lot of discussion. We choose to - play nicely and instruct our firewall to issue - returns: + The correct strategy for block policies has been the + subject of rather a lot of discussion. We choose to + play nicely and instruct our firewall to issue + returns: - set block-policy return + set block-policy return - In PF versions up to - OpenBSD 4.5 inclusive, scrub is a - keyword which enables network packet normalization, - causing fragmented packets to be assembled and removing - ambiguity. Enabling scrub provides a - measure of protection against certain kinds of attacks - based on incorrect handling of packet fragments. A - number of supplementing options are available, but we - choose the simplest form which is suitable for most - configurations. + In PF versions up to + OpenBSD 4.5 inclusive, scrub is a + keyword which enables network packet normalization, + causing fragmented packets to be assembled and removing + ambiguity. Enabling scrub provides a + measure of protection against certain kinds of attacks + based on incorrect handling of packet fragments. A + number of supplementing options are available, but we + choose the simplest form which is suitable for most + configurations. - scrub in all + scrub in all - Some services, such as NFS, require some specific - fragment handling options. This is extensively - documented in the PF user - guide and man pages provide all the information you - could need. + Some services, such as NFS, require some specific + fragment handling options. This is extensively + documented in the PF user + guide and man pages provide all the information you + could need. - One fairly common example is this, + One fairly common example is this, - scrub in all fragment reassemble no-df max-mss 1440 + scrub in all fragment reassemble no-df max-mss 1440 - meaning, we reassemble fragments, clear the - do not fragment bit and set the maximum - segment size to 1440 bytes. Other variations are - possible, and you should be able to cater to various - specific needs by consulting the man pages and some - experimentation. + meaning, we reassemble fragments, clear the + do not fragment bit and set the maximum + segment size to 1440 bytes. Other variations are + possible, and you should be able to cater to various + specific needs by consulting the man pages and some + experimentation. - antispoof is a common special - case of filtering and blocking. This mechanism protects - against activity from spoofed or forged IP addresses, - mainly by blocking packets appearing on interfaces and - in directions which are logically not possible. + antispoof is a common special + case of filtering and blocking. This mechanism protects + against activity from spoofed or forged IP addresses, + mainly by blocking packets appearing on interfaces and + in directions which are logically not possible. - We specify that we want to weed out spoofed traffic - coming in from the rest of the world and any spoofed - packets which, however unlikely, were to originate in - our own network: + We specify that we want to weed out spoofed traffic + coming in from the rest of the world and any spoofed + packets which, however unlikely, were to originate in + our own network: - antispoof for $ext_if + antispoof for $ext_if antispoof for $int_if - + - - Handling Non-Routable Addresses from - Elsewhere + + Handling Non-Routable Addresses from + Elsewhere - Even with a properly configured gateway to handle - network address translation for your own network, you - may find yourself in the unenviable position of having - to compensate for other people's - misconfigurations. + Even with a properly configured gateway to handle + network address translation for your own network, you + may find yourself in the unenviable position of having + to compensate for other people's + misconfigurations. - One depressingly common class of misconfigurations - is the kind which lets traffic with non-routable - addresses out to the Internet. Traffic from - non-routeable addresses have also played a part in - several DOS attack techniques, so it may be worth - considering explicitly blocking traffic from - non-routeable addresses from entering your - network. + One depressingly common class of misconfigurations + is the kind which lets traffic with non-routable + addresses out to the Internet. Traffic from + non-routeable addresses have also played a part in + several DOS attack techniques, so it may be worth + considering explicitly blocking traffic from + non-routeable addresses from entering your + network. - One possible solution is the one outlined below, - which for good measure also blocks any attempt to - initiate contact to non-routable addresses through the - gateway's external interface: + One possible solution is the one outlined below, + which for good measure also blocks any attempt to + initiate contact to non-routable addresses through the + gateway's external interface: - martians = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, \ + martians = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, \ 10.0.0.0/8, 169.254.0.0/16, 192.0.2.0/24, \ 0.0.0.0/8, 240.0.0.0/4 }" block drop in quick on $ext_if from $martians to any block drop out quick on $ext_if from any to $martians - Here, the martians macro denotes - the RFC 1918 addresses and a few other ranges which are - mandated by various RFCs not to be in circulation on the - open Internet. Traffic to and from such addresses is - quietly dropped on the gateway's external - interface. + Here, the martians macro denotes + the RFC 1918 addresses and a few other ranges which are + mandated by various RFCs not to be in circulation on the + open Internet. Traffic to and from such addresses is + quietly dropped on the gateway's external + interface. - The specific details of how to implement this kind - of protection will vary, among other things according to - your specific network configuration. Your network - design could for example dictate that you include or - exclude other address ranges than these. + The specific details of how to implement this kind + of protection will vary, among other things according to + your specific network configuration. Your network + design could for example dictate that you include or + exclude other address ranges than these. - This completes our simple NATing firewall for a - small local network. A more thorough tutorial is - available at http://home.nuug.no/~peter/pf/, - where you will also find slides from related - presentations. + This completes our simple NATing firewall for a + small local network. A more thorough tutorial is + available at http://home.nuug.no/~peter/pf/, + where you will also find slides from related + presentations. - Viewing Traffic + Viewing Traffic Over time, a number of tools have been developed which interact with PF in various ways. - Can Erkin Acar's pftop - makes it possible to keep an eye on what passes into and - out of the network. pftop is - available through the ports system as - sysutils/pftop. The name is a strong - hint at what it does - pftop - shows a running snapshot of traffic in a format which is - strongly inspired by &man.top.1;. - + Can Erkin Acar's pftop + makes it possible to keep an eye on what passes into and + out of the network. pftop is + available through the ports system as + sysutils/pftop. The name is a strong + hint at what it does - pftop + shows a running snapshot of traffic in a format which is + strongly inspired by &man.top.1;. +