From owner-svn-doc-all@FreeBSD.ORG Tue Feb 18 21:05:37 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 8345675E; Tue, 18 Feb 2014 21:05:37 +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 6C76314DC; Tue, 18 Feb 2014 21:05:37 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1IL5bmI047707; Tue, 18 Feb 2014 21:05:37 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1IL5bW8047706; Tue, 18 Feb 2014 21:05:37 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201402182105.s1IL5bW8047706@svn.freebsd.org> From: Dru Lavigne Date: Tue, 18 Feb 2014 21:05:37 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43986 - 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 21:05:37 -0000 Author: dru Date: Tue Feb 18 21:05:36 2014 New Revision: 43986 URL: http://svnweb.freebsd.org/changeset/doc/43986 Log: Editorial pass through Tables section. 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 20:17:42 2014 (r43985) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Tue Feb 18 21:05:36 2014 (r43986) @@ -1004,74 +1004,64 @@ pass out on $ext_if inet proto udp from Using Tables - By this time it may appear that this gets awfully static - and rigid. There will after all be some kinds of data which + Some types of data are relevant to filtering and redirection at a given time, - but do not deserve to be put into a configuration file! - Quite right, and PF offers - mechanisms for handling these situations as well. Tables - are one such feature, mainly useful as lists which can be + 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 where fast lookups are desirable. Table names are - always enclosed in < >, like + 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 } - Here, the network 192.168.2.0/24 - is part of the table, except the address + 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 (logical NOT). It is + the ! operator. It is also possible to load tables from files where each item is - on a separate line, such as the file - /etc/clients. + on a separate line, as seen in this example + /etc/clients: 192.168.2.0/24 !192.168.2.5 - which in turn is used to initialize the table in - /etc/pf.conf: + To refer to the file, define the table like this: table <clients> persist file "/etc/clients" - Then, for example, one of our earlier rules can be - changed to read + Once the table is defined, it can be referenced by a + rule: pass inet proto tcp from <clients> to any port $client_out flags S/SA keep state - to manage outgoing traffic from client computers. With - this in hand, the table's contents can be manipulated live, - such as - - &prompt.root; pfctl -t clients -T add 192.168.1/16 - - Note that this changes the in-memory copy of the table - only, meaning that the change will not survive a power - failure or other reboot unless there are arrangements to - store the changes. + A table's contents can be manipulated live, using pfctl. + This example adds another network to the table: - One might opt to maintain the on-disk copy of the table - using a &man.cron.8; job which dumps the table content to + &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 >/etc/clients. Alternatively, - /etc/clients could be edited, replacing - the in-memory table contents with the file data: + /etc/clients can be updated with + the in-memory table contents: &prompt.root; pfctl -t clients -T replace -f /etc/clients - - For operations performed frequently, administrators will - sooner or later end up writing shell scripts for tasks - such as inserting or removing items or replacing table - contents. The only real limitations lie in individual needs - and creativity. - Overload Tables + Using Overload Tables to Protect <acronym>SSH</acronym> - Those who run a Secure Shell login service which is - accessible from the Internet have probably seen something + 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 @@ -1081,95 +1071,68 @@ Sep 26 03:12:44 skapet sshd[29635]: Inva 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 - And so on. This is what a brute force attack looks - like. Essentially somebody, or more likely, a cracked - computer somewhere, is trying by brute force to find a - combination of user name and password which will let them - into your system. - - The simplest response would be to write a - pf.conf rule which blocks all access. - This leads to another class of problems, including what to - do in order to let people with legitimate business on the - system access it anyway. Some might consider moving the - service to another port, but then again, the ones flooding - on port 22 would probably be able to scan their way to port - 22222 for a repeat performance. - - Since OpenBSD 3.7, and soon after in &os; version 6.0, - PF has offered a slightly more - elegant solution. Pass rules can be written so they - maintain certain limits on what connecting hosts can do. - For good measure, violators can be banished to a table of - addresses which are denied some or all access. If desired, - it is even possible to drop all existing connections from - machines which overreach the limits. Here is how it is - done: + 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. + + 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. - First, set up the table. In the tables section, - add + To configure this, create this table in the tables section + of the ruleset: table <bruteforce> persist - Then somewhere fairly early in the ruleset, add a rule - to block the bruteforcers: - - block quick from <bruteforce> + Then, somewhere early in the ruleset, add rules + to block brute access while allowing legitimate access: - And finally, the pass rule. - - pass inet proto tcp from any to $localnet port $tcp_services \ + block quick from <bruteforce> +pass inet proto tcp from any to $localnet port $tcp_services \ flags S/SA keep state \ - (max-src-conn 100, max-src-conn-rate 15/5, \ + (max-src-conn 100, max-src-conn-rate 15/5, \ overload <bruteforce> flush global) - The first part here is identical to the main rule we - constructed earlier. The part in parentheses is the new - stuff which will ease network load even further. + The part in parentheses defines the limits and the + numbers should be changed to meet local requirements. It + can be read as follows: max-src-conn is the number of - simultaneous connections allowed from one host. In this - example, it is set at 100. Other setups may want a slightly - higher or lower value. + simultaneous connections allowed from one host. max-src-conn-rate is the rate of new - connections allowed from any single host, here 15 - connections per 5 seconds. Again, the administrator is the - one to judge what suits their setup. + 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 table bruteforce. Our rule - set blocks all traffic from addresses in the bruteforce + 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 host's connections will be - terminated (flushed). The global part says that for good - measure, this applies to connections which match other pass - rules too. - - The effect is dramatic. From here on, bruteforcers - more often than not will end up with - "Fatal: timeout before - authentication" messages, getting - nowhere. + a host reaches the limit, that all (global) of that host's connections will be + terminated (flush). These rules will not block slow - bruteforcers, sometimes referred to as the - Hail Mary Cloud. + bruteforcers, as described in http://home.nuug.no/~peter/hailmary2013/. - Once again, please keep in mind that this example rule - is intended mainly as an illustration. It is not unlikely - that a particular network's needs are better served by - rather different rules or combinations of rules. - - If, for example, a generous number of connections in - general are wanted, but the desire is to be a little more - tight fisted 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: @@ -1179,87 +1142,53 @@ Sep 26 03:12:44 skapet sshd[24703]: Fail (max-src-conn 15, max-src-conn-rate 5/3, \ overload <bruteforce> flush global) - It should be possible to find the set of parameters - which is just right for individual situations by reading the - relevant man pages and the - PF User - Guide, and perhaps a bit of - experimentation. - It May Not be Necessary to Block All Overloaders - It is probably worth noting at this point that the - overload mechanism is a general - technique which does not have to apply exclusively to the - ssh service, and it is not always - optimal to block all traffic from offenders - entirely. + 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, in the web - case, to redirect to a specific web page. + queue with a minimal bandwidth allocation or + to redirect to a specific web page. - - Expiring Table Entries with - <application>pfctl</application> - - At this point, we have tables which will be filled by - our overload rules, and since we could - reasonably expect our gateways to have months of uptime, - the tables will grow incrementally, taking up more memory - as time goes by. - - Sometimes an IP address that was blocked last week due - to a brute force attack was in fact a dynamically assigned - one, which is now assigned to a different ISP customer who - has a legitimate reason to try communicating with hosts in + 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. - Situations like these were what caused Henning Brauer - to add to pfctl the ability to - expire table entries not referenced in a specified number - of seconds (in OpenBSD 4.1). For example, the - command + 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 - will remove <bruteforce> - table entries which have not been referenced for 86400 - seconds. - - - - The <application>expiretable</application> - Tool - - Before pfctl acquired the - ability to expire table entries, Henrik Gustafsson had - written expiretable, which + Similar functionality is provided by + security/expiretable, which removes table entries which have not been accessed for a specified period of time. - One useful example is to use the - expiretable program as a way of - removing outdated <bruteforce> - table entries. - - For example, let - expiretable remove + Once installed, + expiretable can be run to remove <bruteforce> table entries older - than 24 hours by adding an entry containing the following - to /etc/rc.local: + than a specified age. This example removes all entries + older than 24 hours: /usr/local/sbin/expiretable -v -d -t 24h bruteforce - - expiretable is in the - Ports Collection on &os; as - security/expiretable. -