gratifiant > linux.debian.user.french

steve (05/06/2019, 08h40)
Salut à tous,

Depuis une dizaine de jours, j'observe une augmentation massive de scans
sur ma machine.

sshd:
Authentication Failures:
unknown (115.159.235.17): 100 Time(s)
unknown (153.37.192.4): 99 Time(s)
unknown (183.103.146.208): 99 Time(s)
unknown (190.0.159.69): 99 Time(s)
unknown (106.13.103.204): 98 Time(s)
unknown (109.86.200.141): 98 Time(s)
unknown (94.23.62.187): 98 Time(s)
unknown (45.127.106.51): 96 Time(s)
unknown (103.202.132.175): 95 Time(s)
unknown (217.182.95.16): 95 Time(s)
unknown (47.74.150.153): 95 Time(s)
unknown (220.168.86.37): 87 Time(s)
unknown (122.155.223.31): 73 Time(s)
unknown (190.111.239.48): 70 Time(s)
unknown (188.166.31.205): 56 Time(s)
unknown (47.254.158.221): 48 Time(s)
unknown (51.15.117.94): 47 Time(s)
unknown (142.93.237.233): 34 Time(s)
unknown (223.83.155.77): 16 Time(s)
unknown (41.77.145.34): 13 Time(s)
unknown (118.24.99.163): 12 Time(s)
unknown (46.190.57.82): 9 Time(s)
unknown (89.79.197.61): 9 Time(s)
unknown (115.159.30.108): 8 Time(s)
backup (188.166.31.205): 2 Time(s)
root (104.236.102.16): 2 Time(s)
root (223.17.237.138): 2 Time(s)
unknown (128.199.221.18): 2 Time(s)
backup (103.202.132.175): 1 Time(s)
backup (47.254.158.221): 1 Time(s)
backup (47.74.150.153): 1 Time(s)
daemon (45.127.106.51): 1 Time(s)
backup (188.166.31.205): 2 Time(s)
root (104.236.102.16): 2 Time(s)
root (223.17.237.138): 2 Time(s)
unknown (128.199.221.18): 2 Time(s)
backup (103.202.132.175): 1 Time(s)
backup (47.254.158.221): 1 Time(s)
backup (47.74.150.153): 1 Time(s)
daemon (45.127.106.51): 1 Time(s)
games (103.202.132.175): 1 Time(s)
games (188.166.31.205): 1 Time(s)
games (94.23.62.187): 1 Time(s)
gnats (159.65.144.233): 1 Time(s)
gnats (190.111.239.48): 1 Time(s)
gnats (45.127.106.51): 1 Time(s)
hplip (103.202.132.175): 1 Time(s)
irc (106.13.103.204): 1 Time(s)
irc (217.182.95.16): 1 Time(s)
irc (41.77.145.34): 1 Time(s)
irc (47.74.150.153): 1 Time(s)
list (47.254.158.221): 1 Time(s)
lp (217.182.95.16): 1 Time(s)
mail (103.202.132.175): 1 Time(s)
man (115.159.30.108): 1 Time(s)
man (153.37.192.4): 1 Time(s)
man (47.74.150.153): 1 Time(s)
mysql (109.86.200.141): 1 Time(s)
mysql (153.37.192.4): 1 Time(s)
mysql (190.111.239.48): 1 Time(s)
mysql (202.88.241.107): 1 Time(s)
mysql (45.127.106.51): 1 Time(s)
mysql (51.15.117.94): 1 Time(s)
mysql (81.133.216.92): 1 Time(s)
mysql (94.23.62.187): 1 Time(s)
news (190.0.159.69): 1 Time(s)
news (47.74.150.153): 1 Time(s)
nobody (118.25.221.166): 1 Time(s)
nobody (217.182.95.16): 1 Time(s)
plex (217.182.95.16): 1 Time(s)
proxy (103.202.132.175): 1 Time(s)
proxy (47.74.150.153): 1 Time(s)
root (104.248.211.180): 1 Time(s)
root (105.235.116.254): 1 Time(s)
Invalid Users:
Unknown Account: 1610 Time(s)

