samedi 04 octobre
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Derniers journaux de yeupou :

Journal : xinetd assure !

Posté par gnap gnap (page perso, ) le 28 février 2006
0
Sur Gna!, nous fournissons pas mal de services basés sur SSH.

Or, nous constations pas mal de trucs pénibles ingérables avec SSH seul (multiples tentatives de connexion sur des dicos de login en quelques secondes), qui en soit ne posais pas vraiment problème mais bouffait petit à petit pas mal de ressources.

Ben là solution magique est xinetd. Nous utilisions déjà xinetd pour quasiment tout le reste (multiples avantages : limite du nombre de connexion par IP, limite du nombre de connexion par seconde, fermeture de l'accès en cas de charge trop élévée, différente politiques en fonction de l'émetteur, banissement par /etc/hosts.deny).

Théoriquement, il est dit qu'utilise SSH par xinetd fait perdre en perf plutôt que l'utiliser directement. Peut-être. Mais depuis l'autre jour, tout passe par xinetd et la charge est divisée par deux, réellement. Tout simplement parce que nos serveurs sont devenus suffisement connus pour que certains pénibles deviennent suffisement pénibles et que des règles de xinetd soit l'outil idéal pour leur dire au revoir.

Mis à part ça, pour ceux qui font tourner un serveur de courriel public, vous pouvez jetter un oeil à https://gna.org/p/seeyoulater que j'ai écris l'autre jour pour éviter que certains pénibles dont l'IP est bloquée via des DNSBL fiables, ou qui envoie des courriels vers des adresses qui ne correspondent à rien (dans les archives de gna, nous publiant les message-id des courriels, c'est pratique pour faire des recherches avec google par message-id : ça produit plein d'adresse qui ne correspondent à rien telles que 213131313135@subversion.gna.org, dont les spambots rafolent) repointent leur museau trop souvent dans les heures qui suivent (multipliant inutilement les requêtes vers les DNSBL), en mettant les IP logguées sous la forme ++BAN:IP++ dans hosts.deny pour un temps défini.

L'outil est prévu pour fonctionner avec Exim mais devrait fonctionne avec n'importe quel serveur.

Tout ça pour dire que si vous faites tourner des serveurs publics, tournez vous vers xinetd, vous allez gagner du temps !

> Lire le journal (13 commentaires, moyenne: 2,8).  

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Méthode avec netfilter

Posté par antonus () le 28/02/2006 à 14:59. (lien). Évalué à 3.

pour les pénibles, j'utilise ça : http://blog.blackdown.de/2005/02/18/mitigating-ssh-brute-for(...)

  • [^]Re: Méthode avec netfilter

    Posté par TuxPierre () le 28/02/2006 à 15:23. (lien). Évalué à 6.

    Et pour ceux qui utilisent autre chose que shorewall : http://www.debian-administration.org/articles/187

    Sinon, il faut noter l'existence d'un petit utilitaire fort sympatique : fail2ban. Permet de bannir pendant un certain temps et apres un certain nombre de tentatives... Et il ne concerne pas que ssh.

    • [^]Re: Méthode avec netfilter

      Posté par Antoine Jacquet (page perso, ) le 28/02/2006 à 16:40. (lien). Évalué à 1.

      Génial, c'est exactement ce que je cherchais, un filtrage au niveau iptables.
      Merci !

      • [^]Re: Méthode avec netfilter

        Posté par mathieu mathieu (Jabber id, page perso, ) le 28/02/2006 à 20:33. (lien). Évalué à 1.

        il exite aussi un script python qui s'appelle failtoban...
        cela insere au bout de 5 echecs dans une table avec la règle -j drop!
        Le blocaque est annulé au bout d'un temps paramétrable
        Couplé avec portsentry, c'est très efficace!

        • [^]Re: Méthode avec netfilter

          Posté par Adrien BUSTANY (Jabber id, page perso, ) le 28/02/2006 à 21:00. (lien). Évalué à 1.

          Aussy denyhosts dans le même genre, très efficace aussi :)

          --
          madcat

