Basic Internet Services

In this section, we discuss the basic services offered by most ISPs as part of a general Internet connectivity product. We cover common mistakes regarding assignment and registration of IP addresses and Autonomous System Numbers (ASNs), as well as little-known security issues regarding Internet routing and border router security.

IP Address (Prefix) Assignment and Registration

In addition to acquiring physical connectivity to an ISP (which is covered in detail in Chapter 4), an organization must acquire a block of IP addresses (IP prefix), as a direct allocation from the American Registry for Internet Numbers (ARIN) or as a reassignment from the ISP. In either case, proper registration of the IP prefix is critical to ensure that miscreants cannot alter the data.

Note 

North American organizations obtain IP addresses through ARIN, while South American organizations are served by Latin American and Caribbean Network Information Center (LACNIC). Asian organizations are served by Asia Pacific Network Information Center (APNIC), and European organizations are served by RIPE Network Coordination Center (RIPE NCC). Northern Africa is served by RIPE NCC, and Southern Africa is served by ARIN.

Both ISPs and ARIN require an organization to submit justification for the size of IP prefix they are requesting. Each ISP has different processes for organizations requesting IP addresses, while ARIN has strict guidelines and processes, which are documented on its web site under "Registration" on the home page (http://www.arin.net/registration/index.html).

When submitting information regarding the IP prefix, the ISP or organization should utilize role accounts for all point of contact (POC) records and contact handles, as they are outlined in Request for Comments (RFC) 2142. Role accounts are e-mail aliases within the organization's mail system that are populated with one or more employees who monitor the mailbox/distribution list. While this RFC does not specifically deal with ARIN registration data, the same concept applies here. The following data depicts a properly registered IP prefix as it would appear in the ARIN database.

 OrgName:    Internet Assigned Numbers Authority OrgID:      IANA Address:    4676 Admiralty Way, Suite 330 City:       Marina del Rey StateProv:  CA PostalCode: 90292-6695 Country:    US NetRange:   192.0.2.0 - 192.0.2.255 CIDR:       192.0.2.0/24 NetName:    IANA NetHandle:  NET-192-0-2-0-1 Parent:     NET-192-0-0-0-1 NetType:    Reassigned Comment:    Please see RFC 3330 for additional information. RegDate: Updated:    2002-10-14 OrgAbuseHandle: IANA-IP-ARIN OrgAbuseName:   Internet Corporation for Assigned Names and Number OrgAbusePhone:  +1-310-301-5820 OrgAbuseEmail:  abuse@iana.org OrgTechHandle:  IANA-IP-ARIN OrgTechName:    Internet Corporation for Assigned Names and Number OrgTechPhone:   +1-310-301-5820 OrgTechEmail:   abuse@iana.org 

In this example, we draw your attention to the contact handles: Technical and Abuse. These list role accounts rather than individuals within the organization. One of the most important aspects of registering an IP prefix is to provide organizational contact information that is not related to a specific individual. For instance, let us assume a network administrator within an organization has registered a prefix under the organization's name , but has registered his or her own personal information for the contact handles. Let us further assume that this administrator becomes disgruntled and leaves the organization, or is terminated . If this employee were so inclined, he might contact ARIN (as the organization's supposed technical contact), and request changes such as organizational name and contact information, or even return the prefix to ARIN for reallocation to another organization! This is a somewhat rare case but it is possible. ARIN certainly has guidelines in place to help prevent situations such as this, but ISPs and organizations should attempt to mitigate the risk of unauthorized data modification using this method.

Organizations should also ensure that the company name, street address, and telephone numbers are correct and current. This aids in authenticating individuals making changes to the data.

Autonomous System Number Assignment and Registration

