So , portspoof will reply that every port is opened but with a fake banner on specific service , but that does not means that the server is safe , however the idea is great .
Even if a scanner is pointed to port 80 and it receives an ssh banner , the attacker already knows that port 80 is for http service , this means apache or nginx , and just need to launch some exploits .
It is much better for the server admin to compile individually the tools that will use and change the output info on scanners , instead the attacker gets "Nginx 2.05" it will get "Custom http server 1.0" witch there is no exploit for it , or configure iptable for on port scanner to drop every every connection from that ip , or even to slow down the response by implementing some rules of pks/s on that port .
Another alternative witch could be more valuable to the system admin , it to run a script on the background that is checking iptables reports , and when it gets an attempt to scan or ping a port not configured in iptables the that script will run automatically an nmap scan on attacker ip , register the ip on a separated file with hour , country of ip , etc..... .
Same thing can be done to http ports if something out of the ordinary is been experimented by the attacker , like sql exploitation attempt , etc.....
on ssh ports anyone can configure a port knocking config , witch is easy to do and much more safer than anything , it must need the correct sequence of pings to get that port opened and the ssh keys ahead that turns the exploitation or brute force attempt even more improbable .
So , portspoof will reply that every port is opened but with a fake banner on specific service , but that does not means that the server is safe , however the idea is great . Even if a scanner is pointed to port 80 and it receives an ssh banner , the attacker already knows that port 80 is for http service , this means apache or nginx , and just need to launch some exploits . It is much better for the server admin to compile individually the tools that will use and change the output info on scanners , instead the attacker gets "Nginx 2.05" it will get "Custom http server 1.0" witch there is no exploit for it , or configure iptable for on port scanner to drop every every connection from that ip , or even to slow down the response by implementing some rules of pks/s on that port . Another alternative witch could be more valuable to the system admin , it to run a script on the background that is checking iptables reports , and when it gets an attempt to scan or ping a port not configured in iptables the that script will run automatically an nmap scan on attacker ip , register the ip on a separated file with hour , country of ip , etc..... . Same thing can be done to http ports if something out of the ordinary is been experimented by the attacker , like sql exploitation attempt , etc..... on ssh ports anyone can configure a port knocking config , witch is easy to do and much more safer than anything , it must need the correct sequence of pings to get that port opened and the ssh keys ahead that turns the exploitation or brute force attempt even more improbable .