Episode #30: Twiddling with the Firewall

Ed kicks it off:

One of the real gems of the Windows command line is netsh. I use it all the time. In Episode #2, about a thousand years ago (gosh... can it be only 2 months?), we talked about using netsh (yeah, and iptables) to display firewall config information. But, you know, there are some commands I run even more often that alter the firewall.

In particular, if I'm in my lab doing an analysis that requires me to shut off the built-in Windows firewall, or when I'm conducting a pen test and want to hack naked without a firewall, I drop the firewall with:

C:\> netsh firewall set opmode disable

That's soooo much easier than digging through the blasted GUI to find where Microsoft buried the firewall configuration in the given version of Windows.

Simple command, but I use it all the time.

To turn it back on, you'd run:

C:\> netsh firewall set opmode enable

If you want to poke holes through the firewall based on port, you could run:

C:\> netsh firewall add portopening protocol = [TCP|UDP] port = [portnum] name = [NameOfRule]
    mode = enable scope = custom addresses = [allowedIPaddr]

This syntax would configure the firewall to allow traffic in for the port you specify only if it comes from allowedIPaddr, to make your rule a little safer.

And, to remove the rule, just change "add" to "del", and only type in the command up to the port number.

Finally, as we mentioned in Episode #2, to show the overall config of the firewall, you can run:

C:\> netsh firewall show config

Hal chimes in:

Firewall software is another one of those areas where there are a number of competing options on different Unix/Linux platforms. For example you've got ipfilter on Solaris and {Free,Net}BSD, pf on OpenBSD, and IP Tables on Linux. I'm going to stick with IP Tables for purposes of this discussion, since it's probably what most of you all deal with the most.

Unfortunately, IP Tables is rather cranky to work with from the command line if you stick with the basic "iptables" command. The developers tried to smash all of the possible functionality configuration options into a single command, and IP Tables is capable of some complicated stuff. The result, however, is that there's a pretty steep learning curve for doing even basic operations. This is why simplified firewall configuration GUIs are provided by the major Linux distributions.

But let's try and cover some of the same command-line territory that Ed does in his Windows examples. First, as far as starting and stopping the firewall goes, your best bet is to just run "/etc/init.d/iptables [start|stop]" as root. The init script hides a lot of complexity around loading and unloading kernel modules, firewall rules, and default packet handling policies. For example, here are the manual command equivalents for "/etc/init.d/iptables stop":

# iptables -P INPUT ACCEPT
# iptables -P OUTPUT ACCEPT
# iptables -P FORWARD ACCEPT
# iptables -F

Yep, four commands-- and that's without even showing you the commands that some init scripts use to unload the IP Tables kernel modules. The first three commands above set the default permit ("ACCEPT") policy ("-P") for inbound ("INPUT") and outbound ("OUTPUT") packets, as well as for packets being passed through the system ("FORWARD"). It's possible that your particular firewall configuration doesn't change the default policies to block packets ("DROP"), but it's best to be sure. The final "iptables -F" command flushes all filtering rules, which means all packets will now simply be handled by the default "ACCEPT" policies.

The simplest possible example of adding a rule to allowing traffic into your system on a particular port would be something like:

# iptables -A INPUT -p tcp --dport 80 -j ACCEPT

This allows ("-j ACCEPT") inbound traffic ("-A INPUT") on 80/tcp ("-p tcp --dport 80"). Deleting the rule is as simple as running the same command but with a "-D INPUT" option (delete from the "INPUT" chain) instead of "-A INPUT" (add to the "INPUT" chain).

However, depending on how your particular Linux vendor sets up their firewall, adding rules directly to the "INPUT" chain may not be the right thing to do. Many vendors set up their own rule chains that pre-empt the default chains. Also, you may have to add rules to the "OUTPUT" chain (or vendor-specific equivalent) to allow the return packets to escape your host, unless you have a "default permit" configuration in the outgoing direction. For these reasons, it's best to inspect your current rule sets ("iptables -L -v") before making changes.

I should mention that a simplified command-line interface is now becoming available in some Linux distributions, notably Ubuntu. If all you're interested in is a host-based firewall, the "ufw" command makes configuration and maintenance much easier. Here are some sample "ufw" commands:

# ufw enable                # enable filtering
# ufw disable               # turn off firewall
# ufw status                # show current rules
# ufw allow 80/tcp          # allow 80/tcp to any IP on this host
# ufw delete allow 80/tcp   # delete above rule

You can also do more complex rules like:

# ufw allow proto tcp from 1.2.3.4 to any port 25

If you're more used to Cisco extended ACL syntax, or use ipfilter on other Unix systems, the "ufw" command-line syntax will be pretty natural for you.