Oui, utiliser DROP est inutile. Utilisez REJECT.
Même lorsque la règle indique "DROP", le système répond toujours à un SYN entrant avec un TCP RST/ACK - ce qui est le comportement par défaut pour les ports sans services en cours d'exécution. (tcpdump et autres n'enregistrent pas cela).
Si un service est en cours d'exécution, la réponse au SYN est un TCP SYN/ACK.
Étant donné que la règle DROP ne répond pas normalement à un SYN/ACK TCP, mais plutôt à un RST/ACK, votre règle DROP fera la publicité de votre pare-feu et les scanners de port sauront que vous faites du pare-feu et pourraient continuer à vous harceler dans l'espoir de faire tomber votre pare-feu.
C'est maintenant que nmap peut rapporter "filtré" au lieu de "fermé" par exemple :
$ nmap localhost
Starting Nmap 6.40 ( http://nmap.org ) at 2018-03-14 00:21 SAST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0000060s latency).
Not shown: 986 closed ports
PORT STATE SERVICE
21/tcp open ftp
53/tcp open domain
80/tcp open http
Nmap done: 1 IP address (1 host up) scanned in 1.60 seconds
$ iptables -I INPUT -p tcp --dport 1111 -j DROP
$ nmap localhost
Starting Nmap 6.40 ( http://nmap.org ) at 2018-03-14 00:21 SAST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0000060s latency).
Not shown: 986 closed ports
PORT STATE SERVICE
21/tcp open ftp
53/tcp open domain
80/tcp open http
1111/tcp filtered lmsocialserver
Nmap done: 1 IP address (1 host up) scanned in 1.60 seconds
$ iptables -D INPUT 1
En tant que telle, la seule configuration de pare-feu "invisible" est celle où un dispositif dédié se trouve entre vos appareils et ne fait que transférer sélectivement les ports.
Si vous voulez vraiment perturber les scanners de base, vous pouvez TARPIT les connexions tcp, ce qui met la fenêtre TCP à 0 afin qu'aucune donnée ne puisse être transférée après l'ouverture de la connexion, en ignorant les demandes de fermeture de la connexion, ce qui signifie que le scanner doit attendre le timeout de la connexion, s'il veut être sûr. Mais il est trivial pour un attaquant de détecter cela et de rendre son délai d'attente très court.
Tout bien considéré, il est probablement préférable d'utiliser REJECT ou de placer un dispositif de transfert de port dédié entre votre serveur et Internet.
Ou simplement l'exécution de services sur vos machines tournées vers l'Internet qui ne nécessitent pas de pare-feu.
En général, REJECT est la meilleure solution pour les serveurs web, car quel que soit le service qui essaie d'y accéder (le plus souvent, c'est vous), il obtiendra rapidement une réponse et les utilisateurs ou les autres services ne seront pas obligés d'attendre en se demandant s'il y a une panne de réseau.