Je me demandais si vous observiez la même chose.

Merci

Steve
Eric Degenetais (05/06/2019, 09h20)
Il y a 5 ans déjà, je constatais des scans à longueur de journées sur l'ip
publique serveurs sans nom de domaine, dès leur première journée. Il y a
clairement une exploration systématique de certaines plages IP à la
recherche de serveurs à subvertir.

Éric Dégenètais

Le mer. 5 juin 2019 8:37 AM, Belaïd <oblivion.ikiub> a écrit :
[..]
Yahoo (05/06/2019, 09h30)
Bonjour,

c'est quasiment tous le temps, si tu veux limiter cela tu peux modifier
le port de ta connexion ssh, cela ??vite une bonne partie de ces bots,

ensuite tu peux mettre fail2ban pour les irr??ductibles que trouverais le
bon ports.

Lo??c

Le 05/06/2019 ?? 08:32, steve a ??crit??:
[..]
Jean Millet (05/06/2019, 10h20)
Bonjour,

J?observe cela depuis plusieurs années. au départ les bot chinois qui
sont très actifs puis d'autres.

Chez GuppY (CMS) nous avons préconisé l'utilisation de blocage de plages
IP dans le .htaccess à la racine des sites hébergés en mutualisé et nous
utilisons iptables sur nos serveurs

Exemple pour les htaccess à la racine des sites :

<Files *>
  <RequireAll>
    Require all granted

# Cambodia (KH)
Require not ip 114.134.184.0/21
# Chinese (CN) IP addresses follow (split into two lines on 7/6/17 to
avoid possible Server 500 due to excess line length):
Require not ip 1.24.0.0/13 1.48.0.0/15 1.50.0.0/16 1.56.0.0/13
1.68.0.0/14 1.80.0.0/13 1.92.0.0/14 1.180.0.0/14 1.188.0.0/14
1.192.0.0/13 1.202.0.0/15 1.204.0.0/14 14.16.0.0/12 14.104.0.0/13
14.112.0.0/12 14.134.0.0/15 14.144.0.0/12 14.204.0.0/15 14.208.0.0/12
23.80.54.0/24 23.104.141.0/24 23.105.14.0/24 23.226.208.0/24 27.8.0.0/13
27.16.0.0/12 27.36.0.0/14 27.40.0.0/13 27.50.128.0/17 27.54.192.0/18
27.106.128.0/18 27.115.0.0/17 27.148.0.0/14 27.152.0.0/13 27.184.0.0/13
27.192.0.0/11 27.224.0.0/14 36.1.0.0/16 36.4.0.0/14 36.26.0.0/16
36.32.0.0/14 36.36.0.0/16 36.40.0.0/13 36.48.0.0/15 36.56.0.0/13
36.96.0.0/11 36.128.0.0/11 36.248.0.0/14 39.64.0.0/11 39.128.0.0/10
42.4.0.0/14 42.48.0.0/15 42.52.0.0/14 42.56.0.0/14 42.84.0.0/14
42.88.0.0/13 42.96.128.0/17 42.100.0.0/14 42.120.0.0/14 42.156.0.0/16
42.176.0.0/13 42.185.0.0/16 42.202.0.0/15 42.224.0.0/12 42.242.0.0/15
42.248.0.0/15 43.255.0.0/20 43.255.16.0/22 43.255.48.0/22 43.255.60.0/22
43.255.64.0/20 43.255.96.0/20 43.255.144.0/22 43.255.168.0/22
43.255.176.0/22 43.255.184.0/22 43.255.192.0/22 43.255.200.0/21
43.255.208.0/21 43.255.224.0/21 43.255.232.0/22 43.255.244.0/22
47.88.0.0/14 47.92.0.0/14 49.5.0.0/16 49.64.0.0/11 49.112.0.0/13
54.222.0.0/15 58.16.0.0/14 58.20.0.0/16 58.21.0.0/16 58.22.0.0/15
58.34.0.0/16 58.37.0.0/16 58.38.0.0/16 58.40.0.0/16 58.42.0.0/16
58.44.0.0/14 58.48.0.0/13 58.56.0.0/14 58.60.0.0/14 58.68.128.0/17
58.82.0.0/15 58.100.0.0/15 58.116.0.0/14 58.128.0.0/13 58.208.0.0/12
58.240.0.0/13 58.248.0.0/13 59.32.0.0/12 59.48.0.0/14 59.52.0.0/14
59.56.0.0/13 59.72.0.0/16 59.108.0.0/15 59.172.0.0/14 60.0.0.0/12
60.11.0.0/16 60.12.0.0/14 60.16.0.0/13 60.24.0.0/13 60.160.0.0/11
60.194.0.0/15 60.205.0.0/16 60.208.0.0/12 60.253.128.0/17 61.4.64.0/20
61.4.80.0/22 61.4.176.0/20 61.48.0.0/13 61.128.0.0/10 61.135.0.0/16
61.136.0.0/18 61.139.0.0/16 61.145.73.208/28 61.147.0.0/16 61.150.0.0/16
61.152.0.0/16 61.154.0.0/16 61.160.0.0/16 61.162.0.0/15 61.164.0.0/16
61.172.0.0/15 61.175.0.0/16 61.177.0.0/16 61.179.0.0/16 61.183.0.0/16
61.184.0.0/16 61.185.219.232/29 61.187.0.0/16 61.188.0.0/16
61.232.0.0/14 61.236.0.0/15 61.240.0.0/14

