[Emerging-Sigs] Jorik FakeAV sig

Matthew Jonkman jonkman at emergingthreatspro.com
Mon Oct 31 13:22:34 EST 2011


On Oct 31, 2011, at 1:09 PM, Packet Hack wrote:

> So can someone give the quick and dirty when it's better to use
> fast_pattern:only vs. http_uri/http_method?
> 

I don't know that there's a simple answer there. And it'll vary depending on the engine. 

fast pattern only is complicated on Snort, and I have to admit I don't fully understand it there. You can create false negatives in cases where you put too long a string into FP:only, etc. So we tend to let snort and suricata make the decisions on fast pattern when we can. They both do a good job by default. 

Now when we have an obviously more unique shorter string we mark it to fast_pattern, but not often do we use only as well.

As for using http_*, that's important on both engines snort and suri. Normalization, especially in the URIs is critical. Performance is a moot point really, if not normalized we become extremely evadable. 

On suricata using "alert http …" and http_* is a great performance gain, because the http rules will not be applied to anything that's not http. And they'll also be applied to every stream on any port that IS http. That's why suri does WAY better on malware than snort with the same ruleset. Off port http malware CnC's are easy to catch. 

That help any?

matt



> -- pckthck
> 
> On Sun, Oct 30, 2011 at 11:23 AM, Martin Holste <mcholste at gmail.com> wrote:
>> Yep, looks like this one needs to be updated to content:"GET";
>> http_method; content:"/britix/a"; http_uri;  By the way, "britix"
>> never appears in any part of a URI legitimately in our experience, so
>> this should not need any anchoring.
>> 
>> On Sat, Oct 29, 2011 at 10:19 PM, waldo kitty <wkitty42 at windstream.net> wrote:
>>> On 10/29/2011 15:40, Jason wrote:
>>>>> 
>>>>> alert tcp $EXTERNAL_NET  any ->  $HOME_NET $HTTP_PORTS (msg:"UFOISC
>>>>> Jorik FakeAV GET"; flow:established,to_server;  content:"GET /britix/a
>>>>> HTTP/1.1"; fast_pattern:only; sid:9100560; rev:1;)
>>>>> 
>>>> 
>>>> 
>>>> Forgive me as i do not work often with snort. Would this signature also catch
>>>> "/britix/ar"? You should be on guard for this in addition to the /a. Thank you.
>>> 
>>> strictly looking at the rule posted, it would appear that your URI is not
>>> caught... why? because the space is invisible in the rule and it appears to read
>>> as "/a http/1.1" (no case on purpose)... which means that "/a" followed by a
>>> space plus the http revision is all that's looked for...
>>> 
>>> _______________________________________________
>>> Emerging-sigs mailing list
>>> Emerging-sigs at emergingthreats.net
>>> http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
>>> 
>>> Support Emerging Threats! Subscribe to Emerging Threats Pro http://www.emergingthreatspro.com
>>> The ONLY place to get complete premium rulesets for Snort 2.4.0 through Current!
>>> 
>> _______________________________________________
>> Emerging-sigs mailing list
>> Emerging-sigs at emergingthreats.net
>> http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
>> 
>> Support Emerging Threats! Subscribe to Emerging Threats Pro http://www.emergingthreatspro.com
>> The ONLY place to get complete premium rulesets for Snort 2.4.0 through Current!
>> 
> _______________________________________________
> Emerging-sigs mailing list
> Emerging-sigs at emergingthreats.net
> http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
> 
> Support Emerging Threats! Subscribe to Emerging Threats Pro http://www.emergingthreatspro.com
> The ONLY place to get complete premium rulesets for Snort 2.4.0 through Current!


----------------------------------------------------
Matt Jonkman
Emerging Threats Pro
Open Information Security Foundation (OISF)
Phone 866-504-2523 x110
http://www.emergingthreatspro.com
http://www.openinfosecfoundation.org
----------------------------------------------------



More information about the Emerging-sigs mailing list