A Fast Worm Scan Detection Tool for VPN Congestion Avoidance Arno - - PowerPoint PPT Presentation

▶

Dec 24, 2023 157 likes •353 views

A Fast Worm Scan Detection Tool for VPN Congestion Avoidance Arno Wagner,Thomas D ubendorfer, Roman Hiestand, Christoph G oldi, Bernhard Plattner Communication Systems Group Swiss Federal Institute of Technology Zurich (ETH Zurich)

SLIDE 1

A Fast Worm Scan Detection Tool for VPN Congestion Avoidance

Arno Wagner,Thomas D¨ ubendorfer, Roman Hiestand, Christoph G¨

ldi, Bernhard Plattner

Communication Systems Group Swiss Federal Institute of Technology Zurich (ETH Zurich)

SLIDE 2

Outline

1. Setting
2. Problem Statement
3. Design Goals
4. Approach
5. Implementation
6. Tests, Validation
7. Remarks

Arno Wagner, ETH Zurich, DIMVA 2006 – p.1

SLIDE 3

Setting

Collaboration between OpenSystems AG, Zurich and Communication Systems Group (CSG) at ETH Zurich OpenSystems: Provides, e.g., managed VPN links on OpenSystems hardware (Linux based industrial PCs) Administration remotely from Zurich NOC Customers in 70 countries > 100 VPN links operational

Arno Wagner, ETH Zurich, DIMVA 2006 – p.2

SLIDE 4

Problem Statement

Internet links: SAT-phones, . . ., high-speed Internet Congestion can cause significant problems Remote diagnosis can be difficult Customers may need their links repaired very fast IT competence at customers sites varies strongly Diagnosis has to be done remotely by OpenSystems

⇒ Typically requires several hours of manual work

One main congestion source: Worm infected hosts

Arno Wagner, ETH Zurich, DIMVA 2006 – p.3

SLIDE 5

Design Goals

The scan traffic detector needs to: Run on the VPN endpoints (detection is for attached network, not VPN tunnel) Communicate only when problems are detected Have low resource needs Detect scan and DoS traffic fast Identify infected hosts Have a low false positives rate

Arno Wagner, ETH Zurich, DIMVA 2006 – p.4

SLIDE 6

Approach

Main approach: Failed connection counting on a per-host basis Relatively simple for TCP Still works for UDP and ICMP Idea is well documented in the literature

Arno Wagner, ETH Zurich, DIMVA 2006 – p.5

SLIDE 7

TCP Scan Detection

Each active host has a state Measurements are done incrementally Identified infected hosts are ignored to reduce load

Arno Wagner, ETH Zurich, DIMVA 2006 – p.6

SLIDE 8

TCP Host Flowchart I

< 5 minutes failed conn. in < 2 minutes TCP_BENIGN yes yes no first failed TCP connection no > 100 failed conn. TCP_SCAN to >100 hosts in

Arno Wagner, ETH Zurich, DIMVA 2006 – p.7

SLIDE 9

TCP Host Flowchart II

TCP_HOST_SCAN < 5 minutes failed conn. TCP_HOST_SAMEPORT_SCAN TCP_HOST_PORT_SCAN failed conn. yes yes yes yes no no no TCP_HOST_NOTSAMEPORT_SCAN WORM WORM no to >100 hosts in > 100 hosts on the same to > 300 hosts in < 5 min. DoS TCP_DOS

conn. to < 5 hosts in

> 1200 failed TCP_SAMEPORT_SCAN < 4 min failed conn. to port in < 5 min.

TCP_BENIGN back to

Arno Wagner, ETH Zurich, DIMVA 2006 – p.8

SLIDE 10

UDP Scan Detection

Similar to TCP , but failed ”connection” can be UDP packet, no answering packet UDP packet, answering ICMP ”destination unreachable” Further differences: Thresholds are different More traffic needed to trigger detection

Arno Wagner, ETH Zurich, DIMVA 2006 – p.9

SLIDE 11

ICMP Scan Detection

Similar to TCP , but No port checks Failed ”connections” possibilities (not distinguished): ICMP ”destination unreachable” ICMP requests without answer

Arno Wagner, ETH Zurich, DIMVA 2006 – p.10

SLIDE 12

Detection Latency

Tests are done serially to conserve memory + No traffic needs to be stored

Worst case detection time is higher

But: More scan traffic gives faster detection Worst case detection times are still reasonable (TCP: 17 min, UDP: 18 min)

Arno Wagner, ETH Zurich, DIMVA 2006 – p.11

SLIDE 13

Implementation

VPN node: P4 2.4GHz, 1GB RAM, 2 * FE, 2 * GbE, customised 2.4 kernel Detector: Uses Bro intrusion detection system Traffic capturing via libpcap Event propagation via system log Alerting via OpenSystems log monitor

Arno Wagner, ETH Zurich, DIMVA 2006 – p.12

SLIDE 14

Performance I

4 infected hosts, simulated TCP worm traffic (MACE)

1 1 2 3 4 5 6 7 8 9 10 cpu usage (%) time (min)

Memory load stays below 8MB

Arno Wagner, ETH Zurich, DIMVA 2006 – p.13

SLIDE 15

Performance II

252 infected hosts, simulated TCP worm traffic (MACE)

10 20 30 40 50 60 70 80 1 2 3 4 5 6 7 8 9 10 cpu usage (%) time (min)

Memory load stays below 20MB

Arno Wagner, ETH Zurich, DIMVA 2006 – p.14

SLIDE 16

Validation

The detector was tested with Blaster worm (real infection) SQL Slammer worm (real infection) Simulated worm traffic by MACE 22 hours of productive traffic from 15 VPN links

⇒ No false positives

Several different P2P filesharing applications

⇒ Alerts from eMule when firewalled and searching

Arno Wagner, ETH Zurich, DIMVA 2006 – p.15

SLIDE 17

Remarks I

Detector is used in OpenSystems production environment Source code available upon request: Detector scripts (Bro): GPL MACE extensions: non-commercial use Very successful project: Students: Very good master’s thesis OpenSystems: Practical solution of a real problem ETH: Paper at DIMVA’06

Arno Wagner, ETH Zurich, DIMVA 2006 – p.16

SLIDE 18

Remarks II: Collaboration

Industrial collaboration with OpenSystems on student theses works well. No money flows Topics must be of interest to all sides Everybody invests real effort and shapes results Mutual understanding of different goals Produced software GPL where possible Important: Avoid ”problem students”

Arno Wagner, ETH Zurich, DIMVA 2006 – p.17

SLIDE 19

Thank You!

Arno Wagner, ETH Zurich, DIMVA 2006 – p.18