AV-02 · Exposed services and remote access weaknesses

VPNs, firewalls, admin panels, RDP, SSH, and internet-facing applications are repeatedly targeted when patching, hardening, or access controls are weak.

$ action: Maintain an inventory of exposed services, patch aggressively, and restrict administrative access paths.

1. Why Internet-Facing Exposure Is High Risk

Internet-facing systems are continuously scanned and tested. Attackers do not need to know your organization personally to find exposed services, admin interfaces, or remote access paths. Exposure itself creates opportunity.

This category includes VPN portals, firewalls and network appliances, SSH/RDP endpoints, admin panels, remote management platforms, and web applications that are reachable from the public Internet.

Risk increases quickly when exposure is combined with weak patching, poor hardening, broad administrative access, or incomplete inventory. You cannot defend what you do not know is exposed.

2. What Good Defenders Do First

Build and maintain an exposure inventory. Track every internet-facing service, host, hostname, IP, owner, business purpose, and authentication method. Include temporary exceptions and maintenance systems, not just production applications.

Validate exposure regularly with direct testing and logs. Use discovery tools and compare results over time so you notice new ports, new services, and changed banners quickly.

Reduce administrative exposure wherever possible. Separate admin access paths from general internet exposure and require stronger authentication and network restrictions for management interfaces.

3. Hardening and Response Priorities

Patch internet-facing systems aggressively, especially known exploited vulnerabilities and remote access software. Public exposure should be part of your highest-priority remediation queue.

Restrict access with allowlists, VPN segmentation, conditional access, jump hosts, and role-based admin workflows where practical. The goal is to make remote access both secure and auditable.

Monitor authentication attempts, scan behavior, and unusual traffic patterns against exposed services. A strong monitoring baseline helps you distinguish expected internet noise from a focused attack sequence.

detection-signals

$Unexpected new ports/services on internet-facing hosts compared to prior scans.
$Authentication failures or brute-force patterns against VPN, SSH, RDP, or admin panels.
$Unusual request paths, exploit probes, or malformed requests targeting exposed web apps/appliances.
$New management interfaces reachable from the internet after a change window.
$Traffic spikes or repeated scans focused on one externally reachable service.

telemetry-sources

$Nmap/Ndiff scan outputs for exposure drift and service changes.
$Firewall, VPN, reverse proxy, and load balancer logs for external access attempts.
$Web server / application logs for exploit probes and admin panel access.
$IDS/IPS (Suricata/Snort) alerts on internet-facing segments.
$Asset inventory/CMDB and change records to validate expected exposure.

recommended-tools-and-guides

open Nmap Discover and validate exposed services safely, with repeatable audit workflows. open Ndiff Compare previous and current scan results to detect unexpected exposure changes. open Nikto Quick first-pass web server validation for common exposures and misconfigurations. open Suricata Monitor and alert on suspicious traffic hitting exposed services. open tcpdump Capture packet evidence from an affected host or sensor during troubleshooting/attack triage.

lab-safe-detection-workflows

These commands are for learning, validation, and defensive triage in your own lab or authorized environment. Adapt to your tooling and log locations.

Exposure validation and drift check (authorized)

nmap -sV -Pn -p 22,80,443,3389 203.0.113.10
nmap -sS -T2 -oX scans/external-scan.xml 203.0.113.10
ndiff scans/previous.xml scans/external-scan.xml || true

$ why: Confirm what is exposed now and compare with prior known-good scans to identify unintended changes.

Internet-facing service triage (logs + packet sample)

grep -Ei "401|403|/admin|/login" /var/log/nginx/access.log | tail -n 80 || true
journalctl --since "-1h" | grep -Ei "vpn|ssh|rdp|auth" | tail -n 80
sudo tcpdump -ni any -c 200 host 203.0.113.10 and \(tcp port 443 or tcp port 22\)

$ why: Correlate logs and packets to distinguish expected internet noise from focused attempts against exposed services.

triage-questions

?Is this exposed service expected, documented, and owned by a team?
?Did the service become reachable due to a recent change or drift from baseline?
?Are management/admin interfaces exposed more broadly than intended?
?Which auth controls and monitoring alerts protect this access path?
?What is the immediate containment step if the exposure is unintended (ACL, firewall rule, reverse proxy, disable service)?

defender-actions.checklist

$Maintain a current inventory of all exposed services and owners.
$Prioritize KEV and remote access software patching for internet-facing systems.
$Restrict admin interfaces to approved access paths and stronger auth controls.
$Compare exposure scans regularly to detect drift and unintended changes.
$Alert on unusual auth attempts and focused scanning against exposed systems.

study-workflow

Learn what normal behavior looks like for this area (auth, exposure, config, or internal traffic).
Identify the logs and telemetry that should show the behavior.
Practice one safe validation in a lab or authorized environment.
Write a short playbook for detection, triage, and response.
Review the related tool guides under /learning/tools.

<- previous threat AV-01 · Phishing and credential theft -> next threat AV-03 · Vulnerability exploitation and misconfiguration abuse