adaptive distributed traffic control service for ddos attack mitigation
Download
Skip this Video
Download Presentation
Adaptive Distributed Traffic Control Service for DDoS Attack Mitigation

Loading in 2 Seconds...

play fullscreen
1 / 91

Adaptive Distributed Traffic Control Service for DDoS Attack Mitigation - PowerPoint PPT Presentation


  • 183 Views
  • Uploaded on

Adaptive Distributed Traffic Control Service for DDoS Attack Mitigation. By VIJAY CHAND UYYURU. Introduction and Motivation. Internet attacks are rising: Frequency of reported security incidents grows exponentially 1988: 6 incidents  2003: 137‘529 incidents reported by CERT/CC

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Adaptive Distributed Traffic Control Service for DDoS Attack Mitigation' - candid


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
adaptive distributed traffic control service for ddos attack mitigation

Adaptive Distributed Traffic Control Service for DDoS Attack Mitigation

By

VIJAY CHAND UYYURU

introduction and motivation
Introduction and Motivation

Internet attacks are rising:

  • Frequency of reported security incidents grows exponentially

1988: 6 incidents  2003: 137‘529 incidents reported by CERT/CC

  • Organised crime is blackmailing owners of e-commerce web sites („pay or you will go offline“): e.g. casino, ad distribution, sport bet sites
  • New worms, viruses, trojans, and exploits announced almost daily
introduction and motivation3
Introduction and Motivation

Why?

  • More and more computers operated by security unaware users get broadband Internet access
  • Knowledge and tools for attackers abound
  • Attackers can use cheap resources (bandwidth, CPU) of thousands of compromised Internet hosts
direct ddos attack
Direct DDoS Attack

Attacker

Victim V

Masters Mi

Agents Ai

From: Xi (spoofed)

To: Master Mi

From: Xi (spoofed)

To: Agent Ai

From: Xi (spoofed)

To: Victim V

control packet

control packet

attack packet

reflector ddos attack
Reflector DDoS Attack
  • A new variant of DDoS attacks became known as DDoS “reflector” attack.
  • This attack form is especially difficult to defense against as the victim is flooded with traffic from ordinary Internet servers that were not even compromised.
  • Any server that supports a protocol which replies with a packet after it has received a request packet can be misused as a reflector without the need for a server compromise.
how ddos reflector attack works
How DDoS Reflector Attack Works
  • The agents send their packets with the spoofed address set to the victim’s address to “innocent” servers, which act as reflectors.
  • The source addresses of the actual attack packets received by the victim are not spoofed. They belong to legitimate uncompromised servers.
  • Stopping traffic from these sources will also terminate access to Internet services that the victim might reply on.
reflector ddos attack7
Reflectors RiReflector DDoS Attack

Note: Reflectors are NOT compromised. They simply answer requests.

Attacker

Victim V

Masters Mi

Agents Ai

From: Xi (spoofed)

To: Master Mi

From: Xi (spoofed)

To: Agent Ai

From: Ri

To: Victim V

From: V (spoofed)

To: Reflector Ri

control packet

attack packet

control packet

attack trigger packet

analysis of mitigation mechanisms
Analysis of Mitigation Mechanisms
  • There are two basic mitigation mechanisms:
  • Reactive Mitigation Strategies
  • Proactive mitigation Strategies
reactive mitigation strategies
Reactive Mitigation Strategies
  • Reactive schemes often proceed in three phases:
  • In the first phase, distributed monitoring components try to detect on-going DDoS attacks.
  • Once an attack is detected, the detector triggers the second phase resulting in the deployment of countermeasures.
  • In the third phase, when the DDoS attack subsides or stops, countermeasures are relieved or removed.
some examples of reactive strategies
Some Examples of Reactive Strategies
  • Traceback mechanisms
  • Internet Indirection Infrastructure
  • Pushback
