As a part of my research, I need to determine the maximum packets (Internet traffic) can one instance of firewall/ IDS process. I am not sure where to begin though.

Your assistance and guidance in this regard is much appreciated.

  • Did you try launching a ping flood? – Limit Jan 3 '17 at 22:56
  • I have been suggested to do so, but I'd prefer to rely on collecting real datasets instead of making up one. – Nadir Jan 9 '17 at 0:03

Having done tests for multiple clients where they claim "scans won't knock this over, you'll be alright", then an hour later we're having a meeting discussing how they're going to handle a serious downtime incident, I can safely say a few things:

  1. The marketing figures describing performance are at best a peak performance case, produced in a lab situation where the test case has been fully optimised for maximum performance stats with no regard for actual usability or functionality. At worst they're a complete fabrication or misrepresentation of the data. You should ignore any such performance statistics.
  2. Standard flood tests (e.g. ICMP flood, SYN flood) are rudimentary tools at best. Resistance to ICMP flooding is rarely a useful measure of anything since people learned their lessons in the 90s. SYN flooding will tell you whether the system is capable of de-prioritising waiting half-open connections behind clients who have actually sent a final ACK to complete the connection, along with implementing a basic anti-flooding system like TCP SYN cookies. These are rudimentary things that you can expect from any networking product.
  3. Bandwidth flood tests can be useful in working out network saturation issues, but they only really tell you what the network pipe's continuous bandwidth limit is. By flooding a network link with large packets (usually UDP datagrams) you can saturate the pipe and make it hard for new legitimate packets to come through. That said, that usually tells you more about the network itself than the device under test (the firewall or IDS).
  4. IPS/IDS/Firewall systems have ludicrously fast throughput rate for traffic, but the real bottlenecks occur on the management side. For example, if you log every time a packet is seen from an IP address which does not have an ARP entry (I have seen this done) then sending lots of packets from a spoofed IP (or just without ARP'ing first) will very quickly fill the log buffer in memory and saturate the disk IO on the drive which stores the logs, usually knocking the whole system over. The device may be capable of passing legitimate traffic forward at a ridiculously high rate, but a single edge case like this can flatten it in minutes.
  5. You can perform all the DoS / DDoS test suites you like, verify your results in production, open it up to real world traffic and see great results, then find that it falls flat on its face as soon as a pentester (or some skript kiddie) runs Nessus or sqlmap through it, because so many alerts are being thrown that the alerting system can't keep up.
  6. If you test a device in a test environment, then move it to production, don't be surprised when your device no longer performs as expected. Tests have to be done in the real-world setup with the exact same config and same topology. Something subtly different can completely throw off your results.

If you want to properly test the realistic capabilities one of these devices, you need to install it in your production environment and run a full battery of tests through it, in your final production configuration. The results will be different for each model or version of the firewall/IDS/IPS, different config options, and different networking topologies and backend systems being reached through the device. Whatever answer you gain for, say, a pfSense firewall, will be entirely different than, say, a Checkpoint firewall.

|improve this answer|||||

Since you're talking about research, the first thing you should do is define what you mean by firewall and IDS. They are different things; at a trivial level, a (stateful) firewall is concerned with the network layer, while an IDS must do at least some packet inspection and application-level analysis to be useful.

While there are other kinds of firewalls and IDS, what limits their throughput is ultimately the slowest element in the processing chain. Here is a trival example:

  1. The packet hits the network card
  2. At the kernel level, the network stack works on the frame (e.g. defragments it)
  3. The firewall (say, iptables) matches the rebuilt packet against its ruleset
  4. The logging system writes an event to /dev/log and then forgets about it
  5. The IDS looks into the packet, and waits for more packets to arrive to complete the inspection

In this case the components involved are:

  • network card (PCI bus)
  • CPU and RAM

The slowest element of the chain is the PCI bus, so that's the limiting factor in case of single packets. This means that unless you put a 10Gb card on a 486 CPU with a clock of 100 MHz, the network card will always be the bottleneck. It's a back-of-the-envelope calculation but it gives you a lower boundary.

Once you have a baseline you can start complicating it: for example, what if the system is overloaded? What's the minimum number of threads your CPU must be able to allocate in order to keep up with a maximum throughput? In other words: isolate your variables and, keeping everything else the same, analyse their boundaries. You might consider a boundary analysis approach.

You also need to clarify your research question: you talk about

the maximum packets (Internet traffic) can one instance of firewall/ IDS process

What do you mean by "process"? Is your IDS active or passive (e.g. does it block packet flow until it's happy, or does it do passive analysis only)? If it's blocking, you have a producer/consumer queue model where your upper bound depends on whether the IDS can scale over multiple cores. Other things you may want to consider are memory footprint, susceptibility to denial-of-service attacks, and so on. Think about what happens if an attacker sends one fragmented packet. Will the firewall wait forever to assemble it? What if the attacker sends only the first chunk of a chunked HTTP request?

To sum up - start by defining exactly what you're trying to assess; for each element, determine its lower and (possibly) upper bounds; combine the results.

|improve this answer|||||

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