1 / 50

IP hijacking

IP hijacking. Sagar Vemuri (slides, courtesy Z. Morley Mao and Mohit Lad). Agenda. What is IP Hijacking? Types of IP Hijacking Detection and Notification of IP Hijacking Accurate real-time identification of IP hijacking PHAS: A Prefix Hijack Alert System. routes. Control plane:

terrywagner
Download Presentation

IP hijacking

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. IP hijacking Sagar Vemuri (slides, courtesy Z. Morley Mao and Mohit Lad)

  2. Agenda • What is IP Hijacking? • Types of IP Hijacking • Detection and Notification of IP Hijacking • Accurate real-time identification of IP hijacking • PHAS: A Prefix Hijack Alert System

  3. routes Control plane: exchange routes Fail over to alternate route : Routing session Dynamic adaptation Internet Data plane: forward traffic IP traffic www.cnn.com IP=64.236.16.52 Prefix=64.236.16.0/20 Bear.eecs.umich.edu IP=141.212.110.196 Prefix=141.212.0.0/16

  4. What is IP Hijacking • Stealing IP addresses belonging to other networks • Also known as BGP Hijacking, Fraudulent origin attack • Achieved by announcing unauthorized prefixes on purpose or by accident

  5. IP Hijacking Example

  6. Motivation for IP hijacking • Conduct malicious activities • Spamming, illegal file sharing, advertising • Disrupt communication of legitimate hosts • DoS attacks • Inherent advantage • Hide attacker’s identities • Difficult for trace back

  7. Hijacked IP Space for selling

  8. MOAS • Multiple Origin AS • Conflicts arise if different origin ASes announce the same prefix • A prefix is usually originated by a single AS • But several legitimate conflicts also exist • multi-homing without BGP • using private AS numbers

  9. subMOAS • Subnet of an existing prefix is announced by a different origin AS • Example: AS1 announces 164.83.0.0./16 and AS2 announces 164.83.240.0/24 • Globally propagated and used • BGP uses longest prefix based forwarding of routes

  10. Classification of hijacking • Hijack only the prefix • Hijack both the prefix and the AS number • Hijack a subnet of an existing prefix • Hijack a prefix subnet and the AS number

  11. Hijacking only the prefix • Attacker announces the prefix belonging to other ASes using his own AS number. • Leading to MOAS (Multiple Origin AS) conflicts

  12. Hijack both the prefix and AS • Announce a path through itself to other ASes and their prefix • AS M announces a Path [AS M, AS 1] to reach prefix 141.212.110.0/24

  13. Hijack a subnet of an existing prefix • In previous attack models, the hijacker has to compete with victim to attract traffic. • Announcing only a subnet of other’s prefix avoids the competition altogether due to the Longest Prefix Matching rule of BGP • No apparent MOAS Conflicts in routing table! subMOAS!

  14. Hijack a subnet of a prefix and AS number • Announce a path to a subnet of one of victim AS’s Prefix • No subMOAS conflicts! Most stealthy with almost no abnormal symptom in routing table • Ability to receive all traffic because of longest prefix matching • Globally propagated and used

  15. Hijacking along a legitimate path • Path to the destination goes through the attacker’s AS • Violates the rule of forwarding traffic • Instead of forwarding the traffic, the attacker intercepts the traffic • Originates new traffic as if coming the legitimate source

  16. Prevention Techniques … 1 • Route Filtering • Analogous to ingress/egress filtering for traffic • Filter route announcements to preclude prefixes not owned by customers • Proper configuration of route filters at links b/w providers and customers

  17. Prevention Techniques … 2 • Difficulties with Route Filtering • Lack of knowledge of address blocks owned by customers • Difficult to enforce across all networks • Filtering impossible along peering edges • SHOULD be enforced properly by all the providers

  18. Prevention Techniques … 3 • Digitally sign routing updates • High overhead in terms of memory, CPU and additional management • Store a list of originating ASes • Such a list is unauthenticated and optional • Prefer a set of known stable routes over transient routes • Does not scale well to arbitrary routes

  19. Data plane and control plane • Control plane: controls the state of network elements • Route selection • Disseminate connectivity information • Optimal path selection • Data plane: determines data packet behavior • Packet forwarding • Packet differentiation (e.g., ACLs) • Buffering, link scheduling

  20. Consistency between them • Consistency • (Routing) state advertised by the control plane is enforced by the data plane • Inconsistency due to • Routing anomalies • Misconfigurations • Protocol anomalies • Malicious behavior • Main insight: use expected consistency to identify routing problems.

  21. Accurate real-time identification of IP hijacking Xin Hu Z. Morley Mao

  22. Approach • Goal: • Detect and thwart potential IP hijacking attempts • Light-weight and real-time detection • Approach: • Real-time monitoring and active/passive fingerprinting triggered by suspicious routing updates • Identify conflicting data-plane fingerprints indicating “successful” IP hijacking

  23. Methodology • Monitor all route updates in real time • Given suspicious updates, use data-plane fingerprinting to reduce false positive/negative rate • Our key insight: A real hijacking will result in conflicting fingerprints describing the edge networks

  24. Fingerprinting • Technique for remotely determining the characteristics or identity of devices • A given IP address in the hijacked prefix is used by different end hosts • Faking a fingerprint is extremely difficult and challenging

  25. Fingerprinting … 2 • Host-based • Operating System • Actual physical device • Host software • Host services • Network-based • Firewall properties • Bandwidth information

  26. Fingerprinting … 3 • The system employs four main type of fingerprints: • OS detection • IP ID probing • TCP round trip time • ICMP timestamp

  27. Probe place selection • From a single place, the probing packets can only reach either attacker’s or victim’s AS, not both. • To probe both, we need multiple probing points. • Use Planetlab, which consists of more than 600 machines all over the world. • Select probing places that are near the targets, in terms of AS path.

  28. Detection of hijacking a prefix • Candidates are prefixes that have MOAS conflicts. • Build path tree for the prefix: • Select Planetlab nodes near different origin ASes and probing live hosts in the prefix

  29. Detection of hijacking a prefix and AS number • Candidates are BGP Updates that violates • Geographical constraint • Edge popularity Constraint • The invalid path announced by attacker will be very likely to violate these constraint • Geographical location of prefixes and ASes can be obtained from a number of commercial and public database such as IP2Location, Netgeo • Netgeo Record for prefix 141.212.0.0/16 |141.212.0.0/16|237| COUNTRY: US NAME: UMNET2 CITY: ANN ARBOR STATE: MICHIGAN LAT: 42.29 LONG: -83.72

  30. Detection of hijacking a subnet of prefix -- Reflect scan If not hijacking, the reflected SYN/ACK packet will be sent to H2 IP ID value of H2 will increase During hijacking, the reflected SYN/ACK packet will not reach H2 IP ID value of H2will not increase.

  31. Detection of hijacking a prefix subnet and AS number • Candidate is every new prefix that is a subnet of some prefix in its origin AS. • To detect, combine • Geographical constraint • Reflect scan

  32. System architecture

  33. Classifier • For each BGP update, classifier decides whether it is a valid update and classify those invalid updates into separate types • Then feed the classification results to probing module for selecting proper probing methods

  34. Different signatures, example: • 63.130.249.0/24|63.130.249.1|1273 3561|1273:planetlab-1.eecs.cwru.edu 3561:node1.lbnl.nodes.planet-lab.org planetlab-1.eecs.cwru.edu: Interesting ports on 63.130.249.1: (The 1664 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 23/tcp open telnet 1214/tcp filtered fasttrack 6346/tcp filtered gnutella 6699/tcp filtered napster No exact OS matches for host … node1.lbnl.nodes.planet-lab.org: Interesting ports on 63.130.249.1: (The 1663 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 7/tcp open echo 9/tcp open discard 13/tcp open daytime 19/tcp open chargen 23/tcp open telnet No exact OS matches for host …

  35. K-root server results Local Machine [root@wing statistic]# nmap -O 193.0.14.129 Warning: OS detection will be MUCH less reliable because we did not find at least 1 open and 1 closed TCP port Interesting ports on k.root-servers.net (193.0.14.129): (The 1667 ports scanned but not shown below are in state: filtered) PORT STATE SERVICE 53/tcp open domain Device type: general purpose Running: Linux 2.4.X|2.5.X OS details: Linux 2.4.0 - 2.5.20 Uptime 26.048 days (since Thu Mar 23 06:17:24 2006) Nmap finished: 1 IP address (1 host up) scanned in 43.319 seconds Planetlab in China bash-2.05b# nmap -O 193.0.14.129 Interesting ports on k.root-servers.net (193.0.14.129): (The 1664 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 53/tcp open domain 179/tcp open bgp 2601/tcp open zebra 2605/tcp open bgpd Device type: general purpose Running: FreeBSD 5.X|6.X OS details: FreeBSD 5.2-CURRENT - 5.3 (x86) with pf scrub all, FreeBSD 5.2.1-RELEASE or 6.0-CURRENT Uptime 119.383 days (since Mon Dec 19 22:13:54 2005) Nmap finished: 1 IP address (1 host up) scanned in 15.899 seconds

  36. Limitations • No proper way to inform the owner of the legitimate prefix/AS • Accuracy of fingerprinting techniques • Choosing a probing location might be difficult

  37. PHAS: A Prefix Hijack Alert System Dan Massey and Yan Chen Colorado State University Mohit Lad, Lixia Zhang UCLA Beichuan Zhang University of Arizona

  38. Necessities for a viable Detection system • Ability to see the “bad” information • Use BGP Data Collectors (like RouteViews) • Ability to distinguish between “good” and “bad” information • Prefix owner knows legitimate origin, suballocations, and last hop. • Incentive to fix the problem if one is found • Prefix owner is affected directly

  39. Objectives of PHAS • Goal: Report origin changes • If a new origin appears, report immediately • Potential Attack • If an origin has not been in use for “some time”, report origin removal. • Attack stopped. • Prevent replay attacks. • Why not report origin removals immediately? • Origins very dynamic. • Most of the dynamics are legitimate.

  40. RouteViews based PHAS • Step 1: Monitor RouteViews BGP tables and updates in (near) Real-Time • Step 2: Keep a database of Origins used to reach each Prefix • Step 3: Report any change in Origins used to reach the Prefix • Step 4: Owner applies local filter rules to determine significance

  41. Components of PHAS

  42. Email Registration • The owner should first register with the PHAS to get notifications • Attacker registers as owner • PHAS alarms are based on public information • Attacker tries to unsubscribe or modify owner registration • Slice secret and send one part to each mailbox. Require all parts assembled to confirm change.

  43. 1:00 1:05 Origin Monitor P= 65.173.134.0/24 Path=D A Q P=65.173.134.0/24 Path=D X Data Collector D P= 65.173.134.0/24 Path=B A Q Origin set: Set of origins seen by all the monitors B Origin Set ALARM: Origin set for 65.173.134.0/24 changed {Q,X} Instantaneous origin set has lots of dynamics

  44. Message Delivery PHAS detects origin change for prefix 65.173.134.0/24 65.173.134.0/24 D A X 65.173.134.0/24 Q Hijacker True origin C B Alarm can be delivered to hijacker instead of true origin. Z Y RV PHAS Problem: One or more nodes on path from PHAS to origin could believe the hijacker.

  45. Multipath Delivery Origin specifies multiple “webmail” servers {A,B,C} as intermediate storage points A PHAS Origin B C ? Hijacker It is difficult for hijacker to compromise all paths, i.e. cut this graph.

  46. ? ? ? Message Delivery WebMail B 131.179.0.0/16 D A X 131.179.0.0/16 Q Hijacker C C is affected by hijack, but since WebMail A and B are not hijacked, C delivers to WebMail. UCLA B Z Y RV WebMail A PHAS If no mailbox can be reached, then ALARM raised

  47. Local Notification Filter • Deployed at the user side • Reduce false positives • Task 1: Deliver only one copy of alarm to mailbox. • Task 2: Simple Filter rules • IF ORIGIN-GAINED EQ 562 THEN REJECT • IF TYPE=LOSS THEN REJECT

  48. Customizing PHAS Notifications • PHAS Delivers Text Data in a Simple Format: SEQUENCE_NUMBER: 1160417987 TYPE: origin BGP-UPDATE-TIME: 1160396231 PHAS-DETECT-TIME: 1160414387 PHAS-NOTIFY-TIME: 1160417987 PREFIX: 60.253.29.0/24 SET: 30533 GAINED: LOST: 33697 • Readable By People, But Intended for Scripts • Script receives notifications and applies local policies

  49. Limitations • Cannot identify subnet hijacking attacks • Cannot identify last hop hijacks • Prefix in routing table: 131.179.0.0/16, with origin Q • Hijacker X announces a false link to Q. • Leave corrective action for prefix owner • Prefix owner knows what is legitimate and what is not.

  50. Conclusion • Both papers deal with detection of IP Hijacking • First appraoch: detects in Real-time • Second approach: might involve some delay • PHAS also sends notifications to the user to take corrective action • Can combine both the approaches to be more effective: detection + notification

More Related