Firewall & Perimeter Protection

From ChekMate Security Group

Blake (a Calgarian) solicits the members of BBR to get an unsolicited packet through the NAT/Firewall of several popular home routers.
Challenge Delivered
First Winner
  • Kerio, Sygate, ZoneAlarm Personal firewalls. Sygate and Kerio's firewalls are more advanced than ZoneAlarm

pf Firewall

The pf firewall is a BSD licenced firewall that showed up around OpenBSD 3.0. It has been adopted by FreeBSD, NetBSD and a few others. It is known for it's clarity in configuration and flexibility with large feature set. QoS, statefull failover, and a large feature set for logging and authetication make this a firewall of choice for some users of this site.

FAQs and Docs

Configuration help

Logging and Monitoring


iptables example rulesets and utility programs

(Mirrored from Daniel De Graaf's web site with permission. http://daniel.6dns.org/info/iptables/)

Programs

Ruleset manipulation

  • confread, which allows you to make a more english-like configuration file (example)
  • view, which displays a summary of the iptables rules from an iptables-restore file, or if run as root with no arguments, the current table
  • mkscript, which converts these rulesets to shell scripts
  • patch, which takes two rulesets and outputs a script to move from one to the other (needs IPTables.pm)

Ruleset debugging

  • trace - allows you to see what actions are taken on a packet as it goes through iptables. Use -v to see each rule that is checked. This script uses IPTables.pm. There is no relation between this and the TRACE target
  • TRACE target - add this to the raw table (like iptables -t raw -A PREROUTING -j TRACE) and the packets will be traced in the system log. This target requires that you patch your kernel and iptables binaries with patch-o-matic and recompile them. See the README for a quick howto
  • nfsim - full kernel-level simulation of netfilter code. More useful for debugging the kernel modules, but you can debug or test a ruleset with it

Log analysis

  • adcfw-log - firewall log analyzer/summarizer with several types of reports
  • IptablesWeb - Inspect iptables logs using a web browser, PHP, and MySQL
  • fire-log, which either displays a summary of firewall logs or runs a continuous summary. Config file

Administration tools

  • ulogd - if you are using the LOG target for more than just debugging, ULOG is better for several reasons: it doesn't fill up dmesg, logs to a separate file or even database, and can log in tcpdump format
  • conntrack - Kernel 2.6.14 and later lets you manipulate the conntrack table from userspace. This program can list, add, remove, or clear entries from the conntrack table
  • ctview - a perl ncurses-based frontend to the conntrack tool above. Entries with an endpoint on the local system are resolved to the owning pid, uid, and command. You can also delete any entry by using 'd' when it is selected

Frontends

If you don't want to learn iptables, you can use one of several frontends to it. I haven't personally used any of them, but other people like them. There are many more on google; there are just the ones I have looked at.

  • KIptablesGenerator - a graphical frontend to iptables that generates a script and lets you configure allowed ports and NAT
  • ipkungfu - generates an iptables ruleset from a set of config files in /etc/ipkungfu/. Allows both simple and complex configuration including NAT and logging, or custom rules if needed

Example rulesets

Simpler rulesets are at the start, with more complex scripts near the end. All rulesets are in iptables-save format and I discuss their use below.

Empty Script

  • empty - this resets the firewall to an accept-all policy. Ignore any "unable to initialize table" rules

Single host

  • minimal - no open ports, logging, or anything else. Good starting place
  • ssh for single host - allow SSH connections from a single IP address (1.8.9.7)
  • simple - two open services, DNS and WWW
  • simple+log - same, but with logging to syslog
  • simple+ulog - log to ulog (need ulogd running; creates a separate firewall log)
  • server - basic server. Mail, dns, www, ssh access from local network (10.0.0.0/8) and another host
  • outbound filtering by UID. This is usually not needed, but can provide an extra barrier to certain attacks (for example, an exploit on the http server would not be able to create a spambot or connect to a controlling host)

Normal router

  • MAC filtering - bind a specific MAC to an IP. This can be spoofed, but it requires finding an unused mac-ip pair and taking them. Eth1 is local network, eth0 is the internet link, all requests come from a single MAC.

NAT Router

  • NAT router - simple NAT router, no open or forwarded ports; eth1 is local network, eth0 is dynamic IP
  • Port forward - NAT router with port 80 forwarded to 10.0.0.2 and port 25 open on the router; with logs
  • DMZ router - NAT router with a DMZ of 10.0.0.* and clients on 10.0.1.*; one mail&ssh server and one ftp&web server.
  • complex - NAT, server, port-knocking, portscan-blocking, logging, bad-source-block, ipv6, ... this was generated from this configuration file by confread, and commented to be more readable.

Bridge Router

  • bridge router - simple bridge, network connected to eth1 is allowed to make outgoing connections but incoming connections are blocked
  • my bridge - filtering bridge allowing card0 and card1 full access, but doing a bit of protection against inbound. Newer version of the complex ruleset above, with the source

Abnormal setups

  • Passwordless VNC server - You can run a VNC server on port 5900, with no password, and it is only accessible by someone logged in as you. This is useful if you tunnel it through SSH (which this example also opens) - you've already logged in once
  • Multi-subnet virtual host NAT - Each server has its own /24 which is actually empty, but which the server thinks contains all the other services it needs to contact. External connections retain their source, of course. This was created for a contest that requires you to eventually drop the firewall, but not the NAT

Use of the recent module

  • port knocking - to connect to SSH, first connect to port 12345, then connect to ssh within 5 minutes (300 seconds) of your first connection
  • multiport knocking - to connect to SSH, connect to port 10001,20002,30003,40004,50005 then connect to ssh
  • CGI knocking - Instead of connecting to random ports, just visit a webpage. This ruleset could be protected with a password on the webserver for extra security. It could be combined with either of the previous two rulesets
  • portscan blocking - gives an hour's block to any IP that tries to connect to an unused port 4 times (in this example, all ports are unused). The service on tcp port 12345 cannot be revealed by nmap unless you know the number beforehand (or are excessively patient)
  • brute-force prevention - prevents more than two SSH connections per minute to slow down SSH scans. Can be used in combination with port knocking to prevent a DoS attack - just put the port knocking first.
  • ident opening - Opens the ident port to any host you connect on port 25 (SMTP) or 6667 (IRC) so that ident checks succeed while not giving everyone access to the ident port. Closes the port after 60 seconds
  • manual conntrack - If you are getting SYN flooded at 100-500Mbit, the linux state modules panics. This is an alternate state-tracking ruleset written using -m recent which doesn't crash the kernel. Of course, the normal state tracking is better and this code should only be used when actually under an attack

HowTo

Tutorials

  • Iptables Tutorial by Oskar Andreasson (mirror) is a very nice starting place for iptables, but may be a bit long
  • netfilter.org howtos - Some of the external links on that page are outdated, but overall it is a good collection of information

Diagrams

Rulesets

These rulesets are in iptables-save format. I have written some simple documentation of the iptables-save format. I use this format for several reasons: it ensures there are no other rules in iptables, it loads faster, it avoids the possibility of a race condition that most iptables scripts have (although the race window would be about 1ms for most rulesets).

There are several ways to use these rulesets.

  • Use the scripts as an init script without any modifications
  • Use mkscript to convert the iptables-save file into a shell script and add the script to your init scripts
  • Save the ruleset as-is to /etc/iptables.conf and use this init script
  • Add pre-up iptables-restore < /etc/iptables.conf to the internet-facing interface in /etc/network/interfaces (Debian-based Distributions only)

For the best security, a firewall should be applied before the internet-facing interface is brought up. If you have a dynamic IP and need to use it in your ruleset, consider loading a simple deny-all firewall (remember to allow DHCP) before bringing up the interface, then switching to the real firewall after the you get an IP.

Related scripts

  • sysctl settings that may be useful if you are running a firewall.

References

  • The iptables 1.3.4 manpage, which has a full syntax description and covers all the modules.
  • Netfilter, the official iptables/netfilter website.