FSM based Algorithms for IDS Design:
An Active Discrete Event System Approach to
Intrusion Detection System for ARP Attacks
Company
LOGO
Agenda
Outline
•Overview of IDSs
•Address Resolution Protocol (ARP)
•Overview
•Security issues in ARP
•Existing ARP Attack Detection Mechanisms and Motivation
•Active Discrete Event Systems (DES)
•FDD theory of DES for Detecting ARP attacks
•Modeling and Attack Detection
What is IDS?
Intrusion

A set of actions aimed to compromise the
security goals, namely
 Integrity, confidentiality, or availability, of a
computing and networking resource
Intrusion detection

The process of identifying and responding
to intrusion activities
IDS: Taxonomy
Location of Deployment

Host based
• Monitor Computer Processes
•
•
•
•

File Integrity Checkers (system files, checksum e.g. hash value)
Log File Analysis (attack s are encoded in terms of regular exp.)
Statistical Approach (session duration, CPU uses, no. of files open)
System Call Monitoring (any deviation is compared with normal
seq.)
Network based
 Monitor Network Traffic
 Packet Signatures
 Anomalous Activity
IDS: Taxonomy
Detection Methodology

Signature based
• Detects known attacks whose syntax and
behavior is known
• Can not detects new or novel attacks
• Generate large number of False Positive Alarms
Signature based Misuse Detection
pattern
matching
Intrusion
Patterns
intrusion
activities
Example: if (src_ip == dst_ip) then “land attack”
alert ip any any − > any any (msg : ”BAD TRAFFIC sameSRC/DST”; sameip;
reference : cve,CVE−1999−0016; url,www.cert.org/advisories/CA−1997−28.html;
classtype : bad − unknown; sid : 527; rev : 3; )
IDS: Taxonomy
Detection Methodology

Anomaly based
• Can detects both known and unknown attacks
• Create normal (and/or attack) profile from
training data set
• Require pure training dataset for profile
generation
• Network packets are classified as Normal and
Anomalous based on the profile
• Detects patterns that do not confirm expected
or normal behavior
• Generate large number of False Positive Alarms
Anomaly Based Detection
activity
measures
90
80
70
60
50
40
30
20
10
0
probable
intrusion
normal profile
abnormal
CPU
Process
Size
IDS: Taxonomy
Detection Methodology

Event based
• Detects known attacks for which a signature
can not be generated
• These attacks do not change the syntax and
sequence of network traffic under normal and
compromised situation
• Detection is through monitoring the difference
in sequence of events (i.e. network packets)
under normal and compromised situations
Agenda
What is ARP?
 Address Resolution Protocol maps IP address to MAC address
Purpose of ARP
32-bit Internet address
ARP
RARP
48-bit Ethernet address
 ARP CACHE : IP – MAC Bindings
IP
MAC
TYPE
10.0.0.2
00:00:00:00:00:02
dynamic
Agenda
How ARP works?
 ARP Request is Broadcasted to all the hosts in LAN
Who has IP 10.0.0.2?
10.0.0.2
00:00:00:00:00:02
10.0.0.1
00:00:00:00:00:01
10.0.0.3
00:00:00:00:00:03
Agenda
How ARP works?
 Unicast Reply from concerned host
I have IP 10.0.0.2
My MAC is 00:00:00:00:00:02
10.0.0.2
00:00:00:00:00:02
10.0.0.1
00:00:00:00:00:01
10.0.0.3
00:00:00:00:00:03
Agenda
What is ARP cache?
 ARP cache : updated
10.0.0.2
00:00:00:00:00:02
10.0.0.1
00:00:00:00:00:01
IP
MAC
TYPE
10.0.0.2
00:00:00:00:00:02
dynamic
10.0.0.3
00:00:00:00:00:03
Agenda
ARP Packet
Ethernet : 1
IP : 0X800
OPCODE
1: ARP Request
2: ARP Reply
Size : 28 bytes
Agenda
Why is ARP vulnerable?
 ARP is a stateless protocol

Hosts cache all ARP replies sent to them even if they
had not sent an explicit ARP request for it.
 No mechanism to authenticate their peer
Agenda
ARP Spoofing
 Attacker sends forged ARP packets to the victim
