Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
500 packets is not massive. Massive starts in the millions. – Stig Hemmer Feb 10 at 8:48

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.

share|improve this answer
"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 Feb 9 at 13:33
@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 Feb 9 at 13:45
@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). brings up some other reasons why changing the SSH port from 22 might not be such a good idea. – JAB Feb 9 at 13:50
In order to start a new service, either the user would have to edit the sshd_config file (which only root can do) or he need to copy an elf which will start a new service on a specified port. In both cases it doesn't matter what port the original service is running on. – void_in Feb 9 at 13:53
@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. – immibis Feb 9 at 20:14

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.

share|improve this answer

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

Sophos UTM appears to have similar functionality.

share|improve this answer

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.