Serveur web debian "moribond"

Support Debian
#1

Bonjour.

Est-il possible de faire en sorte qu’un système debian n’ait aucun utilisateur ayant un accés console ou distant?
Je précise ma question; si je procède ainsi:

  • j’installe un serveur debian, avec comme users (root+mdproot) et (bob+mdpbob)
  • je le configure (apache - mysql - php - iptable et tutti quanti par exemple)
  • je mets à bob le shell par défaut /bin/false
  • depuis un liveCD, je supprime le mdp de l’utilisateur root (fichier /etc/shadow mettre un ! à la place du “haché” du mdp si j’ai bien compris?)
  • je redémarre mon serveur.

Le serveur sera opérationnel non?
Est-ce que cette démarche peut “sécuriser” un serveur contre les/certaines attaques distantes?
Pour un serveur qui peut être coupé fréquemment et qui n’a pas besoin d’être administré à distance, c’est un type de fonctionnement envisageable?

Merci de vos suggestions.

#2

Et bien il faut essayer :p!
Au fait, il n’y a pas besoin d’un live Cd pour changer le mot de passe de l’utilisateur root.

Si ton application est mal conçue, je ne vois pas en quoi la suppression du mot de passe root, pourra empêcher des injections SQLs. Si il y a une faille dans les logiciels que tu utilises, il se pourrait que l’on puisse faire exécuter des commandes à ton serveur pour obtenir ou modifier des fichiers. Tu peux aussi penser à chrooter certains services comme pour l’utilisation du protocole FTP ou TFTP, qui permettrait d’obtenir des informations.

Moi je dirais qu’il faut administrer un système pour le sécuriser. Supprimer le mot de passe root n’est pas la solution. Est-ce que tu savais qu’il était possible d’obtenir les droits root au démarrage de ton système avec un GRUB mal configuré ? Tout cela pour dire que laisser une machine à l’abandon n’est pas une solution sûre.

#3

Je dirais plutot comme thialme.
Sinon, tu te logues en root, et là, tu fais juste un chsh pour root et bob, et c’est bon, sauf que je crains que ça n’empêche les scripts s’executant en root de s’executer.
Par ailleurs, il n’est pas dit que ça empêche pour autant d’exploiter une faille et lancer un shell root d’une autre manière que le login.

#4

Merci thialme, pour ce qui est du grub, on peut effectivement passer l’option init=/bin/sh (vu dans cahiers de l’admin - debian GNU/Linux si je me souviens bien) qui donne les droits root…
Mon but est de sécuriser un serveur hébergé à la maison des attaques distantes, je suppose donc que le serveur n’est pas atteignable physiquement, (je me base sur l’intégrité de mon domicile personnel!) la modification de menu.lst à distance suppose que l’attaquant a obtenu quand même pas mal de droits sur la machine…

Maintenant pour ce qui est de l’éxécution de code arbitraire en utilisant une application web mal foutue (par exemple démarrer un serveur ssh sur la fonera, GNU linux mag mai 2007 page 76): , c’était le but de ma question. On ne se protège pas de ce type d’attaque en supprimant toute possibilité de login si j’ai bien compris. Concrètement tout processus appartient à un user et une éxécution de code arbitraire peut être faite sous l’identité du dit user c’est ça?

Pour ce qui est de placer apache et compagnie en chroot, j’y ai songe mais je suis tombé là dessus (diverses méthodes pour sortir d’un chroot):
touslesreseaux.com/forum/ind … &#entry107
je sais pas ce que ça vaut mais bon…

#5

Je pense que si on arrive à sortir d’un chroot, c’est à cause des permissions trop importantes accordées à l’utilisateur. Si les commandes unix sont restreintes un maximum à l’utilisateur, je ne vois pas comment il s’en sortira. Après, ma parole est ce qu’elle vaut, je ne m’y connaît pas bien dans la mise en place de chroot.