I have IP 10.0.0.3
My MAC is 00:00:00:00:00:02
Victim
10.0.0.1
ARP Reply
10.0.0.2
00:00:00:00:00:01
00:00:00:00:00:02
IP
MAC
TYPE
10.0.0.3
00:00:00:00:00:02
dynamic
Attacker
Agenda
Man-in-the-Middle Attack
IP
MAC
TYPE
10.0.0.3
00:00:00:00:00:01
dynamic
10.0.0.2
00:00:00:00:00:02
10.0.0.1
00:00:00:00:00:01
Attacker
10.0.0.3
00:00:00:00:00:03
IP
MAC
TYPE
10.0.0.2
00:00:00:00:00:01
dynamic
EXISTING TOOLS AND TECHNIQUES
Agenda
EXISTING TOOLS AND TECHNIQUES
 Static ARP Cache entries—Fixed IP-MAC pairs

Huge administrative effort

Does not scale on a large dynamic network

One new/changed host affects all the hosts
 Port Security -- Bind switch port to specified MAC address and shut down
pot in case of change in MAC address of a transmitter IP.
 If the first packet sent has spoofed IP-MAC pair, then genuine packets
may be dropped.
Agenda
EXISTING TOOLS AND TECHNIQUES
 ARPWATCH

maintains a database with IP-MAC mappings

any change detected is reported to administrator using syslog/email
 ARP Defender

Hardware device running ARPWATCH
 ArpGuard

keeps track of a MAC-IP mappings and alerts changes and invalid
mappings
If the first packet sent has spoofed IP-MAC pair, then genuine packets
may be dropped.
Agenda
EXISTING TOOLS AND TECHNIQUES
 Signature and Anomaly based IDS

High number of false alarms
 Modifying ARP using Cryptographic Techniques

Secure-ARP - Digital Signature for authentication

Ticket-based ARP – Tickets from Ticket-issuing Agents
Calls for Replacement of entire Network Stack
Additional overhead of cryptographic calculations
Change Standard ARP
Agenda
EXISTING TOOLS
AND TECHNIQUES
 Active Spoof Detection Engine

Send TCP SYN packets to probe IP-MAC pairs

Receive SYN/ACK if port is open or RST if closed

No response => malicious host
Violation of network layering architecture
 Active Man in the Middle Attack Detector


IDS finds Systems with IP forwarding enabled
Spoof the ARP cache of all such systems: Now all traffic forwarded
by such systems reach IDS
Additional network Traffic
Difficulty in poisoning ARP cache of the attacker
Motivation: What
is Required in an IDS for
Agenda
ARP attacks





Should not modify the standard ARP
Should generate minimal extra traffic in the network
Should not require patching, installation of extra
software in all the systems
Should detect a large set of LAN based attacks
Use a state-transition based framework with
“active” component
ARP ATTACK DETECTION
USING ACTIVE DISCRETE EVENT SYSTEM
Agenda
Assumptions of the LAN
1. Non-compromised hosts will send a response to an ARP
request within a specific interval Treq
2. IDS is running on a trusted machine with fixed IP
3. Port mirroring is enabled at the switch
The IDS has two network interfaces – one is used for data collection in the
LAN through port mirroring and the other is exclusively used for
sending/receiving ARP probes requests/replies.
Agenda
Network Architecture

Port Mirroring is enabled at the switch

E is working as IDS
IDS
Monitor Port
A
C
E
Probe Port
B
D
Attacker
Switch
Agenda
Terminology








RQP: Request Packet
RSP: Response Packet
PRQP: Probe Request
PRSP: Probe Response
IPS: Source IP
IPD: Destination IP
MACS: Source MAC
IPD: Destination MAC
 RQPIPS : Source IP address of the Request Packet (RQP)
 Similarly for all cases…..
DES model and
Failure Detection
Agenda
A DES is characterized by a discrete state space and some event driven
dynamics.
The diagnosis problem for a DES model is to determine the fault status of the
states within a finite number of observations after the occurrence of a fault
along all possible traces of the system
Simplicity of both the model and the associated algorithms.
Most of the dynamic systems can be viewed as DESs at some level of abstraction.
Signal from sensors
Process
Model
Diagnostic results
DES Model Requirements
Agenda
(in addition to Sampath et al. [6])
 Requires Timing Information
Need to note time of arrival of packets
 Size of domains of variables involved in DES modeling for IDS is very large
