Upload
elvin
View
44
Download
0
Embed Size (px)
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
Citation preview
> 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
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
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
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
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
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.
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)
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
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.
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
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
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)
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 ?
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 ?
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
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
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
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.
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
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
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
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
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
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 ?
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 ;-)
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)> ...
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