Three Reasons to Deploy a Standalone IDS Instead of a Firewall with IPS

//Three Reasons to Deploy a Standalone IDS Instead of a Firewall with IPS

Three Reasons to Deploy a Standalone IDS Instead of a Firewall with IPS

It seems like the current trend in networking equipment and datacenter design is to combine as many things as possible into as few physical devices as you can get away with. From virtualized servers running on a single massive hypervisor to integrated firewalls with intrusion detection and prevention capabilities there’s more and more functionality being added to existing devices all the time.

While that’s great for cost reduction it might not always be the best solution.

One trend I’m specifically seeing is the increasing inclusion of IPS or Intrusion Prevention System functionality into firewalls and border devices. While common firewalls will only block attacks and traffic based on the source and destination IP and port (layer 4 of the OSI model) an IPS goes further, inspecting the actual contents of the traffic and looking for attacks such as SQL injection attempts, botnet traffic, or brute force password cracking attempts among many other scenarios. Devices with this functionality include products like the Sophos UTM and FortiNet FortiGate devices.

What’s good and convenient about the integrated IPS device is that it can immediately block suspicious traffic that it detects. I’ve had good experiences with Palo Alto Networks’ implementation of this feature in their firewalls, but it also created some massive problems that I needed to solve.

As a result I’ve found that in some situations it might make more sense to leave these features turned off and go back to using a traditional standalone Intrusion Detection Sensor or IDS. An IDS will do just as well as an integrated IPS when it comes to detecting attacks, but it won’t proactively block the attack — that’s up to you and your incident response protocols.

Why would I want an IDS instead of an IPS? I’ve got three reasons.

Throughput

Firewalls have gotten very good at processing large quantities of traffic very quickly using their basic layer 4 rules, but as soon as you add the IPS features which analyze the traffic more closely and use advanced rules for detection of attacks the throughput of the device drops like a stone.

Take the Cisco ASA 5505 Security Plus firewall, for example. I’ve configured and maintained hundreds of these devices for customers around the world and know it well, it’s a great device and I love working with it. In normal operation the firewall can handle a maximum throughput of 150 Mbps which would be enough for any small office or datacenter deployment. Once the IPS features are enabled that throughput is cut in half — only capable of processing 75 Mbps.

The IPS functionality is also very sensitive to the number of packets and connections going through the device. Protocols that use small quickly dispatched packets such as SIP (VoIP) connections will overwhelm the devices more quickly and further reduce the actual maximum throughput of the firewall.

Speaking of VoIP, that’s one application where the IPS functionality in a firewall can make your business critical functions near useless. The increased processing time and decreased throughput of the IPS enabled firewall can significantly delay the packets as they come into and out of your network, leading not only to a delay in your phone calls but also jitter — a stuttering call quality that makes phone calls impossible for either party to understand what is being said.

Moving the intrusion detection functionality to a standalone device like an IDS removes these issues. Because the packets aren’t being inspected by a device “in line” with the connection there’s no delay and no reduction in throughput. Phone calls are clear and understandable and file transfers are quicker. All while still having the same visibility into any potential attacks that comes with an IDS or IPS device.

Not Getting Blamed when Things Go Wrong

IT security is a critical component of every modern business, but we often get more blame than praise. Let me give you an illustrative example.

While I was working for Rackspace Hosting as a Network Security Administrator one of the devices we provided our customers was a Web Application Firewall or WAF, a type of IPS device that was specifically designed to detect and stop web application based attacks like SQL injection and remote code uploads. It worked great, but sometimes it worked a little too great. The customer would sometimes update their web application to use a new feature that the WAF would mis-identify as an attack and block customers from actually using on the site. Usually we would have this fixed within minutes of being reported, but the impact of a single instance would have lasting effects with the customer.

From that point forward every time the customer would have an issue with their website our WAF was the primary suspect, not their abysmal code. We spent countless hours trying to prove a negative — that the WAF was not the issue — before the customer would even consider their application being the problem.

The same goes for built in IPS functionality in firewalls. For example, the Palo Alto Networks firewalls I used would often mis-identify a GIT replication attempt as an SSH brute force attack and block the traffic, causing the developer to lose valuable time and effort fixing something that should have just worked. From that point on we became the default group to blame whenever there was more latency than users expect or whenever something in their applications didn’t work.

By using an IDS instead of an IPS (a device that looks but doesn’t interfere with traffic) we were able to side step that issue. Instead of spending countless hours trying to assure annoyed developers (and their managers) that our security devices weren’t keeping them from their important work we were able to device our time to actually monitoring for alerts and responding to incidents.

Ease of Installation

Imagine a scenario where you have an existing basic firewall connecting your office to the internet, or even just the router your internet service provider dropped off when you signed up. If you wanted to get one of these fancy firewalls with a built-in IPS functionality installed you’ll need to configure the device, set up the IPS functionality, and then potentially disrupt the business for a while to get the device swapped in and troubleshoot the issues you know will inevitably come up.

That sucks. I know — I’ve been there.

The beauty of a standalone IDS installation is that there are no major network changes. In its simplest form, all you will need to do is install a tap on the link between your internal network and the border device (router or firewall) and then plug the IDS into that tap. In total you’re looking at about five seconds of downtime while you install the tap and then you’re done.

Conclusion

Overall, integrating an IPS into the border device such as a firewall is a good thing. Making the most out of your purchase is important to minimize the cost of security in your business, but you have to balance that against the potential impact. For me, having a standalone IDS device makes the most sense. It minimizes the impact to the network, allows the security team to focus on their jobs instead of user complaints, and requires very few changes to implement.

By |2018-05-30T00:35:03+00:00March 7th, 2018|Intrusion Detection System|0 Comments

About the Author:

Nick is the Chief Information Security Officer (CISO) for NetTex Solutions. He graduated from Penn State in 2010 with a degree in Security and Risk Analysis focusing on Information and Cyber Security. Since then he has worked as a risk analyst contractor for the Department of Homeland Security and a Network Security Administrator for Rackspace Hosting.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.