Network Security Basics

Table of Contents

• Module 1: IT Security Concepts
  • The Need for IT Security
  • The CIA Triad: Confidentiality, Integrity, and Availability
  • Threats, Vulnerabilities, and Exploits
  • Reducing Threat Exposure with Zero Trust
  • Defense in Depth
• Module 2: Authentication Methods
  • Authentication, Authorization, and Accounting (AAA)
  • Authentication Protocols and Single Sign-On
  • Multifactor Authentication
  • Network Access Control
• Module 3: Security Assessments
  • Categorizing Risks in IT
  • Assessing Risk: Security and Business Professionals
  • Demo: Scanning a Host with Nmap
  • Business Risk Assessments
  • Security Information and Event Management (SIEM)
• Module 4: Common Network Attacks
  • Human Exploits and Social Engineering
  • Technical Exploits: DoS and DDoS Attacks
  • Wi-Fi Attacks
  • On-Path (Man-in-the-Middle) Attacks
  • Rogue DHCP Servers
  • Password and Other Attacks
• Module 5: Network Hardening Techniques
  • Securing Layer 2: VLANs and Port Security
  • Demo: Examining Port Security Operation
  • Preventing Rogue DHCP Servers at the Switch
  • Dynamic ARP Inspection
  • Securing Layer 3 and Layer 4 with ACLs
  • Securing Layer 7 and Above
  • Demo: Examining Netstat
• Module 6: Wireless Security
  • Wireless Encryption Standards
  • Demo: Wireless Security Options on a Controller
  • Geofencing
  • Other Wireless Security Considerations
• Module 7: Remote Access and Security
  • Remote Access Overview
  • Secure Shell (SSH)
  • Demo: Examining SSH
  • Virtual Private Networks
  • Split Tunnel vs. Full Tunnel VPNs
  • Remote Desktop Connections
  • Demo: Remote Desktop Connection
  • Virtual Desktops and Remote Desktop Gateways
  • Network Management: In-Band vs. Out-of-Band
• Module 8: Physical Security
  • Video Surveillance
  • Asset Tracking and Disposal
  • Facility Access Controls
• Summary

This course introduces the foundational terminology, concepts, and technologies used to secure IT infrastructure and networks. It covers how threats and vulnerabilities are identified, the methods used to authenticate users and devices, the most common categories of network attacks, the techniques used to harden network devices against those attacks, and the remote access technologies (such as VPNs) that let users and administrators reach corporate resources securely. By the end of this material, you should understand the concepts, protocols, and techniques used to identify and secure the threats that can compromise IT infrastructure.

Module 1: IT Security Concepts

In IT, there are risks involved in collecting, storing, using, and managing data, services, and employees. This module introduces the high-level concepts and some of the technical detail behind why organizations need IT security, and the terms, concepts, and tools used to help prevent network attacks and alert defenders when they occur. The practices described here represent widely recognized best practices; not every organization implements all of them, since each organization is on its own maturity journey with respect to security.

The Need for IT Security

Simply by existing in society and using the internet, personal information about each of us is stored on a computer somewhere — likely on a server in a data center, and likely reachable in some way via the internet. This can include:

• Name, address, age, and profession
• Location and travel behavior
• Gender identity and marital status
• Home security camera footage
• Photos uploaded to the cloud
• Personal interests
• Medical records
• Purchase history
• Bank account information

All of this information is valuable, and the primary reason it is collected comes down to money. Consider a medical practice: it is not directly selling patient records, but it may anonymize data (removing names, addresses, phone numbers, and other uniquely identifying details), aggregate it across many patients, and sell that anonymized data to researchers who use it to improve medical outcomes. Social media platforms operate similarly — every post, status update, or shared photo helps a platform build a profile of a user’s interests, which is then used to sell targeted advertising. This is fundamentally how most social media companies generate revenue, and it is why they are worth billions of dollars.

The CIA Triad: Confidentiality, Integrity, and Availability

Because this data is valuable both to the individual it describes and to the organization storing it, IT security is organized around three core goals, commonly abbreviated CIA:

These three properties apply well beyond medical records and banking — they matter for social media platforms and any business that depends on user data and interaction being trustworthy and accessible. The goal of an IT security program is to ensure that stored data meets all three criteria so it can be used to its full potential without unacceptable risk.

flowchart TD
    CIA["CIA Triad"]
    CIA --> C["Confidentiality<br/>Keep data secret from<br/>unauthorized parties"]
    CIA --> I["Integrity<br/>Keep data accurate<br/>and untampered"]
    CIA --> A["Availability<br/>Keep data accessible<br/>to authorized users"]

Threats, Vulnerabilities, and Exploits

These three terms are frequently used interchangeably in casual conversation, but they describe distinct concepts.

The National Institute of Standards and Technology (NIST) defines a threat as:

Any circumstance or event with the potential to adversely impact organizational operations, organizational assets, individuals, other organizations, or a nation through a system via unauthorized access, destruction, disclosure, or modification of information, and/or denial of service.

In plain terms, a threat is any circumstance or event — malicious or not — that can adversely impact an organization through unauthorized access, destruction, disclosure, modification, or denial of information. Threats can be:

• Internal, such as a disgruntled employee seeking to harm the organization, or an ignorant employee who simply doesn’t know the correct policies and procedures.
• External, such as an attacker on the internet, or even a non-malicious event like a construction crew accidentally severing a fiber-optic line running to a data center.

A vulnerability is a weakness — technical, procedural, or human — that could be exploited. A simple analogy: a home’s windows are a vulnerability, since a thrown rock can shatter the glass and grant entry. In IT, workstations run software written by humans, on operating systems written by humans, running on hardware designed by humans — every layer of that stack introduces the possibility of vulnerabilities, some known and some not yet discovered.

MITRE maintains an extensive, public catalog of known vulnerabilities called CVE (Common Vulnerabilities and Exposures), published at cve.org. This database can be searched by keyword (for example, a search for “HTTP” returns thousands of matching CVE records) and can even be downloaded in bulk so that organizations can scan their own systems and check whether their software versions are affected by a known issue.

One category of vulnerability that CVE does not cover is the 0-day (zero-day) vulnerability — a vulnerability that an attacker has discovered and figured out how to exploit before it has ever been publicly documented. Because no prior knowledge of the flaw exists, the organization being attacked typically has no way to defend against it in advance. Zero-day exploits are frequently reported in the media as the cause of major breaches.

An exploit is the mechanism used to take advantage of a vulnerability. Having a vulnerability does not automatically mean a system is at risk — the exploit is what actually leverages the weakness. Returning to the window analogy: the vulnerability is the fragile glass; throwing the rock is the exploit. In IT, an exploit could be malware, a virus, or an attacker who has obtained valid credentials and uses them to send traffic into the infrastructure that takes advantage of a known weakness.

flowchart LR
    T["Threat<br/>A circumstance or event that could<br/>cause harm (internal or external,<br/>malicious or accidental)"] --> V["Vulnerability<br/>A weakness that could be<br/>taken advantage of"]
    V --> E["Exploit<br/>The actual mechanism used<br/>to take advantage of the<br/>vulnerability"]
    E --> Impact["Compromise of Confidentiality,<br/>Integrity, or Availability"]

Reducing Threat Exposure with Zero Trust

Zero trust is a security philosophy in which no device — a new workstation, a home user’s personal laptop connecting over VPN, a smartphone, or even a cloud service provider’s infrastructure — is trusted until it has been run through a defined set of procedural and technical checks. Achieving true zero trust is difficult in practice, especially in organizations with deadlines and constant operational pressure, but the model can be broken into four components:

flowchart TD
    ZT["Zero Trust"] --> UIA["User Identity<br/>and Authentication"]
    ZT --> DIA["Device Identity<br/>and Authentication"]
    ZT --> PCD["Policy Compliance<br/>and Device Scan"]
    ZT --> AAC["Application Authorization<br/>and Access Control"]

User identity and authentication. Modern practice favors role-based access: users, and even automated scripts, are only granted access to the systems required for their role — a significant departure from the loosely governed, broadly administrative access common in many organizations during the 1990s, when most systems were not internet-connected and the primary threat was limited to internal users or physical intruders. Role-based access builds on the principle of least privilege: grant the minimum access necessary, whether for a human user or a background automation script. A script that performs routine database maintenance, for example, should be given only the specific privileges it needs — if that script’s account is compromised, the blast radius should be as small as possible. Infrastructure teams should also apply separation of duties, so no single administrator has unilateral access to every system; multi-person processes create checks and balances that prevent abuse.

Device identity and authentication. This mirrors the evolution of airport security: prior to 2001, travelers could walk through a checkpoint with minimal identity verification. Modern checkpoints require an agent to validate a ticket and an ID before baggage is scanned and the traveler passes through a metal detector. IT applies the same layered model through Network Access Control (NAC):

1. Authenticate the user (credentials).
2. Authenticate the device (confirm it’s an authorized, known device, not an attacker’s machine or an unapproved personal laptop).
3. Scan the device for patch level, up-to-date software, and absence of malware/ransomware.
4. Grant least-privilege access based on role.

This can be genuinely difficult with legacy equipment — for example, medical devices such as MRI machines or CT scanners that were approved by regulators like the FDA years ago, where recertifying an update is expensive and slow, so those systems often remain stuck running with broader access than is ideal.

Policy compliance, network segmentation, and screened subnets. Organizations can further reduce exposure through network segmentation — placing devices into separate VLANs so that, where needed, a firewall can sit between the general network and a sensitive device. A firewalled zone that hosts internet-facing resources reachable both externally and internally is known as a screened subnet, more commonly known by the older term DMZ (demilitarized zone) — borrowed from the buffer zone maintained between hostile countries. A DMZ lets an organization write firewall rules such as “allow access to this server from this specific group of devices, deny everyone else,” so that (for example) a public web server can be reached from the internet while an internal intranet site remains reachable only from inside the network.

A related technique is the honeypot — a deliberately placed, realistic-looking but fake resource (a database, a fake internal web application) placed in a screened subnet. If an attacker penetrates the network and is redirected into the honeypot, defenders can observe and delay them there rather than letting them reach real, sensitive systems.

flowchart LR
    Internet((Internet)) -->|Firewall Rules| Screened["Screened Subnet / DMZ"]
    Screened --> WebServer["Public Web Server<br/>(internal + external access)"]
    Internal["Internal Network"] --> Intranet["Intranet Site<br/>(internal access only)"]
    Screened -.->|Redirected attacker traffic| Honeypot["Honeypot<br/>(fake sensitive data)"]

Defense in Depth

Defense in depth ties all of these techniques together: a policy of zero trust, least privilege for users/devices/scripts, role-based access, enforced network segmentation, screened subnets/DMZs, network access control, and honeypots. No single control is sufficient on its own — applying these concepts together, as best as an organization’s maturity allows, helps prevent common attacks and protects the confidentiality, integrity, and availability of network systems.

flowchart TD
    DiD["Defense in Depth"] --> ZT2["Zero Trust Policy"]
    DiD --> LP["Least Privilege"]
    DiD --> RBA["Role-Based Access"]
    DiD --> NS["Network Segmentation"]
    DiD --> DMZ["Screened Subnets / DMZs"]
    DiD --> NAC2["Network Access Control"]
    DiD --> HP["Honeypots"]

Module 2: Authentication Methods

Authenticating users is a critical line of defense that requires, at minimum, a username and password before granting access to an IT system. This module covers Authentication, Authorization, and Accounting (AAA); the protocols and services used to authenticate users and devices; multifactor authentication; and network access control at Layer 2.

Authentication, Authorization, and Accounting (AAA)

AAA describes three related but distinct components of access management:

Two dominant service families implement AAA and typically work alongside a separate directory of usernames and passwords:

Both act as a middleman that processes authentication requests on behalf of network devices, typically working in conjunction with a directory service.

Authentication Protocols and Single Sign-On

Local authentication is what most people experience on a personal device — a passcode, face, or fingerprint check performed entirely on the local device against a local credential store.

In a larger organization, domain authentication is used instead: credentials are sent to a central server — typically Microsoft Active Directory — for validation, rather than being checked locally.

The protocol used for this exchange is Kerberos, which:

• Encrypts the authentication exchange so the username and password cannot be intercepted in transit.
• Validates that the connecting device is authorized to send credentials to the Active Directory server.
• Issues tickets that authorize the user and device to access multiple systems without re-entering credentials.

Kerberos works alongside LDAP (Lightweight Directory Access Protocol), together enabling Single Sign-On (SSO) — a single set of credentials that grants access to many internal services. For example, a login might be validated via Kerberos against Active Directory, and once authorized, the same session grants access to an accounting application. SSO is popular because it is both more convenient for users and more secure — users with only one set of credentials to remember are less likely to write passwords down or reuse them across many systems, which would otherwise defeat the purpose of having credentials at all. This same pattern extends to the consumer internet, where apps commonly let users “sign in with” Facebook, Apple, or Google rather than creating a new username and password for every app.

sequenceDiagram
    participant U as User Device
    participant AD as Active Directory (KDC)
    participant App as Internal Application

    U->>AD: Kerberos: Username + Password (encrypted)
    AD-->>U: Ticket-Granting Ticket
    U->>App: Present ticket (via LDAP-integrated service)
    App->>AD: Validate ticket
    AD-->>App: Authorized
    App-->>U: Access granted (Single Sign-On)

Multifactor Authentication

Multifactor authentication (MFA) adds one or more additional verification factors beyond a username and password. These factors are commonly categorized as:

MFA is significantly more resistant to compromise than a username and password alone, since an attacker who has obtained valid credentials (for example, from a breached-password database) is still blocked by the second factor.

mindmap
  root((Multifactor Authentication))
    Something You Know
      Username
      Password
    Something You Have
      Key card / fob
      Authenticator app code
    Something You Are
      Fingerprint / Face ID
      Retinal / hand scan
    Somewhere You Are
      IP-based geolocation
    Something You Do
      Signature dynamics
      Speech recognition

Network Access Control

By default, a network switch simply forwards Layer 2 traffic between connected devices with no authentication required. Switches can instead be configured to require an authenticating device to present credentials before the port is fully enabled. The workflow is:

1. The connecting device sends authentication information to the switch.
2. The switch forwards that authentication request to an Active Directory, TACACS+, or RADIUS server.
3. If authorized, the server instructs the switch to open the port and complete the Layer 2 connection.

The same concept applies to wireless networks. Home Wi-Fi networks commonly rely on a simple pre-shared key, but enterprise wireless networks typically authorize the connecting device using a username/password or certificate — a more sophisticated approach than a shared passphrase. The protocols used to accomplish this are 802.1X (a Layer 2 port-based access control standard commonly used on switches) and EAP (Extensible Authentication Protocol), frequently used together, especially in enterprise wireless deployments (EAP variants are covered further in the wireless security module).

flowchart LR
    Dev["Connecting Device"] -->|802.1X / EAP credentials| SW["Switch or Wireless Controller"]
    SW -->|Forward credentials| AAA["RADIUS / TACACS+ / Active Directory"]
    AAA -->|Authorized| SW
    SW -->|Port enabled| Dev
    AAA -.->|Denied| SW
    SW -.->|Port remains blocked| Dev

Module 3: Security Assessments

Understanding the threats an organization faces, and where vulnerabilities might allow an attacker to take advantage of them, requires periodic security assessments.

Categorizing Risks in IT

IT risk can be grouped into three categories:

mindmap
  root((IT Risk Categories))
    Technical Risks
      External attackers
      Internal bad actors
      Design/config errors
      Rushed temporary fixes
    Facilities Risks
      Unsecured data centers
      Switch closets doubling as janitorial rooms
      Lack of leadership buy-in
    Human Risks
      Phishing
      Password sharing
      Social engineering

Technical risks are often the first thing people associate with IT security — an external attacker sending malicious traffic — but internal risk is just as significant: disgruntled insiders, design errors, or rushed/incomplete fixes that are never properly resolved.

Facilities risks arise when physical infrastructure isn’t adequately secured. Data centers benefit from access control (card readers) and video surveillance, but switch closets are a frequently overlooked risk — they are often carved out of existing janitorial closets that have running water, mops, brooms, and frequent foot traffic, all of which pose a real risk to expensive, business-critical network equipment (a mop handle can snag and damage cabling, for example). Facilities planners do not always appreciate how critical IT infrastructure has become to the modern business.

Human risks are arguably the number-one IT security risk. Phishing emails trick recipients into believing a message originates from a trusted source. A classic technique: sending mail from a domain such as amazonaccounts@amazon.badnastysite.com — the visible brand name (“amazon”) is only a subdomain of the actual, unrelated domain badnastysite.com. Many phishing emails are poorly written with obvious grammar and spelling errors, though not all are. Organizations that fail to invest in security-awareness training for employees are exposed to real operational consequences: one described scenario involved employees repeatedly clicking phishing links purporting to be from “IT” threatening to disable email access unless the recipient acted immediately. This led to compromised credentials being used to blast out mass phishing email from the organization’s own mail servers, which in turn got the organization’s mail servers blacklisted by spam filters — causing 24–48 hours of legitimate email disruption each time it happened, on a roughly monthly basis.

Other human-risk vectors include malicious links (mitigated with URL filtering against known-bad site lists), malicious email attachments (mitigated with antivirus/attachment scanning), and simple credential sharing — historically, help desk staff would ask users directly for their password to troubleshoot, training users to hand out credentials to anyone claiming to be “IT.” No one but the account owner should ever know a password — this remains a critical point of security-awareness education, since social engineers exploit exactly this trained behavior.

Assessing Risk: Security and Business Professionals

Organizations reduce risk through a combination of internal policies/procedures/processes, Security Information and Event Management (SIEM) tooling, and periodic external audits performed by hired professionals.

Security assessment professionals perform technical risk assessments, producing a report for management that covers:

flowchart TD
    SA["Security Assessment"] --> TA["Threat Assessment<br/>Which threats matter most?"]
    SA --> VA["Vulnerability Assessment<br/>Design, facilities, firewall<br/>rules, server config"]
    SA --> PA["Posture Assessment<br/>Device patch level,<br/>malware scan"]
    SA --> PT["Penetration Testing<br/>Authorized simulated attack"]
    TA & VA & PA & PT --> Report["Report to Management"]

Demo: Scanning a Host with Nmap

The narration demonstrates using Nmap (via its graphical interface, though a command-line version exists for both Windows and Linux) to scan a host and enumerate the services running on it — a task a penetration tester would routinely perform.

Steps performed in the demo:

1. Launch the Nmap GUI on a Windows 10 workstation.
2. Enter the target host’s IP address (10.128.50.43) and leave all other options at their default (“Intense Scan”).
3. Run the scan and wait for it to complete — Nmap performs port scanning, traceroutes, script scanning (OS/service fingerprinting), DNS scans, and SSH scans, among other checks.
4. Review the results across several tabs.

Ports and Nodes tab — example findings:

A security professional reviewing this output would evaluate each listed service to confirm it is expected and required, and would disable unencrypted or unnecessary services (particularly protocols like plain HTTP or unencrypted SMB in an enterprise setting).

Other tabs:

• Topology — shows relative network position when multiple hosts are scanned (only one host was scanned here, so no topology graph is produced).
• Host Details — reports OS fingerprint (in this case, a Linux 3.x kernel identified with high confidence), uptime (unknown in this run), and IP address.
• OS Classes / fingerprint data — details supporting the OS identification.

Additional scan profiles available in the Nmap GUI include “Intense Scan plus UDP” and “All TCP Ports,” and a command-line tab allows fully custom switch combinations for targeted scans — the option most security professionals would use directly on Linux.

sequenceDiagram
    participant P as Pen Tester / Nmap
    participant H as Target Host

    P->>H: TCP/UDP port probes
    P->>H: OS/service fingerprinting scripts
    P->>H: DNS / SSH specific checks
    H-->>P: Open ports + banners
    H-->>P: OS fingerprint (e.g., Linux 3.x)
    P->>P: Compile report: unexpected/unencrypted services flagged

Business Risk Assessments

A business risk assessment professional evaluates whether weaknesses in IT infrastructure could threaten the viability of the business itself, rather than focusing purely on technical findings. Responsibilities include:

• Reviewing whether documented policies and procedures are actually being followed in practice.
• Cross-referencing security assessment findings against the nature of the business to determine whether the organization could suffer a business-ending event due to an IT compromise.
• Recommending realignment of policy, procedure, and technical controls to reduce that risk.
• Assessing the security posture of vendors — for example, a small ISP/MSP hosting a purchased software product, or a large cloud provider (AWS, Google Cloud, Microsoft Azure) hosting organizational data — since the organization’s own risk is tied to the security practices of every vendor it depends on.

Security Information and Event Management (SIEM)

