[RESOLU]anti force brute neuneu

Support Debian
#1

slt

depuis quelque temps j’ai remarqué que certaines IP s’amusaient à me faire des attaques en force brute sur mon ssh d’un nouveau genre
d’habitude on a des tentatives user / mot de passe et puis fail2ban fait le ménage

mais là c’est rien que pour pourrir mon auth.log car c’est vraiment :

ssh root@mon.ip
ctrl+c

comme ca fail2ban ne bannit pas mais en face le type n’a aucune chance de se logger (d’autant qu’un seul user a le droit de se logger chez moi)
c’est vraiment pour faire clignoter mon switch quand je bois mon café le matin

je me demandais si je ne pouvais pas configurer fail2ban pour qu’il me gère ce genre de tentative débile, je ne peux considérer ca comme une attaque sérieuse
j’ai regardé dans les fichiers de config et n’ayant rien trouvé je me suis résigné à me faire une petite règle iptables qui ferme le port 22 pour l’IP source (je n’ai pas encore tous les critères qui vont bien, faut que je geek)

mais bon avant de lancer le truc je soumet ceci à votre sagacité : fail2ban peut-il gérer les pseudo-attaque de type login en root puis ctrl+c ?

#2

Je ne sais pas si cela te conviendra, mais tu peux très facilement mettre deux trois règles iptables pour en finir avec ton problème. Regarde du côté du module recent. C’est une des méthodes possible, la plus simple d’après moi. Autrement, on peux compliquer la chose mais cela pose quelques contraintes coté utilisateur.

Voila un exemple pour le ftp :

iptables -A wan_in_new -p tcp --dport 21 -m recent --set --name ftp_hits_list
iptables -A wan_in_new -p tcp --dport 21 -m recent --rcheck --seconds 300 --hitcount 2 --name ftp_hits_list -j reject_all
iptables -A wan_in_new -p tcp --dport 21 -j ACCEPT

La chaîne utilisateur wan_in_new récupère les paquets entrants (Internet -> serveur) associée aux nouvelles connexions. La chaine reject_all se charge de rejeter les paquets …
Tu peux aussi ajouter des logs si tu veux pour garder une trace des tentatives.

#3

ouais c’est chouette

ca correspond à ce que je m’imaginais
je vais tester, regarder du coté de recent, éventuellement modifier
dans tous les cas geeker et reporter

merci

edit : faut surtout que je regarde si c’est pas trop perturbant pour les utilisateurs, j’en ai tellement … :wink:

#4

hello
Il y a le module -m limit --limit 24/h --limit-burst 1 -p , tu filtres donc sur l’ip distante et comme la tienne est en principe différentes de la sienne, ( je veux dire par là que c’est quand tu va te connecter a ton poste distant. )
Il est peux, je dirai même impossible que tu récupères celle que tu as banni il sa lui cloue le bec durant 24h. et si sur le poste distant la connections est refusée. tu note l’heure, et si l heure correspond. c’est fort possible que c’est le poste sur le qu’elle tu te trouves qui a servis a faire le brute force.

Chez moi sa marche bien et sans fail2ban :slightly_smiling:

#5

fort intéressant tout cela
ce qui est bien c’est que je n’avais pas encore bien réfléchi à comment faire ma règle iptables
et en quelques heures me voila avec deux soluces éprouvées
j’ai honte, je ne voudrais pas que vous pensiez que je veux me faire macher le travail :blush:

#6

il y a pas de honte a apprendre, iptables n’est pas simple.
la logique est pourtemp simple il y a 2 solution:

faire une config global pour tout et de façon ace que cela ne bouge plus. ce qui en principe veux dire on interdit tout sauf ce qui est permis.

ou comme moi c’est a dire : on ne sais pas ce qui rentre mai on c’est ce qui sort.
je filtre aux nivaux logiciel, sa a ces avantage est ces inconvenian. puis que si l’application est vérolée elle peux sortire. sinon couic :slightly_smiling:

mai les 2 solution marche bien de plus t’es pas sous windows :slightly_smiling:

#7

il y a pas de honte a apprendre, iptables n’est pas simple.
la logique est pourtemp simple il y a 2 solution:

faire une config global pour tout et de façon ace que cela ne bouge plus. ce qui en principe veux dire on interdit tout sauf ce qui est permis.

ou comme moi c’est a dire : on ne sais pas ce qui rentre mai on c’est ce qui sort.
je filtre aux nivaux logiciel, sa a ces avantage est ces inconvenian. puis que si l’application est vérolée elle peux sortire. sinon couic :slightly_smiling:

mai les 2 solution marche bien de plus t’es pas sous windows :slightly_smiling:

bref un petit tuto :slightly_smiling:
linux-france.org/prj/inetdoc … -tutorial/

bonne lecture :slightly_smiling:

#8

sous quoi :question:

#9

linux :unamused: :smt064

#10

Le -p, c’est une coquille :p!

Du coup, il n’y a aucun inérêt à utiliser le module limit pour mettre en place une limitation d’accès à un service ; il n’est pas capable de différencier les ips source. C’est pour cela que le module recent me paraît plus judicieux. De cette manière un utilisateur X n’est pas interdit de connexion à cause d’un utilisateur Y qui s’amuse sur un service. De plus, l’utilisation de limit n’est pas précise c’est une moyenne.

-m limit 24/h, cela autorise 24 matchs par heure, pas un match toutes les 24h

#11

Les données qui rentrent tu les connais forcément, elles sont liées au services que fournis ta machine, ou aux données que l’utilisateur de ta machine veux récupérer.

Du coup, je pencherais plutôt par la solution 1, plus la solution 2 par dessus si c’est nécessaire.

#12

j’étais juste en train d’expérimenter car je subissais à nouveau des tentatives de log en root
en tout cas merci pour votre implication et vos points de vue différents

je ne peux pas trop limiter les connexions ssh sur ma machine car je m’en sers beaucoup pour du dev et pour clusteriser, puis j’ai les potes de passage qui viennent faire joujou, je ne connais pas trop leur ip
par contre j’aime beaucoup l’idée de compter les connexions non abouties et au bout d’un certain nombre d’itérations droper tout ce monde là

par contre j’ai une règle laissant passer les connexions établies qui est en placée dans les premières règles d’INPUT qui m’oblige à insérer ma règle de bannissement en début de chaine

je n’ai plus qu’à potasser mon iptables encore une fois afin de faire quelque chose de propre

affaire à suivre

#13

Regarde les chaines utilisateur, cela te permettra d’éviter ce genre de désagrément.

#14

thialme a écrit

:laughing:

thialme a écrit

Et le module ip range qui va avec pour filtrer le ip ser a rien je suppose ?

Il suffis ensuite d’adapter la ligne quoi. l’idée du module récent est bonne aussi :slightly_smiling:
Sinon c’est vrai que je me suis mélanger les pinceaux pour le
-m limit 24/h, :laughing:

thialme a écrit

Non !
S’il s’agit d’un nouvelle connections qui veux savoir sur qu’elle port elle peut ce connecter si un port est déjà occuper elle ne pourra pas. par contre on peux <> que tel port correspond a tel application. mai rien n’empêche d’avoir plusieurs application qui veule une réponse sur le même port le port 80, mai pas en même temps <<1 seul par port>
(oui bon c’est pas claire donc prenons un petit exemple)

Par exemple le port 80:tout les navigateurs , les lecteur de e-mail permette aussi de voire les image et sans avoir les images en fichier attacher sa passe par le port 80.
Après pour savoir si sa va aux aux navigateur ou aux lecteur d’e-mail ou autre chose tu peux pas savoire c’est pas toi qui <<crée le paquet envoiyer par la machine distante>>, tu sais donc
pas qu’elle est le l’objectif :le navigateur ou lecteur ?

