Web Probing

Review Caddy access logs if enabled

sudo journalctl -u caddy --since "1 hour ago"

Start by reviewing recent web activity from the service itself.

Search for suspicious paths in your web logs

sudo grep -Ei "wp-admin|phpmyadmin|\.env|admin|login|setup|config|backup" /var/log/* 2>/dev/null

This helps identify common targets that attackers and bots probe for automatically.

Count repeated client IPs in access logs

sudo awk '{print $1}' /var/log/caddy/*.log 2>/dev/null | sort | uniq -c | sort -nr | head

A single IP generating many requests in a short time may indicate scanning or enumeration.

Look for repeated 404 responses

sudo grep ' 404 ' /var/log/caddy/*.log 2>/dev/null | tail -n 50

A high volume of 404s often suggests automated discovery attempts.

Check firewall logs for related source IPs

sudo grep "UFW BLOCK" /var/log/ufw.log | tail -n 50

Sometimes web probing is followed by other connection attempts against different services.

Block a clearly abusive source IP

sudo ufw deny from <IP_ADDRESS>

Restrict access to sensitive paths through your web server configuration

# Example concept:
# deny access to admin or internal paths not meant for public use

If a path should not be public, do not rely on obscurity alone.

Disable or remove unused web applications

sudo systemctl list-units --type=service --state=running
sudo ss -tulnp

Probe attempts matter more when forgotten software is still present and reachable.

Review what paths actually exist on disk

sudo find /var/www -maxdepth 3 -type f | less

Confirm whether suspicious requests were just noise or whether something sensitive might actually exist.

Check for exposed backups or environment files

sudo find /var/www -type f \( -name "*.bak" -o -name ".env" -o -name "*.old" -o -name "*.zip" \)

These files are frequently targeted because they can leak secrets or source code.

Review for successful admin or app access

sudo grep -Ei "admin|login" /var/log/caddy/*.log 2>/dev/null | tail -n 100

Web probing alone is not a compromise, but confirm whether it escalated into real access attempts or successful use.

Option 1 — Remove anything you do not need

sudo find /var/www -type f | less

Old panels, test apps, backups, and forgotten files create unnecessary risk.

Option 2 — Keep applications and dependencies updated

sudo apt update
sudo apt upgrade

Probing often turns into exploitation when software is outdated.

Option 3 — Restrict sensitive paths

# Protect internal admin or setup paths in your web server configuration

If something should not be public, explicitly protect it.

Option 4 — Review logs regularly

sudo journalctl -u caddy --since "24 hours ago"

Repeated web probing helps show what attackers expect to find on your server.

Option 5 — Separate public and internal services

sudo ss -tulnp

Public websites should not sit beside unnecessary internal dashboards, database ports, or admin tools.