Tuto Wiki sur la Sécurité des serveurs

Pause Café
#1

Salut la Compagnie!
Sur le forum du Wiki Gilles à posté ceci au sujet de la sécurité
Je pense que ce serait intéressant d’avoir un tuto complet sur le Wiki à ce sujet

Voici ce que Gilles propose:

  1. Masquer la version de apache et autres infos
  1. Interdire les installations de paquets aux autres membres du réseau. SEUL root pourra faire des install.
  1. Installer un outil permettant d’améliorer les performances des applications PHP au niveau du cache.
  1. Maintenant on va installer 2 modules complémentaire pour apache.

4-1) mod_defensible (bloque spammers et hackers et utilise les blacklists DNS ( RBL ))

Pour le paramétrer

et on relance apache : etc/init.d/apache2 restart

4-2) mod_evasive, qui protège le serveur contre les attaques DoS

Pour le paranetrer

  1. Fail2ban: son role banir les IP qui tenteront da passer par force brute

pour le paramétrer

Quant à moi, j’ajouterais bien quelque chose sur le mot de passe root, rkhunter, la configuration de ssh, supprimer les services inutiles (genre portmap nks-common inetd…) et iptables évidemment (mais je suis pas un cador comme vous avez pu vous en apercevoir…).

Concernant le module apache avec “blacklist” je ne suis pas trop chaud… J’en ai moi-même marre d’être injustement blacklisté!

J’aimerais votre avis avant de me lancer (pas sur que j’ai le temps avant fin juillet, mais au moins le débat sera lancé)…

#2

Je pense qu’il faudrait mettre sa dans la sécurisation d’un serveur apache. Pour moi la sécurisation d’un serveur c’est plus général (fail2ban par exemple, politique de mot de passe et de manière d’administrer son serveur (su ou sudo ?) etc).

#3

Oui en effet il y a bien deux parties à mettre en place :

_ la sécurisation d’un serveur
_ la sécurisation des services ( serveur web, serveur ftp, serveur jabber, etc … )

Et ce même si à fortiori le premier point aide le deuxième et pareil dans l’autre sens, il est plus facile de dissocier les différents services et de dégager les régles de sécurité générale à mettre en place.

#4

Le paquet libudns0 n’est nul part sur ma squeeze :017
Je viens de voir que ce paquet n’existe sur sur sid

Du coup le paramétrage de apache.conf plante :075

#5

Salut,

[quote=“M3t4linux”]Le paquet libudns0 n’est nul part sur ma squeeze :017
Je viens de voir que ce paquet n’existe sur sur sid[/quote]

Je n’ai pas essayé les “trucs” de Gilles.
C’est rédhibitoire, il ne faut pas l’utiliser. Le principe de la liste noire je n’aime déjà pas, alors s’il faut en plus taper dans Sid, pour un serveur…

Effectivement il faudrait commencer par la sécurité en général:

  • Accès physique à la machine
  • Mot de passe
  • Suppression des programmes inutiles
  • Configuration de ssh
  • Configuration de sudo (s’il est installé - pour ma part je ne l’installe pas sur mes serveurs, pas besoins)
  • Iptables
  • Rkhunter
  • Fail2ban (qu’il faut utiliser pour tous les services utilisés: http mail ftp…)

D’autres idées ?

#6

Salut,

[quote=“lol”]

  • Accès physique à la machine
  • Mot de passe
  • Suppression des programmes inutiles
  • Configuration de ssh
  • Configuration de sudo (s’il est installé - pour ma part je ne l’installe pas sur mes serveurs, pas besoins)
  • Iptables
  • Rkhunter
  • Fail2ban (qu’il faut utiliser pour tous les services utilisés: http mail ftp…)

D’autres idées ?[/quote]
en cas de souci,un Raid peut s’avérer utile ,un lien vers un tuto Raid ???

#7

Salut,

[quote=“terix”]Salut,
en cas de souci,un Raid peut s’avérer utile ,un lien vers un tuto Raid ???[/quote]

Ici je pensais plutôt à la sécurité réseau.
Raid aurait plutôt sa place dans une section sécurité des données. Il y a un tuto sur le wiki sur mdadm (raid1)

