Location Research Breakthrough Possible @S-Logix pro@slogix.in

Office Address

Social List

Tracking Port Scanning Attacks Against Linux Servers Through Network Traffic Monitoring and Automated Security Alerting

Description

Organizations operate Linux servers that expose network services such as SSH, HTTP, HTTPS, DNS, databases, and internal application services. Attackers commonly perform Port Scanning Attacks during reconnaissance to identify reachable services and determine which network ports are open.

A port scan may generate a large number of connection attempts against different ports within a short period. If this activity is not monitored, reconnaissance can occur without generating sufficient visibility for the Security Operations Center.

In this use case, an enterprise-like Ubuntu Linux server is deployed inside an isolated laboratory using VirtualBox. The server contains controlled services representing a typical Linux application environment. Kali Linux is used as the authorized security-testing system.

A controlled port-scanning scenario is generated against the Ubuntu server using Nmap. The objective is to determine whether the SOC can identify the abnormal pattern of repeated connection attempts across multiple ports.

Zeek is used as the network-security monitoring component to collect connection telemetry. Wazuh collects and analyzes the relevant security events and generates alerts when the configured port-scanning detection condition is satisfied.

OpenSearch is used as the centralized SOC investigation platform to visualize connection activity, identify the scanning source, reconstruct the reconnaissance timeline, and support incident investigation.

When the scanning behavior is detected, the configured response mechanism can temporarily restrict the laboratory source.

The complete SOC workflow is: Linux Server → Network Traffic → Multiple Port Connection Attempts → Zeek Telemetry → Wazuh Detection → Security Alert → SOC Investigation → Source Attribution → Automated Response → Containment → Validation

Existing Security Problem

Application: Linux Network Services

The Ubuntu server hosts controlled network services that represent services commonly found on enterprise Linux systems.

Existing Problem:

An attacker may scan a Linux server to determine which ports are reachable and which services may be available. A single connection attempt is not necessarily suspicious because legitimate clients may connect to individual services. However, repeated connection attempts against many different ports from the same source within a short period can indicate reconnaissance activity.

The security problem is therefore:

External Source → Linux Server → Multiple Port Connection Attempts → Open / Closed Port Responses → Network Reconnaissance → Service Discovery → Potential Attack Preparation

Attack

Specific Attack: Port Scanning Attack

The controlled attack scenario simulates a port-scanning attack against the authorized Ubuntu Linux server. Kali Linux performs a controlled Nmap scan against only the laboratory target. The scan generates multiple connection attempts across a defined range of ports. The objective is to determine whether the SOC monitoring environment can distinguish normal network connections from reconnaissance behavior.

Attack Behavior:
Kali Linux Test System
→
Nmap Port Scan
→
Multiple Port Connection Attempts
→
Ubuntu Linux Server
→
Zeek Network Telemetry
→
Wazuh Event Analysis
→
Port-Scan Detection
→
Security Alert
→
SOC Investigation
→
Automated Response
→
Source Restriction

Security Concept

SOC-Based Network Reconnaissance Detection:

The primary security concept is SOC-based network reconnaissance detection.

The objective is to continuously monitor network connections and identify abnormal patterns associated with port-scanning activity.

The secure processing flow is:

Network Traffic
→
Connection Monitoring
→
Event Collection
→
Source / Destination Analysis
→
Port Activity Correlation
→
Reconnaissance Detection
→
Security Alert
→
SOC Investigation
→
Automated Response
→
Containment
→
Validation

Defensive Mechanism

Network Connection Monitoring

Zeek monitors network connections involving the Ubuntu server.

Purpose

Provide visibility into network communication.

Port Activity Collection

Network connection events containing destination-port information are collected.

Purpose

Identify which ports are being contacted.

Port-Scan Behavior Detection

Multiple connection attempts against different ports are correlated.

Purpose

Detect systematic reconnaissance behavior.

Source Attribution

The originating source address is identified.

Purpose

Determine which system is performing the scan.

Threshold-Based Detection

The number of contacted ports and connection frequency are evaluated against configured detection conditions.

