6.2.1 Protocols Are Usually Bidirectional

Protocols are usually bidirectional; they almost always involve one side sending an inquiry or a command, and the other side sending a response of some kind. When you're planning your packet filtering rules, you need to remember that packets go both ways. For example, it doesn't do any good to allow outbound Telnet packets that carry your keystrokes to a remote host, if you don't also allow the incoming packets for that connection that carry the screen display back to you.

Conversely, it also won't do you any good to block only half a connection. Many attacks can be carried out if attackers can get packets into your network, even if the attackers can't get any responses back. This is possible because the responses may be predictable enough to allow attackers to carry on their side of the conversation without having to actually see the responses at all. If the responses are predictable, an attacker doesn't need to see them. They won't be able to extract any information directly if they don't see the responses, but they may be able to do something that gives them the data indirectly. For example, even if they can't see your /etc/passwd file directly, they can probably issue a command to mail themselves a copy.

6.2.2 Be Careful of `Inbound' Versus `Outbound' Semantics

When you're planning your packet filtering strategy, you need to be careful in your discussions of "inbound" versus "outbound." You need to carefully distinguish between inbound and outbound packets, and inbound and outbound services . An outbound service (e.g., the Telnet service mentioned above) involves both outbound packets (your keystrokes) and inbound packets (the responses to be displayed on your screen). Although most people habitually think in terms of services , you need to make sure you think in terms of packets when you're dealing with packet filtering. When you talk to others about filtering, be sure to communicate clearly whether you're talking about inbound versus outbound packets, or inbound versus outbound services.

6.2.3 Default Permit Versus Default Deny

In Chapter 3 , we distingushed between the two stances you can choose in putting together your security policy: the default deny stance (that which is not expressly permitted is prohibited) and the default permit stance (that which is not explicitly prohibited is permitted). From a security point of view, it is far safer to take the attitude that things should be denied by default. Your packet filtering rules should reflect this stance. As we discussed earlier, start from a position of denying everything and then set rules that allow only protocols that you need, that you understand the security implications of, and that you feel that you can provide safely enough (according to your own particular definition of "safely enough") for your purposes

The default deny stance is much safer and more effective than the default permit stance, which involves permitting everything by default and trying to block those things that you know are problems. The reality is that with such an approach, you'll never know about all the problems, and thus you'll never be able to do a complete job.

In practical terms, the default deny stance means that your filtering rules should be a small list of specific things that you allow, perhaps with a few very specific things you deny scattered throughout to make the logic come out right, followed by a default deny that covers everything else. We'll explain in detail how these rules work later in this chapter.