30

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 85.25.217.47 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?

psmears
  • 900
  • 7
  • 9
PaddyKim
  • 459
  • 2
  • 5
  • 8

5 Answers5

55

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.

tylerl
  • 82,665
  • 26
  • 149
  • 230
  • 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 Feb 09 '16 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 Feb 09 '16 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). http://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 Feb 09 '16 at 13:50
  • Of course, you could have a local firewall with specific rules to allow only certain applications to use specific ports, but that only covers the scenario I brought up rather than the other ones mentioned in the linked answer (though is actually related to one of the scenarios mentioned in that linked answer). – JAB Feb 09 '16 at 13:53
  • 2
    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 09 '16 at 13:53
  • @JAB the risk can be mitigated if you know what you're doing. You could also do the mapping in your firewall instead of the application. And some people pick an alternate port in the privileged range such as 222, which is not a bad idea either. – tylerl Feb 09 '16 at 15:35
  • 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. – user253751 Feb 09 '16 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 Feb 10 '16 at 03:36
  • The threat is certainly esoteric and would require a lot of things to fail up front. If you're setting up a policy to apply broadly across a fleet of servers, then it's worth considering. But otherwise just use your common sense. – tylerl Feb 10 '16 at 03:38
  • I had someone trying to brute force my RDP service. I ignored them for a couple of weeks but than gave in and switched it off (in favour of another remote access solution) – Andrew Savinykh Feb 10 '16 at 04:50
  • Dont you dare having 22 open. Always use something non-default such as port 42994. Plus the SSL best practice with only allowing key-based verification. SSL isnt perfect softwate which means that it still has exploizable weaknesses that might be used on 22 oder 2222 servers – BlueWizard Feb 11 '16 at 05:53
  • I never open port 22, and using it in a non-default port is a false sense of security. I only ssh only through VPN. – Rui F Ribeiro Feb 18 '16 at 07:57
  • 2
    @RuiFRibeiro It's a bit of a toss-up as to whether it's safer to have a VPN listener or an SSH listener; both can be exploitable with equal probability. ipsec or openvpn for example aren't inherently safer than openssh. Running SSH on an alternate port reduces or even eliminates automated attacks, which doesn't make you *safe* but does make you *safer* and eliminates a lot of log noise. – tylerl Feb 18 '16 at 15:57
  • @BlueWizard As people before in these comments have been pointed out, _don't_ use a high-port for SSH. Using something like 42994 reduces security. Furthermore, you are confusing SSL with SSH (the former of which tends to use port 443). You need to grasp the basics first before giving out dangerous advice. – forest Jan 26 '18 at 03:07
  • My comment from a year ago seem to by typed on a smartphone. "SSL" was a typo. And not using 22, 222 and similar easy to guess ports has benefits as stated above. I further want to add that it reduces your log spam which means you might have better oversight over the raw data (latter one is not a convincing argument I have to admit). I just can repeat that while SSH is pretty mature you'll never know when the shit hits the fan and every :22 and :222 device gets picked first. – BlueWizard Jan 26 '18 at 16:34
  • @user253751 "They can crash sshd, then run a honeypot version of sshd that logs all passwords that are entered, on the same port." This would only work if he could get access to the sshd server key, which he has not in your scenario. – HolgerJeromin Apr 20 '20 at 18:53
19

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.

k to the z
  • 1,125
  • 1
  • 12
  • 25
  • Is it sensible to ban an IP temporarily (e.g. 24 hours) if a port scan is detected? – Tahlor Dec 01 '16 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 Apr 11 '17 at 23:36
4

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

Sophos UTM appears to have similar functionality.

Anti-weakpasswords
  • 9,850
  • 2
  • 24
  • 52
0

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.

user96118
  • 9
  • 1
-2

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.

Russell Hankins
  • 105
  • 2