Purpose

Reduce reliance on individual connection events.

Security Alert Generation

Wazuh generates an alert when the configured port-scanning condition is satisfied.

Purpose

Provide immediate SOC visibility.

Centralized Investigation

OpenSearch provides centralized access to network events and alerts.

Purpose

Allow analysts to investigate the scanning activity.

Automated Source Restriction

The configured response mechanism can temporarily restrict the identified laboratory source.

Purpose

Prevent continued reconnaissance activity.

Incident Timeline Reconstruction

Related network events are correlated chronologically.

Purpose

Understand the progression of the scanning activity.

Post-Containment Validation

Network activity is monitored after containment.

Purpose

Verify that scanning has stopped while legitimate service communication remains functional.

Security Tools

Primary SOC Detection and Response Tool: Wazuh

Wazuh is the primary SOC platform because it provides security-event collection, rule-based analysis, alert generation, and automated response capabilities. Wazuh can also work with network telemetry and custom detection rules for reconnaissance activity.

Purpose
  • Collect security events.
  • Analyze network-related telemetry.
  • Correlate port activity.
  • Generate security alerts.
  • Support source attribution.
  • Trigger configured response actions.
  • Support SOC investigation.

Primary Network Monitoring Tool: Zeek

Zeek is used to monitor network connections involving the Ubuntu server.

Purpose
  • Monitor network connections.
  • Generate connection telemetry.
  • Record source and destination information.
  • Record destination ports.
  • Provide network evidence for SOC investigation.

SOC Investigation Platform: OpenSearch

OpenSearch is used as the centralized investigation and visualization platform.

Purpose
  • Centralize security events.
  • Search network connection activity.
  • Investigate port-scanning alerts.
  • Visualize scanning patterns.
  • Review event timelines.
  • Support incident investigation.

Attack Simulation Tool: Nmap

Nmap is used only within the isolated laboratory to generate the controlled port-scanning activity.

Purpose
  • Generate controlled port scans.
  • Identify laboratory service exposure.
  • Produce repeated connection attempts.
  • Validate detection capabilities.
  • Support post-remediation testing.

Network Telemetry Source: Linux Network Stack

The Ubuntu Linux networking subsystem provides the underlying network activity observed by the monitoring infrastructure.

Purpose
  • Process incoming connection attempts.
  • Generate network responses.
  • Provide the actual traffic analyzed by Zeek.
  • Support validation of legitimate service connectivity.

Target Platform: Ubuntu Linux

Ubuntu provides the controlled Linux server environment.

Purpose
  • Host the monitored network services.
  • Receive controlled port-scanning traffic.
  • Generate network telemetry.
  • Apply containment actions.
  • Validate legitimate network access.

Security Testing Platform: Kali Linux

Kali Linux provides the controlled security-testing environment.

Purpose
  • Run Nmap.
  • Generate authorized port-scanning activity.
  • Validate SOC detection.
  • Test post-containment behavior.

Virtualization Platform: VirtualBox

VirtualBox provides the isolated laboratory infrastructure.

Purpose
  • Host Ubuntu.
  • Host Kali Linux.
  • Isolate the network-security assessment.
  • Prevent scanning of production systems.

Process

STEP 01

Step 1: Prepare the Isolated SOC Network Laboratory

  • Create an isolated cybersecurity laboratory using VirtualBox.
  • Configure Ubuntu as the monitored Linux server.
  • Configure Kali Linux as the security-testing system.
  • Establish controlled network connectivity.
  • Verify communication between the laboratory systems.
  • Ensure the environment is separated from production networks.
  • Confirm that only the authorized laboratory target is used.
Tools: VirtualBox + Ubuntu + Kali Linux
STEP 02

Step 2: Configure the Ubuntu Network Services

  • Configure the Ubuntu server with controlled network services.
  • Enable the required laboratory services.
  • Verify the listening ports.
  • Confirm that each service operates normally.
  • Record the expected service and port configuration.
  • Establish the normal network-service baseline.
