• 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 �v�nements anormaux

portsentry permet de d�tecter les scan de ports

ids = intrusion detection system

• snort : le plus utilis�
• prelude : le petit nouveau qui monte …

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 �labore : 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 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 : �a 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