> Nicolas FISCHBACH IP Engineering Manager - COLT Telecom AG

27
> Nicolas FISCHBACH IP Engineering Manager - COLT Telecom AG [email protected] - http://www.securite.org/nico/ version 1.0 (Distributed) Denial of Service attacks, detection and protection

description

(Distributed) Denial of Service attacks, detection and protection. > Nicolas FISCHBACH IP Engineering Manager - COLT Telecom AG [email protected] - http://www.securite.org/nico/ version 1.0. Agenda. Denial of Service and Worms Attacks Architectures - PowerPoint PPT Presentation

Transcript of > Nicolas FISCHBACH IP Engineering Manager - COLT Telecom AG

Page 1: > Nicolas FISCHBACH      IP Engineering Manager - COLT Telecom AG

> Nicolas FISCHBACH IP Engineering Manager - COLT Telecom AG [email protected] - http://www.securite.org/nico/

version 1.0

(Distributed) Denial of Service

attacks, detection and protection

Page 2: > Nicolas FISCHBACH      IP Engineering Manager - COLT Telecom AG

2© 2002 Sécurité.Org

Agenda

» Denial of Service and Worms» Attacks

> Architectures> Distributed attacks and agents> Local and remote network based attacks

» Detection and protection> Locally> Internet

» Conclusion

Page 3: > Nicolas FISCHBACH      IP Engineering Manager - COLT Telecom AG

3© 2002 Sécurité.Org

Definition (1)

» Goal of DoS attacks> Eat up resources (bandwidth, CPU, memory, etc) to make

a service slow or take it completely down :- File descriptors, sockets, state memory, PIDs- SSL sessions, IPsec encrypted VPNs- Dynamic web pages, SQL requests, downloads, SPAM- Fill up logs (make searching/parsing the logs more complex)

> Take the service down by (continuously) exploiting a bug in the network, the system, the service or the application -- or even by destroying information

> Easier for a script kiddie to launch a DoS attack than to break into a system :

- agents/systems under control are traded on IRC- at the moment these kiddies focus on online game servers

Page 4: > Nicolas FISCHBACH      IP Engineering Manager - COLT Telecom AG

4© 2002 Sécurité.Org

Definition (2)

» Goal of DoS attacks> Attack from a single source or multiple, distributed,

sources> Source IP address spoofed or stepping stone to :

- Hide the real source- Amplify the attack- Make filtering based on the source IP address useless- Fake a competitor attack

> Unfortunately most of the attacks are and can still be used months, even years after their discovery :

- « Part » of the protocol or the infrastructure- Solution or work-around not yet available or not yet

deployed

Page 5: > Nicolas FISCHBACH      IP Engineering Manager - COLT Telecom AG

5© 2002 Sécurité.Org

Attacks : architecture (1)

Bad guy VictimCompromisedhost

» Basic attack> Some names :

- (win)nuke, ping of death, land, teardrop, jolt, pepsi, bo(i)nk, nestea(2), naptha , 3wahas, stream, fraggle, or a mix of some attacks (targa/rape)

> TCP- SYN flood- Use of several flags (FIN/SYN/RST/PSH/ACK/URG)- Attacks requiring an established TCP session

> ICMP- Often ICMP echo and echo_reply messages

> UDPThird parties

Page 6: > Nicolas FISCHBACH      IP Engineering Manager - COLT Telecom AG

6© 2002 Sécurité.Org

Attacks : architecture (2)

Bad guy Victim

Amplifiers

Ownedhost

» Amplified or reflectors based attacks> Basic attack, but amplified (factor 10-1000:1) and/or

using reflectors (usually a 1:1 ratio) :- smurf, P2P clients/servers, DNS servers, broken TCP

implementations with guessable ISNs, etc.

Page 7: > Nicolas FISCHBACH      IP Engineering Manager - COLT Telecom AG

7© 2002 Sécurité.Org

Attacks : architecture (3)

Bad guy Masteragent Victim (s)

Slave agents(zombies, bots)

Third parties

Ownedhost

» Distributed attack> Usually only one target : large packets (bandwidth),

