This morning I was looking through firewall logs and saw there were about 500 packets marked as port scan. The scanning range was from 1000-1200 5000-5200. The IP address is which seems to be somewhere in Germany. And these guys continuously scan our ports on a regular basis.

The packets were all dropped by the firewall (a Sophos SG125). What I normally do is I just add the IP range to our blocking list so next time it just drops them by a specific rule.

How do you guys deal with port scan attacks?

  • 15
    500 packets is not massive. Massive starts in the millions. Commented Feb 10, 2016 at 8:48

5 Answers 5


I ignore them. And if you have a reasonable security posture, you should too.

Your servers should have no ports open to the general public other than those that you use to serve the general public.

For example, your web server should have open port 80, 443, and maybe 22; everything else should be SSH-tunneled or otherwise VPN'ed if you need to connect to it, unless you expect random nobodies on the Internet to be using the listening service. Perhaps you may want to remap SSH to port 222 or or something in the upper range to avoid filling your auth logs with failed logins, and that should be as exciting as your servers get.

If instead the port scan is hitting your outbound corp gateway, then the scan should show zero ports open, because your corp gateway isn't a server. And you, like a wise IT admin, run all your servers elsewhere on the internet, not inside your corp network, for a whole raft of reasons I won't go into here.

A port scan should reveal to the attacker nothing that they couldn't reasonably guess. And if this is not the case, then your problem isn't the port scan, it's the public secrets you're trying to hide by blocking port scans.

  • 3
    "Perhaps you may want to remap SSH to port 2022 or or something in the upper range" By my understanding, that can be dangerous if one of the server's non-root users does get compromised as root access is required to listen to port 22 but not to port 2022.
    – JAB
    Commented Feb 9, 2016 at 13:33
  • 5
    @JAB If a non-root user gets compromised, the attacker will get the privileges of that user. What difference would it make if the service is running on 22 or 2022? Changing the port is just to thwart the automatic scans that search for common ports and brute force common credentials.
    – void_in
    Commented Feb 9, 2016 at 13:45
  • 8
    @void_in The difference is that a user without the ability to bind to ports <1024 would not be able to start their own "SSH" server on port 22 while they could do so just fine on port 2022 (and if you prevent the user from binding to any ports, then you also prevent them from using any sort of socket-based IPC, which may not be desirable). security.stackexchange.com/a/32311/27226 brings up some other reasons why changing the SSH port from 22 might not be such a good idea.
    – JAB
    Commented Feb 9, 2016 at 13:50
  • 5
    @void_in Suppose that someone gets shell access to your server as non-root, and additionally they have a way to crash sshd. They can crash sshd, then run a honeypot version of sshd that logs all passwords that are entered, on the same port. They can't do that if your sshd port is below 1024, because only root can listen on those ports. Commented Feb 9, 2016 at 20:14
  • 3
    @immibis: Your sshd ought to have passwords turned off (because you're exclusively using SSH keys, right?). Authenticating to a honeypot with your SSH key does not give the attacker anything useful, if I understand the crypto correctly. If you see a password prompt, you know not to enter your password. So this is a rather hypothetical risk, if you're following best practices.
    – Kevin
    Commented Feb 10, 2016 at 3:36

I don't believe in enumerating badness. If you have infrastructure sitting on the internet it's going to get scanned all the time by numerous IPs.

For example, I created an AWS app that turns up spot instances, scans blocks of IPs from a list, and turns them off once the results are shipped to the master server. If I was scanning your range daily you would be blocking different AWS IPs every day since I'm assigned them randomly. That means you may block something legitimate down the line when they get assigned an IP I used.

  • Is it sensible to ban an IP temporarily (e.g. 24 hours) if a port scan is detected?
    – Tahlor
    Commented Dec 1, 2016 at 17:20
  • 1
    Assuming you get to it before the scan is complete, and the scanner scans again from the same IP within 24 hours, and you are certain that you have no legitimate use from that IP. For IP blocking to be a reasonable long-term solution, it needs to begin the instant the scan does, and end the instant the scan does. Which is infeasible.
    – Οurous
    Commented Apr 11, 2017 at 23:36

I use Snort or Suricata on pfSense to automatically block IPs for a time period.

Sophos UTM appears to have similar functionality.


After I see someone scanning I usually do a little recon on who they are, if they are on known blocklists I usually ignore and let the firewall drop it (ASAs). If they are an unknown entity I'll add a rule to drop connections with our IPS from that IP. I have used suricata in the past and will give that a +1 as it could help in a situation like this as the comment above stated.


Write a program that listens on a common port such as port 21 or 25. If someone connects to the program, the program disconnects from them, then adds that IP address to the firewall to block them on all ports.

I also have a web site that only says Coming Soon. It only appears if you access my web server directly with the IP address, instead of using a dot com name. In that page, I add their IP address to the firewall ban list. I also add their IP address to a table in a database. Other servers check that table for new entries and ban their IP address from there too.

Also, I show no mercy. IP addresses are banned forever. These days, it's probably a static IP address belonging to a foreign government. I have 260 IP addresses so far.

People/governments have automated tools to automatically try every security hole they know of. You need automated tools to ban their IP address when they are first discovered instead of hoping all your defenses are 100%. If you wait until the next day to look at your logs, you'll look one day and find all your logs have been deleted and there's this new folder there with a program in it that even the administrator can't delete.

If you hope it's enough that your router stops them, you should read about how the CIA can hack your router.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .