Ping sweeping

A ping sweep of all your network subnets and hosts is a good way to find out which hosts are alive and kicking on the network. A ping sweep is when you ping a range of addresses using Internet Control Message Protocol (ICMP) packets. Figure 9-1 shows the command and the results of using Nmap to perform a ping sweep of a class C subnet range.

Dozens of Nmap command line options exist, which can be overwhelming when you want only a basic scan. Nonetheless, you can enter nmap on the command line to see all the options available.

The following command line options can be used for an Nmap ping sweep:

• -sP tells Nmap to perform a ping scan.
• -n tells Nmap not to perform name resolution.
• -T 4 tells Nmap to perform an aggressive (faster) scan.
• 192.168.1.1-254 tells Nmap to scan the entire 192.168.1.0 subnet.

Using port scanning tools

Most port scanners operate in three steps:

1. The port scanner sends TCP SYN requests to the host or range of hosts you set it to scan.

   Some port scanners perform ping sweeps to determine which hosts are available before starting the TCP port scans.

   Most port scanners by default scan only TCP ports. Don’t forget about UDP ports. You can scan UDP ports with a UDP port scanner, such as Nmap.

2. The port scanner waits for replies from the available hosts.
3. The port scanner probes these available hosts for up to 65,534 possible TCP and UDP ports — based on which ports you tell it to scan — to see which ones have available services on them.

The port scans provide the following information about the live hosts on your network:

• Hosts that are active and reachable through the network
• Network addresses of the hosts found
• Services or applications that the hosts may be running

After performing a generic sweep of the network, you can dig deeper into specific hosts you find.

Nmap

After you have a general idea of what hosts are available and what ports are open, you can perform fancier scans to verify that the ports are actually open and not returning a false positive. Nmap allows you to run the following additional scans:

• Connect: This basic TCP scan looks for any open TCP ports on the host. You can use this scan to see what’s running and determine whether intrusion prevention systems (IPSs), firewalls, or other logging devices log the connections.
• UDP scan: This basic UDP scan looks for any open UDP ports on the host. You can use this scan to see what’s running and determine whether IPSs, firewalls, or other logging devices log the connections.
• SYN Stealth: This scan creates a half-open TCP connection with the host, possibly evading IPS systems and logging. This is a good scan for testing IPSs, firewalls, and other logging devices.
• FIN Stealth, Xmas Tree, and Null: These scans let you mix things up a bit by sending strangely formed packets to your network hosts so you can see how they respond. These scans change around the flags in the TCP headers of each packet, which allows you to test how each host handles them to point out weak TCP/IP implementations as well as patches that might need to be applied.

Be careful when performing these scans. You can create your own DoS attack and potentially crash applications or entire systems. Unfortunately, if you have a host with a weak TCP/IP stack (the software that controls TCP/IP communications on your hosts), there’s no good way to prevent your scan from creating a DoS attack. A good way to help reduce the chance of this occurring is to use the slow Nmap timing options — Paranoid, Sneaky, or Polite — when running your scans.

Figure 9-2 shows the NMapWin Scan tab, where you can select the Scan Mode options (Connect, UDP Scan, and so on). If you’re a command line fan, you see the command line parameters displayed in the lower-left corner of the NMapWin screen. This helps when you know what you want to do and the command line help isn’t enough.

If you connect to a single port (as opposed to several all at one time) without making too much noise, you might be able to evade your firewall or IPS. This is a good test of your network security controls, so look at your logs to see what they saw during this process.

NetScanTools Pro

NetScanTools Pro (www.netscantools.com) is a very nice all-in-one commercial tool for gathering general network information, such as the number of unique IP addresses, NetBIOS names, and MAC addresses. It also has a neat feature that allows you to fingerprint the operating systems of various hosts. Figure 9-3 shows the OS Fingerprinting results while scanning a wireless network access point.

Countermeasures against ping sweeping and port scanning

Enable only the traffic you need to access internal hosts — preferably as far as possible from the hosts you’re trying to protect — and deny everything else. This goes for standard ports, such as TCP 80 for HTTP and ICMP for ping requests.

