Skip to main content

Why is your IDS outside your firewall?

Stop that. You’re doing it wrong.


This is a very puzzling situation that I run across quite often, more often than I should. I thought i’d bring up a few points as to why, I view, IDSs outside of Firewalls, to be a bad thing.


Allow me to play Devil’s Advocate here for a minute, present a few arguments, then allow me to rebuttal them. I am not insulting anyone that has their sensors outside the firewall. But I ask to you please reconsider. Here you go:




1. We place a sensor outside of our firewall to see what’s “out there in the wild”.


    First off, the Internet is not plugged into one big hub. Network traffic that is destined for somewhere else is not going to be seen by your network. Only networks that you advertise as yours will receive the traffic that you intend. Placing a sensor outside of a Firewall because you think you are going to see traffic “floating” by, is just plain wrong.


    Second of all, if you have a "Deny all, permit by exception" policy on your Firewall -- as you should -- only allowing things into the network that you explicitly want people to access remotely, you will only see UDP based attacks on the outside. So, you will simply pick up a lot more SQL Slammer attempts at your gateway. Confused? What do I mean?


    If you have a state-ful Firewall, denying access to your network prevents a valid 3-way handshake to be exchanged with a host you EXPLICITLY allow access to from the outside, you will never receive any more attacks on a TCP basis. Your IDS will sit there and track SYN packets all day, attempting to track sessions, never receive SYN-ACK’s, and purging that session from the state table upon timeout. Maybe your Firewall will send an ICMP Admin Prohibited response if you have it configured to do so, however, most Firewalls simply drop silently. After all, why would you want the attacker that is coming after you to know you have a Firewall, and exactly what hop it is in the network?


    This is a waste of IDS resources, time, and money. (Time = money.)


    2. “We put the IDS outside the firewall because if an attacker is going to attack our network, they are going to attack the firewall first.”


    (Yes, this is an actual quote. I do have permission to repeat it, as long as I don’t tell anyone who said it. Actually, the person who told me this was simply repeating what his network admin had told him.)


    If you told me that statement above, I would assume three things.


    First: The management interface to your Firewall is accessible from the Internet.


    Second: If it is, what is the condition of the rest of your network, because I can most likely attack it easier.


    Third: Obviously you are willing to sacrifice your IPS. (by putting it outside) What is the difference between an IPS and a Firewall in this context?


    I say they are both security devices, and are both vital to the protection of the network. If I am an attacker, I am not going to attack your firewall. I am going to try and find a way THROUGH your firewall, install some kind of backdoor, then get in through that, or better yet, have the backdoor opened for me from the inside. You obviously allow some ports open on your firewall so I am going to go in through those first. I’d rather go after your SSH server, FTP server, HTTP server, hell, i’d rather attack your printer than to go after your firewall. That is, of course, assuming your management interface isn’t sitting in the DMZ, and has a password of “password”.


    3.  It’s the only aggregation point we have where all the traffic comes together!


    Okay, fair enough, I’ll allow this argument. However, I am assuming then, that this is just a temporary solution until you can either afford to buy more sensors, or build more SNORT® boxes. It should only be a temporary solution and you should really concentrate hard on moving your IPS inside of your firewall, perhaps get traffic to the IPS/IDS with taps or multiple spans. Utilizing multiple detection engines on one machine is a good way to do that. A sensor sitting outside the firewall is never the solution, for two or three really good reasons I just talked about above.


    I am sure I can probably think of some more, but that’s enough for now.

    Comments

    akosbeginner said…
    1. If there were no sense to use an external IPS before the Firewall, than an integrated IPS in a UTM device would have no sense as well. Just thinking about the portscan realised by the IPS modul…
    Example: If I see a suspicious traffic from a source IP (Reconnaissance, Probe *owner of the IP is here*, Penetrate, Propagate, Paralyze.) and then I see his IP in normal Firewall log as legitim/enabled traffic, then I would suspect that he/she goes one level forward (Reconnaissance, Probe, Penetrate *owner of the IP is now here*, Propagate, Paralyze.) and tries something through an opened port on my public server behind the firewall. In this case I would close the IP out with the external IPS.

    2. What I could imagine as a basic concept for IPS planning is shared IPS topology:
    - Phase 1.: Basic monitoring/filtering. As an example portscan, ip spoofing and stuff you can do with nmap and such tools. Monitoring of the legitim traffic on Application level should I leave for Phase 2.
    - Phase 2.: Specific monitoring/filtering, according to our publicly available services through the firewall (http, https, smtp)

    Phase 1. The basic filtering before the firewall.
    The firewall filters out all not legitim traffic and only with internal IPS we loose the information about the attackers looking for or scanning for accessible services. But if we identify a not legitim traffic from a host and than we see the same host as a legitim traffic, than it is almost 100% that it is not clear…

    Phase 2. The specific filtering before or after the firewall.
    In case of many DMZ interfaces (in which many servers are publicly available) would it be easer to implement an IPS before the firewall and not pro DMZ interfaces. This way we can monitor only on one interface all our public servers residing in many different DMZs.
    Just a quick picture from the market, the todays smallest firewalls have minimum 4-8 ports meaning that the general topology, where we had only an inside and outside interface, has changed.
    On the other side DMZ means Demilitarized Zone where we always expect attacks. If we have different priorities for the DMZs than between DMZs we can use another IPS as well - it depends on the company's security policy.

    3. "… a lot more SQL Slammer attempts at your Gateway"
    The IPS that is not customized can genarate tons of false positives, no matter where it resides. The external IPS should not monitor everything too. With finetunnig can we sort out all low severity events.

    4. “We put the IDS outside the firewall because if an attacker is going to attack our network, they are going to attack the firewall first.”
    The management access is required not ony for IPS, but for many Servers, Applications generally. There are many new customer requirements and people want to work from an InternetCafe. (It was at first funny but spreads faster then we think.)
    The remote IPS management access should be as secure as other remote access for the company. Typicallly VPN (ssl or IPSec) is used here that is a service terminated on the firewall. Apart from those many services can be terminated on the firewall too. Those can be protected (or at least monitored) only with external IPS.

    Popular posts from this blog

    Offset, Depth, Distance, and Within

    Without going off the deep-end here and discussing every single Snort rule keyword, I just wanted to touch on a few modifiers that people sometimes misunderstand.  They aren't difficult, and hopefully after this explanation and a few examples, I can clear some of the air around these five modifiers.

    The five modifiers that I am talking about are
    OffsetDepthDistanceWithinnocaseThese five modifiers are not keywords of themselves, but rather they apply as modifiers to another keyword.  That keyword is "content". The content keyword is one of the easiest pieces of the Snort rules language as all it does is look for a particular string.  So for instance if I wanted to look for the word "joel" within a packet.  A simple:
    content:"joel";Would allow me to do that.  The interesting part comes into play when you want to specify where inside of a particular packet you want the string "joel" to be looked for.  If you are running just a plain content ma…

    Writing Snort Rules Correctly

    Let me start off by saying I'm not bashing the writer of this article, and I'm trying not to be super critical.  I don't want to discourage this person from writing articles about Snort rules.  It's great when people in the Snort community step up and explain some simple things out there.  There are mistakes, it comes with the territory.  If you choose to be one of the people that tries to write Snort rules, you also choose to be someone who wants to learn how to do it better.  That's why I write this blog post, not to bash the writer, but to teach.

    I noticed this post today over at the "Tao of Signature Writing" blog, and to be honest I glanced over most of it figuring it was a rehash of things I've already read or things that have already been written from countless people about "Here's how you write Snort rules!".  I scrolled down quickly skimming, not reading at all really, and noticed this part:
    Now, let us look at the second questio…

    Safari 5.1.4 now available

    Safari 5.1.4 now available, fixes issues and improves performance | TUAW - The Unofficial Apple Weblog:


    Improve JavaScript performanceImprove responsiveness when typing into the search field after changing network configurations or with an intermittent network connectionAddress an issue that could cause webpages to flash white when switching between Safari windowsAddress issues that prevented printing U.S. Postal Service shipping labels and embedded PDFsPreserve links in PDFs saved from webpagesFix an issue that could make Flash content appear incomplete after using gesture zoomingFix an issue that could cause the screen to dim while watching HTML5 videoImprove stability, compatibility and startup time when using extensionsAllow cookies set during regular browsing to be available after using Private BrowsingFix an issue that could cause some data to be left behind after pressing the "Remove All Website Data" button