traceback mechanisms
Traceback mechanisms
  • Traceback is very valuable in forensics to find the origins and may be the originator of the attack, it deals with neither detecting attacks not deploying any dipositions against ongoing attacks.
  • Traceback mechanisms play an important role in other reactive mitigation schemes to determine where countermeasures should be deployed and which filtering rules should be applied.
  • Reactive strategies involving traceback mechanisms, will yield a wrong “attack source”- the reflectors – to be identified and possibly filtered, if DDoS attacks involve reflectors.
internet indirection infrastructure i3
Internet Indirection Infrastructure(i3)
  • i3 is implemented as an overlay that is used to route a client’s packets to a trigger and from there to the server.
  • Due to performance concerns, i3 would only be used if a server were under attack. Otherwise communication could be established directly between the client and server.
  • To use i3 as a defense mechanisms, IP addresses of the attached servers are assumed to be hidden from the attackers. It remains unclear how server IP addresses can be hidden under attack, when they are known under normal operation.
pushback
Pushback
  • Pushback performs monitoring by observing packet drop statistics in individual routers.
  • Once a link becomes overloaded to a certain degree, the pushback logic, which is co-located with routers, classifies dropped packets according to source addresses. The class of source addresses with the highest dropped packet count is then considered to originate form the attacker.
  • Filter rules to rate limit packets from the identified source address(es) are automatically installed on the concerned router. Routers on the path towards the source(s) of attack are informed about the detected attacks and install the same rules. In this way, the attack is pushed back and confined.
  • In many cases, however, an attacked server’s resources are exhausted before its uplink is overloaded.
proactive mitigation strategies
Proactive mitigation Strategies
  • Proactive strategies intend to reduce the possibility of successful DDoS attacks by taking appropriate provisions prior to attack. Some of the strategies are:
  • Ingress Filtering
  • Secure Overlay networks
ingress filtering
Ingress Filtering
  • Ingress filtering rejects packets with spoofed source address at the ingress of a network. (e.g. ISP’s backbone)
  • Attacks involving reflectors with legitimate source addresses, however, are only affected if ingress routing is applied on paths between agents and reflectors.
  • Performing ingress filtering puts a management burden on ISPs, because they must keep all filtering rules up to date and defective rules will disgruntle their customers.
secure overlay networks
Secure Overlay networks
  • Secure overlay networks like SOS and Mayday reduce the risk that a DDoS attack severely affects the communication among members of the overlay network to a minimum.
  • It requires each user of a group wanting to communicate to pre-establish a trust relationship with the other group members.
  • Keeping malicious users out of an overlay will be a challenge for a large user base.
mitigation effectiveness
Mitigation Effectiveness
  • DDoS attacks are so hard to control because of the fact that attack traffic generally contains spoofed source addresses.
  • In DDoS reflector attacks this is even more complex, because the victim does not receive traffic from the DDoS agents directly, but from legitimate sources without spoofed source addresses.
  • If source spoofing was impossible, reflector attacks could be prevented.
  • Also complex traceback mechanisms would not be needed, because the originator could be identified by the source address in those packets.
mitigation effectiveness18
Mitigation Effectiveness
  • Making source address spoofing impossible requires proactive mechanisms, since measures have to be taken before an attack.
  • They may be implemented directly in the IP network or as an overlay network. More effective defense strategies are possible within the IP network.
  • Performing Ingress Filtering, a single router is capable of blocking traffic from a big number of malicious nodes.
  • ISPs currently lack any incentive to implement proactive mechanisms.
distributed traffic control concepts and approach
Distributed Traffic Control: Concepts and Approach

Definition of traffic ownership:

A network data packet is „owned“ by the network user who is officially registered to hold either the source or destination IP address or both.

 The server operator „owns“ the traffic his server S will finally receive (to: S)

 The user of client C „owns“ the traffic sent until it reaches its destination (from : C)

Approach:

 We extend the network user‘s control over „his traffic“ to the Internet core (and right to the attacker‘s uplink) by a novel distributed Internet traffic control service.

to:server S

from:client C

payload

IP packet:

adaptive device for traffic control
Adaptive Device for Traffic Control

Idea: Let each IP address owner control his/her Internet traffic

