Level: Introductory IBM Tivoli staff (tivweb@us.ibm.com), Author, IBM Tivoli software
01 Jan 2003 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. This article discusses five customizable engines within WebIDS - parser, pattern, skip, trust and suspicion engines - as well as how to track and analyze WebIDS alerts.
Introduction
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.
Five Customizable Engines
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.
Parser Engine
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.
Pattern Engine
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.
Skip Engine
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:
This tells WebIDS to throw out any request that ends with “.gif”
or “.jpg”, because they cannot possibly be attacks.
Trust Engine
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.
Suspicion 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.
Summary
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.
About the author  | | | This artcile is brought to you by the IBM Tivoli staff. |
Rate this page
| 
