Transcript attacks, detection and protection Nicolas Fischbach

(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
> Distributed attacks and agents
> Local and remote network based attacks
Detection and protection
> Locally
> Internet
Conclusion
© 2002 Sécurité.Org
2
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
© 2002 Sécurité.Org
3
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
© 2002 Sécurité.Org
4
Attacks : architecture (1)
» 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
Bad guy
Compromised
host
Victim
- 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
> UDP
© 2002 Sécurité.Org
Third parties
5
Attacks : architecture (2)
» 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.
Victim
Bad guy
Amplifiers
Owned
host
© 2002 Sécurité.Org
6
Attacks : architecture (3)
» Distributed attack
> Usually only one target : large packets (bandwidth), small
packets (host resources)
Bad guy
Master
agent
Victim (s)
Slave agents
(zombies, bots)
Owned
host
Third parties
© 2002 Sécurité.Org
7
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
© 2002 Sécurité.Org
8
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.
© 2002 Sécurité.Org
9
Attacks : the data link layer
» 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
© 2002 Sécurité.Org
10
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
© 2002 Sécurité.Org
11
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)
© 2002 Sécurité.Org
12
Detection (2)
» Correlate data to ease detection
> Locally by using multiple sources : xIDS/FW/ACLs with loginput/NMS/flows/honeypots
- Improves the detection of false positive and false negatives
»
> By taking part of or paying for services that analyze pseudoanonymous 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 ?
© 2002 Sécurité.Org
13
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 ?
© 2002 Sécurité.Org
14
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
© 2002 Sécurité.Org
15
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
© 2002 Sécurité.Org
16
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
© 2002 Sécurité.Org
17
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.
© 2002 Sécurité.Org
18
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
© 2002 Sécurité.Org
19
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
© 2002 Sécurité.Org
20
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
© 2002 Sécurité.Org
21
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
© 2002 Sécurité.Org
22
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
© 2002 Sécurité.Org
23
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 ?
© 2002 Sécurité.Org
24
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 ;-)
© 2002 Sécurité.Org
25
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)
> ...
© 2002 Sécurité.Org
26
That’s all folks :-)
» Latest version will be posted to :
< http://www.securite.org/presentations/ddos/ >
» IP Backbone Security presentation :
< http://www.securite.org/presentations/secip/ >
» Q&A
Image: http://www.inforamp.net/~dredge/funkycomputercrowd.html
© 2002 Sécurité.Org
27