Implementation: Adaptive devices to filter/process IP owner’s traffic

 Premium service mostly for e-business companies; few packets are rerouted through adaptive device

This path only taken by user‘s own packets

deployment of traffic control service
Deployment of Traffic Control Service

ISP … Internet/Backbone Service Provider

Incremental deployment:First at border/edge routers of major ISPs, later at most major routers

actions for ddos attack mitigation
Actions for DDoS Attack Mitigation

Traffic processing triggered by matching IP packet header fields (source/dest

address, ports etc.), payload, timing and link load conditions etc.:

  • Packet dropping
  • Payload deletion
  • Source blacklisting
  • Traffic rate control
  • Ingress filtering for owned IP addresses:  Stops DDoS reflector attacks immediately
  • Reactive and proactive
  • Filtering close to source of attack traffic
  • Coordinated Internet wide attack defence

IP packet„from: S“

S

A

Internet

IP packetfrom: S

B

IP packet„from: S“

ruling out misuse of traffic control
Ruling Out Misuse of Traffic Control

Restrictions on Traffic Control Service prevent misuse:

  • Traffic Ownership: Acts only on packets owned by network user

Others:

  • Addressing/Routing: No modification of source or destination addresses
  • Resource Usage: No change of time to live (TTL)
  • Traffic Amplification: No increase of packet rate and/or size
  • Traffic Processing: User-defined functionality checked at installation or run time
  • Prevention of collateral damage
  • ISPs/BSPs don‘t lose control over their network
other enabled traffic control services
Other Enabled Traffic Control Services

Traceback

  • Proactively collect packet hashes
  • Supporting network forensics
  • Locate origin of spoofed network traffic

Automated reaction to traffic anomalies

  • Suspicious increase in connection attempts from/to server or network
  • Detection of variations in address and/or port usage and spoofing attempts

Network debugging and optimization

  • Measure link delays, packet loss, quality of service
  • Optimize content distribution network

Network forensics

  • Traffic sampling at flow-level and/or packet-level for network forensics
conclusions and outlook
Conclusions and Outlook
  • Any chance of success for the Traffic Control Service?
    • Incrementally deployable
      • Add-on box
      • Function may be integrated into future routers
      • Not necessary to have complete coverage on all routers
    • Premium (paid) service for large customers (not home users!)
    • Business incentive for network service providers
  • Were issue’s of Internet Service Providers respected?
    • Approach not “scary” for ISPs: Safe, scalable, controllable
    • Ever changing shape of DDoS attack threat needs adaptive solution
    • Technology is not disruptive
  • International patent application filed (PCT/CH2004/000631)
  • Prototype implementation underway
thank you
Thank you!

Any questions?

apply data mining to defense in depth network security system
Apply Data Mining to Defense-in-Depth Network Security System

Written by: Huang, Kao, Hun, Jai, Lin

Presented by: Terry Griffin

introduction
Introduction

http://www.cert.org/present/cert-overview-trends/

introduction32
Introduction

http://www.cert.org/present/cert-overview-trends/

introduction33
Introduction
  • IDS / IPS
    • Intrusion Detection / Prevention System
  • IDS
    • Packets pass through
    • Active logging
    • Signature comparisons
  • IPS
    • Alters packet data
    • Blocks packets (possibly)
introduction34
Introduction
  • IDS/IPS Types
    • Misused Detection
      • Signature based
      • Identifies patterns of traffic or application data presumed to be malicious
      • presumed to be able to detect only 'known' attacks
      • However, sometimes detect new attacks which share characteristics with old attacks, e.g., accessing 'cmd.exe' via a HTTP GET request.
introduction35
Introduction
  • IDS/IPS Types
    • Misused Detection
      • Signature based
      • Snort currently has 2200+ signatures
      • Used alone can lead to > false positives
introduction36
Introduction
  • IDS/IPS Types
    • Anomaly Detection
      • notify operators of traffic or application content presumed to be different from 'normal' activity on the network or host
      • Typically use “self learning”
      • Require a training phase.
      • Observes “Normal Flow”
      • Normal is relative (set by administrator).
      • Any deviation from normal results in an alert
