DTIC ADA529552: Detecting HTTP Tunneling Activities

9 Pages·0.18 MB·English

by  Defense Technical Information Center

PROCEEDINGSOFTHE2002IEEEWORKSHOPONINFORMATIONASSURANCE 1
Detecting HTTP Tunneling Activities
⁄
Daniel J. Pack$,Member, IEEE , William Streilein+, Seth Webster+, and Robert Cunningham+
Abstract|Inthispaperwepresentanovelintrusiondetectionsys- ciated with web tra–c. Lightweight tra–c parsing such
tem which makes use of behavior proflles to identify HyperText as this makes the proposed techniques appealing for real-
Transfer Protocol (HTTP) tunneling activities. Behavior proflles
time applications. The extensive use of packet features
correspond to inherent attributes of application network sessions.
Our system evaluates network behaviors at two difierent levels: a as described in our paper has not been found in existing
local multi-packet level and a session level. When suspicious behav- IDSsexceptintheworkpresentedbyPaxonandZhang[1]
ior is detected, a veriflcation module performs a detailed analysis of where they used the frequency of small packets to detect
the corresponding session data. Currently, our system detects both
the presence of interactive backdoors.
maliciousandunauthorizedHTTPtunnelingactivities. Ourexperi-
mentalresultsshowtheefiectivenessofoursystemanddemonstrate
the validity of using packet features for anomaly detection.
II. Background
Index Terms|HTTP Tunneling, Tunneling Detection, Be-
havior Proflles, Network Intrusion Detection
TosomeextentmostflrewallandIDSdevelopersareaware
of the potential for illegal HTTP tunneling. In fact, sim-
I. Introduction plesignaturematchingtechniquesfordetectingthemhave
already been incorporated into some existing flrewalls and
RECENTLY, HTTPtunnelingactivities1 havereceived IDSs. However, these techniques have the following short-
an increased amount of attention from the Intrusion comings.
Detection community. The primary reason for this is the
Forintrusiondetectionssoftwarerunningondedicatedma-
extensive use of HTTP in the Internet tra–c and thus
chines, parsing all the packet data and then searching for
the widespread potential for misuse of HTTP for tunnel-
attack signatures is computationally expensive and thus,
ing data and control. current Intrusion Detection Systems
not feasible for real-time applications. Without parsing
(IDSs), however, do not adequately detect HTTP tunnel-
the data, however, simple string matching tends to pro-
ing activities. This lack of protection against misuses of
duce high false alarm rates [2]. Furthermore, signature
the HTTP is troublesome, given its pervasiveness and the
based systems can not generalize attack patterns and fail
factthatitisallowedto(cid:176)owfreelythroughmostflrewalls.
torecognizenewtypesoftunnelingactivities[3]. Asimilar
For instance, we monitored the Internet tra–c of a large
problem exists with the flrewalls. Stateless flrewalls allow
enterprise for a one week period and found that over 40%
all HTTP tra–c to pass through them as long as allowed
ofallincomingandover90%ofalloutgoingdataconsisted
port numbers and IP addresses are appropriately specifled
of HTTP tra–c.
in access control lists. Stateful application proxies provide
Inthispaper,wedemonstratetheutilityofpacketfeatures a bit more protection by performing limited protocol veri-
todetect, identify, andverifyabnormal HTTPwebtra–c. flcationandsometimesremovingJavaandJavascriptfrom
Whenweusethetermpacket features, wemeanattributes the data stream. These proxies cannot, however, perform
extracted from a single packet or a set of packets such as detailed analysis of each packet and still keep up with the
packet size, change of packet size, or the time between the highdataratesassociatedwithwebtra–c. Unfortunately,
flrst and last packets in a connection. One advantage of studyinglimitedHTTPheaderinformationdoesnotdetect
using packet features for the detection of HTTP tunneling tunneling activities; simple signature matching techniques
is that more efiort is required on the part of the attacker cause high false alarm rates, making the techniques im-
to manipulate these aspects of the tra–c, in order to hide practical; and parsing all packet contents is computation-
unauthorized HTTP tunneling activities and attacks. An- ally too expensive. To further complicate this problem,
other important advantage of using packet features is that HTTP tunneling techniques are currently used in many
these features can easily be extracted from packet head- legitimate network activities such as streaming video and
ers without having to parse large volumes of data asso- audio[4],managementofnetworksusingremoteprocedure
callsencapsulatedinCMIPandSNMP[5],andforpassing
⁄ThisworkwasfundedbyAFIWC.Opinions,interpretations,con- intrusiondetectionalerts[6]. Forthesecommonactivities,
clusions, and recommendations are those of the authors and do not theHTTPischosenbecauseitstra–c(cid:176)owsfreelythrough
necessarilyrepresenttheviewsoftheagencyortheUSAirForce. most flrewalls.
$Department of Electrical Engineering, U.S. Air Force Academy,
CO80840,USA
+MIT Lincoln Laboratory, 244 Wood Street, Lexington, MA These same HTTP tunneling techniques, however, also
02420-9185 provide opportunities to misuse an organization’s com-
1 The HTTP tunneling is a method to establish a bi-directional puter network resources. By encapsulating their activi-
connectionbetweentwocomputersbyencapsulatingmessagesorat-
ties within HTTP tra–c, attackers are able to interact
tackswiththeHTTPprotocolforthepurposeoftunnelingthrough
flrewalls. with and control machines that would otherwise be iso-
Report Documentation Page Form Approved
OMB No. 0704-0188
Public reporting burden for the collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and
maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information,
including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington
VA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to a penalty for failing to comply with a collection of information if it

