After completing these activities you should be able to:
This lecture will discuss various network security tools and approaches, under the overarching umbrella concept of network security architectures. As we discuss various security measures, keep in mind that security also relies upon some of the human factors and policy considerations discussed in recent lectures, such as humans’ willingness and ability to properly utilize security tools. While this lecture is more technical in nature, don’t lose sight of the importance of people and processes!
We’ve already discussed some types of attacks in this course, such as cross-site scripting attacks on websites or attacks on authentication mechanisms (brute force, rainbow tables, etc.). In the next class, we will discuss malware and vulnerabilities in more detail, which is often associated with running programs. This lecture will focus on network-based attacks. Keep in mind, there isn’t always a clean break between what is and is not ‘network-based’ - for instance, brute forcing a login to a website requires a network, though it might not be considered an attack on a network, per se.
One major category of network attacks are those designed to disrupt services, known as Denial of Service (DoS) attacks. These attacks attempt to overwhelm a system so legitimate users cannot connect. When multiple attackers or compromised devices coordinate these efforts, it becomes a Distributed DoS (DDoS), making defense even more challenging. Often, many compromised machines - bots - are controlled by an attacker, making up a larger botnet (the attacker often controls these through a command and control, or C2, node or server). The primary target of a DDoS or DoS attack is system availability.
To address this complex threat landscape, security professionals rely on the principle of Defense in Depth (DiD), which means applying multiple layers of defense rather than relying on any single measure. Consider the Carrier Strike Group as an analogy: multiple ships and aircraft, along with their associated sensors and weapon systems, form overlapping layers of physical defense. Threats might be engaged farthest out by fighter aircraft from the Carrier Air Wing; as a threat gets closer, Standard Missiles or the 5-inch gun may be employed. Even more immediate threats might be dealt with by CIWS, RAM, or various decoy systems. While certain systems might be optimized for certain threats, overlapping defenses attempt to avoid single points of failure.
To better understand the concept of DiD in action, consider a notional network, as illustrated in the diagram below. This network includes wired and wireless hosts, layer 2 switches, layer 3 routers, and various servers. This network topology is relatively simple - we’ve excluded smartphones, Internet of Things (IoT) devices, printers, webcams, and the like, which may pose unique challenges - but it still functions well enough for our discussion.
This network could be administered by a school, company, military organization, or similar group. There is an internal side of the network, controlled by the organization, and an external portion, which connects to the larger internet, with a boundary in between the two. One unique exception is the Demilitarized Zone (DMZ); this enclave, which we will discuss in more detail later, is controlled by the organization, but is typically considered to sit outside the boundary. As we discuss the application of DiD, you’ll notice there is a strong relationship to the layers of protection, and the layers of the network stack (although some security solutions interact across layers, and others don’t neatly align to a layer of the stack).
As such, we will begin with physical controls. Organizations will use various means - security guards, ID checks, clearance levels, controlled compartmented facilities, etc. - to physically control access to network infrastructure. Here is where human factors and policies certainly come into play - well-meaning employees may be duped into letting an intruder access an installation. Personnel security policies, meanwhile - such as background checks and polygraphs - serve as a non-technical means of limiting access.
The next layer of control is port security. Switches may be configured to allow or block devices based on their MAC address, reducing unauthorized network access. MAC addresses can be spoofed, however, so this is an insufficient defense on its own - and it can be difficult to identify all authorized MAC addresses for a large organization.
The next step is network segmentation, which logically (and possibly physically) divides the network. Tools such as Access Control Lists (ACLs) can block or allow traffic based on the source IP address. As a result, even if a single device is compromised, segmentation may limit an attacker’s ability to move from one device to another or to move across networks.
In the graphic below, ACL 10 prevents a member from the Sales Department from accessing the IT Department’s segment of the network; if a sales representative’s computer is compromised, the impact is contained. In this instance, the Sales Department is also prevented from accessing the Utilities Department’s network segment, and vice versa. (If a device in the IT department is compromised, however, segmentation won’t help much in this scenario.)
Blocking traffic by IP address might work in some circumstances, but it’s a rather blunt tool. Firewalls provide similar security, but with additional flexibility, such as the ability to allow or block specific protocols, or even specific aspects of a protocol. For instance, a firewall may allow port 443 traffic to pass through to enable web communication, but block port 22 to prevent SSH connections. Other rules might allow outbound ICMP requests, but block incoming ones, allowing an organization to test the connectivity of remote systems but denying attackers the ability to probe for connected devices on the organization’s network. Firewalls use a series of rules, read in order, to determine if traffic should be allowed into a network. The last rule - the default for all traffic that doesn’t match any previously prescribed rule - is usually to deny (or drop) any traffic. In other words, the presumption is that traffic is malicious, and it’s only allowed into a network if it meets a previously identified, legitimate use, as indicated by an associated firewall rule. (A user or organization can change this behavior, providing a default rule to allow any traffic, but such a permissive approach incurs greater vulnerability for a network.)
Some firewalls are capable of even more powerful analysis, known as Stateful Packet Inspection (SPI) and Deep Packet Inspection (DPI). SPI filters will keep track of existing sessions (think: TCP connections), allowing it to recognize and block spoofed session traffic. DPI filters go even further, evaluating application-layer data in an attempt to identify threats. As you can imagine, SPI filters require more computational resources than simple firewall rules, and DPI filters require even more resources than that.
Firewalls can be set up within the internal network of an organization, but they also may be set up to filter traffic coming across the network boundary mentioned earlier. Here, it’s common for organizations to employ an Intrusion Prevention System (IPS) to monitor traffic across the boundary and block potentially hazardous traffic. IPS are usually configured to automatically block malicious traffic, as well as alerting network security personnel.
iptables firewall rules that might be applied to an internal DNS server. The default policy is set to DROP, meaning any inbound traffic not explicitly allowed by the rules will be denied.
in) labeled lo, used internally by the server itself for testing purposes). An additional consideration is that at network boundaries, routers exchange routing information with external peers (for example, an Internet Service Provider). False or malicious route updates could potentially allow an adversary to redirect, block, or modify traffic, threatening the confidentiality, integrity, and availability of network traffic. Route verification prevents this by using cryptographic authentication mechanisms (incorporating aspects of hashing and symmetric cryptography) to help ensure that updates come from trusted neighbors and haven’t been tampered with. On the global Internet, technologies like Resource Public Key Infrastructure (RPKI) add another layer of verification, confirming that route advertisements match authorized IP address owners.
Now that we’ve reached the boundary of our network - the separation of the internal and external components - let’s talk about the Demilitarized Zone (DMZ). A DMZ sits outside of the internal network, making it accessible for users across the web. Consider a company with a website - the company has internal affairs (payroll, human resources, IT policies, etc.) that don’t need to be accessed by external actors, so that remains internal. However, the company’s public-facing website - what you as a normal user would browse to - should be accessible, so it will be placed externally.
However, just because something is external doesn’t mean we don’t care what happens to it - we would still want to monitor for suspicious activity. Organizations will often place an Intrusion Detection System (IDS) in the DMZ; it monitors for suspicious activity and alerts administrators, but does not automatically take blocking actions. This is a risk tradeoff - an organization accepts that an external, publicly-facing website could receive malicious network traffic, but decides to take a reactive posture in order to maintain greater availability. The purpose of having the DMZ is that if an actor compromises an external device (such as the publicly-facing webserver), they still have not accessed the internal network.
In the paragraphs above, we said internal affairs don’t need to be accessed by external actors - but what if they do? For instance, you may want to access internal Academy resources while off the Yard at your sponsor’s house. Exposing the entirety of USNA’s internal network to the world could be dangerous, but there is a solution: a Virtual Private Network (VPN).
With a VPN, a user device makes an encrypted connection to a VPN server, and that server forwards traffic to the destination. This can have multiple benefits, such as protecting data in transit on a public wifi network, granting access to networks that would otherwise be unavailable, or obfuscating the location of a device. (Keep in mind, using any VPN server will not necessarily grant you access to the internal network; you must connect to the VPN server(s) trusted by an organization, as these devices will be allowed to make a connection from outside the boundary to internal devices.)
TCP/IP STACK LAYERS
+-----------------------+
| Layer 5 - APPLICATION | >>> DMZ, EDR, Firewall: DPI
+-----------------------+
| Layer 4 - TRANSPORT | >>> Firewall: SPI, IDS, IPS
+-----------------------+
| Layer 3 - NETWORK | >>> ACL, IGP/EGP route verification, VPN, Firewall: Packet Filtering/NAT
+-----------------------+
| Layer 2 - DATA LINK | >>> Port Security, authentication management
+-----------------------+
| Layer 1 - PHYSICAL | >>> locks, cabinets, controlled access, perimeter fencing and sensors
+-----------------------+