Printable View
What would you think as the ideal placement of an IDS on the network. The ideal way I would think is immediately after the firewall and before the main router. One of my colleagues suggested placement of the IDS before the firewall. I am not sure. COuld you give me suggestions on where an ideal placement would be. Also could IDS and the firewall data correlate with each other in creating a more dynamic security policy?
After the firewall would be a good location for it because it eliminates seeing all the other traffic out there and there's a lot of traffic that would pass by. The IDS' placement after the firewall (or even after the main router) are good locations as it will detect attacks that manage to get pass the firewall (acting as an alarm system). Tying the firewall and IDS together could work but you do run into risks with false positives, which might cause your firewall to close more ports than necessary. Personally, I'm a firm believer in having a human check things and doing the alterations as technology can only go so far. As a random example, if an attacker was particularly out to cause damage he could "spoof" an attack as if it comes from your DNS and thus cause the IDS to tell the firewall to ignore anything from the DNS.
Which IDS are you implementing?
I prefer to use a layered defence, by placing an IDS in front of the Firewall and another IDS behind the Firewall. In my environment, I need to know when we are receiving a sustained attack, thus the IDS placed outside the Firewall. Because of the Firewall rulebase dropping particular packets/connections on the Firewall, I may not be aware of an attack against the Firewall itself or devices behind the firewall where the attack is blocked at the Firewall. (lots of noise though) The second IDS lets me know what potential attacks have made it through the firewall and into the DMZ in question.
I'm with OverdueSpy on this one. A stealth NIDS on the outside of the firewall and a non-stealthed NIDS on the inside. I can see what traffic comes at and passes through my firewall which is a firewall rules check in itself.
The stealthed NIDS outside the firewall also has an additional benefit in that it sees all traffic regardless of the firewall but it's detection is very difficult. Basically you have to own the border router or the firewall to detect it's presence and the detection can be a hit or miss affair. Therefore, in the event of a successful compromise and disabling of the "locatable" NIDS the attacker may simply carry on with his "job" thinking that he has disabled my security systems. That would be a mistake.... ;) The fact that it is outside the firewall ensures that I catch all the traffic still because that is the "choke point" all his traffic _must_ pass through in a remote compromise.
I disabled all network related services on my fast XP box and put two NICs on it. One pluged behind the firewall and one outside. I am running two instances of Snort and snort is logging to mysql database located behind the NAT. The inside card has a legit IP/subnet, and the outside card has a bogus IP. With everything disabled, the box shows no signs of existance on the outside NIC. I guess I could have used redhat and have no IP on the outside as opposed to a bogus one, but I am just more familiar with disabling services in windows as opposed to securing redhat.
Tarpi:
Disable all protocols on the outside NIC.... Then it is stealthed. WinPCAp will still open the NIC for use without risk of transmission
Hi Everyone -- it's my first post here and I would like to comment :) . While having a NIDS on both sides is ideal, most smaller customers (ones with 5 servers or less) would find it difficult to cost justify this particular scenario. Most environments would do well with one, while having a good admin running some kind of sniffer tool could keep track of any suspicious traffic that may get past a firewall and/or NIDS and be a little less expnsive at the same time (at least the software-based ones would be anyway). Just my 2 cents.....
Hrmm.. Snort with PHP/MySQL on FreeBSD box cost me $50 (for the box -- a pentium 100 w/64MB of ram). If you think superlarge servers, then yes cost can be an issue but if you get creative, it doesn't necessarily have to be.Quote:
While having a NIDS on both sides is ideal, most smaller customers (ones with 5 servers or less) would find it difficult to cost justify this particular scenario.
whta: Ms. Mittens, as usual, is right. There is a ton you can do for free and it doesn't have to be in a open source environment. I do have a "bigger" network but I also work for a non-profit so cash isn't exactly "flowing".
My tutorial on Secure Central Logging found here shows a fairly complex system but you will note that outside the hardware cost my only cost was time. The hardware costs could be cut significantly commensurate with the perceived risk/tolerance level yet still provide a cost effective yet secure system for even a small shop.
sorry i am late at looking for responses and replying. I was inundated with work this morning. the past 2 days has been practically immersed in a sea of reseach and stuff. anyway we are implementing a e-trust IDS on a enterprise wide basis. I did speak about this issue to a few people. We are leaning towards putting it just behind the firewall and before the main router. Then again, we will truly know only during deployment which will happen in a couple of weeks time.
Vikram7000 Just an FYI here - If you are new to the IDS arena, one of the challanges I have seen many organizations face, is that most IDS platforms do not have a reliable backup plan. Most of the IDS companies claim that their products are recoverable if you will simply back-up the database. In reality this is normally far from the truth. For instance if you loose the HDD that the, I'll say "event collector" for lack of a better term, ... that the event collector is stored on, your first challange will be with the encryption scheme that allows the database on the event collector to communicate with your remote detectors. Normally this is not a big challange, but most of the IDS platforms tie the encryption key into an "instance per installation" type of schema. This means that while you still have your database and can get to the information, you will be unable to integrate it with any new data going forward.
The second challange is with the custom policies that you build to reduce displaying false positives, e-mail or text notifications, etc. Most of these polices have flags that are tied to the old database, which are once again tied to the encryption key installation instance, even though the policy is in essence a flat file. Typically this requires the administrator to rebuild any custom policies from scratch, because the expected pointers become no longer valid.
The third challenge I have seen, is that after you have brought up a new database, you will have to reinstall all of you remote detectors to make the encryption schemes match.
This is all based on my personal experience with different products, and may not be applicable to what you are running, but it is definantly something to look at before a failure occurs. If anybody else has experience playing with backup availavbility for IDS, pleas post your thoughts. I look forward any info on an easily recoverable IDS solution.
Thanks OverdueSpy for the heads up i am new to the ids scene and in the process of testing some ids system for future deployment. Your post gave me a lot to think about and ad to my tests.
PS i think you just saved me from a lot of late nights kicking and screaming at my ids.
Guys, with all due respect, you're getting off the subject. I agree with whtabtbill about his observation, and the poster didn't ask about the best way to create an "enterprise IDS implimentation."
The original question was "where is the best place for an IDS?" Sounds like a single to me. So far, I've read responses about using multiple IDSs, Snort, user policies, etc., etc.. After the first couple of posts, the thread went haywire (no pun intended).
So, "where IS the best place for an IDS?" If you only have one, I would put it on the inside of both routers, closest to the servers, workstations, etc.. I do pen-testing for a living. I see these things "all the time":
- open VPN access (right through or past the firewall and IDS),
- modem access (that never goes through the routers),
- router compromise (and access through the IDS),
- IDS compromise (game over),
- Trojan action from inside,
- malicious insider,
- workstation comrpomise (exploit from the inside).
Wouldn't placing the IDS on the inside router help prevent most of these? Oh, and have it face both ways...
my $.02.
Excellent responses by OverDueSpy...
IDS/IPS "solutions" are/can be very tricky indeed. Taking what was said a step farther, be *sure* that if you do run an IDS/IPS in-line that it fails open. I have seen some major IDS/IPS vendors with appliance based IDS/IPS solutions that failed closed in line. This means that *all* trafffic stops. Can you imagine cutting off 10,000 users simultaniously? Also, if you go an extra step and buy an IPS solution, my advice is to run it in "log only" mode for at least a week. This will allow you to understand how it would have reacted if you had full IPS turned on.
Now, different vendors make different claims when it comes to the actual quality of data you receive. Here is what I can tell you about the vendors I have dealt with.
Cisco 4235 series on the 4.x platform - Many false positives. Signatures are kinda clunky to update. Console is too many layers deep (have to click about 10 things before seeing what you really want). Reporting is awful.
ISS Proventia G series - False positives are minimal. Configuration is easy. Management console is clean and uses common language to give you the info you want (EX: Show me the source of this event). Signature updates are easy to get but the HUGE pain in the ass is that whenver you get a new signature you have to reconfigure all of the signatures. I have bitched to ISS about this and perhaps they will modify the bahavior down the road.
I have also heard that NAI has finally gotten their act together in the IDS/IPS arena but I have yet to demo their product.
The bottom line here is that you may want to take the layered approach but you also may want to go a little bit deeper with a multi-vendor layered approach. You can argue for or against this but in my experience, this has proven to be the best overall approach.
And finally, you are going to have to do some serious traffic analysis and aggregate data at different layers as to not be overwhelmed with meaningless security data. I could write a book on this but just be aware of it from the start.
If I only had one device, and I trusted my firewall, then yes, an internal IDS would serve you better overall but placement on the inside is just as important. I would pop it off a management interface of the core internal router but that's just me. ;)Quote:
Wouldn't placing the IDS on the inside router help prevent most of these? Oh, and have it face both ways...
--TH13
Mykol:
You seem to be forgetting two things.
1. Most environments are switched and many, especially smaller shops don't use managed switches so viewing internal traffic with a "single" IDS is very difficult.
2. Let's be a little creative. A single IDS can monitor many parts of a network at relatively low cost. Just keep adding NIC's till you fill up the slots..... ;) I have a single box that monitors inside and outside my firewall, it has two NICs. If I wanted to monitor somewhere deeper in the core of my network with the same box I add a NIC, cable it to an appropriate point to capture the traffic and configure another instance of Snort. Total cost: $20 for the NIC and a few dollars maybe for a new cable - I might be able to patch it in though existing cabling. I kept all my old hubs when I moved to switches.... What can I say.... Packrat....
The examples of things you see are common I'm sure but they fall into two categories really. Improper configuration, (VPN, modem, router, IDS compromise), and the rest are a question of "acceptable risk of doing business" and fall into that "balance of security versus usability" area that makes our jobs so much more interesting...... ;)
The initial question was, IMO, a little "over simple", (no offense to Vikram), but to be able to properly monitor anything outside a single collision domain you need, at a minimum, multiple interfaces otherwise Murphy's Law clearly states that the traffic you _need_ to alert on will never enter the collision domain you are monitoring. So, unless Vikram intends to only monitor a single collision domain he's going to need more than one interface or IDS depending on the capabilities of his IDS solution.
In Vikram's case he uses the word "enterprise" which to me implies a multiple collision domain architecture and the use of a single IDS placed just inside the firewall. IMO, in a single IDS/interface environment he is placing it optimally insofar as he is placing it at the point of greatest risk. Having said that he will miss all the traffic that remains internal to his network unless the network is _entirely_ hubbed. That precludes him from monitoring much of the risk posed by malicious users, open modems, worms traversing the network via shares etc. etc. etc unless he can wire the network in such a way to ensure that all traffic passes through the IDS which, in an existing network, can be harder than one may think... I recently discovered that I was omitting a whole subnet because the wiring wasn't quite the same as I thought I had..... :o
Vikram: I would suggest looking into secondary sensors appropriately placed in order to more thoroughly monitor the network. Snort is good and the price is right and can be run from multi-use servers or workstations in many cases without significant overhead or risk of packet loss which will help to keep the additional costs down.
As Tiger Shark rightly put it, I am now leaning on placing the main IDS just inside the main firewall and placing some more secondary sensors inside of the network to monitor the intranet traffic. I am gonna have to do this in all the locations on the network. Yes it is gonna be a multiple collision domain. Thats why I in consultation of my colleagues have decided as you rightly put it, to place some sort of secondary sensors for the internal traffic and the traffic between our various locations.
The deployment might start off sometime next week hopefully(keeping fingers crossed).
IDS works best if it is at the Border Router to your network.
This is not to say you may need more than 1 IDS to protect
your network.
The IDS I am somewhat familiar with is the Cisco line.