SIEM (Security Information and Event Management) systems ingest logging and SNMP monitoring data collected continuously from devices across the network and correlate events across all of those sources. This correlation makes it possible to:

• Generate audit reports validating that users are behaving as expected.
• Detect a virus outbreak and trace its path across the network to aid containment.
• Support broader investigation and compliance reporting.

flowchart LR
    Logs["Device Logs"] --> SIEM["SIEM Platform"]
    SNMP["SNMP Monitoring Data"] --> SIEM
    OtherSrc["Other Event Sources"] --> SIEM
    SIEM --> Correlate["Event Correlation"]
    Correlate --> Audit["Audit Reports"]
    Correlate --> Detect["Outbreak Detection<br/>and Path Tracing"]

Module 4: Common Network Attacks

This module covers foundational categories of network attacks relevant to a Network Security Basics course. Readers interested in a deeper, hands-on treatment of ethical hacking techniques should pursue dedicated advanced coursework on the subject.

Human Exploits and Social Engineering

Social engineering tricks people into taking action they should not take:

• Phishing — sending a deceptive message (often an email) with a malicious link intended to harvest credentials or payment information.
• Impersonation — pretending to be someone with legitimate authority to request access or information. A real-world non-IT example: a hotel front-desk agent left a room key for a “friend” without ever verifying that the requester was actually a registered guest of that room — the same failure to verify identity plays out when an attacker calls pretending to be “the help desk” and asks for a username and password.
• Malicious USB drop attacks — leaving an attractive-looking USB drive in a parking lot in hopes an employee will plug it into a work computer, unknowingly installing malware. Less prevalent today given cloud storage adoption, but still a viable vector.
• Tailgating / piggybacking — following an authorized person through a secured door (e.g., a data center entrance) by taking advantage of common courtesy (holding the door).
• Shoulder surfing — visually observing a PIN, password, or sensitive on-screen information over someone’s shoulder (e.g., at an ATM or in an open office).

flowchart TD
    HE["Human Exploits"] --> Phish["Phishing"]
    HE --> Imp["Impersonation"]
    HE --> USB["Malicious USB Drop"]
    HE --> Tail["Tailgating / Piggybacking"]
    HE --> Shoulder["Shoulder Surfing"]

Technical Exploits: DoS and DDoS Attacks

A Denial of Service (DoS) attack aims to make a system or service unavailable. A well-known historical example is the 1995-era “Ping of Death” against Windows 95, where a maliciously crafted ping packet could crash the target machine (blue screen), requiring a reboot — a vulnerability that no longer applies to modern operating systems.

Modern DoS attacks are typically Distributed Denial of Service (DDoS) attacks that rely on IP spoofing — crafting packets with a forged source address so that responses are misdirected toward an unsuspecting victim rather than the attacker:

• Reflective DDoS — the attacker sends a request to an intermediary server with the source address spoofed as the victim’s address; the intermediary’s response floods the victim, who never actually made the request.
• Amplification attack — commonly using DNS: the attacker sends many DNS resolution requests to open DNS servers with the source address spoofed as the victim, and the (often much larger) DNS responses flood the victim.

Compromised IoT devices (smart lightbulbs, small connected appliances) are frequently recruited into large-scale DDoS botnets — a single vulnerable IoT device model, multiplied across millions of installed units, can generate enough malicious traffic to take down major DNS infrastructure and, by extension, large swaths of the internet (this has happened in real large-scale DNS outages that impacted major online services). Because IoT devices are so numerous and each has a unique source address, it is very difficult to reliably distinguish malicious DDoS traffic from legitimate traffic and block only the former.

flowchart LR
    Attacker(["Attacker<br/>(spoofed source address)"]) -->|"Request appears to come from Victim"| Intermediary["Reflector / DNS Server"]
    Intermediary -->|Large response| Victim(["Victim<br/>(never made the request)"])

Wi-Fi Attacks

flowchart TD
    subgraph Legit["Legitimate Network"]
        AP1["Legitimate AP"]
    end
    subgraph Evil["Attacker"]
        AP2["Rogue / Evil Twin AP<br/>(same SSID)"]
    end
    Client["Client Device"] -.->|Deauth frames force disconnect| AP1
    Client -->|Auto-reconnects to known SSID| AP2
    AP2 -->|Relays / inspects traffic| Internet((Internet))

On-Path (Man-in-the-Middle) Attacks

An on-path attack (also called a man-in-the-middle attack) frequently relies on ARP spoofing. Normally, a workstation broadcasts an ARP request asking “who has the default gateway’s MAC address?” and the legitimate gateway replies. In an ARP spoofing attack, the attacker floods the network with unsolicited ARP replies claiming that the attacker’s MAC address is the default gateway. Victim devices update their ARP caches accordingly and begin sending all outbound traffic to the attacker’s device first. Combined with additional trickery around certificates, the attacker can potentially intercept and decrypt traffic before forwarding it on to the real internet, all without the victim noticing.

sequenceDiagram
    participant V as Victim Workstation
    participant Atk as Attacker
    participant GW as Real Default Gateway
    participant Net as Internet

    Atk->>V: Spoofed ARP reply: "I am the gateway"
    V->>Atk: Sends traffic believing Atk is the gateway
    Atk->>GW: Forwards (and inspects/decrypts) traffic
    GW->>Net: Delivers traffic normally
    Net-->>V: Victim is unaware of the interception

Rogue DHCP Servers

A rogue DHCP server attack is another way to establish an on-path position: the attacker’s device races to respond to DHCP discovery broadcasts faster than the legitimate DHCP server can. Since a DHCP request is broadcast, any device on the local segment can attempt to answer it. If the rogue server wins the race, it can hand out a lease that designates the attacker’s device as the default gateway, letting the attacker observe all outbound traffic from the victim before it ever reaches the legitimate network path.

sequenceDiagram
    participant V as Victim Workstation
    participant Rogue as Rogue DHCP Server
    participant Real as Legitimate DHCP Server

    V->>V: Broadcast DHCP Discover
    Rogue-->>V: DHCP Offer (wins the race)
    Real-->>V: DHCP Offer (arrives too late)
    V->>Rogue: DHCP Request / Ack
    Note over V,Rogue: Rogue-assigned "default gateway"<br/>now intercepts victim's traffic

Password and Other Attacks

• Brute-force password attacks — repeatedly submitting username/password combinations until one succeeds. Longer, more complex passwords significantly increase the time required, ideally past the point an attacker is willing to invest.
• Rainbow tables / breached-credential databases — large precomputed dictionaries of passwords, or databases of real breached username/password pairs (such as those searchable through Troy Hunt’s Have I Been Pwned service). Interestingly, this same public data can be used defensively — organizations can block users from selecting any password known to already be present in a breached-credential list.
• Virus, malware, and ransomware — a virus is software that may or may not cause damage and may spread to other systems; malware broadly seeks to steal data or manipulate victims; ransomware encrypts an organization’s data with a key known only to the attacker, who demands payment (illegal, but still commonly paid by victim organizations) in exchange for the decryption key.
• DNS poisoning — an attacker injects false DNS records into a resolver’s cache, redirecting a legitimate hostname (e.g., a bank or search engine domain) to a malicious, look-alike destination.
• VLAN hopping — historically, an attempt to jump from one VLAN to another by injecting a crafted frame; modern switches are effectively immune to this technique and it is no longer considered a significant real-world concern.

Module 5: Network Hardening Techniques

Having reviewed common attacks, this module covers the mechanisms available to prevent them, organized by OSI layer.

Securing Layer 2: VLANs and Port Security

Consumer-grade switches used in home networks are typically unmanaged — every port belongs to the same VLAN with no configuration required. Enterprise-class switches, by contrast, ship with every port pre-assigned to a default VLAN (commonly VLAN 1). Hardening recommendations at Layer 2 include:

• Abandon the default VLAN (VLAN 1). Never use VLAN 1 for production traffic — with thousands of other VLAN IDs available, there is no reason to rely on the factory default.
• Disable unused switch ports. Any port without an authorized device connected should be administratively disabled to prevent an attacker from plugging in an unauthorized device. (An attacker could still unplug and replace an active device, but doing so is far more likely to be immediately noticed, and can additionally be defended against with port security.)
• Use private VLANs. A private VLAN isolates each connected device onto its own broadcast domain so that a broadcast from one device is heard only by that device and the default gateway — no other device on the segment hears it. This directly defeats ARP-spoofing-based on-path attacks, since there are effectively only two devices (the host and the gateway) that could ever legitimately exchange ARP traffic on that segment.

Port security lets an administrator bind a switch port to a specific, learned MAC address. If a different device connects to that port, the switch can deny the traffic or shut the port down entirely, requiring administrator intervention — directly countering the “unplug a legitimate device and plug in an attacker’s device” scenario.

flowchart TD
    L2["Layer 2 Hardening"] --> V1["Abandon VLAN 1"]
    L2 --> DP["Disable Unused Ports"]
    L2 --> PV["Private VLANs<br/>(isolate broadcast domains)"]
    L2 --> PS["Port Security<br/>(bind port to known MAC)"]

Demo: Examining Port Security Operation

The demo connects (via a serial console through PuTTY) to a Cisco 2960 switch with port security already configured on interface FastEthernet0/1.

SwitchA# show run int f0/1
interface FastEthernet0/1
 switchport access vlan 10
 switchport mode access
 switchport port-security
 switchport port-security mac-address sticky
 switchport port-security mac-address sticky 0011.2233.41cc
 spanning-tree portfast

Configuration notes:

• The port is assigned to VLAN 10 as an access (untagged) port.
• switchport port-security enables port security on the interface.
• The sticky MAC-address setting means the first MAC address seen on the port is automatically learned and written into the running configuration — in this case, a device with a MAC ending in 41cc.

Observed behavior when the connected device is disconnected and replaced:

1. Disconnecting the authorized device triggers a link-down message:

   %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to down
   %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to down
   

2. Connecting a different network interface card (a different MAC address, 41c9) causes the port to briefly come up, detect the mismatch, and immediately trigger a security violation:

   %PM-4-ERR_DISABLE: psecure-violation error detected on Fa0/1, putting Fa0/1 in err-disable state
   %PORT_SECURITY-2-PSECURE_VIOLATION: Security violation occurred, caused by MAC address 0011.2233.41c9 on port FastEthernet0/1
   

3. Checking interface status confirms the shutdown:

   SwitchA# show int f0/1
   FastEthernet0/1 is down, line protocol is down (err-disabled)
   

4. Even reconnecting the original, correct MAC address does not automatically bring the interface back — an administrator must manually re-enable it:

   SwitchA(config)# interface f0/1
   SwitchA(config-if)# shutdown
   SwitchA(config-if)# no shutdown
   

5. After no shutdown, the interface returns to a normal up/up state:

   SwitchA# show int f0/1
   FastEthernet0/1 is up, line protocol is up (connected)
   

If an unauthorized device is reconnected again, the port immediately flips back to err-disable. This demonstrates how port security renders an attacker’s device effectively useless the moment it is plugged into a protected port, while requiring administrative action to restore legitimate connectivity.

Preventing Rogue DHCP Servers at the Switch

Switches can label each port as trusted or untrusted for DHCP purposes (DHCP snooping). Ports connected to end-user devices (PCs, printers) are labeled untrusted; only the single port that leads toward the legitimate DHCP server is labeled trusted. Any DHCP server message (offer/ack) arriving on an untrusted port is silently discarded, preventing a rogue DHCP server from ever successfully responding to client requests — while the legitimate DHCP server, reachable through the trusted port, continues to respond normally.

ip dhcp snooping
ip dhcp snooping vlan 10
!
interface GigabitEthernet0/1
 description Uplink to legitimate DHCP server
 ip dhcp snooping trust
!
interface range FastEthernet0/2-24
 description End-user access ports
 ! untrusted by default — no additional command required

Dynamic ARP Inspection

Dynamic ARP Inspection (DAI) builds directly on DHCP snooping. As each device receives an IP address from the legitimate DHCP server, the switch records a binding table mapping MAC address, assigned IP address, and switch port. If a device then sends an ARP reply claiming an IP address inconsistent with its recorded binding (for example, claiming to be 10.0.0.1 while actually bound to port 5 as 10.0.0.40), the switch detects the mismatch and drops the ARP reply before it ever reaches the rest of the network — preventing ARP-spoofing-based on-path attacks even outside of a private-VLAN design.

ip dhcp snooping
ip dhcp snooping vlan 10
ip arp inspection vlan 10
!
interface GigabitEthernet0/1
 ip dhcp snooping trust
 ip arp inspection trust

The equivalent protection for IPv6 is IPv6 Router Advertisement (RA) Guard, which similarly maps MAC/IPv6 address/port bindings to prevent an attacker from injecting forged router advertisements that could otherwise redirect or compromise IPv6 traffic on the segment.

flowchart TD
    DHCP["DHCP Snooping<br/>(builds MAC/IP/Port binding table)"] --> DAI["Dynamic ARP Inspection<br/>(validates ARP replies against binding table)"]
    DHCP --> RAGuard["IPv6 RA Guard<br/>(validates router advertisements)"]
    DAI --> Drop["Spoofed ARP replies dropped"]
    RAGuard --> Drop2["Forged router advertisements dropped"]

Securing Layer 3 and Layer 4 with ACLs

Access control lists (ACLs) on routers and firewalls define what traffic is permitted or denied.

A simple standard ACL, matching only source address:

access-list 10 permit host 10.0.0.10
! Implicit "deny any" applies to everything else

Any traffic from 10.0.0.10 is permitted; traffic from any other source (e.g., 10.0.0.20) is denied by the implicit deny any that exists at the end of every ACL by default. Administrators may also write an explicit deny any statement — functionally identical in behavior, but useful for clarity when reviewing the configuration:

access-list 10 permit host 10.0.0.10
access-list 10 deny any

A more sophisticated extended ACL, commonly used on firewalls, can match source, destination, and Layer 4 port:

access-list 101 permit tcp any host 192.168.10.10 eq 443
access-list 101 deny ip any any

This permits any source device to reach 192.168.10.10 only over HTTPS (port 443); a request to the same server on port 80 would be rejected at the firewall.

For DDoS-style volumetric attacks, Control Plane Policing (CoPP) — a quality-of-service mechanism available on routers, Layer 3 switches, and firewalls — can watch control-plane traffic for abnormal spikes (for example, a sudden surge in DNS traffic) and throttle or deny that traffic category until legitimate and malicious traffic can be distinguished.

flowchart TD
    Pkt["Incoming Packet"] --> ACLCheck{"Matches a permit<br/>statement?"}
    ACLCheck -->|Yes| Allow["Forward Packet"]
    ACLCheck -->|No| Deny["Implicit/Explicit Deny"]

Securing Layer 7 and Above

SNMP security varies significantly by protocol version:

Firmware and OS updates. Network hardware (routers, switches, load balancers) and endpoint operating systems should be kept up to date to close known vulnerabilities. Firmware updates should be tested before wide deployment, since a firmware change can alter device behavior and potentially break dependent applications — while still avoiding staying on outdated, vulnerable releases indefinitely.

Password security. Default credentials (frequently admin/password or similar, easily discoverable via a web search) must always be changed. Passwords should follow a documented complexity/length standard (see NIST password guidance) that balances security with memorability.

Demo: Examining Netstat

netstat reveals which services are actively listening or connected on a local Windows workstation — complementary to using Nmap to scan a remote host.

netstat -a -n -o

• -a — show all connections and listening ports.
• -n — display addresses and port numbers numerically (skip DNS/service-name resolution).
• -o — display the owning process ID (PID) for each connection.

Example workflow from the demo:

1. Run netstat -a -n -o and observe a long list of TCP and UDP entries — for example, a listener on port 1537 associated with PID 1300.
2. Open Task Manager (Ctrl+Shift+Esc) → Details/Services tab, sort by PID, and locate PID 1300 — in the demo, this maps to the EventLog service.
3. Attempting to stop that service directly is blocked because other services depend on it, illustrating that some listening services are core OS components rather than something to be casually disabled.
4. Additional entries include sessions in CLOSE_WAIT (a browser session not yet fully torn down after the browser closed), IPv6 sessions (identifiable by the :: double-colon notation), and a UDP listener on port 500 (commonly associated with a VPN service, e.g., IKE for IPSec).

The overall goal of this exercise is to inventory every listening service on a workstation and confirm each one is expected, disabling anything that shouldn’t be running.

Module 6: Wireless Security

Wireless Encryption Standards

Wireless traffic that is not encrypted at Layer 2 (via WPA2/WPA3) is fully readable by anyone within radio range, even without actually joining the network — regardless of whether an application-layer protocol like HTTPS, SSH, or a VPN is also in use for a given session. Encrypting the Layer 2 wireless link itself is essential to prevent passive sniffing of everything exchanged between a client and its access point.

Encryption requires an authentication mechanism so that both the client and the access point can derive shared keys without exposing them:

Enterprise-scale networks strongly favor username/password or certificate-based authentication over a shared PSK: in an organization with 10,000 employees, a single pre-shared key would have to be rotated across every device whenever any employee left the company. With PEAP or EAP-TLS, disabling one user account or one device certificate is sufficient.

MAC filtering — restricting which MAC addresses may join a wireless network — is a weak, supplementary control at best, since MAC addresses are easily observed on the air and easily spoofed by an attacking device.

flowchart LR
    WEP["WEP<br/>(broken)"] --> WPA["WPA<br/>(weak)"] --> WPA2["WPA2<br/>(strong, widely deployed)"] --> WPA3["WPA3<br/>(strongest)"]

sequenceDiagram
    participant Client
    participant AP as Access Point / Controller
    participant AAA as RADIUS / TACACS+
    participant DS as Directory Service (e.g., AD)

    Client->>AP: Associate (PEAP / EAP-TLS)
    AP->>AAA: Forward credentials or certificate
    AAA->>DS: Validate identity
    DS-->>AAA: Authorized
    AAA-->>AP: Access granted
    AP-->>Client: Encrypted session established (WPA2/WPA3)

Demo: Wireless Security Options on a Controller

The demo walks through creating a new wireless network on a home/small-business wireless controller (a Ubiquiti-style controller with associated access points):

1. Create a new SSID and set a passphrase.
2. Configure the wireless band (2.4 GHz or 5 GHz) and related radio options.
3. Review the available security modes:
   • WPA-2
   • WPA-2/WPA-3 (mixed mode)
   • WPA-2 Enterprise
   • WPA-3 Enterprise
4. Selecting an “Enterprise” mode reveals fields for a RADIUS server address and shared secret, used to integrate with an organization’s AAA/directory infrastructure.
5. Additional options include hiding the SSID broadcast and enabling Protected Management Frames.
6. MAC authorization can optionally be configured with either an allow-list or a deny-list of specific MAC addresses.

Geofencing

Geofencing aims to contain the physical footprint of a wireless signal to the intended coverage area (inside a building, or an explicitly authorized outdoor space) rather than letting the signal propagate far beyond the property line, where an unauthorized user — for example, someone “war driving” outside the building — could attempt to connect.

Access points placed at the center of a building provide strong central coverage but weaker coverage at the edges (further reduced by walls and other obstructions). Placing access points near the building’s perimeter improves internal edge coverage but tends to radiate a strong signal well outside the building. Modern wireless controllers can mitigate this using RF shaping techniques that intentionally cancel or shape the radiated signal so that the effective range is contained closer to the building’s actual footprint — meaning a person standing just outside the building may see little or no usable signal for the organization’s internal SSIDs.

flowchart TD
    Center["AP at Building Center"] -->|Weak edge coverage| Problem1["Poor coverage near<br/>building perimeter"]
    Edge["AP at Building Edge"] -->|Strong signal| Problem2["Signal leaks well<br/>beyond property line"]
    Geofencing["Geofencing / RF Shaping"] -->|Contains footprint| Solution["Coverage matches<br/>authorized area only"]

Other Wireless Security Considerations

• Client isolation — mirrors the private-VLAN concept from wired networks: each wireless client can only communicate with the access point, not with other clients on the same SSID. This is especially valuable for IoT devices, which frequently run opaque firmware and may harbor undetected malware; isolating them (or placing them on their own dedicated SSID) limits their ability to attack other devices even if compromised.
• Guest SSIDs — a separate wireless network for visitors (or, in a corporate setting, non-employees) that is firewalled to permit internet access only, with no path to internal corporate resources — important both at home and in regulated environments like banking, where a visitor’s laptop must never have a path to sensitive internal systems.
• Captive portals — a web-based login/consent page shown before granting network access, commonly used in hotels and healthcare facilities, avoiding the need to distribute a pre-shared key while still gating initial access.

