I was introduced to a nice network forensics tool today called Dshell, written by the U.S. Army Research Lab. Written in Python, it allows dissection of pcaps using decoders, which can be chained together to do multiple analyses of traffic. You can run decode -l to see the list of available decoders, which includes:
dns - extract and summarize DNS queries/responses (defaults: A,AAAA,CNAME,PTR records)
reservedips - identify DNS resolutions that fall into reserved ip space
large-flows - display netflows that have at least 1MB transferred
long-flows - display netflows that have a duration of at least 5 mins
rip-http - rip files from HTTP traffic
protocols - Identifies non-standard protocols (not tcp, udp or icmp)
and many others..
You can download the source and find what dependencies need installed as well as examples and syntax at:
https://github.com/USArmyResearchLab/Dshell
Information, tools and how-to's for the new intrusion analyst. Mentoring by blogging.
Monday, December 22, 2014
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.
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.
Subscribe to:
Posts (Atom)