Journal xinetd assure !

Posté par  .
Étiquettes : aucune
0
28
fév.
2006
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 !

  • # Méthode avec netfilter

    Posté par  . Évalué à 3.

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

  • # Pour les BSDistes

    Posté par  . É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  . É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  (site web personnel) . É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  . É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  (site web personnel) . Évalué à 2.

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

    • [^] # Re: Changer le port de SSH

      Posté par  . É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  . É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.

Suivre le flux des commentaires

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