HANDS-ON LAB WRAP

Lab: Linux Servers for Security Operations

Service Management, Monitoring & Hardening from a SOC Perspective

Duration
45-60 min
Difficulty
Intermediate
Environment
Linux VM/WSL

Lab Objectives

After completing this lab, you will be able to:

Common Linux Server Services

SOC analysts must understand these services to detect attacks and misconfigurations:

Apache/Nginx

Web servers - primary target for web attacks (SQLi, XSS, RCE)

Ports: 80, 443

SSH (sshd)

Remote access - brute force target, credential theft

Port: 22

Postfix/Sendmail

Mail servers - spam relays, phishing infrastructure

Ports: 25, 587, 465

MySQL/PostgreSQL

Databases - injection attacks, data exfiltration

Ports: 3306, 5432

Samba/NFS

File sharing - lateral movement, ransomware spread

Ports: 139, 445, 2049

DNS (bind)

Name resolution - DNS hijacking, exfiltration tunnels

Port: 53

Lab Progress

0 of 4 tasks completed

1

Service Management with systemctl

Pending

Understanding how to list, start, stop, and investigate services is critical for SOC analysts.

bash - systemctl commands
$ systemctl list-units --type=service --state=running UNIT LOAD ACTIVE SUB DESCRIPTION ssh.service loaded active running OpenSSH server daemon apache2.service loaded active running Apache HTTP Server mysql.service loaded active running MySQL Community Server cron.service loaded active running Regular background... $ systemctl status ssh ● ssh.service - OpenSSH server daemon Loaded: loaded (/lib/systemd/system/ssh.service; enabled) Active: active (running) since Mon 2024-01-04 10:15:32 UTC Main PID: 1234 (sshd) CGroup: /system.slice/ssh.service └─1234 /usr/sbin/sshd -D
Command Purpose
systemctl list-units --type=service List all loaded services
systemctl status <service> View service status and recent logs
systemctl stop <service> Stop a service (incident response)
systemctl disable <service> Prevent service from starting at boot
systemctl is-enabled <service> Check if service starts at boot
SOC Red Flag: Unknown services running, especially those listening on network ports. Use systemctl list-units --type=service --state=running and investigate any unfamiliar names.
I listed all running services and checked SSH service status
2

Investigating Listening Ports

Pending

Identify what services are listening on network ports - unexpected listeners may indicate compromise.

ss -tulnp

Flags: -t (TCP), -u (UDP), -l (listening), -n (numeric), -p (process)

ss output
$ ss -tulnp Netid State Local Address:Port Process tcp LISTEN 0.0.0.0:22 users:(("sshd",pid=1234)) tcp LISTEN 0.0.0.0:80 users:(("apache2",pid=5678)) tcp LISTEN 127.0.0.1:3306 users:(("mysqld",pid=9012)) tcp LISTEN 0.0.0.0:4444 users:(("nc",pid=6666))
Suspicious in the example above: Port 4444 with netcat (nc) listening. This is a common Metasploit reverse shell port. The process ID 6666 should be immediately investigated.
SOC Tip: Compare listening ports against your organization's baseline. Any new listeners should trigger an investigation.
# Find process details by PID
ps aux | grep 6666
ls -la /proc/6666/exe
I listed listening ports and can identify expected vs. unexpected services
3

Server Log Investigation

Pending

Server logs are critical for detecting attacks. Know where to look and what to look for.

Service Log Location What to Look For
SSH /var/log/auth.log Failed logins, brute force attempts
Apache /var/log/apache2/access.log Web attacks, SQLi, directory traversal
Nginx /var/log/nginx/access.log Same as Apache
System /var/log/syslog Service crashes, kernel messages
All (journald) journalctl Unified logging for systemd services
# Check for SSH brute force attempts
grep "Failed password" /var/log/auth.log | tail -20

# Count failed attempts per IP
grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn
SSH brute force detection
$ grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -5 847 185.234.219.45 523 91.240.118.172 312 45.227.255.99 89 192.168.1.100 12 10.0.0.5
In the example above: IP 185.234.219.45 has 847 failed login attempts - this is clearly a brute force attack. This IP should be blocked and reported.
I know how to search logs for brute force attacks and web exploits
4

Basic Server Hardening Checklist

Pending

SOC analysts should understand hardening recommendations to advise teams on remediation.

Category Hardening Action Command/Config
SSH Disable root login PermitRootLogin no in /etc/ssh/sshd_config
SSH Use key-based auth only PasswordAuthentication no
Firewall Enable UFW/iptables sudo ufw enable
Services Disable unused services systemctl disable <service>
Updates Enable automatic security updates apt install unattended-upgrades
Monitoring Install fail2ban apt install fail2ban
fail2ban: Automatically blocks IPs after repeated failed login attempts. Essential for any internet-facing SSH server.
# Check fail2ban status
sudo fail2ban-client status sshd

# View currently banned IPs
sudo fail2ban-client status sshd | grep "Banned IP"
I understand basic Linux server hardening principles
I can advise on SSH hardening and fail2ban implementation