Security in network design

Proper network design provides us with one of the chief tools we have to protect ourselves from the variety of network threats we might face. A well-configured and patched network is the foundation of any security program. With a properly laid out network, we can prevent some attacks entirely, mitigate others, and, when we can do nothing else, fail in a graceful way.

Network segmentation can go a long way toward reducing the impact of such attacks. When we segment a network, we divide it into multiple smaller networks, each acting as its own small network called a subnet. We can control the flow of traffic between subnets, allowing or disallowing traffic based on a variety of factors, or even blocking the flow of traffic entirely if necessary. Properly segmented networks can boost network performance by containing certain traffic to the portions of the network that actually need to see it and can help to localize technical network issues. Additionally, network segmentation can prevent unauthorized network traffic or attacks from reaching portions of the network to which we would prefer to prevent access, as well as making the job of monitoring network traffic considerably easier.

Another design factor that can be of assistance in the goal of securing our networks is to funnel network traffic through certain points where we can inspect, filter, and control the traffic, often referred to as choke points. The choke points might be the routers that move traffic from one subnet to another, the firewalls or proxies that control traffic moving within, into, or out of our networks or portions of our networks, or the application proxies that filter the traffic for particular applications such as Web or e-mail traffic. Choke points come with some risk because if they fail the network is compromised. We will discuss some of these devices at greater length in the next section of this chapter.

Redundancy in network design can prove to be another major factor in helping to mitigate risk to our networks. Certain technical issues or attacks may render unusable portions of our networks, network infrastructure devices, border devices such as firewalls, or a number of other components that contribute to the functionality of our networks. Good network design includes planned redundancy for devices failing, connectivity being lost, or coming under attack to the point that they are rendered useless or we lose control of them. For example, if one of our border devices is being subjected to a DDoS attack, there are few steps we can take to mitigate the attack. We can, however, switch to a different connection to the Internet, or route traffic through a different device until we can come to a longer-term solution.

Firewalls

A firewall is a mechanism for maintaining control over the traffic that flows into and out of our network(s). The concept and first implementations of firewall technologies can be traced back to the late 1980s and early 1990s. One of the first papers to discuss the idea of using a firewall is titled “Simple and Flexible Datagram Access Controls,” written in 1989 by Jeffrey Mogul [2], then at Digital Equipment Corporation (DEC). We can also see the first commercial firewall from DEC, the DEC SEAL, which shipped in 1992 [3].

A firewall is typically placed in a network where we see the level of trust change. We might see a firewall on the border between our internal network and the Internet, as shown in Figure 10.1. We may also see a firewall put in place on our internal network to prevent network traffic of a sensitive nature from being accessed by those that have no reason to do so.

Many of the firewalls in use today are based on the concept of examining the packets that are coming in over the network. This examination determines what should be allowed in or out. Whether the traffic is allowed or blocked can be based on a variety of factors and largely depends on the complexity of the firewall. For example, we might allow or disallow traffic based on the protocol being used, allowing Web and e-mail traffic to pass, but blocking everything else.

DMZs

A DMZ, or demilitarized zone, is generally a combination of a network design feature and a protective device such as a firewall. As we discussed earlier in the “Security in Network Design” section, we can often increase the level of security on our networks by segmenting them properly. When we look at systems that need to be exposed to external networks such as the Internet in order to function, such as mail servers, proxy servers, software as a service application, and Web servers, we need to ensure their security and the security of the devices on the network behind them. We can often do this by putting a layer of protection between the device, such as our mail server, and the Internet, and between the rest of our network and the device, as shown in Figure 10.2.

This allows only the traffic that needs to reach the mail server—for instance, Internet Message Access Protocol (IMAP) and Simple Message Transfer Protocol (SMTP) on ports 143 and 25, respectively—to reach our mail server, and the same ports to pass through on our network. Presuming that no other services are running on the same system, we could restrict the traffic going into and out of the DMZ where our mail server sits to those particular ports.

Network intrusion detection systems

