Often, the first indication that you've browsed a malicious site is strange behavior that shows your host has been compromised. Or worse, someone is co-opting the credentials they have harvested through the exploitation of your browser. There are ways to protect yourself of course: anti-virus, anti-spyware and personal firewalls being three of the best examples. Check out Firekeeper, a new tool for detecting and protecting against online threats, which has recently been released.
Using rules to match malicious traffic
Firekeeper integrates with the Firefox browser and monitors your browsing. It intervenes if it detects malicious traffic. Firekeeper's detection engine is modelled on the popular open source intrusion detection system (IDS), Snort. Snort uses a series of rules that define the characteristics of malicious traffic, such as what protocol, ports and payload it uses. These rules often use regular expressions to detect malicious attacks.
Like Snort, Firekeeper also uses rules to match malicious traffic. Firekeeper's rules focus on incoming HTTP(S) traffic. The rules scan the headers, body and URLs of such traffic and block traffic that matches. Firekeeper can also scan HTTPS and compressed traffic, processing and determining whether the traffic under it is either decrypted or decompressed.
Firekeeper is available for Linux and Windows and is installed as a Firefox extension. You can download it from http://firekeeper.mozdev.org/installation.html. After installation, it is available as a menu option on the Tools menu. Firekeeper can be enabled and disabled from this interface, and rules may be added, changed and deleted.
Rule files can be installed locally or downloaded from a remote URL. This use of remote files allows you to define an enterprise-wide set of rules that all of your host's browsers can download and act upon. Three default rule files come with Firekeeper -- whitelist, blacklist and default. The whitelist and blacklist files contain URLs which you have whitelisted or blacklisted. The default file contains the rules that come with Firekeeper.
Responding to malicious activity alerts
So what happens when Firekeeper detects what it believes to be malicious activity? When this occurs, Firekeeper generates an alert and prompts you to take one of four actions: Block Once, Allow Once, Blacklist and Whitelist. The Block Once and Allow Once either interrupt or allow, respectively, the processing of the HTTP or HTTPS response that caused the alert for that alert only. If you return to the page and malicious activity is detected again, then a further alert will be generated.
The Blacklist and Whitelist actions allow you to take more permanent action. Blacklisting interrupts the HTTP(S) processing and adds the URL to the Blacklist rule file. Whitelisting allows the response and adds the URL to the Whitelist rules file. In both cases, if you return to that site, then the response is remembered and the malicious activity is either blocked or allowed without an alert being generated. You can also use the rule management functions, available under the Tools menu, to manage your blacklists and whitelists by editing, removing or manually adding sites to either list.
Rule headers and rule payloads for Firekeeper
As discussed, Firekeeper rules are very much like Snort rules, but with a simpler format. Indeed, if you have a good working knowledge of Snort rules, then creating rules for Firekeeper should be easy and quick. The rules are broken into two sections, a rule header and a rule payload. Let's look at a typical rule:
alert (msg:"Outlook EML access"; url_content:".eml"; nocase; url_re:"/\.eml$/i"; reference:nessus,10767; fid:1233; rev:11;)
The rule headers tell Firekeeper what action to take when a rule is triggered. There are three types of rule headers -- alert, drop and pass. An alert rule will generate an alert when triggered, prompting the user to take one of the four actions described above. A drop rule cancels the activity that triggered the rule, without generating an alert. Finally, the pass rule allows the activity that triggered the rule, again without generating an alert.
After the rule header, the rule payload defines the characteristics of the activity that will trigger the rule. In the rule displayed, you can see the rule payload is contained in brackets. Each option consists of a keyword, some string (Note: If the string is content, then it is encapsulated in quotation marks.) and terminated with a semicolon. For example:
There are two types of payload options -- description and content. There are a number of content options: url_content, headers_content, body_content, url_re, headers_re and body_re. Each of these options allows you to specify content that can be searched for in the URL itself and the header and body of the HTTP response. The first three options can contain binary or alpha content and match against this. For instance, in our sample rule you can see the url_content option being used to search for the string ".eml" in the URL.
The second three options, url_re, headers_re and body_re, can make use of Perl regular expressions to find content, again in the URL, header and body. Be careful using regular expressions options since, like Snort, these options can have adverse performance impacts on the execution of your rules. Lastly, again like Snort, you can also specify the nocase option after one of the content options to indicate that the content to be matched is case insensitive. See here:
Like Snort rules, Firekeeper allows you to describe your rule. There are four description keywords - msg, reference, fid and rev. The first keyword, msg, specifies the message that is displayed in an alert when the rule is triggered. The next option, reference, allows you to specify links to further information about the malicious activity, such as a link to a CVE or BugTraq description. This keyword uses the same format as Snort's reference keyword and you can see a full explanation of how to use it in the Snort manual. The last two options, fid and rev, are the rule ID (which must be unique) and the rule version or revision. The fid is equivalent to Snort's sid keyword. The rev keyword should be incremented when a rule is changed to allow identification of rule definition changes.
Check out more Firekeeper rules.
Adding another layer of security
Firekeeper is an interesting concept and well worth investigating and potentially adding to your
arsenal of security tools. Of course, like all security controls you shouldn't deploy Firekeeper
alone. Firekeeper is another layer in the defense-in-depth model of your host. You should also
consider other controls such as anti-virus, anti-spyware and firewalls to protect your host. You
should also ensure you keep up to date with the latest patches and fixes for your software.
This was first published in May 2007