Detecting and mitigating dos attack in a network
Sponsored Links
This presentation is the property of its rightful owner.
1 / 41

Detecting and Mitigating DoS Attack in a Network PowerPoint PPT Presentation


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

Detecting and Mitigating DoS Attack in a Network. Cisco Systems. Agenda. DDoS Reality Check Detecting Tracing Mitigation Protecting the Infrastructure. Z. Z. Z. Z. Z. Z. Z. Z. Z. DDoS Vulnerabilities Multiple Threats & Targets. Z. Attack ombies : Use valid protocols

Download Presentation

Detecting and Mitigating DoS Attack in a Network

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


Detecting and Mitigating DoS Attack in a Network

Cisco Systems


Agenda

  • DDoS Reality Check

  • Detecting

  • Tracing

  • Mitigation

  • Protecting the Infrastructure


Z

Z

Z

Z

Z

Z

Z

Z

Z

DDoS VulnerabilitiesMultiple Threats & Targets

Z

Attack ombies:

  • Use valid protocols

  • Spoof source IP

  • Massively distributed

  • Variety of attacks

POP

Peering

Point

ISP Backbone

  • Provider infrastructure:

  • DNS, routers and links

Attackedserver

Access line

  • Entire data center:

  • Servers, security devices, routers

  • E-commerce, web, DNS, email,…


Evolution

# Attackers

Type of attack

Protection

Distribution Management

(Bandwidth)

  • Email attach

  • Download from questionable site

  • via “chat”

  • ICQ, AIM, IRC

  • Worms

  • Blackhole (?)

  • ACL (?)

  • DDoS solutions

  • Anycast (?)

  • Legitimate requests

  • Infrastructure elements (DNS, SMTP, HTTP…)

Via botnets

~X00,000 attackers

(X-X0 Gbps)

  • ISP/IDC

  • Blackhole

  • ACL

  • DDoS solutions

  • Email attach

  • via “chat” ICQ, AIM, IRC…

~X00-X,000

Attackers

(X00 Mbps)

  • All type of applicatios (HTTP, DNS, SMTP)

  • Spoofed SYN

Manually

  • Enterprise level

  • Firewall/

  • ACL access routers

X0-X00 attackers

(X0 Mbps)

Spoofed SYN

Manually

(hack to servers)

Manually

Non critical Protocols

(eg ICMP)


Security ChallengesThe Cost of Threats

Dollar Amount of Loss By Type of Attack - CSI/FBI 2004 Survey


ISP Security Incident Response

  • ISP’s Operations Team response to a security incident can typically be broken down into six phases:

    • Preparation

    • Identification

    • Classification

    • Traceback

    • Reaction

    • Post Mortem


Sink Hole Routers (for ISP mainly)

  • Use unallocated addresses

    • A lot of them on the Internet… 10.0.0.0/8, 96.0.0.0/4, …

  • Sink hole Router locally advertises these addresses

  • Infected hosts will seek to contact them

  • Log will provide list of locally infected hosts

  • Will be useful for other tricks


  • Let’s advertise non used IP networks (in routing protocol):

  • 0.0.0.0/8

  • 1.0.0.0/8

  • 96.0.0.0/4

Sink Hole (aka Network Honey Pot) Set-Up

Infected System

XYZ

Sink Hole Router


Let’s infect all other hosts

Try: 96.97.98.99

Sink Hole In ActionWorm Detection

The very same set-up will be used for other games

Could be used for enterprise as well

Infected System

XYZ

Sink Hole Router

IDS Sensor


Agenda

  • DDoS Reality Check

  • Detecting

  • Tracing

  • Mitigation

  • Protecting the Infrastructure


Identification Tools

  • Customer/User Phone call

  • CPU Load on Router

  • SNMP – Watching the baseline and tracking variations/surges.

  • Netflow/IPFIX – Traffic Anomaly Detection Tools.

  • Sink Holes – Look for Backscatter


Netflow: Statistics per TCP/UDP FlowsDoS == Unusual Behavior

Potential DoS attack (33 flows) on router1

Estimated: 660 pkt/s 0.2112 Mbps

ASxxx is: …

ASddd is: …

src_ipdst_ipinoutsrcdestpktsbytesprotsrc_asdst_as

intintportport

192.xx.xxx.69194.yyy.yyy.229491308771406xxxddd

192.xx.xxx.222194.yyy.yyy.22949177412431406xxxddd

192.xx.xxx.108194.yyy.yyy.22949186910761406xxxddd

192.xx.xxx.159194.yyy.yyy.2294910509031406xxxddd

