Boldfaced directories have been collapsed into one listing. Click on them to see their contents.
The address module checks for _invalid_ source and destination addresses, such as loopback, multicast, and broadcast address usage. These rules should be safe to use on any network.
The autoreject module sets up a chain that can be called from other firewall rules. It detects what kind of traffic is going by and sets up the appropriate reject for that traffic, as opposed to just calling -j REJECT which sends a port unreachable, even if the traffic is not udp.
It specifically sends _no_ reject message in response to the following: tcp rst packets, icmp destination unreachables, icmp time exceededs, and icmp parameter problems (to avoid rfc-violating loops).
The banfor30 module provides a chain which, if called by some other rule, bans that source IP from making NEW connections for 30 seconds. Actually, this chain just _remembers_ the source IP in the "banfor30" recent table; to actually accomplish a 30 second ban, the "checkbans" brick must be loaded before NEW traffic rules accept traffic.
The blockfwdports module puts in blocks for services that should never be forwarded through this firewall. The ports to block are set in /etc/modwall/blockfwdports.conf .
This module should be safe to use on any network, but you will have to decide what services are appropriate to block.
The bogons module checks for bogon source addresses; addresses which have not yet been assigned by IANA. No legitimate hosts should be using them.
This module should be safe to use, but please check no less than once a month for an updated bogon list. The file can be found at http://www.cymru.com/Documents/bogon-bn-agg.txt and should be placed in /var/lib/modwall//bogon-bn-agg.txt .
The canarydst module looks at traffic going to closed ports and unused machines - canaries. The assumption is that if someone goes to a closed port/machine, they are probably going after a real machine next - we will catch them and block them for 30 seconds so they cannot get to the real machine either.
Experimental.
The catchmapper module identifies people trying to map our network. It uses the psd (port scan detector) module to identify - you guessed it - port scans. When found, the source address of the scan is remembered in the mapper table for punishment by the punishmapper module.
Because of the potential for a spoofed source address in a probe packet, this is a potentially dangerous module.
The catchmapreply module identifies people trying to map our network. It looks for icmp errors such as proto, host, network, or port unreachables, as well as time exceeded in transit errors, and remembers the _destination_ ip address of those packets - the IP that sent the probe packet.
Because of the potential for a spoofed source address in a probe packet, this is a potentially dangerous module.
If the checkbans module sees state NEW traffic arriving from an IP address that was banned (i.e., some other module placed it in the "banfor30" chain) in the last 30 seconds, the traffic is dropped.
The established module allows all state ESTABLISHED or RELATED traffic through. It should go after checks for illegal packet characteristics (which is the role of most of the other bricks). Rules and chains following this one can then focus on the state NEW packets (the starting packets of the conversation).
Not only is this safe to use, but the stateful nature of iptables firewalling provided by the state module actual improves the security of a firewall. The only circumstance in which this might not be a good idea is if you have a firewall that is already straining to handle a very high load. In that case, stateful checks should be moved to one or more additional firewalls behind the main one.
The fwddstaddrtype module checks the destination address for valid and invalid address types, as maintained by the kernel. For example, should we really be sending packets to an address the kernel knows is administratively prohibited?
This module is somewhat experimental, but the checks should be conservative enough to safely use.
The fwdsrcaddrtype module checks the source address for valid and invalid address types, as maintained by the kernel. For example, should we really be receiving packets from an address the kernel knows is unreachable?
This module is somewhat experimental, but the checks should be conservative enough to safely use.
The histogram module simply logs the sizes of the packets (with the exception of packets going over the loopback interface, which can have odd sizes). With 1500 rules, this is not for regular use, but more for learning.
The icmpchk module puts in some blocks for fragmented icmp packets (illegal) and address mask and timestamp requests and replies. At best, these are uncommon and are used in network mapping. These rules should be safe to use on any network.
The icmpfwdchk module checks only icmp packets being forwarded through this router. It specifically disallows fragmented ICMP and ICMP redirects. Both should be universally safe to forward.
If a firewall drops Ident (tcp port 113) trafficwith out sending back a reset, this results in email, rlogin and irc connections that take two minutes to get going. _If_ you plan to disallow ident traffic, common firewall wisdom says to reject it with a reset instead of dropping it; this identreject module does that.
_Do_ _not_ use this module if you need to allow ident traffic across your firewall.
The inputsrcaddrtype module checks the source address for valid and invalid address types, as maintained by the kernel. For example, should we really be receiving packets from an address the kernel knows is unreachable?
This module is somewhat experimental, but the checks should be conservative enough to safely use.
The ipopts module checks for any IP options and discards/logs those packets. The Strict and Loose source route IP options are generally considered malicious as they can circumvent Internet routing tables. IP options are generally not used legitimately, and it is a common practice to block them at the firewall.
IP options (generally malicious) are distinct from TCP options, which are generally _not_ malicious and are in common use.
These rules should be safe to use on any network.
The kernel module sets some standard security settings in the Linux kernel /proc filesystem. When run, it returns the commands needed to return the kernel to its previous state, allowing you to save the current settings.
These are generally safe to use.
The local-forward-accept module is for locally defined rules of FORWARD traffic that is to be accepted.
The local-input-accept module is for locally defined rules of INPUT traffic that is to be accepted.
The local-output-accept module is for locally defined rules of OUTPUT traffic that is to be accepted.
The lockdown module completely blocks all traffic going in, out or through the machine. It is designed to go at the top of the ruleset, blocking all traffic while the network interfaces, routing tables, and firewall rules are being set up. Once those are all in place, the lockdown module can be shut down, allowing traffic to flow normally.
The logremainder module logs all non-loopback traffic not handled by a previous rule.
The macchk module checks for valid IP address/Mac address/Interface triplets. You will need to fill in the LegalMacs and NeverCheckMac arrays in /etc/modwall/modwall.conf for this to be functional.
Not good for DHCP environments where IP addresses change (where there are too few addresses for the machines that need them).
The mapssh module uses some very tight checks to identify the SSH protocol string found at the beginning of a connection. Because it strictly limits how many packets it inspects, it _should_ not produce high load on the system, even when inspecting every tcp connection. There is a small chance of false positives and/or false negatives.
The outputdstaddrtype module checks the destination address for valid and invalid address types, as maintained by the kernel. For example, should we really be sending packets to an address the kernel knows is administratively prohibited?
This module is somewhat experimental, but the checks should be conservative enough to safely use.
The pasvmap module doesn\'t block any traffic, but simply passively logs any tcp servers to syslog. It does this by logging established SYN/ACK packets; these must have come from a real server at the logged source IP address and source port.
Any "IP Port" pairs listed in /var/lib/modwall//tcpservers are returned before hitting the log rule; place any known servers here.
The only reason why you might want to avoid this module is because it may log heavily. Otherwise it should be univerally safe.
The plength module takes a closer look at the lengths of certain types of packets. Certain types of packets should be _at least_ N bytes long. For example, since normal fragmentation produces non-terminal fragments that are at least the MTU large, we should never see a non-terminal packet smaller than 68 bytes (the rfc791 minimum MTU) or even less than 512 bytes (the Internet practical minimum MTU). See the notes in this file for more details about the packet types and reasons for their minimums lengths.
We have put enough thought into this module that it _should_ be safe to use, but it could really use a few days on an unprotected ISP router to be sure I haven\'t missed some subtle issue. It might be worth running this with an action of NONE for a few hours before putting it into production use.
The policy module sets the policy (action to take if no rule matches) at the end of each of the 3 built-in chains (INPUT, OUTPUT, and FORWARD). The policy can be set by setting: DefaultPolicy='ACCEPT'
or DefaultPolicy='DROP'
in /etc/modwall/modwall.conf , or can be specified on the command line (command line overrides file setings).
The punishmapper module punishes people that have already violated one of our security policies (they\'ve _already_ sent in syn/fin packets, portscans, probes, etc.). Their addresses are already in a kernel table of offending source addresses, courtesy of the ipt_recent match module.
This table is called after we\'ve checked for nasty traffic, but before the normal allow rules. We now treat any other packets from that host as hostile and log and drop them.
This is by no means a sure thing; we\'re implementing an Intrusion Prevention system, with all its caveats and issues. You may wish to tread carefully with this one.
Once the scrutinizesrc or scrutinizedst module has remembered an IP address in the recent "scrutinize" table, this module is responsible for logging all packets to or from that IP for the next two minutes. ulogd must be running in userspace to receive the packets and send them to a pcap file or sql database. See http://www.stearns.org/doc/iptables-ulog.current.html for more info on how this is done.
The scrutinizedst module is a helper module. If a rule in some other part of the firewall identifies something suspicious, it can choose to "-j scrutinizedst". For two minutes from that point, all packets to that IP address get logged to userspace, where ulogd can save the complete packets to a pcap/bpf file, or to a MySQL or Postgresql database.
The scrutinizesrc module is a helper module. If a rule in some other part of the firewall identifies something suspicious, it can choose to "-j scrutinizesrc". For two minutes from that point, all packets from that IP address get logged to userspace, where ulogd can save the complete packets to a pcap/bpf file, or to a MySQL or Postgresql database.
The shundst module places permanent bans on destination IP addresses or networks listed in any files whose names start with /var/lib/modwall//shun .
The shunsrc module places permanent bans on source IP addresses or networks listed in any files whose names start with /var/lib/modwall//shun .
The syncapture module sends all packets with SYN set up to userspace to be stored in a libpcap file (or wherever ulogd decides to send it). This will capture SYN and SYN/ACK packets that tools like p0f and ettercap like to do their OS fingerprinting, as well as providing the firewall administrator with essentially enough packet logging to be able to reconstruct all TCP connection attempts (both successful and not). Note that the third packet of a three way handshake is not saved to the pcap file.
In addition to the normal SYN and SYN/ACK packets, this will capture _any_ packets with the SYN bit set, including SYN/FIN, SYN/RST, etc.
If Ulogd is not running or not available, you will probably want to change the default action to LOG (but remember that the rate limiting used on LOG may lose some events).
This module carries a small risk of filling up your log drive if you come under attack. With that warning, it should be safe to use otherwise.
The tcpchk module checks characteristics of tcp traffic. It handles low port (ports 0-19) and illegal tcp flag combinations. The flag rules tend to be conservative, so it should be safe to use these in any environment (unless you know you are using small services).
The udpchk module checks for low port (0-21) traffic. These rules should be safe to use in any network.
Welcome to Modwall, the Modular firewall.
This is most definitely a work in progress. These are slowly working their way towards being a set of independent firewall modules which can be inserted into any existing firewall. Use caution, only light testing so far. Feedback welcome.
This project was originally called Firebricks, but changed its name to avoid a clash with an existing firewall product.
Name : modwall Relocations: (not relocatable) Version : 0.2.3 Vendor: William Stearns Release : 0 Build Date: Tue May 24 00:30:22 2005 Install Date: (not installed) Build Host: sparrow Group : Networking/Admin Source RPM: modwall-0.2.3-0.src.rpm Size : 209270 License: GPL Signature : RSA/MD5, Tue May 24 00:30:24 2005, Key ID 012334cbf322929d Packager : William Stearns <wstearns@pobox.com> URL : http://www.stearns.org/modwall/ Summary : Firewall modules that can be used in an existing firewall Description : Modwall provides a collection of independent firewall modules. These can be used to create a complete firewall, or can be individually inserted into an existing firewall.
Name : firebricks Relocations: (not relocatable) Version : 0.1.8 Vendor: William Stearns Release : 0 Build Date: Sun Jan 25 14:34:53 2004 Install Date: (not installed) Build Host: sparrow Group : Networking/Admin Source RPM: firebricks-0.1.8-0.src.rpm Size : 201750 License: GPL Signature : RSA/MD5, Sun Jan 25 14:34:54 2004, Key ID 012334cbf322929d Packager : William Stearns <wstearns@pobox.com> URL : http://www.stearns.org/firebricks/ Summary : Firewall modules that can be used in an existing firewall Description : Firebricks provides a collection of independent firewall modules. These can be used to create a complete firewall, or can be individually inserted into an existing firewall.
The files in this collection are part of William Stearns' software archive. If any of the links on this page do not work, you may be viewing an incomplete mirror. There is a complete list of the mirror sites at the starting page for this mirror and at the primary mirror.