Monitoring your network, and doing it right

So, at my employer, deCarta, we recently moved from using a Cisco ASA5510 to using Vyatta firewalls. At some point later, I’ll review Vyatta. We did the migration on July 4th, so everything was in a nasty flux. Anyways, because of various reasons, the firewalls implementation was rushed, and that left certain security holes. In most networks, you verify that packets can traverse a particular part of the network. Though, we don’t test our security equipment enough. We often fail to verify that packets are not traversing the network. To look to our programmer brethren, many people are adopting test based development, where you build several unit tests around a particular function, and certain ones are supposed to fail (gracefully), and others are supposed to succeed. The point of checking for graceful failure is to make sure that the application isn’t accepting bad input.

Networks are far more fragile to human error than programs. Programming languages have certain barriers which prevents programmers from making mistakes. On the other hand, most network equipment is made to make ease of use a top priority. This allows someone to accidentally switch around the order of words, or leave out a stanza, opening up a network to attack. We need to verify that our security rules are working, and dropping the proper packets.

There are a few obstacles to this kind of testing. Doing specific SYNs/ACKs between different networks is difficult unless you have some sort of probe sitting in the center of the network, that can touch all portions of it. There are a variety of ways to approach this, which again, I wont cover here. Next, is the more complex part, coming up with the ways to test the rules. You can’t test every possible situation under which the rule should activate, and drop a packet. For example, if you have a rule which says that no system in 192.168.123.0/24 can contact hosts in 10.88.88.0/24, we obviously can’t test every possible combination of this, because that’d be 255^2. Instead, you come up with several different cases under the rules might fail. Firstly, a base case (a very typical one), make sure that 192.168.123.102 cannot send an ICMP request to 10.88.88.101. Next, you come up with a list of typically used numbers, like .100, .254, .1, or any other management hosts you have in your networks. Lastly, think of exceptions to the rule. For example, let’s say 192.168.123.22 is allowed to contact 10.88.88.55. Add these to the probe lists on either side. Now, on either side you have several hosts which you can test between, and that will give you a fairly good idea if your network filtering is active.

192.168.123.0/24 hosts:

  • 192.168.123.55
  • 192.168.123.1
  • 192.168.123.102
  • 192.168.123.254

10.88.88.0/24 hosts:

  • 10.88.88.22
  • 10.88.88.1
  • 10.88.88.102
  • 10.88.88.254

From this you can derive 15 test which should fail to pass packets, and will cover most typical human error. Remember, human error is never typical, so take these as examples, and remember you can never have too many tests to fail.

Anyways, all in all, just remember to make sure that your network is dropping as many packets as it can, and it only takes one packet to compromise your network😉.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: