Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Tentatives d'accès SSH

10 réponses
Avatar
pehache
Bonjour,

J'ai ouvert il y a quelques temps un accès ssh depuis internet vers mon
NAS. Dans la translation de port sur la box j'ai choisi un un port
non-standard (pas 22, quoi) en espérant limiter les fouineurs.

Après quelques temps tranquille, depuis 3 semaines c'est la foire aux
tentatives de connexion. J'ai mis une règle pour bloquer une IP après 3
tentatives ratées, et j'en bloque en moyenne 200 par jour.

Je ne suis pas plus inquiet que ça, le mot de passe d'accès fait 19
caractères en mélangeant minuscules/majuscules/chiffres/spéciaux, il va
leur falloir un certain temps avant de le trouver :) (et en plus le
login n'est pas trivial). Néanmoins :

1) est-ce que ça va se calmer Í  un moment ?

2) est-ce que tous les ports sont systématiquement scannés, ou bien y en
a-t-il qui le sont plus que d'autres ?

PS : pour diverses raisons ça ne m'arrange pas de mettre un filtrage par
liste blanche d'IP, ni une connexion par clés.

10 réponses

Avatar
Marc SCHAEFER
pehache wrote:
J'ai ouvert il y a quelques temps un accès ssh depuis internet vers mon
NAS. Dans la translation de port sur la box j'ai choisi un un port
non-standard (pas 22, quoi) en espérant limiter les fouineurs.

Il existe des services comme shodan.io o͹ on peut demander: donne-moi un
service SSH qui a telle vulnérabilité sur n'importe quelle port sur
n'importe quelle adresse IP.
Pour mémoire, avec une excellente liaison Internet, on peut scanner
l'ensemble des ports TCP de tout Internet en quelques jours.
Après quelques temps tranquille, depuis 3 semaines c'est la foire aux
tentatives de connexion. J'ai mis une règle pour bloquer une IP après 3
tentatives ratées, et j'en bloque en moyenne 200 par jour.

fail2ban est une bonne solution, en ce qui me concerne je reporte par
exemple Í  abuseipdb.com
1) est-ce que ça va se calmer Í  un moment ?

non
2) est-ce que tous les ports sont systématiquement scannés

oui
PS : pour diverses raisons ça ne m'arrange pas de mettre un filtrage par
liste blanche d'IP, ni une connexion par clés.

Alternative: réseau privé / VPN.
PS: assurer que son SSH et toutes les dépendances sont Í  jour.
Avatar
pehache
Le 11/12/2020 Í  20:30, Marc SCHAEFER a écrit :
Après quelques temps tranquille, depuis 3 semaines c'est la foire aux
tentatives de connexion. J'ai mis une règle pour bloquer une IP après 3
tentatives ratées, et j'en bloque en moyenne 200 par jour.

fail2ban est une bonne solution,

Ben je les bloque, la question n'est pas lÍ ...
1) est-ce que ça va se calmer Í  un moment ?

non

Ah... Mais ces IP d'o͹ proviennent les tentatives ce sont les vrais IP
ou des fakes ?
PS : pour diverses raisons ça ne m'arrange pas de mettre un filtrage par
liste blanche d'IP, ni une connexion par clés.

Alternative: réseau privé / VPN.

Ca ne fait un peu que déplacer le problème, non ? Il faut ouvrir un
service sur l'extérieur...
Bon, de toutes façons je ne souhaite pas non plus en arriver lÍ . A la
base j'ai ouvert le service SSH pour que certaines personnes extérieures
puissent accéder au SFTP. Si je leur demande d'utiliser des clés ou de
passer par un VPN, ça ne va pas le faire...
PS: assurer que son SSH et toutes les dépendances sont Í  jour.

Oui.
Avatar
Marc SCHAEFER
pehache wrote:
Ah... Mais ces IP d'o͹ proviennent les tentatives ce sont les vrais IP
ou des fakes ?

Ce sont de vrais IP, peut-être des réseaux command-and-control.
Alternative: réseau privé / VPN.

Ca ne fait un peu que déplacer le problème, non ? Il faut ouvrir un
service sur l'extérieur...

Oui, mais Í  un point central, qui lui peut être bien surveillé,
alimenter abusedbip, etc.
Bon, de toutes façons je ne souhaite pas non plus en arriver lÍ . A la
base j'ai ouvert le service SSH pour que certaines personnes extérieures
puissent accéder au SFTP. Si je leur demande d'utiliser des clés ou de
passer par un VPN, ça ne va pas le faire...