compared to systems usually handled by model
Model variables are also incorporated –extended automata [sekar et al.]
Active DES Model
Agenda
Agenda
Active DES Model: Transitions
Agenda
Active DES Model: Traces
Agenda
Active DES Model: Measurability
Agenda
Active DES Model: Measurability
Agenda
Active DES Model: Measurability
Agenda
Active DES Model: Controllability
Not a possible scenario
Agenda
Active DES Model: Failures
An ExampleAn Example
3
a
1
4
2
b
c
failure
5'
1'
a'
2'
b'
3'
c'
4'
d'
Agenda
Active DES Model: Fi-Diagnosable
A DES model is Fi-Diagnosable for failure Fi under a measurement
limitation if:
nFi  N s.t. [s  ( X Fi ){t  L f (G ) / s (| t | nFi  D)}]
D : u  P 1[ P( st )], final (u )  X Fi
Where,
 ( X F )  {s  L f (G ) | the last transition of s is
i
measurable and ends in a Fi state}
s
t
• trace s ends with in a failure state
• trace t is a sufficiently long continuation of trace s
• “any trace of the system that looks like st must contain a
failure state of same type as fi”
Diagnoser
Agenda
 Daignoser is represented as a directed graph O = < Z, A >
Z
set of detector states called O-states
A
set of detector transitions called O-transitions
 Each O-state z  Z comprises a subset of equivalent model states
representing uncertainty about the actual states
 Each O-transition a  A is set of equivalent model transitions
