I came across this tool recently https://github.com/drk1wi/portspoof
How efficient will it be to use it to confuse hackers doing port scanning? If it's actually going to be pretty efficient, why hasn't it caught up so far? That is, 189 stars for 5 years is bad.
Multiple problems here.
Dynamic port responses - if I scan you from two different IPs and compare the two responses, do I get a valid port list? If so, it is a very weak defence.
You're burning CPU to respond to the reconnaissance phase of an attack. This can be used against you. Depending on how this is set up, I can kill your server by forcing your spoofer to consume all the CPU on the machine.
Are you sure portspoof doesn't have any extra bonus vulnerabilities that your app DOESN'T have?
Can I slowloris likely non-real ports and see what else stops responding to filter out spam?
If you're running this, and I get a foothold and open a remote command port - will you notice, or will you get lost in your own spam?
zlib doesn't get updated much ever these days. Not because there are no maintainers, but because it is complete.
Commented
Jul 19, 2019 at 3:53
I assume the effectiveness will be very limited.
First of all, exploiting port scanning tools will rarely be useful because most pentesters will use VMs and other confined environments when conducting any attacks.
Second, it is very unclear how useful it is to obfuscate which ports are really open. If you still have services running these obviously have to respond properly. There are only 65536 ports so trying them all is not a big deal. In any case, you will usually have to announce on which ports services run because you want people to find them! Why else are you running them?
And third, answering all queries on all ports might actually generate quite a bit of useless work. You might want to spend those clockcycles elsewhere.
So, these are the first reasons that come to my mind. I have not used this tool but maybe other people think similarly and that is why it has not seen widespread adoption.
There is one thing that the author of that software says which I like:
Instead of informing an attacker that a particular port is in a CLOSED or FILTERED state [...]
The scan is not going to tell the hacker whether a port is really open or not. This is a good idea and I use it through my iptables setup.
What I do in my firewall is let the user immediately connect to my regular services or DROP the packet. By dropping packets, you do not right away tell the user whether the port is opened or closed. This is similar to attempting a login with the wrong password. It pauses for 1 second or so then you can try again. By doing so, it can take nmap. Assuming the client waits for a reply for up to 1 second, then it will take over 18 hours to scan the 65536 ports.
Of course, my firewall blocks all ports except the very few that I want to open (i.e. maybe 22, 80, and 443). So if you try port 5432 or 3306, you'll get the DROP even if I have those ports actually open.
Outside of that, like many pointed out, this is more likely to drain a lot of your CPU time as the hacker tools are likely to try to connect to all the satisfactory ports (i.e. HTTP-like services) over and over until they decide that it's not worth it... which could take a very long time. I had a computer under an SMTP relay attack which lasted over 6 months. It was great for me since I could test various things in my software and make sure it worked with a real live (but safe) attack.
Note to self: Bots are brain dead.