192.xx.xxx.54194.yyy.yyy.2294920187301406xxxddd

192.xx.xxx.136194.yyy.yyy.2294918215591406xxxddd

192.xx.xxx.216194.yyy.yyy.2294915163831406xxxddd

192.xx.xxx.111194.yyy.yyy.229491894451406xxxddd

192.xx.xxx.29194.yyy.yyy.22949160012091406xxxddd

192.xx.xxx.24194.yyy.yyy.22949112010341406xxxddd

192.xx.xxx.39194.yyy.yyy.2294914598681406xxxddd

192.xx.xxx.249194.yyy.yyy.2294919676921406xxxddd

192.xx.xxx.57194.yyy.yyy.2294910445211406xxxddd

……………………………

Real data deleted in

this presentation

Real data deleted in

this presentation

Real data deleted in

this presentation


Sink Hole RouterBackscatter Analysis

  • Under DDoS victim replies to random destinations

  • -> Some backscatter goes to sink hole router, where it can be analysed


random destinations

Backscatter Analysis

Other

ISPs

IngressRouters

random sources

Target

random sources

Sink Hole Router


Agenda

  • DDoS Reality Check

  • Detecting

  • Tracing

  • Mitigation

  • Protecting the Infrastructure


Tracing DoS Attacks

  • If source prefix is not spoofed:

    • -> Routing table -> Internet Routing Registry (IRR)-> direct site contact

  • If source prefix is spoofed:

    • -> Trace packet flow through the networkACL, NetFlow, IP source tracker

    • -> Find upstream ISP-> Upstream needs to continue tracing

  • Nowadays, 1000’s of sources not spoofed

    • -> not always meaningful to trace back…


Trace-Back in One Step: ICMP Backscatter

  • Border routers:

    • Allow ICMP (rate limited)

    • On packet drop, ICMP unreachable will be sent to the source

  • Use ACL or routing tricks (routing to NULL interface)

    • All ingress router drop traffic to <victim>

    • And send ICMP unreachables to spoofed source!!

  • Sink hole router logs the ICMPs!


Trace-Back Made Easy: ICMP Backscatter Step 1: no drop

Other

ISPs

IngressRouters

random sources

Target

random sources

Sink hole Router


Trace-Back Made Easy: ICMP Backscatter Step 2: Drop Packets

Other

ISPs

IngressRouters

Target

ICMP unreachables

Sink hole Router

with logging


Agenda

  • DDoS Reality Check

  • Detecting

  • Tracing

  • Mitigation

  • Protecting the Infrastructure


.

.

.

.

.

.

.

.

At the Edge / FirewallsACL/QoS to Drop/Throttle DDoS Traffic

R4

R5

peering

R2

R3

  • Easy to choke

  • Point of failure

  • Not scalable

  • Consumer tuned

  • Too late

1000

1000

R1

100

R

R

R

FE

Server1

Target

Server2


.

.

.

.

.

.

.

.

At the Routers in the NetworkACL/QoS to Drop/Throttle DDoS Traffic

R4

R5

peering

R2

R3

  • Rand. Spoofing?

  • Throws good with bad

  • ~X0,000 ACLs?

1000

ACLs,

Upper bound on traffic

1000

R1

100

R

R

R

FE

Server1

Victim

Server2


Black Holing the DoS TrafficRe-Directing Traffic to the Victim

Other

ISPs

IngressRouters

  • Keeps line to customer clear

  • But cuts target host off completely

  • Discuss with customer!!!

  • Just for analysis normally

Target

Sink hole Router: Announces route “target/32”

Logging!!


Identifying and Dropping only DDoS Traffic/1

Cisco Anomaly Guard Module

Cisco Traffic Anomaly Detector Module (or Cisco IDS or third- party system)

Protected Zone 1: Web

Protected Zone 2: Name Servers

Protected Zone 3: E-Commerce Application


Identifying and Dropping only DDoS Traffic/2

Cisco Anomaly Guard Module

Cisco Traffic Anomaly Detector Module

1. Detect

Target

Protected Zone 1: Web

Protected Zone 2: Name Servers

Protected Zone 3: E-Commerce Application


Identifying and Dropping only DDoS Traffic/3

Cisco Anomaly Guard Module

2. Activate: Auto/Manual

Cisco Traffic Anomaly Detector Module

1. Detect

Target

Protected Zone 1: Web

Protected Zone 2: Name Servers

Protected Zone 3: E-Commerce Application


Identifying and Dropping only DDoS Traffic/4

Route update:

RHI internal, or BGP/other external

3. Divert only