Configure firewalls to look for potentially malicious behavior over time (such as the number of packets received in a certain period of time) and have rules in place to cut off attacks if a certain threshold is reached, such as 10 port scans in one minute or 100 consecutive ping (ICMP) requests.

Most firewalls and IPSs can detect such scanning and cut it off in real time.

You can break applications on your network when restricting network traffic, so make sure that you analyze what’s going on and understand how applications and protocols are working before you disable any type of network traffic.

Vulnerabilities

The problem is that most network hosts run SNMP enabled with the default read/write community strings of public/private. The majority of network devices I come across have SNMP enabled and don’t even need it.

If SNMP is compromised, a hacker may be able to gather such network information as ARP tables, usernames, and TCP connections to attack your systems further. If SNMP shows up in port scans, you can bet that a malicious attacker will try to compromise the system.

Here are some utilities for SNMP enumeration:

• The commercial tools NetScanTools Pro and Essential NetTools
• Free Windows GUI-based Getif
• Free Windows text-based SNMPUTIL (www.wtcs.org/snmp4tpc/FILES/Tools/SNMPUTIL/SNMPUTIL.zip)

You can use Getif to enumerate systems with SNMP enabled, as shown in Figure 9-4.

In this test, I was able to glean a lot of information from a wireless access point, including model number, firmware revision, and system uptime. All this could be used against the host if an attacker wanted to exploit a known vulnerability in this particular system. By digging in further, I was able to discover several management interface usernames on this access point, as shown in Figure 9-5. You certainly don’t want to show the world this information.

For a list of vendors and products affected by the well-known SNMP vulnerabilities, refer to www.cert.org/historical/advisories/CA-2002-03.cfm.

Countermeasures against SNMP attacks

Preventing SNMP attacks can be as simple as A-B-C:

• Always disable SNMP on hosts if you’re not using it — period.
• Block the SNMP ports (UDP ports 161 and 162) at the network perimeter.
• Change the default SNMP community read string from public and the default community write string from private to another long and complex value that’s virtually impossible to guess.

There’s technically a “U” that’s part of the solution: upgrade. Upgrading your systems (at least the ones you can) to SNMP version 3 can resolve many of the well-known SNMP security weaknesses.

telnet

You can telnet to hosts on the default telnet port (TCP port 23) to see whether you’re presented with a login prompt or any other information. Just enter the following line at the command prompt in Windows or UNIX:

telnet ip_address

You can telnet to other commonly used ports with these commands:

• SMTP: telnet ip_address 25
• HTTP: telnet ip_address 80
• POP3: telnet ip_address 110

Figure 9-6 shows specific version information about an IceWarp e-mail server when telnetting to it on port 25. For help with telnet, simply enter telnet /? or telnet help for specific guidance on using the program.

Countermeasures against banner-grabbing attacks

The following steps can reduce the chance of banner-grabbing attacks:

• If there isn’t a business need for services that offer banner information, disable those unused services on the network host.
• If there isn’t a business need for the default banners, or if you can customize the banners, configure the network host’s application or operating system to either disable the banners or remove information from the banners that could give an attacker a leg up. Check with your specific vendor for information on how to do this. TCP Wrappers in Linux is another solution.

If you can customize your banners, check with your lawyer about adding a warning banner. It won’t stop banner grabbing but will show would-be intruders that the system is private and monitored (assuming it truly is). A warning banner may also help reduce your business liability in the event of a security breach. Here’s an example:

Warning! This is a private system. All use is monitored and recorded. Any unauthorized use of this system may result in civil and/or criminal prosecution to the fullest extent of the law.

Testing

A few tests can verify that your firewall actually does what it says it’s doing. You can connect through the firewall on the ports that are open, but what about the ports that can be open but shouldn’t be?

AlgoSec Firewall Analyzer

A commercial tool I often use with great results is AlgoSec’s Firewall Analyzer (www.algosec.com) as shown in Figure 9-7.

