Hack 37 Keep Your Network Self-Contained

Use egress filtering to mitigate attacks and information leaks coming from your network .

You're probably familiar with the concept of firewalling as it applies to blocking traffic coming into your network. Have you considered the benefits of filtering traffic that leaves your network? For instance, what would happen if someone compromised a host on your network and used it as a platform to attack other networks? What if a worm somehow made it onto your network and tried to infect hosts across the Internet? At the very least, you would probably receive some angry phone calls and emails. Luckily, filtering your outbound traffic— otherwise known as egress filtering —can help to contain such malicious behavior. Egress filtering can not only protect others from attacks originating from your network, but can also be used to enforce network usage policies and make sure information doesn't leak out of your network onto the wider Internet. In many situations, egress filtering is just as important as filtering inbound traffic.

The general guideline when crafting egress-filtering rules is the same as when constructing any inbound-filtering rule—devices should only be allowed to do what they were meant to do. That is, a mail server should only be allowed to serve and relay mail, a web server should only be allowed to serve web content, a DNS server should only service DNS requests , and so on. By ensuring that this policy is implemented, you can better contain the threats mentioned earlier.

It may also be a good idea to force users to use internal services rather than Internet services wherever possible. For example, if you are using your own DNS servers, clients shouldn't be able to connect to external DNS servers to resolve hostnames. If a client is allowed to do this, you risk the chance that they will reveal intranet hostnames to outside parties when the client attempts to resolve an internal hostname through an external DNS server.

For instance, this restriction can be accomplished in OpenBSD with a rule like this:

rdr on $


INT_IF


inet proto { tcp, udp } from $


INT_IF


:network to any port 53 

-> $


DNS_SERVER


port 53

Of course, you'll need to set INT_IF to the interface facing your internal network and set DNS_SERVER to the IP address of your internal DNS server.

Similarly, if you're running an internal mail server, then company email need never cross the Internet. If you have gone to the trouble of setting up an internal email server, do you really want your employees to be able to connect to servers outside your network?

You can do this with a similar rule:

rdr on $


INT_IF


inet proto tcp from $


INT_IF


:network to any port 25 -> $


SMTP_HOST


port 25

Egress filtering can also prevent IP spoofing. By filtering on your external interface at the border of your network, you can verify that packets leaving your network have source addresses that match your address space. By filtering all other traffic, you can ensure that any IP spoofing attack performed from your network or routed through it will be dropped before the packets are able to leave.

Hack 38 Test Your Firewall

Find out if your firewall really works the way you think it should .

So you've set up a firewall and done a few cursory tests to make sure it's working, but have you tested the firewall to be sure that it's blocking everything that it's supposed to? You may not have done this because you think it will take too long or be too difficult. Luckily there's ftester (http://ftester. sourceforge .net), a free tool for doing extensive firewall tests.

Ftester consists of three Perl scripts. The ftest script is used for injecting custom packets as defined in the configuration file ftest.conf . If you are testing how the firewall behaves with ingress traffic, you should run this script on a machine outside of your firewalled network. If you want to test your firewall's behavior toward egress traffic, you will need to run ftest from a machine within your firewall's protected network. One of the other scripts is ftestd , which listens for the packets injected with ftest that come through the firewall that you are testing. This script should be run on a machine within your internal network if you are testing the firewall's ingress behavior. If you are testing egress behavior, you'll need to run it on a machine external to your network. Both of these scripts keep a log of what they send or receive. After a test run, their respective logs can be compared using the freport script, to quickly see what packets were able to get through the firewall.

Before you can use Ftester , you will need the Net::RawIP , Net::PcapUtils , and NetPacket Perl modules. You will also need the Net::Pcap module if it is not already installed, since the Net::PcapUtils module depends on it. If you have the CPAN Perl module available, you can install these modules with the following commands:

#

perl -MCPAN -e "install Net::RawIP"

#

perl -MCPAN -e "install Net::PcapUtils"

#

perl -MCPAN -e "install NetPacket"

