From owner-freebsd-doc@FreeBSD.ORG Fri Apr 24 06:23:49 2009 Return-Path: Delivered-To: freebsd-doc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75CE6106564A; Fri, 24 Apr 2009 06:23:49 +0000 (UTC) (envelope-from trhodes@FreeBSD.org) Received: from gloomweaver.pittgoth.com (gloomweaver.pittgoth.com [205.134.165.107]) by mx1.freebsd.org (Postfix) with ESMTP id A39A48FC18; Fri, 24 Apr 2009 06:23:48 +0000 (UTC) (envelope-from trhodes@FreeBSD.org) Received: from localhost.fbsdsecure.org (net-ix.gw.ai.net [205.134.160.6]) (authenticated bits=0) by gloomweaver.pittgoth.com (8.14.3/8.14.3) with ESMTP id n3O6Tuk9042518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 Apr 2009 02:29:57 -0400 (EDT) (envelope-from trhodes@FreeBSD.org) Date: Fri, 24 Apr 2009 02:23:36 -0400 From: Tom Rhodes To: Manolis Kiagias Message-Id: <20090424022336.3f4c6792.trhodes@FreeBSD.org> In-Reply-To: <49E796E6.70709@gmail.com> References: <49E796E6.70709@gmail.com> X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: pepper@cbio.mskcc.org, pgj@FreeBSD.org, freebsd-doc@FreeBSD.org, trhodes@FreeBSD.org, keramida@FreeBSD.org, gabor@FreeBSD.org Subject: Re: [PATCH] for the 'firewalls' chapter X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 06:23:49 -0000 Hey Manolis, My review, as promised, please see comments in line. I'm sorry it came so late! Thanks! On Thu, 16 Apr 2009 23:36:54 +0300 Manolis Kiagias wrote: > Hey all, > > Once again, calling all my usual reviewers (as well as anyone else who > wishes to comment) on this (unfortunately long) patch for the > 'firewalls' chapter. > I've been writing and rewriting this for quite some time now, partly > while I was translating the chapter to Greek but also for quite some > time afterwards. It has gone through many changes and also includes > relevant parts from PR docs/131568 (author CCed). I will try to > summarize some of the changes, although this is as huge a task as the > patch itself! > > - Attempt to reduce some duplication. An identical paragraph on what is > an inclusive firewall was removed from each section, rephrased and added > at the beginning of the chapter. There are still more sections that > contain duplicate information. > - Convert to passive voice where possible and reduce amount of 'you' > (and in some cases 'I') references > - Rephrase several paragraphs (some were already commented as > problematic in the source). There were cases were the information was > clearly wrong (i.e. it was referenced that a packet exits the network, > reaches the destination and returns. Clearly, this is not the same > packet). Also not all firewalls need to have two interfaces (this was > submitted in the above PR). > - Attempt to improve markup. Originally I was planning to use s > everywhere, but the chapter is so full of them, that even the subtle > dotted line HTML rendering becomes tiring after a while. I did insert > s for consistency, where some terms were already marked (i.e. > TCP) and adjacent terms were not (i.e. UDP). If people feel we should > markup all of them, I'll gladly do it. I also inserted/fixed numerous > other tags (mostly ) > - Fix grammar / syntax / spelling in several cases > - Numerous other changes that will hopefully become clear while reading > the patch itself > > Here is the diff: > > http://people.freebsd.org/~manolis/firewalls.diff > > If you prefer to read the HTML build: > > http://www.freebsdgr.org/handbook-mine/firewalls.html > > Plase take all the time you need to read this - I will try to integrate > any suggested changes as they are coming, and obviously this is not > going in soon :) diff -r 126c435025de -r f6a8c68b044d en_US.ISO8859-1/books/handbook/firewalls/chapter.sgml --- a/en_US.ISO8859-1/books/handbook/firewalls/chapter.sgml Sun Feb 01 15:17:37 2009 +0200 +++ b/en_US.ISO8859-1/books/handbook/firewalls/chapter.sgml Thu Apr 16 22:46:31 2009 +0300 @@ -124,12 +124,22 @@ reverse. It only allows traffic matching the rules through and blocks everything else. - Inclusive firewalls are generally safer than exclusive + An inclusive firewall offers much better control of the outgoing + traffic, making it a better choice for systems that offer services to + the public Internet. It also controls the type of traffic originating + from the public Internet that can gain access to your private network. + All traffic that does not match the rules, is blocked and logged by + default design. Inclusive firewalls are generally safer than exclusive I don't like "by default design" here. It just kind of sounds a tad bit off. How about "by design" instead? firewalls because they significantly reduce the risk of allowing - unwanted traffic to pass through the firewall. + unwanted traffic to pass through them. + + + Unless noted otherwise, all the configurations and example + rulesets in this chapter, create inclusive type firewalls. "all configuration and example rulesets in" + Security can be tightened further using a stateful - firewall. With a stateful firewall the firewall keeps + firewall. This type of firewall keeps track of which connections are opened through the firewall and will only allow traffic through which either matches an existing connection or opens a new one. The disadvantage of a stateful @@ -153,14 +163,14 @@ &man.altq.4; and &man.dummynet.4;. Dummynet has traditionally been closely tied with IPFW, and ALTQ with - PF. Traffic shaping for IPFILTER can currently - be done with IPFILTER for NAT and filtering and + PF. Traffic shaping for IPFILTER can currently + be done with IPFILTER for NAT and filtering and IPFW with &man.dummynet.4; Too many "and" in this sentence. How about: "Traffic shaping for IPFILTER can currently be done with IPFILTER for NAT. IPFW filtering is handled via the &man.dummynet.4; driver ..." Perhaps the entire paragraph should be re-worded after we commit these other changes? or by using PF with ALTQ. IPFW, and PF all use rules to control the access of packets to and from your system, although they go about it different ways and - have different rule syntaxes. + have different rule syntax. "have a different rule syntax." The reason that &os; has multiple built in firewall packages is that different people have different requirements and @@ -174,7 +184,7 @@ Since all firewalls are based on inspecting the values of selected packet control fields, the creator of the firewall rulesets must have an understanding of how - TCP/IP works, what the different values in + TCP/IP works, what the different values in the packet control fields are and how these values are used in a normal session conversation. For a good explanation go to: pf_enable="YES" is present. However, the PF module will - not load if the system cannot find a PF + not be loaded if the system cannot find a PF ruleset configuration file. The default location is /etc/pf.conf. If your PF ruleset is located somewhere else put @@ -291,7 +301,7 @@ paired with &man.carp.4; to create failover firewalls using PF. More information on CARP can be found in - chapter 29 of the handbook. + of the Handbook. The PF kernel options can be found in /usr/src/sys/conf/NOTES and are reproduced @@ -448,14 +458,14 @@ options ALTQ enables the ALTQ framework. - options ALTQ_CBQ enables Class Based - Queuing (CBQ). CBQ + options ALTQ_CBQ enables Class Based + Queuing (CBQ). CBQ allows you to divide a connection's bandwidth into different classes or queues to prioritize traffic based on filter rules. - options ALTQ_RED enables Random Early - Detection (RED). RED is + options ALTQ_RED enables Random Early + Detection (RED). RED is used to avoid network congestion. RED does this by measuring the length of the queue and comparing it to the minimum and maximum thresholds for the queue. If the @@ -463,16 +473,16 @@ True to its name, RED drops packets from different connections randomly. - options ALTQ_RIO enables Random Early - Detection In and Out. + options ALTQ_RIO enables Random Early + Detection In and Out. options ALTQ_HFSC enables the - Hierarchical Fair Service Curve Packet Scheduler. For more + Hierarchical Fair Service Curve Packet Scheduler. For more information about HFSC see: . - options ALTQ_PRIQ enables Priority - Queuing (PRIQ). PRIQ + options ALTQ_PRIQ enables Priority + Queuing (PRIQ). PRIQ will always pass traffic that is in a higher queue first. @@ -492,11 +502,6 @@ IPFILTER - - This section is work in progress. The contents might - not be accurate at all times. - - The author of IPFILTER is Darren Reed. IPFILTER is not operating system dependent: it is an open source application and has been ported to &os;, NetBSD, OpenBSD, &sunos;, HP/UX, and @@ -519,30 +524,17 @@ stateless type of rules. Over time IPF has been enhanced to include a quick option and a stateful keep state option which drastically modernized the rules - processing logic. IPF's official documentation covers the legacy - rule coding parameters and the legacy rule file processing + processing logic. IPF's official documentation covers only the legacy + rule coding parameters and rule file processing logic. The modernized functions are only included as additional options, completely understating their benefits in producing a - far superior secure firewall. + far superior and more secure firewall. The instructions contained in this section are based on using rules that contain the quick option and the stateful keep state option. This is the basic framework for coding an inclusive firewall rule set. - - - An inclusive firewall only allows packets matching the rules - to pass through. This way you can control what services can - originate behind the firewall destined for the public Internet - and also control the services which can originate from the - public Internet accessing your private network. Everything else - is blocked and logged by default design. Inclusive firewalls are - much, much more secure than exclusive firewall rule sets and is - the only rule set type covered herein. - For detailed explanation of the legacy rules processing method see: @@ -567,13 +559,13 @@ IPF is included in the basic &os; install as a separate run time loadable module. The system will dynamically load the IPF - kernel loadable module when the rc.conf statement + kernel loadable module when the rc.conf statement ipfilter_enable="YES" is used. The loadable module was created with logging enabled and the - default pass all options. You do not need + default pass all options. There is no need to compile IPF into the &os; kernel just to change the default - to block all, you can do that by just coding - a block all rule at the end of your rule set. + to block all. This can be done just by adding + a block all rule at the end of your rule set. @@ -603,7 +595,7 @@ kernel options - It is not a mandatory requirement that you enable IPF by + It is not a mandatory requirement to enable IPF by compiling the following options into the &os; kernel. It is only presented here as background information. Compiling IPF into the kernel causes the loadable module to never be @@ -630,16 +622,15 @@ the default behavior so any packet not matching a firewall pass rule gets blocked. - These settings will take effect only after you have built - and installed a kernel with them set. + These settings will take effect only after installing a kernel + that has been built with the above options set. Available rc.conf Options - You need the following statements in - /etc/rc.conf to activate IPF at boot - time: + To activate IPF at boot time, the following statements need to + be added to /etc/rc.conf: ipfilter_enable="YES" # Start ipf firewall ipfilter_rules="/etc/ipf.rules" # loads rules definition text file @@ -649,9 +640,9 @@ # v = log tcp window, ack, seq # n = map IP & port to names - If you have a LAN behind this firewall that uses the - reserved private IP address ranges, then you need to add the - following to enable NAT + If there is a LAN behind this firewall that uses the + reserved private IP address ranges, the following lines will have to + be added to enable NAT functionality: gateway_enable="YES" # Enable as LAN gateway @@ -664,10 +655,10 @@ ipf - The ipf command is used to load your rules file. Normally - you create a file containing your custom rules and use this - command to replace in mass the currently running firewall - internal rules: + The &man.ipf.8; command is used to load your rules file. "ruleset file." ? + Your custom rules would normally be placed in a file, and the + following command could then be used to replace in mass the + currently running firewall rules: &prompt.root; ipf -Fa -f /etc/ipf.rules @@ -738,7 +729,7 @@ Packet log flags set: (0) When supplied with either for inbound - or for outbound, it will retrieve and + or for outbound, the command will retrieve and display the appropriate list of filter rules currently installed and in use by the kernel. @@ -772,7 +763,7 @@ ipfstat command is the flag which displays the state table in a way similar to the way &man.top.1; shows the &os; running process table. When your - firewall is under attack this function gives you the ability to + firewall is under attack, this function gives you the ability to identify, drill down to, and see the attacking packets. The optional sub-flags give the ability to select the destination or source IP, port, or protocol that you want to monitor in @@ -792,19 +783,19 @@ In order for ipmon to work properly, the - kernel option IPFILTER_LOG must be turned on. This command has + kernel option IPFILTER_LOG must be turned on. This command has two different modes that it can be used in. Native mode is the - default mode when you type the command on the command line + default mode when the command is typed on the command line without the flag. - Daemon mode is for when you want to have a continuous - system log file available so that you can review logging of - past events. This is how &os; and IPFILTER are configured to + Daemon mode is for when a continuous + system log file is desired, so that logging of past events may be + reviewed. This is how &os; and IPFILTER are configured to work together. &os; has a built in facility to automatically rotate system logs. That is why outputting the log information - to syslogd is better than the default of outputting to a - regular file. In the default rc.conf file - you see the ipmon_flags statement uses the + to &man.syslogd.8; is better than the default of outputting to a + regular file. In the default rc.conf file, + the ipmon_flags statement uses the flags: ipmon_flags="-Ds" # D = start as daemon @@ -815,7 +806,7 @@ The benefits of logging are obvious. It provides the ability to review, after the fact, information such as which packets had been dropped, what addresses they came from and - where they were going. These all give you a significant edge + where they were going. These all can provide a significant edge "These can all provide" if we're making the change here. :) in tracking down attackers. Even with the logging facility enabled, IPF will not @@ -826,7 +817,7 @@ It is very customary to include a default deny everything rule with the log keyword included as your last rule in the - rule set. This way you get to see all the packets that did not + rule set. This makes possible to see all the packets that did not "This makes it possible" match any of the rules in the rule set. @@ -850,15 +841,15 @@ To setup IPFILTER to log all data to - /var/log/ipfilter.log, you will need to - create the file. The following command will do that: + /var/log/ipfilter.log, the file will need to be + created beforehand. The following command will do that: &prompt.root; touch /var/log/ipfilter.log - The syslog function is controlled by definition statements + The &man.syslogd.8; function is controlled by definition statements in the /etc/syslog.conf file. The syslog.conf file offers considerable - flexibility in how syslog will deal with system messages issued + flexibility in how syslog will deal with system messages issued by software applications like IPF. Add the following statement to @@ -871,13 +862,13 @@ file location. To activate the changes to /etc/syslog.conf - you can reboot or bump the syslog task into + you can reboot or bump the &man.syslogd.8; daemon into re-reading /etc/syslog.conf by running /etc/rc.d/syslogd reload Do not forget to change /etc/newsyslog.conf to rotate the new log - you just created above. + just created above. s/just // @@ -924,18 +915,18 @@ The addresses. This is actually three fields: the source address and port (separated by a comma), the -> - symbol, and the destination address and port. - 209.53.17.22,80 -> 198.73.220.17,1722. + symbol, and the destination address and port, e.g. "e.g.:" + 209.53.17.22,80 -> 198.73.220.17,1722. PR followed by the protocol name or - number, e.g. PR tcp. + number, e.g. PR tcp. "e.g.:" len followed by the header length - and total length of the packet, e.g. len 20 40. + and total length of the packet, e.g. len 20 40. "e.g.:" here too please. :) @@ -958,15 +949,15 @@ Some experienced IPF users create a file containing the rules and code them in a manner compatible with running them as a script with symbolic substitution. The major benefit of - doing this is that you only have to change the value associated - with the symbolic name and when the script is run all the rules + doing this is that only the value associated + with the symbolic name needs to be changed, and when the script is run all the rules containing the symbolic name will have the value substituted in - the rules. Being a script, you can use symbolic substitution + the rules. Being a script, symbolic substitution can be used to code frequently used values and substitute them in multiple - rules. You will see this in the following example. + rules. This can be seen in the following example. - The script syntax used here is compatible with the sh, csh, - and tcsh shells. + The script syntax used here is compatible with the &man.sh.1;, &man.csh.1;, + and &man.tcsh.1; shells. Symbolic substitution fields are prefixed with a dollar sign: $. @@ -1012,8 +1003,8 @@ That is all there is to it. The rules are not important in this example; how the symbolic substitution fields are populated and used are. If the above example was in a file - named /etc/ipf.rules.script, you could - reload these rules by entering the following command: + named /etc/ipf.rules.script, these rules could be + reloaded by entering the following command: &prompt.root; sh /etc/ipf.rules.script @@ -1040,7 +1031,7 @@ value) into /etc/rc.conf file. Add a script like the following to your - /usr/local/etc/rc.d/ startup + /usr/local/etc/rc.d/ startup directory. The script should have an obvious name like ipf.loadrules.sh. The .sh extension is mandatory. @@ -1062,25 +1053,19 @@ IPF Rule Sets - - - A rule set is a group of ipf rules coded to pass or block + A rule set is a group of IPF rules coded to pass or block packets based on the values contained in the packet. The bi-directional exchange of packets between hosts comprises a - session conversation. The firewall rule set processes the - packet two times, once on its arrival from the public Internet - host and again as it leaves for its return trip back to the - public Internet host. Each TCP/IP service (i.e. telnet, www, - mail, etc.) is predefined by its protocol, source and - destination IP address, or the source and destination port - number. This is the basic selection criteria used to create - rules which will pass or block services. + session conversation. The firewall rule set processes both the Are we using "rule set" or "ruleset" because up above it was just one word. We should come to a conclusion and run a %s/one/right one/g across this chapter then. :) + packets arriving from the public Internet, as well as the packets + produced by the system as a response to them. + Each TCP/IP service (i.e. telnet, www, "i.e.: " + mail, etc.) is predefined by its protocol and privileged (listening) + port. Packets destined for a specific service, originate from the + source address using an unprivileged (high order) port and target the + specific service port on the destination address. All the above + parameters (i.e. ports and addresses) can be used as selection "i.e.: " again. :) + criteria to create rules which will pass or block services. IPFILTER @@ -1101,19 +1086,6 @@ basic framework for coding an inclusive firewall rule set. - - - An inclusive firewall only allows services matching the - rules through. This way you can control what services can - originate behind the firewall destined for the public Internet - and also control the services which can originate from the - public Internet accessing your private network. Everything - else is blocked and logged by default design. Inclusive - firewalls are much, much securer than exclusive firewall rule - sets and is the only rule set type covered herein. - All this removal is key. Seriously, this has needed to be done for some time. Thanks!! When working with the firewall rules, be very careful. Some configurations will @@ -1187,7 +1159,7 @@ The action indicates what to do with the packet if it matches the rest of the filter rule. Each rule - must have a action. The following + must have an action. The following actions are recognized: block indicates that the packet should @@ -1204,7 +1176,7 @@ A mandatory requirement is that each filter rule explicitly state which side of the I/O it is to be used on. - The next keyword must be either in or out and one or the + The next keyword must be either in or out and one or the other has to be coded or the rule will not pass syntax checks. @@ -1250,8 +1222,8 @@ processing logic. When a packet is logged, the headers of the packet are - written to the IPL packet logging pseudo-device. - Immediately following the log keyword, the following + written to the IPL packet logging pseudo-device. + Immediately following the log keyword, the following qualifiers may be used (in this order): body indicates that the first 128 @@ -1259,8 +1231,8 @@ headers. first If the log - keyword is being used in conjunction with a keep - state option, it is recommended that this option is + keyword is being used in conjunction with a keep + state option, it is recommended that this option is also applied so that only the triggering packet is logged and not every packet which thereafter matches the keep state information. @@ -1270,7 +1242,7 @@ SELECTION The keywords described in this section are used to - describe attributes of the packet to be interrogated when + describe attributes of the packet to be checked when determining whether rules match or not. There is a keyword subject, and it has sub-option keywords, one of which has to be selected. The following general-purpose @@ -1291,7 +1263,7 @@ protocol names found in /etc/protocols are recognized and may be used. The special protocol keyword tcp/udp may be used to match either a - TCP or a UDP packet, and has been added as + TCP or a UDP packet, and has been added as a convenience to save duplication of otherwise identical rules. @@ -1303,23 +1275,19 @@ synonym for from any to any with no other match parameters. - from src to dst: the from and to + from src to dst: the from and to keywords are used to match against IP addresses. Rules must - specify BOTH source and destination parameters. + specify both source and destination parameters. any is a special keyword that matches any - IP address. Examples of use: from any to any - or from 0.0.0.0/0 to any or from any to - 0.0.0.0/0 or from 0.0.0.0 to any or - from any to 0.0.0.0. + IP address. Examples of use: from any to any + or from 0.0.0.0/0 to any or from any to + 0.0.0.0/0 or from 0.0.0.0 to any or + from any to 0.0.0.0. - - - IP addresses may be specified as a dotted IP address - numeric form/mask-length, or as single dotted IP address - numeric form. There is no way to match ranges of IP addresses which - do not express themselves easily as mask-length. See this + do not express themselves easily using the dotted numeric + form / mask-length notation. See this web page for help on writing mask-length: . It's a port too, that ipcalc utility. :) @@ -1329,21 +1297,21 @@ If a port match is included, for either or both of source and destination, then it is only applied to - TCP and UDP packets. When composing port + TCP and UDP packets. When composing port comparisons, either the service name from /etc/services or an integer port number - may be used. When the port appears as part of the from + may be used. When the port appears as part of the from object, it matches the source port number; when it appears - as part of the to object, it matches the destination port + as part of the to object, it matches the destination port number. The use of the port option with the to object is a mandatory requirement for the modernized rules processing logic. Example of use: - from any to any port = 80 + from any to any port = 80 - + - Port comparisons may be done in a number of forms, with - a number of comparison operators, or port ranges may be + Single port comparisons may be done in a number of ways, using + a number of different comparison operators. Port ranges may also be specified. port "=" | "!=" | "<" | ">" | "<=" | ">=" | @@ -1364,8 +1332,8 @@ <acronym>TCP</acronym>_FLAG Flags are only effective for TCP - filtering. The letters represents one of the possible flags - that can be interrogated in the TCP packet + filtering. The letters represent one of the possible flags + that can be matched against the TCP packet header. The modernized rules processing logic uses the @@ -1402,15 +1370,15 @@ exchange of packets comprising a session conversation. When activated, keep-state dynamically generates internal rules for each anticipated packet being exchanged during the - bi-directional session conversation. It has the interrogation - abilities to determine if the session conversation between the + bi-directional session conversation. It has sufficient matching + capabilities to determine if the session conversation between the originating sender and the destination are following the valid procedure of bi-directional packet exchange. Any packets that do not properly fit the session conversation template are automatically rejected as impostors. - Keep state will also allow ICMP packets related to a - TCP or UDP session through. So if you get + Keep state will also allow ICMP packets related to a + TCP or UDP session through. So if you get ICMP type 3 code 4 in response to some web surfing allowed out Missed tag. :) by a keep state rule, they will be automatically allowed in. Any packet that IPF can be certain is part of an active @@ -1419,21 +1387,22 @@ What happens is: - Packets destined to go out the interface connected to the + Packets destined to go out through the interface connected to the public Internet are first checked against the dynamic state - table, if the packet matches the next expected packet - comprising in a active session conversation, then it exits the + table. If the packet matches the next expected packet + comprising an active session conversation, then it exits the firewall and the state of the session conversation flow is - updated in the dynamic state table, the remaining packets get - checked against the outbound rule set. + updated in the dynamic state table. Packets that do not belong to + an already active session, are simply checked against the outbound + rule set. - Packets coming in to the interface connected to the public - Internet are first checked against the dynamic state table, if - the packet matches the next expected packet comprising a + Packets coming in from the interface connected to the public + Internet are first checked against the dynamic state table. If + the packet matches the next expected packet comprising an active session conversation, then it exits the firewall and the state of the session conversation flow is updated in the - dynamic state table, the remaining packets get checked against - the inbound rule set. + dynamic state table. Packets that do not belong to an already active + session, are simply checked against the inbound rule set. When the conversation completes it is removed from the dynamic state table. @@ -1443,7 +1412,7 @@ packets will be allowed through automatically and any impostors automatically rejected. If a new session is blocked, none of its subsequent packets will be allowed through. Stateful - filtering has technically advanced interrogation abilities + filtering has technically advanced matching abilities capable of defending against the flood of different attack methods currently employed by attackers. @@ -1455,10 +1424,15 @@ The following rule set is an example of how to code a very secure inclusive type of firewall. An inclusive firewall only - allows services matching pass rules through and blocks all - other by default. All firewalls have at the minimum two - interfaces which have to have rules to allow the firewall to - function. + allows services matching pass rules through, and blocks all + other by default. Firewalls intended to protect other machines, "others by default." + also called network firewalls, should have at least + two interfaces, which are generally configured to trust one side + (the LAN) and not the other (the public Internet). Alternatively, Perhaps around LAN? + a firewall might be configured to protect only the system running the + firewall software—this is called a "only the system it is running on—this is called a" Mainly to avoid saying "firewall" twice in the same sentence. + host based firewall, and is particularly appropriate + for servers on an untrusted network. All &unix; flavored systems including &os; are designed to use interface lo0 and IP address @@ -1468,20 +1442,19 @@ special internally used packets. The interface which faces the public Internet is the one - where you place your rules to authorize and control access out - to the public Internet and access requests arriving from the - public Internet. This can be your user PPP + to place the rules that authorize and control access of the outbound + and inbound connections. This can be your user PPP tun0 interface or your NIC that is connected to your DSL or cable modem. - In cases where one or more NICs are cabled to private LANs - behind the firewall, those interfaces must have a rule coded to - allow free unmolested movement of packets originating from - those LAN interfaces. + In cases where one or more NICs are cabled to private network + segments, those interfaces may require rules to allow packets + originating from those LAN interfaces transit to each other and/or + to the outside (Internet). - The rules should be first organized into three major - sections: all the free unmolested interfaces, the public - interface outbound, and the public interface inbound. + The rules should be organized into three major + sections: first trusted interfaces, then the public + interface outbound, and last the public untrusted interface inbound. The rules in each of the public interface sections should have the most frequently matched rules placed before less @@ -1490,66 +1463,65 @@ direction. The Outbound section in the following rule set only - contains 'pass' rules which contain selection values that + contains pass rules which contain selection values that uniquely identify the service that is authorized for public - Internet access. All the rules have the 'quick', 'on', - 'proto', 'port', and 'keep state' option coded. The 'proto - tcp' rules have the 'flag' option included to identify the + Internet access. All the rules have the quick, on, + proto, port, and keep state options set. The proto + tcp rules have the flag option included to identify the session start request as the triggering packet to activate the stateful facility. The Inbound section has all the blocking of undesirable packets first, for two different reasons. The first is that - these things being blocked may be part of an otherwise valid - packet which may be allowed in by the later authorized service - rules. The second reason is that by having a rule that - explicitly blocks selected packets that I receive on an - infrequent basis and that I do not want to see in the log, they - will not be caught by the last rule in the section which blocks - and logs all packets which have fallen through the rules. The - last rule in the section which blocks and logs all packets is - how you create the legal evidence needed to prosecute the - people who are attacking your system. + malicious packets may be partial matches for legitimate traffic. + These packets have to be discarded rather than allowed in, based on + their partial matches against allow rules. + The second reason is that known and uninteresting rejects may be + blocked silently, rather than being caught and logged by the last + rules in the section. The final rule in each section, blocks and + logs all packets and can be used to create the legal evidence needed + to prosecute the people who are attacking your system. - Another thing you should take note of, is there is no - response returned for any of the undesirable stuff, their - packets just get dropped and vanish. This way the attacker + Another thing that should be taken care of, is to insure there is no + response returned for any of the undesirable traffic. Invalid + packets should just get dropped and vanish. This way the attacker has no knowledge if his packets have reached your system. The less the attackers can learn about your system, the more time they must invest before actually doing something bad. - The inbound 'nmap OS fingerprint' attempts rule I log + Rules that include a log first option, will only + log the event the first time they are triggered. This option is + included in the sample nmap OS fingerprint rule. + The security/nmap utility is + commonly used by attackers who attempt to identify the operating + system of your server. - + Any time there are logged messages on a rule with + the log first option, an ipfstat -hio + command should be executed to evaluate how many times the rule has + actually matched. Large number of matches usually indicate that the + system is being flooded (i.e. under attack). "i.e.: " again. :) - the first occurrence because this is something a attacker - would do. - - Any time you see log messages on a rule with 'log first'. - You should do an ipfstat -hio command to see - the number of times the rule has been matched so you know if - you are being flooded, i.e. under attack. - - When you log packets with port numbers you do not - recognize, look it up in /etc/services or - go to The /etc/services file may be used to + lookup unknown port numbers. Alternatively, + visit - and do a port number lookup to find what the purpose of that - port number is. + and do a port number lookup to find the purpose of a particular + port number. Check out this link for port numbers used by Trojans . - The following rule set is a complete very secure - 'inclusive' type of firewall rule set that I have used on my - system. You can not go wrong using this rule set for your own. - Just comment out any pass rules for services that you do not - want to authorize. + The following rule set creates a complete and very secure + inclusive type of firewall rule set that has been + tested on production systems. It can be easily modified for your + own system. Just comment out any pass rules for + services that should not be authorized. - If you see messages in your log that you want to stop - seeing just add a block rule in the inbound section. + To avoid logging unwanted messages, + just add a block rule in the inbound section. - You have to change the dc0 - interface name in every rule to the interface name of the Nic + The dc0 interface name has to be changed + in every rule to the real interface name of the NIC card that connects your system to the public Internet. For user PPP it would be tun0. @@ -1572,9 +1544,9 @@ ################################################################# # Interface facing Public Internet (Outbound Section) -# Interrogate session start requests originating from behind the +# Match session start requests originating from behind the # firewall on the private network -# or from this gateway server destine for the public Internet. +# or from this gateway server destined for the public Internet. ################################################################# # Allow out access to my ISP's Domain name server. @@ -1609,38 +1581,38 @@ # Allow out nntp news pass out quick on dc0 proto tcp from any to any port = 119 flags S keep state -# Allow out gateway & LAN users non-secure FTP ( both passive & active modes) +# Allow out gateway & LAN users' non-secure FTP ( both passive & active modes) # This function uses the IPNAT built in FTP proxy function coded in # the nat rules file to make this single rule function correctly. # If you want to use the pkg_add command to install application packages # on your gateway system you need this rule. pass out quick on dc0 proto tcp from any to any port = 21 flags S keep state -# Allow out secure FTP, Telnet, and SCP +# Allow out ssh/sftp/scp (telnet/rlogin/FTP replacements) # This function is using SSH (secure shell) pass out quick on dc0 proto tcp from any to any port = 22 flags S keep state -# Allow out non-secure Telnet +# Allow out insecure Telnet pass out quick on dc0 proto tcp from any to any port = 23 flags S keep state -# Allow out FBSD CVSUP function +# Allow out FreeBSD CVSup pass out quick on dc0 proto tcp from any to any port = 5999 flags S keep state # Allow out ping to public Internet pass out quick on dc0 proto icmp from any to any icmp-type 8 keep state -# Allow out whois for LAN PC to public Internet +# Allow out whois from LAN to public Internet pass out quick on dc0 proto tcp from any to any port = 43 flags S keep state # Block and log only the first occurrence of everything # else that's trying to get out. -# This rule enforces the block all by default logic. +# This rule implements the default block block out log first quick on dc0 all ################################################################# # Interface facing Public Internet (Inbound Section) -# Interrogate packets originating from the public Internet -# destine for this gateway server or the private network. +# Match packets originating from the public Internet +# destined for this gateway server or the private network. ################################################################# # Block all inbound traffic from non-routable or reserved address spaces @@ -1711,9 +1683,8 @@ # Block and log only first occurrence of all remaining traffic # coming into the firewall. The logging of only the first -# occurrence stops a .denial of service. attack targeted -# at filling up your log file space. -# This rule enforces the block all by default logic. +# occurrence avoids filling up disk with Denial of Service logs. +# This rule implements the default block. block in log first quick on dc0 all ################### End of rules file ##################################### @@ -1735,8 +1706,8 @@ NAT - NAT stands for Network Address - Translation. To those familiar with &linux;, this concept is + NAT stands for Network Address + Translation. To those familiar with &linux;, this concept is called IP Masquerading; NAT and IP Masquerading are the same thing. One of the many things the IPF NAT function enables is the ability to @@ -1748,17 +1719,16 @@ normally assign a dynamic IP address to their non-commercial users. Dynamic means that the IP address can be different each time you dial in and log on to your ISP, or for cable and DSL - modem users when you power off and then power on your modems - you can get assigned a different IP address. This IP address - is how you are known to the public Internet. + modem users, when the modem is power cycled. This dynamic IP + address is used to identify your system to the public Internet. Now lets say you have five PCs at home and each one needs Internet access. You would have to pay your ISP for an individual Internet account for each PC and have five phone lines. - With NAT you only need a single account - with your ISP, then cable your other four PCs to a switch and + With NAT only a single account is needed + with your ISP. The other four PCs may then be cabled to a switch and the switch to the NIC in your &os; system which is going to service your LAN as a gateway. NAT will automatically translate the private LAN IP address for each @@ -1766,18 +1736,9 @@ exits the firewall bound for the public Internet. It also does the reverse translation for returning packets. - NAT is most often accomplished without - the approval, or knowledge, of your ISP and in most cases is - grounds for your ISP terminating your account if found out. - Commercial users pay a lot more for their Internet connection - and usually get assigned a block of static IP address which - never change. The ISP also expects and consents to their - Commercial customers using NAT for their - internal private LANs. - There is a special range of IP addresses reserved for - NATed private LAN IP address. According to - RFC 1918, you can use the following IP ranges for private nets + NATed private LANs. According to + RFC 1918, the following IP ranges may be used for private nets which will never be routed directly to the public Internet: @@ -1837,7 +1798,7 @@ When changing the NAT rules after NAT has been started, make your changes to - the file containing the NAT rules, then run ipnat command with + the file containing the NAT rules, then run the ipnat command with the flags to delete the internal in use NAT rules and flush the contents of the translation table of all active entries. @@ -1901,18 +1862,18 @@ A packet arrives at the firewall from the LAN with a public destination. It passes through the outbound filter rules, - NAT gets his turn at the packet and applies + NAT gets its turn at the packet and applies its rules top down, first matching rule wins. NAT tests each of its rules against the - packets interface name and source IP address. When a packets + packet's interface name and source IP address. When a packet's interface name matches a NAT rule then the - [source IP address, i.e. private LAN IP address] of the packet + source IP address (i.e. private LAN IP address) of the packet i.e.: again please. is checked to see if it falls within the IP address range specified to the left of the arrow symbol on the NAT rule. On a match the packet has its source IP address rewritten with the public IP address obtained by the 0/32 keyword. - NAT posts a entry in its internal + NAT posts an entry in its internal NAT table so when the packet returns from the public Internet it can be mapped back to its original private IP address and then passed to the filter rules for @@ -1965,11 +1926,11 @@ In the above rule the packet's source port is unchanged as the packet passes through IPNAT. By - adding the portmap keyword you can tell - IPNAT to only use source ports in a range. + adding the portmap keyword, + IPNAT can be directed to only use source ports in the specified range. For example the following rule will tell IPNAT to modify the source port to be - within that range: + within the range shown: map dc0 192.168.1.0/24 -> 0/32 portmap tcp/udp 20000:60000 @@ -1982,12 +1943,12 @@ - Using a pool of public addresses + Using a Pool of Public Addresses In very large LANs there comes a point where there are just too many LAN addresses to fit into a single public address. If a block - of public IP addresses is available, you can use these addresses as - a pool, and let IPNAT pick one of + of public IP addresses is available, these addresses can be used as + a pool, and IPNAT may pick one of the public IP addresses as packet-addresses are mapped on their way out. @@ -2017,10 +1978,10 @@ has to be some way to direct the inbound traffic to the correct LAN PCs. IPNAT has the redirection facilities of NAT to solve this problem. - Lets say you have your web server on LAN address 10.0.10.25 and your single public IP - address is 20.20.20.5 you would - code the rule like this: + For example, assuming a web server operating on LAN address 10.0.10.25 and using a single public IP + address of 20.20.20.5 the rule would + be coded as follows: rdr dc0 20.20.20.5/32 port 80 -> 10.0.10.25 port 80 @@ -2048,7 +2009,7 @@ changed to address new security concerns. FTP has two flavors, it can run in active mode or passive mode. The difference is in how the data channel is acquired. Passive mode is more - secure as the data channel is acquired be the ordinal ftp + secure as the data channel is acquired by the ordinal ftp session requester. For a real good explanation of FTP and the different modes see . @@ -2099,8 +2060,8 @@ Only one filter rule is needed for FTP if the NAT FTP proxy is used. - Without the FTP Proxy you will need the following three - rules: + Without the FTP Proxy, the following three rules will be + needed: # Allow out LAN PC client FTP to public Internet # Active and passive modes @@ -2124,7 +2085,7 @@ IPFW - The IPFIREWALL (IPFW) is a &os; sponsored firewall software + The IPFIREWALL (IPFW) is a &os; sponsored firewall software application authored and maintained by &os; volunteer staff members. It uses the legacy stateless rules and a legacy rule coding technique to achieve what is referred to as Simple @@ -2133,7 +2094,7 @@ The IPFW sample rule set (found in /etc/rc.firewall and /etc/rc.firewall6) in the standard &os; - install is rather simple and it is not expected that it used + install is rather simple and it is not expected to be used directly without modifications. The example does not use stateful filtering, which is beneficial in most setups, so it will not be used as base for this section. @@ -2147,14 +2108,14 @@ different protocols use and create their unique packet header information is necessary before the power of the IPFW rules can be unleashed. Providing that level of explanation is out of the - scope of this section of the handbook. + scope of this section of the Handbook. IPFW is composed of seven components, the primary component is the kernel firewall filter rule processor and its integrated - packet accounting facility, the logging facility, the 'divert' + packet accounting facility, the logging facility, the divert rule which triggers the NAT facility, and the advanced special purpose facilities, the dummynet traffic shaper - facilities, the 'fwd rule' forward facility, the bridge + facilities, the fwd rule forward facility, the bridge facility, and the ipstealth facility. IPFW supports both IPv4 and IPv6. @@ -2170,9 +2131,9 @@ IPFW is included in the basic &os; install as a separate run time loadable module. The system will dynamically load the kernel module when the rc.conf statement - firewall_enable="YES" is used. You do not - need to compile IPFW into the &os; kernel unless you want - NAT function enabled. + firewall_enable="YES" is used. There is no + need to compile IPFW into the &os; kernel unless + NAT functionality is desired. After rebooting your system with firewall_enable="YES" in @@ -2184,8 +2145,8 @@ The loadable module does have logging ability compiled in. To enable logging and set the verbose logging - limit, there is a knob you can set in - /etc/sysctl.conf by adding these + limit, there is a knob that can be set in + /etc/sysctl.conf. By adding these statements, logging will be enabled on future reboots: net.inet.ip.fw.verbose=1 @@ -2219,9 +2180,9 @@ kernel options - It is not a mandatory requirement that you enable IPFW by - compiling the following options into the &os; kernel unless - you need NAT function. It is presented here + It is not a mandatory requirement to enable IPFW by + compiling the following options into the &os; kernel, unless + NAT functionality is required. It is presented here as background information. options IPFIREWALL @@ -2231,13 +2192,13 @@ options IPFIREWALL_VERBOSE Enables logging of packets that pass through IPFW and have - the 'log' keyword specified in the rule set. + the log keyword specified in the rule set. options IPFIREWALL_VERBOSE_LIMIT=5 Limits the number of packets logged through &man.syslogd.8; - on a per entry basis. You may wish to use this option in - hostile environments which you want to log firewall activity. + on a per entry basis. This option may be used in + hostile environments, when firewall activity logging is desired. This will close a possible denial of service attack via syslog flooding. @@ -2250,8 +2211,8 @@ options IPFIREWALL_DEFAULT_TO_ACCEPT This option will allow everything to pass through the - firewall by default, which is a good idea when you are first - setting up your firewall. + firewall by default, which is a good idea when the firewall is being + set up for the first time. kernel options @@ -2265,9 +2226,10 @@ functionality. - If you do not include IPFIREWALL_DEFAULT_TO_ACCEPT or set - your rules to allow incoming packets you will block all - packets going to and from this machine. + If the option IPFIREWALL_DEFAULT_TO_ACCEPT + is not included, and there are also no rules to allow incoming + packets, the firewall will block all incoming and outgoing Double negative here (use of no and not in the same sentence). Perhaps: "The firewall will block all incoming and outgoing packets if either the IPFIREWALL_DEFAULT_TO_ACCEPT kernel option or a rule to explicily allow these connections are missing." + connections. @@ -2308,7 +2270,7 @@ of firewall rules. - filename — absolute path of + filename — absolute path of file containing firewall rules. @@ -2323,12 +2285,12 @@ add block in all add block out all - On the other hand, it is possible to set - firewall_script variable to absolute path of + On the other hand, it is possible to set the + firewall_script variable to the absolute path of an executable script that includes ipfw commands being executed at system boot time. A valid ruleset script that would be equivalent to the ruleset file shown above would - be following: + be the following: #!/bin/sh @@ -2376,22 +2338,22 @@ ipfw - The ipfw command is the normal vehicle for making manual - single rule additions or deletions to the firewall active + The ipfw command is the normal vehicle for making manual + single rule additions or deletions to the active firewall internal rules while it is running. The problem with using this method is once your system is shutdown or halted all the - rules you added or changed or deleted are lost. Writing all + rules that were added, changed or deleted are lost. Writing all your rules in a file and using that file to load the rules at boot time, or to replace in mass the currently running firewall - rules with changes you made to the files content is the + rules with changes you made to the files content, is the recommended method used here. - The ipfw command is still a very useful to display the + The ipfw command is still a very useful way to display the running firewall rules to the console screen. The IPFW accounting facility dynamically creates a counter for each rule that counts each packet that matches the rule. During the process of testing a rule, listing the rule with its counter - is the one of the ways of determining if the rule is + is one of the ways of determining if the rule is functioning. To list all the rules in sequence: @@ -2403,7 +2365,7 @@ &prompt.root; ipfw -t list - To list the accounting information, packet count for + The next example lists accounting information, the packet count for matched rules along with the rules themselves. The first column is the rule number, followed by the number of outgoing matched packets, followed by the number of incoming matched @@ -2424,33 +2386,30 @@ &prompt.root; ipfw zero - Zero the counters for just rule + Zero the counters for just the rule with number NUM: - &prompt.root; ipfw zero NUM + &prompt.root; ipfw zero NUM IPFW Rule Sets - + - A rule set is a group of ipfw rules coded to allow or deny + A rule set is a group of IPFW rules coded to allow or deny packets based on the values contained in the packet. The bi-directional exchange of packets between hosts comprises a - session conversation. The firewall rule set processes the - packet twice: once on its arrival from the public Internet host - and again as it leaves for its return trip back to the public - Internet host. Each tcp/ip service (i.e. telnet, www, mail, - etc.) is predefined by its protocol, and port number. This is - the basic selection criteria used to create rules which will - allow or deny services. + session conversation. The firewall rule set processes both the + packets arriving from the public Internet, as well as the packets + originating from the system as a response to them. + Each TCP/IP service (i.e. telnet, www, The "i.e.: " thing again. + mail, etc.) is predefined by its protocol and privileged (listening) + port. Packets destined for a specific service, originate from the + source address using an unprivileged (high order) port and target + the specific service port on the destination address. All the above + parameters (i.e. ports and addresses) can be used as selection + criteria to create rules which will pass or block services. IPFW @@ -2461,14 +2420,14 @@ When a packet enters the firewall it is compared against - the first rule in the rule set and progress one rule at a time + the first rule in the rule set and progresses one rule at a time moving from top to bottom of the set in ascending rule number - sequence order. When the packet matches a rule selection - parameters, the rules action field value is executed and the + sequence order. When the packet matches the selection parameters + of a rule, the rules' action field value is executed and the search of the rule set terminates for that packet. This is referred to as the first match wins search method. If the packet does not match any of the rules, it gets - caught by the mandatory ipfw default rule, number 65535 which + caught by the mandatory IPFW default rule, number 65535 which denies all packets and discards them without any reply back to the originating destination. @@ -2479,26 +2438,13 @@ The instructions contained here are based on using rules - that contain the stateful 'keep state', 'limit', 'in'/'out', - and via options. This is the basic framework for coding an + that contain the stateful keep state, limit, in, out + and via options. This is the basic framework for coding an inclusive type firewall rule set. - - - An inclusive firewall only allows services matching the - rules through. This way you can control what services can - originate behind the firewall destine for the public Internet - and also control the services which can originate from the - public Internet accessing your private network. Everything - else is denied by default design. Inclusive firewalls are - much, much more secure than exclusive firewall rule sets and - is the only rule set type covered here in. - - When working with the firewall rules be careful, you can - end up locking your self out. + Be careful when working with firewall rules, as it is easy to + end up locking yourself out. @@ -2580,17 +2526,17 @@ log or logamount - When a packet matches a rule with the log keyword, a - message will be logged to syslogd with a facility name of + When a packet matches a rule with the log keyword, a + message will be logged to &man.syslogd.8; with a facility name of SECURITY. The logging only occurs if the number of packets logged so far for that particular rule does not - exceed the logamount parameter. If no logamount is + exceed the logamount parameter. If no logamount is specified, the limit is taken from the sysctl variable - net.inet.ip.fw.verbose_limit. In both cases, a value of + net.inet.ip.fw.verbose_limit. In both cases, a value of zero removes the logging limit. Once the limit is reached, logging can be re-enabled by clearing the logging counter or the packet counter for that rule, see - the ipfw reset log command. + the ipfw reset log command. Logging is done after @@ -2605,50 +2551,50 @@ Selection The keywords described in this section are used to - describe attributes of the packet to be interrogated when + describe attributes of the packet to be checked when determining whether rules match the packet or not. The following general-purpose attributes are provided for matching, and must be used in this order: udp | tcp | icmp - or any protocol names found in - /etc/protocols are recognized and may - be used. The value specified is protocol to be matched + Any other protocol names found in + /etc/protocols are also recognized and may + be used. The value specified is the protocol to be matched against. This is a mandatory requirement. from src to dst - The from and to keywords are used to match against IP - addresses. Rules must specify BOTH source and destination + The from and to keywords are used to match against IP + addresses. Rules must specify both source and destination parameters. any is a special keyword that matches any IP address. me is a special keyword that matches any IP address configured on an interface in your &os; system to represent the PC the - firewall is running on (i.e. this box) as in 'from me to - any' or 'from any to me' or 'from 0.0.0.0/0 to any' or - 'from any to 0.0.0.0/0' or 'from 0.0.0.0 to any' or 'from - any to 0.0.0.0' or 'from me to 0.0.0.0'. IP addresses are - specified as a dotted IP address numeric form/mask-length, + firewall is running on (i.e. this box) as in from me to Again "i.e.: " + any or from any to me or from 0.0.0.0/0 to any or + from any to 0.0.0.0/0 or from 0.0.0.0 to any or from + any to 0.0.0.0 or from me to 0.0.0.0. IP addresses are + specified as a dotted IP address numeric form/mask-length (CIDR notation), or as single dotted IP address numeric form. This is a - mandatory requirement. See this link for help on writing - mask-lengths. port number For protocols which support port numbers (such as - TCP and UDP). It is mandatory that you - code the port number of the service you want to match - on. Service names (from + TCP and UDP), it is mandatory to + code the port number of the service that will be matched. + Service names (from /etc/services) may be used instead of numeric port values. in | out Matches incoming or outgoing packets, respectively. - The in and out are keywords and it is mandatory that you - code one or the other as part of your rule matching + The in and out are keywords and it is mandatory that + one or the other is coded as part of your rule matching criterion. via IF @@ -2677,9 +2623,9 @@ N connections with the same set of parameters as specified in the rule. One or more of source and destination addresses and ports can be - specified. The 'limit' and 'keep-state' can not be used on - same rule. Limit provides the same stateful function as - 'keep-state' plus its own functions. + specified. The limit and keep-state can not be used on the + same rule. The limit option provides the same stateful function as + keep-state, plus its own functions. @@ -2696,17 +2642,17 @@ Stateful filtering treats traffic as a bi-directional exchange of packets comprising a session conversation. It - has the interrogation abilities to determine if the session + has the matching capabilities to determine if the session conversation between the originating sender and the destination are following the valid procedure of bi-directional packet exchange. Any packets that do not properly fit the session conversation template are automatically rejected as impostors. - 'check-state' is used to identify where in the IPFW rules + The check-state option is used to identify where in the IPFW rules set the packet is to be tested against the dynamic rules facility. On a match the packet exits the firewall to - continue on its way and a new rule is dynamic created for + continue on its way and a new rule is dynamically created for the next anticipated packet being exchanged during this bi-directional session conversation. On a no match the packet advances to the next rule in the rule set for @@ -2715,14 +2661,14 @@ The dynamic rules facility is vulnerable to resource depletion from a SYN-flood attack which would open a huge number of dynamic rules. To counter this attack, &os; - added another new option named limit. This + added another new option named limit. This option is used to limit the number of simultaneous session - conversations by interrogating the rules source or - destinations fields as directed by the limit option and + conversations by checking the rules source or + destinations fields as directed by the limit option and using the packet's IP address found there, in a search of the open dynamic rules counting the number of times this rule and IP address combination occurred, if this count is - greater that the value specified on the limit option, the + greater that the value specified on the limit option, the packet is discarded. @@ -2738,41 +2684,41 @@ The benefits of logging are obvious: it provides the ability to review after the fact the rules you activated logging on which provides information like, what packets had - been dropped, what addresses they came from, where they were + been dropped, what addresses they came from and where they were going, giving you a significant edge in tracking down "were going" could probably be "went" here. But that is outside scope of the patch so we could just classify that as a later fix up. attackers. Even with the logging facility enabled, IPFW will not generate any rule logging on it's own. The firewall - administrator decides what rules in the rule set he wants - to log and adds the log verb to those rules. Normally only + administrator decides what rules in the rule set will be + logged, and adds the log verb to those rules. Normally only deny rules are logged, like the deny rule for incoming ICMP pings. It is very customary to - duplicate the ipfw default deny everything rule with the - log verb included as your last rule in the rule set. This - way you get to see all the packets that did not match any + duplicate the ipfw default deny everything rule with the + log verb included as your last rule in the rule set. This + way it is possible to see all the packets that did not match any of the rules in the rule set. Logging is a two edged sword, if you are not careful, you can lose yourself in the over abundance of log data and fill your disk up with growing log files. DoS attacks that fill up disk drives is one of the oldest attacks around. These - log message are not only written to syslogd, but also are + log messages are not only written to syslogd, but also are displayed on the root console screen and soon become very annoying. The IPFIREWALL_VERBOSE_LIMIT=5 kernel option limits the number of consecutive messages - sent to the system logger syslogd, concerning the packet + sent to the system logger &man.syslogd.8;, concerning the packet matching of a given rule. When this option is enabled in the kernel, the number of consecutive messages concerning a particular rule is capped at the number specified. There is nothing to be gained from 200 log messages saying the same identical thing. For instance, five consecutive messages concerning a particular rule would be logged to - syslogd, the remainder identical consecutive messages would - be counted and posted to the syslogd with a phrase like - this: + syslogd, the remainder identical consecutive messages would + be counted and posted to syslogd with a phrase like + the following: last message repeated 45 times @@ -2788,18 +2734,18 @@ rules and code them in a manner compatible with running them as a script. The major benefit of doing this is the firewall rules can be refreshed in mass without the need of rebooting - the system to activate the new rules. This method is very + the system to activate them. This method is very convenient in testing new rules as the procedure can be - executed as many times as needed. Being a script, you can - use symbolic substitution to code frequent used values and - substitution them in multiple rules. You will see this in + executed as many times as needed. Being a script, + symbolic substitution can be used to code frequent used values and + substitute them in multiple rules. This is shown in the following example. - The script syntax used here is compatible with the 'sh', - 'csh', 'tcsh' shells. Symbolic substitution fields are + The script syntax used here is compatible with the &man.sh.1;, + &man.csh.1;, &man.tcsh.1; shells. Symbolic substitution fields are prefixed with a dollar sign $. Symbolic fields do not - have the $ prefix. The value to populate the Symbolic - field must be enclosed to "double quotes". + have the $ prefix. The value to populate the symbolic + field must be enclosed in "double quotes". Start your rules file like this: @@ -2820,12 +2766,12 @@ ################### End of example ipfw rules script ############ That is all there is to it. The rules are not important - in this example, how the Symbolic substitution field are + in this example, how the symbolic substitution field are populated and used are. - If the above example was in - /etc/ipfw.rules file, you could reload - these rules by entering on the command line. + If the above example was in the + /etc/ipfw.rules file, the rules could be + reloaded by entering the following on the command line. &prompt.root; sh /etc/ipfw.rules @@ -2852,8 +2798,8 @@ example of how to code a very secure 'inclusive' type of firewall. An inclusive firewall only allows services matching pass rules through and blocks all other by default. - All firewalls have at the minimum two interfaces which have - to have rules to allow the firewall to function. + Firewalls designed to protect entire network segments, have at minimum two interfaces which must + have rules to allow the firewall to function. All &unix; flavored operating systems, &os; included, are designed to use interface lo0 and IP @@ -2862,15 +2808,15 @@ rules must contain rules to allow free unmolested movement of these special internally used packets. - The interface which faces the public Internet, is the one - which you code your rules to authorize and control access out - to the public Internet and access requests arriving from the - public Internet. This can be your ppp + The interface which faces the public Internet is the one + to place the rules that authorize and control access of the + outbound and inbound connections. This can be your user + PPP tun0 interface or your NIC that is connected to your DSL or cable modem. - In cases where one or more than one NIC are connected to - a private LANs behind the firewall, those interfaces must + In cases where one or more than one NICs are connected to + a private LAN behind the firewall, those interfaces must have rules coded to allow free unmolested movement of packets originating from those LAN interfaces. @@ -2881,41 +2827,38 @@ The order of the rules in each of the public interface sections should be in order of the most used rules being placed before less often used rules with the last rule in - the section being a block log all packets on that interface + the section blocking and logging all packets on that interface and direction. The Outbound section in the following rule set only - contains 'allow' rules which contain selection values that + contains allow rules which contain selection values that uniquely identify the service that is authorized for public - Internet access. All the rules have the, proto, port, - in/out, via and keep state option coded. The 'proto tcp' - rules have the 'setup' option included to identify the start + Internet access. All the rules have the proto, port, + in/out, via and keep state option coded. The proto tcp + rules have the setup option included to identify the start session request as the trigger packet to be posted to the keep state stateful table. The Inbound section has all the blocking of undesirable - packets first for two different reasons. First is these - things being blocked may be part of an otherwise valid packet - which may be allowed in by the later authorized service - rules. Second reason is that by having a rule that - explicitly blocks selected packets that I receive on an - infrequent bases and do not want to see in the log, this - keeps them from being caught by the last rule in the section - which blocks and logs all packets which have fallen through - the rules. The last rule in the section which blocks and - logs all packets is how you create the legal evidence needed + packets first, for two different reasons. The first is that + malicious packets may be partial matches for legitimate traffic. + These packets have to be discarded rather than allowed in, based on + their partial matches against allow rules. + The second reason is that known and uninteresting rejects may be + blocked silently, rather than being caught and logged by the last + rules in the section. The final rule in each section, blocks and + logs all packets and can be used to create the legal evidence needed to prosecute the people who are attacking your system. - Another thing you should take note of, is there is no - response returned for any of the undesirable stuff, their - packets just get dropped and vanish. This way the attackers + Another thing that should be taken care of, is to insure there + is no response returned for any of the undesirable stuff. Invalid + packets should just get dropped and vanish. This way the attacker has no knowledge if his packets have reached your system. - The less the attackers can learn about your system the more - secure it is. When you log packets with port numbers you do - not recognize, look the numbers up in - /etc/services/ or go to /etc/services/ or go to - and do a port number lookup to find what the purpose of that + and do a port number lookup to find the purpose of the particular port number is. Check out this link for port numbers used by Trojans: . @@ -2925,36 +2868,37 @@ An Example Inclusive Ruleset The following non-NATed rule set is a - complete inclusive type ruleset. You can not go wrong using - this rule set for you own. Just comment out any pass rules - for services you do not want. If you see messages in your - log that you want to stop seeing just add a deny rule in the - inbound section. You have to change the 'dc0' interface name - in every rule to the interface name of the NIC that connects - your system to the public Internet. For user ppp it would be - 'tun0'. + complete inclusive type ruleset. It is safe to use this rule set + on your own systems. Just comment out any pass + rules for services that are not required. To avoid logging + undesired messages, add a deny rule in the + inbound section. The dc0 interface will + will have to be changed in every rule, with the actual name of the + interface (NIC) that connects your system to the public Internet. + For user PPP, this would be + tun0. - You will see a pattern in the usage of these + There is a noticeable pattern in the usage of these rules. All statements that are a request to start a session - to the public Internet use keep-state. + to the public Internet use keep-state. All the authorized services that originate from the - public Internet have the limit option to stop + public Internet have the limit option to stop flooding. - All rules use in or out to clarify direction. + All rules use in or out to clarify direction. - All rules use via interface name to specify the + All rules use via interface-name to specify the interface the packet is traveling over. @@ -3047,8 +2991,8 @@ ################################################################# # Interface facing Public Internet (Inbound Section) -# Interrogate packets originating from the public Internet -# destine for this gateway server or the private network. +# Check packets originating from the public Internet +# destined for this gateway server or the private network. ################################################################# # Deny all inbound traffic from non-routable reserved address spaces @@ -3124,7 +3068,7 @@ There are some additional configuration statements that need to be enabled to activate the NAT - function of IPFW. The kernel source needs 'option IPDIVERT' + function of IPFW. The kernel source needs option IPDIVERT I've always used: option SOMEOPTION But that's probably not a huge deal. statement added to the other IPFIREWALL statements compiled into a custom kernel. @@ -3136,14 +3080,14 @@ natd_interface="rl0" # interface name of public Internet NIC natd_flags="-dynamic -m" # -m = preserve port numbers if possible - Utilizing stateful rules with divert natd rule (Network + Utilizing stateful rules with divert natd rule (Network Address Translation) greatly complicates the rule set coding - logic. The positioning of the check-state, and 'divert natd' + logic. The positioning of the check-state, and divert natd rules in the rule set becomes very critical. This is no longer a simple fall-through logic flow. A new action type - is used, called 'skipto'. To use the skipto command it is - mandatory that you number each rule so you know exactly - where the skipto rule number is you are really jumping + is used, called skipto. To use the skipto command it is + mandatory that each rule is numbered, so the + skipto rule number knows exactly where it is jumping to. The following is an uncommented example of one coding @@ -3152,67 +3096,69 @@ The processing flow starts with the first rule from the top of the rule file and progress one rule at a time deeper - into the file until the end is reach or the packet being + into the file until the end is reached or the packet being tested to the selection criteria matches and the packet is released out of the firewall. It is important to take notice of the location of rule numbers 100 101, 450, 500, and 510. These rules control the translation of the outbound and inbound packets so their entries in the keep-state dynamic table always register the private LAN IP address. Next - notice that all the allow and deny rules specified the - direction the packet is going (IE outbound or inbound) and - the interface. Also notice that all the start outbound - session requests all skipto rule 500 for the network address + notice that all the allow and deny rules specify the + direction the packet is going (i.e. outbound or inbound) and i.e.: again. ;) + the interface. Also notice that the start outbound + session requests, all skipto rule 500 for the network address translation. Lets say a LAN user uses their web browser to get a web - page. Web pages use port 80 to communicate over. So the - packet enters the firewall, It does not match 100 because it - is headed out not in. It passes rule 101 because this is the - first packet so it has not been posted to the keep-state + page. Web pages are transmitted over port 80. So the + packet enters the firewall. It does not match rule 100 because it + is headed out rather than in. It passes rule 101 because this is the + first packet, so it has not been posted to the keep-state dynamic table yet. The packet finally comes to rule 125 a matches. It is outbound through the NIC facing the public Internet. The packet still has it's source IP address as a private LAN IP address. On the match to this rule, two - actions take place. The keep-state option will post this + actions take place. The keep-state option will post this rule into the keep-state dynamic rules table and the specified action is executed. The action is part of the info - posted to the dynamic table. In this case it is "skipto rule - 500". Rule 500 NATs the packet IP address + posted to the dynamic table. In this case it is skipto rule + 500. Rule 500 NATs the packet IP address and out it goes. Remember this, this is very important. - This packet makes its way to the destination and returns and + This packet makes its way to the destination, where a response + packet is generated and sent back. This new packet enters the top of the rule set. This time it does match rule 100 and has it destination IP address mapped back to its corresponding LAN IP address. It then is processed by the - check-state rule, it's found in the table as an existing + check-state rule, it is found in the table as an existing session conversation and released to the LAN. It goes to the LAN PC that sent it and a new packet is sent requesting another segment of the data from the remote server. This - time it gets checked by the check-state rule and its outbound - entry is found, the associated action, 'skipto 500', is + time it gets checked by the check-state rule and its outbound + entry is found, the associated action, skipto 500, is executed. The packet jumps to rule 500 gets NATed and released on it's way out. On the inbound side, everything coming in that is part of an existing session conversation is being automatically - handled by the check-state rule and the properly placed - divert natd rules. All we have to address is denying all the + handled by the check-state rule and the properly placed + divert natd rules. All we have to address is denying all the bad packets and only allowing in the authorized services. - Lets say there is a apache server running on the firewall box + Lets say there is an apache server running on the firewall box and we want people on the public Internet to be able to access the local web site. The new inbound start request packet matches rule 100 and its IP address is mapped to LAN IP for the firewall box. The packet is them matched against - all the nasty things we want to check for and finally matches + all the nasty things that need to be checked for and finally matches against rule 425. On a match two things occur. The packet rule is posted to the keep-state dynamic table but this time any new session requests originating from that source IP address is limited to 2. This defends against DoS attacks of service running on the specified port number. The action is - allow so the packet is released to the LAN. On return the - check-state rule recognizes the packet as belonging to an - existing session conversation sends it to rule 500 for - NATing and released to outbound + allow so the packet is released to the LAN. + The packet generated as a response, is recognized by the + check-state as belonging to an + existing session conversation. It is then sent to rule 500 for + NATing and released to the outbound interface. Example Ruleset #1: @@ -3306,9 +3252,9 @@ ################################################################# # Interface facing Public Internet (Outbound Section) -# Interrogate session start requests originating from behind the +# Check session start requests originating from behind the # firewall on the private network or from this gateway server -# destine for the public Internet. +# destined for the public Internet. ################################################################# # Allow out access to my ISP's Domain name server. @@ -3356,8 +3302,8 @@ ################################################################# # Interface facing Public Internet (Inbound Section) -# Interrogate packets originating from the public Internet -# destine for this gateway server or the private network. +# Check packets originating from the public Internet +# destined for this gateway server or the private network. ################################################################# # Deny all inbound traffic from non-routable reserved address spaces -- Tom Rhodes