Sécuriser son Ubuntu-server
Par NiKo le lundi 5 février 2007, 23:00 - Ubuntu
- Lien permanent -
19 commentaires -
Tags :
L'intérêt d'avoir une Dedibox sur une classe C réputée niche à boulets, c'est qu'on est confronté à de nombreuses tentatives de hacks, DDOS et autres bruteforce quasi-quotidiennement. De quoi envisager une approche totalement paranoïaque de la sécurité du système ; voila quelques bonnes résolutions pour une Ubuntu-server.
Utilisez de vrais mots de passe
Minimum 8 caractères avec des lettres, des chiffres et de la ponctuation. Changez-en régulièrement.
Mieux, utilisez des clés SSH.
Désactiver l'accès root depuis SSH
Si quelqu'un arrivait à craquer votre accès SSH, il serait dommage qu'il arrive directement en root. Le moyen le plus simple pour éviter cela, c'est de désactiver l'accès SSH en root, en éditant le fichier /etc/ssh/sshd_config et en remplaçant la ligne :
PermitRootLogin: yes
par
PermitRootLogin: no
Changer le port SSH par défaut
Toujours dans le même fichier /etc/ssh/sshd_config, changer le numéro de port par défaut (22) par un autre :
Port 12345
Attention, ne prenez pas un numéro de port utilisé par un des autres services que vous utilisez sur le serveur (80 pour http, 25 pour smtp, 443 pour https, etc.)
Par exemple si vous déclarez le port 12345 pour SSH, vous vous connecterez ainsi sur la machine :
$ ssh user@machine.tld -p 12345
Note : Chaque modification du fichier sshd_config doit occasionner un redémarrage du service :
$ sudo /etc/init.d/ssh restart
Blacklister les IP malsaines
fail2ban est un petit utilitaire qui scanne les logs d'accès sshd et blackliste les IP depuis lesquelles émanent trop de tentatives de connexion échouées. Pour l'installer :
$ sudo apt-get install fail2ban
Plus d'infos sur la configuration et l'utilisation de fail2ban.
Interdire l'execution depuis /tmp
Le répertoire /tmp est souvent utilisé par les script-kiddies de tous poils pour y déposer leurs executables et les lancer. Une approche intelligente du phénomène est d'interdire l'execution de programme sur ce point de montage, en ajoutant la directive noexec à votre fichier /etc/fstab, comme dans cet exemple :
/dev/sda3 /tmp ext3 noexec,nosuid 0 2
Si vous ne possédez pas de point de montage pour /tmp, pas de panique : vous allez pouvoir en créer un à l'arrache 
Attention :
- Le gestionnaire de paquet
apta parfois besoin d'executer des scripts depuis cet emplacement lors de certaines mises à jour, chose que la drectivenoexecinterdit; - MySQL a parfois besoin de créer des tables temporaires à cet emplacement pour traiter des requêtes coûteuses, chose que le
nosuidinterdit.
La manipulation décrite ci-dessus n'est donc à appliquer en connaissance de cause. (voire à ne pas appliquer du tout, en fait. Hem.)
Installer un firewall
Shorewall est un firewall simple à administrer, mais pas pour autant moins efficace que les autres. L'installation se fait par un traditionnel :
$ sudo apt-get install shorewall
Un très bon tutoriel de configuration du logiciel existe, n'hésitez pas à aller y faire un tour. L'idée est dans tous les cas de tout interdire par défaut et d'ouvrir les ports un à un en fonction de vos besoins.
Vérifier régulièrement la présence de rootkits
Chkrootkit scanne votre machine et y déniche les rootkits les plus répandus. Le programme s'installe facilement via la commande :
$ sudo apt-get install chkrootkit
Et se lance de cette façon :
$ sudo chkrootkit
Vous pouvez croner l'exécution du programme quotidiennement et vous en envoyer le résultat par email, en ajoutant cette ligne dans votre crontab :
0 3 * * * chkrootkit 2>&1 | mail vous@domain.tld -s "Rapport de chkrootkit"
D'autres outils peuvent tout aussi bien faire l'affaire et peuvent être utilisés de façon complémentaires :
Ces deux outils sont disponibles dans les dépôts officiels Ubuntu et sont d'une utilisation très simple.
Note : si la commande mail est inconnue de votre système, installez le paquet mailx :
$ sudo apt-get install mailx
Emprisonnez vos programmes et utilisateurs
Chroot est un programme qui permet de littéralement emprisonner un utilisateur ou un programme dans un environnement désolidarisé du reste du système, ce qui garanti une réversibilité des dommages occasionnés.
Plus d'informations sur la commande chroot.
Encore quelques conseils de base
- Mettez régulièrement à jour votre système
- Utilisez toujours les dépôts officiels Ubuntu
- N'installez jamais de softs pour tester en oubliant de les désinstaller par la suite
- N'ouvrez de nouveaux services que si vous en avez réellement besoin
- Surveillez vos logs
- Surveillez régulièrement les process système
- Monitorez votre machine, surveillez les comportements anormaux
- Ne donnez jamais vos mots de passe
- Touchez du bois
Les commentaires bouillent d'impatience de recevoir vos remarques, suggestions et contributions.
Edit : Prise en compte de certains commentaires judicieux.
Edit 2 : JJL pose une vraie question : Ubuntu est-elle prête pour le serveur ? Sachant que les paquets Universe contenant des choses comme Trac ou Bacula ne sont pas maintenues au niveau patches de sécurité, cela laisse songeur...