Etc

__________________________________________________ ________________________

pour iptables :

iptables -I INPUT 1 -s 212.83.144.0/20 -j DROP
iptables -I INPUT 1 -s 118.200.0.0/16 -j DROP
iptables -I INPUT 1 -s 207.46.0.0/16 -j DROP
iptables -I INPUT 1 -s 54.254.0.0/16 -j DROP
iptables -I INPUT 1 -s 91.224.160.0/23 -j DROP
iptables -I INPUT 1 -s 175.100.144.0/20 -j DROP
iptables -I INPUT 1 -s 134.212.0.0/15 -j DROP
iptables -I INPUT 1 -s 134.214.0.0/16 -j DROP
iptables -I INPUT 1 -s 190.255.176.88/29 -j DROP
iptables -I INPUT 1 -s 118.70.176.0/20 -j DROP
iptables -I INPUT 1 -s 195.154.0.0/17 -j DROP
iptables -I INPUT 1 -s 91.200.12.0/22 -j DROP
iptables-save -c > /etc/iptables-save

Etc

Amicalement,
Jean alias JeandePeyrat



d'autres !

Le 05/06/2019 à 08:32, steve a écrit :
[..]
Yann Serre (05/06/2019, 10h50)
Bonjour,

Même si vous faites parti des personnes sensibilisées, voici un article
de presse grand public. Je pense que ça a un rapport avec le sujet même
si la piste mafieuse serait probablement à privilégier.

Cyrille Bollu (05/06/2019, 11h30)
Oui oui ça fait partie de l?Internet standard.

Si cela t?inquiète vraiment, le programme fail2ban peut t?aider.

Cyrille
[..]
steve (05/06/2019, 13h40)
Le mercredi 05 juin 2019, Yahoo a écrit :

> Bonjour,
> c'est quasiment tous le temps, si tu veux limiter cela tu peux modifier le
> port de ta connexion ssh, cela évite une bonne partie de ces bots,


Déjà fait depuis longtemps (22->2222). Peut-être faudrait-il que je
mette un port moins évident ?

> ensuite tu peux mettre fail2ban pour les irréductibles que trouverais le
> bon ports.


# fail2ban-client status sshd
Status for the jail: sshd
|- Filter
| |- Currently failed: 2
| |- Total failed: 11952
| `- File list: /var/log/auth.log
`- Actions
|- Currently banned: 3
|- Total banned: 54
`- Banned IP list: 73.15.91.251 104.248.187.179 41.223.142.211

Mais en fait ma question était plus sur une éventuelle augmentation de
la fréquence de scan que sur les méthodes de mitigation que je connais
déjà et qui sont en place.
Yahoo (05/06/2019, 14h30)
D??sol??, je n'avais pas compris ta demande.

Donc sur la fr??quence, de mon c??t?? j'ai tr??s peu d'attaque force brut
sur le service ssh, mais effectivement j'utilise un port un peu plus
exotique que le tiens

la vue pour un serveur up depuis 1 ans:

Status for the jail: sshd
|- Filter
|?? |- Currently failed: 0
|?? |- Total failed:???????? 23
|?? `- File list:?????????????? /var/log/auth.log
`- Actions
???? |- Currently banned: 0
???? |- Total banned:???????? 1
???? `- Banned IP list:

Il est donc possible que 2222 soit trop simple

Le 05/06/2019 ?? 13:33, steve a ??crit??:
[..]
Pierre Malard (06/06/2019, 09h00)
Bonjour,

Sans présumer de qui est le plus « méchant » (Chinois, Russes, USA, Fr?) et pratique
le scan massif, je ne saurait trop conseiller un filtrage avec la limitation des
ports ouverts par un pare-feu et, sur les serveurs ouverts, l?installation de
« Fail2Ban » en validant les règles « récidive ».

Pour ceux qui ne savent pas entendre raison il y a le truc de « ban-them » qui
construit une liste à chaud de ceux-là et ? les bannis définitivement. C?est
très utile et évite de faire tout ça à la main :

Cela demande tout de même une surveillance pour éviter les faux positifs mais
c?est très bien.

Cordialement
[..]
Daniel Caillibaud (06/06/2019, 09h10)
Le 06/06/19 à 08:30, Pierre Malard <plm> a écrit:
> Bonjour,
> Sans présumer de qui est le plus « méchant » (Chinois, Russes, USA, Fr?)
> et pratique le scan massif, je ne saurait trop conseiller un filtrage
> avec la limitation des ports ouverts par un pare-feu et, sur les serveurs
> ouverts, l?installation de « Fail2Ban » en validant lesrègles « récidive
> ».


Sur un serveur en prod, l'intérêt d'un pare-feu est quand même très limité
(éventuellement pour gérer du throttle), à priori si un portest ouvert sur
une ip publique c'est qu'on veut qu'il soit accessible (sinon on l'aurait
pas ouvert là).

Pour le sshd, le plus efficace reste encore de le configurer pour interdire
la connexion par mot de passe, ensuite fail2ban n'est plus nécessaire
(sinon pour réduire le bruit dans auth.log).

Il faut mettre dans /etc/ssh/sshd_config la ligne :

PasswordAuthentication no
Pierre Malard (06/06/2019, 09h20)
> Le 6 juin 2019 à 09:09, Daniel Caillibaud <ml> a écrit :
> Le 06/06/19 à 08:30, Pierre Malard <plm> a écrit :
> Sur un serveur en prod, l'intérêt d'un pare-feu est quand même très limité
> (éventuellement pour gérer du throttle), à priori si un port est ouvert sur
> une ip publique c'est qu'on veut qu'il soit accessible (sinon on l'aurait
> pas ouvert là).


Effectivement c?est pourquoi il y avait un « et » et non un « ou ».