An ASN is a unique number that is used in dynamic routing protocols to identify a set of routers under a single "administrative control." Put another way, an ASN is used as a means of identifying a path between networks to reach a final destination IP prefix. The most current allocation and use of AS numbers may be found on the Internet Assigned Numbers Authority (IANA) web site (http://www.iana.org/assignments/as-numbers/).

Organizations obtain an ASN directly through ARIN. Procedures and templates for requesting an ASN may be found on ARIN's web site, under "Registration" (http://www.arin.net/registration/index.html). When submitting registration information for the ASN, we suggest following the same guidelines regarding role accounts as outlined in the previous section. The risk of data modification applies to ASNs just as it applies to IP prefixes. The following data depicts a properly registered (but fictitious) ASN as it would appear in the ARIN database:

 OrgName: Internet Assigned Numbers Authority OrgID:      IANA Address:    4676 Admiralty Way, Suite 330 City:       Marina del Rey StateProv:  CA PostalCode: 90292-6695 Country:    US ASNumber:   65535 ASName:     IANA-RSVD2 ASHandle:   AS64512 Comment: RegDate:    1995-04-06 Updated:    2002-09-12 OrgAbuseHandle: IANA-IP-ARIN OrgAbuseName:   Internet Corporation for Assigned Names and Number OrgAbusePhone:  +1-310-301-5820 OrgAbuseEmail:  abuse@iana.org OrgTechHandle:  IANA-IP-ARIN OrgTechName:    Internet Corporation for Assigned Names and Number OrgTechPhone:   +1-310-301-5820 OrgTechEmail:   abuse@iana.org 

By utilizing role accounts for POC and contact handles as shown in the IP prefix example, ISPs and organizations can mitigate the risk of unauthorized modification.

Internet Routing

Internet routing can be likened to the postal service for delivering mail. The postal service "routes" mail starting with a high-level aggregation by state, followed by a more specific designation by city, followed by even more specific designations of street, numeric address, and finally person (name). Internet routing follows this same pattern starting with a high-level aggregation by IP prefix (assigned to a specific ISP or directly to an organization), then more specifically within the ISP or organization's network to a geographic region ( generally ), then even more specifically to a customer. Finally, the most specific designation of a single IP address is followed. In this section, we primarily focus on the basic function of border gateway protocol version 4 (BGP4, documented in RFC 1771). We cover more advanced routing techniques, risks, and mitigation in Chapter 4.

In Figure 1-1, we depict hierarchical routing as described above. Traffic from Client 1 is destined for www.example.com (192.0.2.10).

image from book
Figure 1-1: Example hierarchy of Internet routing

Client 1 follows a route for 192.0.2.0/24 to ISP B. ISP B forwards packets to ISP A, following the same route for 192.0.2.0/24. ISP A has three more specific routes within the 192.0.2.0/24 prefix. The destination falls within the prefix 192.0.2.0/25, therefore ISP A forwards packets to example.com, and within example.com's network, packets are forwarded to the destination host www.example.com (192.0.2.10).

Routing with Border Gateway Protocol (BGP)

BGP is an inter-Autonomous System routing protocol. Networks utilizing BGP actually use an Interior Gateway Protocol (IGP), such as Open Shortest Path First (OSPF) or Intermediate System to Intermediate System (IS-IS), for hop-by-hop routing within an AS, while using BGP to determine the "exit gateway(s)" at the edge of a network to forward a packet on towards the destination IP prefix.

In Figure 1-2, we depict route announcements through a gateway, and traffic flow following route announcements through that gateway.

image from book
Figure 1-2: Example of exit gateways within an ISP network

BGP-speaking routers exchange prefixes with each other, including common prefix attributes such as:

  • The IP prefix and the netmask /length (i.e., 192.168.0.0/16, 10.0.0.0/8)

  • The AS that the prefix originated from (or that the prefix belongs to)

  • The AS path (the ASs that the prefix can be reached through, in order, from origin to current AS)

  • The IP address of the gateway to the next -hop AS (known as the exit point, or inter-AS exchange point)

An organization may choose to have an ISP provide routing for its IP prefix, or the organization may obtain an ASN and perform routing between themselves and one or more ISPs. The following example depicts common attributes for the IP prefix 192.0.20.0/24 (note: this is not a routed prefix but is used for discussion purposes only):

 192.0.2.0/24 4513 5650 65535     195.66.224.82 from 195.66.224.82 (209.10.12.222)       Origin IGP, localpref 100, valid, external 

The first line displays the prefix and netmask length. The second line displays the AS path, which is interpreted from right to left with the origin AS on the far right. In this case, AS 65535 is the originator of this particular prefix. AS 65535 announces the prefix to AS 5650, which in turn announces the prefix to AS 4513. Finally, AS 4513 announces to our router that we have obtained this information. The third line displays (from left to right) the next-hop IP gateway (exit point), and the IP address of the router that announced this prefix. The fourth line contains some of the other attributes of the prefix that are not as relevant to this discussion.

In Chapter 2 we discuss advanced routing mechanisms, and the security risks and mitigation techniques related to them.



Extreme Exploits. Advanced Defenses Against Hardcore Hacks
Extreme Exploits: Advanced Defenses Against Hardcore Hacks (Hacking Exposed)
ISBN: 0072259558
EAN: 2147483647
Year: 2005
Pages: 120

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net