introduction37
Introduction
  • This paper attempts to:
    • Incorporate data mining within an IDS/IPS
    • Obtain real time Dos Alerts
    • Decrease number of False Alarms
defense in depth architecture
Defense-in-Depth Architecture

The Security Architecture is based on 2 concepts / components:

  • LPS – Local Policy Server
  • GPS – Global Policy Server
defense in depth architecture39
Defense-in-Depth Architecture

LPS – Local Policy Server

  • contains a signature database
  • logs all packets
  • somewhat of a local IDS/IPS
defense in depth architecture40
Defense-in-Depth Architecture

GPS – Global Policy Server

  • Receives logs from LPS’s
  • Monitors/Controls LPS’s
  • Does the “Real Time” data mining 
  • Can shut down / throttle the LANs
system architecture of gps
System Architecture of GPS

Consists of 4 components:

  • Security Information Management (SIM) module
  • Global Log Server (GLS)
  • GUI
  • Global Database
system architecture of gps43
System Architecture of GPS
  • Security Information Management (SIM) module
    • Does the actual data mining
    • Details in next section
  • Global Log Server (GLS)
    • Manages all logs from the LPS
    • Must handle multiple parallel incoming connections
    • Does no mining, just logging
system architecture of gps44
System Architecture of GPS
  • Gui
    • Well... it’s a GUI
  • Global Database
    • Signature database
    • Created through the logs received from the GLS
system architecture of gps45
System Architecture of GPS

Sim Module has 4 components

  • Online Data Miner
    • classifies records in active database
  • Rules Tuner
    • runs the machine learning algorithms
    • tunes the parameters of rules accordingly
  • GLS
  • Policy Dispatcher
    • Waits for commands from online miner
system architecture of gps46
System Architecture of GPS

Data mining framework

system implementation and experiment results
System Implementation and Experiment Results

Data flow of online detecting phase is separated into 3 stages:

    • Loading
      • all drivers are loaded
      • classifiers loaded and initialized
    • Monitoring
      • endless loop monitoring logged packets for signatures
    • Event Handling
      • Alerts LPS’s
      • Controls / Throttles them if necessary
  • Author used IDS Snort and IPS NetKeeper as the IDS/IPS backend.
system implementation and experiment results48
System Implementation and Experiment Results

Data Collection Results

  • For 18 days NetKeeper detected 886,764 events.
  • For 5 days Snort logged 11,070 events

This was the data used to test the system.

slide49
System Implementation and Experiment Results

The system was tested with the following 4 combinations of events:

  • Single type

(SYN Flooding, TCP Flooding, UDP Flooding / Smurfing, IP Flooding, ICMP Flooding / Smurfing, IGMP Flooding)

  • Mix – 2

(TCP-SYN, TCP-IP,TCP-ICMP, TCP-IGMP, TCP-UDP, UDP-IP,

UDP-ICMP,UDP-IGMP, IP-SYN, IP-ICMP, IP-IGMP, ICMP-IGMP)

  • Mix – 3

(TCP-SYN-IP, TCP-SYN-UDP,SYN-UDP-IP, SYN-IP-ICMP, UDP-ICMP-IP)

  • Mix – 4

(SYN-TCP-ICMP-IP,SYN-TCP-UDP-IP, TCP-UDP-ICMP-IP)

slide50
System Implementation and Experiment Results

Intrusion Detection Results (Detection Rate)

95% detection rate which is “really good” (quote from author)

slide51
System Implementation and Experiment Results

Intrusion Detection Results (False Alarm Rate)

around 1% false alarms (if remove IGMP)

conclusions
Conclusions
  • Author never really gave detail about the real time system.
  • Really just wrote a wrapper around OTB IDS/IPS systems.
  • This explains formatting problems he mentioned (I didn’t though)
  • Never explained the “retraining” or tuning phase. Whether this was online, or offline. (most important part)
  • Paper made references to figures that didn’t exist.
