Est-il sage d'utiliser un outil de portspoofing sur votre serveur pour confondre les attaquants?
J'ai rencontré cet outil récemment https://github.com/drk1wi/portspoof
Dans quelle mesure sera-t-il efficace de l'utiliser pour confondre les pirates informatiques effectuant une analyse de port? Si cela va être assez efficace, pourquoi ne l'a-t-il pas rattrapé jusqu'à présent? Autrement dit, 189 étoiles pendant 5 ans, c'est mauvais.
Plusieurs problèmes ici.
Réponses de port dynamiques - si je vous scanne à partir de deux IP différentes et compare les deux réponses, ai-je une liste de ports valide? Si c'est le cas, c'est une défense très faible.
Vous brûlez du CPU pour répondre à la phase de reconnaissance d'une attaque. Cela peut être utilisé contre vous. Selon la façon dont cela est configuré, je peux tuer votre serveur en forçant votre spoofer à consommer tout le CPU de la machine.
Êtes-vous sûr que portspoof n'a pas de vulnérabilités bonus supplémentaires que votre application n'a pas?
Puis-je ralentir les ports non réels probables et voir quoi d'autre cesse de répondre pour filtrer le spam?
Si vous exécutez cela, et que je prends pied et que j'ouvre un port de commande à distance - le remarquerez-vous ou vous perdrez-vous dans votre propre spam?
Je suppose que l'efficacité sera très limitée.
Tout d'abord, l'exploitation des outils d'analyse de port sera rarement utile car la plupart des pentesters utiliseront des machines virtuelles et d'autres environnements confinés lors de la conduite d'attaques.
Deuxièmement, il n'est pas très clair à quel point il est utile de masquer les ports réellement ouverts. Si vous avez toujours des services en cours d'exécution, ceux-ci doivent évidemment répondre correctement. Il n'y a que 65536 ports, donc tous les essayer n'est pas un gros problème. Dans tous les cas, vous devrez généralement annoncer sur quels ports les services fonctionnent car vous voulez que les gens les trouvent! Sinon, pourquoi les dirigez-vous?
Et troisièmement, répondre à toutes les requêtes sur tous les ports peut en fait générer un peu de travail inutile. Vous voudrez peut-être passer ces cycles d'horloge ailleurs.
Ce sont donc les premières raisons qui me viennent à l'esprit. Je n'ai pas utilisé cet outil mais peut-être que d'autres personnes pensent de la même manière et c'est pourquoi il n'a pas été largement adopté.
Il y a une chose que l'auteur de ce logiciel dit que j'aime:
Au lieu d'informer un attaquant qu'un port particulier est dans un état FERMÉ ou FILTRÉ [...]
L'analyse ne va pas dire au pirate si un port est vraiment ouvert ou non. C'est une bonne idée et je l'utilise via ma configuration iptables.
Ce que je fais dans mon pare-feu, c'est de laisser l'utilisateur se connecter immédiatement à mes services habituels ou DROP le paquet. En supprimant des paquets, vous ne dites pas immédiatement à l'utilisateur si le port est ouvert ou fermé. Cela revient à tenter une connexion avec un mot de passe incorrect. Il s'arrête pendant environ 1 seconde, puis vous pouvez réessayer. Ce faisant, il peut prendre nmap. En supposant que le client attend une réponse pendant 1 seconde maximum, il faudra plus de 18 heures pour analyser les ports 65536.
Bien sûr, mon pare-feu bloque tous les ports sauf les très rares que je souhaite ouvrir (c'est-à-dire peut-être 22, 80 et 443). Donc, si vous essayez le port 5432 ou 3306, vous obtiendrez le DROP même si ces ports sont réellement ouverts.
En dehors de cela, comme beaucoup l'ont souligné, cela est plus susceptible de drainer une grande partie de votre temps processeur car les outils de piratage sont susceptibles d'essayer de se connecter à tous les ports satisfaisants (c'est-à-dire les services de type HTTP) encore et encore jusqu'à ce qu'ils décident que cela n'en vaut pas la peine ... ce qui pourrait prendre très longtemps. J'avais un ordinateur sous une attaque par relais SMTP qui a duré plus de 6 mois. C'était génial pour moi car je pouvais tester diverses choses dans mon logiciel et m'assurer qu'il fonctionnait avec une vraie attaque en direct (mais sûre).
Note à soi-même: les robots sont morts du cerveau.