#8

[quote=“lol”]
D’autres idées ?[/quote]

Le port knocking :083 c’est toujours sympathique à mettre en place tout du mois expliquer la mise en place et son utilisation de tous les jours :033

Je sais pas trop, j’aurai découpé le tutoriel plutôt en trois parties, avec une partie sur al sécurisation en locale et physique de la machine, le côté distant et collaboratif et enfin les services qui tourne dessus.
Un peut comme ça :

[ul]Sécurisation de la machine locale :

[list]_ nettoyage des services et applications inutiles
_ sécurisation du/des mots de passe
_ mise ne place d’outils de surveillance de données ( rkhunter, Chkrootkit )
_ mettre en place la politique d’authentification à la machine ( openssl, openldap, pam, etc … )
_ etc …[/ul]

Sécurisation de la machine distante :

[ul]_ mise en place d’iptable
_ mise en place de ssh
_ sécurisation de l’espace de travail ( si il y a collaboration sur la machine, revoir les “PATH” )
_ mise en place de fail2ban ( configuration restrictive revue plus tard après la mise en place de chaque service )
_ etc …[/ul]

Sécurisation des services de la machines :

[ul]_ serveur de courriel ( si il y a du winwin dans le domaine penser à un antivirus, sinon de l’antispam )
_ serveur web ( selon le type de serveur renvoyer vers le tutoriel de chaque serveur )
_ serveur de irc ( pffff je sais pas trop là je sèche )
_ serveur de tchat vocale ( il y en pas des masses )
_ etc …[/ul][/list:u]

#9

Ça va d’ici quelques années on auras quelque chose.

#10

En plus de ce qui a été écrit, j’ai aussi l’excellent soft de François : “surveillance”.

EDIT :
Liaison exclusive en ssh avec clef (fil dans T&A)
Pas de sudo et un pass root en béton armé.
Toutes les commandes sont envoyée avec 'su -c commande (ou ‘commande en plusieurs mots’), ce qui ne laisse jamais root en route :wink: retour immédiat à ‘$’

#11

[quote=“MisterFreez”]Ça va d’ici quelques années on auras quelque chose.[/quote]Très encourageant… :mrgreen:

@Clochette: pourquoi séparer machine locale de machine distante ? Moi je ne fais pas de différence.
+1 pour le port knocking, mais je n’ai jamais mis en pratique…

@ Ricardo:
+1 pour surveillance
+1 pour ssh avec clef
Moi je suis d’avis de ne pas parler de sudo. Sur un serveur ce n’est pas utile (ou alors sur un serveur de tests…)

#12

Bien sûr, pas de ‘sudo’ général.
Perso, je ne l’ai mis que par fainéantise de taper une commande longue que je répétais souvent et pour laquelle j’avais fait un alias très court

ricardo serveur=NOPASSWD: /etc/init.d/apache2 restart

#13

J’aurai bien séparé les deux aspects d’une machine le côté ( le plus :pray: ) à l’abri du côté plus sensible de la machine avec la connexion distante.

Ce qui me paraissais sympathique de proposer de sécuriser une machine tournant sous Debian au minimum et peut importe son utilisation et rajouter tel des modules la possibilités de sécuriser les services que l’on veut faire tourner dessus.

Du coup une machine en générale c’est “uni-personnel” avec comme exception l’invité qui ne fais que de la navigation basique.
Après on rajoute la protection de la machine en cas d’utilisateur multiple et se connectant à distance, et ensuite on rajoute les services et le moyen de sécuriser tous ça.

Par exemple :

L’utilisation et la configuration de sudo par exemple à déjà été traité et un simple lien devrait suffire.

De même on a un article traitant de apache2 auquel on s’assure que la sécurisation soit faite de manière optimale auquel on renvoie quand on aborde de la sécurisation du serveur web ( idem avec les autres serveurs ).

Etc …

Après je sais pas trop si le fait de séparé la partie locale de la partie distante soit s’y indispensable, c’était d’après moi une façon clair de proposer une manière sécuritaire basique de gérer une Debian.

  • EDIT - bon après relecture c’est pas super claire ce que je dit.

