Tu peux capturer, mais surtout générer des paquets.

Ça fonctionne très bien, j’ai ça en prod pour pouvoir injecter des messages SIP non supportés par le central téléphonique du client.

Scapy utilise en dessous des raw sockets, qui te permettent de créer toi-même ton dialogue TCP ou UDP.

Par contre, les perfs sont pourries par rapport à une ouverture de socket classique, et tu dois être root pour faire ça.

Pour le port, je sais pas, j’ai jamais eu à le faire.

Pour écouter un port comme Wireshark, j’imagine qu’il faut faire des appels système très spécifiques à l’os, on ne doit pas pouvoir utiliser simplement l’objet socket de Python ?

Et oui, tu peux regarder ce qui se passe sur un port puisque des outils comme wireshark le font.

Par contre, quel est l’intérêt d’interdire d’écouter les ports en dessous de 1024 ?

C’est possible, sinon, d’avoir un second processus qui écoute ce qui passe sur un port (pour faire un analyseur de trafic, par exemple) ?

Par exemple, pour autoriser l’utilisateur courant à utiliser le port 80 :

touch /etc/authbind/byport/80

authbind python server.py

À moins que ce soit un mix entre botnet et bottleneck. Une sorte d’IA malveillante qui force l’ensemble de l’humanité à boire à la bouteille.

Par exemple pour Flask , c’ est 5000. Superstition fétiche ou contrainte hardware ?

C’est juste le port par défaut, ça se configure. Il faut prendre un port qu’on pense ne pas être trop utilisé par d’autres software, mais facile à retenir puisqu’on va taper l’adresse dans son navigateur lors du dev. Après c’est freestyle.

Pourquoi ils n’ ont pas pris 80 ?

Parce que personne n’a envie de donner les droits root à flask ou se faire chier à utiliser les astuces de cet article en mode développement.

Pourquoi rediriger les ports à écouter ?

Parce que, comme écrit dans l’article, tout port sous 1024 ne peut être écouté que si on a les droits admin.

Une illustration utile pour une bidouille de débutant sur Flask , bottle ou cherrypy ?

C’est pareil, l’article marche pour flask, bottle ou cherrpy. Mais généralement on place ces derniers derrière nginx pour des raisons de perf, donc pas besoin.

Conséquences pour la sécurité ?

Si ton exécutable est compromis, le serveur pourra écouter sur ce port. C’est exploitable, par exemple pour faire croire à tes utilisateurs qu’ils tapent toujours sur ton serveur. Mais si tu en arrives là, tu as des problèmes plus grave que ça.

@Thomas M :

Du coup n’importe quel utilisateur peut lancer python et s’accaparer le port 80.

Non, dans l’exemple on le fait sur un python d’un environnement virtuel, qui est dans le dossier d’un utilisateur. Donc les autres utilisateurs n’ont pas accès à cet exécutable.

Ah oui, et pour un site à fort trafic mieux vaut utiliser tout de même Nginx, il sera plus à même de gérer les connexions réseaux entrantes.

Tout dépend. Par exemple twisted en front tient parfaitement la charge pour un gros site et ne sera probablement jamais ton bottlenet. Cherrypy, pour un petit site, peut aussi être raisonnablement mis en front si on veut pas se faire chier.

A la limite le 8080 pourrait être utilisé https://www.grc.com/port_8080.htm mais vu que c’est destiné avant tout à un usage “local” ça ne changerait pas grand chose à par la satisfaction d’être un peu plus en phase avec les standard.

Si il n’utilisent pas le 80 je dirais:

pour la raison évoqué dans l’article (problème d’autorisation dans l’OS)
parce que c’est plus pratique pour le dev et les test si sur la même machine le 80 est utilisé par quelque chose de plus stable
car il y a pas mal de chance que le 80 soit déjà utilisé (même le 8080 par exemple, typiquement une install par défaut d’Apache et de Tomcat sur bcp de distribution Linux)
parce que souvent c’est des serveurs web peu adaptés à un accés public (sécurité, performance, multiple protocole et standard pas forcément supporté….) et qu’il sont bien mieux derrière un reverse proxy à ne gérer que le traffic applicatif sans que leur dev est besoin de se préocupper du reste

Rediriger les port ça évite le “:5000” dans l’adresse, plus pratique et surtout ça permet de tester dans des conditions plus proche du fonctionnement final (adresse généré, plus facile pour les non techniciens d’y accéder….).

Niveau sécurité un mix des truc précédents.