DISCOVERY

Within the vast sea of the Internet, targets are easy to find. Most all networks advertise the Internet service provider (ISP) they depend on as well as their design, configuration, hardware types, and potentially vulnerable holes. Keep in mind that most of the normal discovery techniques for information gathering are noninvasive and usually are no more illegal then rattling door handles to check whether doors are open . Depending on the attacker's intensions and the target's legal resources, most find these will be hard, if not impossible , to prosecute .

Detection

Methods of detection can vary; primary detection consists of gathering privileged information without alerting the target. Depending on the target, many techniques will go unnoticed.

Profiling

Partially unobtrusive profiling via port scanning can be performed with a variety of tools, most of which we have discussed in previous chapters. traceroute, netcat, nmap, and SuperScan are some recommended tools to detect and identify devices on your network. Depending on the target of the detection process, many discovery techniques can be seen and logged by an intrusion detection system (IDS). Keep your detection footprint simple and to the point. Most information can be found from the simplest of sources.

dig

Popularity:	10
Simplicity:	10
Impact:	3
Risk Rating:	3

dig is an updated replacement for nslookup primarily in the UNIX environment. dig is a very simple tool. Using the easy command-line parameters, one can gather wonders of information about a target's domain names . Here, we can see http://example.com relies on bigisp for its DNS service. We can see http://example.com has redundant e-mail servers. Both mail server entries seem to point to the same IP address. This could be some type of mail server load balancing or custom setup, although it's more likely an administrator misconfiguration. dig gives us a nonintrusive and mostly undetectable look into http://example.com and its dependents.

 [e-mail]:~# dig -t mx example.com ; <<>\> DiG 9.1.3 <<>\> -t mx example.com ;; global options: printcmd ;; Got answer: ;; ->\>HEADER<<opcode: QUERY, status: NOERROR, id: 5278 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 4 ;; QUESTION SECTION: ;example.com.                        IN      MX ;; ANSWER SECTION: example.com.                 34      IN      MX       0 mx2.serv.net. example.com.                 34      IN      MX       0 mx1.serv.net. ;; AUTHORITY SECTION: example.com.                 34      IN      NS       dns2.bigisp.com. example.com.                 34      IN      NS       dns.bigisp.com. ;; ADDITIONAL SECTION: mx1.serv.net.         86176  IN      A       172.32.45.7 mx2.serv.net.         86151  IN      A       172.32.45.7 dns.bigisp.com.       172534 IN      A       192.168.15.9 dns2.bigisp.com.      172534 IN      A       192.168.15.9 ;; Query time: 2 msec ;; SERVER: 127.0.0.1#53(0.0.0.0) ;; WHEN: Mon Nov 24 1:00:01 2002 ;; MSG SIZE rcvd: 188 