Once these modules are available on the systems you will be using to conduct your firewall test, you will need to create a configuration file to tell ftest what packets it should generate.

The general form for a TCP or UDP packet in ftest.conf is:



source addr


:


source port


:


dest addr


:


dest port


:


flags


:


proto


:


tos

where source addr and source port are the source IP address and port, and dest addr and dest port are the destination IP address and port. Address ranges can be specified in the low - high format or by using CIDR notation. Port ranges can be specified using the low - high format as well. The flags field is where you specify the TCP that you want set for the packet. Valid values for this field are S for SYN, A for ACK, P for PSH, U for URG, R for RST, and F for FIN. The proto field specifies which protocol to use (either TCP or UDP ), and tos contains the number to set the Type-of-Service (ToS) field in the IP header to. Sometimes routers will use the contents of this field to make decisions about traffic prioritization. You can get more information on the ToS field by reading RFC 791 (http://www.ietf.org/rfc/rfc0791.txt), which defines Internet Protocol.

ICMP packets can be defined in a similar manner. Here's the general form for one:



source addr


::


dest addr


:::ICMP:


type


:


code

Here you can see that the main difference between the two forms is the omission of port numbers and flags. This is because ICMP does not use port numbers and does not make use of flags. Instead, it uses types and codes, hence the addition of the type and code fields. Currently, there are over 40 ICMP types. Some that may be familiar to you are the ones used by the ping utility, echo (type 8) and echo reply (type 0), or the type used by the traceroute command (type 30). ICMP codes are like subclassifications of an ICMP type. Not all ICMP types have ICMP codes associated with them, although there are roughly the same number of ICMP codes as there are types. You can find out more about ICMP types and codes by reading the IANA's assignments for them (see http://www.iana.org/assignments/icmp-parameters).

Here's an ftest.conf that will check all of the unprivileged TCP ports on a machine with the IP address 10.1.1.1:

192.168.1.10:1025:10.1.1.1:1-1025:S:TCP:0

stop_signal=192.168.1.10:1025:10.1.1.1:22:S:TCP:0

The stop_signal creates a payload for the packet that will tell ftestd that the testing is over.

Before starting ftest , you should start ftestd :

#

./ftestd -i eth0

Now, to run ftest :

#

./ftest -f ftest.conf

This will create a log file called ftest.log containing an entry for every packet ftest sent. When ftestd receives the signal to stop, it will exit. You can then find its log of what packets it received in ftestd.log . Now you can copy the logs to the same machine and run them through freport . If you used a configuration file like the one shown earlier and were allowing SSH, SMPTP, and HTTP traffic, you might get a report similar to this:

#

./freport ftest.log ftestd.log

Authorized packets:

-------------------



22 - 192.168.1.10:1025 > 10.1.1.1:22 S TCP 0

25 - 192.168.1.10:1025 > 10.1.1.1:25 S TCP 0

80 - 192.168.1.10:1025 > 10.1.1.1:80 S TCP 0



Modified packets (probably NAT):

--------------------------------



Filtered or dropped packets:

----------------------------



1 - 192.168.1.10:1025 > 10.1.1.1:1 S TCP 0

2 - 192.168.1.10:1025 > 10.1.1.1:2 S TCP 0

3 - 192.168.1.10:1025 > 10.1.1.1:3 S TCP 0

If you are using a stateful firewall and want to test this functionality, you can also specify packets that have flags other than SYN set. For instance, if the previous example had used ACK or some other flag instead of SYN, it would be dropped by the firewall since only packets with the SYN flag set are used to initiate connections.

It's a good idea to run ftest each time you make changes to your firewall, or periodically just to make sure that your firewall works as you expect it to. While complex rulesets on your firewall can sometimes make it difficult to predict exactly how it will behave, ftest will tell you with good authority exactly what kind of traffic is permitted.

Flylib.com

Category list

Similar pages

Hack 37 Keep Your Network Self-Contained

Hack 37 Keep Your Network Self-Contained

Hack 38 Test Your Firewall

Similar products

Similar products