> Pour le sshd, le plus efficace reste encore de le configurer pour interdire
> la connexion par mot de passe, ensuite fail2ban n'est plus nécessaire
> (sinon pour réduire le bruit dans auth.log).
> Il faut mettre dans /etc/ssh/sshd_config la ligne :
> PasswordAuthentication no


Effectivement, c?est même l?option par défaut sur toute installation
actuellement. C'était, dans mon esprit, la configuration de base mais il est vrai
que ce n?est pas parce que « ça allait sans le dire qu?il ne faut pas ?
le dire ».

Merci
Arnaud Gambonnet (06/06/2019, 10h40)
Bonjour la liste,

Je n'ai pas lu en détails le fil, mais pour protéger les demandes
intempestives de connexions ssh (et d'autres si besoin), il existe la
solution de port knocking.
Ce qui n?empêche pas de mettre en place une authentification par certificat
et fail2ban pour les services moins sensibles.

Bonnes cogitations...

Le jeu. 6 juin 2019 à 09:18, Pierre Malard <plm> a écrit :
[..]
Daniel Caillibaud (06/06/2019, 15h50)
Le 06/06/19 =C3=A0 10:31, Arnaud Gambonnet <arnaud.gambonnet> a =
=C3=A9crit :
> Bonjour la liste,
>=20
> Je n'ai pas lu en d=C3=A9tails le fil, mais pour prot=C3=A9ger les demand= es
> intempestives de connexions ssh (et d'autres si besoin), il existe la
> solution de port knocking.


Pourquoi faire (compliqu=C3=A9) ?

> Ce qui n=E2=80=99emp=C3=AAche pas de mettre en place une authentification= par
> certificat et fail2ban pour les services moins sensibles.


Au contraire, auth par certif pour tous les serveurs, sensibles ou pas, et
plus besoin de port knocking ni port exotique ni fail2ban, on peut rester
sur du standard avec ssh sur le port 22 qui fonctionne comme attendu.

--=20
Daniel

On devient jeune =C3=A0 soixante ans.
Malheureusement c'est trop tard.
Pablo Picasso
Florian Blanc (06/06/2019, 17h00)
Bon je vais vous livrer un petit secret.
J'utilise des noip qui mettent à jour mon ip public cliente sur un dns..

Sur mon script principal iptables je crée une chain qui s'appelle INDYNAMIC
à partir de INPUT:
/sbin/iptables -A INPUT -j INDYNAMIC

Ensuite j'ai un second script iptables pour écraser mes regles dynamique
comme ceci:
/sbin/iptables -F INDYNAMIC # ici je flush
/sbin/iptables -A INDYNAMIC -m tcp -p tcp --src lolilol.dyndnsnoiplalala.io
--dport 22 -j ACCEPT # j'autorise lolilol.dyndnsnoiplalala.io sur le port
22 (il fait la résolution comme un grand).

je crontab ce dernier script qui s'execute toutes les x minutes (20 par
exemple).
tu le combine à fail2ban et c'est bon.

Le jeu. 6 juin 2019 à 15:45, Daniel Caillibaud <ml> a
écrit :
[..]
Daniel Caillibaud (06/06/2019, 19h50)
Le 06/06/19 =C3=A0 16:51, Florian Blanc <florian.blanc.adm> a =C3=
=A9crit :
[..]
> je crontab ce dernier script qui s'execute toutes les x minutes (20 par
> exemple).
> tu le combine =C3=A0 fail2ban et c'est bon.


C'est bien ce que je disais :

> > Pourquoi faire (compliqu=C3=A9) ?


Car je ne vois aucun avantage par rapport =C3=A0 ne rien faire (en dehors de
virer l'auth par mot de passe si c'est pas d=C3=A9j=C3=A0 le cas).

--=20
Daniel

Certaines zones de p=C3=AAche commencent a =C3=AAtre tellement pollu=C3=A9e=
s=20
par les hydrocarbures qu'on y p=C3=AAche des turbots diesels.
Philippe Geluck, Le chat

Discussions similaires