Une idée pourrait être knockd: du style, pour que le port SSH s'ouvre,
il faut faire:
telnet 1.2.3.4 5555
telnet 1.2.3.4 2345
telnet 1.2.3.4 7890
dans cet ordre
Avatar
Eric Demeester
Bonjour,
Marc SCHAEFER (Fri, 11 Dec 2020 20:30:38 +0100 (CET)
- fr.comp.securite) :
pehache wrote:
Après quelques temps tranquille, depuis 3 semaines c'est la foire aux
tentatives de connexion.

fail2ban est une bonne solution, en ce qui me concerne je reporte par
exemple Í  abuseipdb.com

Oui. Ça fait un moment que je me dis qu'il faudrait que je l'installe,
ne serait-ce que pour nettoyer mes logs.
1) est-ce que ça va se calmer Í  un moment ?
non
2) est-ce que tous les ports sont systématiquement scannés
oui

Je confirme. Moi, c'est sur le port smtp que j'ai le plus de tentatives
de connexion, genre des milliers par jour. J'évite de regarder mes logs
trop souventr, parce qu'Í  chaque fois ça fait PEUR :)
Avatar
Stéphane CARPENTIER
Le 12-12-2020, Eric Demeester a écrit :
Je confirme. Moi, c'est sur le port smtp que j'ai le plus de tentatives
de connexion, genre des milliers par jour. J'évite de regarder mes logs
trop souventr, parce qu'Í  chaque fois ça fait PEUR :)

Au contraire, c'est quand j'ai eu des périodes o͹ les tentatives de
connexions ont diminuées que je me suis inquiété. J'ai cherché, j'ai
rien trouvé et quand j'ai entendu qu'un gros botnet avait été stoppé ça
m'a rassuré.
Je me dis que tant qu'ils essayent c'est qu'ils n'y arrivent pas. S'ils
arrêtent d'essayer, l'explication peut être qu'ils ont réussi et ça
m'inquiète.
--
Si vous avez du temps Í  perdre :
https://scarpet42.gitlab.io
Avatar
Marc SCHAEFER
Eric Demeester wrote:
Je confirme. Moi, c'est sur le port smtp que j'ai le plus de tentatives
de connexion, genre des milliers par jour. J'évite de regarder mes logs
trop souventr, parce qu'Í  chaque fois ça fait PEUR :)

Moi j'en ai un peu partout, mais j'ai des règles fail2ban qui détectent
les erreurs d'authentification et qui triggent assez vite. Et si
récidive: blocage pendant une semaine + report Í  abuseipdb.com
Toutefois, sur un petit système embarqué GNU/Linux Í  jour (alix, 256 MB
de mémoire), depuis quelques semaines je me ramasse beaucoup de DoS DNS,
provenant d'adresses IP falsifiées.
Malheureusement ce serveur est un serveur DNS autoritaire pour
plusieurs domaines (bon, il y a des réplicats qui ne sont pas
affectés).
Les règles de bind9 font que ce petit serveur répond quand même
par saccades (puis bind9 ignore car il voit le DoS).
J'ai donc fait deux choses:
a) interdit toutes les réponses DNS de type DENIED via iptables
-> donc il ne répond plus jamais DENIED
b) ajouté un script genre fail2ban qui détecte les abus et
firewall spécifiquement.
Depuis, la charge CPU a bien baissé ainsi que la contribution de ce
système Í  un DDos.
Ce que je trouve bizarre, c'est qu'il n'a jamais été `ouvert' (il n'a
jamais répond que pour son propre domaine). Et que donc son efficacité
dans un DDoS n'est dans les petites saccades o͹ il répond de nouveau.
Avatar
Marc SCHAEFER
Eric Demeester wrote:
Je confirme. Moi, c'est sur le port smtp que j'ai le plus de tentatives
de connexion, genre des milliers par jour. J'évite de regarder mes logs
trop souventr, parce qu'Í  chaque fois ça fait PEUR :)

Moi j'en ai un peu partout, mais j'ai des règles fail2ban qui détectent
les erreurs d'authentification et qui triggent assez vite. Et si
récidive: blocage pendant une semaine + report Í  abuseipdb.com
Toutefois, sur un petit système embarqué GNU/Linux Í  jour (alix, 256 MB
de mémoire), depuis quelques semaines je me ramasse beaucoup de DoS DNS,
provenant d'adresses IP falsifiées.
Malheureusement ce serveur est un serveur DNS autoritaire pour
plusieurs domaines (bon, il y a des réplicats qui ne sont pas
affectés).
Les règles de bind9 font que ce petit serveur répond quand même
par saccades (puis bind9 ignore car il voit le DoS).
J'ai donc fait deux choses:
a) interdit toutes les réponses DNS de type DENIED via iptables
-> donc il ne répond plus jamais DENIED
b) ajouté un script genre fail2ban qui détecte les abus et
firewall spécifiquement.
Depuis, la charge CPU a bien baissé ainsi que la contribution de ce
système Í  un DDos.
Ce que je trouve bizarre, c'est qu'il n'a jamais été `ouvert' (il n'a
jamais répond que pour son propre domaine). Et que donc son efficacité
dans un DDoS n'est dans les petites saccades o͹ il répond de nouveau.
Voir l'image: http://test1.gluglu.ch/munin/localdomain/localhost.localdomain/if_eth1-year.png
(remplacer gluglu par teleinf)
Avatar
Marc SCHAEFER
Eric Demeester wrote:
Je confirme. Moi, c'est sur le port smtp que j'ai le plus de tentatives
de connexion, genre des milliers par jour. J'évite de regarder mes logs
trop souventr, parce qu'Í  chaque fois ça fait PEUR :)

Moi j'en ai un peu partout, mais j'ai des règles fail2ban qui détectent
les erreurs d'authentification et qui triggent assez vite. Et si
récidive: blocage pendant une semaine + report Í  abuseipdb.com
Toutefois, sur un petit système embarqué GNU/Linux Í  jour (alix, 256 MB
de mémoire), depuis quelques semaines je me ramasse beaucoup de DoS DNS,
provenant d'adresses IP falsifiées.
Malheureusement ce serveur est un serveur DNS autoritaire pour
plusieurs domaines (bon, il y a des réplicats qui ne sont pas
affectés).
Les règles de bind9 font que ce petit serveur répond quand même
par saccades (puis bind9 ignore car il voit le DoS).
J'ai donc fait deux choses:
a) interdit toutes les réponses DNS de type DENIED via iptables
-> donc il ne répond plus jamais DENIED
b) ajouté un script genre fail2ban qui détecte les abus et
firewall spécifiquement.
Depuis, la charge CPU a bien baissé ainsi que la contribution de ce
système Í  un DDos.
Ce que je trouve bizarre, c'est qu'il n'a jamais été `ouvert' (il n'a
jamais répond que pour son propre domaine). Et que donc son efficacité
dans un DDoS n'est dans les petites saccades o͹ il répond de nouveau.
Voir
http://test1.gluglu.ch/munin/localdomain/localhost.localdomain/if_eth1-year.png
http://test1.gluglu.ch/munin/localdomain/localhost.localdomain/cpu-month.png
http://test1.gluglu.ch/munin/localdomain/localhost.localdomain/load-year.png
(remplacer gluglu par teleinf)
Avatar
pehache
Le 12/12/2020 Í  10:39, Stéphane CARPENTIER a écrit :
Le 12-12-2020, Eric Demeester a écrit :
Je confirme. Moi, c'est sur le port smtp que j'ai le plus de tentatives
de connexion, genre des milliers par jour. J'évite de regarder mes logs
trop souventr, parce qu'Í  chaque fois ça fait PEUR :)

Au contraire, c'est quand j'ai eu des périodes o͹ les tentatives de
connexions ont diminuées que je me suis inquiété. J'ai cherché, j'ai
rien trouvé et quand j'ai entendu qu'un gros botnet avait été stoppé ça
m'a rassuré.
Je me dis que tant qu'ils essayent c'est qu'ils n'y arrivent pas. S'ils
arrêtent d'essayer, l'explication peut être qu'ils ont réussi et ça
m'inquiète.

Pareil :)
Avatar
Thomas
In article ,
pehache wrote:
PS : pour diverses raisons ça ne m'arrange pas de mettre un filtrage par
liste blanche d'IP,

est ce que c'est envisageable d'alléger la charge en faisant une liste
noire par grandes tranches ?
par ex un FAI étranger dont t'es certain que tes "personnes extérieures"
ne viendront jamais, autre chose qu'un FAI, ...
évidement ça ne te garantira pas la sécurité,
ça fera juste un peu moins de traitement pour fail2ban
ni une connexion par clés.

pourquoi ?
(quel genre de pb y a t il, avec ces "certaines personnes extérieures" ?)
--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/