Par contre ce qui sort, on c’est clairement d’ou ça part puis qu’on est sur la machine qui produit le paquet.

bon evidament je vais pas rentrer dans les détail donc si je m’exprime pas clairement … il faut voire la chose en très gros quoi

#15

Je veux bien un exemple. Je n’arrive pas à voire comment tu peux reconnaître des clients venant d’Internet avec le module iprange et leur autoriser à chacun un nombre de hits sur un service particulier.

Nos points de vue sont complètement différents ; j’ai pas envie de passer 40 ans à discuter la dessus, mais pour moi, ton approche d’un firewall me semble plus qu’étrange et en rien comparable avec ce que je peux voir sur la liste dédiée Netfilter.

#16

un petit aperçus

iptables -A INPUT -p tcp -m iprange --src-range 10.0.0.0-10.0.0.255 --dport 22 -m limit --limit 20/d --limit-burst 1

(adapte la plage d’ip a tes besoin)
Ensuite un petit script qui identifie ce qui tourne sur le port 22 avec lsof par exemple (mon scripte le fait). et lire les entrée dans un fichier log j ULOG --ulog-prefix="tien un visiteurs"
Ensuite tu en fais ce que tu veux, compter le nombre d’entrée, fixer une plage d’heure tu peux faire un match sure chaque entrée etc etc.
Autorise que l’application X a tourner sur le port 22 , note il y a un module qui permet de le faire seulement sa marche pas chez moi (SMP) :frowning:

OWNER match v1.3.8 options:
[!] --uid-owner userid     Match local uid
[!] --gid-owner groupid    Match local gid
[!] --pid-owner processid  Match local pid
[!] --sid-owner sessionid  Match local sid
[!] --cmd-owner name       Match local command name
NOTE: pid, sid and command matching are broken on SMP

(d’ou le script)
Bref c’est pas les possibilité qui manque, je préfère un script plutôt qu’un outil, car plus facilement modifiable, et ne dépant d’aucun programme supplémentaire (fail2ban par exemple)

40 ans et tu crois que sa va suffire :laughing:
Disons plutôt que linux a l’avantage être plus souple et avec des configuration différentes sure (chaque) machine et donc c’est plus sécuriser.
Sa ne veux pas dire que ma méthode est juste, mai j’aime bien avoir l’avis des gens sur un sujet qui est quand même assez complexe.[/quote]

#17

whow !
vous maitrisez le sujet vachement mieux que moi
je n’ai fait que des firewall simples jusqu’à présent, le plus complexe était pour un petit routeur

thialme, j’ai effectivement regardé du côté des chaines utilisateur et ca se passe beaucoup mieux
maintenant je commence à avoir quelque chose de pas mal
mais je vais essayer de faire suer l’attaquant maintenant en fouinant du coté du module tarpit

moi qui voulais juste me faire une petite règle pèpère me voilà reparti dans les arcanes d’iptables

c’est agréable de voir des gens maitrisant le sujet échanger des idées, ca me fait progresser :smiley:

#18

[quote=“panthere”]
(oui bon c’est pas claire donc prenons un petit exemple)

Par exemple le port 80:tout les navigateurs , les lecteur de e-mail permette aussi de voire les image et sans avoir les images en fichier attacher sa passe par le port 80.
Après pour savoir si sa va aux aux navigateur ou aux lecteur d’e-mail ou autre chose tu peux pas savoire c’est pas toi qui <<crée le paquet envoiyer par la machine distante>>, tu sais donc
pas qu’elle est le l’objectif :le navigateur ou lecteur ?[/quote]

Je ne veux pas rentrer dans le débat mais ce point est faux. Une connexion = (IP-source+port,IP-destination+port).
Un serveur (i.e un programme bien précis) écoute sur un port précis et un port en écoute ne sert qu’une application: Le port est donc fixé et des défauts (modifiables) sont donnés (cf fichier /etc/services)

