Adaptive distributed traffic control service for ddos attack mitigation l.jpg
This presentation is the property of its rightful owner.
Sponsored Links
1 / 91

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


  • 147 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

Adaptive Distributed Traffic Control Service for DDoS Attack Mitigation

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 l.jpg

Adaptive Distributed Traffic Control Service for DDoS Attack Mitigation

By

VIJAY CHAND UYYURU


Introduction and motivation l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

Reflectors Ri

Reflector 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 l.jpg

Analysis of Mitigation Mechanisms

  • There are two basic mitigation mechanisms:

  • Reactive Mitigation Strategies

  • Proactive mitigation Strategies


Reactive mitigation strategies l.jpg

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 l.jpg

Some Examples of Reactive Strategies

  • Traceback mechanisms

  • Internet Indirection Infrastructure

  • Pushback


Traceback mechanisms l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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


Service registration l.jpg

Service Registration


Service deployment l.jpg

Service Deployment


Node architecture l.jpg

Node Architecture


Actions for ddos attack mitigation l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

Thank you!

Any questions?


Apply data mining to defense in depth network security system l.jpg

Apply Data Mining to Defense-in-Depth Network Security System

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

Presented by: Terry Griffin


Introduction l.jpg

Introduction

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


Introduction32 l.jpg

Introduction

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


Introduction33 l.jpg

Introduction

  • IDS / IPS

    • Intrusion Detection / Prevention System

  • IDS

    • Packets pass through

    • Active logging

    • Signature comparisons

  • IPS

    • Alters packet data

    • Blocks packets (possibly)


Introduction34 l.jpg

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 l.jpg

Introduction

  • IDS/IPS Types

    • Misused Detection

      • Signature based

      • Snort currently has 2200+ signatures

      • Used alone can lead to > false positives


Introduction36 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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


Defense in depth architecture41 l.jpg

Defense-in-Depth Architecture


System architecture of gps l.jpg

System Architecture of GPS

Consists of 4 components:

  • Security Information Management (SIM) module

  • Global Log Server (GLS)

  • GUI

  • Global Database


System architecture of gps43 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

System Architecture of GPS

Data mining framework


System implementation and experiment results l.jpg

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 l.jpg

    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 l.jpg

    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 l.jpg

    System Implementation and Experiment Results

    Intrusion Detection Results (Detection Rate)

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


    Slide51 l.jpg

    System Implementation and Experiment Results

    Intrusion Detection Results (False Alarm Rate)

    around 1% false alarms (if remove IGMP)


    Conclusions l.jpg

    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.


    Dos seminar 2 spoofed packet attacks and detection methods l.jpg

    DoS Seminar 2Spoofed Packet Attacks and Detection Methods

    By

    Prateek Arora


    Introduction54 l.jpg

    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 l.jpg

    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 l.jpg

    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 l.jpg

    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 l.jpg

    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 l.jpg

    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 l.jpg

    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 l.jpg

    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 l.jpg

    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 l.jpg

    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 l.jpg

    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


    Summary of attack methods l.jpg

    Summary of attack methods


    Detection methods l.jpg

    Detection Methods

    • Routing-based

    • Active

      • Proactive

      • Reactive

    • Passive


    Routing based method l.jpg

    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 l.jpg

    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 l.jpg

    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 l.jpg

    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 l.jpg

    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 l.jpg

    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 l.jpg

    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 l.jpg

    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 l.jpg

    Experiments

    • Determine the validity of various spoofed-packet detection methods

    • Predictability of TTL

    • Predictability of TTL (active)

    • Predictability of ID (active)


    Experiment description passive l.jpg

    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 l.jpg

    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 l.jpg

    Results - Passive

    • Predictability measure

      • Conditional Entropy (unpredictability)

    • Values closer to zero indicate higher predictability


    Results passive79 l.jpg

    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 l.jpg

    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 l.jpg

    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 l.jpg

    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 l.jpg

    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 l.jpg

    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 l.jpg

    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 l.jpg

    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 l.jpg

    Results - Reactive

    • Preliminary only

      • Ran for 18 hours

      • 8058 probes sent

      • 218 unique addresses

        • 173 external

        • 45 internal


    Results reactive88 l.jpg

    Results - Reactive

    • TTL off by:

      • Total # probes8058 1591

      • +/- 2 or less6467 37180%

      • +/-1 or less6096 98675%

      • 0511063%


    Results reactive89 l.jpg

    Results - Reactive

    • ID off by:

      • Total # probes8058

    • OffsetCount

    • 1601

    • 257

    • 421

    • 616

    • 514

    • 711

    • 89

    • OffsetCount

    • 25673

    • 5125

    • 768 22

    • 128010


    Conclusion l.jpg

    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 l.jpg

    References

    • www.google.co.in

    • http://seclab.cs.ucdavis.edu/

    • www.cert.org

    • www.caida.com

    • http://www.uspto.gov/

    • www.cisco.com


  • Login