19 commentaires (Ajouter un commentaire)
j'aurais des conseils différents :
+ le noexec sur le /tmp ça sert pas à grand chose, ça se contourne très facilement (de plus quid du /var/tmp?)
+ installer logcheck
+ install arpwatch car l'arpspoofing sur les dedibox c'est assez simple à faire aussi
+ netstat est ton ami
+ un firewall n'est pas vraiment utile suffit de savoir ce qu'on fait tourner
+ la directive AllowGroup dans sshd_config devrait être fortement envisagé
+ rkhunter en plus de chkrootkit, + d'autres solutions de monitoring (tiger, etc...)
+ une debian à la place d'une ubuntu
+ chrooter ses utilisateurs?
+ et plus encore ....
M.
conseil #1 utiliser un vrai truc sécurisé : comme OpenBsd ... ok je sais je sors mais pourtant c'est le bien et c'est mieux qu'UbuntU ^^
Malheureusement, même tout ça ne suffit pas à contrer les attaques par injection de code si on héberge des sites codés n'importe comment donc chrooté Apache serait un plus ainsi que l'installation d'un IPS (logcheck va bien en coulpe avec logwatch)...
Chrooter pas chrooté... (désolé, c'est tôt
)
un truc tout simple que je fais régulièrement aussi ... suivant les choses qu'on installe, un petit nmap de loin pour voir ce qu'on a d'ouvert sur le monde... Surtout pour voir s'il y en a plus que de raison !
Mais merci pour ce billet ! superbe ... je découvre d'autres de tes billets a travers lequel j'ai du passer je ne sais comment ! Cool =)
"Touchez du bois"
Le grand Asimov (Isaac) disait "touchons du plastique !".
Ne pas oublier de redémarrer sshd après avoir changé le port, sinon ça sert pas trop
root c'est le mal (sauf quand on a foiré son /etc/sudoers ok)
Je connaissais pas fail2ban, intéressant !
Autre conseil : pensez à mettre à jour tous les serveurs du parc si vous en avez plusieurs connectés, surtout si certains ont des clés vers les autres (vécu inside :/).
... installer des softs d'analyse des logs, histoire d'avoir un rapport synthétique tous les matins de ce qui s'est passé sur la machine. Le tout est bien sûr de prendre le temps tous les matins de lire ce genre de mail passionnant...
Amha, le risque le plus courant est les tentatives d'attaque du serveur web. On n'est jamais à l'abri d'un exploit "0 day" dans dotclear ou autre. D'où l'utilité de chrooter Apache par exemple, et d'installer des petits trucs tout simple pour blacklister les script-kiddies. Des directives dans ce genre dans un htaccess peuvent être utiles:
je n'ai pas de dedibox mais il serait peut-être temps que je devienne un peu parano et que je suive te conseils : j'ai tendance à laisser tourner mon ordi à la maison avec serveur ssh pour pouvoir m'y connecter... d'ailleurs comment sait-on qu'on est victime de tentatives d'intrusion sous Ubuntu ??
Voilà mon petit conseil à moi pour laisser ssh sur le port 22 sans trop de problèmes:
/sbin/iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
/sbin/iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 300 --hitcount 3 -j DROP
Cela limite les tentatives de connexions à 3 et bloque l'ip pendant 10 min si elle n'a pas reussit à s'authentifier.
Wildmary> Les fichiers de logs situés dans /var/log sont une aide précieuse. Comme énoncé plus haut, des outils comme netstat (que j'associe systématiquement à lsof) ou ps sont précieux pour remonter à l'origine du mal.
merci
juste une petite remarque, tu devrais corriger ta phrase (au moins rajouter le "pas" manquant) :
> Attention, ne prenez un numéro de port utilisé par un des autres services que vous utilisez sur le serveur (80 pour http, 25 pour smtp, 443 pour https, etc.)
j'ai mis un moment à comprendre "ne prenez PAS un numéro de port déjà utilisé par un autre service (80 etc." x_x (3 ou 4 lectures mais pour une fois j'ai fini par comprendre avant de poser la question
en lieu et place de shorewall, j'utilise arno-iptable-firewall.
En plus de logcheck, il y a aussi logwatch.
bon résumé sinon, va falloir que je pique 2/3 trucs
Merci bien pour ce qui semble etre de bonnes bases pour la sécurité d'un serveur. Et pas seulement valable pour ubuntu je pense, mon imac va passer à la moulinette billet-de-niko-pour-pas-que-les-mechants-script-kiddies-y-viennent-trifouiller-dans-ma-machine.
Le pb avec /tmp en noexec, c'est qu'apt y exécute des scripts pendant certaines maj.
Exact. De plus
nosuidempêche MySQL de créer certaines tables temporaires. Je suis en train de me dire que cette manipulation n'est finalement pas une si bonne idée que ça.J'édite le billet en conséquence.
Pour le chroot, tu enfermes au niveau d'apache je présume ou de tout (ssh, ftp, mail, home des users) ?
NiCoS> Apache dans un premier temps, bien sûr.
Changer le port de SSH ? Bof... un nmap -vvA donnera le bon port.
Ne pas oublier non plus le manuel de sécurisation de Debian http://www.debian.org/doc/manuals/s... qui, pour pas mal de choses, s'applique aussi à Ubuntu.
La discussion continue ailleurs
Sécuriser son serveur ssh : Denyhosts
Denyhosts est un programme qui bloque les attaques ssh en ajoutant les IP dans /etc/hosts.deny. Denyhosts informe aussi les administrateurs (par mail) des attaques d'utilisateurs ou de login suspicieux....