Tools: Ubuntu Linux
STEP 03

Step 3: Establish the Normal Network Baseline

  • Connect from the authorized laboratory client to the required services.
  • Generate normal SSH or HTTP activity.
  • Verify legitimate service connections.
  • Observe the resulting network traffic.
  • Record normal connection patterns.
  • Preserve the baseline for comparison.
Tools: Ubuntu + Kali Linux
STEP 04

Step 4: Deploy Zeek Network Monitoring

  • Install Zeek within the isolated laboratory network.
  • Configure the appropriate monitoring interface.
  • Start Zeek monitoring.
  • Verify that connection logs are generated.
  • Confirm that source and destination information is recorded.
  • Confirm that destination-port information is available.
Tools: Zeek
STEP 05

Step 5: Configure Wazuh Monitoring

  • Install the Wazuh agent on the Ubuntu environment where required.
  • Register the agent with the Wazuh manager.
  • Verify agent communication.
  • Configure collection of the relevant network-security telemetry.
  • Confirm that security events are reaching Wazuh.
  • Verify that the event pipeline is operational.
Tools: Wazuh + Ubuntu
STEP 06

Step 6: Integrate Zeek Telemetry with Wazuh

  • Configure Wazuh to collect the relevant Zeek connection logs.
  • Validate the log format and parsing.
  • Confirm that source and destination fields are correctly identified.
  • Confirm that destination-port information is available.
  • Generate a normal connection event.
  • Verify that the event appears in Wazuh.
Tools: Zeek + Wazuh
STEP 07

Step 7: Configure Port-Scan Detection

  • Identify the relevant network connection fields.
  • Define the number of different ports that should trigger investigation.
  • Define the detection time interval.
  • Configure correlation based on source address.
  • Create or validate the applicable Wazuh detection rule.
  • Assign an appropriate alert severity.
  • Test the detection logic with limited controlled traffic.
Tools: Wazuh + Zeek
STEP 08

Step 8: Configure OpenSearch Investigation

  • Connect the security-event pipeline to OpenSearch.
  • Confirm that Zeek-related Wazuh events are available.
  • Create searches for repeated connection attempts.
  • Create a view showing source, destination, port, and timestamp.
  • Prepare an investigation dashboard for scanning activity.
  • Verify that network events can be searched centrally.
Tools: OpenSearch + Wazuh
STEP 09

Step 9: Configure the Automated Response

  • Configure the response mechanism for the port-scanning alert.
  • Define the laboratory containment action.
  • Configure temporary source restriction where required.
  • Ensure that the response applies only to the controlled Kali source.
  • Test the response mechanism safely.
  • Verify that the response event is recorded.
Tools: Wazuh + Ubuntu
STEP 10

Step 10: Generate Controlled Port-Scanning Activity

  • Use Kali Linux as the authorized test system.
  • Target only the laboratory Ubuntu server.
  • Perform a controlled Nmap scan against the defined test port range.
  • Generate multiple connection attempts.
  • Allow sufficient telemetry to be collected.
  • Stop the scan after the detection threshold is reached.
Tools: Nmap + Kali Linux
STEP 11

Step 11: Collect and Correlate Network Events

  • Allow Zeek to record the scanning traffic.
  • Allow Wazuh to collect the Zeek events.
  • Identify the scanning source.
  • Identify the destination server.
  • Identify the contacted ports.
  • Correlate events by source address and time.
  • Compare the activity against the normal network baseline.
Tools: Zeek + Wazuh
STEP 12

Step 12: Detect the Port-Scanning Attack

  • Verify that the configured detection rule identifies the scanning pattern.
  • Confirm that the defined port threshold is reached.
  • Verify the scanning source.
  • Verify the targeted Ubuntu server.
  • Review the number of contacted ports.
  • Confirm that Wazuh generates the security alert.
Tools: Wazuh
STEP 13

Step 13: Investigate the Security Alert

  • Open the port-scanning security alert.
  • Identify the source system.
  • Identify the destination Ubuntu server.
  • Review the contacted ports.
  • Review the timestamps.
  • Review the connection frequency.
  • Compare the behavior with normal network activity.
  • Determine whether the event represents the controlled reconnaissance scenario.
