Accurate Real-time Identification of IP Hijacking. Presented by Jacky Mak

Transcription

1 Accurate Real-time Identification of IP Hijacking Presented by Jacky Mak

2 Outline Problem and Objectives Interdomain Routing and BGP Basics Attack Model of IP Hijacking Real-time Detection Techniques Implementation Evaluation Conclusion and Critique

3 The Problem What is IP hijacking? Stealing IP addresses belonging to other networks to: Conduct malicious activities such as spamming and DoS attacks Disrupt the reachability of legitimate hosts in the stolen addresses Also known as BGP (Border Gateway Protocol) hijacking or fraudulent origin attacks

4 The Problem IP hijacking is not difficult! The current BGP protocol (RFC 4271) [1] implements little authentication and assumes a significant level of trust between peering ASes IP hijacking may occur if an autonomous system (AS) advertises a prefix that it is not authorized to use either on purpose or by accident

5 The Problem Public incidents: Feb 2008: Pakistan's attempt to block YouTube access within their country takes down YouTube entirely [2] Jan 2006: Con-Edison hijacks big chunk of the Internet [3] Dec 2004: TTNet in Turkey pretends to be the entire Internet [4] Apr 1997: The misbehaving AS7007 brings down the whole Internet [5]

6 The Problem Network providers could preclude customers from announcing routes for prefixes that they do not own. However: Providers do not always know which address blocks their customers own Route filtering is impossible along peering edges because the information about the peers customers are often not available As long as there is one provider that does not enforce filtering, IP hijacking can still occur

7 The Objectives We want a solution to detect IP hijacking with these properties: Timeliness detect suspicious routing updates as soon as they occur Accuracy minimize both false positives and false negatives Scalability does not require too much resources to monitor a large number of routing updates in real time Practicability can be incrementally deployed without modifying infrastructure nor requiring support from networks

8 Interdomain Routing and BGP Basics Autonomous System (AS) A set of routers that has a single routing policy, and that run under a single technical administration Viewed as a single entity from the outside world Each public AS has a unique number (ASN) assigned by IANA. See RFC 1930 ASNs were 16-bit until early 2007; 32-bit ASN is described in RFC 4893 Routing information is exchanged between ASes via an exterior gateway protocol such as BGP

9 Interdomain Routing and BGP Basics Autonomous System (AS) Stub AS an AS that is connected to only one other AS Multihomed AS an AS that is connectioned to more than one AS Transit AS an AS that provides connections through itself to separate networks. ISPs are always transit ASes. Peering voluntary interconnection of ASes for the purpose of exchanging traffic without each party paying the other

10 Interdomain Routing and BGP Basics Autonomous System (AS) Tier-1 ISPs backbones Tier-2 ISPs Tier-3 ISPs

11 Interdomain Routing and BGP Basics BGP Allows a subnet to advertise its existence to the rest of the Internet and how to get there ASes exchange routing information over TCP connections over port 179 ASes determine good routes to subnets based on the reachability information and on AS policies

12 Interdomain Routing and BGP Basics BGP Uses path vector routing instead of link-state routing (OSPF) or distance-vector routing (RIP)

13 Interdomain Routing and BGP Basics The global routing table has over 200,000 entries as of later 2006

14 Attack Model of IP Hijacking Type-1: Hijack a prefix Type-2: Hijack a prefix and its AS Type-3: Hijack a subnet of a prefix Type-4: Hijack a subnet of a prefix and its AS Type-5: Hijack along a legitimate path

15 1: Hijack a Prefix The attacker announces the ownership of IP indexes that belong to some victim ASes Multiple Origin AS (MOAS) conflicts in routing table the same prefix appears to have originated from both the original owner s AS and the hijacker s AS

16 1: Hijack a Prefix

17 1: Hijack a Prefix

18 2: Hijack a Prefix and its AS The attacker announces a route to a prefix with an AS path that traverses its own AS to reach the victim There is no MOAS conflict, but the route is still invalid The attacker can easily intercept, modify, and insert traffic

19 2: Hijack a Prefix and its AS Fake AS edge or routing policy violation

20 3: Hijack a Subnet of a Prefix Similar to type 1, except the attacker only announces a subnet of an existing prefix There is no directly observable MOAS without examining its supernet prefix submoas

21 3: Hijack a Subnet of a Prefix

