What Every IDS User Should Do

The Emerging Threats Rulesets (AllRulesets) are not your average rulesets. There are a lot of very niche applications being covered, and a lot of malware activity detected. Much of this is behavioral, and much is very specific to certain environments. Every user when choosing to use the Emerging Rulesets should take a very close look at all of the rules before they enable them. Some may not apply to you, some may detect things you don't care about. Do yourself a huge favor and spend an hour browsing through before turning things on.

Even as specific as this ruleset is, there are many things we've not been able to add to this ruleset. Most of these are things that are important, but that can't be generalized enough to fit every environment. These are things you should be doing, but that you'll have to write your own rules for. This page will outline some of those suggestions and give you a starting point to write your own local rules to suite these needs.

If You are using an Automated Blocking Tool

There are many ways to use Snort data. One of the most effective is to do automated blocking of attackers. This can be done using the Snort_Inline package or Snortsam. Both of these tools allow you to define Snort Signature hits that will cause the source or destination IP address to be blocked for a certain amount of time. Snort_Inline will be a bit faster, while SnortSam will allow you to block among many devices on your perimeter. Both are great tools and using one or the other is highly recommended if you can do so in your environment.

If you are blocking here are some things you should consider adding to your local ruleset.

Unused Ports

Lets assume you have a firewall (if you don't you shouldn't tell anyone). You don't allow all traffic in, and hopefully you control what ports are allowed out. Those packets that come in for ports that you don't allow will tell you something about the source. For example, someone scanning for open ports on 5900 is looking for VNC servers and will likely start a brute force attack if they find one. Well thats an IP you probably don't want to talk to for any reason. There are a number of ports that would not be welcome: 1434, 139, 3306, 8080, etc. People looking for exposed services to abuse. People you don't want to talk to. So lets add a few rules for common unused port ranges. You should consider and adjust these port ranges to suit your own need. I'll add SnortSam block statements in these examples. For Snort_Inline you'd make the rule a drop or stickydrop vs an alert.

var UNUSED_EXTERNAL_TCP_PORTS [1:19,26:52,515:]
var UNUSED_EXTERNAL_UDP_PORTS [1:52,162:]
alert tcp $EXTERNAL_NET any -> $HOME_NET $UNUSED_EXTERNAL_TCP_PORTS (msg:"LOCAL Inbound Traffic to Unused TCP Ports -- BLOCKING SOURCE"; \
 flags: S,12; threshold: type both, track by_src, count 3, seconds 60; classtype:policy-violation; sid:100000x; rev:1; fwsam:src, 60 minutes;)
alert udp $EXTERNAL_NET any -> $HOME_NET $UNUSED_EXTERNAL_UDP_PORTS (msg:"LOCAL Inbound Traffic to Unused UDP Ports -- BLOCKING SOURCE"; 
 threshold: type both, track by_src, count 3, seconds 60; classtype:policy-violation; sid:100000x; rev:1; fwsam:src, 60 minutes;)

These two rules will give you one alert every minute for more than 3 inbound syn packets to unused ports. This will block the source IP for 60 minutes if you use snortsam. If they keep trying they'll continue to be blocked. YOU NEED TO LOOK AT THOSE PORT RANGES!!! Adjust them to suit the services for which you expect incoming traffic.

Why block an attacker that's already been blocked by your firewall? Because they will continue to beat on your door till they find something they can brute force or exploit. So lets use their initial scanning to identify hostile intent and block. If you're not too sure you can block for shorter periods, like 5 minutes. That way if you block a legitimate client the block is gone before it's even realized by the client. If they're a hostile host they'll likely keep tripping this or other rules and they'll remain blocked longer.

Multiple Inbound SMTP

This is one of my favorites. Spam bots don't usually pipeline SMTP connections as they should. That is if they have 10 emails for your site they are supposed to send them all in one session. Spam bots aren't that sophisticated so they generally will send them all in separate connections. I run this rule and it cuts out a good 40% of my inbound spam.


alert tcp !$HOME_NET any -> $HOME_NET 25 (msg:"LOCAL Multiple Inbound SMTP Connections -- BLOCKING SOURCE"; \
flags: S,12; threshold: type both, track by_src, count 9, seconds 300; classtype:misc-activity; sid:100000x; rev:1; fwsam:src, 15 minutes;)

This will block and host that tries to make more than 9 new smtp connections within 5 minutes. That may sound low but it's really a spectacular amount of mail from a single source. You can adjust that up and down and find where it works for your site. Keep in mind that mail from major providers like Gmail and Yahoo is sent from large farms of servers. They'll not initiate many connections from a single one of those farm servers to your mail server.