Tools: Wazuh + OpenSearch
STEP 14

Step 14: Reconstruct the Reconnaissance Timeline

  • Search OpenSearch for the identified source.
  • Review all related connection events.
  • Identify the first scanning attempt.
  • Identify subsequent port connections.
  • Determine the scan duration.
  • Identify the alert-generation event.
  • Identify the response event.
  • Build the complete reconnaissance timeline.
Tools: OpenSearch + Wazuh + Zeek
STEP 15

Step 15: Trigger and Validate Automated Containment

  • Allow the configured Wazuh response to execute.
  • Apply the temporary source restriction.
  • Attempt a controlled additional scan from the restricted laboratory source.
  • Verify that the additional scanning activity is blocked or restricted.
  • Confirm that the containment event is recorded.
  • Verify that scanning activity has stopped.
Tools: Wazuh + Ubuntu + Kali Linux
STEP 16

Step 16: Validate Legitimate Network Services

  • Use the authorized laboratory client.
  • Connect to the legitimate Ubuntu services.
  • Verify that authorized SSH or HTTP access succeeds.
  • Confirm that legitimate communication remains available.
  • Verify that the containment mechanism does not unnecessarily affect authorized clients.
  • Review the corresponding network telemetry.
Tools: Ubuntu + Kali Linux + Zeek
STEP 17

Step 17: Review the Complete SOC Investigation

  • Review the original network baseline.
  • Review the port-scanning activity.
  • Review the Zeek connection telemetry.
  • Review the Wazuh detection alert.
  • Review the OpenSearch investigation timeline.
  • Review the containment action.
  • Confirm that the scanning activity was detected and restricted.
  • Document the final investigation result.
Tools: Wazuh + OpenSearch + Zeek
STEP 18

Step 18: Perform Final SOC Detection and Response Validation

  • Repeat the controlled port-scanning assessment.
  • Verify that Zeek records the connection activity.
  • Verify that Wazuh collects the relevant events.
  • Verify that the port-scanning pattern is detected.
  • Verify that the security alert is generated.
  • Verify that OpenSearch displays the related network events.
  • Verify that the automated response is triggered.
  • Confirm that continued scanning is restricted.
  • Confirm that legitimate network services remain accessible to authorized clients.
  • Document the final SOC detection and response results.
Tools: Nmap + Zeek + Wazuh + OpenSearch + Ubuntu + Kali Linux

Outcome

  1. A controlled Ubuntu Linux server environment is successfully deployed within an isolated SOC laboratory.
  2. Normal network-service behavior is established and monitored, providing a baseline for distinguishing legitimate connections from reconnaissance activity.
  3. A controlled Port Scanning Attack is safely simulated using Nmap, generating multiple connection attempts against the laboratory server.
  4. Zeek successfully captures and records the scanning-related network telemetry, providing source, destination, port, and timing information for investigation.
  5. Wazuh correlates the network events and identifies the configured port-scanning behavior, generating a security alert when the detection threshold is reached.
  6. The SOC investigation identifies the scanning source, targeted Ubuntu server, contacted ports, connection frequency, and reconnaissance timeline through Wazuh and OpenSearch.
  7. OpenSearch provides centralized visualization and investigation of the scanning activity, allowing analysts to reconstruct the complete incident sequence.
  8. The configured automated response temporarily restricts the identified laboratory scanning source, preventing continued reconnaissance activity.
  9. Legitimate network services remain accessible to authorized laboratory clients after containment, demonstrating that the SOC response does not unnecessarily disrupt normal operations.
  10. The complete Port Scanning Attack detection, network-traffic monitoring, Zeek telemetry collection, Wazuh event correlation, security alerting, SOC investigation, reconnaissance timeline reconstruction, automated containment, legitimate-service validation, recovery, and final detection-and-response validation workflow is successfully demonstrated.
← Previous Project
Project 4 of 7
Next Project →