Pages

Friday, March 6

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.