Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 22/04/2016, à 13:00

fletcher02

FAIL2BAN - Bannissement impossible.

Bonjour à tous,

Je viens ici solliciter l'avis d'expert car je vais tourner fou !

Rapide descriptif de la situation :

- Serveur Debian 7.7 en ligne
- Service SSH
- Fail2ban

Le serveur est sujet à des attaques soutenues et Fail2ban envoi des mails (800 par jours !).

Voici un exemple de notification :

Apr 17 10:55:25 Serveur sshd[26603]: Did not receive identification string from 159.226.125.73
Apr 17 11:01:56 Serveur sshd[26662]: Failed password for root from 159.226.125.73 port 36176 ssh2
Apr 17 11:01:56 Serveur sshd[26662]: Received disconnect from 159.226.125.73: 11: Bye Bye [preauth]
Apr 17 11:05:32 Serveur sshd[26730]: Failed password for root from 159.226.125.73 port 47502 ssh2
Apr 17 11:05:37 Serveur sshd[26730]: Received disconnect from 159.226.125.73: 11: Bye Bye [preauth]
Apr 17 11:07:11 Serveur sshd[26736]: Connection closed by 159.226.125.73 [preauth]

Ligne de log visiblement issues de /var/log/auth.log puisque c'est la configuration et c'est que me dit la notification mail. Mais le soucis c'est que dans le fichier, quand je vais voir sur la VM, je n'ai absolument pas ça !

Et le second soucis, que je pense lié, c'est que Fail2ban ne bannit pas ! Les regex fonctionnent visiblement puisqu'il détecte des choses, mais le bannis jamais. J'ai un bantime à 15 jours et j'ai beau filter avec iptables un nombre ultra restreint d'IP autorisé en SSH, j'ai toujours ce type de mail et aucune entrée dans les logs ....

J'ai même installé XINETD et autorisé un nombre ultra restreint d'adresse IP a utilisé le service SSH mais c'est toujours pareil.

Il y a forcément quelque chose que je loupe...

Je poursuis mes investigations mais si quelqu'un à un idée, je suis preneur :-)

Bien à vous.

Dernière modification par fletcher02 (Le 22/04/2016, à 13:01)

Hors ligne

#2 Le 23/04/2016, à 09:41

LeoMajor

Re : FAIL2BAN - Bannissement impossible.

bonjour,

geoiplookup 159.226.125.73
GeoIP Country Edition: CN, China
GeoIP City Edition, Rev 1: CN, 22, Beijing, Beijing, N/A, 39.928902, 116.388298, 0, 0
GeoIP ASNum Edition: AS7497 Computer Network Information Center

ip chinoise.

awk '{ for(i=1;i<=NF;i++) if($i~/([0-9]{1,3}\.){3}[0-9]{1,3}/) { split($i,n,/\.|:/); ip=n[1]"."n[2]"."n[3]"."n[4]; ips[ip]++}}; \
END { for (ipi in ips) { cmd="geoiplookup " ipi ; while (cmd | getline tmp) { if(!(tmp~/can|not found/))outs[tmp]++}; close(cmd); print "------"; printf("%s %s %s %s\n",ips[ipi],"fois",ipi,"ok"); \
print "G--"; for(out in outs) print out; delete outs; }}'  target.log

Contre la Chine, laisse tomber Fail2ban. C'est insuffisant. La Chine est vraiment un cas à part, en sécurité informatique, qui ne fait fait rien comme tout le monde.
Il y a qu'avec iptables mod geoip que tu arriveras à t'en débarrasser.  -> exemple d'installation

Hors ligne

#3 Le 25/04/2016, à 08:57

fletcher02

Re : FAIL2BAN - Bannissement impossible.

Merci beaucoup pour le retour et le conseil. Je m'y atèle rapidement et vous ferez un retour de l’efficacité.

Hors ligne

#4 Le 28/04/2016, à 15:36

fletcher02

Re : FAIL2BAN - Bannissement impossible.

Bon c'est pas mieux malheureusement ....

Fail2ban continu d'envoyer des notifications à tout va avec des informations que je ne retrouve nulle part dans mes fichiers de log.

Il dit qu'il trouve cela dans /var/log/auth.log, des choses comme :

Apr 24 18:04:52 ServeurWeb sshd[19569]: Failed password for root from 183.3.202.187 port 10529 ssh2
Apr 24 18:04:54 ServeurWeb sshd[19569]: Failed password for root from 183.3.202.187 port 10529 ssh2
Apr 24 18:04:56 ServeurWeb sshd[19569]: Failed password for root from 183.3.202.187 port 10529 ssh2
Apr 24 18:04:57 ServeurWeb sshd[19569]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=183.3.202.187  user=root

Apr 28 12:58:48 ServeurWeb sshd[12518]: Did not receive identification string from 195.154.104.191

On parle de 600 mails par jour, c'est la folie.

Dans mon fichier /var/log/auth.log en direct sur la VM j'ai rien du tout. J'ai vérifier syslog, kern, messages .... J'ai même fait un grep sur tout ce qui pourrait contenir cela, j'ai rien de rien ... Je comprends plus rien.

Au niveau IPtables j'ai une règle qui autorise uniquement mon ip publique et c'est tout mais rien à faire.

Quand je test d'une autre IP que la mienne, j'ai même pas la mire de login, le filtrage fonctionne. Alors comment font ils pour tenter des authentifications ? Pourquoi Fail2ban les voit ? J'ai même essayer la méthode XINETD pour uniquement autoriser le daemon ssh sur mon IP, mais j'ai encore et toujours des mails de tentative.

Je fini par me dire que tant qu'ils testeront, j'aurais des notifs. Il y a pas moyen de supprimer ça ? Comme faire en sorte de démarrer SSH que quand c'est mon IP en entrée et donc

Je dois oublier quelque chose ...

Merci à vous.

Dernière modification par fletcher02 (Le 28/04/2016, à 15:43)

Hors ligne

#5 Le 28/04/2016, à 16:39

pires57

Re : FAIL2BAN - Bannissement impossible.

@fletcher02:

que renvoie

iptables -L

?
Si F2B ne bannit pas c'est qu'il n'est pas configuré correctement. F2B analyse les logs et bannit en fonction de cela, ce que tu reçoit par mail peut être très loin dans le fichier (voir même dans un autre fichier ) au moment ou tu regardes.
Iptables log toutes les tentatives échoués, que l'IP soit ou non autorisé donc la réception des mails est logique si tu les a activés.
D'ailleur c'est un peu idiot de recevoir les mails pour les connections échoués, ceux qui n'arrive pas se connecté je m'en balance, c'est si la personne arrive a se connecter qu'il faut envoyer un mail!

Contre la Chine, laisse tomber Fail2ban. C'est insuffisant.

Contre la connerie aussi malheureusement... le fait que l'IP viennent de Chine, de Tanzanie ... ou de n'importe ou ne change absolument rien à la manière dont F2B gère la requête.
De plus, il n'y a pas que des IP chinoise qui font ce genre de chose.

Dernière modification par pires57 (Le 28/04/2016, à 16:42)


Utilisateur d'Archlinux, Ubuntu et Kali Linux
Administrateur système et réseau spécialisé Linux.
LinkedIn

Hors ligne

#6 Le 01/05/2016, à 14:31

LeoMajor

Re : FAIL2BAN - Bannissement impossible.

@fletcher02

183.3.202.187 ip chinoise
195.154.104.191  apparemment ton serveur

nc -w1 -i1 -z 195.154.104.191 22; echo "$?"
0
telnet 195.154.104.191 22

Ton service ssh est accessible sur le 22, et tu as, semble-t-il, que le ssh ouvert vers l'extérieur (le nc renvoie 1 sur les autres services, donc inaccessibles ou inexistants)

Au niveau IPtables j'ai une règle qui autorise uniquement mon ip publique

C'est la directive Listen du service, qui détermine l'écoute, là où doivent se trouver les postes clients. Si le nc, commande cliente, renvoie 1, alors le poste client ne se trouve pas, dans le réseau attendu par le Listen du service. (ou service inexistant). Le pendant de nc -z, est netstat, à taper sur le serveur.

sudo ufw allow in 22/tcp

normalement, suffit sur le serveur. (donc pas d'ip explicite pour autoriser.). Le client, lui, utilisera un port arbitraire ( Failed password for root from 183.3.202.187 port 10529 )

Enlève tarpit au cas où, et change de port, devraient suffire à éviter les notifications et avoir des logs moins noirs, moins volumineux. Cela ne semble pas être un vrai ddos. Tu devrais pouvoir t'en sortir avec iptables mod geoip.

Dans fail2ban, c'est le ratio maxretry/findtime, qui détermine la sensibilité de ta règle. Trop sensible, l'alarme se déclenche pour un oui, pour un non, comme régler une alarme volumétrique en plein Mistral; pas assez sensible, la règle ne se déclenche  jamais.
findtime; plafond minimum 10.  valeurs usuelles ~ findtime = 30, maxretry = 3

@pires57
-1

Hors ligne

#7 Le 04/05/2016, à 10:29

pires57

Re : FAIL2BAN - Bannissement impossible.

Ton service ssh est accessible sur le 22, et tu as, semble-t-il, que le ssh ouvert vers l'extérieur

faux, le port ssh utilisé est bien 22 mais il est accessible depuis l’extérieur.
Par défaut les requêtes sortantes (donc vers l'extérieur) ne sont pas bloqués.

sudo ufw allow in 22/tcp
normalement, suffit sur le serveur. (donc pas d'ip explicite pour autoriser.). Le client, lui, utilisera un port arbitraire ( Failed password for root from 183.3.202.187 port 10529 )

Tu parles d'UFW mais iptables permet de faire des choses bien plus poussés qu'un simple UFW. Puisqu'il parle directement d'iptables, je ne pense pas qu'il est passé par UFW.
Les ports inférieurs à 1024 sont réservés, pour se connecter en SSH tu attaques bien (par défaut) le port 22 mais le port que ta machine utilise ne pourras pas être inférieur à 1024.

Enlève tarpit au cas où, et change de port, devraient suffire à éviter les notifications et avoir des logs moins noirs, moins volumineux. Cela ne semble pas être un vrai ddos. Tu devrais pouvoir t'en sortir avec iptables mod geoip.

Changer le port pourrait permettre d'éviter de recevoir autant de log mais encore une fois le but n'est pas de savoir qui n'a pas réussi à se connecter mais l'inverse.
Ce genre de chose est courant au niveau serveur, ce sont des réseau botnet qui tapent des ip au hasard, ce n'est pas du DDOS, le but c'est d'obtenir un accès root pour corrompre le serveur, pas de le faire tomber.

Dans fail2ban, c'est le ratio maxretry/findtime, qui détermine la sensibilité de ta règle. Trop sensible, l'alarme se déclenche pour un oui, pour un non, comme régler une alarme volumétrique en plein Mistral; pas assez sensible, la règle ne se déclenche  jamais.
findtime; plafond minimum 10.  valeurs usuelles ~ findtime = 30, maxretry = 3

Avec un findtime a 10 il y a tout à parier que rien ne sera bloqué.
La config de fail2ban utilise des secondes donc 3 echec en 10 seconde ....
la valeur default de findtime au niveau de fail2ban est de 600 seconde (soit 10 minute, je pense que tu as fait la conversion?) pour un maxretry de 3, ce qui signifie qu'a partir du premier echec et ce sur une durée de 600 seconde donc si tu te plantes encore 2 fois dans ce laps de temps tu passes dans la jail et prends le bantime (600 seconde également par défaut)
En conclusion, plus tu augmentes ton findtime, plus la tache de fail2ban va être lourde puisqu'il devra analyser plus de log.
Maintenant en terme de configuration de fail2ban tu as également la possibilité de faire des niveau de jail, ce qui te permettra de bannir une ip récidiviste (listé dans un autre fichier de log) pour une longue (voir très longue) durée.

Dernière modification par pires57 (Le 04/05/2016, à 10:38)


Utilisateur d'Archlinux, Ubuntu et Kali Linux
Administrateur système et réseau spécialisé Linux.
LinkedIn

Hors ligne