Pour les BSDistes

Posté par gaston () le 28/02/2006 à 15:08. (lien). Évalué à 3.

Une solution réservée aux bsdistes qui répond bien à ce problème (attaques bruteforce sur un service), il y a une fonctionnalité intéressante de pf (packet filter) qui permet de bloquer le nombre de connexions maximum par seconde au niveau réseau, voir
http://beta.gcu.info/1727/2000/01/01/Bloquer-les-attaques-br(...)

  • [^]Re: Pour les BSDistes

    Posté par TuxPierre () le 28/02/2006 à 15:33. (lien). Évalué à 3.

    Oui je confirme... C'est vraiment une tres bonne fonctionnalite. Elle est issue a la base de PF du projet OpenBSD. PF a ete porte sur FreeBSD mais pas sur netBSD (a ma connaissance).
    Cependant dans l'exemple donne dans ton lien, l'adresse IP est stockée dans une table en memoire et du coup toute tentative de connexion venant de cette IP est systematiquement refusee.. Donc grosso modo, la machine devient "invisible" pour cette IP.
    Mais si on ne rajoute pas un petit script pour purger de temps en temps cette table, l'adresse IP va y rester "definitivement" (sauf en cas de reboot ou de flush manuel bien evidemment).

  • [^]Re: Pour les Linuxiens

    Posté par Florent Bayle (page perso, ) le 28/02/2006 à 17:05. (lien). Évalué à 7.

    Pour les Linuxiens, il est possible de faire la même chose ave iptables :

    iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
    iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_WHITELIST
    iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j ULOG --ulog-prefix SSH_brute_force
    iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP

    Si on a plus de 4 tentatives de connexions en moins d'une minute, on bloque l'ip pendant une minute.

    • [^]Re: Pour les Linuxiens

      Posté par Olivier Jeannet () le 07/03/2006 à 00:18. (lien). Évalué à 2.

      Si on a plus de 4 tentatives de connexions en moins d'une minute, on bloque l'ip pendant une minute.

      Très intéressant, je suis preneur, mon serveur se prend des attaques régulièrement. Je fais le DROP à la main avec une seule règle, quand je suis devant mon ordi et que je vois qu'il y a du trafic anormal :
      iptables -A INPUT -i eth0 -s 11.22.33.44 -j DROP .

      Je n'ai pas le mot-clef --rttl dans mon "man" (j'ai un noyau 2.6.12), peux-tu me dire ce qu'il fait ?
      Et comment est-il précisé que le blocage s'arrête au bout d'une minute ?

      Sinon j'ai vu une légère simplification de tes 4 lignes, mais je ne sais pas si ça gère le déblocage :
      iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
      iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP

Changer le port de SSH

Posté par neriki (page perso, ) le 28/02/2006 à 15:29. (lien). Évalué à 2.

Chez moi, ça a suffit pour retrouver un auth.log normal. :o)

  • [^]Re: Changer le port de SSH

    Posté par TuxPierre () le 28/02/2006 à 15:36. (lien). Évalué à 2.

    C'est clair que ca suffit amplement en ce qui concerne les differents vers qui circulent en ce moment.
    Une autre methode tres efficace aussi est de n'autoriser que les clés publiques... du coup ca degage quasiment tout le mode aussi.

    • [^]Re: Changer le port de SSH

      Posté par gnap gnap (page perso, ) le 28/02/2006 à 15:56. (lien). Évalué à 4.

      Dans le cas de Gna!, aucune connexion par mot de passe n'est autorisée. Par contre, ne pas utiliser les ports classiques ne ferait que pertuber les utilisateurs, le prix à payer en temps de traitement des demandes d'assistances ne nous arrangeraient pas.

Revenir en haut de page

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.0766s (dont 0.0076 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !