Sécurité générale

Guide de sécurité (pris sur http://www.linux-france.org/prj/inetdoc/telechargement/tutoriel.securite.pdf)

Philosophie

Il n'est pas possible d'obtenir une machine 100% sécurisée. La seule solution pour y parvenir consiste à débrancher tous les cables réseaux... Un vrai hacker réussira toujours à pénetrer une machine, il lui suffira d'y mettre le temps.

Par contre, il est toujours possible d'augmenter le niveau de sécurité d'une machine. Chaque petit détail, même le plus infime, qui restreint les accès ou améliore la sécurité de la machine contribue à diminuer les chances de pénétration de la machine par un hacker. En particulier, on peut facilement se prémunir contre les scripts kiddies qui executent des programmes de hacks trouvés sur le web sans rien comprendre à ce qui se passe réèllement derrière. Ce genre de hack répresente quand même une partie non négligeable des pénétrations de machines...

Regles

• Ne jamais mettre en place un serveur MySQL sans password root
• Masquer le plus possible les versions et les options de configuration des services en fonction sur les machines. Certains hackers se contentent de scanner des adresses IP au hasard et de rechercher un service qui s'annonce avec une version connue pour être vulnérable.
• Par exemple, pour la configuration apache, utiliser :
  • Signature Off
  • ServerTokens ProductOnly
• Pour PHP, placer dans le php.ini :
  • expose_php = Off
• Pour les sites webs, il faudrait pour bien faire que le serveur apache n'ait les droits d'écriture nulle part, et particulièrement aucun droit d'écriture dans le document-root des sites webs. Donner les droits d'écriture à apache permet aux hackers d'uploader des scripts php ou des cgi perl et ainsi d'excuter n'importe quelle commande sur la machine. De la à ouvrir un shell, puis passer root, il n'y a aucune difficultée pour quelqu'un possèdant un minimum de connaissances... En général, tout serveur web ayant besoin de stocker des données devrait le faire dans une base sql.
• FreeBSD: Mettre dans /etc/sysctl.conf les 2 lignes suivantes : net.inet.tcp.blackhole=1 et net.inet.udp.blackhole=1 afin que le kernel n'envoie jamais de RST / port unreachable pour les ports fermés. Cela ralentit les ports scans de base.
• MySQL: Il faudrait un mot de passe root MySQL différent sur CHAQUN de nos serveurs SQL. C'est lourd, mais tant pis !
• MySQL: Pour les users/passwords utilisés pour les scripts (ClaraSync, Réplication...), ne JAMAIS réutiliser le même password sur des machines différentes. Une machine, Un user, Un Password. De plus comme il s'agit de passwords qu'on ne tapera jamais manuellement, autant prendre de bonnes chaines aléatoires de 16 caractères.
• Passwords : Les scripts (en général SQL) qui comportent des passwords en clairs ne doivent évidemment PAS être lisibles par tout le monde !!
• MySQL : NE JAMAIS DONNER TROP DE DROITS AUX USERS ! Il est evidemment plus simple/rapide de donner tous les droits à un user quand on le créé - toujours dans l'urgence - mais c'est une TRES MAUVAISE IDEE ! -> Passer en revue l'intégralité de nos users sur chaque serveur MySQL et vérifier si les droits sont adaptés ! (à certains endroits des users ont les droits MySQL root ...)
• NFS : Ne JAMAIS faire en sorte que UID 0 sur un client == UID 0 sur le serveur NFS ! (option root= dans le fichier export pour le NetAPP). Ok, on ne peut plus faire de modif sur les webs ou autre en se logguant en root sur n'importe quel machine cliente - mais les hackers non plus ne peuvent plus !
• NFS : Toujours monter les partages NFS (Netapp, filers...) sur les clients avec les options nosuid, noexec si possible, et nodev.
• clés SNMP: longue clé, en RO avec un subnet autorisé pour le scan
• Stocker les mots de passe crypté avec une clé de hachage (également connues sous le nom de « fonctions à sens unique », ces fonctions sont faites pour qu'il soit difficile de

retrouver leur entrée (le mot de passe en clair) à partir de leur sortie (le mot de passe haché).Il ne faut donc pas utiliser une fonction de hachage prévue pour traiter rapidement de grandes quantités de données (MD5, SHA-512…) mais des algorithmes prévus pour être lents (bcrypt…), sauf si on a énormément de d'authentification

• Avoir un script de md5sum global qui envoie un mail dès qu'un fichier à changer (vérifier principalement : /sbin#/bin#/lib#/usr/bin#/usr/lib#/usr/sbin#/usr/local/bin#/usr/local/sbin#

/etc/rc.d#/etc/init.d)

• Avoir un script qui regarde les ports en écoute et qui envoie un mail dès qu'un nouveau port et en écoute

Packages

Les packages suivant (sous debian) permettent ou facilitent le maintien de la sécurité :

Debsums : md5 global du system
Integrit : md5 amélioré
Logcheck : surveillance des journaux
Rkhunter : detecte les rootkits, portes dérobées et exploits