Changing IPs is more expensive and requires more effort than being able to scan all ports from one IP, so yes they can certainly do that if they are determined,

Changing IPs is more expensive and requires more effort than being able to scan all ports from one IP, so yes they can certainly do that if they are determined, but the more expensive you make it for them to do that (resources, time, energy), the better a position you are in. Attackers can try anything, but it's defeatist to just let them instead of creating an obstacle. You have a point that showing you're hiding something could potentially pique someone's interest, but also showing that you have few defenses and obstacles also makes you more appealing to an attacker since it makes you more worth their time. I don't think HTTP status codes are a good analogy, since they are more informative than a port being open/closed. If a port scan shows a port as closed, you don't have any information about whether a service is actually running there, just that you can't access it on a given IP address. If a scan shows filtered for a port then you can infer that it's there, but only accepts requests from a different IP. Also, running SSH on port 22 without any rate limiting is pretty much asking for brute forcing and makes you appealing as a target, even if they have no chance of succeeding it's still wasting resources. I like putting that on a high numbered port if possible, so someone has to port scan (with limited attempts) to even find it. Depending on how aggressive and thorough you get with nmap (using the -T 5 option, OS/service version detection, and scripting that can actually run active exploits versus just reconnaissance), you can absolutely use up a good amount of CPU/bandwidth. This is a frequent problem for us at work when we are getting pentested, it can be very noisy and disruptive. Though that resource usage comes more from the volume of traffic versus how it's rejected. Reduce the volume of ports they can try with one IP or in a given time frame, and reduce the resources you spend defending. However, my understanding is that a firewall would help prevent nmap from doing complete TCP handshake simulations, depending on what type of nmap scan is being done and how the firewall is blocking traffic. So yes, each individual request is almost nothing if that's happening in kernel, but that could easily add up if someone's scanning all 65535 ports and doing an invasive scan. And I haven't even talked about scanning for UDP services, which take more energy on both sides since you don't have a TCP handshake to help you infer information easily. I think it would help for you to use nmap on your own infrastructure from the position of an attacker: https://www.tryhackme.com/room/furthernmap https://www.tryhackme.com/room/furthernmap