IDSes monitor the networks, hosts, or applications to which they are connected for unauthorized activity. There are several types of IDSes, including host-based intrusion detection systems (HIDSes), application protocol-based intrusion detection systems (APIDSes), and network-based intrusion detection systems (NIDSes). We will focus on NIDSes in this chapter, returning to HIDSes and APIDSes in Chapters 11 and 12, respectively.

NIDSes will typically be attached to the network in a location where they can monitor the traffic going by, but they need to be placed carefully so that they are not overloaded. Placing an NIDS behind another filtering device, such as a firewall, can help to eliminate some of the obviously spurious traffic in order to decrease the traffic the NIDS needs to inspect. As NIDSes need to examine a large amount of traffic on a typical network, they can generally do only a relatively cursory inspection in order to determine whether the situation on the network is normal or not. Because of this, an NIDS may miss some types of attacks, particularly those that are specifically crafted to pass through such inspections. Packet crafting attacks involve very specifically designed packets of traffic that carry attacks or malicious code, but are designed to avoid detection by IDSes, firewalls, and other similar devices. Combining functions like firewalls and IDSs into one correlated capability starts the defense in depth security program organizations depend on today.

The impact of intercepted data

One of the largest concerns when we are sending sensitive data over a network is of having the data intercepted by someone that might misuse it. Given the many networks available today in offices, hotels, coffee shops, restaurants, and other places, the opportunity to accidentally expose data to an attacker is large.

When we send data over networks that are not secure or trusted, an eavesdropper can glean a large amount of information from what we send. If we use applications or protocols that do not encrypt what they are sending over the network, we may end up giving our login credentials, credit card numbers, banking information, and other data to anyone that happens to be listening.

Data can be intercepted from both wired and wireless networks, often with very little effort, depending on the design of the network. We will discuss some of the tools that can be used to perform such interception later in the chapter.

Virtual private networks

The use of virtual private networks (VPNs) can provide us with a solution for sending sensitive traffic over unsecure networks. A VPN connection, often referred to as a tunnel, is an encrypted connection between two points. This is generally accomplished through the use of a VPN client application on one end of the connection and a device called a VPN concentrator on the other end. The client uses the software to authenticate to the VPN concentrator, usually over the Internet, and after the connection has been established, all traffic exchanged from the network interface connected to the VPN flows through the encrypted VPN tunnel.

VPNs are often used to allow remote workers to connect to the internal resources of an organization. When such a connection has been established, the connected device is able to act as though it were connected directly to the internal network of the organization hosting the connection. This can be very useful as it allows us to enable greater access for a remote worker than we would normally be able to do securely when the worker is outside the borders of our network.

In addition to allowing us access to the internal resources of our organization, VPNs may also be used to protect or anonymize the traffic we are sending over untrusted connections. Companies such as StrongVPN sell their services to the public for exactly such purposes, allowing us to protect the contents of our traffic from logging by our Internet service providers (ISPs) or being sniffed by others on the same network, to obscure our geographical location and bypass location-oriented blocking.

Such services are also popular with those that engage in peer-to-peer (P2P) file-sharing services. Such activity is often flagged by ISPs and by organizations such as the Motion Picture Association of America (MPAA) and the Recording Industry Association of America (RIAA) in order to prosecute those engaged in copyright infringement. VPNs can allow both the traffic and the actual IP addresses of those that engage in such activities to remain hidden from those that would seek them out.

Wireless network security

As we discussed earlier in this chapter, unsecured wireless networks freely broadcast our data for anyone with the appropriate (and very common) technology to hear. The present record for an unamplified 802.11 wireless connection is about 237 miles [4]. Although this was under ideal conditions, it does give us some idea of how far our wireless signals might carry. This means that, even in a much less favorable radio frequency (RF) environment, such as we might find in a residential area, someone miles away, with the right antenna, could potentially be eavesdropping on our network traffic.

In addition to the issues with our traffic being potentially listened in on, there is also the possible issue of wireless devices being placed without our knowledge. In particular, wireless access points being attached to our network without authorization, commonly known as rogue access points, can present a serious security issue.

