Firekeeper is an "Intrusion Detection and Prevention System for Firefox. It is able to detect, block and warn the user about malicious sites. Firekeeper uses flexible rules similar to Snort ones to describe browser based attack attempts. Rules can also be used to effectively filter different kinds of unwanted content."

Looking at the ruleset, the rules are specific to browser sessions and are much more simplified than the average Snort rule. IMO, this is a very interesting idea.

I'm running it on all my win32 browsers as an additional layer of security. I did notice a bit of a load on one of my machines when browsing, but I don't know if this is the typical FF memory leak thing or the additional processing power of Snort on the backend of the browser client.

I'm surprised no one at LQ has mentioned this tool yet. I'd considered mentioning it in the FF sticky thread but didn't know if it warranted its own thread, so here it is.

Your thoughts?

What about this two lines in FAQ?

This is a really interesting extension. Have you run it on GNU/Linux yet? Does it run okay alongside NoScript? I'm not surprised it hasn't been mentioned here, as it is not very well-known. I mean, it pales in comparison to NoScript, for example. NOTE: At the time of this post, Google showed 41 sites linking to Firekeeper, and 749 linking to NoScript (1727% higher).

The default rules are default, as in standard...these are probably standard rules that come with the latest version release of the extension. The other rules lists are the ones that you can actually edit, I believe (not sure yet...I'm still playing with the options, but I believe these lists are similar to local.rules with Snort). There are 4 lists (not including the default list) and a whitelist and blacklist (probably for domains and/or IPs).

This extension has a test feature and it renders logging just as Snort does. In this case, it gives a description of the alert and captures packet sessions.

I've not used NoScript so I don't know how well the two tools compare, although I've seen a description of how NoScript is supposed to work and have seen examples of how it alerts. Firekeeper is almost exactly like Snort, if I've read correctly, and the alert payload is very similar also. Anything suspicious/malicious that has a rule created for it can be ported to Firekeeper and subsequently logged/blocked.

I am wondering how you determined that NoScript is that much better than Firekeeper. I've extreme trust in Snort, as I've used it the last 5 years in many different ways. For someone to integrate this into a browser is amazing and leverages opensource tools to a level that I've not seen before. I'll study up on NoScript, though.

I first got word of this extension when monitoring ISC's diary. I don't think the tool has actually existed all that long. In the past, I've found great reads that were popular amongst niche groups that search engines didn't track all that well. I just figured that someone here would see the reference since I assumed everyone read ISC's diary...I assumed wrong, I guess.

EDIT - one thing I notice with NoScript so far is that you definitely have to 'tune' it. It has alerted on almost every forum I've visited so far.

Cool.

Heh, that's cuz I didn't. I was just wondering if the two work well together, as in using both extensions simultaneously. They share similar goals (to lower the chance of users getting hit by exploits via Web browsing), but otherwise are completely different tools AFAICT.

Yeah, I share your amazement in this regard. I look forward to taking it for a spin once I've done some reading-up on it and stuff (and opening a test account, etc).

Well, you should feel proud that the Google search result for Firekeeper on LQ brings up this thread of yours as the only result (at the time of this post). If Firekeeper catches-on here at LQ you can take all the credit and stuff.

Yeah, one manages to tune it up to personal taste pretty quickly, though.

I've downloaded it some time ago, just never allocated time to play with it.


If there is one add-on you should install as first reflex it is NoScript.


And that is a Good Thing. Rather than take an overly broad whitelist it "learns" by asking you to make (informed) decisions if you want to trust a certain resource.


With respect to Firekeeper I think the first thing is to ask is if it is the right tool for the job and if it is, what benefits it has over other applications. Snort has a long history of improvement and I don't need to talk about its configurability, the quality of matching or the speed with which it reassembles and inspects streams. Firefox, well. The first reservation I have (one I admit should investigate further myself) is with Firefox itself. I think (and do correct me) it would not be FUD to say that Firefox itself is not without flaws, either through design or coding errors. Nor would it be incorrect I think to say that plugins can influence each other or make Firefox less stable (understatement). I still very much like the idea of one purpose tools versus integrated toolkits: plugins operate *within* Firefox and there is (at least as far as I know) no clear way to test and validate functionality like you could with for instance a standalone application like Snort. Next to that, because Snort runs as low in the stack as possible, running it inline or paired with a third party app, it allows you to block based on protocol, packet header details or payload, long before it hits anything else further up the stack. Snort has a wider scope, and in reactive mode protects not just one clients browser but the whole system.

Firekeeper uses one local and four remote URIs to load rulesets, referenced in firekeeper_prefs.js. Of these four, three are at firekeeper.mozdev.org and one at malware.com.br. Same as with Snort the malware.com.br ruleset is IMNSHO an example of how to *not* use a product which strength lies in handling fast and accurately filtering of content (using advanced matching techniques, at least in the case of Snort). This simple URI list can be fed into any hosts file, any browser that supports blocking (Opera internally, Firefox plugin), any DNS server, filtering proxy or any other "less advanced" (no disrespect) filtering tools, no need to burden a highly efficient tool with "dumb" filters (maybe that will lower your load as well). Examining the rulesets for amount of alerts, a 'grep -c ^alert' shows new_threats.fk:0 experimental.fk:3 default.rules:20 xss.fk:32 malware.fk:1240. Of the twenty rules in default.fk aprox ten are not related to GNU/Linux. One credit is that four rules are diagnostic warnings (the pass rules), that's a good Thing. Of the four rules in experimental.fk two are not related to GNU/Linux and the other two where fixed in Firefox some time ago, IIRC. The only interesting rules in my opinion are in xss.fk, but XSS is something NoScript already checks for... The rulesets at firekeeper.mozdev.org are plaintext. Loading them is not validated as far as I can see, meaning you trust everyone to not change or redirect rulesets at firekeeper.mozdev.org or muck with your firekeeper_prefs.js. Snort's rulesets are provided by Snort, the community and Bleeding (connotations of peer reviews, quality assurance, and speed of update) whereas those that Firekeeper loads are what? If a typo occurs, how would you know a rule is ineffective unless you test them all?..


So, is it the right tool for the job? I think that for one thing depends on its purpose. If you for instance can make and provide rules for recent web-based risks of any class before other tools can, then maybe it can remain in the spotlight and evolve. If it stays this way, without rule migration automation or scripts and without merging more recent rules (if any), then I doubt it.

As usual much more depends on a community supporting this than they realise...

Very good overview,unSpawn.I agree completly.

This is good.

If I said I tried every piece of security software out there, that would be an outright lie. I've done fine without NoScript so far, so either I'm extremely lucky, know what I'm doing, or a combination of both. The only reason I've installed it is to compare it against Firekeeper. I do like it and may continue to use it after my comparison.

I don't totally agree with that being a good thing, as some may add a site to a whitelist without understanding the impact of said addition. While the user may control his/her destiny, isn't there something on the backend that is determining why a site should be be added to a list? I've seen several people install unwanted software on their machines because they get into the habit of just blindly clicking things they shouldn't. I've even security-savvy guys doing this because they are sometimes in a rush. I understand the logic in adding trusted sites to whitelists but I'd thought there was more intelligence behind NoScripts.

One thing I did notice was that, when visiting one of my sites, http://wigglit.ath.cx (which has a DynDNS hostname), NoScripts alerted on 'ath.cx' and Sitemeter. Sitemeter is a javascript counter and I expected this alert, but there is nothing javascript-wise on the page that references wigglit.ath.cx. So, why is NoScript alerting? Because DNS hosting services typically battle malicious users masking their identity?

Every user is going to have certain requirements that may conflict someone else's ideal solution...such is life.

I'm only comparing the two for the sake of debating. In the end, if either works for you, that is good. I like varied solutions so that a given one may counterbalance another, and if they can be executed in conjunction with another, all the better.

And thanks for breaking down how Firekeeper operates. I have a somewhat better understanding of the tool now. While there are possible issues with who maintains the rulesets, at least they are available. I'd rather put up with those limitations since any additional security layer will lessen malcode exploitation (to some extent).

Agreed.

From your reply I get the idea I should have written things down differently. I tried to present what little information I have as objective as possible focussing on capabilities and quality, without bias (OK, prolly failed there), without "ideal solutions" or uber-strict, outrageous requirements in mind. I certainly am not trying to convince you you're better off without Firekeeper, but your reply makes me wonder what counterbalance there exists. Or, for the sake of debating, exactly *what* "additional security layer" does Firekeeper provide, when in short:
- Firekeeper is qualitatively less complete in terms of scope (protocols, header and content matching),
- Firekeeper is qualitatively less complete in terms of detection (amount, quality and availability of rules),
- Firekeeper depends on this imperfect browser,
- Firekeepers own ruleset is small,
- Firekeepers malware.co.br ruleset can be dealt with otherwise (DNS, proxy, ClamAV, .*),
- Firekeepers "remaining" XSS ruleset is being dealt with by NoScript, and
- NoScript provides coverage Firekeeper doesn't?

* BTW, since you've used Snort for that long, would you be interested in helping Firekeeper with say adding rules? Just curious.

I'm most likely going to be running both tools consecutively for quite awhile. I'm experienced enough to know that malware that use browsers as vectors will always be very prevalent. I'm also experienced enough to not let such issues hinder me (which is probably why I've not yet been compromised via browsers) when using browsers to peruse the internet. By counterbalance, I mean, what can Firekeeper detect that NoScript can't? Looking at the sigs that Firekeeper uses, it can detect quite alot more than NoScript can, but that's what sniffers do...they sniff. That's not saying that noScript is redundant. You highlighted earlier that the maintenance of the Snort sigs is a potential downfall of Firekeeper (which I believe) and that the ruleset is small (which can be remedied over time and by combining all the rulesets web-based sigs). With PCRE-enabled sigs, Snort/Firekeeper should be able pattern-match ANY traffic crossing port 80...but this is dependent upon if a rule exists to track such traffic (the same as any pattern-matching tool).

