I am configuring a Linux router with iptables. I want to write acceptance tests for the configuration that assert things like:

  • traffic from some guy on the internet is not forwarded, and
  • TCP to port 80 on the webserver in the DMZ from hosts on the corporate LAN is forwarded.

An ancient FAQ alludes to a iptables -C option which allows one to ask something like, "given a packet from X, to Y, on port Z, would it be accepted or dropped?" Although the FAQ suggests it works like this, for iptables (but maybe not ipchains as it uses in the examples) the -C option seems to not simulate a test packet running through all the rules, but rather checks for the existence for an exactly matching rule. This has little value as a test. I want to assert that the rules have the desired effect, not just that they exist.

I've considered creating yet more test VMs and a virtual network, then probing with tools like nmap for effects. However, I'm avoiding this solution due to the complexity of creating all those additional virtual machines, which is really quite a heavy way to generate some test traffic. It would also be nice to have an automated testing methodology which can also work on a real server in production.

How else might I solve this problem? Is there some mechanism I might use to generate or simulate arbitrary traffic, then know if it was (or would be) dropped or accepted by iptables?

  • This one might be interesting too: security.stackexchange.com/questions/31957/… – dawud May 30 '14 at 15:30
  • 1
    @dawud I don't think either of those are duplicates. I know how to run a port scan: that's not a good test because I'm limited to testing to and from destinations and sources that I can control. My concern is also not locking myself out of the server. I want to automatically test that the firewall rules actually have the effects I designed them to have. – Phil Frost May 30 '14 at 15:37

If you are prepared to do a bit of coding, you could try this:

  • Create a new network namespace by using the CLONE_NEWNET flag for the clone system call, or by using ip netns add and ip netns exec commands.
  • In this namespace crate a set of virtual network interfaces using the tun driver or ip link add.
  • Load the configuration using iptables-restore
  • Feed a number of packets to the rules through the tun or veth devices
  • Observe that you get the correct packets out of the tun or veth devices

This approach is likely going to work best for testing rules for forwarded packets. Connections to/from the machine where iptables is used requires a bit more effort, but should be feasible to test this way as well.

Here is an example of a sequence of commands, that could be used:

ip netns add test-iptables
ip netns add test-iptables-some-guy-on-the-internet
ip netns add test-iptables-lan-host

ip netns exec test-iptables ip link add eth0 type veth peer name eth0-peer
ip netns exec test-iptables ip link set eth0-peer netns test-iptables-some-guy-on-the-internet
ip netns exec test-iptables ip link add eth1 type veth peer name eth1-peer
ip netns exec test-iptables ip link set eth1-peer netns test-iptables-lan-host

ip netns exec test-iptables ifconfig eth0 netmask
ip netns exec test-iptables ifconfig eth1 netmask

ip netns exec test-iptables-some-guy-on-the-internet ifconfig eth0-peer netmask
ip netns exec test-iptables-some-guy-on-the-internet route add default gateway

ip netns exec test-iptables-lan-host ifconfig eth1-peer netmask
ip netns exec test-iptables-lan-host route add default gateway

ip netns exec test-iptables-some-guy-on-the-internet telnet
ip netns exec test-iptables iptables-restore < /tmp/iptables-test
ip netns exec test-iptables-some-guy-on-the-internet telnet

ip netns del test-iptables
ip netns del test-iptables-some-guy-on-the-internet
ip netns del test-iptables-lan-host

This would create three network namespaces for testing and load a set of iptables rules in one of them. The other two serve as the role of some guy on the internet and a host on the LAN.

In the above example the first telnet command get connection refused from the test-iptables-lan-host namespace, the second telnet command get a timeout if the ruleset drops the packet.

This doesn't touch the initial network namespace, which is the one all your production will be happening in by default. The only way to get more separation from your production is to run it on a separate host (physical or virtual).


the professional world do that with the help of hardware/software provided by 2 companies.



In the first case you can use something like an Ixia 400T chassis + Ixload.

In the second case the line Smartbits or Testcenter with their corresponding applications

These devices can (among other things) emulate lot of clients performing different kind of requests on your selected target server. They come ready to test your servers security including a pre-defined set of attack tests plus you can always define your own set. They also have many other capabilities like load stress tests and the like.

Not a cheap option.

  • it is amazing to see how plain ignorance can quietly downgrade valid answers... – Pat Jun 1 '14 at 22:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.