Firekeeper for Firefox

internetSurfer · 05-07-2008, 05:53 PM

Been using Firekeeper since the initial post.
Only errors that have been noticed was one for paypal url redirection.

Seems the rule list is getting updated from here:

http://www.malware.com.br/
http://www.malware.com.br/cgi/submit...n=list_fkeeper
http://www.malware.com.br/cgi/submit...type=agressive

_

unixfool · 05-20-2008, 10:19 PM

I emailed the lead developer:

Quote:

Hi,

I'm a security analyst by trade and found myself using Firekeeper after I read about it at isc.sans.org. I've been using Snort since 2003 at the enterprise level and at home. I was very excited when I saw that someone had integrated the engine into Firefox. I'd mentioned my findings on a security forum and was challenged to assist in beefing up your ruleset, since there are approximately 5,000 Emerging Threats Snort rules related to HTTP/S, a far cry above what Firekeeper's rule count is.

I was wondering if the dev team has a central and open (meaning I can browse through the ruleset) repository...or is what's included with Firekeeper WYSIWYG? I'd like to attempt to convert as many Emerging Threats Snort rules into Firekeeper rules as I can, but had some questions.

Following http://www.mozdev.org/pipermail/fire...ch/000033.html and your pages on Firekeeper rule syntax, I transcribed several ET rules into FK rules. Some of this was difficult, as I had to guess how Snort's 'content' tags equated into FK rules, as there are url_content, headers_content, and body_content to consider). Some examples were obvious but others required me to guess and I didn't really want to have to reference each exploit just to transcribe a rule.

I'm now finding that the transcribing of existing Snort rules can be tedious unless you are intimately familiar with the attack and/or corresponding rule.

Is anyone on the dev team looking to expand the current rulesets and if so, how is it currently being done?

--
unixfool

His response is below:

Quote:

Hi,

Yes, Firekeeper rule set is now far from being reach. I concentrate on
engine development, which, because of lack of good and easy to use
infrastructure for capturing HTTP traffic in Mozilla, is very time
consuming task. But I hope it will change in the near future (I
submitted a patch that greatly simplifies capturing browser traffic
and it now awaits Mozilla developers review). I'm currently working on
making Firekeeper work with Firefox 3.0 which turned out to be not
trivial.

I was discussing converting Emerging Threats rules with Matt Jonkman
some time ago and have scripts for this almost ready, I would like to
make this rules available after I finish work on FF 3.0 compatibility.

You are right that 100% automatic conversion is not possible. With
script that I prepared you have to write additional input file which
describes which rules to convert and what part of the response rule
should check (url, header, body).

Maybe it would be good idea to have only one type of rule that checks
body and header. I decided to distinguish this 2 types of rules from
performance reason. Firefox internally divides response into headers
and body, and it is possible to sniff them separately not as a one,
long string, it seemed like a good idea to have different rules for
theme. Yet, I haven't done any performance testing to check if there
really is significant gain from such approach.

Another problem with automatic conversion is that you still have to
have at least a general idea what the rule is doing. I haven't found
any Snort ruleset that consist only of rules that make sense in the
browser context. Emerging Threats HTTP rules do not only describe
attacks against client but also HTTP server. It does not make much
sense to include such rules in Firekeeper. Expect, if you want to
check if the page you are visiting does not try to exploit some
server vulnerability, which may be useful info but is not an attack
against the client.

Cheers,
Jan

So, a first step may be to determine what Snort rules focus on browser clients then convert those. This may be as trivial as grepping for the rules' flow state (maybe look for inbound flows). I'll look more into this tomorrow.

I don't even know if its worthwhile to continue this endeavor since the maintainer stated he is considering changing the rule structure, although he has testing to do and he probably won't start his testing until after he's done with FF 3.0 compatibility.

unSpawn · 05-21-2008, 05:59 AM

Good to see you sink your teeth into this. If I "^alert.tcp.*EXT.*HTTP.*HOME_NET" ET's emerging-all.rules and leave out the "(microsoft|windows|win32|explorer|wmf|activex|msie|vbscript|com.object|to_server)" and the "ET.(EXPLOIT.(IE|MS)|INAPPROPRIATE)" I end up with fiftyfive SIDs to consider: 2008206 2001447 2002773 2000520 2001533 2000581 2001335 2001317 2007806 2001959 2001960 2001066 2003296 2007669 2001921 2006396 2006399 2007576 2008065 2007670 2007671 2001188 2003326 2003327 2007878 2002889 2008129 2001811 2008062 2003173 2003174 2001101 2001103 2001105 2001106 2001095 2001190 2001191 2001192 2001195 2001058 2003207 2001668 2002174 2001807 2002127 2002128 2002380 2003415 2003400 2002381 2001549 2002786 2002787 2007932.