1 votes

Nmap fonctionne plus lentement en tant que root qu'en tant qu'utilisateur normal

Je travaille sur un bash script pour permettre la détection automatique et le contrôle à distance des enregistreurs de données propriétaires de ma société. Les enregistreurs exécutent une version personnalisée de linux et sont essentiellement des pis ou des arduinos puissants.

Le port Ethernet des appareils est configuré de telle sorte que lorsqu'il est branché sur le réseau, il reçoit un bail dhcp. Afin de détecter les périphériques, je surveille /var/lib/dhcp/dhcpd.leases sur ma machine locale. Pour chaque entrée unique, je fais un balayage de ports pour tester le statut du serveur ssh en utilisant nmap . Pour permettre un lancement automatique de ce script, il est appelé depuis /etc/rc3.d/rc.local et est donc lancé par root au démarrage. C'est là que les choses deviennent étranges.

Pour s'assurer que nous pouvons toujours détecter les nouvelles connexions, le fichier dhcpd.leases est vérifié dans une boucle infinie. Nous voulons également maintenir une faible empreinte système, donc afin de réduire le temps de chaque itération de la boucle, nous imposons un petit délai d'attente à notre fichier nmap . Voici la ligne exacte utilisée :

nmap --max-retries=1 -p 22 --host-timeout=50ms $ip_address

Lorsqu'elle est exécutée en tant qu'utilisateur normal, cette ligne fonctionne de manière incroyablement cohérente, mais en tant que root, je dois augmenter le timeout à 600ms pour obtenir des résultats positifs constants. Je l'ai testé en utilisant le time et voici un résultat habituel (fait avec un délai de 600ms) :

Starting Nmap 6.40 ( http://nmap.org ) at 2014-12-19 09:41 EST
Nmap scan report for 192.168.53.101
Host is up (0.00039s latency).
PORT    STATE SERVICE
22/tcp  open  ssh

Nmap done: 1 IP address (1 host up) scanned in 0.05 seconds

real    0m0.059s
user    0m0.043s
sys     0m0.004s

Voici le résultat pour la même chose, mais en étant connecté en tant que root :

Starting Nmap 6.40 ( http://nmap.org ) at 2014-12-19 09:48 EST
Nmap scan report for 192.168.53.101
Host is up (0.00035s latency).
PORT    STATE SERVICE
22/tcp  open  ssh
MAC Address: 00:04:D1:0B:03:EC

Nmap done: 1 IP address (1 host up) scanned in 0.55 seconds

real    0m0.580s
user    0m0.056s
sys     0m0.008s

Avez-vous une idée de ce qui pourrait causer ce temps supplémentaire et comment l'éviter ? D'après quelques recherches préliminaires, je peux voir que root fonctionne avec certains paramètres par défaut auxquels les autres utilisateurs n'ont pas accès. Comment puis-je m'y prendre pour reproduire les conditions de nmap exécuté par un utilisateur normal ?

En outre, ce projet est exécuté sur une machine Ubuntu 14.04 LTS.

0voto

JorganPubshire Points 111

Après une recherche plus approfondie, j'ai trouvé quelque chose d'intéressant dans la section MISC de la page de manuel. Il existe une option pour --unprivileged qui force le fonctionnement en tant qu'utilisateur normal, même en tant que root. Cette méthode effectue beaucoup moins d'opérations et fournit moins d'informations en retour, mais si tout ce que vous faites est de vérifier la présence de ssh sur le port 22, elle le fait aussi rapidement que possible.

0voto

Felipe Salazar Points 135

Je ne suis pas sûr de ce qui pourrait causer la différence entre les deux parcours, mais j'ai quelques idées pour la cohérence et la vitesse qui pourraient aider. Tout d'abord, voici les différences d'opérations entre les scans root et non-root avec les options que vous avez sélectionnées :

  • Les scans non privilégiés (non root) utiliseront une paire de TCP connect() pour déterminer si l'hôte est actif ; les scans de la racine envoient une requête ARP et reniflent le réseau pour obtenir la réponse. La demande ARP devrait être plus rapide, puisque les appels de connexion nécessitent l'intervention du système d'exploitation :
    1. une requête ARP, ou au moins une consultation du cache ARP
    2. au moins un autre aller-retour pour obtenir une réponse de la cible
  • Les scans non-root utiliseront un TCP complet. connect() pour analyser le port 22, et doit fermer le socket une fois l'analyse terminée ; les analyses de la racine effectueront une demi-serrure de main, en comptant sur le système d'exploitation pour fermer la connexion "en arrière-plan".

Ainsi, avec ces options, un scan privilégié sera généralement plus rapide. Cependant, avec une connexion réseau à très faible latence, il est possible que la configuration des différents écouteurs PCAP ralentisse un peu l'analyse de la racine. Mais ce n'est probablement pas l'origine de votre retard.

Vous pouvez accélérer votre analyse en sautant certains des éléments suivants phases de balayage dont vous n'avez pas besoin. Essayez d'ajouter le -n pour ignorer la recherche inversée du nom ( qui ne compte pas dans le délai d'attente de l'hôte, d'ailleurs ! ). Ou si vous connaître la cible est présente et que vous souhaitez uniquement vérifier la réponse du port 22, ajoutez l'élément -Pn pour sauter la phase de découverte des hôtes.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X