For example, if we worked in an area where wireless was prohibited, we might find that an enterprising individual decided to bring in an access point of his or her own and install it under his or her desk, in order to provide wireless access to a nearby outdoor smoking area. Although this might not have been done with bad intentions in mind, this one simple action may have invalidated the entire set of carefully planned network security measures we have put in place by creating a back door.

If the rogue access point in our example was set up with poor security or no security at all, our well-intentioned access point installer would have just provided anyone within range of the access point with an easy path directly into our network, bypassing any border security that we might have in place. There is a possibility that a network IDS might pick up the activity from the rogue access point, but there is no guarantee of this. The simple solution to finding such rogue equipment is to carefully document the legitimate devices that are part of the wireless network infrastructure and regularly scan for additional devices using some of the wireless scanning tools which we will discuss later in this chapter.

For the legitimate and authorized devices on our network, our chief method of protecting the traffic that flows through them is the use of encryption. The encryption used by 802.11 wireless devices, the most common of the wireless family of network devices, breaks down into three major categories: Wired Equivalent Privacy (WEP), Wi-Fi Protected Access (WPA), and Wi-Fi Protected Access version 2 (WPA2). Of these, WPA2 is the most current and offers the strongest inherent security.

Secure protocols

One of the simplest and easiest ways we can protect our data is to use secure protocols. Many of the more common and older protocols, such as File Transfer Protocol (FTP) for transferring files, Telnet for interacting with remote machines, Post Office Protocol (POP) for retrieving e-mail, and a host of others, deal with data in an insecure manner. Such protocols often send sensitive information, such as logins and passwords, in cleartext (remember back to Chapter 5) over the network. Anyone listening on the network with a properly positioned sniffer can pick up the traffic from such protocols and easily glean the sensitive information from the traffic they send.

Many insecure protocols have secure equivalents, as we will discuss at greater length in Chapter 12. In brief, we can often find a secure protocol with the type of traffic we wish to carry. Instead of operating over the command line with Telnet, we can use Secure Shell (SSH), and instead of transferring files with FTP, we can use Secure File Transfer Protocol (SFTP), which is also based on SSH.

SSH is a very handy protocol for securing communications as we can send many types of traffic over it. It can be used for file transfers and terminal access, as we mentioned, and to secure traffic in a variety of other situations, such as when connecting to a remote desktop, communicating over a VPN, mounting remote file systems, and any number of other tasks. The encryption used by SSH is RSA, a public key encryption algorithm.

What is a mobile device?

When we hear the term mobile device discussed, we typically think of smartphones and tablets, at the present time largely running IOS from Apple or Android from Google, with a smattering of others thrown in. Additionally, there are a variety of head-mounted devices, smartwatches, and all manner of other devices. Finally we have USB or thumb drives. Mobile devices are used to send and receive e-mail, surf the web, manipulate documents, play videos, listen to music, play games, and numerous other activities; in short, these devices can perform most of the same functions as a nonmobile device.

The definition of what is and is not a mobile device has become considerably more blurred in recent years. Presently we have smartphones which rival the processing power and storage of some computers and have similarly capable operating systems. On the other hand, we have computers, including very small and light ultrabooks and devices such as the Raspberry Pi which run on minimal hardware and use very little power, some even running “mobile” operating systems such as Android. As distinguishing between these devices is largely a question of design philosophy rather than physical capability, the general inclination is to treat them the same from a security perspective. The most practical definition is any device that can access external systems or be acceded while not behind the organizations’ security infrastructure.

One of the potential areas where the difference between mobile and other devices actually is visible, from a security perspective, is centralized management of the data on them.

Mobile device management

While most devices that are not running a mobile operating system, that is, Windows, OS X, Linux, etc. have a well-established seat of tools and features that allow them to be centrally managed, this may not hold true with mobile devices. We generally want to be able to mandate patching and software upgrades, force changing of passwords at some interval, regulate and track installed software, adjust settings to a standard dictated by our policies, and a number of other similar functions. In order to enable these types of tasks, we generally turn to an external Mobile Device Management (MDM) solution such as those developed by Good Technologies, MobileIron, and a number of others.