flowchart TD
    WirelessSec["Additional Wireless Controls"] --> CI["Client Isolation<br/>(clients cannot see each other)"]
    WirelessSec --> Guest["Guest SSID<br/>(internet-only, firewalled from internal network)"]
    WirelessSec --> Captive["Captive Portal<br/>(web-based access gate)"]

Module 7: Remote Access and Security

Remote access into corporate networks became critical infrastructure during the shift to widespread remote work, and remains an essential capability today.

Remote Access Overview

A remote user — whether an IT administrator, help desk staff, an application support specialist, or simply a business user — typically needs access to internal applications, databases, cloud services, virtual desktops, or (for network engineers specifically) a dedicated administrator workstation restricted to a small, specifically authorized set of IP addresses used to configure routers, switches, firewalls, and load balancers. The firewall/VPN gateway is the boundary that decides which remote users are allowed through, and which are blocked.

Key remote access technology categories:

Secure Shell (SSH)

SSH provides encrypted command-line interface access to network and server infrastructure. In many organizations, administrative SSH access is restricted to specific, pre-approved source subnets (such as a dedicated administrator workstation subnet), reducing the risk that a compromised general-purpose workstation could be used to reconfigure critical infrastructure.

Demo: Examining SSH

The demo uses PuTTY (a widely used, freely downloadable terminal client supporting Telnet, SSH, and serial connections) to connect to a switch:

1. Enter the target device’s IP address (10.128.50.254), set the port to 22, and select the SSH connection type.
2. Authenticate with a username and password.
3. Enter privileged EXEC mode (re-entering the password when prompted).
4. From this point, the device can be fully configured remotely exactly as if a local serial console cable were connected — SSH is supported on routers, switches, Linux servers, some Windows servers, and many firewalls.

# Example PuTTY-equivalent OpenSSH command line:
ssh ross@10.128.50.254 -p 22

Virtual Private Networks

SSL (Secure Sockets Layer) and TLS (Transport Layer Security) are, for practical purposes, the same protocol family — the “TLS” name was adopted after 1999 following a dispute between Microsoft and Netscape over naming, and the terms are frequently used interchangeably today.

In a site-to-site VPN, traffic originating on one site’s internal subnet (e.g., 192.168.0.0/24) can reach the other site’s subnet (e.g., 172.20.0.0/24) as though the two subnets were on the same local switch — the VPN device precisely routes and encrypts traffic over the tunnel, invisible to end users.

In a client/remote-access VPN, software on the remote device establishes an encrypted tunnel to the firewall/VPN gateway, after which the remote device behaves as if it were physically located inside the corporate network. As always, least privilege should still apply — a compromised remote device connected over VPN should only be able to reach the specific resources that user actually needs, limiting the blast radius of any compromise.

flowchart LR
    subgraph SiteA["Site A (e.g., Chicago) — 192.168.0.0/24"]
        RouterA["Router/Firewall A"]
    end
    subgraph SiteB["Site B (e.g., New York) — 172.20.0.0/24"]
        RouterB["Router/Firewall B"]
    end
    RouterA <-->|IPSec Tunnel over the Internet| RouterB

flowchart LR
    Remote["Remote User Device"] -->|Client software: IPSec or SSL/TLS| GW["Firewall / VPN Gateway"]
    GW --> Internal["Internal Corporate Network"]

Split Tunnel vs. Full Tunnel VPNs

Once a client VPN tunnel is established, administrators must decide how the remote user’s internet-bound traffic (e.g., browsing a public website) is handled:

One historical, particularly strict implementation: configuring devices so that no traffic would flow at all unless a VPN tunnel to the corporate network was automatically established immediately after login — a technique used to prevent both the installation of unapproved software and casual personal use of a company device.

flowchart TD
    Client["Remote Client"] -->|Split Tunnel| Choice{"Traffic destination?"}
    Choice -->|Corporate resource| Tunnel1["Via VPN Tunnel"]
    Choice -->|General internet| Direct["Directly to Internet<br/>(not inspected)"]

    Client2["Remote Client"] -->|Full Tunnel| GW2["Firewall / VPN Gateway"]
    GW2 --> Corp["Corporate Resources"]
    GW2 --> Inet["General Internet<br/>(inspected/filtered)"]

Remote Desktop Connections

RDP (Remote Desktop Protocol) is Microsoft’s remote-desktop implementation; VNC (Virtual Network Computing) is a functionally equivalent open-source alternative. Both let a remote user see and control a target machine’s desktop (mouse, keyboard, screen) as though sitting directly in front of it — commonly used by administrators to reach a restricted administrator workstation, or to reach a server’s management console.

Demo: Remote Desktop Connection

1. On the source Windows 10 machine, open the Remote Desktop Connection app and enter the target device’s IP address (10.128.50.135).
2. Authenticate with the remote device’s username and password (subsequent connections may only prompt for the password).
3. Once connected, the session displays the remote device’s desktop; running ipconfig locally on the client machine (in this example showing 10.128.50.193) confirms the two machines are distinct.
4. The remote session can be switched to full screen so it behaves like a local desktop; video or fast-motion graphics may show minor lag, but general productivity/administrative work is unaffected.
5. To enable Remote Desktop on a Windows machine so it can receive connections: search for Remote Desktop settings, and toggle the setting on (disabled by default). Reaching the machine from outside the local network additionally requires appropriate firewall configuration.

Virtual Desktops and Remote Desktop Gateways

A Remote Desktop Gateway can allow RDP-style access without requiring a full VPN client — for example, exposing the gateway over HTTPS through a screened subnet/DMZ. Once authenticated to the gateway, the user can reach an administrator workstation or server. Centralizing remote desktop access through a gateway also makes it easier to apply consistent policy and centralized logging/monitoring of who is connecting and when.

A virtual desktop goes a step further by providing an entirely virtualized computer — provisioned on demand with the required software, drive mappings, and files — rather than remote-controlling one specific physical machine. Benefits include:

• Fresh virtual machines can be spun up per session and torn down afterward, returning compute/memory resources to the pool for other users.
• Constant virus scanning and consistently up-to-date software, since the virtual machine image is rebuilt/refreshed regularly.
• A strong isolation boundary between the user’s personal (potentially insecure) physical device and the corporate virtual machine — even if the physical device has unrelated malware or unmanaged software installed, that risk does not transfer into the virtual desktop session.

This model has become popular even for on-premises use, not solely for remote access scenarios.

flowchart LR
    RemoteUser["Remote User Device<br/>(potentially unmanaged)"] -->|RDP/VNC over HTTPS or VPN| Gateway["Remote Desktop Gateway"]
    Gateway --> VDI["Ephemeral Virtual Desktop<br/>(fresh image, current patches)"]
    VDI -.->|Torn down after session| Pool["Resource Pool"]

Network Management: In-Band vs. Out-of-Band

In-band management configures and monitors devices over the same production network that carries normal traffic (e.g., SSH over the live network). This works well until the network itself experiences an outage — sometimes humorously described as “cutting your arm off,” since an accidental configuration change can take down the very path used to reach and fix the device.

Out-of-band management provides an alternate path that does not depend on the primary network being operational:

• A dedicated AUX port (common on Cisco and other vendor equipment) connected via a serial cable to a dial-up modem, reachable over the PSTN (Public Switched Telephone Network) — a legacy but still occasionally used approach.
• A separate internet connection (e.g., a dedicated cable modem and small firewall) with its own VPN path directly to devices, independent of the primary corporate network path.

Out-of-band access becomes essential for organizations with geographically distributed infrastructure, where physically traveling to a remote site to fix an outage is impractical.

flowchart TD
    Admin["Administrator"] -->|Primary Network (SSH)| InBand["In-Band Management"]
    Admin -->|AUX + Modem over PSTN, or dedicated OOB link| OutOfBand["Out-of-Band Management"]
    InBand -->|Fails if primary network is down| Device["Network Device"]
    OutOfBand -->|Independent of primary network| Device

Module 8: Physical Security

Human beings represent a significant security risk, and continuous training on policy and procedure is essential — but technical, physical security controls remain a necessary complement to that training.

Video Surveillance

Camera coverage with centralized recording supports after-the-fact investigation (“who did what, when”). Cameras are commonly placed at facility entrances, check-in vestibules, and especially sensitive areas such as data centers (less commonly in switch closets, though this does occur). Motion sensors inside a data center can trigger lighting and camera activation and alert administrators in real time when someone enters the space, supporting a determination of whether that access is authorized.

Asset Tracking and Disposal

Every network device — PCs, switches, routers, firewalls, servers, and racks — is considered an asset that should be tracked: where it is located, when it was purchased, and when it is scheduled for retirement. Organizations commonly apply physical asset tags that can be scanned to pull up this information from a database.

Tamper-detection mechanisms help indicate whether a device has been physically opened or altered without authorization:

• “Void if removed” tamper-evident stickers (often with a hologram/diffraction pattern) that visibly destruct when peeled.
• Simple mechanical tamper seals (similar in concept to those used on utility meters) that are easy to break but hard to reassemble undetected.
• Similar principles are used in consumer electronics — for example, internal water-exposure indicators used to determine whether device damage is covered under warranty.

Secure disposal ensures that data is fully wiped or physically destroyed at end of life — for example, using a high-powered degausser to disable magnetic hard drives, or a certified shredding service that physically destroys drives collected in locked containers.

Facility Access Controls

Facilities housing critical infrastructure (data centers, switch closets) should limit access as tightly as practical:

• Secure access vestibules (“mantraps”) — an intermediate secured space (sometimes staffed by a guard, sometimes with a sign-in log) that must be passed through — typically requiring a code or badge both to enter the vestibule and again to enter the actual data center — directly countering tailgating/piggybacking by requiring two independent secured transitions.
• Access credentials — ID badges/card readers, key fobs, or biometric methods (fingerprint, retinal scan, handprint) used to gate entry and log who accessed the space and when. Physical badges/fobs share a common weakness: if lost, they can potentially be used by whoever finds them, which is a key argument for supplementing or replacing them with biometric verification in higher-security environments.

flowchart LR
    Entrance(["Facility Entrance"]) --> Vestibule["Secure Access Vestibule<br/>(code/badge + optional guard + sign-in log)"]
    Vestibule --> DataCenter["Data Center<br/>(code/badge again)"]
    DataCenter --> Racks["Server Racks / Switch Closets"]

Summary

Network security rests on a small number of durable principles that recur throughout every layer of the infrastructure stack:

• CIA (Confidentiality, Integrity, Availability) is the foundational goal of every security control — every technique in this course ultimately protects one or more of these three properties.
• Threats, vulnerabilities, and exploits are distinct concepts: a threat is a potential circumstance or event, a vulnerability is a weakness, and an exploit is the mechanism that actually takes advantage of that weakness. CVE (cve.org) catalogs known vulnerabilities; zero-day vulnerabilities are, by definition, not yet publicly known.
• Zero trust, least privilege, role-based access, and defense in depth should govern how users, devices, and automated processes are granted access — trust nothing by default, grant only what is required, and layer multiple independent controls rather than relying on any single one.
• AAA (Authentication, Authorization, Accounting) underlies virtually every access-control system, whether implemented via TACACS+, RADIUS, Kerberos/LDAP, or 802.1X/EAP.
• Multifactor authentication meaningfully raises the bar against credential-based attacks by combining something you know with something you have, something you are, somewhere you are, or something you do.
• Security assessments — threat, vulnerability, posture, and penetration testing, supplemented by business risk assessments and SIEM correlation — provide the ongoing visibility needed to find and close gaps before attackers do.
• Common attacks (phishing/social engineering, DoS/DDoS, Wi-Fi attacks, on-path/ARP-spoofing, rogue DHCP, password attacks, ransomware, DNS poisoning) each have well-understood mechanisms and correspondingly well-understood mitigations.
• Hardening techniques exist at every layer: VLANs/private VLANs/port security at Layer 2; DHCP snooping and Dynamic ARP Inspection to stop rogue DHCP and ARP spoofing; ACLs and control-plane policing at Layer 3/4; and secure SNMP, current firmware/OS patch levels, and strong non-default passwords at Layer 7 and above.
• Wireless security depends on strong encryption (WPA2/WPA3), strong authentication (PEAP or EAP-TLS/PEAP-TLS over a shared PSK in enterprise settings), geofencing to contain signal footprint, and supplementary controls like client isolation, guest SSIDs, and captive portals.
• Remote access technologies — SSH, site-to-site and client VPNs (full tunnel vs. split tunnel), RDP/VNC, virtual desktops, and in-band vs. out-of-band management — extend secure access to users and administrators outside the physical network, provided least privilege is still enforced over what a remote session can reach.
• Physical security — video surveillance, asset tracking/tamper detection/secure disposal, and layered facility access controls (vestibules, badges, biometrics) — protects the hardware layer that every other control ultimately depends on.

Quick-Reference Table

Study Checklist

• Explain the CIA triad and give a real-world example of each property being violated.
• Distinguish between a threat, a vulnerability, and an exploit, and explain what a zero-day vulnerability is.
• Describe the four pillars of a zero-trust model.
• Explain AAA and name at least one protocol/service associated with each of the three components.
• List the five categories of multifactor authentication factors with an example of each.
• Compare threat, vulnerability, posture, and penetration-testing assessments.
• Describe how a reflective DDoS attack and an amplification DDoS attack differ.
• Explain how ARP spoofing enables an on-path (man-in-the-middle) attack, and how DHCP snooping/Dynamic ARP Inspection prevents it.
• Compare WEP, WPA, WPA2, and WPA3, and compare PSK, PEAP, and EAP-TLS/PEAP-TLS authentication.
• Explain the difference between a split-tunnel and a full-tunnel VPN, and when each is appropriate.
• Compare in-band and out-of-band network management, and describe at least one out-of-band access method.
• List at least three physical security controls used to protect a data center or network closet.

Search Terms

network · security · cybersecurity · fundamentals · networking · systems · attacks · remote · access · authentication · wireless · desktop · examining · exploits · layer · securing · assessments · business · dhcp · management · port · risk · rogue · servers