Most *nix boxes have iptables pre-installed. For example, an Ubuntu Linux Server (headless) 16.04.2 LTS will have iptables installed.
Find out what rules exist on the host to which you have console and root/sudo access:
$ sudo iptables -L -v
Iptables won’t do much w/o the sudo command, or switch to root if you like before digging in. The -L will list all rules in all chains (more on that later). The -v adds verbosity to the output. Here’s an example of what that output can look like:
trfflhntr@ubuntu:~$ sudo iptables -L -v
[sudo] password for trfflhntr:
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- lo any anywhere anywhere
987 85229 ACCEPT all -- any any anywhere anywhere ctstate RELATED,ESTABLISHED
9 576 ACCEPT tcp -- any any anywhere anywhere tcp dpt:ssh
399 100K DROP all -- any any anywhere anywhere
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 596 packets, 77529 bytes)
pkts bytes target prot opt in out source destination
Looking at the above output as a guide, we can see that the INPUT chain has a default policy of ACCEPT, four rules, and – thx to the last rule – packets that do not match rules 1-3 will be dropped into the nothingness.
Let’s talk about this further.
Chains: INPUT is traffic destined for the host (e.g. this is the “host-based firewall” ruleset), FORWARD is used when the host is in the path of traffic (e.g. as an actual firewall, with hosts behind it, perhaps NAT is being used – perhaps not), and OUTPUT is traffic originating from the host destined for anything other than interface lo (i.e. 127.0.0.1).
Rule 1, above, is allowing any protocol, port, any src/dst to the lo interface (designated “in”, as in “inbound”).
Rule 2 is a failsafe rule, ensuring that some moroon (hi guys!) doesn’t try to get all fancy with, say, locking down SSH and forgetting to allow their own host and then locking themselves out of the remote host. The rule essentially says, “if your connect state is already ESTABLISHED or RELATED, rock on man”.
Rule 3 is a basic “go ahead and ssh into this box, using tcp and port 22 – I don’t really care what your IP address is or what interface you’re trying to hit, if you wanna try to auth via ssh, I’ll let you bang away”.
Rule 4 drops anything else.
There are two more things that any aspiring iptables muckracker should know. First, how to save/restore rules – and that rules exist in memory and are not, by default, sticky – they won’t persist a reboot. Second, how to see the command(s) that were used to created the rule(s) that exist on the box at this time.
Saving and Restoring a ruleset:
$ sudo iptables-save > /path/to/where/you/want/to/save/filename $ sudo iptables-restore /path/to/that/filename
Viewing the commands that were used to create the existing rules:
$ sudo iptables -S
trfflhntr 