• le Security-HOWTO
• Security-Quickstart-Redhat-HOWTO
• linux administration security guide
• linux security
• le forum securite
• la faq du forum sécurité
• Strategic Security Intelligence: site de Fred Cohen
• sans institute
• incidents
• insecure
• port numbers : une liste des ports utilises par les logiciels
• trojan port une liste des ports dangereux

et un magazine en français : misc

• n'installer que des logiciels de source sure (c'est à dire des packages signés)
• réduire les accès par l'utilisation d'un firewall
• limiter le nombre des services lances au démarrage(chkconfig)
• limiter les nombre des services lances via inetd/xinetd
• rendre moins bavards les services : supprimer bannières, versions …
• réduire les accès aux services via les tcp-wrappers
• utiliser les shadow password (pwconv, grpconv) pour cacher les mots de passes cryptes
• travailler le moins possible sur le user root
• se tenir informe des failles de sécurité
• garder ses logiciels a jours des patch de sécurité(voir gestion logicielle)
• utiliser ssh ou openssh pour remplacer les remote-commandes, telnet, ftp …
• appliquer bastille-linux a sa configuration
• monter ses file-systemes avec des options restrictives: par exemple
  
  • /tmp : noexec (sur debian, pb avec certains scripts de paquetages), nosuid, nodev (sur debian pb avec loadndiswrapper)
  • /home : nosuid, nodev
  • /var : nosuid, nodev (pas de noexec sur debian a cause des scripts de pre/post-installation)
• réduire les possibilités d'accès root au démarrage

linux intégre un firewall, basé, selon les noyaux, sur ipchains (2.2) ou iptables (2.4).
Voir la documentation pour plus de précisions ou iptables-tutorial.

pour fabriquer une configuration facilement (interface graphique), il y a fwbuilder

1. utiliser nmap pour détecter les ports ouverts
2. avec la commande fuser -v -n tcp num_port pour identifier le programme qui utilise un port

La licence GPL impose la disponibilité des codes sources, ce qui “facilite” la relecture et le debugage des programmes. Les Bugs sont donc plus vite trouvées et corrigées
Par contre, les rapports de bugs étant publics, il est plus facile à un pirate d'exploiter les failles de sécurité …
Il est donc indispensable de suivre les évolutions logicielles

il faut pour cela s'abonner a des listes de diffusion :

• cert
• linuxsecurity
• bugtraq

ou de s'abonner a des flux rss d'annonces des nouveautes logicielles :

• freshmeat

les commandes rlogin, rcp, rsh ne sont pas sures (les autres non plus) : au pire les mots de passe circulent en clair sur le réseau, au mieux, il est facile de tromper l'identification de l'usager : ce sont de gros trous de sécurités.

c'est d'utiliser un soft qui crypte les sessions.

• openssh : est un clone libre de ssh (du monde bsd), utiliser imperativement le protocole version 2

• Installing and Configuring OpenSSH
• OpenSSH key management : les docs ibm

1. supprimer le service sshd des démon lances : chkconfig sshd off
2. rajouter dans /etc/inetd.conf la ligne : ssh stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sshd -i
3. modifier le fichier /etc/ssh/sshd_config :
   • mettre IgnoreRhosts no
   • mettre RhostsRSAAuthentication yes
4. pour chaque user :
   1. positionner un fichier .shosts (droits 600) contenant des lignes “machine compte” (syntaxe identique au .rhosts)
   2. lancer la commande ssh-keygen
   3. transferer la clef publique (identity.pub) et la rajouter au fichier ~/.ssh/authorized_keys (droits 600)
   4. ajouter soit dans le fichier /etc/ssh/ssh_known_hosts (global) soit dans ~/.ssh/known_hosts la clef de la machine source : faire un slogin inverse pour cela

ssh (fourni par tuxfinder)
site central openssh

remplacer ses fichiers .rhosts par des .shosts (mv .rhosts .shosts; chmod 600 .shosts
ne pas oublier dans un second temps de modifier /etc/inetd.conf pour devalider totalement les remotes commandes.

il existe un projet pour sécuriser les distributions Redhat/Mandriva : bastille-linux
c'est une série de scripts perls interactifs.

Pour vérifier que son systèmes n'a pas été modifie a son insu, il faut comparer à intervalles réguliers les signatures des fichiers “sensibles” avec une base. Un article plus complet est consacré à ce sujet.

en utilisant logcheck : on peut “sortir” des logs les évenements anormaux

portsentry permet de détecter les scan de ports

ids = intrusion detection system

• snort : le plus utilisé, assez complet et complexe
• prelude : le petit nouveau qui monte …
• ossec : un autre outil libre qui n'a pas l'air mal

pour faciliter l'exploitation de snort, on peut utiliser :

• fwlogwatch : un outil d'analyse et de reaction sur iptables/snort
• snortalog : idem

le principe est simple : analyse en temps réel ( appel par fam/gamin) des log et mise en quarantaine (provisoire) reseau (firewall) des adresses IP trouvées. cela permet par exemple d'empecher toute attaque en force brute. on peut proteger tout service (ssh, apache ….) : url de fail2ban

• chrootkit : le plus connu
• Rootkit Hunter : le “petit nouveau” qui monte
• AntiExploit : utilise un module noyau (dazuko) avec un démon en machine pour une surveillance permanente

le principe est d'installer un “faux” serveur sur un port connu (ftp par exemple) et de logguer tout ce qui essaie de s'y connecter :

• deception toolkit : très élaboré : on peut simuler de façon configurable un protocole
• honeynet

le principe est d'avoir des droits d'acces aux fichiers plus fins que les droits unix. par exemple, un serveur apache doit pouvoir acceder a certains fichiers de configuration sous /etc, mais pas à /etc/shadow

Initialement developpé par Suse, et adopté par Mandriva. En 2008, le projet semble quasi arrété, mais semble repris par Ubuntu en 2009 : sa pérennité est incertaine.
concretement, il est assez facile a utiliser (test en mandriva 2008.1)

Initialement developpé par le NSA et adopté par RedHat/Fedora, il est intégré au noyau linux.
cette solution s'appuie sur l'utilisation d'acl dans les inodes. Elle me semble assez complexe a administrer, et semble lourde pour le systeme.

Initialement developpé par une société japonaise, le code vient d'être intégré au noyau linux, ce qui est un gage de stabilité et de pérennité.
cette solution est un peu comparable a apparmor, avec en plus des niveaux de fonctionnement (disabled, learning, enforcement …), associ� un environnement (la hierarchie des process appelants) C'est pour moi la meilleure solution actuelle, j'ai commencé de faire une doc d'utilisation

intégré dans le noyau linux, basé sur des acl, un peu comme selinux. pas testé

on va utiliser des méthodes un peu semblables a celles des pirates :

c'est un scanner de ports : il permet de savoir ce qui est ouvert sur une machine

pour détecter les failles de sécurité

• lsat (linux security auditing tool)
• tiger
• saint : un successeur de SATAN

la plupart des certifications se font avec un mécanisme clef publique/clef privée.
c'est utilise notamment dans :

• ssh : connexion sécurisée
• gpg : signature de packages, de mails; on peut s'enregistrer sur keyserver

Sous linux, 2 principales méthodes :

• loop-aes
• kerneli

— eric gerbier 2009/09/11 09:13