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.
1 comment:
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.
Post a Comment