small packets (host resources)

Page 8: > Nicolas FISCHBACH      IP Engineering Manager - COLT Telecom AG

8© 2002 Sécurité.Org

Attacks : agents (1)

» Slave agents> « Modified » servers, services and also network

equipment (ie. routers)> Compromised servers run a (D)DoS agent :

- Trinoo, TFN{(2,3)k}, omega, Stacheldrat*, Carko, Trinity, etc.

- Trojan horse> P2P (peer-to-peer) tools

» Agents are distributed> On the same network : school, company, ISP, cable/xDSL

« area »> Same country or continent> Same « type » of network : IPv6 island, mbone, Internet2> Completely distributed over the Internet

Page 9: > Nicolas FISCHBACH      IP Engineering Manager - COLT Telecom AG

9© 2002 Sécurité.Org

Attacks : agents (2)» Agents deployment and communications

> « By hand »> Automated script (downloading data from a central server

over HTTP/FTP/DCC/etc)> DDoS agents « deployed » using a worm or a virus and

hidden using a {tool,root}kit (adore, t0rn, etc) : - Makes it easy and quick to collect and acquire a lot of systems- First sign of a « soon to be launched » attack- VBS/*, Win32/*, Code*, Nimda, 1i0n/ramen, slapper, etc.- (Bio)diversity helps to reduce exposure to a worm, but makes

the IS more complex> Warez FTP servers> Fake update for a well known application> IRC, P2P tools, instant messaging, etc.

Page 10: > Nicolas FISCHBACH      IP Engineering Manager - COLT Telecom AG

10© 2002 Sécurité.Org

» Affected protocols> ARP : DoS and traffic redirection> CDP : DoS (next to information leak)> STP : create loops in the network or even take it

down (block all ports)> VTP : change the VLANs configuration> DTP : transport VLANs over the network> DHCP/BOOTP : traffic redirection and DoS

Attacks : the data link layer

Page 11: > Nicolas FISCHBACH      IP Engineering Manager - COLT Telecom AG

11© 2002 Sécurité.Org

Attacks : the network layer

» Local attacks> IGPs (OSPF, (E)IGRP, IS-IS)

» « Remote » attacks> TCP segment with specific flags> (Fragmented) UDP packets> (Fragmented) ICMP messages> Single packet containing a buffer overflow, format

string, etc.> Inject routes into an eBGP session or try to break the

TCP session

Page 12: > Nicolas FISCHBACH      IP Engineering Manager - COLT Telecom AG

12© 2002 Sécurité.Org

Detection (1)

» Define metrics and describe, graph and monitor (ab)normal behaviour

» At the network layer> New SMTP and/or HTTP flows> Size and fragmentation of packets> Protocols distribution (TCP/UDP/ICMP)> Line load, CPU load, free memory, response time, etc.> Advanced analysis of network traffic

» On systems and at the application layer> Firewalls, xIDS, NMS> Logs> CPU load, memory usage, response time> State tables (TCP sessions state for example)

Page 13: > Nicolas FISCHBACH      IP Engineering Manager - COLT Telecom AG

13© 2002 Sécurité.Org

Detection (2)

» Correlate data to ease detection> Locally by using multiple sources : xIDS/FW/ACLs with

log-input/NMS/flows/honeypots- Improves the detection of false positive and false

negatives > By taking part of or paying for services that analyze

pseudo-anonymous logs and inform subscribers about on-going attacks

> Packets, transactions, strange network behaviour (DNS lookups, nmap/queso/xprobe based scans, etc)

» IA based anomaly detection> Still in the R&D labs !> Is detection the real issue or is it the quantity of data to

deal with ?

Page 14: > Nicolas FISCHBACH      IP Engineering Manager - COLT Telecom AG

14© 2002 Sécurité.Org

Detection (3)

» How to find the source of an attack ?> Local logs> Logs of systems used as stepping stones> Public archives of routing information :

- Which AS used to announce this network prefix- Which route server used to see the same thing, etc

> Netflow exports (or RMON), S-train’s « source tracking »> Network traffic dumps :

- Dumps are seldom (this gets even worse for layer 2 dumps)- Logs and dumps usually start _after_ the attack- Depending on the network architecture, capturing traffic

can be a headache or even impossible> Hop-by-hop backtracing : what about AS boundaries and

upstream tracing ?

Page 15: > Nicolas FISCHBACH      IP Engineering Manager - COLT Telecom AG

15© 2002 Sécurité.Org

Protection (1)» What are the issues ?

> Spoofed source IP address(es)> The source of the attack is far away from a network point

of view> Most of the time you can just sit down and wait :

- You and your ISP are at the network edge- The source of the attack is in the APNIC zone- The network prefixes aren’t allocated and only routed for a

short period of time> It may be complex to identify the type of traffic : try to be

proactive> Your network is usually redundant, resilient, divided up into

domains and able to fail-over in case of failure of a link or an equipment : take (D)DoS risks into account during design

Page 16: > Nicolas FISCHBACH      IP Engineering Manager - COLT Telecom AG

16© 2002 Sécurité.Org

Protection (2)

» What are the solutions ?> There is no technical solution that makes you completely

safe :- Configuration of the equipment and network architecture- Systems and applications up-to-date, audited and monitored

> Attacks can be filtered at differents levels :- Switches, routers, firewalls, xIDS with « fireback »- Dedicated devices : commercial solutions (local and

distributed) (still) require a human decision- Systems/applications (decode and filter parameters)

> Should you drop this kind of traffic or react to it ?- RST in response to SYN ?- Don’t make the situation worse and more complex

> Best Current Practices

Page 17: > Nicolas FISCHBACH      IP Engineering Manager - COLT Telecom AG

17© 2002 Sécurité.Org

Protection (3)

» At the data link layer> Disable and filter (depends on your network

architecture) all unused or useless protocols- CDP, STP, DTP, VTP

> Monitor (or fix) ARP caches and tables on your systems and network devices

Page 18: > Nicolas FISCHBACH      IP Engineering Manager - COLT Telecom AG

18© 2002 Sécurité.Org

Protection (4)

» At the network layer> Bandwidth

- Talk to your ISP/upstream(s)- Why should you allow more than 64Kb/s of ICMP and/or

UDP traffic on your Internet link ? Take normal traffic into account (DNS and Path MTU Discovery for example)

- What if your bandwidth is charged on a UBB basis ?> Filter source and destination IP addresses

- Your network prefixes- DSUA networks (RFC 1918, AutoDHCP, D/E classes, etc)- Only route and accept network from allocated blocks- etc.

Page 19: > Nicolas FISCHBACH      IP Engineering Manager - COLT Telecom AG

19© 2002 Sécurité.Org

Protection (5)

» At the network layer> Decide not to route or not accept prefixes known to be

source of problem a la *@{hotmail, yahoo}.com SMTP filtering

> Stop to announce the PI space if possible (IRC servers ;-) or de-aggregate a large PA block into /24s and stop announcing the « affected » prefixes

> Make sure you have some way to administer your network and the devices « out-of-band »

> In some recent network designs engineers plan a second ISP (routing, addressing, NAT and DNS become an issue)

> When possible think about using some non-routed prefixes when not needed

Page 20: > Nicolas FISCHBACH      IP Engineering Manager - COLT Telecom AG

20© 2002 Sécurité.Org

Protection (6)

» At the network layer> Automatic « blacklisting » can make you quickly

unreachable (large cable/DSL providers, proxy/caches)> Depending on the filtering you will implement you may

not have any log/evidence :- Dynamic routing into null0 or reject- « Drop » ACL without logging, loose/strict uRPF- Upstream based filtering

> Decide if you want to rate-limit the traffic only or redirect it to some dedicated device

> Filter based on traffic or packet patterns (TTL, ip.id, ip.length, ISNs, ICMP message type, ports, etc)

> Route dampening may not be your friend for a short period of time

Page 21: > Nicolas FISCHBACH      IP Engineering Manager - COLT Telecom AG

21© 2002 Sécurité.Org

Protection (7)

» At the transport layer> TCP segments with the SYN flag

- Use « cookies » (dito for IPsec)- Intercept the 3-way handshare on some dedicated device

(router, firewall, DDoS filter) acting as a TCP Intercept like> Established TCP sessions :

- Use load balancers to redirect part of the traffic (to reduce the impact, to redirect traffic into a black hole or towards a dedicated device)

- Do we need a tool or device that monitors and tracks the full TCP session and related state changes (as far as FIN_WAITx)?

» At the application layer> Use application layer proxies and filters (NBAR ?)> Use devices that recognize flows and can deal with them

Page 22: > Nicolas FISCHBACH      IP Engineering Manager - COLT Telecom AG

22© 2002 Sécurité.Org

Protection (8)

» At the Internet « level »> ICMP Traceback (itrace)

- Each router sends, with a low probability, a message to the destination of a packet it forwarded with information about the previous and next hop and part of the payload

- “Works” only for larger (D)DoS attacks> IP Traceback

- Traceback information is stored in the ip.id field by the “IPT” routers on the packet’s path

- Probability to catch smaller attacks is better than with itrace> MULTOPS (Multi-Level Tree for Online Packet Statistics)

- A local data structure on each router stores data about current flows and is analyzed to detect/respond to attacks

Page 23: > Nicolas FISCHBACH      IP Engineering Manager - COLT Telecom AG

23© 2002 Sécurité.Org

Protection (9)

» At the Internet « level »> SPIE (Source Path Isolation Engine)

- The router stores temporary a hash about each packet it forwards and authorized routers can query this information

> Pushback- Routers send rate-limit requests for certain networks if they

detect attacks (based on traffic characteristics) to their neighbors

> IDIP (Intruder Detection and Isolation Protocol)- Protocols and framework used to correlate information,

detect and respond to intrusions> HIP (Host Identity Payload/Protocol)

- New name space (next to IP/DNS) with IKE like functionalities and public key based authentication for hosts

Page 24: > Nicolas FISCHBACH      IP Engineering Manager - COLT Telecom AG

24© 2002 Sécurité.Org

Protection (10)

» At the Internet « level »> CenterTrack

- Secondary network used to carry “interesting” packets detected by routers for analysis

> Limitations- CPU and memory needs on routers- Fundamental changes (infrastructure, deployment, ops,

etc)- IP address spoofing and traceback are the key issues

> Conclusion- {in,e}gress filtering- Deployment of S-BGP, IPsec (AH), IPv6, ECN, multicast ?- « Legitimate » DoS (« Slashdot effect »)- Laws ?

Page 25: > Nicolas FISCHBACH      IP Engineering Manager - COLT Telecom AG

25© 2002 Sécurité.Org

Conclusion

» Future> Research in this domain is quite active, but not a lot of

publications (attack/defense)> Device capable of generating a lot of PPS are being

targeted (routers)> Agents and worms become more and more

« intelligent »> A new playground : Internet2> Come up with « un peu de finesse dans ce monde de

brutes » : attacks are usually emotional firebacks and not « well prepared »

» And you ?> Post-mortem analysis and incident response processes> Help to get rid of (D)DoS by securing your network ;-)

Page 26: > Nicolas FISCHBACH      IP Engineering Manager - COLT Telecom AG

26© 2002 Sécurité.Org

Publications

» Publications> Inferring Internet DoS Activity (Caida)> A Snapshot of Global Worm Activity (Arbor)> Shining Light on Dark Internet Address Space (Arbor)> How to 0wn the Internet in Your Spare Time

(Staniford/Paxson)> Global Routing Instabilities during Code Red II and

Nimda Worm Propagation (Renesys)> Trends in Denial of Service Attack Technology (CERT)> ...

Page 27: > Nicolas FISCHBACH      IP Engineering Manager - COLT Telecom AG

27© 2002 Sécurité.Org

That’s all folks :-)

» Latest version will be posted to :

» IP Backbone Security presentation :

» Q&A

< http://www.securite.org/presentations/ddos/ >

< http://www.securite.org/presentations/secip/ >

Image: http://www.inforamp.net/~dredge/funkycomputercrowd.html