introduction54
Introduction
  • When a denial of service (DoS) attack occurs, a computer or a network user is unable to access resources like e-mail and the Internet. An attack can be directed at an operating system or at the network.
types of dos attacks
Types of DoS attacks
  • Ping Flood Attack (ICMP echo)
  • SYN Flood Attack (DoS attack)
  • DDoS Attack (Distributed SYN Flood)
  • UDP Flood Attacks
  • Smurf Attack
  • DNS name server Attack
  • Land Attack
  • Ping of Death Attack
  • Fragmentation / Teardrop Attack
  • Connection Spoofing
  • Bounce Scanning
  • Stealth Communication
what is a spoofed packet
What is a “Spoofed Packet”?
  • Packets sent by an attacker such that the true source is not authentic
    • MAC spoofing
    • IP packet spoofing
    • Email spoofing
  • This is not same as routing attacks
    • These cause packets to be redirected
      • e.g. DNS cache poisoning; router table attacks; ARP spoofing
significance of spoofed packets in dos attacks
Significance of “Spoofed Packets” in DoS attacks
  • Spoofed packets are a part of many attacks
    • SYN Flood Attack
    • Smurf Attack
    • Connection Spoofing
    • Bounce Scanning
    • Stealth Communication
ip tcp header review
IP/TCP Header Review

IP Header Format

version

header

length

TOS

total length

identification

flags

fragment offset

TTL

protocol

header checksum

20 bytes

source IP address

destination IP address

options (if any)

data

ip tcp header review59
U

R

G

A

C

K

P

S

H

R

S

T

S

Y

N

F

I

N

IP/TCP Header Review

TCP Header Format

source port number

destination port number

sequence number

acknowledgement number

20 bytes

header

length

reserved

window size

TCP checksum

urgent pointer

options (if any)

data (if any)

smurf attack
Smurf Attack
  • In this attack, spoofed IP packets containing ICMP Echo-Request with a source address equal to that of the attacked system and a broadcast destination address are sent to the intermediate network.
  • Sending a ICMP Echo Request to a broadcast address triggers all hosts included in the network to respond with an ICMP response packet, thus creating a large mass of packets which are routed to the victim's spoofed address.
smurf attack contd
1 SYN

Simultaneous10,000 SYN/ACKs - VICTIM IS DEAD

Smurf Attack (contd.)

ICMP echo (spoofed source address of victim) Sent to IP broadcast address

ICMP echo reply

ICMP = Internet Control

Message Protocol

INTERNET

PERPETRATOR

VICTIM

INNOCENTREFLECTOR SITES

BANDWIDTH MULTIPLICATION:

A T1 (1.54 Mbps) can easily

yield 100 MBbps of attack

SOURCE: CISCO

syn flood attack
SYN Flood Attack
  • TCP Handshake Review
    • client
      • sends SYN packet to server
      • waits for SYN-ACK from server
    • server
      • responds with SYN-ACK packet
      • waits for ACK packet from client
    • client
      • sends ACK to server

SYN

SYN-ACK

ACK

syn flood attack63
Half-open connection; Waiting for ACK

Completed handshake; connection open

empty

buffer

SYN Flood Attack

TCP Buffers

  • Attacker causes TCP buffer to be exhausted with half-open connections
  • No reply from target needed, so source may be spoofed.
  • Claimed source must not be an active host.

169.237.5.23

168.150.241.155

169.237.7.114

syn flood attack64
Half-open connection; Waiting for ACK

Completed handshake; connection open

empty

buffer

SYN Flood Attack

TCP Buffers

  • Attacker causes TCP buffer to be exhausted with half-open connections
  • No reply from target needed, so source may be spoofed.
  • Claimed source must not be an active host.

128.120.254.1

128.120.254.2

128.120.254.3

128.120.254.4

128.120.254.5

128.120.254.6

128.120.254.7

128.120.254.8

128.120.254.9

128.120.254.10

128.120.254.11

128.120.254.12

128.120.254.13

128.120.254.14

169.237.7.114

128.120.254.15

detection methods
Detection Methods
  • Routing-based
  • Active
    • Proactive
    • Reactive
  • Passive