does not display a currently valid OMB control number.
1. REPORT DATE 3. DATES COVERED
2002 2. REPORT TYPE 00-00-2002 to 00-00-2002
4. TITLE AND SUBTITLE 5a. CONTRACT NUMBER
Detecting HTTP Tunneling Activities
5b. GRANT NUMBER
5c. PROGRAM ELEMENT NUMBER
6. AUTHOR(S) 5d. PROJECT NUMBER
5e. TASK NUMBER
5f. WORK UNIT NUMBER
7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 8. PERFORMING ORGANIZATION
Massachusetts Institute of Technology,Lincoln Laboratory,244 Wood REPORT NUMBER
Street,Lexington,MA,02420
9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSOR/MONITOR’S ACRONYM(S)
11. SPONSOR/MONITOR’S REPORT
NUMBER(S)
12. DISTRIBUTION/AVAILABILITY STATEMENT
Approved for public release; distribution unlimited
13. SUPPLEMENTARY NOTES
U.S. Government or Federal Rights License
14. ABSTRACT
see report
15. SUBJECT TERMS
16. SECURITY CLASSIFICATION OF: 17. LIMITATION OF 18. NUMBER 19a. NAME OF
ABSTRACT OF PAGES RESPONSIBLE PERSON
a. REPORT b. ABSTRACT c. THIS PAGE Same as 8
unclassified unclassified unclassified Report (SAR)
Standard Form 298 (Rev. 8-98)
Prescribed by ANSI Std Z39-18
2 PROCEEDINGSOFTHE2002IEEEWORKSHOPONINFORMATIONASSURANCE
Libpcap: The Libpcap library routines provide an inter-
face through which applications can obtain raw packets
from the network. The HTTP tunneling detection pro-
Internet Firewall Intranet gram uses its algorithms along with the PSplice routines
toprocesseachpacket, which wedescribelaterinthissec-
tion. The Libpcap routines, therefore, remove the details
HTTP Tunneling sliding window
Detector f1 of communications with the network interface card, allow-
Local Level ing the tunneling detection program to focus on a high
Libpcap and Analysis Module packet #
PSplice level packet feature analysis.
Session Level fn
Analysis Module
Psplice: Psplice[7]isalibraryofC++Classesandmeth-
packet #
ods that handles all the complexities of associating pack-
Session Session Session PSplice Verification Module ets into connections and keeping track of each connec-
process packets for current session tion’s status. It is composed of two separate components:
The packet parsing component of Psplice parses individ-
VeMriofidcualteion Alert Admin ual packets and provides ready access to packet internals
through the creation of packet objects. The connection
tracking component of Psplice matches incoming packets
Fig.1. SystemArchitecture
to their respective connections and tracks the state of all
connections seen. The connection tracking component is
also able to piece the data from a connection’s packets to-
lated from them behind a flrewall. Legitimate users may
gether into a seamless transcript. The HTTP detection
use HTTP tunneling without being blocked by a flrewall
system uses the Psplice library routines to keep statistics
or detected by an IDS to access unauthorized software or
onandextractedinformationfromnetworkconnectionob-
to access services from the internet in violation of their
jects.
organization’s policies or services from the Internet with-
out being blocked by a flrewall or detected by an IDS.
Local Level Analysis Module: The local level analysis
Occasionally, these individuals may inadvertently bring in
module applies a sliding window to a set of packets to
ordownloadmaliciousprogramstoanorganization’scom-
search for abnormal local activities that match any of the
puter network, but in most cases, such activities simply
anomalous behavior proflles pre-generated using training
waste available network bandwidth and lower productiv-
data. The sliding window size is deflned by the user, and
ity. A prominent example of such activity is to stream
it deflnes the number of packets considered at a time in
non-work related video segments during periods of high
the local level analysis module. The features for abnormal
network usage.
local behaviors include actual and difierential packet sizes
betweenconsecutivepacketsandthedirectionofdata(cid:176)ow.
Given the aforementioned status of current IDSs and flre-
walls regarding the HTTP tunneling, the objectives of our
Session Level Analysis Module: While the local level
work are (1) to introduce and demonstrate a novel ap-
analysismodulesearchesfordistinctivelocalbehaviors,the
proachofnetworkintrusiondetectionbycharacterizingthe
session level analysis module evaluates global connection
inherentfeaturesassociatedwithpacketlevelnetworktraf-
behaviors by examining the running average of features
flc for HTTP tunneling activities; (2) to illustrate the use
andchangingfeaturepatterns. Thefeaturesusedtodetect
of behavior proflles to capture network events; and (3) to
globalanomalousactivitiesincludeaveragesizeofpackets,
present a hierarchical system that evaluates network be-
direction of data (cid:176)ow, ratio of large to small packets, to-
haviors at difierent resolutions, detecting and classifying
tal amount of data transfer, and total number of packets
illegitimate and unauthorized HTTP tunneling activities.
exchanged.
Veriflcation Module: The veriflcation module is only
III. System Description
invoked when a suspicious activity is detected by the local
analysismoduleorthesessionanalysismodule. Currently,
The system, shown in Figure 1, contains two difierent the veriflcation process consists of parsing the transcript
packet level processing modules and one additional tran- of a connection and searching for keywords. If particular
script analysis module to detect, identify, and verify in- keywordsarefound,theveriflcationmoduleinformsanet-
teractive, scripted, and streaming sessions: the local level work administrator. To verify an attack activity, we use a
analysis module searches for local features of individual set of 29 keywords while 11 keywords are used to identify
sessionpackets,thesessionlevelanalysismoduleexamines a stream session. We plan to interface the attack veriflca-
theaverageactivitiesforanentiresessionuptothecurrent tion process with the bottleneck veriflcation algorithm [8],
time, and the veriflcation module extracts and considers a transcript analysis tool.
the contents of packets to verify the existence of HTTP
tunneling activities.
: 3
IV. Behavior Profiles
New Packet Update Connection
Status
Two important advantages exist for using behavior pro-
flles in an IDS as the basis for detecting network intru-
Perform Local Abnormal Positive Inform sions: generality and extendibility. One of most desir-
anAdn Saelysssiiosn Verify Administrator able attributes of an IDS is the ability to generalize at-
tack patterns instead of matching speciflc signatures or
Normal Negative flngerprints. In place of speciflc keyword string patterns,
our system searches for general packet level behavior pat-
Add Packet Information Psplice Yes USepsdsaioten terns. Forexample, oursystemcontainsonebehaviorpro-
to Psplice Connection Callback Transcript flle to detect interactive sessions, another one to detect
scripted attacks, and third one to detect all streaming ses-
No sions. That is, we do not have a list of difierent proflles
to detect streaming video, streaming voice, and streaming
music: one general behavior proflle covers all three ac-
tivities. Furthermore, this single behavior proflle is used
Fig.2. Flow-ChartdepictingtheprocessinvolvedindetectingHTTP
to detect streaming activities generated by four difierent
tunnelingactivities.
streaming software tools and protocols: MediaPlayer, Re-
alPlayer,QuickTime,andWinAmp. Experimentswithop-
erational data show that the same stream behavior proflle
Processing a Packet: Figure 2 shows the (cid:176)ow-chart of allowsthesystemtoflndstreamingdataproducedbyother
theprocessingpathapacketgoesthroughwithinthedetec- tools, such as the NSPlayer.
tionsystem. Whenanewpacketiscollectedbythetunnel
detection system, the detection system updates a connec- Thesecondadvantageofusingbehaviorprofllesistheabil-
tion object. If a packet does not belong to any existing ity to extend the scope of detection to other types of clan-
sessions, a new connection object is created. A connection destine activities. Our system can be extended to detect
object contains information pertaining to the source and newabnormalbehaviorsbycreatingnewbehaviorproflles.
thedestinationoftheconnection,suchasIPaddressesand We show how we generate such proflles using packet level
portnumbersas well as thenumber of packets received by features shortly. Each behavior proflle consists of a set
the client and the server, packet size, arrival time, and of programmable conditions. A proflle developer describes
the contents of each packet. Each connection object also the local behavior and global behavior of an abnormal ac-
contains information such as the running packet size aver- tivity using individual features such as the average packet
age,thetotalnumberofbytesreceivedsofar,andupdated size, total number of packets, rate of packet size changes,
transcripts for both source and destination sites. and relational attributes such as the packet ratio between
largeandsmallpacketsandthedisparitybetweenthenum-
Once an appropriate connection object has been estab- ber of packets originated from a destination and the num-
lished,thenewpacketfeaturesalongwithfeaturesderived berofpacketsinitiatedfromasource. Theabilitytodeflne
from the past n packets are analyzed by the local level new behavior proflles provides the (cid:176)exibility for adminis-
analysis module. At the same time, the session level anal- trators to easily add the detection capability for new at-
ysis module examines the set of packets seen to this point tacks once its general packet behavior is identifled.
in the connection.
We now describe the training data used to generate be-
The veriflcation module parses through the transcript and havior proflles. For normal web tra–c, we collected over
searches for a set of preselected keywords. If the veriflca- 100 Mbytes actual web tra–c data. The data is supple-
tion module flnds a tunneling activity, the appropriate in- mented with over 2 Gbytes of simulated web tra–c data
formation is sent to the system administrator. Otherwise, using the LARIAT [9] testbed. The data generated by
thepacketissenttothenextprocessingmodule. Thenext LARIAT accurately portrays actual web tra–c and pro-
processing module, shown as \Add Packet Information to videmuchneededvolumeandvarietyofnormalwebtra–c
Psplice Connection" block in the flgure, appends the cur- for training. For interactive attack sessions, seven difier-
rent packet information to an existing connection object ent attack scenarios using the GNU http tunneling pro-
if it exists or starts a new connection object The corre- gram [10] were carried out while capturing the associated
sponding session transcript is updated only if necessary networktra–c. Thesevenscenariosincludeprobingdirec-
conditions are met by the Psplice callback routine2. tory structure, copying, modifying, inserting, and moving
flles, and carrying out FTP sessions. To generate tra–c
for scripted attacks, we captured the network tra–c from
six attack scenarios generated using an HTTP tunneling
2Wecan’tsimplyaddthepacketinformationtoaconnectionevery program developed at MIT-Lincoln Laboratory. These six
timeapacketarrives,sincepacketsarriveoutoforder. scenariosincludethefollowingactivities: probingdirectory
4 PROCEEDINGSOFTHE2002IEEEWORKSHOPONINFORMATIONASSURANCE
Data Size of Packets Received by Client Data Size of Packets Received by Server
1500 700
600
Packet Size (byte)1000 Packet Size (byte)345000000
500
200
100
00 500 1000 1500Packe2ts000 2500 3000 3500 00 500 1000 1500Packe2ts000 2500 3000 3500
(a) (b)
Histogram of Packet Size Received by Client Histogram of Packet Size Received by Server
1200 2500
1000 2000
mber of Packets680000 mber of Packets1500
Nu Nu1000
400
500
200
00 500 1000 1500 00 100 200 300 400 500 600 700
Packet Size (byte) Packet Size (byte)
(c) (d)
Fig.3. Asampleofauthors’normalwebtra–c: frames(a)and(b)showthepacketsizereceivedbytheclientandtheserver,respectively;
thehistogramsforthedatainframes(a)and(b)areshowninframes(c)and(d),respectively.
structure, copying and moving flles, removing processes, tra–c shown in Figure 3 at the client side, and frame (d)
and changing flle access modes. Finally, for stream ses- shows the corresponding distribution at the server side.
sions, we collected network tra–c while using four difier- Note that distribution peaks present at packet data size 0
ent streaming software clients: Realplayer, Mediaplayer, and 1460 exist, and there is a wide spread of packet data
Quicktime (Window version), and WinAmp. Using each sizes shown in frame (c). From frame (d) we observe that
client we collected data while streaming music, audio, and thedatasizeofpacketsfromtheclienttotheserverisrela-
video. tivelysmallwiththemaximumpacketdatasizeunder700
bytes. These packet data sizes re(cid:176)ect the average amount
Creating Behavior Proflles: Currently,abehaviorpro- of data exchanged by clients and servers [11]. The exam-
flle is generated by specifying the following seven packet ple shows that, on average, the client receives an order of
features: (1) packet size, (2) number of packets (duration, magnitude more data than the server. These characteris-
sliding window size), (3) ratio between large and small tic makes intuitive sense when we consider that most web
packets, (4) data directions, (5) average packet size, (6) sessions consist of small data request packets from clients
change of packet size pattern, and (7) size of total packets and large data reply packets from servers.
received. From our experiments, we found that these fea-
tures are su–cient to distinguish abnormal HTTP session To demonstrate how anomalous behavior proflles are cre-
from a normal one. ated, we compare normal web tra–c data with data col-
lectedfrominteractiveattacksessionsandstreamsessions.
As an example, we flrst consider the case of normal web Figures4and5correspondtoaninteractiveattacksession
tra–c,showninFigure3. Thisdatawasproducedbycap- andastreammusicsessionusingtheMicrosoftMediaplyer,
turingnetworktra–cwhiletheauthorssurfedtheInternet. respectively. For each flgure, frame (a) represents the size
A total of 3217 packets were received by a client with av- of the packets received by the client during the session,
erage of 9.218 packets per session, while a total of 3071 frame (b) represents the size of the packets received by a
packets were received by a server with average of 8.799 serveroverthesamesession,frame(c)showsthehistogram
packets per session. A total of 349 sessions are included in of packet sizes corresponding to frame (a), and frame (d)
the data shown in the flgure. Average packet sizes, shown shows the histogram of packet sizes associated with frame
inFigure3frames(a)and(b),are745.964bytesand78.993 (b). Frames (e) and (f) of Figure 5 are the running aver-
bytes, respectively. The histogram in Figure 3 frame (c) ages of packet sizes at the client and at the server using
shows the distribution of packet sizes for the normal web the data shown in frames (a) and (b) of the same flgure.
: 5
Data Size of Packets Received by Client Data Size of Packets Received by Server
1 100
0.8 90
0.6 80
Packet Data Size (byte)−−0000....02442 Packet Data Size (byte)3456700000
−0.6 20
−0.8 10
−10 20 40 60 80 100 120 00 50 100 150 200 250 300 350
Packets Packets
(a) (b)
Histogram of Packet Size Received by Client Histogram of Packet Size Received by Server
120 200
180
100
160
mber of Packets6800 mber of Packets111024000
Nu Nu80
40
60
40
20
20
−060 −40 −20 0 20 40 60 00 10 20 30 40 50 60 70 80 90 100
Packet Size Packet Size
(c) (d)
Fig. 4. Interactive tunnel session: frames (a) and (b) show the packet size received by a client and a server; frames (c) and (d) represent
histogramsusingthedatashowninframes(a)and(b),respectively
For the interactive attack session, a total of 111 packets duration by the number of packets exchanged between a
were received by the client and total 329 packets were re- client and a server. Empirical results show the script ses-
ceivedbytheserver. AveragepacketsizesshowninFigure sion and normal web tra–c sessions tend to have a small
4 frames (a) and (b) are 0 bytes and 2.088 bytes, respec- number of packets exchanged per session while interactive
tively. For the streaming session, 1357 packets were re- andstreamsessionstendtohavealargenumberofpackets
ceived by the client and 834 packets were received by the exchanged.
server. Average packet sizes shown in Figure 5 frames (a)
and (b) are 609.059 bytes and 0.5072 byte, respectively. (3) Ratio of Large and Small Packets: We can use this
feature to detect both an interactive session and a stream
Using the data shown in the three flgures, we now give session. In an interactive session, one communication end
examples of how each component of a behavior proflle is usuallysendssmallsizepackets withcommandstobecar-
specifled. ried out. By collecting the number of \small" packets and
comparing it to the total number of packets being sent,
(1) Packet Size: frame (a) in Figure 4 and Frame (b) in oursystemcandetectaninteractivesession. Inabehavior
flgure 5 show a sequence of packets with zero size being proflle, a user can specify the \smallness" of a packet in
receivedatoneofthetra–cends. Whilemanyzeropackets terms of the number of bytes a packet contains. Experi-
appear in the normal web tra–c (Fig. 3 frames (a) and mentalstudyalsoshowsthatwhenastreamisinprogress,
(b)), such appearance only lasts for a \short" period of a large number of packets with a similar size tends to be
time and does not constitute an entire session as shown senttoaclientwhileasequenceofacknowledgementpack-
in the aforementioned flgure frames. This feature alone, ets are sent in response to a server. The exact packet size
of course, does not separate normal web tra–c from the varies depending on the streaming software used, but we
tunnelingtra–c,butwecanuseitasoneoftheindicators. can still exploit the pattern of same-sized packets to dis-
Anotherexamplefollows. Thesizeofpacketssentfromthe tinguish streaming session from normal web tra–c.
clienttotheserverfortheinteractivesessionindicatesthat
thepacketsizeformostpacketsissmall: thesearepackets (4) Direction: The general direction of network tra–c is
containingshortcommands. Thisfeatureisusedtodetect another distinguishing characteristic of web activity. To
interactive sessions. detect an interactive session initiated from inside a local
network,onecanobservethenumberofpacketsbeingsent
(2) Number of Packets: The system measures a session to the Internet and compare it to the number of packets
6 PROCEEDINGSOFTHE2002IEEEWORKSHOPONINFORMATIONASSURANCE
1500 Data Size of Packets Recieved by Client 450 Data Size of Packets Recieved by Server
400
350
Packet Size (byte)1000 Packet Size (byte)223050000
500 150
100
50
00 200 400 600 800 1000 1200 1400 00 100 200 300 400 500 600 700 800 900
Packets Packets
(a) (b)
1400 Histogram of Packet Size Received by Client 900 Histogram of Packet Size Received by Server
800
1200
700
Number of Packets1680000000 Number of Packets456000000
300
400
200
200 100
00 500 1000 1500 00 50 100 150 200 250 300 350 400 450
Packet Size (bytes) Packet Size (bytes)
(c) (d)
700 Average Packet Size 120 Average Packet Size
600 100
500
Number of Bytes340000 Number of Bytes6800
40
200
100 20
00 200 400 600Packet8s00 1000 1200 1400 00 100 200 300 40P0acke5t0s0 600 700 800 900
(e) (f)
Fig.5. Musicstreamsession: (a)sizeofpacketsreceivedbytheclient, (b)sizeofpacketsreceivedbytheserver, (c)histogramofdatain
frame(a),and(d)histogramofdatashowninframe(b).
received by the local machine. In a normal web session, being sent to the destination where we can see the small
a client asks for a webpage or a flle from a server and packet size. Also observe that the client is receiving a
the server then sends a relatively large amount of data long sequence of acknowledgement packets (frame (a) of
to the client, while the client acknowledges the receipt of the same flgure) from the server, which is abnormal.
the data. Thus, the total number of packets received by
the client is much larger than the total number of packets (5) Average Packet Size: This feature in conjunction with
being sent. On the other hand, for a tunneled interactive thesessionlengthcangiveaddedevidenceastowhethera
session, a client tends to send many small packets over a stream session or an interactive session is in progress. As
\long" period of time to a server and receives relatively showninFigure5frames(e)and(f),observingtheaverage
small sized packets when compared to normal web tra–c packet size over time shows that the average packet size
sessions3. Figure 4 shows the initial session where this receivedbyaclientinastreamsessionwillreachanon-zero
activity occurs. Frame (b) of this flgure shows the packets constantvaluewhiletheaveragepacketsizebeingreceived
byaserverreachesalmostzero. Foraninteractivesession,
3 A similar pattern is observed when a client posts a message to theaveragesizeofthepacketssentfromaservertoaclient
a server in a normal web session, but the difierence is the session decreasesasasessioncontinues. Thischaracteristiccanbe
durationforaninteractivesessionissigniflcantlylonger.
: 7
Type Outside IP Outside Org Num
S 207.239.241.41 winmed.westwindmedia.com 6
S 198.88.9.80 mail.alumrpi.edu 1
S 208.184.44.20 netshowc.mpo.intervu.net 1
S 64.89.104.44 abowms02.obmnet.com 7
S 63.250.208.18 wmcontent01.broadcast.com 1
S 207.46.184.73 msn.expedia.com 1
S 216.34.209.10 www.cj.com 1
S 140.177.203.60 www.wolfram.com 1
S 159.142.1.210 arpet.gov 4
Chat 63.160.183.240 chat.yahoo.com 1
OM 64.58.76.99 mail.yahoo.com 5
OM 205.188.160.121 aol.com 2
TABLEI
Summary of HTTP tunneling activities
seen in Figure 4 frame (b). Stream Session Behavior Proflle: Compared to the
normal web tra–c, streaming audio, music, or video has
(6) Change of Packet Size Pattern: In a stream session, the following distinctive behaviors: (a) the session dura-
a signiflcant change in packet size over flve consecutive tion is signiflcantly longer; (b) the number of packets with
packets is a common event. Thus, the presence of this a same size dominates the total number of packets in a
event indicates a streaming session is in progress versus session; (c)aclientsendsasustainedsequenceofacknowl-
a normal web sessions in which a large number of static edgement packets to a server; (d) a signiflcant change in
pictures or data being transferred. packet data size exists among neighboring packets in be-
tween two sequences of identical sized packets; (e) a con-
(7) Size of Total Packets Received: The amount of data
stant packet size not corresponding to the maximum al-
being received also plays an important role for detecting
lowable packet size is observed; (f) the size of packets to
abnormalactivities. Innormalwebtra–c,aclientasksfor
theserverissmaller; (g)therunningaverageofthepacket
information and a server provides the requested informa-
size to the server decreases over the duration of a session;
tion. When we compare the amount of data transferred
(h) the number of packets received by a client is always
from a client to a server and vice versa, we flnd that a
greater than the number of packets received by a server.
client receives a larger amount of data than was sent. A
clientthatsendsmoredatathanitreceivesisanindication
of tunneling activity.
V. Results and Discussion
Thesevenfeaturesarechosentodescribebehaviorproflles
after analyzing the training data. Further study is neces- In this section we present the experimental results using
say to verify whether the selected features are su–cient to real operational web tra–c of a large organization. We
detect arbitrary HTTP tunnecting activities. used 1Gbyte of network tra–c collected by sni–ng a net-
work with a 2Mbits/sec data rate. Out of the 1Gbyte of
InteractiveTunnelingSessionBehaviorProflle: Our
data, just over 60% was web tra–c. When we fed the web
systemdetectsinteractivesessionsbydetectingthefollow-
tra–c to our system, it detected the activities shown in
ingbehaviors: (a)thesizeofpacketsbeingsentbyaclient
Table 1.
(originator) is relatively small; (b) while receiving small
packets,aserversendsasequenceoflongacknowledgement In the flrst column of the table, \S" indicates activities
packets in response; and (c) the number of small packets where audio, video, music, and other data are streamed
compared to the total number of packets being sent to a to a computer of the organization and the OM stands for
server is large; (d) the duration of a session is long. interactive mail activities using mailservers outside of the
organization. A total of 38 difierent alerts were generated
Scripted Tunneling Session Behavior Proflle: Tode-
whileprocessingthedata(1hourofnettra–crepresenting
tect scripted sessions the system looks for the following
communication between the Internet and the organization
behaviors: (a) a short session with a relatively large data
during 11 to 12 AM on a weekday). Out of the 38 alerts,
transfer; (b) a sequence of acknowledgement packets from
14werefromstreamingmusic, 1wasfromstreamingradio
a server; and (c) the amount of data received by a client
broadcast,8werefrominteractivemailrelatedactivities,1
compared to the amount of data received by a server.
wasfromchattingsession,7werefromstreaminglargedata
flles, and 7 were false alarms. The sample experimental
8 PROCEEDINGSOFTHE2002IEEEWORKSHOPONINFORMATIONASSURANCE
result data cannot be used to measure the efiectiveness of
thesystembutshowsthatanumberoftunnelingactivities
aretakingplaceintheorganization. Noattacksessionwas
detected.
VI. Conclusion
Inthispaper,wepresentedanovelsystemtodetectHTTP
tunneling activities. In particular, the system uses user-
deflned behavior proflles based on packet (cid:176)ow directions,
packet sizes, large and small packet ratios, average packet
size, change of packet size pattern, connection duration,
and size of total transfer of packets. Behavior proflles are
used to detect interactive and scripted sessions as well as
streaming data over the HTTP protocol. The system con-
sistsofthreelevelsofanalysis: thelocallevelanalysismod-
ule processes a limited number of packets within a sliding
window to extract local behaviors; the session level anal-
ysis module processes all packets received for a particular
session to capture global behaviors; and the veriflcation
moduleanalyzessessiontranscriptsifeitherthelocallevel
module or the session level analysis module detects suspi-
cious activities. Application of actual operational data of
alarge organization shows theefiectivenessand validity of
the proposed system approach. We are currently working
toexpandthesystemtodetectdifierentattacksandtofuse
the veriflcation module with a transcript analysis system
to perform a detailed analysis of suspicious transcripts.
References
[1] Y.ZhangandV.Paxon,\Detectingbackdoors,"Proceedingsof
2000 USENIX Security Symposium,August2000.
[2] A. Valdes and K. Skinner, \Adaptive, model-based monitoring
forcyberattackdetection,"Proceedingsofthe2000RecentAd-
vances in Intrusion Detection Conference, Toulouse, France,
October2000.
[3] P. Porras and A. Valdes, \Live tra–c analysis of TCP/IP
gateways," Proceedings of the 1998 Internet Society’s Network
and Distributed Systems Security Symposium, Athens, Greece,
March1998.
[4] \Vividon focuses on video streaming," http://boston.bcentral.
com/boston/stories/2000/10/23/newscolumn2.html.
[5] \Using HTTP as an RPC transport," http://msdn.microsoft.
com/library/psdk/rpc/ pv-http 7h4k.htm.
[6] \ICEcapmanager,"http://www.networkice.com/products/icecap
manager.html.
[7] S.Webster,\PSplice,"Personal Communication.
[8] R.CunninghamandR.Lippmann,\Host-basedbottleneckver-
iflcatione–cientlydetectsnovelcomputerattacks,"Proceedings
of IEEE Military Communications Conference,1999.
[9] L. Rossey, R. Cunningham, D. Fred, J. Rabek, R. Lippmann,
J. Haines, and M. Zissman, \LARIAT: Lincoln adaptable real-
timeinformationassurancetestbed,"Submittedforpublication.
[10] \HTTPtunnel,"http://www.nocrew.org/software/httptunnel.html.
[11] D.Gregg,W.Blackert,D.Heinbuch,andD.Furnanage,\Ana-
lyzing denial of service attacks using theory and modeling and
simulation," Proceedings of the 2001 IEEE Workshop on In-
formation Assurance and Security, pp. 205{211, United States
MilitaryAcademy,WestPoint,NY,June2001.