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.