Happy hacking :-)

petit bloc-notes à usage interne qui peut peut-être servir à d'autres ...

Aller au contenu | Aller au menu | Aller à la recherche

Keyword - sécurité

Fil des billets - Fil des commentaires

05mai

RMLL 2008> thème sécurité + interviews + réservations

Et bien, voilà, les Rencontres Mondiales du Logiciel Libre reviennent comme tous les ans et cette fois-ci, cela se passe à Mont de Marsan, dans les Landes.

Pour ma part, je m'occupe de la coordination du thème sécurité. Au programme :

  • une session de 3 conférences sur les pare-feux (netfilter, pf et NuFW). Session à laquelle se rajoute une conférence sur la méthode MEHARI,
  • une session sur les intrusions et le fuzzing.

Ont été aussi réalisées 2 interviews :

And last but not the least, vous pouvez désormais réserver en ligne vos repas/logement pour les RMLL.

Go !

27jan

[Article MISC] reverse proxy Apache 2.2 ou l'intérêt d'un équipement en coupure

Juste un petit mot pour rappeler que le MISC de Janvier/Février 2008 est sorti avec un petit article de votre serviteur dedans.

L'objet ? une présentation de l'intérêt d'avoir un reverse proxy (ici Apache 2.2) pour mettre en ligne sur Internet une application de type boite noire pour ses collaborateurs ou partenaires.

Pourquoi un reverse proxy ?

  • capacité à maitriser la mise en ligne sans toucher au code (réécriture HTTP cookies compris, réécriture HTML)
  • capacité à ajouter des fonctionnalités sans toucher au serveur applicatif : https, authentification et habilitation LDAP par exemple
  • capacité à bloquer certaines attaques toujours sans toucher au code (puisque vous ne l'avez pas car c'est une boite noire)

Cela vaut la peine d'y réfléchir finalement, non ;-) ?

PS : pourquoi Apache ? parce que c'est libre, parce que c'est efficace en diable et parce que c'est super documenté. What else ? ;-)

17jan

Gandi Hébergement -- part 2: sécuriser le SSH de son serveur Ubuntu

Une fois acquis, votre hébergement est accessible en mode expert via ssh : ssh <votre user>@<votre adresse IP>

1. Le problème

Mais dès que vous dites cela, vous vous rendez compte que tous les robots et autres botnets peuvent en faire autant.

Vous ne me croyez pas ?

Lancez donc cette commande comme moi au bout de seulement 2 jours :

root@XXX:/home/user1# cat /var/log/auth.log* | grep 'Failed password' | grep sshd
 | awk '{print $1,$2}' | sort | uniq -c
    690 Jan 10
     58 Jan 11

Le résultat exprime le nombre d'échecs de connexion SSH par jour (sic !). En gros, Presque 700 échecs de connexion pour une machine venant d'être mise en ligne. CQFD.

Quelques faits :

  • SSH est configuré par défaut chez Gandi pour ne pas autoriser les logins root,
  • vous devez renforcer absolument le password de votre user de connexion,
  • vous devez vous prémunir des attaques de force brute.

2. La solution

Un moyen tout simple est d'utiliser le logiciel Fail2ban.

Principe :

Analyser les échecs de connexion consignés dans le fichier /var/log/auth.log et mettre à jour le firewall en bannissant pour un temps donné les adresses IP apparaissant plus de tant de fois en échec dans le fichier en question.

Prérequis :

Installer un firewall. Iptables dans notre cas.

Commande :

apt-get install iptables
apt-get install fail2ban

Configuration :

La configuration s'effectue dans le répertoire /etc/fail2ban. La configuration par défaut est dans le jail.conf que l'on peut altérer en créant le fichier jail.local. Comme cela, lors d'une update, pas d'écrasement de configuration.

Mon fichier jail.local :

[DEFAULT]
ignoreip = @IP1 @IP2 @IP3

[ssh]
maxretry = 3

Où @IPx sont les adresses sur lesquelles vous ne souhaitez pas de mise en liste noire. Cela peut être utile d'y mettre l'IP fixe de votre box domestique ou celle de votre sortie internet d'entreprise au cas où cela soit VOUS qui ayez oublié votre password ;-)

Résultat :

root@XXX:/home/user1# cat /var/log/auth.log* | grep 'Failed password' | grep sshd
 | awk '{print $1,$2}' | sort | uniq -c
    690 Jan 10
     58 Jan 11
     11 Jan 12
     14 Jan 13
      7 Jan 14
      2 Jan 15

Liste du nombre d'échecs de connexions sur SSH avec une installation de fail2ban le 11 Janvier. Spectaculaire hein ?

06mai

[Article MISC] Mon serveur DNS, mon IDS oublié ;-)

Le numéro de Mai/Juin 2007 de MISC publie un article de votre serviteur sur l'utilisation d'un serveur DNS d'entreprise en tant que sonde de détections d'intrusion. Enjoy !

Lire la suite

22juin

[Article MISC] De la sécurité d'une architecture DNS d'entreprise

Cet article est issu de l'article publié dans le numéro 23 de MISC. Ses auteurs sont Christophe Brocas (christophe.brocas@free.fr) et Jean-Michel Farin (jeanmichel.farin@free.fr). Tous droits réservés à MISC.

Ces dix dernières années, les entreprises ont vu une interconnexion toujours croissante de leurs systèmes d'informations (SI), entre eux ainsi qu'avec l'internet. Cette interconnexion s'est accompagnée d'une adoption massive de protocoles standards. Parmi ces protocoles, le DNS (Domain Name Service) affiche la double caractéristique d'être le plus systématiquement utilisé et sûrement le moins correctement surveillé.

Lire la suite