Securité sur un server Linux
Bonjour aux Linuxiens,
Ayant un niveau "débutant" avec les systèmes *ix/ux, je me permet de vous solliciter.
J'aimerai une sorte de "best-practice" au niveau de la sécurité pour un server.
Voilà à quoi j'ai pensé:
- Anti-virus: ClamAV
- Rootkit detector: rkhunter
- File integrity: Tripwire
J'ai également vu qu'il y avait Lynis comme tool d'audit, mais je ne connais pas du tout. J'ai aussi planifier d'utiliser Nessus périodiquement comme vulnerability scanner.
Que pensez-vous de ces tools? Lesquels me conseillez-vous? Sont-ils fiables?
Merci d'avance pour toute aide, remarques, etc.
Ayant un niveau "débutant" avec les systèmes *ix/ux, je me permet de vous solliciter.
J'aimerai une sorte de "best-practice" au niveau de la sécurité pour un server.
Voilà à quoi j'ai pensé:
- Anti-virus: ClamAV
- Rootkit detector: rkhunter
- File integrity: Tripwire
J'ai également vu qu'il y avait Lynis comme tool d'audit, mais je ne connais pas du tout. J'ai aussi planifier d'utiliser Nessus périodiquement comme vulnerability scanner.
Que pensez-vous de ces tools? Lesquels me conseillez-vous? Sont-ils fiables?
Merci d'avance pour toute aide, remarques, etc.
A voir également:
- Securité sur un server Linux
- Question de sécurité - Guide
- Votre appareil ne dispose pas des correctifs de qualité et de sécurité importants - Guide
- Mode securite - Guide
- Cybera server - Télécharger - Divers Réseau & Wi-Fi
- Ps3 media server - Télécharger - Divers Réseau & Wi-Fi
3 réponses
Personnellement j'ai utilisé rkhunter par le passé et ça marche bien. Côté antivirus je ne suis pas trop au fait de ces questions car c'est plutôt une problématique qui concerne les gens sous windows (jamais rencontré de virus sous linux en 10 ans, mais il parait que ça existe :p).
Quelques idées en parallèle aux pistes que tu évoques pour sécuriser ton serveur, je te laisse faire le tri :-)
1) Attention à l'authentification. Par exemple, si ton serveur est accessible en ssh, une authentification par clé est toujours préférable à une authentification par mot de passe. Autres exemples : utiliser des certificats X509 en mysql, inciter les gens à utiliser GPG avec leurs mails etc...
2) Attention à qui peut se connecter. Cela se gère de trois manières (éventuellement cumulées)
a) La manière dont tu vas gérer les ports ouverts via ton pare-feu (par exemple via une surcouche comme ufw ou directement via iptables).
b) La manière dont tu configures bind-address de tes serveurs. Par exemple par défaut, un serveur mysql est bindé avec 127.0.0.1 (ce qui signifie qu'il n'autorise qu'un client local à la machine à s'y connecter). Il faut bien sûr avoir la politique la plus "stricte" possible. Tu peux voir comment sont bindés tes serveurs avec la commande :
c) La manière dont tu configures ta politique d'accès au niveau du logiciel (du démon) lui-même. Certains serveurs (apache, munin ...) sont capables eux mêmes de gérer des access list pour autoriser un client ou nom à se connecter. Ça peut être pas mal de mettre un 2e rempart à ce niveau.
3) Attention à chiffrer les communications. Par exemple il faut préférer rsh à ssh (et donc éviter d'installer un serveur telnet au profit d'un serveur ssh), dans la mesure du possible préférer https et imaps sur http ou imap etc...
4) Monitorer ça machine (avec munin, nagios etc...) permette de relever des activités louches. On peut imaginer mettre en place log2mail sur /var/log/auth.log pour détecter quand quelqu'un tente de bourriner pour s'authentifier sur ta machine etc...
Bonne chance
Quelques idées en parallèle aux pistes que tu évoques pour sécuriser ton serveur, je te laisse faire le tri :-)
1) Attention à l'authentification. Par exemple, si ton serveur est accessible en ssh, une authentification par clé est toujours préférable à une authentification par mot de passe. Autres exemples : utiliser des certificats X509 en mysql, inciter les gens à utiliser GPG avec leurs mails etc...
2) Attention à qui peut se connecter. Cela se gère de trois manières (éventuellement cumulées)
a) La manière dont tu vas gérer les ports ouverts via ton pare-feu (par exemple via une surcouche comme ufw ou directement via iptables).
b) La manière dont tu configures bind-address de tes serveurs. Par exemple par défaut, un serveur mysql est bindé avec 127.0.0.1 (ce qui signifie qu'il n'autorise qu'un client local à la machine à s'y connecter). Il faut bien sûr avoir la politique la plus "stricte" possible. Tu peux voir comment sont bindés tes serveurs avec la commande :
netstat -ntlp
c) La manière dont tu configures ta politique d'accès au niveau du logiciel (du démon) lui-même. Certains serveurs (apache, munin ...) sont capables eux mêmes de gérer des access list pour autoriser un client ou nom à se connecter. Ça peut être pas mal de mettre un 2e rempart à ce niveau.
3) Attention à chiffrer les communications. Par exemple il faut préférer rsh à ssh (et donc éviter d'installer un serveur telnet au profit d'un serveur ssh), dans la mesure du possible préférer https et imaps sur http ou imap etc...
4) Monitorer ça machine (avec munin, nagios etc...) permette de relever des activités louches. On peut imaginer mettre en place log2mail sur /var/log/auth.log pour détecter quand quelqu'un tente de bourriner pour s'authentifier sur ta machine etc...
Bonne chance
Hello,
Merci pour toutes ces précisions/conseils, je vais m'en inspirer!
Sinon, connais-tu un bon site qui définit un concept "hardening" pour différents servers linux (apache-tomcat; firewall; database; ...)?
Merci encore
Elpens
Merci pour toutes ces précisions/conseils, je vais m'en inspirer!
Sinon, connais-tu un bon site qui définit un concept "hardening" pour différents servers linux (apache-tomcat; firewall; database; ...)?
Merci encore
Elpens
Après un tour sur wikipedia :
https://fr.wikipedia.org/wiki/Durcissement_%28informatique%29
... ça me laisse penser que le but est d'installer le moins de paquets possible. Un certain nombre de suggestions sont évoquées dans cet article. Ça peut être un point de départ à ta recherche.
Avec apt c'est normalement sensé être plus ou moins le cas car les paquets installés explicitement (par tes soins) et ceux installés en cascade (par dépendance) sont marqués différemment au niveau de dpkg. Cela signifie qu'apt conservera (si tu utilises aptitude ou apt-get autoremove) uniquement ce que tu as explicitement installé et ses dépendances. À noter que deborphan peut également aider.
De manière générale :
- on essaye d'installer le moins de truc possible sur une machine pour limiter les risques (typiquement un mode graphique)
- de définir une politique d'accès (réseaux, droits...) aussi stricte que possible (ne permettre que ce qui est légitime, interdire le reste). Ça rejoint notamment certaines problématiques (pare-feu, bind address, mais également tout ce qui concerne les droits) que j'évoquais dans mon précédent message.
Bonne chance
https://fr.wikipedia.org/wiki/Durcissement_%28informatique%29
... ça me laisse penser que le but est d'installer le moins de paquets possible. Un certain nombre de suggestions sont évoquées dans cet article. Ça peut être un point de départ à ta recherche.
Avec apt c'est normalement sensé être plus ou moins le cas car les paquets installés explicitement (par tes soins) et ceux installés en cascade (par dépendance) sont marqués différemment au niveau de dpkg. Cela signifie qu'apt conservera (si tu utilises aptitude ou apt-get autoremove) uniquement ce que tu as explicitement installé et ses dépendances. À noter que deborphan peut également aider.
De manière générale :
- on essaye d'installer le moins de truc possible sur une machine pour limiter les risques (typiquement un mode graphique)
- de définir une politique d'accès (réseaux, droits...) aussi stricte que possible (ne permettre que ce qui est légitime, interdire le reste). Ça rejoint notamment certaines problématiques (pare-feu, bind address, mais également tout ce qui concerne les droits) que j'évoquais dans mon précédent message.
Bonne chance