routing based method
Routing-based Method
  • For a given network topology certain source IP addresses should never be seen
    • Internal addresses arriving on external interface
    • External addresses arriving on internal interface
    • IANA non-routable addresses on external interface
    • Other special addresses

External NIC

Internal NIC

special addresses
Special Addresses
  • 0.0.0.0/8 - Historical Broadcast
  • 10.0.0.0/8 - RFC 1918 Private Network
  • 127.0.0.0/8 - Loopback
  • 169.254.0.0/16 - Link Local Networks
  • 172.16.0.0/12 - RFC 1918 Private Network
  • 192.0.2.0/24 - TEST-NET
  • 192.168.0.0/16 - RFC 1918 Private Network
  • 240.0.0.0/5 - Class E Reserved
  • 248.0.0.0/5 - Unallocated
  • 255.255.255.255/32 - Broadcast
routing based methods
Routing-based Methods
  • Most commonly used method
    • firewalls, filtering routers
  • Relies on knowledge of network topology and routing specs.
  • Primarily used at organizational border.
  • Cannot detect many examples of spoofing
    • Externally spoofed external addresses
    • Internally spoofed internal addresses
proactive methods
Proactive methods
  • Looks for behavior that would not occur if client actually processed packet from client.
  • Method: change in IP stack behavior
  • Can observe suspicious activity
  • Examples –
    • TCP window games
    • SYN-Cookies (block with out detection)
tcp window games
TCP Window Games

SYN

ack-number

  • Modified TCP Handshake
    • client
      • sends SYN packet and ACK number to server
      • waits for SYN-ACK from server w/ matching ACK number
    • server
      • responds with SYN-ACK packet w/ initial “random” sequence number
      • Sets window size to zero
      • waits for ACK packet from client with matching sequence number
    • client
      • sends ACK to server with matching sequence number, but no data
      • Waits for ACK with window > 0
      • After receiving larger window, client sends data.

Spoofer will not see 0-len window and will send data without waiting.

SYN-ACK

seq-number, ack-number

window = 0

ACK

seq_number, ack-number

(no data)

ACK

seq-number, ack-number

window = 4096

ACK

seq_number, ack-number

w/ data

syn cookies
SYN-Cookies

SYN

ack-number

  • Modified TCP Handshake
  • Example of “stateless” handshake
    • client
      • sends SYN packet and ACK number to server
      • waits for SYN-ACK from server with matching ACK number
    • server
      • responds with SYN-ACK packet with initial SYN-cookie sequence number
      • Sequence number is cryptographically generated value based on client address, port, and time.
      • No TCP buffers are allocated
    • client
      • sends ACK to server with matching sequence number
    • server
      • If ACK is to an unopened socket, server validates returned sequence number as SYN-cookie
      • If value is reasonable, a buffer is allocated and socket is opened.

.

Spoofed packets will not consume TCP buffers

SYN-ACK

seq-number as SYN-cookie,

ack-number

NO BUFFER ALLOCATED

ACK

seq_number

ack-number+data

SYN-ACK

seq-number, ack-number

TCP BUFFER ALLOCATED

reactive methods
Reactive methods
  • When a suspicious packet is received, a probe of the source is conducted to verify if the packet was spoofed
  • May use same techniques as proactive methods
  • Example probes
    • Is TTL appropriate?
    • Is ID appropriate?
    • Is host up?
    • Change window size
passive methods
Passive Methods
  • Learn expected values for observed packets
  • When an anomalous packet is received, treat it as suspicious
  • Example values –
    • Expected TTL
    • Expected client port
    • Expected client OS idiosyncrasies
experiments
Experiments
  • Determine the validity of various spoofed-packet detection methods
  • Predictability of TTL
  • Predictability of TTL (active)
  • Predictability of ID (active)
experiment description passive
Experiment Description - Passive
  • Monitor network traffic
  • Record
    • Source IP address
    • TTL
    • Protocol
  • Count occurrences of all unique combinations
  • Statistically analyze predictability of the data