AlgoSec Firewall Analyzer, and similar ones such as SolarWinds Firewall Security Manager (www.solarwinds.com/firewall-security-manager.aspx), allows you to perform an in-depth analysis of firewall rulebases from all the major vendors and find security flaws and inefficiencies you’d never uncover otherwise. Firewall rulebase analysis is a lot like software source code analysis — it finds flaws at the source that humans would likely never see even when performing in-depth security tests from the Internet and the internal network. If you’ve never performed a firewall rulebase analysis, it’s a must!

Countermeasures against firewall rulebase vulnerabilities

The following countermeasures can prevent a hacker from testing your firewall:

• Perform a firewall rulebase audit. I’m always saying that you cannot secure what you don’t acknowledge. There’s no better example of this than your firewall rulebases. No matter how seemingly simplistic your rulebase is, it never hurts to verify your work using an automated tool.

• Limit traffic to what’s needed.

  Set rules on your firewall (and router, if needed) that passes only traffic that absolutely must pass. For example, have rules in place that allow HTTP inbound traffic to an internal web server, SMTP inbound traffic to an e-mail server, and HTTP outbound traffic for external web access.

  This is the best defense against someone poking at your firewall.

• Block ICMP to help prevent an external attacker from poking and prodding your network to see which hosts are alive.
• Enable stateful packet inspection on the firewall to block unsolicited requests.

Network analyzer programs

You can use one of the following programs for network analysis:

• Savvius OmniPeek (www.savvius.com) is one of my favorite network analyzers. It does everything I need and more and is very simple to use. OmniPeek is available for Windows operating systems.
• TamoSoft’s CommView (www.tamos.com/products/commview) is a great, low-cost, Windows-based alternative.
• Cain & Abel (www.oxid.it/cain.html) is a free multifunctional password recovery tool for performing ARP poisoning, capturing packets, cracking passwords, and more.
• Wireshark (www.wireshark.org), formerly known as Ethereal, is a free alternative. I download and use this tool if I need a quick fix and don’t have my laptop nearby. It’s not as user-friendly as most of the commercial products, but it is very powerful if you’re willing to learn its ins and outs. Wireshark is available for both Windows and OS X.
• ettercap (http://ettercap.github.io/ettercap/) is another powerful (and free) utility for performing network analysis and much more on Windows, Linux, and other operating systems.

Here are a few caveats for using a network analyzer:

• To capture all traffic, you must connect the analyzer to one of the following:
  • A hub on the network
  • A monitor/span/mirror port on a switch
  • A switch that you’ve performed an ARP poisoning attack on
• If you want to see traffic similar to what a network-based IPS sees, you should connect the network analyzer to a hub or switch monitor port — or even a network tap — on the outside of the firewall, as shown in Figure 9-8. This way, your testing enables you to view
  • What’s entering your network before the firewall filters eliminate the junk traffic.
  • What’s leaving your network after the traffic passes through the firewall.

Whether you connect your network analyzer inside or outside your firewall, you see immediate results. It can be an overwhelming amount of information, but you can look for these issues first:

• Odd traffic, such as:
  • An unusual amount of ICMP packets
  • Excessive amounts of multicast or broadcast traffic
  • Protocols that aren’t permitted by policy or shouldn’t exist given your current network configuration
• Internet usage habits, which can help point out malicious behavior of a rogue insider or system that has been compromised, such as:
  • Web surfing and social media
  • E-mail
  • Instant messaging and other P2P software
• Questionable usage, such as:
  • Many lost or oversized packets, indicating hacking tools or malware are present
  • High bandwidth consumption that might point to a web or FTP server that doesn’t belong
• Reconnaissance probes and system profiling from port scanners and vulnerability assessment tools, such as a significant amount of inbound traffic from unknown hosts — especially over ports that aren’t used very much, such as FTP or telnet.
• Hacking in progress, such as tons of inbound UDP or ICMP echo requests, SYN floods, or excessive broadcasts.
• Nonstandard hostnames on your network. For example, if your systems are named Computer1, Computer2, and so on, a computer named GEEKz4evUR should raise a red flag.
• Hidden servers (especially web, SMTP, FTP, DNS, and DHCP) that might be eating network bandwidth, serving illegal software, or accessing your network hosts.
• Attacks on specific applications that show such commands as /bin/rm, /bin/ls, echo, and cmd.exe as well as SQL queries and JavaScript injection, which I cover in Chapter 15.

You might need to let your network analyzer run for quite a while — several hours to several days, depending on what you’re looking for. Before getting started, configure your network analyzer to capture and store the most relevant data:

• If your network analyzer permits it, configure it to use a first-in, first-out buffer.

  This configuration overwrites the oldest data when the buffer fills up, but it might be your only option if memory and hard drive space are limited on your network analysis computer.

• If your network analyzer permits it, record all the traffic into a capture file and save it to the hard drive. This is the ideal scenario — especially if you have a large hard drive, such as 500GB or more.

  You can easily fill several hundred gigabytes’ worth of hard drive space in a short period. I highly recommend running your network analyzer in what OmniPeek calls monitor mode. This allows the analyzer to keep track of what’s happening such as network usage and protocols but not capture and store every single packet. Monitor mode — if supported by your analyzer — is very beneficial and is often all you need.

• When network traffic doesn’t look right in a network analyzer, it probably isn’t. It’s better to be safe than sorry.

  Run a baseline when your network is working normally. When you have a baseline, you can see any obvious abnormalities when an attack occurs.

One thing I like to check for is the top talkers (network hosts sending/receiving the most traffic) on the network. If someone is doing something malicious on the network, such as hosting an FTP server or running Internet file-sharing software, using a network analyzer is often the only way you’ll find out about it. A network analyzer is also a good tool for detecting systems infected with malware, such as a virus or Trojan horse. Figure 9-9 shows what it looks like to have a suspect protocol or application running on your network.

Looking at your network statistics, such as bytes per second, network utilization, and inbound/outbound packet counts, is also a good way to determine whether something fishy is going on. Figure 9-10 contains network statistics as seen through the powerful CommView network analyzer.

TamoSoft — the maker of CommView — has another product called NetResident (www.tamos.com/products/netresident) that can track the usage of well-known protocols, such as HTTP, e-mail, FTP, and VoIP. As shown in Figure 9-11, you can use NetResident to monitor web sessions and play them back.

NetResident also has the capability to perform ARP poisoning via its PromiSwitch tool available under the Tools menu, which allows NetResident to see everything on the local network segment. I cover ARP poisoning in the section “The MAC-daddy attack,” later in this chapter.

Countermeasures against network protocol vulnerabilities

A network analyzer can be used for good or evil. The good is to help ensure your security policies are being followed. The evil is when someone uses a network analyzer against you. A few countermeasures can help prevent someone from using an unauthorized network analyzer, although there’s no way to prevent it completely.

If an external attacker or malicious user can connect to your network (physically or wirelessly), he can capture packets on the network, even if you’re using an Ethernet switch.

ARP spoofing

An excessive number of ARP requests can be a sign of an ARP spoofing attack (also called ARP poisoning) on your network.

A client running a program, such as dsniff (www.monkey.org/~dugsong/dsniff) or Cain & Abel (www.oxid.it/cain.html), can change the ARP tables — the tables that store IP addresses to media access control (MAC) address mappings — on network hosts. This causes the victim computers to think they need to send traffic to the attacker’s computer rather than to the true destination computer when communicating on the network. ARP spoofing is used during man-in-the-middle (MITM) attacks.

Spoofed ARP replies can be sent to a switch, which reverts the switch to broadcast mode and essentially turns it into a hub. When this occurs, an attacker can sniff every packet going through the switch and capture anything and everything from the network.

This security vulnerability is inherent in how TCP/IP communications are handled.

Here’s a typical ARP spoofing attack with a hacker’s computer (Hacky) and two legitimate network users’ computers (Joe and Bob):

1. Hacky poisons the ARP caches of victims Joe and Bob by using dsniff, ettercap, or a utility he wrote.
2. Joe associates Hacky’s MAC address with Bob’s IP address.
3. Bob associates Hacky’s MAC address with Joe’s IP address.
4. Joe’s traffic and Bob’s traffic are sent to Hacky’s IP address first.

5. Hacky’s network analyzer captures Joe’s and Bob’s traffic.

   If Hacky is configured to act like a router and forward packets, it forwards the traffic to its original destination. The original sender and receiver never know the difference!

Using Cain & Abel for ARP poisoning

You can perform ARP poisoning on your switched Ethernet network to test your IPS or to see how easy it is to turn a switch into a hub and capture anything and everything with a network analyzer.

ARP poisoning can be hazardous to your network’s hardware and health, causing downtime and more. So be careful!

Perform the following steps to use Cain & Abel for ARP poisoning:

1. Load Cain & Abel and then click the Sniffer tab to enter the network analyzer mode.

   The Hosts page opens by default.

2. Click the Start/Stop APR icon (the yellow and black circle).

   The ARP poison routing (how Cain & Abel refers to ARP poisoning) process starts and enables the built-in sniffer.

3. If prompted, select the network adapter in the window that appears and then click OK.
4. Click the blue + icon to add hosts to perform ARP poisoning on.
5. In the MAC Address Scanner window that appears, ensure the All Hosts in My Subnet option is selected and then click OK.
6. Click the APR tab (the one with the yellow-and-black circle icon) to load the APR page.

7. Click the white space under the uppermost Status column heading (just under the Sniffer tab).

   This re-enables the blue + icon.

8. Click the blue + icon and the New ARP Poison Routing window shows the hosts discovered in Step 3.

9. Select your default route (in my case, 10.11.12.1).

   The right-hand column fills with all the remaining hosts, as shown in Figure 9-12.

10. Ctrl+click all the hosts in the right column that you want to poison.

11. Click OK and the ARP poisoning process starts.

    This process can take anywhere from a few seconds to a few minutes depending on your network hardware and each hosts’ local TCP/IP stack. The results of ARP poisoning on my test network are shown in Figure 9-13.

12. You can use Cain & Abel’s built-in passwords feature to capture passwords traversing the network to and from various hosts simply by clicking the Passwords tab.

The preceding steps show how easy it is to exploit a vulnerability and prove that Ethernet switches aren’t all they’re cracked up to be from a security perspective.

MAC address spoofing

MAC address spoofing tricks the switch into thinking your computer is something else. You simply change your computer’s MAC address and masquerade as another user.

You can use this trick to test access control systems, such as your IPS/firewall, and even your operating system login controls that check for specific MAC addresses.

Countermeasures against ARP poisoning and MAC address spoofing attacks

A few countermeasures on your network can minimize the effects of an attack against ARP and MAC addresses:

• Prevention: You can prevent MAC address spoofing if your switches can enable port security to prevent automatic changes to the MAC address tables.

  No realistic countermeasures for ARP poisoning exist. The only way to prevent ARP poisoning is to create and maintain static ARP entries in your switches for every host on the network. This is something that hardly any network administrator has time to do in today’s rat race.

• Detection: You can detect these two types of hacks through an IPS or a standalone MAC address–monitoring utility.

  Arpwatch (http://linux.maruhn.com/sec/arpwatch.html) is a Linux-based program that alerts you via e-mail when it detects changes in MAC addresses associated with specific IP addresses on the network.

DoS attacks

DoS attacks against your network and hosts can cause systems to crash, data to be lost, and every user to jump on your case wondering when Internet access will be restored.

Here are some common DoS attacks that target an individual computer or network device:

• SYN floods: The attacker floods a host with TCP SYN packets.
• Ping of Death: The attacker sends IP packets that exceed the maximum length of 65,535 bytes, which can ultimately crash the TCP/IP stack on many operating systems.
• WinNuke: This attack can disable networking on older Windows 95 and Windows NT computers.

Distributed DoS (DDoS) attacks have an exponentially greater impact on their victims. One of the most famous was the DDoS attack against eBay, Yahoo!, CNN, and dozens of other websites by a hacker known as MafiaBoy. While updating this book to the third edition, there was a highly publicized DDoS attack against Twitter, Facebook, and other social media sites. The attack was apparently aimed at one user from Georgia (the former Soviet country, not the state where I live), but it affected everyone using these sites. I couldn’t tweet, and many of my friends and family members couldn’t see what everyone was blabbing about on Facebook (oh, the humanity!). There have been numerous other highly-publicized DDoS attacks since then. Think about this: When hundreds of millions of people can be taken offline by one targeted DDoS attack, you can see why understanding the dangers of denial of service against your business’s systems and applications is important.

Testing

Denial of service testing is one of the most difficult security checks you can run. There just aren’t enough of you and your computers to go around. Don’t fret. You can run a few tests to see where you’re weak. Your first test should be a search for DoS vulnerabilities from a vulnerability-scanning perspective. Using vulnerability scanners, such as Nexpose (www.rapid7.com/products/nexpose) and AppSpider (www.rapid7.com/products/appspider), you can find missing patches and configuration weaknesses that can lead to denial of service.

I once performed a security assessment where I used Qualys to find a vulnerability in an older version of OpenSSL running on a web server. As with most DoS findings, I didn’t actually exploit the vulnerability because I didn’t want to take down the production system. Instead, I listed it as a “medium priority” vulnerability — an issue that had the potential to be exploited. My client pushed back and said OpenSSL wasn’t on the system. With permission, I downloaded the exploit code available on the Internet, compiled it, and ran it against my client’s server. Sure enough, it took the server offline.

At first, my client thought it was a fluke, but after taking the server offline again, he bought into the vulnerability. It ended up that he was using an OpenSSL derivative, hence the vulnerability. Had my client not fixed the problem, there could have been any number of attackers around the world taking — and keeping — this production system offline, which could have been both tricky and time consuming to troubleshoot. Not good for business!

Don’t test for DoS unless you have test systems or can perform controlled tests with the proper tools. Poorly planned DoS testing is a job search in the making. It’s like trying to delete data from a network share and hoping that the access controls in place are going to prevent it.

Other DoS testing tools worth checking out are UDPFlood (www.mcafee.com/us/downloads/free-tools/udpflood.aspx), Blast (www.mcafee.com/us/downloads/free-tools/blast.aspx), NetScanTools Pro, and CommView.

Countermeasures against DoS attacks

Most DoS attacks are difficult to predict, but they can be easy to prevent:

• Test and apply security patches (including service packs and firmware updates) as soon as possible for network hosts, such as routers and firewalls, as well as for server and workstation operating systems.

• Use an IPS to monitor regularly for DoS attacks.

  You can run a network analyzer in continuous capture mode if you can’t justify the cost of an all-out IPS solution and use it to monitor for DoS attacks.

• Configure firewalls and routers to block malformed traffic. You can do this only if your systems support it, so refer to your administrator’s guide for details.
• Minimize IP spoofing by filtering out external packets that appear to come from an internal address, the local host (127.0.0.1), or any other private and non-routable address, such as 10.x.x.x, 172.16.x.x–172.31.x.x, or 192.168.x.x. The following paper from Cisco Systems provides more information: www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_10-4/104_ip-spoofing.html.
• Block all ICMP traffic inbound to your network unless you specifically need it. Even then, you should allow it to come in only to specific hosts.
• Disable all unneeded TCP/UDP small services, such as echo and chargen.

Establish a baseline of your network protocols and traffic patterns before a DoS attack occurs. That way, you know what to look for. And periodically scan for such potential DoS vulnerabilities as rogue DoS software installed on network hosts.

If you get yourself in a real bind and end up under direct DoS assault, you can reach out to managed service vendors such as Imperva’s Incapsula (www.incapsula.com), CloudFlare (www.cloudflare.com), and DOSarrest (www.dosarrest.com) who can help you out.

Work with a minimum necessary mentality (not to be confused with having too many craft beers) when configuring your network devices, such as firewalls and routers:

• Identify traffic that is necessary for approved network usage.
• Allow the traffic that’s needed.
• Deny all other traffic.

If worse comes to worst, you’ll need to work with your ISP and see whether they can block DoS attacks on their end.