From owner-svn-doc-all@FreeBSD.ORG Tue Feb 18 22:23:52 2014 Return-Path: Delivered-To: svn-doc-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3CB0A9DD; Tue, 18 Feb 2014 22:23:52 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 22E521C49; Tue, 18 Feb 2014 22:23:52 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1IMNqjg080748; Tue, 18 Feb 2014 22:23:52 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1IMNqRG080747; Tue, 18 Feb 2014 22:23:52 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201402182223.s1IMNqRG080747@svn.freebsd.org> From: Dru Lavigne Date: Tue, 18 Feb 2014 22:23:52 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43988 - head/en_US.ISO8859-1/books/handbook/firewalls X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 22:23:52 -0000 Author: dru Date: Tue Feb 18 22:23:51 2014 New Revision: 43988 URL: http://svnweb.freebsd.org/changeset/doc/43988 Log: White space fix only. Translators can ignore. Sponsored by: iXsystems Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Tue Feb 18 21:30:19 2014 (r43987) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Tue Feb 18 22:23:51 2014 (r43988) @@ -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 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. - - First, enable the gateway in order to let the - machine forward the network traffic it receives on one - interface to another interface. This sysctl + 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 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 &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 -&g 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. - - Note that this ruleset probably allows more - traffic to pass out of the network than is needed. - One reasonable setup could create this macro: + 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: 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 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 an problematic due to the nature of the FTP 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 an - 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: - - icmp_types = "echoreq" - - and a rule which uses the macro: - - 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 - 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" + + and a rule which uses the macro: + + 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 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 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. - - 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 + 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 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 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]: inpu 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 $localne 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 $localne 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 $localne 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. - - 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 - - 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: + 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: + + &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. + + 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. - - 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. - - 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: - - 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;. - + 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. + + 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: + + + + 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 + + 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 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. - - 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: + 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 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: - 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 *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***