Thursday, December 4, 2014

About Those Obvious IDS Filters...

Tuning and filtering your IDS is a necessity to keep from being overwhelmed by false positives, and it's an ongoing process that never ends. New rules are applied, new network segments are stood up, and new services are offered.. it all requires a continual process of tuning. But sometimes that overly obvious filter might not be a good idea.

For example, IDS rules will trigger when they see Base64 encoded content (assuming you have that rule or rules enabled). The reason for that rule is that attackers will often use different encodings to try to obfuscate their attacks. But Base64 is used legitimately on a continual basis, so there may be, actually almost certainly will be, false positives.

You may be tempted to just disable the signature because it causes FP's. I wouldn't recommend that, because there will eventually be malicious content going across your network in Base64 format. Another idea would be to filter out certain sites or content. But think carefully about the full ramifications before you do this.

Here's one I see on a regular basis. Web sites created with the DudaOne Mobile Web Site Creator will contain a Base64 encoded site identifier that looks like this:

SiteType : eval(Base64.decode("J0RVREFPTkUn")),

You could create a content filter that looks for that particular string and use it to filter out packets that contain it. But giving it a little more thought, it would ALSO filter out compromised sites containing that string that also have malicious code else where on the page.

By applying that filter, you are in essence saying "I always trust any site that was created using the DudaOne Mobile Website Creator tool and I never want to see alerts from that site." Not really what you were intending to do, was it?

Use filtering judiciously and carefully and after careful thought about what it will actually do. You don't want to accidentally blind your IDS, and yourself, to traffic you need to see.

No comments:

Blog Archive