As I learn about both tools, my thoughts will probably change. It's easy to judge things that you don't understand, but I do like to learn some things on my own, because it sometimes leads to a better understanding than if someone spoonfed me.

Also, regarding helping Firekeeper with adding rules, I suppose I could but I don't typically delve into rules themselves unless I need to enhance one that exists already. I can definitely and singlehandedly deploy a dedicated Snort machine, tune it, and utilize it. I can and have created rules based on captured packets and used them in certain environments. I'd be reinventing the wheel with most of this stuff though, as Emergingthreats.net/ already exists for the purpose of tracking malware with Snort sigs.

Oh yeah...the XSS detection capability of NoScript is indeed cool and something that Snort has some issues with.

OK, nothing left to say there except one clarification. Where I asked if you (or anyone who runs Firekeeper anyway) would be interested to say add rules, I meant help the project advance by submitting *.fk rulesets, seems that's the first bandaid it needs...

Yeah, I understood what you meant. Creating rules isn't rocket science, especially with .fk rulesets...FK rules seem far less complicated than the average Snort rules. This is probably more of a conversion thing (converting Snort and EmergingThreats (ET) rules into FK rules) than anything, but looking at things so far, a lot of the 5000+ HTTP-related ET rules may not convert into FK rules very well...for one, there's PCRE to consider, which FK doesn't seem to do (no wonder, since regex may put an excessive load on a browser).

