上QQ阅读APP看书，第一时间看更新

Blocking everything that isn't allowed with iptables

To start blocking stuff that we don't want, we have to do one of two things. We can set a default DROP or REJECT policy for the INPUT chain, or we can leave the policy set to ACCEPT and create a DROP or REJECT rule at the end of the INPUT chain. Which one you choose is really a matter of preference. (Of course, before you choose one over the other, you might want to check your organization's policy manual to see if your employer has a preference.)

The difference between DROP and REJECT is that DROP blocks packets without sending any message back to the sender. REJECT blocks packets, and then sends a message back to the sender about why the packets were blocked. For our present purposes, let's say that we just want to DROP packets that we don't want to get through.

There are times when DROP is better, and times when REJECT is better. Use DROP if it's important to make your host invisible. (Although, even that isn't that effective, because there are other ways to discover hosts.) If you need your hosts to inform other hosts about why they can't make a connection, then use REJECT. The big advantage of REJECT is that it will let connecting hosts know that their packets are being blocked so that they will know to immediately quit trying to make a connection. With DROP, the host that's trying to make the connection will just keep trying to make the connection until it times out.

To create a DROP rule at the end of the INPUT chain, use the following code:

donnie@ubuntu:~$ sudo iptables -A INPUT -j DROP
donnie@ubuntu:~$

To set a default DROP policy instead, we can use the following code:

donnie@ubuntu:~$ sudo iptables -P INPUT DROP
donnie@ubuntu:~$

The big advantage of setting up a default DROP or REJECT policy is that it makes it easier to add new ACCEPT rules if need be. This is because if we decide to keep the default ACCEPT policy and create a DROP or REJECT rule instead, that rule has to be at the bottom of the list.

Since iptables rules are processed in order, from top to bottom, any ACCEPT rules that come after that DROP or REJECT rule would have no effect. You would need to insert any new ACCEPT rules above that final DROP or REJECT rule, which is just a tiny bit less convenient than just being able to append them to the end of the list. For now, in order to illustrate my next point, I've just left the default ACCEPT policy and added the DROP rule.

When we look at our new ruleset, we'll see something that's rather strange:

donnie@ubuntu:~$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
. . .
. . .
ACCEPT     icmp --  anywhere             anywhere             ctstate NEW,RELATED,ESTABLISHED icmp parameter-problem
DROP       all  --  anywhere             anywhere            

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
. . .
. . .

The first rule and the last rule of the INPUT chain look the same, except that one is a DROP and the other is an ACCEPT. Let's look at it again with the -v (verbose) option:

donnie@ubuntu:~$ sudo iptables -L -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target prot opt in out source destination 
   67 4828 ACCEPT all -- lo any anywhere anywhere 
  828 52354 ACCEPT all -- any any anywhere anywhere ctstate RELATED,ESTABLISHED
. . .
. . .
    0 0 ACCEPT icmp -- any any anywhere anywhere ctstate NEW,RELATED,ESTABLISHED icmp parameter-problem
  251 40768 DROP all -- any any anywhere anywhere 

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target prot opt in out source destination 
. . .
. . .

Now, we can see that lo, for loopback, shows up under the in column of the first rule, and that any shows up under the in column of the last rule. We can also see that the -v switch shows the number of packets and bytes that have been counted by each rule. So, in the preceding example, we can see that the ctstate RELATED,ESTABLISHED rule has accepted 828 packets and 52,354 bytes. The DROP all rule has blocked 251 packets and 40,763 bytes.

This all looks great, except that if we were to reboot the machine right now, the rules would disappear. The final thing that we need to do is make them permanent. There are several ways to do this, but the simplest way to do this on an Ubuntu machine is to install the iptables-persistent package:

sudo apt install iptables-persistent

During the installation process, you'll be presented with two screens that ask you whether you want to save the current set of iptables rules. The first screen will be for IPv4 rules, while the second will be for IPv6 rules:

You'll now see two new rules files in the /etc/iptables directory:

 donnie@ubuntu:~$ ls -l /etc/iptables*
 total 8
 -rw-r--r-- 1 root root 336 Oct 10 10:29 rules.v4
 -rw-r--r-- 1 root root 183 Oct 10 10:29 rules.v6
 donnie@ubuntu:~$

If you were to reboot the machine now, you'd see that your iptables rules are still there and in effect. The only slight problem with iptables-persistent is that it won't save any subsequent changes that you make to the rules. That's okay, though. I'll show you how to deal with that in just a bit.