Printable View
I have 128 MS SQL servers I need to add into my snort conf. I want to know if anyone has any info or experiences (good or bad) with this.
The servers cannot be added by subnet as they are scattered over a large network.
To sum it up:
What are the perfomance problems with adding 128 ip addresses to the SQL_SERVERS variable in the snort.conf? Has anyone tried this with success? At what number did you start to experience performance hit?
Thanks.
Taking into account the number of servers and therefore the traffic I would suggest multiple IDS'. The large number of variables would place some significant strain on the Snort box and with the amount of traffic the Snort box needs to look at I believe you would end up missing some stuff or it would be so slow as to be unusable.
I would map the network and the locations of the servers and then determine a more manageable sensor placement system. You can still have them log back to a central system to consolidate your logs but the sensors themselves would have some flexibility in case of high traffic situations.
Thanks Tiger.
Sorry, I should have mentioned this. The IDS solution is distributed over 30 sensors around the world. The SQL server are deployed this way too. Any given sensor will be handling a very small portion of SQL traffic.
I'm not to worried about the bandwidth that the sensors are montioring, this was taken into consideration during design and testing. I'm mostly concerned about snort being able to parse and store in memory that many variables. I have some server variables with 10-20 ip address which seems logical. Adding 120+ seems a little extensive, but is needed in this situation.
And I've already visited having a different snort.conf on each sensor. This is not possible as the management would be extremely difficult. Right now I have a base policy that is distributed to all sensors. Local policies are added as needed.
Does that make more sense?
Whats the wire speed and how much traffic is normally going on at peak hours?
You can build a stand alone snort box compiled against Phil Wood's memory mapped libpcap, tailor the rules you need on a semi-powerful cpu and lots of ram and you should be able to easily handle a 100Mb network . Now if you on a gig network you probably have to go with one of the commercial vendors.
I think the limit for a snort variable may be 1024 characters.You might want to do as Tigershark said and try to have your MS SQL have a consolidated ip range say 172.21.0.0 - 172.21.0.255 , then you can use CIDR notation to specify this range 172.21.0.0/24 .
Trench:
You might want to take a look at this.
It's a Windows based Snort policy manager and it might help you.
Disclaimer: I have only been using it for a few days. I have been aware of it for some time but never got around to implementing it. I finally got a bit fed up of doing the management manually and decided to take a look.
It's pretty easy to set up - about the hardest part is setting up an acceptable secure communication with the sensor - and configuring it is pretty easy too. It will automatically d/l and merge snort rules and bleeding snort rules but you can can set it to disable the new rules after merging them if you want to look at them first. Then you can upload individual policies to individual sensors at will. It seems pretty robust and the price is spot on..... :)
Nice pick Tiger... I'm using this too. Let me know if you have any questions about it. I've had it in production for months.
It's actually a really great tool. I would suggest anyone who has multiple sensors to give it a try. It DOES have some quarks though!
Their commercial product looks like a beast! I'd love to get my hands on that. I priced it and it's expensive.
Did you try their Honeynet Security Console? Very cool reporting tool, but it can only be used on one sensor...
I will take a look around their site to see what else they have to offer, thanks for the heads up.
Adding the variables to your snort.conf actually makes the engine faster. Despite what is said here.
If Snort is watching all traffic, but it only has to run SQL rules against those IP's set in the SQL_SERVERS variable, then it DOESN"T have to run the SQL server rules against all the stuff in !SQL_SERVERS.
It's faster, IOW. Fill in as many variables (ESPECIALLY HOME_NET) as you can.
The only decision you need to make then is: "Should EXTERNAL_NET be "any" or !$HOME_NET".