http (apache) = port 80
https = 443
Lecture mail (Pop) = 110
Serveur SMTP = 25
ssh = 22
telnet = 23
etc.

(Pour savoir quels sont les ports en écoute et par qui il suffit de faire

netstat -tpl)

donc effectivement, si une connexion existe sur un port en écoute, c’est pour un service que l’on connait.

Un parefeu a plusieurs objectifs, par ordre d’importance à mes yeux:

  • protéger les services qui écoutent de connexions non désirées: filtrage d’IP (exemple service netsbios-ssn limité au LAN), limitations de connexions (tentatives de connexions SSH, deni de service), etc.
  • empêcher un éventuel troyen de fonctionner: Tout port non prévu est interdit à l’écoute (Le tryen ne peut se mettre sur un port déjà utilisé)
  • empêcher des connexions non désirées, bref filtrer les sorties (interdiction de se connecter à un P2P, à un SMTP (sauf pour une machine bien précise), etc ou limiter le nombre de ces connexions (module recent par exemple)

À cela se rajoute des fonctions supplémentaires bien pratiques:

  • Instaurer des files de priorités pour les paquets sortant: ceux qui jouent à Counter apprécient qu’une priorité maximale soit donnée aux paquets UDP vers les ports 27000-27050 par exemple.
  • Faire un filtrage forcé: Exemple typique, mettre un proxy en mode transparent.
  • Faire des services différenciés en fonction du client (smtp.orange.fr n’est pas la même machine si on est client orange ou non), mais là ça devient du routage.

2 techniques:

  1. On verrouille tout
  2. On verrouille moins mais on surveille

(je préfère la 2 plus souple et plus sûr: on ne s’endort pas sur ses lauriers).
Une intrusion réussie est une intrusion où une personne donnée est entrée par un service de la machine et a obtenu les droits root. Si la machine compromise sert de parefeu, la personne peut tout à fait refaire ce parefeu. Donc sur une machine servant de parefeu, il importe particulièrement d’empêcher l’intrusion (soin apportée aux serveurs) et de détecter le + rapidement possible une intrusion.

#19

[quote=“panthere”]un petit aperçus

iptables -A INPUT -p tcp -m iprange --src-range 10.0.0.0-10.0.0.255 --dport 22 -m limit --limit 20/d --limit-burst 1

[/quote]

Cela me conforte dans l’idée que j’avais bien compris l’utilisation de iprange et de limit.

Un -m limit --limit 24/d --limit-burst 1 n’autorise que 1 connexion toutes les heures. contrairement à un hitcount avec le module recent qui définit un nombre de hits successifs ou pas pendant un temp impartit (je suis pas certains du t :p!). Le fait d’ajouter le module iprange comme ci-dessus n’améliore pas la chose, car tu dois obligatoiremnet savoir à quoi ressemble l’ip distante. De plus, ce module ne permet pas de savoir si les hits ont été fait par une ip ou une autre, elle se contente de matcher sur la range d’ip. Du coup, si un utilisateur lambda (dont iprange match l’ip) tente de se connecter sur mon port 21 par exemple, et que j’ai un --limit 24/d, je ne pourrais pas me connecté sur mon serveur avant moins d’une heure. Donc en cas de flood tu es verrouillé à l’extérieur. Avec le hitcount du module recent non (si il te reste des ressources disponibles :slightly_smiling:).

#20

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set iptables -I INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 90 --hitcount 3 -j DROP
bloque le port ssh si il y a eu 3 connexions dans les 90 dernières secondes.
http://www.linux-france.org/prj/inetdoc/guides/iptables-tutorial/explicitmatches.html#recentmatch

Avec ftp, compte tenu des apt-get qui peuvent faire 5-6 connexions dans ce laps de temps, et de navigateurs qui ouvrent plusieurs connexions en même temps, j’ai porté ce nombre à 12.