The firewall logs, and by default, syslog will put this on the screen. You can turn that off using dmesg(8). Specifically, you want to type dmesg -n 1. Or edit /etc/syslog.conf to put all the logging on another console. Firewalls shouldn't have monitors anyway. :) 

  

 ---- 

 !!!How it works 

  

  

  

 ;${if}-in: Used by all packets entering by this interface for this host only. 

 ;${if}-out: Used by all packets leaving by this interface for this host only. 

 ;${if}-forward-in: Used by packets coming IN this interface that aren't destined for this host itself. 

 ;${if}-forward-out: Used by packets going OUT an interface that aren't originated by this host itself 

 and it will correctly add the --append ${if}- for you and use the correct table too so you don't have to remember if it's the mangle, filter or nat table :) 

  

 Now, you often have a lot of rules that are common between interface, and are even common between firewall installations, for instance some rules that deny all incoming TCP connections but allow outgoing TCP connections. These are stored in the ruleset.d/ directory (discussed later). These firewall "fragments" can be loaded on the fly automatically and used as targets. There is a neat little wrapper around this that you will probably use for almost all your firewalling rules called "policy". policy takes two (or more) arguments, the first is the chain name as you would provide to "apply_policy" and the second is the target, the remaining arguments are passed directly to iptables and can be used for more filtering. 

 some examples: 

 will load the "tcp-strict" ruleset from the ruleset.d directory, and then issue a iptables rule such as: 

 policy will not load a ruleset twice if it's used twice, and will not load rulesets that aren't used to save memory. policy is also smart enough to know about built in rules and some aliases that can be used to make things more clear. 

  

  policy in ACCEPT 

  policy out ACCEPT 

  policy forward-in ACCEPT 

  policy forward-out ACCEPT 

  

 You should only need to use "policy" in the interfaces.d/ directory. In most firewalls I put in place policy is the only command in the interfaces.d directory (sometimes I have a for loop if I've got a range of ports I want to do something with for instance). 

  

 There are also interface features which you can specify in these files. These are /proc entries in /proc/sys/net/ipv4/conf/${if}/*. there is an alias to manage these for you "if_feature". For instance: 

  if_feature rp_filter 1 # enable reverse path filtering for this interface 

  if_feature accept_redirects # accept ICMP redirects on this interface 

 etc... 

  

 There are several example class files in CVS. There are several standard interface "types" (eg: "external", "internal", "dmz" etc) and then you symlink interfaces to these. eg: 

  ln -s external eth0.if 

  ln -s internal eth1.if 

  ln -s dmz eth2.if 

  

 There are two new commands now that should appear as the very first rule in a interface definition. 

  

 Also new main scripts were added: 

 ;fw-ipup: This brings up only one interface and presumes that the main "firewall" script has been run to set everything up. It takes one or two parameters. The first parameter is the interface name (such as eth0, eth1) and the second is an optional name for the name of the interface definition to read. For instance a wireless interface might use "home" or "work", so you could type: 

  ifup eth0 home 

 ;fw-ipdown: This removes all the firewalling rules to do with an interface. Dynamic rulesets that are loaded by that interface are __not__ removed, however won't be executed by packets so only a very slight memory overhead is kept. 

  

 This is used to store fragments of a firewall, each fragment does something simple and can be used by interface.d files. rulesets have the form of "''name''.rule". rulesets don't have much in the way of helper functions. The first line of them should be: 

  . support/ruleset.functions 

 the environmental variable ${RULE} will be set to the rule name (basically the name of the file less the ".rule" extension, and the environmental variable ${IPTABLES} will be set to the path to the iptables executable. There are also "polite_reject" and "polite_drop" which will be discussed later. 

  

 ;tcp-trust: Allows all TCP except to some well known ports that it shouldn't have access to (eg: linuxconf, nfs and portmap etc). Useful for an interface that is connecting to another department that you trust and want traffic to flow to and from, but they don't need any of your sensitive services, so if they get compromised hopefully the attacker won't get the opertunity to compromise you too. 

 ;udp-strict: Disallows incoming UDP that isn't part of an already established "connection" (ie: a reply from a packet that was originated here) 

 ;udp-trust: Disallows incoming UDP to potentially dangerous ports (NFS, Portmap, tftp etc) 

  

  

 !!Misc commands 

 There are also some misc commands that can be used from both interfaces.d/ and ruleset.d/ 

  

 ;polite_reject: requires at least one argument, the first is the rule to append to, the rest is any other iptables options that may be used (eg: limiting it by port). polite_reject then rejects the packets ratelimited to 5/s and logs them at a rate of 2/s, rendering floods less effective. All packets that aren't rejected are dropped. 

  

 ;polite_drop: same as polite_reject but only logs at 2/s and doesn't send back reject messages. This is useful for rules where you know that the rejects aren't going to be used (for example if the source address is a martian) or it could be downright harmful (eg: the packet was directed towards a multicast or broadcast address). 

  

 !!FAQ 

 ;__Q__:Why do I get lots of messages saying "End of ''something''" on my screen/in my syslog 

 ;__A__:You don't have a catch all rule for something in one of your class files. Look at the syslog messages carefully and see what interface they are dealing with and which rule you are missing. 

  

 !!Wishlist features 

 These are all wishlist features which may or may not get implemented :)