As you can see here, a number of DNS entries have come back that indicate multiple MX, NS, and A records present in the name server. MX records are the DNS entries that map the domain name to a particular mail server. NS records are the name servers that are authoritative for that domain (http://www.example.com). And A records are Address records that map a DNS name (such as mx1.serv.net) to a particular IP address (such as 172.32.45.7). What this tells us is that the various DNS names and IP addresses are associated with this domain (example.com) and they can be targeted for attack.

If the hacker goes after the mail server, he can affect mail traffic. If the hacker goes after the name server, he can affect name resolution services. And in so targeting these systems, the hacker can affect the availability of vital functions within a company. To do this, the attacker could alter the DNS records in the name server and effectively re-route traffic from one IP address to an IP address under his control, thereby redirecting queries for popular websites (such as Microsoft's http://Windowsupdate.microsoft.com or CNN.com) to his own malicious servers instead.

dig Countermeasures

As we noted in Chapter 1, the best countermeasures for DNS inquiries like those performed by dig include securing your DNS infrastructure, such as blocking or restricting zone transfers. Beyond these simple steps, there is little else to do to prevent this information from disclosure, as the designed intent of DNS is to provide it broadly in response to network queries. If you don't want information about a specific host propagated in this way, it probably shouldn't be in your DNS.

traceroute

Popularity:	10
Simplicity:	10
Impact:	3
Risk Rating:	8

Using the traceroute or tracert.exe utility included in UNIX or Microsoft Windows, respectively, you can view routers between yourself and a destination host. This provides a good start for targeting a large part of the networking infrastructureroutersand is often the first place attackers will go when targeting the infrastructure. traceroute sends out several packets (UDP and ICMP traceroute packets are used on UNIX and Windows, respectively) to the destination. The first packet's TTL (Time To Live) will be 1 and is increased for each hop discovery. When the packet traverses the router, its TTL is decreased by 1. If the TTL ever hits zero, the packet is dropped. A notification is sent back to the originating source host in the form of an ICMP error packet. Here, we see each hop responding with a TTL- expired ICMP packet, providing us with each hop and the IP address of the network interface closest to the source.

 [e-mail]:~# traceroute 10.14.208.3 traceroute to 10.14.208.3 (10.14.208.3), 30 hops max, 40 byte packets  1  64.200.142.202 (64.200.142.202)  0.299 ms  0.33 ms  0.253 ms  2  sntcca1wcx2-oc48.wcg.net (64.200.151.97)  3.486 ms  3.538 ms 3.989 ms  3  sntcca4lcx1-pos9-0.wcg.net (64.200.240.126)  3.877 ms  3.795 ms 4.229 ms  4  p12-1.pr01.sjc03.atlas.psi.net (154.54.10.113)  3.936 ms  3.83 ms 3.852 ms  5  g9.ba1.sfo1.atlas.cogentco.com (66.28.66.138)  5.916 ms  5.903 ms 5.867 ms  6  customer-2.demarc.cogentco.com (10.14.208.3)  5.955 ms 5.96 ms  6.924 ms  7  z.root-servers.net (7.14.9.50)  6.141 ms  5.955 ms  5.869 ms 

Knowing that 10.14.208.3 is the last hop before our target, we can be fairly certain that it is a device that's forwarding traffic. Also, from the reverse DNS received, we can assume this is the target's network start (or demarc , short for demarcation ) point. This is the device (along with every other device in the path ) attackers may target first. But knowing a router's IP address is a far cry from exploiting a vulnerability within it. We'll need to learn much more about this device with port scanning, OS detection, and information leakage before we can take advantage of any known vendor weaknesses.

traceroute Countermeasure

To restrict a router's response to TTL-exceeded packets on a Cisco router, you can use the following ACL:

 access-list 101 deny icmp any host 1.2.3.4 11 0 log 

For denying traffic directed specifically at a router, the following example is recommended (but may not be appropriate in all situations):

 access-list 101 deny ip any host 10.14.208.3 log 

Repeat this line, as necessary, for all router interfaces.

Alternatively, you can permit the ICMP packets from a particular trusted network (10.11.12.0/24) only and deny everything else:

 access-list 101 permit icmp any 10.11.12.0 0.255.255.255 11 0 access-list 101 deny icmp any host 1.2.3.4 log 

For a more in-depth explanation of ICMP restrictions, Rob Thomas's guide is recommended (http://www.cymru.com/Documents/icmp-messages.html).

IP Lookup

The ARIN database at http://www.arin.net is a good information-gathering starting point. As we discussed in Chapter 1, ARIN lookups are very useful to determine what IP ranges a target has, who is in charge, and when the last changes were made. Here's an example:

 OrgName:    EXAMPLE OrgID:      EXAMPLEA NetRange:   192.168.32.0 192.168.47.255 CIDR:       192.168.32.0/20 NetName:    EXAMPLE NetHandle:  NET-192-168-32-0-1 Parent:     NET-192-168-0-0-1 NetType:    Reassigned NameServer: NS1.EXAMPLE.COM NameServer: NS2.EXAMPLE.COM Comment: RegDate:    1999-10-14 Updated:    2001-11-09 AdminHandle: SM0000-ARIN AdminName: Stuart McClure AdminPhone: [phone] TechHandle: JS0000-ARIN TechName:   Joel Scambray TechPhone:  [phone] TechEmail:  [e-mail] # ARIN Whois database, last updated 2002-12-03 19:05 # Enter ? for additional hints on searching ARIN's Whois database.