Sunday, July 17, 2005
Securing Your Network: Removing Unwanted Devices
Pretend you're a network head at some organization, in charge of a couple dozen - maybe a few hundred - network devices, and you're responsible for their operation, maintenance, and security. Or maybe you don't have to pretend; maybe you really are. In any case, you've got a happy little network, all orderly and mapped out, running great. Over time, however, you notice the network's condition start to deteriorate. Broadcast traffic is on the rise, with more suspicious user activity in the logs every day. Then one morning you get a call from your irate boss wanting to know why he no longer has a network connection, yet the employees - or students or whoever - down the hall are able to play games and visit porn sites, at blazing speeds no less.
You may currently have more on your network than you think.
Not much attention is given to one of the most elusive aspects of security, that of physical connectivity. The main goal of network security is of course to keep legitimate network users up and running, while keeping the bad ones out completely. Under normal circumstances, where the supposed attacker may be hundreds of miles away, on the other side of your firewall, this is relatively easy enough. However, when unauthorized users have a direct physical connection on your network, the problem can be infinitely harder to solve. Should an intruder ever reach the 'soft side' of your network - the private area behind the DMZ - it is vital to know how to detect them, how to find them, and how to pull the plug (often literally).
Detection
Although every network is different, there are several telltale signs that something fishy is going on. Naturally, the more complex your network is, the harder it will be to sniff out a rogue device. Several clues should be examined in an effort to pinpoint the offending source.
Invalid Source Addresses
Most LANs are comprised of a single address hierarchy, for example a 10.x.x.x class A scheme, or a variety of 192.168.x.x class C subnets. Now assume all legitimate devices on your network are assigned a 10.x.x.x IP via DHCP, so they should all have their own reserved spot in this hierarchy. But when checking traffic logs or a sniff capture, you see traffic to/from a device at 192.168.1.1. Obviously this is not a valid address, and probably not an authorized device, either. This scenario is most often caused by Joe User plugging his personal brouter or similar device intended for home networking into an open port on a user switch somewhere.
Repetitive DHCP Requests
Some smaller networks don't run a DHCP server (though not doing so is rare these days), so devices must have static IP addresses entered into them manually. This would give rise to suspicion if you detect an unknown device constantly broadcasting a DHCP request. However, this isn't always a solid lead, as the same effect will be had by a new PC brought online before having an IP assigned to it.
Uncommon Service Traffic
Suppose one segment of your network is dedicated to the Accounting department, a small group of employees who use the network primarily for Internet, E-mail, and SQL database access. If you notice, for example, HTTP traffic heading into this segment from another part of the network, someone in Accounting might have decided to start up a personal web server.
Bandwidth Hogs
This can be the hardest to detect, depending on what method(s) you use to monitor network throughput. At the very least, you should have some sort of probe at the gateway to measure traffic. Let's say you have a good sized network used for typical Web and E-mail access, and decide to run a protocol survey. Over twenty minutes, you see the following traffic throughput:
HTTP: 824 KB (14 hosts)
SMTP: 112 KB (3 hosts)
FTP: 634 MB (1 host)
Now which one doesn't fit? If you picked FTP, you win! (If not, it would be advisable to stop reading now and go update your resume, as you might be needing it shortly.) Generally speaking, you won't find a user downloading an entire CD's worth of data as part of their daily workload.
Determining the Threat
In most instances, the device in question is one of three things; it can be a 'dumb' device configured improperly (by dumb I mean without a human user operating it), an ignorant user, or a malicious user.
Misconfigured Devices
These are typically more of a nuisance than a threat, but should not be overlooked, as they can often be security risks and stand the chance of being compromised at any time. These are typically things like user-bought LAN devices, such as the Linksys and Netgear brouters you can pick up at Best Buy for $50, useful for turning one switch port into four or five. A word of caution, though: many times, users will plug these into your network to provide themselves with unchecked wireless connectivity, a definite security no-no.
Ignorant Users
The context of the term ignorant here is intent. A user who decides to install Apache on their desktop to play around with is unlikely to do any harm and certainly never had the intention too, yet this sort of thing is usually frowned upon by administrators. As a side note, this is also the number one reason grade school students get in trouble with the administration. God forbid they actually learn something in a place of organized education.
Other users that fall under this ignorant-but-innocent category include employees attempting to bypass a webfilter so they can go to personal sites on their lunch hour, or setting up internal FTP servers to share MP3's with their coworkers. While your administration may find this less than acceptable, it rarely has any adverse effect on network integrity (with the possible exception of bandwidth).
Malicious Users
If you encounter a malicious user, this is where you should start to sweat. Here, a user is anyone with access to your network - authorized or not. This could be some anonymous attacker, either with or without physical access to your network. Worse, it could be a disgruntled employee with a legitimate network account and working knowledge of the network layout. Rare as they are, malicious users take all priority when detected because they are often easier to catch if you can track them in real-time.
Enumeration
So, assume you have some unknown device hanging off your network. How you came to know about it irrelevant. Maybe you noticed some unusual protocols or traffic volume, maybe you suddenly lost connectivity to an entire segment. The next step is finding out what the device is. Is it a regular PC? Some sort of server? A switch, or perhaps a router? Advanced enumeration techniques are beyond the scope of this paper, though a good checklist is handy whenever trying to identify a mysterious device.
Who made it?
One of the first - and easiest - things to find out about a device is who made it. All you need for this is the MAC address (or at least its IP address, for starters), which you can then check against the IEEE's Organization Unique Identifier listings at http://standards.ieee.org/regauth/oui/index.shtml. If you only have the IP address, you can easily obtain its MAC address. Provided you're currently on the same switched LAN and VLAN as your target device, all you need to do is stimulate some traffic between yourself and your target. A simple ping will suffice. Then, retrieve the MAC address corresponding to its IP from your system's ARP cache.
C:\> ping -n 1 192.168.10.16
Pinging 192.168.10.16 with 32 bytes of data:
Reply from 192.168.10.16: bytes=32 time=4ms TTL=64
Ping statistics for 192.168.10.16:
Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 4ms, Maximum = 4ms, Average = 4ms
C:\> arp -a 192.168.10.16
Interface: 192.168.4.2 --- 0x2
Internet Address Physical Address Type
192.168.10.16 00-0c-41-45-a9-d6 dynamic
Running Service Identification
On a typical host PC, there aren't many services running, and therefore open ports are limited to the default services of the operating system. For example, a Windows XP box by default will have ports 135, 139, and 445 open for TCP, mapped to legitimate system services.
Network devices, however, will often accept connections to port(s) 22 and/or 23, which are used for secure shell and telnet access, respectively. Another one to watch for is 80, which carries HTTP traffic. Some devices by default will have an optional web interface running in addition to its regular command line interface. Ports 21 and 69 are used for FTP and TFTP daemons, often utilized by routers and switches for configuration and OS updates. It is not uncommon to find end hosts running web and FTP servers, though remote shell services like telnet are typically limited to network devices.
Operating System Identification
A more explicit enumeration technique is OS detection. This can be accomplished rather easily with nmap (http://www.insecure.org/nmap/). Although not 100% reliable, this can give you a pretty solid idea of what to expect from the device.
Obviously, the aforementioned enumeration techniques only provide a very general idea of the device in question. This is sufficient, however, as here we are not looking to actually infiltrate the device; we just want an idea to aid us in removing or otherwise separating it from the rest of the network.
The Hunt Begins
Now armed with a MAC address and some background info, we can begin to hunt it down. On a small network in a moderately sized building, this may be easy enough. Unfortunately, when you're managing a network the size of a city - with enough endpoints to match - the task becomes considerably more difficult. Obviously you're not going to physically search a building or buildings for this device; we're going to trace it through the network. This is why it's important to know the layout of your network in great detail. Also, having adequately descriptive hostnames on your network nodes comes in very handy.
Consider the following network topology. In our scenario layout, buildings A, B, and C, each with their own user base supported by one or two switches, contain a trunk to building X and at least one other building for redundancy. Building X contains the only router with a link to the outside world, but the only user currently hanging off the switch there is the admin (AKA you). Keep in mind this is a very, very simple mock topology and real-world scenarios will tend to be much more complex. Anyhow, you suspect the mystery device to reside among the regular users in building A, B, or C.
Switch MAC Tables
Ethernet switches essentially map MAC addresses to the ports they come from. Therefore, they are extremely helpful when tracing the physical location of a host. Let's say our target's MAC address is 00:01:23:45:67:89. Yes, a brilliant example, I know. From the switch's CLI, we can extract the corresponding switch port from switch's MAC table.
Note: The commands shown here are specific to certain Cisco devices, namely the Catalyst family of switches running IOS and/or CatOS. While I understand different networks may use a wide variety of hardware vendors, it would be impractical to list the exact steps required for every switch out there. If the following steps aren't compatible with your device(s) for whatever reason, consult with your vendor for the appropriate configuration.
Starting from the highest level in the switched hierarchy (in this case building X) we trace the physical path to our end user. In our local switch at building X, we perform the following query:
Switch-X# show mac-address-table address 0001.2345.6789
Non-static Address Table:
Destination Address Address Type VLAN Destination Port
------------------- ------------ ---- --------------------
0001.2345.6789 Dynamic 1 GigabitEthernet0/1
Switch-X#
We see from the result of the MAC query that traffic to 00:01:23:45:67:89 is passed out port GigabitEthernet0/1, one of our trunks to a switch in another building. So, where does it go? One way to find out would be to consult your network map. Duh. But a much cooler way, if you have a Cisco network, is to use CDP and map out your network as you go.
Cisco Discovery Protocol
Naturally proprietary to Cisco Systems, CDP is an extremely useful tool for exploring and mapping a network's 'layer two' topology, as referenced against the almighty OSI model. For more information on CDP, visit http://cisco.com/en/US/tech/tk648/tk362/tk100/tech_protocol_home.html. For now we'll cover the aspects of CDP necessary to continue our quest.
We can list all connected Cisco devices with one command:
Switch-X# show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater
Device ID Local Intrfce Holdtme Capability Platform Port ID
Switch-A1 Gig 0/1 144 R S I WS-C2924 Gig 0/1
Switch-C1 Gig 0/2 144 R S I WS-C2924 Gig 0/1
Router Fas 0/1 144 R S I WS-C4003 Fas 0/1
Switch-B Fas 0/2 144 R S I WS-C2924 Fas 0/1
Switch-X#
Or, we can specify just the interface we want:
Switch-X# show cdp neighbors GigabitEthernet 0/1
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater
Device ID Local Intrfce Holdtme Capability Platform Port ID
Switch-A1 Gig 0/1 144 R S I WS-C2924 Gig 0/1
Switch-X#
We learn that the device on the other end of our gigabit link is Switch-A1, the root switch for building A. We can assume at this point that our mystery device is somewhere within building A, but why stop there? Our goal is to get as specific as possible. We telnet to Switch-A1 and perform the same MAC address query as we did before.
Switch-A1# show mac-address-table address 0001.2345.6789
Non-static Address Table:
Destination Address Address Type VLAN Destination Port
------------------- ------------ ---- --------------------
0001.2345.6789 Dynamic 1 GigabitEthernet0/2
Switch-A1#
Our device isn't connected directly to this switch, either, but passes instead through interface GigabitEthernet0/2, our gigabit link to the other switch in this building. Since there is only one other switch in this building, and the switch we're on now is its only gateway out, it's pretty safe to assume our target is hanging off of Switch-A2. (We could verify this again with CDP, but just take my word for it this time, okay?) But, not only do we want to double-check this, we want to find out exactly what port it's on so we can kill its connection if necessary.
Switch-A2# show mac-address-table address 0001.2345.6789
Non-static Address Table:
Destination Address Address Type VLAN Destination Port
------------------- ------------ ---- --------------------
0001.2345.6789 Dynamic 1 FastEthernet0/19
Switch-A2#
We've reached the end of the road! Our device is on FastEthernet0/19 on Switch-A2.
Traffic Sniffing
Now that we know where our device is hiding, it is at our mercy. Muahahaha! But, we might not want to pull the plug just yet. In the event an attack has occurred successfully, the damage has already been done. If the attacker is still active on the network, we might as well record some evidence for future use. Of course, common sense is your friend for this one; if an attacker has compromised your company's sales database and is actively pulling credit card numbers from it, it's probably a good idea to just cut him off now.
SPANing, or Switched Port ANalysis, provides a very convenient way to mirror port traffic. Switches are designed so that ideally, a frame enters one port and exists through another. In one, out one. This is the major ideology that makes switches so much more efficient than hubs. SPANing allows us to mirror the traffic on one port to another - in one, out two, so to speak. In our example, we would want to monitor all traffic on FastEthernet0/19 on Switch-A2. What we could do then is attach a sniffer to a port - for instance, FastEthernet0/24 - and monitor or capture the mirrored traffic to see what our target is up to. This is done with commands along these lines (depending on what OS you're running):
Switch-A2# configure terminal
Switch-A2(config)# interface f0/19
Switch-A2(config-if)# port monitor f0/24
Switch-A2(config-if)# end
Switch-A2#
Again, this is Cisco-specific syntax. However, SPAN or an equivalent is available on most Ethernet switches. There is also RSPAN, which allows you to mirror traffic over multiple switches, like mirroring Fast0/19 on Switch-A2 across the network to Admin's port on Switch-X. Check with your vendor for more specific information on using SPAN, port monitoring, or whatever they call it.
As for what sniffer to use, this is always a matter of personal preference. One of the best free sniffers out there is ethereal (http://www.ethereal.com). It even gives some commercial sniffers a good run for their money. There are plenty of choices when it comes to protocol analysis software, but I'll leave it at that.
The Final Strike
Okay, playtime's over. Now it's time to cut off the offending device's connection. We have several options here; the most obvious of course is to physically go to the switch and unplug the cable on port 19. However, this takes time. A quicker, if temporary solution is to shut off the port. On our Cisco switch, this done like so:
Switch-A2# configure terminal
Switch-A2(config)# interface f0/19
Switch-A2(config-if)# shutdown
Switch-A2(config-if)# end
Switch-A2#
If the device was added by an ignorant user (refer back to Determining the Threat), it can be entertaining watching them try to figure out why their wireless access point suddenly stopped working. It's mean, of course, but it's also very funny. Some will even have the balls to call up and complain that they lost their network connection. In this case it's best to make a personal appearance so they can explain where the little blue box came from.
There are also a couple clever ways to isolate the device from the network without the device knowing. These are a bit less secure, and probably not a great idea if there happens to be a human attacker behind the device.
VLAN Segregation
By assigning port 19, the MAC address, or (better yet) both to an unused VLAN, the connection remains but its traffic is trapped. So long as the VLAN isn't routed away from the switch, the device is effectively cut off.
Access Lists
A last resort, if for some reason you couldn't isolate the device by means of VLANs. You can set access lists based on IP or MAC addresses - in this case an explicit 'deny any' would likely be in order. However, be aware that IP and MAC addresses alike can easily be changed by a knowledgeable attacker. It is strongly advised to shut down the port or employ VLAN segregation instead.
Future Deterrence
As long as there are users on your network, 100% security will be impossible to maintain. Fortunately, there are a few ideal practices that will discourage even the most determined attackers from gaining access.
Whatever ports aren't being used on a device should be turned off until they're needed. What ports are being used should be locked down as far as possible. This includes restricting STP and VTP traffic from non-trunk ports, as well as imposing a limit of one MAC address per port, to prevent the addition of hubs or other switches. On Cisco devices, this can be accomplished with the portfast, bpduguard, and port-security entities. And as always, the strategic placement of well-designed firewalls and access lists is crucial to good network integrity.
The lesson here is that information only becomes knowledge when it's implemented correctly; a map is good to have, but knowing how to make a new map when needed is what separates the Net+ cardholders from the true network hackers.
l0gic
http://www.l0gic.net - l0gic.net
http://www.l0gic.net/mentor.php - Project Mentor Dare to learn.
source:http://www.whitedust.net/article/21/Securing%20Your%20Network:%20Removing%20Unwanted%20Devices/
