Skip to main content

4.5 From the Inside Out: Monitoring and Defending a Large Network

add to ChatGPT
Verified for the 2027 examUpdated November 2026Fiveable Content Team
Fiveable

🌐AP Networking Unit 4 Review

QR code for AP Networking practice questions

4.5 From the Inside Out: Monitoring and Defending a Large Network

🌐 AP Networking

    continue practicing 4.5

    Multiple choice

    Big networks have a lot more going on than just "a bunch of computers connected together." You've got users clicking things they shouldn't, people trying to sneak into server rooms, malware hopping from device to device, and tons of traffic that needs to be watched. This topic is all about spotting those problems, stopping them, and designing the network so damage stays contained when something does slip through.

    Threats and Weaknesses in a Managed Network

    Even the most expensive network gear can't save you from the people using it. Most incidents start small and snowball from there, so it helps to group the threats by where they come from.

    User-Caused Problems

    Users mess things up in two ways: by accident or on purpose. Either way, the outcomes look similar: unauthorized access, exposed data, or interrupted services.

    Think about what happens when someone:

    • Opens a folder they weren't supposed to see (reaching resources beyond their role)
    • Emails a sensitive spreadsheet to a personal account (handling data improperly)
    • Reuses a weak password across every system (skipping secure procedures)

    Any of these can leak data or let an attacker in. And it doesn't matter if the user meant to cause harm. The damage is the same.

    Physical Security Breaches

    If an unauthorized person actually walks into a secure area, the game basically changes. Now they can:

    • Plug directly into network devices
    • Steal a laptop or even a whole server
    • Tamper with equipment (installing a rogue device, for instance)

    Attackers use some pretty low-tech tricks to pull this off:

    • Tailgating: following an employee through a locked door without swiping a badge
    • Piggybacking: the employee knowingly holds the door open for them (often after being tricked)
    • Theft of servers, laptops, or hard drives

    These tactics skip right past your fancy firewall because they attack the building, not the network.

    Lateral Movement

    Here's where things get really ugly. Once an attacker or piece of malware gets a foothold on one device, they often try to spread sideways to other machines. This is called lateral movement, and the result can be:

    • Widespread data compromise
    • Service outages
    • Loss of administrative control (the attacker ends up with admin rights)

    Lateral movement is more likely in large or segmented networks that don't have strong containment, internal monitoring, or access boundaries between zones. A flat network with no internal walls lets an intruder stroll from HR's printer to the finance server with nothing stopping them.

    Choosing the Right Security Controls

    No single control fixes everything. Good security uses a combination of policies, physical protections, and technical controls layered together. When picking controls, administrators weigh two things: how likely a threat is and how bad it would be if it happened. Controls should also be cost-effective, scalable, and actually fit the environment (a small office doesn't need a military-grade vault).

    Policies That Shape User Behavior

    Policies target user-related vulnerabilities by telling people what they're allowed to do.

    • Acceptable use policies (AUPs): spell out what you can and can't do with company resources (no torrenting on the work network, no plugging in random USB drives, etc.)
    • Password and access control policies: require strong authentication (long passwords, MFA) and define permission levels
    • Data handling guidelines: cover how sensitive data is stored, transmitted, and deleted

    These policies cut down on misconfiguration, mishandling, and improper access by making expectations consistent.

    Physical Controls

    Physical controls stop people from getting direct access to network gear.

    • On-site security guards, cameras, and fencing to discourage anyone from even trying
    • Access control vestibules (a small room with two locked doors, where the second won't open until the first closes) and card readers to control who gets in
    • Secure rooms and locked server cabinets so devices stay physically protected
    • Cable locks on desktops and laptops so they can't be grabbed and carried off
    • Social engineering training so staff recognize tailgating attempts and fake "IT technicians"

    Controls Against Unauthorized Access

    These are the technical controls that limit who can reach what inside the network:

    • Strong password policies plus account lockout: force complex passwords and lock the account after too many failed tries
    • Principle of least privilege: give every user and process the minimum permissions they need to do their job, nothing more
    • Segmentation: split the network into zones so devices in one group can't freely reach another (this directly limits lateral movement)
    • Firewalls: block unauthorized traffic from reaching protected systems
    • Network monitoring: watch traffic for suspicious activity and raise alerts when something looks off

    When you combine these, a compromised intern laptop can't just reach the payroll database, and a stolen password alone won't get an attacker everywhere.

    Reading IDS and IPS Logs

    Intrusion detection systems (IDS) and intrusion prevention systems (IPS) watch network traffic for signs of trouble. The key difference:

    • An IDS watches traffic and raises an alert when it sees a threat. It tells you something bad is happening.
    • An IPS inspects traffic and can immediately block or stop suspicious traffic. It acts on what it sees.

    Checking these logs on a regular schedule matters because catching weird activity early means you can respond before real damage happens. Regular log review also helps you fine-tune your rules so you get fewer false alerts over time.

    Signs of a Possible Security Threat

    When scanning logs, these are red flags that someone might be trying to break in or already has:

    • Repeated failed login attempts (classic sign of a brute-force attack)
    • Access attempts outside of business hours (why is someone logging into the finance server at 3 a.m. on a Sunday?)
    • Connections to known malicious IP addresses (your system is talking to something on a threat intelligence blocklist)
    • Alerts about malware signatures or suspicious files (the IDS/IPS recognized a known piece of malware)
    • Unauthorized network scans (someone is probing your network to map it out)

    These aren't the only signs, but they're the common ones you should be able to recognize.

    Signs of Performance or Configuration Problems

    Not every weird log entry means an attacker. Logs also catch technical issues that affect reliability and availability:

    • Sudden spikes in traffic volume or packet rates (could be a legitimate surge, could be a misbehaving app)
    • Frequent dropped packets or timeout errors (something is choking)
    • Protocols being misused or services behaving unexpectedly (a device is sending traffic in a way it shouldn't)
    • Repeated failed connections or service interruptions (something keeps breaking)

    These problems might not have anything to do with a bad actor. A misconfigured router, a failing cable, or a buggy update can all show up in logs the same way an attack might, which is why you have to investigate before panicking.

    Setting Up a VLAN

    A VLAN (virtual local area network) is a way to logically split one physical network into separate isolated groups. Devices in different VLANs can't talk to each other unless routing between them is configured. That isolation does three big things:

    • Boosts security by keeping sensitive systems away from general users
    • Reduces broadcast traffic (broadcasts stay inside their VLAN)
    • Eases congestion overall

    You can group devices however makes sense: by department, by user role, or by device type.

    Step 1: Plan Your Segmentation

    Before touching any switch, decide how you're going to split things up. Sort users or devices by function or security level. A classic home example might look like:

    • VLAN 10 (ports 1-2): work computers and printers
    • VLAN 20 (ports 3-4): IoT devices like smart TVs, cameras, thermostats
    • VLAN 30 (ports 5-6): entertainment gear like a media server and game consoles
    • VLAN 40 (ports 7-10): personal phones, tablets, and laptops

    The IoT stuff is now isolated from your work computers, so if a cheap smart bulb gets hacked, it can't reach your laptop.

    Step 2: Create the VLAN and Give It an ID

    Every VLAN needs a unique VLAN ID (a number). You can also give it a name so it's easy to identify later. On a Cisco switch, basic creation looks like this:

    </>Code
    Switch(config)# vlan 10
    Switch(config-vlan)# name Work_Devices
    Switch(config-vlan)# exit

    Step 3: Assign Switch Ports

    A device joins a VLAN by being plugged into a switch port configured for that VLAN ID. Any device plugged into that port automatically becomes part of the VLAN.

    Each port is set up as one of two types:

    • Access port: connects a single device to one single VLAN (a laptop, a printer, a camera)
    • Trunk port: carries traffic for multiple VLANs between switches or to a router (this is how VLAN 10 traffic and VLAN 20 traffic can share the cable running between two switches)

    Assigning a port to VLAN 10 on Cisco looks like:

    </>Code
    Switch(config)# interface fastEthernet 0/1
    Switch(config-if)# switchport mode access
    Switch(config-if)# switchport access vlan 10

    You can do all of this through the command line (CLI) or a web-based GUI, depending on the switch.

    Step 4: Verify It Works

    Once everything is set, confirm it actually works:

    • Use show vlan brief to see that the VLANs exist and the right ports are mapped to each one
    • Use ping to test that two devices in the same VLAN can reach each other
    • Use traceroute to see the path packets take, especially if routing between VLANs is set up

    Devices in the same VLAN should communicate normally. Devices in different VLANs should not reach each other unless you've configured routing between them. If a ping succeeds when it shouldn't, your segmentation isn't actually isolating anything, and you've got a config issue to track down.

    See Fiveable more often in Google

    Mark Fiveable as a preferred source and Google is more likely to show you our guides in Top Stories, with a "preferred" badge in AI Mode and AI Overviews.

    Prefer us on Google