1 / 90

CSE 524: Lecture 17

CSE 524: Lecture 17. Network security issues. Administrative. Programming assignment due Monday 12/1 Arrange with TA Final project due 12/10. Optional material. Hacking the stack: Network protocol attacks Hacking TCP Hacking routing Hacking ICMP Hacking DNS Reflector attacks

reese-cabrera
Download Presentation

CSE 524: Lecture 17

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CSE 524: Lecture 17 Network security issues

  2. Administrative • Programming assignment due Monday 12/1 • Arrange with TA • Final project due 12/10

  3. Optional material • Hacking the stack: Network protocol attacks • Hacking TCP • Hacking routing • Hacking ICMP • Hacking DNS • Reflector attacks • Analyzing attacks • Estimating DoS activity • Tracing the source of attacks • Traceback via traffic injection • Traceback via packet marking • Traceback via logging • Intrusion detection and response • Network IDS • Attacking the detectors

  4. Hacking the stack: Network protocol attacks • C. Schuba, I. Krsul, M. Kuhn, E. Spafford, A. Sundaram, D. Zamboni, "Analysis of a Denial of Service Attack on TCP" • S. Bellovin, "Security Problems in the TCP/IP Protocol Suite" • S. Bellovin, "Defending against sequence number attacks" • S. Bellovin, "Packets Found on an Internet" • R. Morris, "A Weakness in the 4.2BSD Unix TCP/IP Software“ • B. Cheswick, S. Bellovin, “A DNS Filter and Switch for Packet-filtering Gateways”. • S. Savage, N. Cardwell, D. Wetherall, T. Anderson, “TCP Congestion Control with a Misbehaving Receiver”.

  5. Hacking TCP: SYN Flooding • Attacker sends many connection requests w/ spoofed source addresses to victim • Victim allocates resources for each request • Finite # half-open connection requests supported • Connection requests exist for TIMEOUT period • Once resources exhausted, all other requests rejected Normal connection est. Syn Flooding attack

  6. Hacking TCP: SYN Flooding Defenses • System Configuration Improvements • Reduce timeout period • Increase length of backlog queue to support more connections • Disable non-essential services to make a smaller target • Router Configuration Improvements • Configure router external interfaces to block packets with source addresses from internal network • Configure router internal interfaces to block packets to outside that have source addresses from outside the internal network • TCP SYN cookies • Make handshake stateless on server end • Server makes ISN a function of a secret nonce it keeps and pieces of the SYN connection ID • Only create TCB and establish connection upon verifying client’s ACK

  7. Hacking TCP: SYN Flooding Defenses • Firewall as a Relay • Firewall answers on behalf of Destination • Once connection established, firewall predicts seq # and establishes 2nd connection to Destination • Disadvantage: Adds delay for every packet

  8. Hacking TCP: SYN Flooding Defenses • Firewall as a Semi-transparent Gateway • Forges the 3rd handshake (ack) from the client to the destination • This moves connection out of backlog queue, freeing resources • If this is attack, no “real” ack will happen • Destination will send RST packet terminating connection • If this is actual connection request the eventual ack will be ignored as a duplicate • Disadvantages: • Large # illegitimate open connections if system under attack • Must very carefully choose timeout periods

  9. Hacking TCP: SYN Flooding Defenses Attack w/ semi-transparent gateway Legit connection w/ semi-transparent gateway

  10. Hacking TCP: SYN Flooding Defenses • Active Monitor • Program that promiscuously monitors and injects network traffic to/from machines it is protecting • Monitors net for SYN packets not acknowledged after a certain period of time • If it detects problems with a half-open connection it can • Send RST packets to the sender to release destination resources • Complete the TCP connections by sending the ACK message • Similar to Semi-Transparent gateways

  11. Hacking TCP: Congestion control tricks • ACK Division • Receiver can acknowledge segments multiple times (up to #bytes acks) • Leads Sender to grow cwnd faster than normal. • Solution to ACK Division • Modify congestion control to guarantee segment-level granularity • Only increment MSS when a valid ACK arrives for the entire segment. Bunch of acks Burst 1 RTT later

  12. Hacking TCP: Congestion control tricks • Duplicate Ack Spoofing • Receiver sends multiple acks/sequence # • no way to tell what segment is being acked • Causes sender to enter fast-recovery mode and inflate cwnd • Solution to Duplicate Ack Spoofing • Add new fields to TCP headers. • “nonce & nonce-reply” – random values sent with segments and replies • Only increment cwnd for ACKs with previously unseen nonces Burst of dup acks Sender enters Fast Recovery and bursts 1 RTT later

  13. Hacking TCP: Congestion control tricks • Optimistic ACKing • Send acks for segments not yet received • Decrease perceived RTT, affecting CW growth. Segment acks Segs arrive

  14. Hacking TCP: Congestion control tricks • Solution to optimistic acking: Cumulative Nonce • Sender sends random number (nonce) with each packet • Segment size slightly randomized • Receiver sends cumulative sum of nonces • if receiver detects loss, it sends back the last nonce it received • Why cumulative? • Requires modifications to stack

  15. Hacking routing: RIP attacks • Attack • Intruder sends bogus routing information to a target and each of the gateways along the route • Impersonates an unused host • Diverts traffic for that host to the intruder’s machine • Impersonates a used host • All traffic to that host routed to the intruder’s machine • Intruder inspects packets & resends to host w/ source routing • Allows capturing of unencrypted passwords, data, etc

  16. Hacking routing: RIP attacks • Defenses • Paranoid gateway • Filters packets based on source and/or destination addresses • Don’t accept new routes to local networks • Messes with fault-tolerance but detects intrusion attempts • Authenticate RIP packets • Difficult in a broadcast protocol • Only allows for authentication of prior sender and doesn’t address information from a deceived gateway upstream

  17. Hacking ICMP • Attack • Targeted Denial of Service (DoS) • Attacker sends ICMP Redirect message to give a bogus route • Attacker sends Destination Unreachable or TTL exceeded messages to reset existing connections • Attacker sends fraudulent Subnet Mask Reply messages • Blocks communication with target • Defenses • Verify ICMP packet contains a plausible sequence # • Don’t modify Global Route Table due to ICMP Redirect messages • Disallow ICMP Redirects? • Check to see if multiple ICMPs from a host agree

  18. Hacking DNS • DNS : Domain Name System • BSD r* • rlogin, rcp, rsh use address based authentication (reverse lookup) • The problem • No authentication • Responses can contain entries that should not be trusted but are • Responses are cached • Attacks • Inject bogus DNS responses • Attach additional bogus entries in valid DNS responses (especially for internal names) Firewall * Application Resolver Local Name Server (Trusted) Remote Name Server (?)

  19. Hacking DNS • Solution: DNS Proxy • Filter • Drop malformed packets • Verify • Does the answer, really answer the query made? • Was the answer received from the appropriate server? • Proxy performs checks on the answers from outside DNS servers • Located within the firewall on a trusted host • Intercepts DNS queries, filters, modifies and forwards in appropriate direction

  20. Hacking the stack: Reflector attacks • A reflector is any IP host that will return a packet or more if sent a packet. • Reflector cannot easily locate the slave because of IP spoofing. • Examples: • Web servers: return SYN ACKS or RSTs in response to SYN or other TCP packets. • DNS servers: return query replies in response to query requests. • Routers: return ICMP Time Exceeded or Host Unreachable messages in response to particular IP packets.

  21. Hacking the stack: ICMP reflectors • ICMP echo, timestamp, address mask, router solicitation, information request/reply. • ICMP echo is widely used. • Smurf attacks • ICMP source quench, unreachable, time exceeded, parameter problem, and redirect. • Important ICMP messages: • Host unreachable. • Time exceeded. • Need fragmentation.

  22. Hacking the stack: TCP reflectors • TCP stack can be made to reflect via… • SYN ACK by sending an initial SYN. • Filtering leads to no-remote access. • RST by sending a FIN. • Filtering RST results in clogging of stale connections state

  23. Hacking the stack: TCP reflectors • Predictable TCP sequence numbers • If reflector stack has guessable TCP sequence numbers, it’s a DISASTER for the victim. • Attacker can drive the Reflector TCP state machine, making it send ACKs, data segments. • Attack can be amplified by transmitting large items and exploiting “ACK splitting” techniques.

  24. Hacking the stack: TCP for Transactions (T/TCP) reflectors • Spoof initial SYN packet with acceptable seq. no. • Make an expensive request. • Factors that limit the T/TCP attack • T/TCP server will begin in slow start. • Unless the server’s stack has predictable seq. no. • Amenable to stateless packet filtering. • T/TCP is not widely deployed.

  25. Hacking the stack: UDP reflectors • UDP • Application-specific • Quake Qstat • Counter-strike clients • DNS

  26. Hacking the stack: DNS reflectors • DNS • Reflector sending DNS reply in response to a spoofed DNS request. • Victim can configure its local DNS servers so as to filter out unknown DNS server responses. • If the victim is a name server • Attacker can query a large number of DNS servers which in turn recursively query the Victim. • Victim server gets bombarded due to multiple queries. • DNS queries needn’t even be spoofed. • Send valid queries to a large set of known DNS servers • Arbitrary names not just the ones responsible for • Caching at the reflector server doesn’t help. • Solution: Provide filtering in name servers so as to serve recursive queries from local addresses, coupled with ingress filtering.

  27. Hacking the stack: SNMP reflectors • SNMP (UDP-based request/reply) • Sites that fail to block off-site access to SNMP provide a large number of reflectors. • SNMP attack is sourced at port 161. • Filtering out the external SNMP messages leads to major problem for service providers. • Configure the filter to receive SNMP messages from interested hosts.

  28. Hacking the stack: HTTP reflectors • HTTP proxies • HTTP proxy caches provide a way that an HTTP client can manipulate a proxy server into initiating a connection to a victim web server. • HTTP proxy servers act as reflectors for the DDOS attacks. • HTTP - Limitations • Proxies can be configured to serve a restricted set of clients. • There are not enough proxy caches to constitute a large pool of possible reflectors. • Connection between slave and the reflector cannot be spoofed unless the reflecting proxy has predictable sequence numbers. Logging helps in identifying the slave’s location. • Definitely a major threat if servers running on stacks with predictable sequence numbers are widely deployed.

  29. Hacking the stack: FTP reflectors • See previous lecture on server-to-server transfers

  30. Hacking the stack: Gnutella • Gnutella attack • Provides a “push” facility that instructs the server to connect to a given IP address and port in order to deliver the Gnutella item. • Gnutella connection to the IP host is separated from the initial client making it impossible to trace back to the slave. • Fix • Modify the protocol to include path information with “push” directives • Gnutella could be a major problem for DDOS reflector attacks.

  31. Analyzing attacks • D. Moore, G. Voelker, S. Savage “Inferring Internet Denial-of-Service Activity”

  32. Analyzing attacks: Backscatter • Attackers spoof source address randomly • Small frequent packets. (packet/sec bottleneck) • e.g. TCP SYN -> victim allocate data structure for arriving packets (for unmatched to existing connections) • Victims, in turn, respond to attack packets • Remotely controlled “Zombies” for DDoS • Unsolicited responses (backscatter) equally distributed across IP space • Received backscatter is evidence of an attacker elsewhere

  33. From caida page

  34. From caida page

  35. Analyzing attacks: Backscatter • Backscatter analysis provides quantitative data for a global view on DoS activity using local monitoring • Videos • Traffic Characterisation (How Data Gathered) • http://www.caida.org/outreach/resources/animations/passive_monitoring/traffic_char.mpg (1min12s) • TCP Port Analysis • http://www.caida.org/outreach/resources/animations/passive_monitoring/tcp_port_analysis.mpg (2min15s) • Backscatter • http://www.caida.org/outreach/resources/animations/passive_monitoring/backscatter.mpg (1min26)

  36. Analyzing attacks: Assumptions • Address Uniformity • Reliable delivery • Backscatter not lost • Backscatter hypothesis • Unsolicited packets represent backscatter • In fact any server can send • Reflector attack may not be detected • Not random IP-forgery • Some attacks (e.g. TCP-RST) doesn’t produce backscatter.

  37. Analyzing attacks: Backscatter platform

  38. Analyzing attacks: Results • 13000 attacks in 3 weeks • 5000 victim IP addresses on 2000 domains • 200 million backscatter packets • *256 < Real attack packets • Most attacks short, some longer persistent ones • Mostly TCP (90-94%) • Some large ICMP storms (43% of all packets) • Attacks cover most ports, but HTTP and IRC singled out • How serious is this? • 500 packets enough to overwhelm server • 38-46 % of attacks (unif.-all) • 14000 packets enough to overwhelm firewall • 0.3-2.4 % of attacks (unif.-all)

  39. Analyzing attacks: Victim characterization • Entire spectrum of sites and businesses • Yahoo!, Amazon, CNN, etc. • Small attacks from personal vendettas • 10-20% targeted towards home machines • Attacks on infrastructure • 5% directed towards routers and root DNS servers

  40. Traceback • H. Burch, B. Cheswick, "Tracing Anonymous Packets to Their Approximate Source“ • S. Bellovin, M. Leech, T. Taylor, "ICMP Traceback Messages" • A. Mankin, D. Massey, C. Wu, S. Wu, L. Zhang, "On Design and Evaluation of "Intention-Driven" ICMP Traceback“ • A. Snoeren, C. Partridge, L. Sanchez, C. Jones, F. Tchakountio, S. Kent and W. Strayer, “Hash-Based IP Traceback”

  41. Traceback: Motivation • DoS attacks • IP spoofing • No one checks source IP address to drop spoofed packets • TCP SYN floods, Smurf (ICMP echo to broadcast addresses) • Difficult to get the help of upstream ISP • Lack skill • Lack resources (might be 6pm on Friday) • In a different country (speak different language, etc) • Require automatic way of identifying where the traffic is coming from without human intervention

  42. Traceback: Problem • Goal • Given set of packets • Determine path • Assumptions • Most routers remain uncompromised • Attacker sends many packets • Route from attacker to victim remains relatively stable A1 A2 A3 A4 A5 R6 R7 R8 R9 R10 R12 V

  43. Traceback: schemes • Record Route • Traffic injection • ICMP Trace (ITRACE) • Probabilistic packet marking • Logging and query • Source Path Isolation Engine (SPIE) • Reverse ITRACE • Subverting Traceback schemes

  44. Traceback: Record Route • Record path • Each router adds IP address to packet • Victim reads path from packet • Problem • Requires space in packet • Path can be long • No extra fields in current IP format • Changes to packet format are not practical

  45. Traceback: Traffic injection • Create a map of routes from victim to every network • Burst TCP/UDP packets to each and see if you are affected • TCP/UDP chargen service • Generates continuous data to anyone who connects to service • If DoS stream perturbed, you have a candidate • Problems • Finding open chargen service • Asymmetric routing • Must generate sufficient load to perturb stream especially when there are multiple attacking hosts • Easy to thwart • Vary source of attack by altering frequency of packets • Attack from many sources • Still can’t turn attacker’s off…Must notify upstream ISP to stop

  46. Traceback: Leverage volume of attack (Part 1) • Many packets • DDoS involves many packets on same path • Have routers periodically send message to victim • Each router sends message to Victim for every X packets it forwards to victim A1 A2 A3 A4 A5 R6 R7 R8 R9 R10 R12 V

  47. Traceback: ICMP trace • ICMP traceback messages • Routers periodically issue traceback ICMP messages to destination • Send 1 message for every 20000 packets forwarded to destination • 0.1% overhead • Similar to RouteRecord, collects intermediate hops along the way to destination • Over time, leaves a trail of where packets are being sourced from • Problems • Skilled attacker spoofing traceback messages to conceal the real source of attack • Requires some signature and trust management • Skilled attacker uses zombies to flood each other along with victim to reduce the amount of traceback messages sent • “Background noise” • Only want traceback messages from far away

More Related