results passive
Results - Passive
  • Data collected over 2 week periods at University of California, Davis
  • 23,000,000 IP packets observed
    • 23461 source IP addresses
      • 110 internal
      • 23351 external
results passive78
Results - Passive
  • Predictability measure
    • Conditional Entropy (unpredictability)
  • Values closer to zero indicate higher predictability
results passive79
All packets

Protocol

H mean

H variance

Number Addresses

Number Packets

All

0.055759

0.029728

23461

22999999

ICMP

0.027458

0.023726

801

223341

IGMP

0

0

23

297

TCP

0.046149

0.023114

15891

20925893

UDP

0.065164

0.040655

7397

1850468

Results - Passive
results passive80
External addresses only

Protocol

H mean

H variance

Number Addresses

Number Packets

All

0.055505

0.029731

23351

9229608

ICMP

0.026159

0.023271

780

88371

IGMP

0

0

3

26

TCP

0.046324

0.023201

15825

8857983

UDP

0.065537

0.041015

7306

283228

Results - Passive
results passive81
Internal Addresses Only

Protocol

H mean

H variance

Number Addresses

Number Packets

All

0.109633

0.026097

110

13770391

ICMP

0.075714

0.03822

21

134970

IGMP

0

0

20

271

TCP

0.004189

0.000321

66

12067910

UDP

0.035207

0.010859

91

1567240

Results - Passive
results passive82
Only Addresses with more than 250 packets

Protocol

H mean

H variance

Number Addresses

Number Packets

All

0.060041

0.035521

2876

22338795

ICMP

0.035778

0.020212

33

219605

IGMP

0

0

1

0

TCP

0.051132

0.027288

2713

20332940

UDP

0.165818

0.175238

148

1779896

Results - Passive
results passive83
Only Addresses with more than 500 packets

Protocol

H mean

H variance

Number Addresses

Number Packets

All

0.050635

0.031506

2306

22140140

ICMP

0.022401

0.014516

30

218560

IGMP

0

0

1

0

TCP

0.042716

0.022273

2190

20150197

UDP

0.164326

0.209436

104

1764716

Results - Passive
results passive84
Results - Passive
  • TTL differs by protocol
  • UDP most unreliable
    • traceroute is major contributor (can be filtered)
    • certain programs set TTL anomalously
    • ToS may be useful in reducing inconsistencies
  • TTL on local network highly regular
    • must filter traceroute traffic
experiment description reactive
Experiment Description - Reactive
  • Monitor network traffic
  • Record IP address, Protocol, TTL and ID
  • Send probe packet(s)
    • ICMP echo reply packet
    • TCP syn packet
    • UDP packet
  • Note the differences between the stored TTL/ID to that of the returning probes.
results reactive
Results - Reactive
  • Evaluate –
    • initial vs. probe reply TTL
    • Initial vs. probe reply ID (delta from original)
  • Predictability measure
    • Conditional Entropy (unpredictability)
  • Values closer to zero indicate higher predictability
results reactive87
Results - Reactive
  • Preliminary only
    • Ran for 18 hours
    • 8058 probes sent
    • 218 unique addresses
      • 173 external
      • 45 internal
results reactive88
Results - Reactive
  • TTL off by:
    • Total # probes 8058 1591
    • +/- 2 or less 6467 371 80%
    • +/-1 or less 6096 986 75%
    • 0 5110 63%
results reactive89
Results - Reactive
  • ID off by:
    • Total # probes 8058
  • Offset Count
  • 1 601
  • 2 57
  • 4 21
  • 6 16
  • 5 14
  • 7 11
  • 8 9
  • Offset Count
  • 256 73
  • 512 5
  • 768 22
  • 1280 10
conclusion
Conclusion
  • Spoofed-packets used in many different attacks
  • Spoofed-packets can be detected by a number of methods
  • High predictability in TTL and ID allow use of passive and active methods
references
References
  • www.google.co.in
  • http://seclab.cs.ucdavis.edu/
  • www.cert.org
  • www.caida.com
  • http://www.uspto.gov/
  • www.cisco.com
ad