I've already considered contributing and joined their mailing group yesterday. I'm looking at the current rules now to get an understanding of the rule structure of FK rules in comparison to Snort rules. I'll most likely be asking questions to their mailing list regarding this (this is something they could actually explain in-depth on their pages in the future, maybe.)

EDIT - found this.

Last night, I did a comparison of Snort vs. FK rules and attempted to convert some ET Snort rules into Firekeeper rules.

First I grepped the ET compiled rules file for $HTTP and directed the output to another file. There are 5,000+ files that are web-based (including things such as SQL rules). From there, I began by taking a few rules and manually attempting to convert them into FK rules. I believe I was successful, but converting 5 rules took 40 minutes (while also referencing FK's knowledgebase to get a better understanding of rule syntax). I'll continue this for maybe another week then assess how things are progressing.

This is a lot more difficult than just creating a rule from scratch, as you have to assess how to transcribe the rule and still keep in mind that FK rules have some limitations (there is little focus on byte size, how many bytes into the packet the rule will scrutinize...stuff like that). Some probably won't convert at all. This isn't something that a conversion script (such as Perl) can do, either. There has to be a certain human element to determine if a rule is even a prime candidate for conversion. There's also the matter of me understanding how the Snort rule is supposed to work and ensuring the converted rule works the same way...for every rule I convert. That's not particularly good and is a LOT of work.

I took the additional (and unusual) steps of speaking to my coworkers about this and their assessment was the same: it is much better to start from the ground up and create the rules when/as needed.

5K is A LOT and I would be mad to let you take that on alone (common people, please join in). Now if you could post which version of ET you take as basis and a list of SIDs (and maybe divide them in chunks) then maybe we could make this a joint effort? I'm in favour of posting converted SIDs and rules here but if you want to keep your own URI of .fk files that's cool by me, just let me know what I can do w/o duplicating efforts, OK?