IDS mailing list archives
RE: Need help to choose a security policy
From: Omar Herrera <oherrera () prodigy net mx>
Date: Sat, 08 May 2004 10:22:48 -0600
< I don't think that trying to match your firewall accept rules is < precisely the best move. Better configure only rules relevant to
you
< architecture (for example, you might have only one type of web
server,
< so disable all rules that deal with attacks to other types of web < servers you don't have). It seems to correspond with my point of view. For example, I see that SMTP traffic is allowed, I look for all the signatures that check attack through this service and then make my
choice
among these signatures depending on my network architecture ( OS, Software etc) . This will fit my
needs
and decrease logs. Am I Right?
Correct, you will avoid irrelevant signatures in your logs. A hit reported in your logs would be relevant if it makes you worry when you see it on your logs. If there are signatures that you usually try to skip while reading your logs instead of reading the full report for that kind of signature, they are most probably irrelevant and are just making your work harder. The last statement works under the assumption that people reading the logs are trained and capable of distinguishing and understanding different kinds of attacks, so that they are well suited to perform this activity.
BUT...for example, I have a lots of alerts of SQL slammer Worms but
there
is no accept rule on the firewall. So I know that the firewall will block them. It's a evidence for me that I shouldn't pay attention to this attack. This attack will not go in the internal network, but is it interesting to
keep
track of this as an information about possible intruders? Should it be considered as noise like scan and so on ? ( too much
data to
be manageable) Is it simply a scan attack so not necessarily against us and not really relevant ?
I would leave that signature but only on the internal IDSs, you know your firewall blocks it so you shouldn't see it on the inside and it should not fill your logs. On your external IDS (before the firewall) you would get several hits a day and that will only tell you that the worm is still active on the Internet an that some infected machines sent attacks to your address range. Being that something that you can be sure that will happen (same with port scans), you can safely get rid of that signature in that IDS since it will give you no additional information. It is good to maintain this signature in the internal network for a few good reasons: * It will make sure your firewall blocks the attack, sounds obvious but you would be surprised how many times a quick request to change things on firewalls to make some application work will break things. * Your firewall might not be your only way into your network (RAS, wireless...) * A special case of the above to be specially careful of is laptops that come into your network from the outside (infected). Slammer resides only in memory, so when you turn the infected machine off it will go away, however, most suspend modes on laptops will keep slammer intact in memory (an there are a lot of reasons for an employee or consultant to have a SQL server installed in his/her laptop.
< Last but no least, if your IDS allows you to create custom rules, I guess it's possible.. < then < you should consider creating some that verify policy compliance.
Should
< your corporate web server start ftp connections to workstations in your < internal network? If not then you might as well forbid all these < "suspicious" activities. Much better if you can apply positive
logic in
<these rules (like in firewalls), for example, in snort you could
create
< 'pass' rules for that which is allowed and then create some general < 'alert' rules that will trigger when activity other than that
permitted
< is detected. This will take you time and increase your rule
database,
< but these are the kind of rules that when you see them on your
report
< you know that there is something very bad going, they don't get obsolete < so fast and the help catching unknown/new attacks/, viruses/worms
and
< the like (so they are worth implementing for critical servers). It is a different way of tuning IDS , not only matching signatures
with
attack but also anaIyse normal and anormal behaviour on the traffic. Am I right ? I read some stuffs
about
that. It seems to be quite hard.I don't know if our IDS handle this but I know that I can tune them with
some
Snort like rules.
It can be as hard and complex as you want, anomaly detectors try to address this as you describe but there are simple rules you can apply based only on use policies. For example, I don't think that a web server in a DMZ should try to initiate a connection to any workstation on the internal network in most cases (the opposite is usually allowed though), so you can put a single rule to detect TCP traffic with the SYN flag set, sent to your internal network from your web server which is sitting at the DMZ. If it is hacked or if it becomes infected with a worm and the hacker/worm intends to spread from there, this rule will most probably catch those attempts and warn you, no matter if the worm/hacker are using a 0day vulnerability or an old one. This will be still reactive with an IDS, but with an IPS it will work even better. IPS work inline and so they have to be well tuned in order to avoid false positives and blocking of legitimate traffic. So IPS usually end up blocking few well known attacks (few is relative to what you can configure in a passive IDS) while not breaking things. However, using rules like the one above with an IPS is great because they are based on company policy so you know they won't break anything, they will catch new/undiscovered attacks and you will take advantage of the preventive nature of an IPS (well you web server in this example will be trashed already, you will only stop further damage). The bottom line is that you don't have to make it so complex with policy based rules, in fact trying to keep it as simple as possible will be much better. The trick here is creating rules that will both support a policy and match common attack patterns at the same time (with negative logic, if you are able to use positive logic you might want to go only for policy compliance and consider any action not allowed by policies as hostile). Regards, Omar Herrera --------------------------------------------------------------------------- ---------------------------------------------------------------------------
Current thread:
- Need help to choose a security policy CEDRIC CASSIN (May 06)
- RE: Need help to choose a security policy Omar Herrera (May 06)
- <Possible follow-ups>
- RE: Need help to choose a security policy CEDRIC CASSIN (May 07)
- RE: Need help to choose a security policy Omar Herrera (May 10)
- Re: Need help to choose a security policy embyte (May 14)
- RE: Need help to choose a security policy CEDRIC CASSIN (May 10)