SY110: Network Security Architectures


Network Security Architectures

Learning Outcomes

After completing these activities you should be able to:


Network Security Architectures Overview

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.

(Distributed) Denial of Service Attacks

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.

Defense in Depth

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).

Physical Controls

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.

Port Security

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.


Network Segmentation and Access Control Lists

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.)


Boundary Security: Firewalls, Intrusion Prevention Systems, and Route Verification

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.)

Whereas standard ACLs only filter by source IP address, extended ACLs consider additional information, such as traffic’s protocol and port values, similar to firewalls. However, extended ACLs are typically stateless, whereas firewalls are typically considered stateful. The nuance is less important for this course, and in some cases, vendors may use terms interchangeably or somewhat misleadingly.

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.






Firewall example: The screenshot above shows inbound 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.
  1. Rule #1 allows loopback traffic (indicated with the interface (in) labeled lo, used internally by the server itself for testing purposes).
  2. Rule #2 permits established and related connections, allowing for response traffic related to outbound requests (like DNS queries to external servers) to pass through the firewall.
  3. Rule #3 allows UDP traffic on port 53 from the internal network (10.0.0.0/8), enabling internal devices to send DNS requests to this server.
  4. Rule #4 allows inbound TCP traffic on port 22, but only from the IT department’s subnet (10.1.27.0/24), restricting who can SSH to this server.
All other inbound traffic will be denied by the default policy. Keep in mind, more stringent rules could be applied, such as limiting which external devices can communicate with the DNS server.



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.

Intrusion Detection Systems and Demilitarized Zones

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.

IDS vs IPS
IDS vs IPS. A road camera (left) could be considered an IDS - it might detect an intruder, but won't stop an intruder (such as an unauthrozied vehicle) on its own. Road spikes, on the other hand, would theoretically block an intruder by default, simiilar to an IPS.

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.

Virtual Private Networks

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.)

VPN Tunnel and Internal Network Connections
VPN Tunnel and Internal Network Connections. This netowrk diagram illustrates the path of an encrypted VPN tunnel established from an external host
to a VPN server located within a DMZ as well as an internal connection path to access data within a server farm.

VPN Privacy and Encryption
VPN Privacy and Encryption. This illustration depicts a user in the U.S. utilizing a VPN server in Brazil to connect to web services in France. The encrypted tunnel provides confidentiality for the open WiFi connection and also masks their location by making the source of traffic requests coming from the VPN server. From the web server perspective in France, requests are coming from Brazil.

Endpoint Security: Anti-Virus Software and Endpoint Detection and Response Systems

What if all these network protections fail, and malicious traffic - such as malware in an email attachment - gets onto a user device? In this case, devices may have antivirus (A/V) software or endpoint detection and response (EDR) capabilities installed to monitor devices for malware. A/V typically scans for known malware signatures and suspicious files, while EDR tools are more advanced, offering additional protections on top of traditional A/V software. For instance, some EDR tools can use behavioral- and anomaly-based detection systems to uncover unknown threats, while traditional A/V systems are usually limited to finding already identified malware. (Don’t forget, protections we’ve previously discussed, such as protecting password files and sanitizing user entries on web servers, still apply!)

    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
    +-----------------------+


Supplemental Media:

+ Exercise - Interactive Firewall Activity


Network Security: What is a DMZ?


Review Questions:

  1. What types of network security technologies are implemented within the boundary perimeter?
  2. How are network security technologies employed at each layer of the TCP/IP stack?
  3. What is defense-in-depth and how do network security architectures leverage its concepts?
  4. What are the differences between the use of IDS v. IPS?
  5. How does network segmentation limit access to different parts of an enterprise network?
  6. What types of services are deployed within a DMZ?
  7. How are VPNs utilized and what security protections are provided by its use?
  8. What technologies are utilized to provide endpoint security?