representing uncertainty about actual transition that occurs
Agenda
Fi –Diagnosability Conditions
Example (Contd..)
3
a
1
4
2
b
c
failure
5'
1'
a'
2'
b'
c'
3'
4'
d'
a7={4}
(a) Active DES Model
a6={4}
z1 a1={1,1'} z2
{a,a'}
{b,b'}
a2={2,2'}
z5
{c}
z3 a4={4'}
{c,c'}
a3={3,3'}
(b) Diagnoser for DES model (a)
a5={5'}
z4
{d'}
Active
Diagnosability
Example
(Contd..):
Active Diagnosis
3
a
1
2
b
4
c
failure
5'
1'
a'
4'
2'
b'
c'
d'
(c) Active DES Model: after trace {1',2',3'} eliminated
a7={4}
a6={4}
z1 a1={1,1'} z2
{a,a'}
{b,b'}
a2={2,2'}
z5
{c}
z3 a4={4'}
{c,c'}
(d) Diagnoser for DES model (c)
a5={5'}
z4
{d'}
Active DES forAgenda
Modeling ARP Attacks
Host
Host
B
A
C
LAN
Host
D
Host
Probe Request
Controllable Event
Supervisory
Controller
Diagnoser
IDS
All Traffic of LAN due to
Port Mirroring
Attack Detection
Active DES forAgenda
Modeling ARP Attacks
 Attacks Considered: Request Spoofing
 S = { RQP, RSP, PRQP, PRSP, failure }
 States with

no primes correspond to normal situation

single prime ( ’ ) correspond to request spoofing
 Model Variable set V = { IPS, MACS }
IPS has the domain as D1 = { x.x.x.x | x  {1, 2, · · · , 255 } }
MACS has the domain as D2 = { hh−hh−hh−hh−hh−hh | h  Hex }
 Clock variable y determines if the probe responses have arrived within
Treq time of sending the corresponding request.
Agenda
DES model: Normal Condition
5 : c
 4 : uc
s 2, s1, , ,{ y  Treq },
, 
, 
s1, s 2, RQP, , ,{IPS  RQPIPS ,
MACS  RQPMACS },{ y  0}
 1 : uc
s1
e
lur
fai
s 4, s1, , , ,
s2
2 : c
s 2, s3, PRQP,{IPS  PRQPIPD }, ,
,{ y  0}}
 3 : uc
s3
s4
s3, s4, PRSP,{IPS  PRSPIPS , MACS  PRSPMACS },{y  Treq},
, 
Agenda
DES model: Request Spoofing
s6 ', s1', , , y  Treq , , 
 '11 : uc
s3', s1', , , y  Treq , ,   '10 : uc
s1', s 2 ', RQP, , ,{IPS  RQPIPS ,
MACS  RQPMACS },{ y  0}
s 2 ', s1', , , y  Treq ,
, 
 '7 : c
s 2 ', s3', PRQP,{IPS  PRQPIPD }, ,
 '2 : c
s2'
 '1 : uc
,{ y  0}}
s1'
s3'
 '8 : uc
s3', s6 ', PRSP,{IPS  PRSPIPS , MACS !  PRSPMACS },{ y  Treq },
 '5 : uc
, 
s 7 ', s1', , , ,
, 
 '6 : uc
s6'
s7’
s6", s7", PRSP,{IPS  PRSPIPS , MACS  PRSPMACS },{ y  Treq },
, 
 '3 : uc
s4’
 '4 : uc
s5’
s3', s 4', PRSP,{IPS  PRSPIPS , MACS  PRSPMACS },{ y  Treq },
s 4 ', s5', PRSP,{IPS  PRSPIPS , MACS !  PRSPMACS },{ y  Treq },
, 
, 
s 4 ', s1', , , y  Treq , ,   '12 : uc
s5', s1', , , , , 
 '9 : uc
Agenda
Normal/Attack certain O-state
 Normal certain O-state : An O state which contains only model
states corresponding to normal situation (N-O node)
 Attack Certain O-state : An O-state which contains only model
states corresponding to attacks (Fi-certain O-node)
 Normal/Attack certain O-states denote that the current model
state estimate comprises only normal/attack states, thereby,
making a decision (Fi-uncertain O-node)
Agenda
Daignoser for ARP Spoofing Attacks
a6 :  4 , '12
a 4 :  5 , '7
a 2 :  2 ,  '2
:
a5
z6:
s1'
z3:
s3,s3'
a3 :  3 , '3
z4:
s4,s4'
a 9 :  '4
a 7 :  '5

'
a1:  1 , '1
z2:
s2,s2'
10
z1:
s1,s1'
z5:
s6'
Two Indeterminate cycles:
z1-z2 : Avoided by sending PRQP
z1-z2-z3-z4: May not be avoided, depends on response for PRQP
1. IP address of the IP-MAC pair being verified is not up
2. IP address of the IP-MAC pair being verified is that of attacker
z7:
s5'
Agenda
DES model: Request Spoofing
s6 ', s1', , , y  Treq , , 
 '11 : uc
s3', s1', , , y  Treq , ,   '10 : uc
s1', s 2 ', RQP, , ,{IPS  RQPIPS ,
MACS  RQPMACS },{ y  0}
s 2 ', s1', , , y  Treq ,
, 
 '7 : c
s 2 ', s3', PRQP,{IPS  PRQPIPD }, ,
 '2 : c
s2'
 '1 : uc
,{ y  0}}
s1'
s3'
 '8 : uc
s3', s6 ', PRSP,{IPS  PRSPIPS , MACS !  PRSPMACS },{ y  Treq },
 '5 : uc
, 
s 7 ', s1', , , ,
, 
 '6 : uc
s6'
s7’
s6", s7", PRSP,{IPS  PRSPIPS , MACS  PRSPMACS },{ y  Treq },
, 
 '3 : uc
s4’
 '4 : uc
s5’
s3', s 4', PRSP,{IPS  PRSPIPS , MACS  PRSPMACS },{ y  Treq },
s 4 ', s5', PRSP,{IPS  PRSPIPS , MACS !  PRSPMACS },{ y  Treq },
, 
, 
s 4 ', s1', , , y  Treq , ,   '12 : uc
s5', s1', , , , , 
 '9 : uc
Conclusions
Active DES based IDS for detecting ARP spoofing.
 Analyze spoofing attack scenarios which can be detected and which cannot be.
Traces required to be eliminated
(i.e., events which are to be enabled and which are not to enabled) by
the controller for attack detection were also identified.
Agenda
References
1.
Brian J. d’Auriol, Kishore Surapaneni, and Brian J. Dauriol, “A state transition model case study
for intrusion detection systems,” in International Conference on Security and Management, 2004,
pp. 186–192.
2.
G. Vigna and R. A. Kemmerer, “NetSTAT: A network-based intrusion detection approach,” in
Proceedings of the 14th Annual Computer Security Applications Conference, 1998, pp. 25–35.
3.
Kenneth L. Ingham, Anil Somayaji, John Burge, and Stephanie Forrest, “Learning DFA
representations of HTTP for protecting web applications,” Computer Networks, vol. 51, pp. 1239–
1255, 2007.
4.
R. Sekar, M. Bendre, D. Dhurjati, and P. Bollineni, “A fast automaton-based method for detecting
anomalous program behaviors,” in Proceedings of the Symposium on Security and Privacy,,
2001, pp. 144–155.
5.
V. Ramachandran and S. Nandi, “Detecting ARP spoo£ng: An active technique,” ICISS05:1st
International Conference on Information Systems Security, LNCS, vol. 3803, pp. 239–250, 2005.
6.
M. Sampath, S. Lafortune, and D. Teneketzis, “Active diagnosis of discrete-event systems,” IEEE
Transactions on Automatic Control, vol. 43, pp. 908–929, 1998.
THANK YOU