target’s traffic

Cisco Anomaly Guard Module

2. Activate: Auto/Manual

Cisco Traffic Anomaly Detector Module

1. Detect

Target

Protected Zone 1: Web

Protected Zone 2: Name Servers

Protected Zone 3: E-Commerce Application


Identifying and Dropping only DDoS Traffic/5

4. Identify and filter malicious traffic

3. Divert only

target’s traffic

Traffic Destined

to the Target

Cisco Anomaly Guard Module

2. Activate: Auto/Manual

Cisco Traffic Anomaly Detector Module

1. Detect

Target

Protected Zone 1: Web

Protected Zone 2: Name Servers

Protected Zone 3: E-Commerce Application


Identifying and Dropping only DDoS Traffic/6

4. Identify and filter malicious traffic

3. Divert only

target’s traffic

Traffic Destined

to the Target

Cisco Anomaly Guard Module

Legitimate Traffic to Target

2. Activate: Auto/Manual

Cisco Traffic Anomaly Detector Module

1. Detect

Target

5. Forward legitimate traffic

Protected Zone 1: Web

Protected Zone 2: Name Servers

Protected Zone 3: E-Commerce Application


Identifying and Dropping only DDoS Traffic/7

4. Identify and filter malicious traffic

3. Divert only

target’s traffic

Traffic Destined

to the Target

6. Non-targeted traffic flowsfreely

Cisco Anomaly Guard Module

Legitimate Traffic to Target

2. Activate: Auto/Manual

Cisco Traffic Anomaly Detector Module

1. Detect

Target

5. Forward legitimate traffic

Protected Zone 1: Web

Protected Zone 2: Name Servers

Protected Zone 3: E-Commerce Application


Multi-Verification Process (MVP)

Integrated Defenses in the Guard XT

Detect anomalous behavior & identify precise attack flows and sources

Legitimate + attack traffic to target

Dynamic &

Static Filters

ActiveVerification

Rate Limiting

Layer 7

Analysis

Statistical

Analysis


Multi-Verification Process (MVP)

Integrated Defenses in the Guard XT

Apply anti-spoofing

to block malicious flows

Legitimate + attack traffic to target

Dynamic &

Static Filters

ActiveVerification

Rate Limiting

Layer 7

Analysis

Statistical

Analysis


Anti-Spoofing Example – http/TCP

SrcIP, Source IP

Guard

Syn(c#)

synack(c#,s#)

Hash-function(SrcIP,port,t)

Verified connections

=

ack(c#,s#)

SrcIP,port#

Redirect(c#,s#)

Victim

Syn(c#’)

Synack(c#’,s#’)

request(c#’,s#’)


Multi-Verification Process (MVP)

Integrated Defenses in the Guard XT

Dynamically insert specific filters to block attack flows & sources

Apply rate limits

Legitimate traffic

Dynamic &

Static Filters

ActiveVerification

Rate Limiting

Layer 7

Analysis

Statistical

Analysis


Measured Response

  • Strong Protection

  • Strong anti-spoofing (proxy) if appropriate

  • Dynamic filters deployed for zombie sources

Anomaly

Identified

  • Basic Protection

  • Basic anti-spoofing applied

  • Analysis for continuing anomalies

Anomaly

Verified

  • Analysis

  • Diversion for more granular in-line analysis

  • Flex filters, static filters and bypass in operation

  • All flows forwarded but analyzed for anomalies

  • Detection

  • Passive copy of traffic monitoring

Attack

Detected

  • Learning

  • Periodic observation of patterns to update baseline profiles


Agenda

  • DDoS Reality Check

  • Detecting

  • Tracing

  • Mitigation

  • Protecting the Infrastructure


Three Planes, Definition

  • A device typically consists of

    • Data/forwarding Plane: the useful traffic

    • Control Plane: routing protocols, ARP, …

    • Management Plane: SSH, SNMP, …

  • In these slides Control Plane refers to all the Control/Management plane traffic destined to the device.

Hardware

Software


Control Plane Overrun

  • Loss of protocol keep-alives:

    • line go down

    • route flaps

    • major network transitions.

  • Loss of routing protocol updates:

    • route flaps

    • major network transitions.

  • Near 100% CPU utilization

    • Can prevent other high priority tasks


Need for Control Plane Policing

  • Classify all Control Plane traffic in multiple classes

  • Each class is capped to a certain amount

  • Fair share for each classes or each source in each classes

    •  one class cannot overflow the others

    •  even an ICMP flood to the router won’t affect routing


Q and A

40

40

40


41

41

41


  • Login