You can also adjust the block time down if you're concerned about blocking legitimate email. Worst case as is is an email will be blocked for 15 minutes.

Traffic to Unused IP Ranges

If you have an unused IP, or a range of unused IPs, I highly recommend a rule to detect anyone talking to those IPs. If they're not advertised for incoming services then anyone attempting a connection to them very likely does not have your best interests in mind. I highly recommend blocking. This is even more effective if you have an unused IP at the numerical beginning and end of your space. That way you catch and block scanners moving across your space sequentially, they'll think your entire ip space is dark and move right along.

var UNUSED_IPs [1.1.1.1,1.1.1.10]
alert tcp !$HOME_NET any -> $UNUSED_IPs any (msg:"LOCAL Inbound Traffic to Unused IPs -- BLOCKING SOURCE"; \
flags: S,12; threshold: type both, track by_src, count 1, seconds 60; classtype:misc-activity; sid:100000x; rev:1; fwsam:src, 24 hours;)

This will trip on 1 packet in 60 seconds and block for 24 hours. Adjust to your liking. I go 24 hours because many of these things will be automated scanners, and a human may come back around to verify results a few hours later.

Rename Blocking Signatures

It's very useful when browsing alerts to have the MSG actually identify that a block action was taken for this alert. Lets the analyst give them a quick look to verify it's not a firendly IP but can then move on. Oinkmaster is ideal for this:

modifysid <comma-separated-list-of-sids> "(.*msg:\s*\")(.*)" | "${1}BLOCKING: ${2}"

All Sites (Blocking or Not)

It's OK, we understand. Not everyone can enable automated blocking in their environment. Whether for politics, risk tolerance, technical limitations, or you're just a big wuss. It's alright. You'll be OK, you'll just have to watch your logs far more often and react in a much more timely manner.

Here are some things that both blocking and non-blocking sites should consider enabling in your local ruleset.

Systems That Should Never Surf the Web

Every environment has a set of systems that should NEVER surf the web. File servers, UPS Controllers, VPN Devices, Domain Controllers, etc. Take a close look at your network inventory and consider which systems shouldn't be connecting outbound. A signature to tell you when they are might look like this:

var NEVER_OUT_SERVERS [192.168.1.x,192.168.1.x, etc]
alert tcp $NEVER_OUT_SERVERS any -> !$HOME_NET $HTTP_PORTS (msg:"LOCAL Outbound Connection from Unexpected Server"; \
flow:established,to_server; threshold: type both, count 1, seconds 60, track by_dst; classtype:policy-violation; sid:100000x; rev:1;)

This will alert once every 60 seconds for outbound established connections from servers in the defined variable. This rule is for http traffic only, you could easily remove that and watch for traffic on all ports. Keep in mind you may have to exclude NTP traffic and other normal things. For Windows servers you'll also likely get Windows Update traffic if you're not doing internal patch pushing. You could exclude that by IP (you will generally get the same WUS server IPs as they're doled out geographically) using a suppress statement like:

suppress gen_id 1, sig_id 100000x, track by_src, ip <IP>

DNS Requests from Other than our DNS

In most environments dns goes through a local resolver, so all outbound dns requests should be from that resolver only. Often malware will try to resove directly, or try to redirect requests to a fake dns server. A rule like so will help you identify these infections as well as other bad things:

alert udp !$DNS_SERVERS any -> $EXTERNAL_NET 53 (msg:"LOCAL Outbound Non-DNS Server DNS Traffic"; content:"|01|"; offset:2; \
depth:1; threshold:type limit,track by_src,count 1, seconds 60; classtype:misc-activity; sid:100000x; rev:1;)

Thanks to Cunningpike for this tip.

Sensor Placement Related

Things not directly signature related.

Default Route Placement

Kevin Ross notes that if you're in an environment where web traffic is proxied placing a sensor at your default route out can be very informative. Most of the traffic (especially web) that tries to go out of your default route should be very suspicious. A large amount of malware isn't proxy settings aware and thus will give itself away every time!

If you are using proxy pack to configure your browsers (as many large sites do) then you will find that the latest version of Flash ignores setting from proxypac and tries to go direct to the 'Net. I imagine this rule would trigger on such traffic (Russell Fulton).

-- MattJonkman - 09 Dec 2008

Topic revision: r10 - 2013-07-09 - MattJonkman
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © Emerging Threats