Port scanning is the digital equivalent of rattling every doorknob on a building. An attacker sends packets to a range of ports on your server, looking for open services they can exploit. It is almost always the first phase of a targeted attack — the reconnaissance that precedes brute-force attempts, exploitation of vulnerable services, or lateral movement into a network.
Most administrators see port scans in their logs daily and ignore them. That is understandable when the volume is high and the scans appear automated. But when you see focused, repeated reconnaissance from the same source — especially when it progresses from broad sweeps to targeted service probing — that is worth reporting. This article is part of my complete guide to reporting IP abuse, focused specifically on port scanning and network reconnaissance.
How to Identify Port Scanning in Your Logs
Port scanning leaves distinct patterns in firewall and IDS logs. The key is knowing where to look and what the signatures look like.
A quick note before you investigate: some SEO crawlers, vulnerability scanners, and security audit tools probe multiple ports as part of their normal operation. If the source IP belongs to a known service like Screaming Frog, Qualys, Nessus, or a penetration testing firm, verify with your team that it is not an authorized scan before filing an abuse report. Check the IP with the IP Location tool and see my guide to identifying web crawlers if the traffic looks more like automated crawling than malicious reconnaissance.
Firewall Logs
Linux (iptables/nftables):
If you have a logging rule for dropped packets (and you should), iptables logs entries like this to syslog or journald:
Feb 12 03:14:22 web01 kernel: [DROP] IN=eth0 OUT= SRC=198.51.100.47 DST=203.0.113.10 PROTO=TCP SPT=54821 DPT=22 WINDOW=1024 SYN
Feb 12 03:14:22 web01 kernel: [DROP] IN=eth0 OUT= SRC=198.51.100.47 DST=203.0.113.10 PROTO=TCP SPT=54822 DPT=23 WINDOW=1024 SYN
Feb 12 03:14:22 web01 kernel: [DROP] IN=eth0 OUT= SRC=198.51.100.47 DST=203.0.113.10 PROTO=TCP SPT=54823 DPT=25 WINDOW=1024 SYN
Feb 12 03:14:23 web01 kernel: [DROP] IN=eth0 OUT= SRC=198.51.100.47 DST=203.0.113.10 PROTO=TCP SPT=54824 DPT=80 WINDOW=1024 SYN
Feb 12 03:14:23 web01 kernel: [DROP] IN=eth0 OUT= SRC=198.51.100.47 DST=203.0.113.10 PROTO=TCP SPT=54825 DPT=443 WINDOW=1024 SYN
Feb 12 03:14:23 web01 kernel: [DROP] IN=eth0 OUT= SRC=198.51.100.47 DST=203.0.113.10 PROTO=TCP SPT=54826 DPT=3306 WINDOW=1024 SYN
The telltale signs: a single source IP hitting multiple destination ports in rapid succession, all SYN packets (connection initiations), sequential or well-known port numbers, and a small TCP window size (common in scanning tools).
BSD/macOS (pf):
Feb 12 03:14:22.384580 rule 4/0(match): block in on em0: 198.51.100.47.54821 > 203.0.113.10.22: S 0:0(0) win 1024
Feb 12 03:14:22.384612 rule 4/0(match): block in on em0: 198.51.100.47.54822 > 203.0.113.10.23: S 0:0(0) win 1024
Feb 12 03:14:22.384644 rule 4/0(match): block in on em0: 198.51.100.47.54823 > 203.0.113.10.25: S 0:0(0) win 1024
Windows Firewall:
Windows Firewall logs to %systemroot%\system32\LogFiles\Firewall\pfirewall.log when logging is enabled:
2025-02-12 03:14:22 DROP TCP 198.51.100.47 203.0.113.10 54821 22 44 S 0 0 1024
2025-02-12 03:14:22 DROP TCP 198.51.100.47 203.0.113.10 54822 23 44 S 0 0 1024
2025-02-12 03:14:22 DROP TCP 198.51.100.47 203.0.113.10 54823 25 44 S 0 0 1024
IDS/IPS Alerts
If you run Snort or Suricata, they generate alerts specifically for port scanning activity:
[**] [122:1:0] (portscan) TCP Portscan [**]
[Priority: 3]
02/12-03:14:22.384580 198.51.100.47 -> 203.0.113.10
PROTO:255 TTL:0 TOS:0x0 ID:0 IpLen:20 DgmLen:158
Open Port Count: 3 Unique Connections: 47 Change: 23
Scanner IP Range: 198.51.100.47-198.51.100.47
Port/Proto Range: 1-65535 Duration: 4 seconds
Suricata's EVE JSON log makes this even easier to parse programmatically, with event types like alert and signatures matching ET SCAN rules.
Patterns That Indicate Reconnaissance
Not every connection attempt is a scan. Here is what distinguishes real reconnaissance:
- Sequential port probing: Destination ports increment sequentially (1, 2, 3... or 20, 21, 22, 23, 25...)
- Well-known port sweeps: Only common service ports are hit (22, 80, 443, 3306, 5432, 8080) — this indicates a targeted scan looking for specific services
- High connection rate: Dozens or hundreds of connection attempts per second from a single source
- SYN-only packets: The connection is never completed (SYN without ACK), indicating a half-open or stealth scan
- Service fingerprinting: After initial port discovery, you see follow-up connections to open ports with unusual payloads — the scanner is trying to identify software versions
Evidence Gathering Checklist
Before filing an abuse report, I recommend collecting the following:
- Firewall or IDS logs covering the entire scan duration, with timestamps in UTC
- Source IP address (verify it is a single source, not multiple IPs in a coordinated scan)
- List of destination ports targeted — note whether they are sequential, random, or focused on specific services
- Scan pattern type — SYN scan, full TCP connect, UDP, or service fingerprinting (this tells the ISP how sophisticated the activity is)
- Duration and frequency — a one-time 30-second sweep is different from daily scans over a week
- Any follow-up activity — did brute-force attempts or exploit attempts follow the scan? This elevates the severity significantly
- Your server's IP address and hostname — the target
Extract the relevant log lines into a plain text file. Strip any lines unrelated to the scanning IP to keep the report focused. Include enough context to show the pattern — a dozen representative lines with timestamps showing the sweep, not your entire syslog.
Finding the Abuse Contact
To report a port scan, you need to know which ISP or hosting provider controls the source IP. Here is how I find it:
- Go to the IP Location tool on DNSChkr
- Enter the scanning IP address (e.g.,
198.51.100.47) - The results will show the ISP, organization, ASN, and geographic location
- Look for the abuse contact — this is typically
[email protected]
You can also query the WHOIS record directly, which often includes an OrgAbuseEmail or abuse-mailbox field in the ARIN/RIPE/APNIC database entry.
If the IP belongs to a cloud provider (AWS, GCP, Azure, DigitalOcean, etc.), report directly to the cloud provider's abuse team — they tend to act faster than traditional ISPs because scanning from cloud instances usually violates their terms of service.
Port Scanning Abuse Report Template
Use this template when filing your report. Replace the placeholders with your actual data:
Subject: Port Scanning / Network Reconnaissance from [SOURCE_IP]
Abuse Team,
I am reporting unauthorized port scanning and network reconnaissance
originating from IP address [SOURCE_IP] targeting my server at
[YOUR_IP] ([YOUR_HOSTNAME]).
Summary:
- Source IP: [SOURCE_IP]
- Target IP: [YOUR_IP]
- Scan type: [SYN scan / TCP connect / UDP scan / service fingerprinting]
- Ports targeted: [e.g., 1-1024 sequential, or 22,80,443,3306,8080]
- Duration: [START_TIME] to [END_TIME] (UTC)
- Total connection attempts: [COUNT]
- Follow-up activity: [None observed / Brute-force on SSH followed scan]
This activity constitutes unauthorized network reconnaissance. The
scan pattern is consistent with [nmap SYN scan / automated vulnerability
scanner / targeted service enumeration].
Relevant firewall logs are attached below (timestamps in UTC):
[PASTE_LOG_LINES]
I request that you investigate this activity and take appropriate
action against the account responsible.
Regards,
[YOUR_NAME]
[YOUR_CONTACT]
Attach the log evidence either inline or as a .txt attachment. Keep the log excerpts focused — 20-50 representative lines are better than thousands of lines that obscure the pattern.
Where to Report
ISP abuse desk: Every ISP is required to maintain an abuse contact. Send your report to the email found via WHOIS or the IP Location tool. Use the standard abuse@ address when available.
Hosting provider: If the scanning IP belongs to a VPS or cloud provider, report through their abuse portal. Most major providers have web forms: AWS (aws.amazon.com/forms/report-abuse), GCP (support.google.com/cloud), DigitalOcean (digitalocean.com/company/contact), etc.
Your own hosting provider: If you are on a managed hosting platform, inform your provider as well. They may be able to implement network-level blocks upstream.
Scan Types and What They Mean
Understanding the type of scan helps you write a more effective report and communicate severity to the ISP.
Full TCP Connect Scans
The scanner completes the full three-way handshake (SYN, SYN-ACK, ACK) for each port. This is the noisiest scan type and the easiest to detect. You will see completed connections in your logs, not just SYN packets. These are often run by less sophisticated attackers or automated scripts that do not bother with stealth.
SYN Stealth Scans
The scanner sends a SYN packet and waits for a SYN-ACK (port open) or RST (port closed), but never completes the handshake. This is the default mode for nmap and is called "stealth" because it historically avoided logging on systems that only logged completed connections. Modern firewalls log SYN packets, so this is no longer stealthy — but it remains the most common scan type.
UDP Scans
The scanner sends UDP packets to common service ports (53, 69, 123, 161, 500, etc.). UDP scanning is slower and less reliable because there is no handshake — the scanner relies on ICMP "port unreachable" responses for closed ports and interprets silence as "open or filtered." UDP scans often indicate the attacker is looking for DNS, SNMP, or NTP services to exploit or use in amplification attacks.
Service Version Detection and Fingerprinting
After identifying open ports, the scanner sends crafted payloads to determine the exact software and version running on each port. You might see HTTP requests with unusual User-Agent strings, SSH banners being collected, or database protocol handshakes. This is the most targeted phase and indicates the attacker is building a profile to select exploits. If you see this, it is worth mentioning in your report — it demonstrates intent beyond casual scanning.
What to Expect After Reporting
I will be honest: many ISPs treat port scanning as low priority. Unlike malware or botnet activity, port scanning alone does not directly cause harm, and some providers argue it is not explicitly prohibited by their terms of service.
That said, reporting still matters for several reasons:
- Repeated reports accumulate. An ISP that receives multiple complaints about the same IP will eventually act.
- Cloud providers act faster. AWS, GCP, and similar providers routinely suspend instances reported for scanning because it violates their acceptable use policies.
- It creates a paper trail. If the reconnaissance escalates to an actual attack, your earlier report establishes a timeline and strengthens any legal or insurance claims.
- Some ISPs do act. Particularly if the scanning IP is a compromised customer machine, the ISP may notify the customer or quarantine the connection.
Expect response times ranging from 24 hours (cloud providers) to several weeks (smaller ISPs), or no response at all. If the scanning continues and escalates, file follow-up reports referencing your original ticket.
Prevention Tips
Reporting is reactive. Here is how to reduce your exposure to port scanning proactively:
- Default-deny firewall policy: Only allow inbound traffic to ports you explicitly need. Everything else should be dropped silently (not rejected — rejection responses confirm your host is alive).
- Port knocking or single-packet authorization (SPA): Hide sensitive services like SSH behind a knock sequence. The port appears closed until the correct sequence of connection attempts is received. Tools like
fwknopimplement this cleanly. - Move services off default ports: Running SSH on port 2222 instead of 22 will not stop a determined attacker, but it eliminates the noise from automated scanners that only hit default ports.
- IDS/IPS with automatic blocking: Configure Suricata or fail2ban to automatically block IPs after detecting scan patterns. A threshold of 10+ ports hit within 60 seconds is a reasonable starting point.
- Rate limiting at the network edge: If you have access to upstream router ACLs or cloud security groups, implement connection rate limits per source IP.
- Check your own exposure: Use DNSChkr's Port Scanner to scan your own server from the outside. If you can see open ports you did not expect, an attacker can too.