![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Administrators are often perplexed with the ever-changing security flaws that abound in web servers and associated software. For every flaw there is a potential exploit that can be used to gain unauthorized access to a system, or to simply bring it down. What to do? How to react?
WebIDS is a lightweight tool that detects malicious attacks aimed at a web server and provides the administrator with details and recommended actions as reported by industry wide security databases. As with any tool, a thorough understanding of its features and nuances is beneficial to optimize performance. In this article we will describe a few of the vast number of features provided by WebIDS. Specifically, we will focus on how WebIDS detects intrusion attempts and the recommended set of steps to safeguard against future attacks.
Unlike network-based intrusion detection systems, which listen to all the traffic on a given network, WebIDS performs its analysis on a web server's logfiles. This domain-specific approach assures that every access attempt is processed. WebIDS passes each requested URL through a series of engines, each designed to detect a different type of attack.
The parser engine looks for problems with the actual URL requests. This covers a wide variety of issues, such as empty strings, invalid date formats, or simply improperly formatted entries. While these examples may not represent attacks, they still are an indication that there is a misconfiguration or other such problem with the web server. Since this can lead to undetected attacks, it is of interest to WebIDS.
The parser engine also detects invalid or suspicious hex codes in the request string. Traditional intrusion detection systems only match off of hardcoded patterns. Attackers, in attempt to fool these programs will often mask their suspicious requests by using hex codes. For instance, an attacker wishing to execute "cmd.exe" would actually ask for "%63md.exe". The web server happily translates this, and the malicious code is executed without being detected. WebIDS not only raises an alert when it sees this type of encoding, but it also performs the translation internally so that the pattern engine can detect what the attacker is actually up to.
The pattern engine provides the bulk of WebIDS's detection capabilities, via an ever-expanding list of signatures. Signatures can represent insecure scripts, sensitive files, protected directories, or a myriad of other things- basically anything that could signal an attack is in progress. These signatures come from many sources, including public vulnerability databases, security advisories, hacking websites, or from the analysis of logfiles.
A signature in the pattern engine consists of at least 2 parts: a label and a perl regular expression. The use of regular expressions for pattern matching provides greater flexibility than static strings. For instance, a signature such as:
view[-_]source
will match on the strings "view-source" or "view_source". Far more complicated regular expressions can be concocted if you wish.
As mentioned above, many of the pattern engine's signatures come from vulnerability databases. In an effort to make an administrator's task of tracking down an attack easier, signatures can also have an associated ID. WebIDS provides IDs for both CVE (Common Vulnerabilities and Exposures) and BugTraq:
view[-_] source view-source [CVE-1999-0174] [CVE]
viewcode\.jse viewcode.jse [3715] [BugTraq]
|
The pattern engine also monitors return codes and reports on any suspicious trends. For example, if an unusual number of "Unauthorized" return codes (403) occur, an alert is raised.
The majority of requests that a web server receives are perfectly valid. This means that due to the very nature of web traffic, Web IDS will spend a great deal of time processing legitimate requests. One way to cut down on this is with the skip engine. The skip engine enables Web IDS to throw out a request before it performs any analysis on it. This improves WebIDS's efficiency. It should, however, only be used when you know that a certain pattern will always be innocuous. The only skip engine signatures that WebIDS ships with are for images:
\.gif$ gif \.jpg$ jpg |
This tells WebIDS to throw out any request that ends with “.gif” or “.jpg”, because they cannot possibly be attacks.
For an added level of granularity, the trust engine should be used. The trust engine offers similar functionality, but instead of causing requests to go un-analyzed, it cancels alerts that would otherwise be raised. This is useful in situations where we know that a certain host will not be launching attacks, but we still wish to know if it generates a large number of unauthorized requests:
[class=trustedHosts; field=host; cancels=pattern(cgi)] friendly\.computer\.fake |
Any cgi alert originating from friendly.computer.fake would be cancelled in this example, but other suspicious activity would still be detected.
The difference between the skip engine and the trust engine is subtle, but important. If you want to increase performance, use the skip engine. If you need more control, use the trust engine.
The opposite of the trust engine is the suspicion engine. This is a place to keep a black list of sorts, where the hostnames and IP address of known attackers can be stored. Anytime one of these sources makes a request, innocent or not, an alert is instantly raised. It's up to the administrator to populate this list over time, as incidences of attacks occur.
Tracking, Analyzing, and Responding to WebIDS Alerts
Now that we've taken a look at how WebIDS processes logs and generates alerts, we will examine a potential breach of security, from the moment WebIDS discovers that something is amiss, all the way to fixing the vulnerability.
Suppose that WebIDS is watching the logfile of an Apache server, and it comes across the following entry:
some.host.org - - [03/May/2002:03:42:23 +0000] "GET /webalizer HTTP/1.1" 200 345 |
WebIDS's pattern engine identifies a potential intrusion attempt when it detects the string "webalizer", matching on the following entry in the signature file:
/webalizer Webalizer [CAN-2001-0835] [CVE] |
From the logfile, Web IDS determines that not only was an attacker attempting to access a known vulnerable cgi script, but that the request was successful. It therefore generates two alerts and forwards them on to the Tivoli Enterprise Console (TEC):
Alerts on Tivoli Enterprise Console
From this view alone, we know that some.host.org attacked a web server running on the host rjanik2. Highlighting the first event and choosing "DETAILS" presents us with the attributes of the alert:
Attributes of the Alert
There a large number of attributes containing relevant information, but for the purposes of analysis we will focus on rm_NameID and rm_NameType. The field rm_NameID provides a vulnerability ID that can be used to obtain more information on the specific attack that triggered this alert. The other field, rm_NameType tells you what database to search for this information. In this particular example, we know to look in the Common Vulnerabilities and Exposures (CVE) database for CAN-2001-0835.
There are many different websites that provide access to the CVE database: for example, the ICAT Metabase hosted by the National Institute of Standards and Technology- http://icat.nist.gov/icat.cfm.
Searching for our CVE ID is an easy process, and we're soon presented with a page of information about the vulnerability, including "severity", "type", "summary", "software affected", "version numbers", and "references". The references are usually links to more details, and by examining these, you can determine what actions to take to fix the vulnerability and prevent future attacks.
For this example, we found that a patch had been issued for Webalizer, and was available for several platforms.
After applying the patch, the next step is to identify the attacker from the details of the event and add this hostname to the signatures of the suspicion engine:
[engine=suspicion; printLvl=alerts] [class=suspiciousHosts; printLvl=all] some.host.org #bad, bad host! |
Now whenever some.host.org issues any request to the web server, an alert is instantly generated and sent to the TEC console.
While the types of attacks are changing and increasing, WebIDS is constantly evolving to ensure customers are appropriately protected, by providing up to date signatures. Plus, the five customizable engines provide additional strength and flexibility to alert and defend against the mounting number of threats. Armed with a thorough understanding of the capabilities of WebIDS, an administrator has a powerful tool with which to keep malicious attackers at bay.
Table of contents
Local resources
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