The exact architecture of an MDM solution will vary from one vendor to another, but most utilize an agent on the mobile device that exists to enforce a certain configuration on the client. These agents typically regulate access to enterprise resources, such as e-mail, calendaring, or network resources, and can discontinue access by the client in the event that it becomes noncompliant in configuration, is stolen, or the user’s employment is terminated. Additionally, many MDM solutions enable the device to be remotely wiped, either completely or just corporate data, and/or disabled entirely.

As the distinction between mobile and nonmobile devices becomes narrower all the time, vendors of MDM solutions have begun to implement support of some devices that have been traditionally considered nonmobile. While this may seem like a considerable overlap with existing enterprise management tools, the ability to remotely manage both mobile and nonmobile devices using the same tools and techniques would result in less load on administrative resources, and would enable a greater uniformity across the set of devices in question.

Bring your own device

The term Bring Your Own Device (BYOD) is often brought up when discussing mobile device security. BYOD generally refers to an organization’s strategy and policies regarding the use of personal versus corporate devices. This can range from only corporate-owned devices being allowed to interact with enterprise resources to only personal devices being used and any combination in between. BYOD is very popular with folks managing the budget because they are leveraging equipment that the organization didn’t pay for. In some cases, they will push to move to BYOD without addressing the security because of the savings.

Allowing only corporate-owned devices can enable a considerably more uniform and secure base of mobile devices for the organization to manage. Depending on the policy implementation, we may choose to disallow the use of personal e-mail and file-sharing applications, for instance, and disable the capability of installing new applications that are not business related through an MDM solution, as discussed earlier in this section. We can also force users to install updates and security patches, change their password regularly, and any number of similar items which lead to a more secure mobile environment.

Choosing the other end of the spectrum, in which only personal devices are used and are not managed with MDM, precludes the use of many of these capabilities. Although some tools do exist that allow minimal control over devices as a function of connecting them to a centralized mail server, such as Microsoft Exchange, without active monitoring a savvy technical user can often subvert such measures with a small amount of effort. While this may be a good choice for a very small organization with minimal resources to administer a complex mobile infrastructure, this would likely not be optimal for a large enterprise.

The middle path, adopted by many organizations, is to allow some measure of each. In many cases, this results in a mix of personal and corporate-owned devices, perhaps with some restriction of capabilities for those with personal devices. In this way, we can allow the more secure and more trusted devices access to a greater set of resources, while still allowing personal devices to access basic services such as e-mail, providing that they agree to have these devices managed by an MDM tool and accept a reasonable set of security features. At the end of the day, this is a balance between cost and risk management.

Wireless

As we discussed earlier in the chapter, attackers accessing a wireless device can potentially bypass all our carefully planned security measures. Worse yet, if we do not take steps to ensure that unauthorized wireless devices, such as rogue access points, are not put in place on our network, we could be allowing a large hole in our network security and never know it.

We can use several tools to detect wireless devices. One of the best-known tools for detecting such devices is called Kismet, which runs on Linux and can be found on the Kali distribution. Kismet is commonly used to detect wireless access points and can find them even when attempts have been made to make doing so difficult. A similar piece of software, called NetStumbler, exists for Windows, although it does not have as full a feature set as Kismet.

In addition to detecting wireless devices, some tools can enable us to break through the different varieties of encryption that are in use on such networks. Many tools for such purposes exist, but a few of the more common ones for cracking WEP, WPA, and WPA2 include coWPAtty and Aircrack-NG.

Port scanners

Scanners are one of the mainstays of the security testing and assessment industry. We can generally break these into two main categories: port scanners and vulnerability scanners. There is some overlap between the two, depending on the particular tool we are talking about.

One of the more famous port scanners that we might want to use is a free tool called Nmap, short for network mapper. Although Nmap is generally referred to as a port scanner, we actually do it a bit of a disservice to call it that. Although Nmap can conduct port scans, it can also search for hosts on a network, identify the operating systems those hosts are running, detect the versions of the services running on any open ports, and much more.

For the most part, in terms of network security, scanners are the most useful when used as a tool for discovering the networks and systems that are in our environment. We will discuss some of the uses for scanners that are more specific to operating system security in Chapter 11.

