Design of a multimedia traffic classifier for Snort
Abstract
Contemporary Intrusion Detection Systems (IDS) have been facing
the challenge of monitoring increasingly higher network traffic which
may result in not all data being inspected for malicious activity. This
paper describes the design and operation of a Snort preprocessor that
adds specialized multimedia knowledge to the IDS packet analysis ca-
pabilities. Empowering the IDS with multimedia-specific knowledge
results in two significant gains: (1) trusted multimedia contents can
be identified and allowed to bypass the detection engine, thereby al-
lowing the IDS to focus on other traffic; (2) the IDS is able to detect
multimedia-specific exploits which would otherwise go by unnoticed.
The solution has been tested in both streaming and non-streaming sce-
narios. Test results confirm that this additional specialized knowledge
enhances the IDS capabilities and results in substantial computational
savings.
Keywords: Intrusion Detection Systems, multimedia security, net-
work security, Snort.
1
1 Introduction
Intrusion Detection Systems (IDS) have become valuable tools for ensuring
system and network security. IDS scan ongoing traffic in search of pat-
terns and signatures that might indicate malicious or unauthorized activ-
ity (Kemmerer and Vigna, 2002; Bace, 2000). One of the issues currently
facing network-based IDS is the high computational cost of doing real-time
analysis when a large amount of traffic is passing through a connection. In
such cases IDS usually have no choice but to skip packets (Bace, 2000). The
increase in multimedia traffic over communication networks, whether in the
form of downloading or streaming large audio and video files, or due to the
convergence of voice, data and video over IP, seems to compound the prob-
lem even further. We believe that the increase in multimedia traffic may
actually help alleviate the problem, if the IDS is aware of the main proto-
cols and file formats used to carry multimedia data and uses that knowledge
to focus its efforts on other types of traffic.
This paper focuses on the implementation aspects of a novel method
to improve the performance of IDS based on multimedia traffic classifica-
tion (Baillargeon, 2005), initially described in (Marques and Baillargeon,
2005). Under the proposed approach, the IDS has additional knowledge
about common multimedia file formats and related protocols, and uses this
knowledge to perform a more detailed analysis of packets carrying that type
of data. If the data complies with the standard format, the corresponding
stream is flagged as trusted and the remaining packets are ignored by the
IDS, which can now focus on other traffic, therefore resulting in computa-
2
tional savings. Otherwise, an anomaly is detected and reported for further
action by the system administrator.
The proposed method has been motivated by the following:
1. The amount and usage of multimedia contents has grown significantly
in recent years and will continue to increase as broadband Internet
access among home users and mobile computing technologies become
mainstream.
2. Multimedia traffic accounts for a significant percentage of the total
Internet traffic, both in terms of streaming and downloading (Guo,
Chen, Xiao and Zhang, 2005; van der Merwe, Sen and Kalmanek,
2002).
3. Multimedia traffic is usually perceived as benign, with relatively few
reports of multimedia-related security exploits so far (see Section 5).
As multimedia formats and algorithms become more complex, how-
ever, there is a greater chance that their implementation may leave
some security hole behind.
4. Increasing network bandwidth capacities create a greater workload
for IDS, which can become saturated and unable to perform its du-
ties (Bace, 2000).
3
2 Adding Multimedia Knowledge to Intrusion De-
tection Systems (IDS)
“Intrusion Detection Systems are software or hardware systems that auto-
mate the process of monitoring the events occurring in a computer system
or network, analyzing them for signs of security problems (Bace and Mell,
2001)”. With the increase in the amount and severity of network-based at-
tacks over the past few years, IDS have become an important and widely
used additional tool in the network security infrastructure of many orga-
nizations. Several tutorials, surveys and taxonomies for IDS have been
published recently, such as (Axelsson, 2000; Sherif and Dearmond, 2002;
McHugh, 2001).
The most important features of IDS are the ability to detect as many
intrusions as possible and to do so with a low rate of false alerts. While
IDS reduce the likelihood of an intrusion they cannot eliminate or prevent
it entirely (Sequeira, 2003). In fact, as pointed out by Kemmerer and Vi-
gna (2002), “IDS do not detect intrusions at all – they only identify evidence
of intrusions, either while they’re in progress or after the fact”.
Network traffic which contains multimedia content is not generally con-
sidered to be an issue which impacts the performance or detection rate of
IDS any differently than any other type of content. During the exhaustive
process of comparing hundreds or thousands of rules against the contents of
a packet, IDS typically do not apply any rules that represent multimedia-
specific knowledge.
Currently, IDS are capable of blocking multimedia content based on port
4
number (in the case of streaming audio/video), string matching of content
type (e.g., content: “User-Agent |3A| Quicktime”) and file extension. None
of these techniques verify the validity of the content; they simply assume that
if data appears to be (from external identifiers, such as MIME) multimedia,
then it is.
This scenario may soon change as a result of new, multimedia-specific,
exploits that have recently surfaced. When the PNG exploit was first discov-
ered, it was noted that existing IDS were not capable of detecting vulnerable
files because they did not have sufficient knowledge of the transfer protocols
or file formats which were being transmitted (CoreLabs, 2005). Exploits
have also been observed with streaming formats, where incomplete protocol
implementations can leave a system vulnerable to attack (US-CERT, 2005).
The work reported in this paper uses additional header information to
classify multimedia, examining the contents of an incoming data stream
and looking for known multimedia characteristics, such as JPEG or MPEG
markers. It leverages Snort’s architecture by encapsulating the multimedia-
specific knowledge into a preprocessor for Snort.
3 Snort
Snort (Snort, 2005) is a flexible, open-source, multi-platform intrusion detec-
tion solution. Snort was chosen as the base utility upon which a multimedia
classifier was built. Snort’s ability to easily add preprocessing functionality
and its open source platform were the primary factors behind its choice.
Snort’s “plug-in” functionality for preprocessor modules, which are writ-
5
Figure 1: Basic dataflow using Snort as an IDS.
ten in C, can add functionality past the base ruleset to include things like
anomaly detection and session reconstruction (Beale, 2004). Any preproces-
sor in Snort can be turned on or off simply by adding a line to a configuration
file for the program.
Snort works by matching traffic patterns to its rules, stored in a ruleset.
The process of intrusion detection within Snort begins with the capture
of packets from an Ethernet port with a tool such as Ethereal (Ethereal,
2005). The captured packets are sent through the packet decoder, which
determines which protocol is in use for a given packet and matches the data
against allowable behavior for patterns of that protocol. Then the packet
is processed by a series of preprocessors which receive packets in the order
which they are initialized in the Snort configuration file. After the packet
has gone through all of the preprocessors in sequence, it is given to the
detection engine for comparison against the ruleset. If any anomaly (e.g.,
malformed headers, overly long packets, unusual or incorrect TCP options)
is detected, an alert is generated (Figure 1).
6
4 The Multimedia Traffic Classifier
4.1 Design
The proposed solution is a two-class classifier, whereas an incoming or out-
going stream is classified either as multimedia or non-multimedia, in a way
that resembles the stream splitting idea proposed in (Judd and McEachen,
2003). Once a session is found to be containing multimedia traffic, the IDS
is able to determine if an authorization is appropriate. Authorization will
not necessarily be immediate, and may require multiple examinations of a
data stream or session to determine content validity. If a stream is deemed
to be unauthorized, normal IDS operation will continue and the data will
be analyzed according to the remaining rulesets. The ultimate goal of the
classification stage is to be able to make intelligent decisions based on pre-
viously encoded knowledge. By preprocessing and authorizing the data,
we can take advantage of Snort’s global do detect flag that tells Snort to
skip the detection phase (ruleset comparison) of the flagged packet. Since
multimedia files are usually very large, the additional time spent classifying
and flagging multimedia data using the first few packets would be offset by
the time savings throughout the remaining packets corresponding to that
stream, thereby achieving the intended performance improvements.
To accomplish the goals of multimedia traffic classification and multi-
media-specific exploit detection, a module was developed to perform packet
level preprocessing and analysis. This module, known as the multimedia
classification preprocessor, works in addition to, not as a replacement for,
the detection engine within the IDS. As network traffic is captured, it passes
7
through the multimedia classifier where it is compared against known stan-
dards to determine whether or not it meets the requirements to be trusted.
After packets are labeled as belonging to a trusted stream or session, they
bypass detailed analysis which is normally performed within the detection
engine, allowing it to focus on traffic which poses a potentially greater threat.
In addition to the rerouting of trusted traffic past the detection engine, the
multimedia-specific knowledge which has been added to the system enables
the detection of multimedia-specific exploits and administrator notification.
Figure 2 shows the dataflow within the multimedia classification pre-
processor. Each packet which enters the multimedia preprocessor is first
checked to see if it belongs to a stream or session which has already been
authorized. The packet then undergoes a series of byte-by-byte checks to
determine if it contains well-known multimedia identifiers. If such identifiers
are located, specialized rules can be applied to extract parameters or check
them for known vulnerabilities. If the packet passes the parameter extrac-
tion and exploit detection stages, it is then classified as part of a trusted
multimedia stream and assigned a flag which lets the detection engine know
that it should not be analyzed any further.
As seen in Figure 2, the multimedia classifier sits before the detection
engine, allowing specialized knowledge to be applied to the collected data
before it is passed to the detection engine for exhaustive analysis. By adding
a few extra steps to the preprocessor’s operation our classifier is able to
distinguish legitimate multimedia traffic from all other types of traffic. This
additional functionality impacts the time spent doing packet preprocessing
and inevitably introduces some overhead. As it will be demonstrated in
8
Figure 2: Modified dataflow as a result of using a multimedia classificationpreprocessor for Snort.
Section 6, the overhead is minimal and except for the case where there is
virtually no multimedia traffic, the addition of this new knowledge results
in significant overall savings.
Possible outcomes of the classification process – compared to a scenario
in which the proposed preprocessor is absent – are:
1. Data is recognized as part of a trusted multimedia stream and autho-
rized.
Result: Significant processor savings in successive packets belonging
to the same stream.
2. Data is recognized as a multimedia specific exploit, an alert is gener-
ated and the remainder of the stream bypasses the detection engine,
9
since we have already labeled it as having malicious contents.
Result: Significant processor savings and detection of malicious ac-
tivity that would otherwise go undetected.
3. Data is not multimedia in nature and continues normally through the
detection engine.
Result: Slight increase in processor usage resulting from overhead
generated by multimedia preprocessor.
4.2 Application Scenarios
4.2.1 Non-streaming (Downloading)
The non-streaming scenario can best be described by multimedia traffic
which has the following attributes:
1. All content must be entirely downloaded before playback can com-
mence.
2. There are no temporally-dependent sessions established for the trans-
mission of playback control messages or content.
3. Files can be partitioned into file header and compressed contents.
Figure 3 illustrates the impact of the proposed classifier on the analysis
of non-streaming traffic. Without the multimedia classifier, all multimedia
packets would pass through the detection engine, with each one undergo-
ing an exhaustive search for possible malicious contents. With the classi-
fier enabled, the stream is classified early by validating the file header and
ensuring it conforms to known standards. After the packet is marked as
10
Figure 3: Non-streaming packet routing with and without the proposedmultimedia classifier.
containing trusted multimedia contents, it is then searched for known mul-
timedia exploits. If no exploits are detected, the multimedia stream is given
authorization, which reroutes future packets belonging to the stream and
greatly reduces the work of the detection engine.
4.2.2 Streaming
Streaming multimedia contents are treated in a similar manner to non-
streaming once they are authorized, but the processes used to accomplish
this authorization are different. We use the streaming description for mul-
timedia traffic that has the following characteristics:
11
Figure 4: Streaming packet routing with and without the proposed multi-media classifier.
1. Session initiation, including handshaking mechanisms, is used to es-
tablish stream parameters such as transfer ports.
2. Content playback can begin as soon as a buffer has received an ade-
quate amount of data.
3. Control messages for manipulation of playback, such as the ability to
pause, may be seen during the course of a session.
After a streaming session is authorized, the classifier flags all future
packets belonging to the stream as authorized until the stream terminates.
Figure 4 illustrates the impact of the proposed classifier on the analysis of
streaming traffic, in terms of computational savings.
12
Marker Identifier Marker Acronym Marker Name0xD8 SOI Start of image0xE0 APP0 Application use marker
0xE1-0xEF APPn Other application segments0xDB DQT Quantization table0xC0 SOF0 Start of frame 00xC4 DHT Huffman table0xDA SOS Start of scan0xD9 EOI End of image0xFE COM Comments field
Table 1: JPEG markers.
4.3 Relevant Multimedia File Formats and Protocols
The multimedia classifier preprocessor handles non-streaming media formats
by examining the file headers for known multimedia markers. A representa-
tive subset of these techniques and the formats they examine are described
below.
4.3.1 JPEG
The JPEG header consists of markers which identify various parts of the
header. These markers can be identified two byte sequences which are pre-
fixed by a FF byte and followed by a byte which represents the function of
the marker. Like many other file formats, a JPEG consists of both required
and optional markers and fields. Table 1 lists JPEG markers of particular
interest for this work and the parameters they define or describe.
The multimedia preprocessor performs analysis of JPEG files in a multi-
step sequence. First, the start of frame marker is located and the length of
the SOF0 field is read. From this point, we move ahead this many positions
13
within the file, to where the Huffman table should be located. If these two
conditions are met, we can safely say that we are in the first packet of a
JPEG file, which contains the file header. Once the JPEG file is identified,
we can begin searching for signs of an exploit within the file.
4.3.2 PNG
The PNG format is based on the GIF file format, redesigned with network
transmission and storage in mind. PNG files can be analyzed by looking for
PNG chunks, which are used to organize the structure of the file.
There are four main PNG chunks, known as critical chunks, three of
which (IHDR, IDAT, IEND) are required in every PNG image. They are:
1. IHDR: Header chunk - Contains basic information about the image.
Must be the first chunk within the image.
2. PLTE: Palette chunk - Stores the colormap which is associated with
the image data. Only present if a palette is used.
3. IDAT: Image data chunk - Contains the image data. Multiple data
chunks may occur within a file and will be found in contiguous order.
4. IEND: Image trailer chunk - Marks the end of the image file.
Figure 5 displays a PNG image with chunks and image data identified.
The IDAT chunk is followed immediately by the compressed image data and
the height (0x0000001E) and width (0x00000019) values are visible just past
the IHDR chunk (0x49484452).
14
Figure 5: PNG file structure.
4.3.3 RTSP
RTSP (Real-Time Streaming Protocol) is a widely used streaming protocol,
which has been implemented in many server software packages, such as Win-
dows Media Services, Helix Servers (RealPlayer) and the Quicktime/Darwin
Streaming Servers. RTSP is used to negotiate client/server streaming ses-
sions and allows this to be done without any requirements on the payload.
The separation between session handling and transfer specification is bene-
ficial from an IDS standpoint because we can focus on analyzing the session
and exempting the payload without having to analyze it as well.
Handling of RTSP for intrusion detection purposes starts by extracting
15
the session data port numbers from the SETUP method during session initi-
ation. Once a RTSP SETUP packet has been identified and the port number
stored for future reference, the IDS looks for a RTSP PLAY request, which
asks the server to begin transferring the media stream. When a PLAY re-
quest is detected, the IDS flags all data entering through the pre-specified
port as exempted from further examination.
This process continues until the IDS detects a TEARDOWN request,
at which time the port is removed from the exemption list. Other RTSP
messages are effectively ignored within the preprocessor, because they do
not contain any information which would further improve the effectiveness
or accuracy of our session monitoring.
5 Multimedia-specific Exploits
Multimedia exploits are relatively rare, given the number of overall vulner-
abilities which have been released for all filetypes. However, in recent years
the number of these exploits has increased and may continue to increase as
more multimedia formats continue to be introduced and software utilities
for multimedia continues to be released (Microsoft, 2004, 2005a,b; Mozilla
Foundation, 2005).
The proposed multimedia classifier makes decisions after having exam-
ined only relevant bytes within the files’ headers. There are three main
reasons for this: (i) the computational overhead introduced by the multime-
dia preprocessor is kept to a minimum; (ii) all relevant multimedia-specific
exploits described later in this Section can be successfully detected within
16
Figure 6: Example of the effects of content modification (beyond headerbytes) to a JPEG image: (top) original; (bottom) modified.
the header bytes; and (iii) the damage that would be caused by one or more
modified bytes past the header is most often very limited and potentially
noticeable by the end user, as illustrated by Figure 6, which demonstrates
the possible effects of a JPEG file in which the contents (beyond the header
bytes) have been modified. Moreover, inspecting multimedia transfers for
malicious content manipulation is outside the scope of intrusion detection
and is best dealt with using digital watermarking and other authentication
techniques.
17
The following subsections will describe a few multimedia specific exploits
in greater detail.
5.1 JPEG
The JPEG exploit allows an attacker to gain control of an exploited system.
The JPEG specification allows the embedding of comments in the JPEG
file. The comment sections start with a hex value of 0xFFFE to signal the
start of the comment, followed by a two-byte value, which specifies the
length of the comment, plus two bytes (for the field itself). The two-byte
field theoretically allows 65,533 bytes of comment data (invisible when the
JPEG is viewed). If the comment field is empty, the length value must
contain the minimum length, or a value of 2. (2 bytes in length). However,
if a specially crafted JPEG file sets this length to a 0 or 1 (illegal values), it
causes a buffer overflow condition (PC Magazine, 2005).
The multimedia classification preprocessor can easily detect exploits like
this one by reading the comment field when a JPEG transfer is detected
and alerting an administrator or blocking the traffic. Figure 7 contains a
JPEG image with a comment embedded in the file header. In this case,
the comment field identifier (0xFFFE) is followed by a field length of 0x000F
(fifteen) which is valid. To turn this valid image into an exploited image, one
would simply change this value to 0x0000 (zero) or 0x0001 (one), followed
by malicious code.
18
Figure 7: JPEG structure with valid markers and image data highlighted.
5.2 PNG
One of the published PNG exploits uses especially crafted PNG chunks to
create a buffer overflow condition that allowed an attacker to gain control
of a target system. Similarly to the JPEG exploit, the end user would likely
not realize their system was compromised, because the image would still
display correctly even though there was a malformed section within the file
header.
This vulnerability is particularly dangerous when combined with MSN
Messenger, because the user does not have to request or accept an image
19
to have their system compromised. The attacker can use a PNG file as a
buddy icon, which is automatically transferred during a chat session, thereby
allowing them to gain control of the target system.
The MSN Messenger PNG vulnerability is detailed in the advisory posted
at CoreLabs (CoreLabs, 2005). This exploit is composed by placing specific
values in the IHDR and tRNS chunks of the image. The colors used and
palette used flags must be set in the color type field and the alpha channel
used flag must not be set. The color type field must have a value of 0x03
and the contents of the tRNS chunk must exceed 256 and reach a function
pointer address.
5.3 RTSP
The proposed multimedia classifier is capable of detecting RTSP buffer over-
flow issues such as the Darwin Streaming Server vulnerability that was
passed through the RTSP DESCRIBE method, which would allow an at-
tacker to execute malicious code (US-CERT, 2005). What follows is an
example of a Snort rule to handle the problem.
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 554
(msg:"WEB-MISC Real Server DESCRIBE buffer overflow attempt";
flow:to_server,established; content:"DESCRIBE"; nocase;
content:"../"; distance:1; pcre:"/^DESCRIBE\s[^\n]{300}/smi";
reference:bugtraq,8476; reference:url,
www.service.real.com/help/faq/security/rootexploit091103.html;
classtype:web-application-attack; sid:2411; rev:5;)
20
This rule works as follows:
1. Snort looks for traffic coming from any external network, on any IP
address which is inbound for an IP address defined as a HTTP server,
on port 554. Port 554 is the default port for all RTSP traffic.
2. Snort looks for the plaintext string “DESCRIBE” using the PCRE
tool (Perl Compatible Regular Expressions).
3. Snort measures the length of the contents which follow the DESCRIBE
string. If these contents are sufficiently large to cause a buffer overflow
condition, an alert is generated.
4. The alerting mechanism generates an alert to the console or inserts a
new record in a database containing a short description of the intru-
sion along with reference data so an administrator can look up more
information online.
Additional implementation details, including source code, can be found
in (Baillargeon, 2005).
6 Experiments and Results
Our approach was tested by monitoring FTP transfers of multimedia and
non-multimedia files using Snort. Experiments were performed on many
platforms to ensure interoperability and flexibility for future work. All ex-
periments had the same common goal: to measure processor usage and
evaluate the impact of adding the proposed specialized preprocessor on the
21
overall performance of the IDS. Statistics and measurements were reported
by Snort when the program was terminated.
6.1 Downloading
All Snort experimentation was done in a Windows environment, using Snort
and the WinPcap packet capture library. For measurement purposes, FTP
transfers were used to ensure that data was not being cached locally. FTP
transfers also allowed batch jobs to be scheduled, for ease of reproducing
the tests to ensure accuracy of the measurements. The classification prepro-
cessor was tested by transferring data with the preprocessor on, then again
with it turned off. Time measurements were taken in Snort, using the C++
clock() function, the unit of which is clock ticks. Division of clock ticks
by the constant CLOCKS_PER_SEC returns a value in seconds. However, in
almost all cases with the classifier on this value was less than 1 second, so
values were left in units of clock ticks.
6.1.1 Single file transfers
In the first series of experiments we looked at specific file types, one at a
time. For AVI files varying from 716 KB to 56 MB in size, a fixed number
of packets (two) per file was required to classify them as valid multimedia
data. The corresponding savings in processor usage was somewhat inversely
proportional to the file size: for small files, the processor was used only 15%
of the time it would have without our classifier, while for very large files, this
number would drop to less than 1%. Similar results were obtained for MPEG
and JPEG files between 417 KB and 67 MB in size. These experiments also
22
File Type File Size (MB) DEU OFF DEU ON MM ONAVI 257 13189 70 30AVI 10.9 640 40 10JPG 2.5 571 30 0MPG 0.4 110 20 0
Table 2: Time savings for miscellaneous downloads.
Table 2 legend:
• DEU OFF - Detection engine usage (in clock ticks) with MM classifieroff.
• DEU ON - Detection engine usage with MM classifier on.
• MM ON - MM classifier usage with MM classifier on.
confirm that the overhead introduced by adding an extra preprocessing step
is minimal – less than 1%.
Table 2 contains sample collected data, demonstrating the drastic re-
duction in overall CPU usage when the multimedia classifier was enabled.
The sum of the two last columns is (much) less than the value in the center
column for all cases.
6.1.2 Mixed traffic
The mixed traffic experiments combine multimedia and non-multimedia files
into a batch FTP job, with varying percentages of multimedia-traffic, from
0% to 100% in 20% increments. Multiple files were transferred with the mul-
timedia classification preprocessor active and then again without to evaluate
CPU utilization. Figure 8 summarizes the results, indicating that processor
usage (in clock ticks) is inversely proportional to the amount of multimedia
23
MM NONMM PMM DEU ON MM ON0 100 0 19198 2103
18.86 81.52 18.79 15279 195441.68 60.93 40.6 12230 142262.51 40.95 60.42 8227 77078.94 20.19 79.63 3966 55099.78 0 100 30 160
Table 3: Time savings for mixed traffic.
Table 3 legend:
• MM - Amount of MM traffic (MB).
• NONMM - Amount of Non-MM traffic (MB).
• PMM - Percent of multimedia traffic.
• DEU ON - Detection engine usage with MM classifier on.
• MM ON - MM classifier usage with MM classifier on.
data in the batch, thereby confirming our claim of increased CPU savings as
the amount of multimedia traffic increases. Table 3 contains raw data col-
lected from mixed traffic experiments, again illustrating a drastic reduction
in overall CPU usage when multimedia traffic is present.
6.2 Streaming
Streaming experiments were conducted using RealPlayer, QuickTime and
Windows Media Player for client-side data capture. Server software utilized
includes Darwin Streaming Server, Windows Media Services and popular
web sites such as iFilm.com for Helix RealPlayer server testing. Data was
gathered in a similar manner to the nonstreaming methods, in that the clock
usage was measured over a period of time with the multimedia preprocessor
24
Figure 8: CPU savings for multimedia traffic downloading.
PL DEU OFF DEU ON MM ON1:00 4843 50 05:00 12983 240 4010:00 24418 400 40
Table 4: Time savings for multimedia streaming.
Table 4 legend:
• PL - Playback length (minutes).
• DEU OFF - Detection engine usage with MM classifier off.
• DEU ON - Detection engine usage with MM classifier on.
• MM ON - MM classifier usage with MM classifier on.
off, and then on.
Table 4 contains representative raw data from one of these tests. This
data was gathered by initiating streams of identical bitrates for varying
25
Figure 9: Time savings for multimedia streaming.
amounts of time and recording the CPU usage of the detection engine and
multimedia classifier, as was done in previous tests. Figure 9 shows those re-
sults for a particular subset using QuickTime and Darwin Streaming server
for streams of varying duration (1, 5, and 10 minutes long). Similar re-
sults were obtained using other server/client combinations. It illustrates the
processor usage savings as playback time increases. Without multimedia
classification, the total amount of processor usage increases linearly with
time, but when the classifier is enabled the total usage increase is minimal.
7 Conclusions
We have described the design and operation of a Snort preprocessor that
adds specialized multimedia knowledge to the IDS packet analysis capabili-
ties. The fundamental idea behind the proposed method is that the addition
26
of multimedia-specific knowledge can greatly improve the efficiency of IDS,
both in terms of detection rate and resource utilization. Empowering the
IDS with multimedia-specific knowledge results in two significant gains: (1)
trusted multimedia contents can be identified and allowed to bypass the de-
tection engine, thereby allowing the IDS to focus on other traffic; (2) the
IDS is able to detect multimedia-specific exploits which would otherwise go
by unnoticed.
Although the addition of multimedia knowledge will likely increase the
overall effectiveness of IDS, there is a tradeoff between the extra CPU time
needed to perform additional analysis on multimedia traffic and the CPU
savings that ensue as a resulting of exempting subsequent packets belonging
to the same, trusted, multimedia stream. Fine-tuning of the system to find
the proper balance of analysis is required and has to be done empirically.
The proposed solution has been tested with several combinations of mul-
timedia and non-multimedia traffic, both downloading and streaming. Re-
sults of our experiments confirm that significant processing savings can be
obtained, given that there is minimally a small amount of multimedia traffic
on a network.
The proposed framework is modular and extensible, allowing a broad
coverage of different file formats and streaming protocols as well as an ad-
justable degree of specialized knowledge upon which the IDS decision is
made. Even though multimedia-specific attacks and exploits are still rela-
tively rare, the proposed solution allows for easy encoding of rules that help
detection and prevention against reported attacks as soon as they become
known, equipping it with a ‘future proofing’ capability.
27
Acknowledgment
This work was partially supported by a grant from the U.S. Department of
Defense (DoD).
References
Axelsson, S. 2000. Intrusion Detection Systems: A Survey and Taxonomy.
Technical Report 99-15 Department of Computer Engineering, Chalmers
University of Technology Goteborg, Sweden: .
Bace, R. 2000. An Introduction to Intrusion Detection and Assessment.
Technical report ICSA Labs.
Bace, R. and P. Mell. 2001. Intrusion Detection Systems. Technical report
National Institute of Standards and Technology.
Baillargeon, Pierre. 2005. A Method for Adding Multimedia Knowledge For
Improving Intrusion Detection Systems. Master’s thesis Florida Atlantic
University.
Beale, J. 2004. Snort 2.1 Intrusion Detection. Second ed. Syngress.
CoreLabs. 2005. “Core Security Technologies Advisory: MSN Messenger
PNG Image Parsing Vulnerability.” http://www.coresecurity.com/.
Ethereal. 2005. “Ethereal: a network protocol analyzer.” http://www.
ethereal.com/.
28
Guo, Lei, Songqing Chen, Zhen Xiao and Xiaodong Zhang. 2005. Analysis
of Multimedia Workloads with Implications for Internet Streaming. In
WWW2005. Chiba, Japan: .
Judd, J. and J. McEachen. 2003. An Architecture for Network Stream
Splitting in Support of Intrusion Detection. In ICICS-PCM. Singapore: .
Kemmerer, R. and G Vigna. 2002. “Intrusion Detection: A Brief History
and Overview.” IEEE Computer 35(4):27–30.
Marques, O. and P. Baillargeon. 2005. A Multimedia Traffic Classification
Scheme for Intrusion Detection Systems. In Proc. of the IEEE ICITA’05.
Sydney, Australia: .
McHugh, John. 2001. “Intrusion and intrusion detection.” International
Journal of Information Security 1(1):14–35.
Microsoft. 2004. “Microsoft Security Bulletin MS04-028: Buffer Overrun in
JPEG Processing (GDI+) Could Allow Code Execution (833987).” http:
//www.microsoft.com/technet/security/bulletin/MS04-028.mspx.
Microsoft. 2005a. “Microsoft Security Bulletin MS05-009: Vulnerability in
PNG Processing Could Allow Remote Code Execution (890261).” http:
//www.microsoft.com/technet/security/bulletin/MS05-009.mspx.
Microsoft. 2005b. “Microsoft Security Bulletin MS05-053 Vulnerabil-
ities in Graphics Rendering Engine Could Allow Code Execution
(896424).” http://www.microsoft.com/technet/security/bulletin/
MS05-053.mspx.
29
Mozilla Foundation. 2005. “Mozilla Foundation Security Advisory 2005-30:
GIF heap overflow parsing Netscape Extension 2.” http://www.mozilla.
org/security/announce/mfsa2005-30.html.
PC Magazine. 2005. “Security Watch Letter: Inside the JPEG Virus.”
http://www.pcmag.com/article2/0,1759,1661942,00.asp.
Sequeira, D. 2003. “Intrusion Prevention Systems: Security’s Silver Bullet?”
Business Communications Reviews pp. 36–41.
Sherif, Joseph S. and Tommy G. Dearmond. 2002. Intrusion Detection:
Systems and Models. In Proceedings of the IEEE WETICE02. Pittsburgh,
PA, USA: .
Snort. 2005. “Official Snort website.” http://www.snort.org/.
US-CERT. 2005. “US-CERT: United States Computer Emergency Readi-
ness Team Vulnerability Note VU460350: Apple Quicktime/Darwin
Streaming Server fails to properly parse DESCRIBE requests.” http:
//www.kb.cert.org/vuls/id/460350.
van der Merwe, Jacobus, Subhabrata Sen and Charles Kalmanek. 2002.
Streaming Video Traffic: Characterization and Network Impact. In Pro-
ceedings of the Seventh International Web Content Caching and Distribu-
tion Workshop. Boulder, CO: .
30