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 • 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
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”.
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
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
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
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
Hacking TCP: SYN Flooding Defenses Attack w/ semi-transparent gateway Legit connection w/ semi-transparent gateway
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
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
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
Hacking TCP: Congestion control tricks • Optimistic ACKing • Send acks for segments not yet received • Decrease perceived RTT, affecting CW growth. Segment acks Segs arrive
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
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
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
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
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 (?)
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
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.
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.
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
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.
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.
Hacking the stack: UDP reflectors • UDP • Application-specific • Quake Qstat • Counter-strike clients • DNS
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.
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.
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.
Hacking the stack: FTP reflectors • See previous lecture on server-to-server transfers
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.
Analyzing attacks • D. Moore, G. Voelker, S. Savage “Inferring Internet Denial-of-Service Activity”
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
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)
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.
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)
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
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”
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
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
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
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
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
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
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