Tentatives d'accès SSH

[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.

[Marc SCHAEFER]

pehache <peha...@gmail.com> 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.

[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.

[Marc SCHAEFER]

pehache <peha...@gmail.com> 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

[Eric Demeester]

Bonjour,

Marc SCHAEFER (Fri, 11 Dec 2020 20:30:38 +0100 (CET)
- fr.comp.securite) :

> pehache <peha...@gmail.com> 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 :)

[Stéphane CARPENTIER]

Le 12-12-2020, Eric Demeester <neu...@potiron.invalid> 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

[Marc SCHAEFER]

Eric Demeester <neu...@potiron.invalid> 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.

[Marc SCHAEFER]

Eric Demeester <neu...@potiron.invalid> 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)

[Marc SCHAEFER]

Eric Demeester <neu...@potiron.invalid> 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)

[pehache]

Pareil :)

[Thomas]

In article <i3hqss...@mid.individual.net>,

pehache <peha...@gmail.com> 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/

[pehache]

Le 11/12/2020 à 20:30, Marc SCHAEFER a écrit :

> pehache <peha...@gmail.com> 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.

> ...

>> 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.
>

>...

>
>> 1) est-ce que ça va se calmer à un moment ?
>
> non

En fait si... Comme je l'avais dit à l'époque, j'avais mis une règle
pour bloquer les IP après 3 tentatives ratées. Les 200 blocages par jour
en moyenne ont petit à petit diminué pour atteindre virtuellement 0 à
l'automne dernier. Je me suis inquiété un peu, me demandant s'ils
n'avaient pas réussi à entrer. Mais ma règle débloque aussi les IP
bloquées au bout d'un an, et il y a quelques semaines (donc pile un an
après les premiers blocages) j'ai recommencé à avoir des notifications
de blocage en nombre (genre 50 par jour).

Conclusion : le pool d'IP attaquantes finit par s'épuiser si on les
bloque petit à petit. En un an j'ai dû en bloquer de l'ordre de 30.000

[Marc SCHAEFER]

pehache <peha...@gmail.com> wrote:
> Conclusion : le pool d'IP attaquantes finit par s'épuiser si on les
> bloque petit à petit. En un an j'ai dû en bloquer de l'ordre de 30.000

C'est possible.

Toutefois, sur un système que je gère, même avec environ 1200 adresses
IP bloquées en permanence, il y en a des nouvelles en continu.
D'ailleurs, depuis quelques temps, les attaques sont constantes en
nombre, mais le nombre de bloqués est en baisse!

Peut-être car certains attaquants sont plus intelligents: ils attaquent
10'000 cibles différentes avec le même pool d'IP, mais de manière lente.
Sauf si vous avez des sondes sur une bonne partie des 10'000 machines,
vous ne voyez qu'un essai par jour, voire moins. Au bon d'un an, ils
ont certainement trouvé quelques comptes sur quelques machines quand
même!

Sur un /24 que j'ai, qui n'illustre pas tout à fait le problème car
l'attaquant peut très bien voir que c'est le même /24 et donc répartir
les attaques en fonction, on voit par exemple deux types d'attaques:

- les bourrins, qui scannent tout, très rapidement
(probablement pour alimenter des services comme shodan.io ou
autres moins publics)

- ceux qui scannent plus intelligemment la plage, mais je les choppe
car ils cumulent plus que 3 par heure sur toute la plage

- ceux qui viennent moins souvent que 3 par heures, que je ne bloque
donc pas

Je reporte les récidives chez abuseipdb.com, parfois je suis un des
premiers, parfois ce sont effectivement des adresses bien pourries déjà!

[Marc SCHAEFER]

pehache <peha...@gmail.com> wrote:
> Conclusion : le pool d'IP attaquantes finit par s'épuiser si on les
> bloque petit à petit. En un an j'ai dû en bloquer de l'ordre de 30.000

C'est possible.

Toutefois, sur un système que je gère, même avec environ 1200 adresses
IP bloquées en permanence, il y en a des nouvelles en continu.
D'ailleurs, depuis quelques temps, les attaques sont constantes en
nombre, mais le nombre de bloqués est en baisse!

Peut-être car certains attaquants sont plus intelligents: ils attaquent
10'000 cibles différentes avec le même pool d'IP, mais de manière lente.
Sauf si vous avez des sondes sur une bonne partie des 10'000 machines,
vous ne voyez qu'un essai par jour, voire moins. Au bon d'un an, ils
ont certainement trouvé quelques comptes sur quelques machines quand
même!

Sur un /24 que j'ai, qui n'illustre pas tout à fait le problème car
l'attaquant peut très bien voir que c'est le même /24 et donc répartir

les attaques en fonction, on voit par exemple trois types d'attaques:

[Stephane Tougard]

On 2022-01-21, Marc SCHAEFER <scha...@alphanet.ch> wrote:

> Peut-être car certains attaquants sont plus intelligents: ils attaquent
> 10'000 cibles différentes avec le même pool d'IP, mais de manière lente.
> Sauf si vous avez des sondes sur une bonne partie des 10'000 machines,
> vous ne voyez qu'un essai par jour, voire moins. Au bon d'un an, ils
> ont certainement trouvé quelques comptes sur quelques machines quand
> même!

Si un pirate pouvait faire 1,000 tests par seconde (ce qui est
impossible en raison des latences réseau), il lui faudrait
2.8231372e16 années pour faire l'ensemble des couples login/password
sur une seule machine.

Comme tu dis, au bout d'un an en faisant un essai par jour sur chaque
machine, leur chance de trouver un couple login/password autres que
"marc/1234" doit etre de l'ordre de 0.000....(beaucoup de 0)0001 sur
cent.

Faut mieux les bloquer, c'est plus sur. On peut aussi avoir un couple
login/password raisonnablement compliqué et dormir sur ses deux oreilles.




--
On leur dit: "eux gentils". Ils disent "OK"
On leur dit: "eux méchants". Ils disent "OK"
Qu'est ce qu'ils sont cons ces pauvres !

[Marc SCHAEFER]

Stephane Tougard <step...@unices.org> wrote:
> Comme tu dis, au bout d'un an en faisant un essai par jour sur chaque
> machine, leur chance de trouver un couple login/password autres que
> "marc/1234" doit etre de l'ordre de 0.000....(beaucoup de 0)0001 sur
> cent.
>
> Faut mieux les bloquer, c'est plus sur.

Donc, pour ceux qui n'ont pas accès à des sondes sur plusieurs adresses
IP de sous-réseaux différents, cela signifie bloquer l'accès SSH dès la
*1ère* tentative incorrecte.

Moi, je bloque dès 3 tentatives incorrectes, sur l'ensemble de mes
sondes (260 adresses IP différentes de 3 sous-réseaux complètement
différents). Et je bloque pour quelques heures. Mais s'il y a récidive,
je bloque pour beaucoup plus longtemps.

Alternative: dès une tentative incorrecte, consulter abuseipdb.com, et
si la confidence > 50% par exemple, bloquer l'IP. J'ai fait des tests
mais je n'ai pas encore mis en place.

> On peut aussi avoir un couple login/password raisonnablement compliqué
> et dormir sur ses deux oreilles.

Et je suis d'accord avec ça, mais quand tu fais du hosting de clients,
les clients peuvent faire n'importe quoi. Mon dernier piratage avéré (*)
date de 2009 quand un client avait installé un compte demo avec mot de
passe demo sur un SSH ouvert sur Internet.

J'ai heureusement détecté le piratage grâce à mon IDS (snort) suite à
des actions idiotes du pirate, et j'ai pu bloquer le compte sans autre
effet. D'après le .bash_history, le pirate était un peu débutant,
heureusement ...

On essaie de sensibiliser: n'ouvrez que les ports strictement
nécessaires, supprimez l'authentification par mot de passe mais
utiliser pubkey ou keypad, etc, mais cela ne marche pas toujours.

D'ailleurs la configuration par défaut dans le hosting `conteneur' est
exactement comme ça.

(*) il y a peut-être des pirates intelligents qui se baladent dans mes
infrastructures quand même, on ne sait jamais ...

[Marc SCHAEFER]

Stephane Tougard <step...@unices.org> wrote:
> Comme tu dis, au bout d'un an en faisant un essai par jour sur chaque
> machine, leur chance de trouver un couple login/password autres que
> "marc/1234" doit etre de l'ordre de 0.000....(beaucoup de 0)0001 sur
> cent.
>
> Faut mieux les bloquer, c'est plus sur.

Donc, pour ceux qui n'ont pas accès à des sondes sur plusieurs adresses
IP de sous-réseaux différents, cela signifie bloquer l'accès SSH dès la

*1ère* tentative incorrecte, ou compter les tentatives incorrectes sur
plusieurs jours, y compris avec un logrotate journalier.

Moi, je bloque dès 3 tentatives incorrectes, sur l'ensemble de mes
sondes (260 adresses IP différentes de 3 sous-réseaux complètement
différents). Et je bloque pour quelques heures. Mais s'il y a récidive,
je bloque pour beaucoup plus longtemps.