Packet sniffers

A network or protocol analyzer, also known as a packet sniffer, or just plain sniffer,¹ is a tool that can intercept traffic on a network, commonly referred to as sniffing. Sniffing basically amounts to listening for any traffic that the network interface of our computer or device can see, whether it was intended to be received by us or not.

Alert!

One of the key elements in employing a sniffer is to place it on the network in the proper position to allow us to actually see the traffic we would like to sniff. In most modern networks, the traffic is segmented in such a fashion that we will likely not be able to see much traffic at all, other than what we are generating from our own machine. In order to be able to sniff properly, we will likely need to gain access to one of the higher-level network switches and may need to use specialized equipment or configurations to allow us access to our target traffic.

Tcpdump is a classic sniffing tool, and it has been around since the late 1980s. Tcpdump is a command-line tool that allows us to monitor the activities of the network to which we are attached and has only a few other key features, such as filtering of traffic. Tcpdump runs only on UNIX-like operating systems, but a version has been ported to Windows, called WinDump.

Wireshark, previously known as Ethereal, is a fully featured sniffer that is capable of intercepting traffic from a wide variety of wired and wireless sources. It has a graphical interface, as shown in Figure 10.3; it includes a large number of filtering, sorting, and analysis tools; and it is one of the more popular sniffers on the market today. Wireshark can also import data from other applications like Tcpdump. Wireshark is a great tool for troubleshooting traffic on the network so is used my many network operations teams as well as security teams.

Kismet, which we discussed in the “Wireless” section, is also a specialized sniffer. Although many of the other sniffers are network media agnostic, for the most part, Kismet will only sniff from wireless networks. Owing to this very specific focus, it can provide us with a much more specific set of tools.

We may also see packet sniffers in hardware form, such as the OptiView Portable Network Analyzer from Fluke Networks. Although we can definitely benefit from well-equipped portable analyzers such as this, they often tend to be very expensive and well beyond the budget of the average network or security professional.

Honeypots

Honeypots are a somewhat controversial tool in the arsenal of those we can use to improve our network security. A honeypot can detect, monitor, and sometimes tamper with the activities of an attacker. Honeypots are configured to deliberately display vulnerabilities or materials that would make the system attractive to an attacker. This might be an intentionally vulnerable service, an outdated and unpatched operating system, a network share named “top secret UFO documents,” or other similar items that might serve as bait for an attacker.

One of the interesting things about honeypots is that the vulnerabilities or data that is left out to bait the attacker is entirely false. In reality, honeypots are configured to display these items so that we can catch the attackers and monitor what they are doing on the system without their knowledge. This might be done in an effort to provide an early warning system for a corporation, as a method of researching what methods attackers are using, or as an intentional target to monitor the activities of malware in the wild.

We can also expand honeypots into larger structures by setting up several such systems in a network, often referred to as a honeynet. Honeynets can allow us to set up multiple honeypots with varying configurations and vulnerabilities, generally with some sort of centralized instrumentation for monitoring all the honeypots on the network. Honeynets can be particularly useful for large-scale monitoring of malware activity, as we can emulate a variety of different operating systems and vulnerabilities for our target systems to display. These systems can be used internally to a network to detect insider threats as well as the threats that got inside.

Firewall tools

In our kit of network tools, we may also find it useful to include those that can map the topology of and help locate vulnerabilities in our firewalls. Hping3 is a well-known and useful tool for such efforts. It is able to construct specially crafted Internet Control Message Protocol (ICMP) packets in such a way as to evade some of the normal measures that are put in place to prevent us from seeing the devices that are behind a firewall. We can also script the activities of Hping3 in order to test the responses of firewalls and IDSes, so that we can get an idea of the rules on which they are operating.

We can also use a variety of the other tools we have discussed in this section to test the security of our firewalls. We can use port and vulnerability scanners to look at them from the outside in order to find any ports that are unexpectedly open, or any services running on our open ports that are vulnerable to known attacks. We can also use sniffers to examine the traffic that is entering and leaving firewalls, presuming that we can get such a tool in place in a network location that will enable us to see the traffic.