Download Document 8927335

9/16/15 5. Network Security Basics ENEE 757 | CMSC 818V Prof. Tudor Dumitraș Assistant Professor, ECE University of Maryland, College Park http://ter.ps/757 https://www.facebook.com/SDSAtUMD Today’s Lecture •  Where we’ve been –  Crypto basics –  OS security basics •  Where we’re going today –  Network security –  TCP/IP, BGP –  Intrusion detecMon •  Where we’re going next –  Trustworthy compuMng 2 1 9/16/15 Internet Is a Network of Networks backbone ISP Internet service provider (ISP) local network local network Autonomous system (AS) is a collecMon of IP networks under control of a single administrator (e.g., ISP) •  TCP/IP for packet rouHng and connecHons •  Border Gateway Protocol (BGP) for route discovery •  Domain Name System (DNS) for IP address discovery 3 OSI Protocol Stack applicaMon email, Web, NFS presentaMon session transport network data link RPC TCP IP Ethernet physical 4 2 9/16/15 Data Formats applicaMon layer transport layer message ApplicaMon data TCP header network layer data link layer TCP header data IP TCP header header data IP TCP header header data data Ethernet header TCP header data segment datagram Ethernet trailer frame 5 IP (Internet Protocol) •  ConnecMonless –  Unreliable, “best-­‐effort” protocol •  Uses numeric addresses for rouMng •  Typically several hops in the route Alice’s computer Bob’s ISP Alice’s ISP 128.83.130.239 Packet Source 128.83.130.239 Dest 171.64.66.201 TTL 3 Bob’s computer 171.64.66.201 6 3 9/16/15 TCP (Transmission Control Protocol) •  Sender: break data into packets –  Sequence number is acached to every packet •  Receiver: reassemble packets in correct order –  Acknowledge receipt; lost packets are re-­‐sent •  ConnecMon state maintained on both sides book mail each page remember received pages and reassemble 7 Threat #1: Eavesdropping on Network ConnecHons •  Goal: extract informaMon from network packets •  Many applicaMons send data unencrypted –  ep, telnet send passwords in the clear •  Network interface card (NIC) in “promiscuous mode” reads all passing data –  Acacker sniffs packets to eavesdrop passively network SoluMon: encrypMon (e.g., IPsec, HTTPS), improved rouMng 8 4 9/16/15 Threat #2: Denial of Service (DoS) •  Goal: take out a large site with licle compuMng work •  DoS can happen at any layer •  Link •  TCP/UDP •  ApplicaMon •  DoS soluMons for one layer cannot always be replicated at other layers –  This means that DoS cannot be solved with end-­‐to-­‐end soluMons –  Need cooperaMon from the network 9 IP and TCP Headers 0 Version Flags Header Length Type of Service Total Length IdenMficaMon Fragment Offset Time to Live Protocol Header Checksum 31 0 Source Port Dest port 31 SEQ Number ACK Number (if ACK flag is set) U A P P S F R C S S Y I G K H R N N Source Address of OriginaMng Host DesMnaMon Address of Target Host Other headers Data OpMons Padding IP Data 10 5 9/16/15 TCP Handshake C S SYN, seq_
Listening… no = x
x+1 o =
ck_n
seq
SYN, seq_n
CK, a
y, A
=
o
_n
o = x+
1, ACK
, ack_n
Spawn thread, store data (connec7on state, etc.) Wait o = y+
1 Delayed segment from previous connecMon with seq_no=x+2 Connected RecommendaMon: Increment the iniMal sequence number every 4 ms (why?) 11 TCP Flow Control •  TCP uses a sliding window mechanism •  Receiver adverMses a window of size W •  Sender can send up W unacknowledged bytes –  Can be split among mulMple segments, if data is not yet available •  Receiver can delay sending ACKs unMl it has data to transmit –  ACKs will be piggybacked on the data packets –  ACK will correspond to the next byte it expects to receive => this may acknowledge mulMple packets received previously 12 6 9/16/15 DoS AZack #1: TCP SYN Flood S SYNspoofed source addr 1 Listening… SYNspoofed source addr 2 Spawn a new thread, store connec7on data SYNspoofed source addr 3 … and more SYNspoofed source addr 4 SYNspoofed1
source 5 MS Blaster (August 6, a2ddr 003): every infected machine sent 50 packets per second to port 80 on windowsupdate.com … and more … and more … and more … and more 13 SYN Flooding Explained •  Acacker sends many connecMon requests with spoofed source addresses •  VicMm allocates resources for each request –  New thread, connecMon state maintained unMl Mmeout –  Fixed bound on half-­‐open connecMons (backlog) •  Once resources exhausted, requests from legiMmate clients are denied •  This is a classic denial of service pacern –  It costs nothing to TCP iniMator to send a connecMon request, but TCP responder must spawn a thread for each request -­‐ asymmetry! 14 7 9/16/15 PrevenHng Denial of Service •  DoS is caused by asymmetric state allocaMon –  If responder opens new state for each connecMon acempt, acacker can iniMate thousands of connecMons from bogus or forged IP addresses •  Cookies ensure that the responder is stateless unMl iniMator produced at least two messages –  Responder’s state (IP addresses and ports of the connecMon) is stored in a cookie and sent to iniMator –  Aeer iniMator responds, cookie is regenerated and compared with the cookie returned by the iniMator 15 SYN Flooding Defense: SYN Cookies [Bernstein and Schenk] C S SYNC CompaMble with standard TCP; cookie looks like a sequence number Listening… SYNS, ACKS sequence # = cookie F(source addr, source port, dest addr, dest port, coarse Mme, server secret) F=AES or crypto hash ACKC sequence # = cookie+1 More info: hcp://cr.yp.to/syncookies.html Does not store state Cookie must be unforgeable and tamper-­‐proof Client should not be able to invert a cookie Recompute cookie, compare with with the one received, only establish connec7on if they match 16 8 9/16/15 AnH-­‐Spoofing Cookies: Basic PaZern •  Client sends request (message #1) to server •  Typical protocol: –  Server sets up connecMon, responds with message #2 –  Client may complete session or not -­‐ potenMal DoS! •  Cookie version: –  Server responds with hashed connecMon data in message #2 –  Client confirms by returning hashed data •  If source IP address is bogus, acacker can’t confirm –  Need an extra step to send postponed message #2, except in TCP (can piggyback on SYN-­‐ACK in TCP) 17 Domain Name Service (DNS) DNS maps symbolic names to numeric IP addresses (for example, www.umd.edu ↔ 54.83.56.209) www.umd.edu Client Local DNS recursive resolver ..edu
umd
.
w
ww
du NS e
NS umd.edu ww
w=
IPa
ddr
root DNS server edu DNS server umd.edu DNS server 18 9 9/16/15 DoS AZack #2: DNS AmplificaHon AZack x50 amplificaMon [Rossow’14] EDNS response (3000 bytes) DNS query SrcIP: DoS Target (60 bytes) DoS Source DNS Resolver DoS Target •  DNS runs over UDP (rather than TCP) => can spoof source IP •  Open DNS resolvers: answer queries from any host •  2006: 0.58M open resolvers on Internet (Kaminsky-­‐Shiffman) •  2013: 21.7M open resolvers (openresolverproject.org) •  March 2013: 300 Gbps DDoS acack on Spamhaus •  There are other protocols that amplify traffic (more on this later) 19 Other DNS VulnerabiliHes •  DNS servers can be DDoS’ed –  Oct ’02: ICMP flood took out 9 root servers for 1 hour •  Kaminski acack: poison DNS caches –  Acacker guesses transacMon ID used to match queries with replies –  SoluMon: randomize ports and transacMon IDs •  DNS implementaMons have vulnerabiliMes –  Reverse query buffer overrun in old releases of BIND –  MS DNS for NT 4.0 crashes on chargen stream •  Can use “zone transfer” requests to download DNS database and map out the network –  SoluMon: block port 53 on corporate name servers See hcp://cr.yp.to/djbdns/notes.html 20 10 9/16/15 Threat #3: Impersonate Other Hosts •  Goal 1: Defeat authenMcaMon that relies on IP-­‐source address –  Must spoof the source addres •  Goal 2: Draw packets desMned to other hosts –  Allows conducMng man-­‐in-­‐the-­‐middle acacks (more on this later) –  Must target the desMnaMon address 21 TCP ConnecHon Spoofing •  Each TCP connecMon has associated state –  Sequence number, port number •  TCP state is easy to guess –  Port numbers standard, seq numbers predictable •  Can inject packets into exisMng connecMons –  If acacker knows iniMal sequence number and amount of traffic, can guess likely current number –  How do you guess a 32-­‐bit sequence number? 22 11 9/16/15 “Blind” IP Spoofing AZack Trusted connecMon between Alice and Bob uses predictable sequence numbers  Packets received w/o connecMon establishment are discarded Alice Bob Œ Open connecMon to Alice to get iniMal sequence number Ž Send packets to Alice that resemble Bob’s packets •  Can’t receive packets sent to Bob, but can bypass Alice’s IP address-­‐based authenMcaMon –  rlogin and other remote access tools, SPF defense against spam 23 Intrusion DetecHon Systems (IDS) •  Hard to prevent all network acacks; can we detect them? –  Host-­‐based / Network-­‐based intrusion detecMon system (HIDS/NIDS) •  Misuse detecMon –  Use acack “signatures” (need a model of the acack) •  Sequences of system calls, pacerns of network traffic, etc. –  Must know in advance what acacker will do –  Can only detect known aZacks •  Anomaly detecMon –  Using a model of normal system behavior, try to detect deviaMons and abnormaliMes •  E.g., raise an alarm when a staMsMcally rare event(s) occurs –  Can potenHally detect unknown acacks 12 9/16/15 Intrusion DetecHon Errors •  False negaHves: acack is not detected –  Big problem in signature-­‐based misuse detecMon •  False posiHves: harmless behavior is classified as an acack –  Big problem in staMsMcal anomaly detecMon •  All intrusion detecMon systems (IDS) suffer from errors of both types •  Which is a bigger problem? –  Acacks are fairly rare events –  Thus IDS oeen suffer from the base-­‐rate fallacy CondiHonal Probability •  Suppose two events A and B occur with probability Pr(A) and Pr(B), respecMvely •  Let Pr(AB) be probability that both A and B occur •  What is the condiHonal probability that A occurs assuming B has occurred? Pr(AB) Pr(A | B) = Pr(B) 13 9/16/15 Bayes’s Theorem •  Suppose mutually exclusive events E1, … ,En together cover the enMre set of possibiliMes •  Then the probability of any event A occurring is Pr(A) = Σ1≤i≤n Pr(A | Ei) • Pr(Ei) •  IntuiMon: since E1, … ,En cover the enMre probability space, whenever A occurs, some event Ei must have occurred •  Can rewrite this formula as Pr(A | Ei) • Pr(Ei) Pr(Ei | A) = Pr(A) Base-­‐Rate Fallacy •  1% of traffic is SYN floods; IDS accuracy is 90% –  IDS classifies a SYN flood as acack with prob. 90%, classifies a valid connecMon as acack with prob. 10% •  What is the probability that a connecMon flagged by IDS as a SYN flood is actually valid? Pr(alarm | valid) • Pr(valid) Pr(valid | alarm) = Pr(alarm) Pr(alarm | valid) • Pr(valid) = Pr(alarm | valid) • Pr(valid) + Pr(alarm | SYN flood) • Pr(SYN flood) 0.10 • 0.99 = 0.10 • 0.99 + 0.90 • 0.01 = 92% chance raised alarm is false!!! 14 9/16/15 Review of Lecture •  What did we learn? –  IP spoofing –  TCP handshake and flow control –  TCP cookies –  Various eavesdropping and denial-­‐of-­‐service acacks –  Base rate fallacy •  Sources –  Vitaly ShmaMkov •  What’s next? –  Trustworthy compuMng 29 15