Donc pour résumé je pensé que pour bien faire on pourrait faire tous d’abord une partie très générale applicable à toute machine et rajouter ensuite tous pleins de particularités ( en partie traité ) par de simples liens vers les dites parties.
D’où mon “embourbement” avec les exemples de sudo et de apache2

#14

Merci de m’avoir fait marrer! :wink: :005

Oui pour ta conclusion!
Et je pense que c’est une excellente idée de regrouper sur une page tout ce que nous savons - ça va c’est pas si lourd… - sur la sécurité et la façon dont nous l’appliquons - à la française… :mrgreen:

#15

bonjour à tous

quand j’ai lancé se post j’ai fait ça à l’arrache.
histoire de lancer une idée

je vois que les idées fusent de partout… super :038

Après relecture des posts il est vrai. Il faut dissocier 2 choses

Le serveur

[quote]

  • Mot de passe
  • Suppression des programmes inutiles
  • Configuration de ssh
  • Les filesystems
  • et autres trucs (sudo pas bessoin c’est un serveur)
  • etc…[/quote]

les services (à traiter cas par cas)

[quote]

  • apache
  • ftp
  • mail
  • etc …[/quote]

Pourras être traité séparément:

[quote]
le raid, (sécurité hardware). Le raid n’à jamais supprimé le sauvegarde des datas :astonished:)
et iptables (sécurité réseaux). Savoir si l’on bosse avec 1, 2, 3 interfaces ou plus, avec le wifi ou non[/quote]

#16

[quote=“lol”]Salut,
Ici je pensais plutôt à la sécurité réseau.
Raid aurait plutôt sa place dans une section sécurité des données. Il y a un tuto sur le wiki sur mdadm (raid1)[/quote]
Le sujet concerne la sécurité serveur ,et pas des données ,je pense que l’un et l’autre sont indissosiable (un simple lien même en fin de sujet “pour rappel”)
Quand je pense sécurité ,je dois être paranno ,parce que maintenant ,je pense au pot de miel (honeypot),pour tester la configuration sur le reseau ,quitte à se faire hacker une machine autant qu’elle soit virtuelle ,et limite le danger pour le système lui-même.

fr.wikipedia.org/wiki/Honeypot

#17

Ma petite phrase plus haut n’était pas anodine. A vouloir trop en faire, ça prend énormément de temps, ça éparpille complètement les contributions.

Je vous rappel qu’il existe ceci dans la documentation officiel :
debian.org/doc/manuals/secur … ex.fr.html

ainsi que

debian.org/security/

#18

Je m’en doute bien.

Toutefois je me permet de dire qu’un “tuto” sur le wiki avec les bases (ce dont nous avons parlés jusque là) serait une bonne chose.

Beaucoup se posent la question de la sécurité, peu vont aller lire les 300 pages (au moins) de debian.org/doc/manuals/secur … ex.fr.html
Qui l’a fait ici ?
Faire quelques pages avec le minimum syndical ne fera pas double emploi! :wink:

Maintenant si tu ne veux pas participer, pas de soucis, mais ce ne serait pas productif de nous décourager… :mrgreen:

#19

Je confirme ,je m’y casse la tête sur cette doc…Je suis donc pour un tuto dans l’axe de ce que tu décris :023
Après pour les questions plus precises il reste la doc officielle

#20

Mais seul root peut faire des install :

$ apt-get install foo
E: Could not open lock file /var/lib/dpkg/lock - open (13: Permission denied)
E: Unable to lock the administration directory (/var/lib/dpkg/), are you root?

Je pense qu’une page citant les principes de bases (mots de passe béton, minimum de services démarrés, principe du moindre privilège, les sauvegardes c’est bon mangez-en) serait suffisante, avec des liens vers d’autres pages pour les softs de sécurité (iptables, fail2ban, rkhunter,… ) voire des docs extérieures quand il y en a des bien faites.
Pour la configuration des services (ssh, apache), une partie « Sécurisation » dans la page du service sera plus adapté.