22 3: Hijack a Subnet of a Prefix

23 4: Hijack a Subnet of a Prefix and its AS The attacker announces a path to reach the victim AS and a subnet of this AS s prefix Most difficult to detect because it introduces neither MOAS nor submoas

24 4: Hijack a Subnet of a Prefix and its AS

25 5: Hijack along a Legitimate Path Instead of forwarding the traffic to the expected next-hop network, the attacker intercepts traffic and originates traffic using the address block of the downstream network Merely violate the rule of forwarding traffic based on its advertised route Can be identified by traceroute easily

26 Real-time Detection Techniques Fingerprinting-based consistency checks Type 1: Detection of prefix hijacking Type 2: Detection of prefix and AS hijacking Type 3: Detection of prefix subnet hijacking Type 4: Detection of prefix subnet and AS hijacking

27 Fingerprinting-based Consistency Checks (FP Checks) When IP hijacking occurs, a given IP address in the hijacked prefix may be used by different end hosts We can check the consistency of destination hosts by verifying whether their properties match Two types of fingerprints: host-based and network based

28 Fingerprinting-based Consistency Checks (FP Checks) Host OS properties Nmap [6] Starting Nmap 4.03 ( ) at :29 HKT Insufficient responses for TCP sequencing (0), OS detection may be less accurate Interesting ports on fortress.cse.cuhk.edu.hk ( ): (The 1668 ports scanned but not shown below are in state: closed) PORT STATE SERVICE VERSION 80/tcp open http Apache httpd 2 137/tcp filtered netbios-ns 138/tcp filtered netbios-dgm 139/tcp filtered netbios-ssn 443/tcp open ssl/http Apache httpd /tcp filtered pptp Device type: general purpose Running: Sun Solaris 10 OS details: SunOS 5.10 (sparc) Nmap finished: 1 IP address (1 host up) scanned in seconds Difficulties: probe duration, load-balanced hosts, firewall,

29 Fingerprinting-based Consistency Checks (FP Checks) IP Identifier probing

30 Fingerprinting-based Consistency Checks (FP Checks) IP Identifier probing IP ID should be unique for each IP datagram with the same source-destination to facilitate IP fragment reassembly A common implementation is global IP ID, i.e., incrementing IP ID by 1 for every packet sent, regardless of the destination IP Difficulties: some systems use random IP ID or reset it to be 0; some systems set IP ID to unique across every connection or peer; not applicable if DF (Don t Fragment) flag is set

31 Fingerprinting-based Consistency Checks (FP Checks) IP Identifier probing hping [7] hping2-rc3]# hping -c 5 HPING (eth ): NO FLAGS are set, 40 headers + 0 data bytes len=46 ip= ttl=250 DF id=6153 sport=0 flags=ra seq=0 win=0 rtt=1.9 ms len=46 ip= ttl=250 DF id=6154 sport=0 flags=ra seq=1 win=0 rtt=1.7 ms len=46 ip= ttl=250 DF id=6155 sport=0 flags=ra seq=2 win=0 rtt=1.7 ms len=46 ip= ttl=250 DF id=6156 sport=0 flags=ra seq=3 win=0 rtt=2.0 ms len=46 ip= ttl=250 DF id=6157 sport=0 flags=ra seq=4 win=0 rtt=1.8 ms hping statistic packets tramitted, 5 packets received, 0% packet loss round-trip min/avg/max = 1.7/1.8/2.0 ms [root@labsupport hping2-rc3]# hping -c 5 HPING (eth ): NO FLAGS are set, 40 headers + 0 data bytes len=46 ip= ttl=252 DF id=6158 sport=0 flags=ra seq=0 win=0 rtt=20.0 ms len=46 ip= ttl=252 DF id=6159 sport=0 flags=ra seq=1 win=0 rtt= ms len=46 ip= ttl=252 DF id=6160 sport=0 flags=ra seq=2 win=0 rtt=639.0 ms len=46 ip= ttl=252 DF id=6161 sport=0 flags=ra seq=3 win=0 rtt=58.2 ms len=46 ip= ttl=252 DF id=6162 sport=0 flags=ra seq=4 win=0 rtt=673.7 ms hping statistic packets tramitted, 5 packets received, 0% packet loss round-trip min/avg/max = 20.0/573.0/ ms

32 Fingerprinting-based Consistency Checks (FP Checks) TCP timestamp probing The TCP timestamp option specified by RFC 1323 [8] used for measuring round-trip times, but it can also be used to estimate the uptime of the target host TCP timestamp is set based on the internal clock of the machine s TCP network stack which is reset upon system reboot This virtual clock runs at a certain frequency ranging from 1Hz to 10kHz Knowing the frequency and the TCP timestamp, the system uptime can be inferred

33 Fingerprinting-based Consistency Checks (FP Checks) ICMP timestamp probing The ICMP timestamp reply contains the system time of the target host reported in millisecond [9] Since many hosts are not synchronized with NTP, we can expect two different hosts likely to have noticeable differences in their clock and hence in their ICMP timestamp replies Difficulties: many hosts do not reply to ICMP timestamp requests

34 Detection of Prefix Hijacking 1. For each prefix involved in MOAS conflicts, find all paths reaching the prefix 2. Build an AS path tree, rooted at the prefix 3. Find a live host if possible in the prefix serving as the probing target 4. Select probe locations so that packets traverse different AS paths and reach conflicting origin ASes 5. Perform FP checks 6. Analyze obtained fingerprints to check for mismatches implying potential IP hijack attacks

35 Detection of Prefix Hijacking Challenge: how to select probe locations such that probe traffic goes into different origin ASes? Use the current best AS paths from publicly available BGP data to guide the selection Probe locations should be as close to the original ASes as possible Difficulties: Incomplete routing data to predict AS-level paths Limited probe locations

36 Detection of Prefix and AS Hijacking Edge popularity constraint: Suspicious if the AS edge has never been observed in other route announcements or there are few prefixes using routes traversing this edge Geographic constraint: BGP peering sessions between two ASes almost always occur between routers colocated, but a fake AS edge can connect two geographically distant networks Relationship constraint: Use inferred AS relationship to identify obvious violations of routing policies within the AS paths

37 Detection of Prefix Subnet Hijacking Customer-provider check: Providers will not intentionally hijack customer s routes due to lack of economic incentives Customers are incapable of hijacking provider s routes because traffic needs to first traverse the provider s network, and providers can easily detect such routing announcements Unlike peer to peer relationships, customer provider relationships can be viewed as transitive No AS path can traverse a customer-provider edge after a provider-customer or peer-peer edge No path can go through more than one peer-peer edge

38 Detection of Prefix Subnet Hijacking Customer-provider check (continued): Edges appearing before the tier-1 AS in the AS path are all customer-provider edges ( up edges) and edges appearing after the tier-1 AS must be all providercustomer edges ( down edges) Legitimate AS paths must be valley-free Given the prevalence of AS paths containing tier-1 ISPs, this check reduces false positives of submoas cases with very low false positives Low overhead and suitable for real-time monitoring Does not deal with conflicts involving two provider ASes who do not have a customer-provider relationship, so we need to resort to fingerprinting for the remaining cases

39 Detection of Prefix Subnet Hijacking Reflect scan: Make use of predictable IP ID increment IP packet and IGP routing within victim AS which is unaffected by polluted BGP updates Use IP spoofing to solicit traffic inside the victim AS The target host will respond differently depending on whether the submoas is caused by hijacking Difficulties: Need to identify a relatively idle host in the hijacked prefix There is no ingress filtering for spoofed packets

40 Reflect Scan when Hijacking Occurs

41 Reflect Scan without Hijacking

42 Detection of Prefix Subnet and AS Hijacking Continuously monitor new prefixes that are subnets of existing prefixes in the routing table Apply similar checks for type-2 attacks: edge popularity constraints, geographic constraints, and relationship constraints (EGR constraints) Apply reflect scan probing to deal with the remaining cases that violates the previous checks We can still achieve real-time monitoring given that the space of suspicious cases for this attack type only include new prefixes not present in the current routing tables

43 Summary of Detection Techniques

44 Implementation System Architecture: Monitor module: processes BGP updates in real time to identify potential IP hijacking Probing module: takes input from the Monitor module and selects corresponding probing techniques. It chooses the appropriate probing locations and launches probing to the target prefix Detection module: analyzes and compares the probe results to identify real hijacking incidents

45 Implementation System architecture:

46 Implementation Classification of hijack types:

47 Implementation BGP data set: University of Oregon RouteViews Server [10] peering with 57 BGP routers in 46 different ASes: Larger coverage but 2-hour lag Used to evaluate the prototype system s scalability and efficiency in processing large number of BGP updates University of Michigan s route monitor peering with 7 BGP routers in 7 distinct ASes including academic and commercial networks: Smaller coverage but real time updates Used to study timely responses to anomalous updates

48 Implementation Probe location selection: Planetlab [11] testbed is used as the probing places for both type-1 and type-2 atackes 642 machines in 179 different ASes including 3 tier-1 ISPs Able to find probing locations for 89% MOAS cases and 75% type-2 attack cases Reflect scans can be conducted anywhere as long as IP spoofing is not blocked

49 Implementation Live IP addresses for probing: Collected by combining locally collected DNS and Web server logs Used reverse DNS to look up authoritative DNS servers and mail servers of various domains Used light-weight ping sweeps for a very limited address range if unable to find a live host from the list 1,165,845 unique IP addresses collected: allowing to find 70.3% target hosts for all prefixes in MOAS conflicts, 55.2% for type-2 attacks, 71.0% for submoas conflicts, and 90.1% for type-4 attacks

50 Implementation Geographic information of prefixes: Used the NetGeo [12] database to map IP addresses and AS numbers to geographic locations NetGeo returned detailed longitude and latitude values for 98.4% of 198,146 prefixes queried

51 Evaluation System Performance Update rate: Maximum: 12 updates/second Minimum: < 1 update/second Average: 2.45 updates/second A workstation machine can easily handle such update rates for many BGP feeds

52 Evaluation System Performance Anomaly rate:

53 Evaluation System Performance Probing time: In general, probing takes less than 10 minutes Average time is less than 3 minutes for Nmap and 4 minutes for reflect scan

54 Evaluation System Performance Memory usage: The prototype system is implemented using both Perl and C and runs on a desktop computer with P4 3.2GHz CPU and 1.5GB memory For RouteViews data, it uses 66% of total memory For real-time BGP data, it uses less than 7% of total memory

55 Evaluation Feasibility of probing techniques: IP ID probing: for each OS, we can always select appropriate probing technique to ensure the IP ID reply is globally sequential TCP/ICMP timestamp probing: both ICMP and TCP timestamp are supported by all of them except Windows XP and Cisco routers. Some routers also disable ICMP timestamp replies.

56 Evaluation Feasibility of probing techniques:

57 Evaluation Effectiveness of customer-provider checking: Using a tier-1 ISP list obtained based on [13], on average 84.4% of all AS paths in RouteViews data contains at least one tier-1 AS, and this increases to than 96% for the locally collected BGP data. Therefore the proposed customer-provider heuristic is fairly effective at eliminating valid submoas conflicts, also demonstrated in Table II.

58 Evaluation Monitoring results: Obtained from over 111 hours of real-time monitoring across 8 days. The rate is averaged over all 7 feeds monitored:

59 Evaluation Suspicious MOAS conflicts:

60 Evaluation Suspicious type-2 attacks:

61 Evaluation Suspicious type-2 attacks:

62 Evaluation Suspicious submoas attacks: Prefix /24 is announced by AS15390 at 21:27 April 25th, 2006, which has a submoas conflict with prefix /16 owned by AS8517:

63 Conclusion A framework for accurate, real-time IP hijacking detection Based on the insight that a real hijacking attack will result in conflicting data-plane fingerprints describing the hijacked network Significantly reduce false positives without sacrificing efficiency Can be incrementally deployed without modifying any infrastructure nor requiring support from networks

64 Further Works and Critique FP efficiency and difficulties caused by firewalls and load balancing Limited by the availability of suitable probing locations Continuous monitoring? Performance-triggered probing? How to notify the victim?

65 References [1] RFC 4271 Border Gateway Protocol 4 (BGP-4) [2] Pakistan hijacks YouTube [3] Con-Ed Steals the 'Net [4] TTNet in Turkey hijacks the Internet [5] Murphy's Law Strikes Again: AS [6] Nmap [7] hping

66 References [8] RFC 1323 TCP Extensions for High Performance [9] RFC 792 Internet Control Message Protocol [10] University of Oregon Route Views Archive Project [11] PlanetLab [12] NetGeo The Internet Geographic Database [13] Subramanian et al. Characterizing the Internet hierarchy from multiple vantage points. In Proc. IEEE INFOCOM, 2002.