Alternative: dès une tentative incorrecte, consulter abuseipdb.com, et
si la confidence > 50% par exemple, bloquer l'IP. J'ai fait des tests
mais je n'ai pas encore mis en place.

> On peut aussi avoir un couple login/password raisonnablement compliqué
> et dormir sur ses deux oreilles.

[Stephane Tougard]

On 2022-01-22, Marc SCHAEFER <scha...@alphanet.ch> wrote:
>> On peut aussi avoir un couple login/password raisonnablement compliqué
>> et dormir sur ses deux oreilles.
>
> Et je suis d'accord avec ça, mais quand tu fais du hosting de clients,
> les clients peuvent faire n'importe quoi. Mon dernier piratage avéré (*)
> date de 2009 quand un client avait installé un compte demo avec mot de
> passe demo sur un SSH ouvert sur Internet.

On peut aussi mettre en place une politique de mots de passe.

N'importe quel full stack dev à peine sortie de l'école le sait, c'est
dommage d'avoir 40 ans de métier et de galérer à cause de problèmes
aussi simples.

Je me demande comment les mecs de SDF font avec un NetBSD et plus de
13,000 comptes utilisateurs accessibles en SSH et en TELNET.

[Marc SCHAEFER]

Stephane Tougard <step...@unices.org> wrote:
> On peut aussi mettre en place une politique de mots de passe.

Tout à fait c'est le cas sur mes serveurs.

A nouveau, je ne parlais pas de ça. Je parlais de systèmes clients,
gérés par des clients. Pour simplifier disons que c'est comme des
machines virtuelles que les clients gèrent eux-mêmes.

Disons que je suis un data center, pour comprendre encore mieux.

Devant, j'y mets un IDS et j'alerte les clients en cas de nécessité.
Pour le reste (ports ouverts, installation de logiciels, politiques de
sécurité, de sauvegarde, etc) c'est configuré par le client.

J'offre bien sûr des recommandations, j'informe quand je vois des choses
suspectes, mais le client gère ses propres systèmes, sauf s'il me
demande de les gérer pour lui, ou qu'un tiers les gère pour lui.

C'est plus clair? :)

Ou on doit tourner en rond comme pour le covid, la médecine moderne et
d'autres cas où tu es difficile?

[Marc SCHAEFER]

Marc SCHAEFER <scha...@alphanet.ch> wrote:
> Stephane Tougard <step...@unices.org> wrote:
>> On peut aussi mettre en place une politique de mots de passe.
>
> Tout à fait c'est le cas sur mes serveurs.

D'ailleurs, il faut se méfier de critères de sélection de mot de passe
trop stricts, qui peuvent mener les utilisateurs à écrire les mots de
passe ou à tenter des manoeuvres de work-around, ou, qui dans le cas
extrême peuvent rendre l'espace des mots de passe à devenir plus petit!

Aujourd'hui on considère par exemple que la technique des initiales de
passphrase est bonne:

https://security.stackexchange.com/questions/6095/xkcd-936-short-complex-password-or-long-dictionary-passphrase

Lire aussi:

https://security.stackexchange.com/questions/32222/are-password-complexity-rules-counterproductive

Une alternative est de tourner une attaque soi-même sur les systèmes où
les mots de passe pourraient être de mauvaise qualité, ou, comme déjà
dit, de passer à des systèmes basés sur clé publique, voire token du
temps (dans ce cas en plus du mot de passe choisi par l'utilisateur). Il
existe d'ailleurs dans le darknet des énormes listes de mots de passe
déjà utilisés.

Enfin, la meilleure solution à mon avis pour les logins interactifs est
est de passer à une double authentification (p.ex. timecode haché) ou à
des clés SSH et interdire les mots de passe (comme déjà suggéré, avec le
blocage d'adresses).

[Marc SCHAEFER]

Marc SCHAEFER <scha...@alphanet.ch> wrote:
> Stephane Tougard <step...@unices.org> wrote:
>> On peut aussi mettre en place une politique de mots de passe.
>
> Tout à fait c'est le cas sur mes serveurs.

[Jo Engo]

Le Fri, 21 Jan 22 11:14:40 +0000, pehache a écrit :

> Conclusion : le pool d'IP attaquantes finit par s'épuiser si on les
> bloque petit à petit. En un an j'ai dû en bloquer de l'ordre de 30.000

30 000 zombies ? Petite ferme.



--
Son ému : or omit, nô tua? Eh! L'héautontimorouménos.
-- Millot, Pierre-Yves

[Stephane Tougard]

On 2022-01-23, Marc SCHAEFER <scha...@alphanet.ch> wrote:
> Stephane Tougard <step...@unices.org> wrote:
>> On peut aussi mettre en place une politique de mots de passe.
>
> Tout à fait c'est le cas sur mes serveurs.
>
> A nouveau, je ne parlais pas de ça. Je parlais de systèmes clients,
> gérés par des clients. Pour simplifier disons que c'est comme des
> machines virtuelles que les clients gèrent eux-mêmes.
>
> Disons que je suis un data center, pour comprendre encore mieux.

Mais alors, si je veux monter un site antivax, tu me loues un serveur ?

[Marc SCHAEFER]

Marc SCHAEFER <scha...@alphanet.ch> wrote:
> Une alternative est de tourner une attaque soi-même sur les systèmes où
> les mots de passe pourraient être de mauvaise qualité, ou, comme déjà
> dit, de passer à des systèmes basés sur clé publique, voire token du
> temps (dans ce cas en plus du mot de passe choisi par l'utilisateur). Il
> existe d'ailleurs dans le darknet des énormes listes de mots de passe
> déjà utilisés.

Encore deux idées:

1) s'abonner à un service qui centralise les notifications de
piratage, comme par exemple https://haveibeenpwned.com/,
pour tous ses domaines actifs, voire ceux des clients

2) ajouter un fichier secret sur son réseau interne, et scanner
régulièrement le darknet pour sa présence: un peu le degré
zéro d'IDS

J'ai abandonné 2), mais j'avais développé un moteur de recherche à usage
de recherche pour scanner tor il y a des années, qui donnait des
résultats comparables à d'autres initiatives. Par manque de temps, j'ai
arrêté.

Il faut aussi dire qu'il y a apparemment des prestataires dans ce
domaine.

[Eric Demeester]

Bonjour,

Marc SCHAEFER (Sat, 22 Jan 2022 07:32:09 -0000 (UTC)
- fr.comp.securite) :

> Stephane Tougard <step...@unices.org> wrote:
> > On peut aussi avoir un couple login/password raisonnablement compliqué
> > et dormir sur ses deux oreilles.
>
> Et je suis d'accord avec ça, mais quand tu fais du hosting de clients,
> les clients peuvent faire n'importe quoi. Mon dernier piratage avéré (*)
> date de 2009 quand un client avait installé un compte demo avec mot de
> passe demo sur un SSH ouvert sur Internet.

J'ai eu en des temps anciens le cas avec un compte FTP accessible via
admin / admin. C'était avant la généralisation des logiciels BitTorrent,
inutile de dire qu'on a retrouvé des choses diverses et variées sur les
disques de la machine.

Plus sérieusement, j'ai un collègue qui ne comprend pas l'intérêt
d'avoir des couples identifiant / mot de passe raisonnablement
compliqués, « parce que ça déplait aux clients », mais que plus
probablement ça le fatigue de gérer ne serait-ce qu'un fichier texte où
figurerait un couple identifiant / mot de passe par client. Oui, là ils
ont tous le même.

J'avoue que les bras m'en tombent.

[Marc SCHAEFER]

Eric Demeester <neu...@potiron.invalid> wrote:
> J'ai eu en des temps anciens le cas avec un compte FTP accessible via
> admin / admin. C'était avant la généralisation des logiciels BitTorrent,
> inutile de dire qu'on a retrouvé des choses diverses et variées sur les
> disques de la machine.

Il y a aussi les comptes mails, aujourd'hui, utilisés pour le spam.

> Plus sérieusement, j'ai un collègue qui ne comprend pas l'intérêt
> d'avoir des couples identifiant / mot de passe raisonnablement
> compliqués, « parce que ça déplait aux clients », mais que plus
> probablement ça le fatigue de gérer ne serait-ce qu'un fichier texte où
> figurerait un couple identifiant / mot de passe par client. Oui, là ils
> ont tous le même.

Oui, l'identifiant aussi gagnerait à être compliqué:

Dans le cas du mail, un de mes clients est passé du `maison'
user+domaine.ch comme login mail au "plus standard" us...@domaine.ch et
quasi instantanément il a découvert des comptes avec mots de passe
vulnérables.

A voir, la `security through obscurity' du user+domaine.ch plutôt
qu'us...@domaine.ch avait suffit, en près de 20 ans d'exploitation, à
rendre les attaques automatiques inefficaces.

Depuis, il tourne régulièrement une vérification de la force des mots de
passe ... et bloque régulièrement des comptes.

> J'avoue que les bras m'en tombent.

Aussi, sur *mes* serveurs, le mot de passe de l'utilisateur pour le mail
n'est pas le même si le même utilisateur a un compte SSH (si je n'ai pas
réussi à le convaincre d'utiliser une clé publique ...).

Ca casse les pieds, mais c'est l'objectif.