Pourquoi est-il préférable d'utiliser les ports 20 et 53 comme ports source lors de la numérisation de port?
J'ai lu que si un serveur est à l'intérieur d'un DMZ derrière un pare-feu sans état, c'est une bonne idée d'utiliser les ports 20 et 53 comme ports source lors de la recherche de ports. Pourquoi est-ce une bonne idée? Je suppose que le pare-feu ne filtrera probablement pas les données FTP et DNS?
Vous avez bien deviné.
Selon le Nmap Guide de référence :
--source-port <portnumber>; -g <portnumber>(Numéro de port de la source d'usurpation)Une mauvaise configuration étonnamment courante consiste à faire confiance au trafic basé uniquement sur le numéro de port source. Il est facile de comprendre comment cela se produit. Un administrateur mettra en place un nouveau pare-feu brillant, pour être inondé de plaintes d'utilisateurs ingrats dont les applications ont cessé de fonctionner. En particulier, le DNS peut être interrompu car les réponses DNS UDP provenant de serveurs externes ne peuvent plus accéder au réseau. FTP est un autre exemple courant. Dans les transferts FTP actifs, le serveur distant tente d'établir une connexion avec le client pour transférer le fichier demandé.
Il existe des solutions sécurisées à ces problèmes, souvent sous la forme de proxys au niveau de l'application ou de modules de pare-feu d'analyse de protocole. Malheureusement, il existe également des solutions plus simples et peu sûres. Notant que les réponses DNS proviennent du port 53 et du FTP actif du port 20, de nombreux administrateurs sont tombés dans le piège de simplement autoriser le trafic entrant de ces ports. Ils supposent souvent qu'aucun attaquant ne remarquerait et n'exploiterait de tels trous de pare-feu. Dans d'autres cas, les administrateurs considèrent cela comme une mesure provisoire à court terme jusqu'à ce qu'ils puissent mettre en œuvre une solution plus sécurisée. Ensuite, ils oublient la mise à niveau de sécurité.
Les administrateurs réseau surchargés ne sont pas les seuls à tomber dans ce piège. De nombreux produits ont été expédiés avec ces règles non sécurisées. Même Microsoft a été coupable. Les filtres IPsec fournis avec Windows 2000 et Windows XP contiennent une règle implicite qui autorise tout le trafic TCP ou UDP du port 88 (Kerberos). Dans un autre puits -cas connu, les versions du pare-feu personnel Zone Alarm jusqu'à 2.1.25 autorisaient tous les paquets UDP entrants avec le port source 53 (DNS) ou 67 (DHCP).
ne réponse de 2005 dans Seclists.org fournit une citation d'une version précédente du Guide de référence:
--source_port <portnumber>Définit le numéro de port source utilisé dans les analyses. De nombreuses installations naïves de pare-feu et de filtrage de paquets font une exception dans leur ensemble de règles pour permettre aux paquets DNS (53) ou FTP-DATA (20) de passer et d'établir une connexion. Évidemment, cela subvertit complètement les avantages de sécurité du pare-feu puisque les intrus peuvent simplement se faire passer pour FTP ou DNS en modifiant leur port source. De toute évidence, pour une analyse UDP, vous devez d'abord essayer 53 et TCP devraient essayer 20 avant 53. Notez que ce n'est qu'une demande - nmap ne l'honorera que si et quand il le peut. Par exemple, vous ne pouvez pas faire TCP ISN échantillonnant tout d'un port Host: à un port Host: donc nmap change le port source même si vous avez utilisé cette option. Il s'agit d'un alias pour le plus court, mais plus difficile à retenir,
-goption.