Le 05-06-2019, à 14:23:04 +0200, Yahoo a écrit :
Il est donc possible que soit trop simple
C'est ce qui semble en effet. J'ai choisi un port différent (guess what)
et depuis 4 jours, pas une seule tentative !
Je persiste et signe qu'un DROP est je ne sais combien de fois mieux qu'un
REJECT sur du traffic non legit.
Il le bénéfice de masquer ton service.
Le botnets peuvent avoir le timeout qu'ils veulent même de 1s c'est pas un
problème.
Justement à chaque DROP tu économise un ICMP
Le 07/06/2019 à 18:40, Florian Blanc a écrit :
le client va timeout
Sauf qu'un attaquant ne va pas utiliser des scanners habituels mais des
outils spécifiques qui pour eux DROP ou REJECT ne change rien, leur
timeout sera très court
Une lecture par ex.
le client va timeout
Le ven. 7 juin 2019 à 18:39, Florian Blanc a
écrit :
> > si on peut lister les URL légitimes, un silent DROP systématique permet
> de ne pas confirmer la présence d'une cible potentielle, non ?
> exactement
>
> Le ven. 7 juin 2019 à 18:34, Eric Degenetais a
> écrit :
>
>>
> si on peut lister les URL légitimes, un silent DROP systématique permet
de ne pas confirmer la présence d'une cible potentielle, non ?
exactement
Le ven. 7 juin 2019 à 18:34, Eric Degenetais a
écrit :
> bonjour,
> si on peut lister les URL légitimes, un silent DROP systématique permet de
> ne
bonjour,
si on peut lister les URL légitimes, un silent DROP systématique permet de
ne pas confirmer la présence d'une cible potentielle, non ?
À l'inverse, fail2ban, qui est utile quoi qu'il arrive pour arrêter les
tentatives de brute force qui atteignent le service protégé, a besoin
Le 07/06/19 à 16:39, Florian Blanc a écrit :
> > Et ça change vraiment grand chose ?
> cf. modele OSI ton firewall refusera les connexions layer 3/4.
Merci ;-)
Ce que je voulais dire, c'est que le gain de perfs[1] est tellement
négligeable que je pense qu'on arrive même pas à le mesurer sur
> Et ça change vraiment grand chose ?
cf. modele OSI ton firewall refusera les connexions layer 3/4.
> C'est ça que je comprends pas trop, quel rapport avec ip fixe ou pas ?
> Sans ip fixe ça fonctionne aussi très bien avec un ssh classique sur le
> port 22 (sans ces règles iptables).
Si client
Le 07/06/19 à 03:53, Florian Blanc a écrit :
> Alors non ssh ne recevra seulement les requêtes provenant de l'adresse Ip
> autorisée dans iptables tu le sais, donc tout le reste du traffic sera
> traité par iptables et non par le service.
Et ça change vraiment grand chose ?
Car un ssh qui
C'est dommage on arrive dans tes retranchements, pour quelqu'un
d'omniscient ça doit faire bizarre.
Alors non ssh ne recevra seulement les requêtes provenant de l'adresse Ip
autorisée dans iptables tu le sais, donc tout le reste du traffic sera
traité par iptables et non par le service.
Le 06/06/2019 à 20:10, Florian Blanc a écrit :
Lol tu réduis la charge serveur au lieu de laisser ssh écouter et
répondre à tout le net... (valable pour tous les types
d'authentification ssh)
Merci de me faire savoir si je me trompe
Je pense que oui:
. avec tes règles ssh écoute également
Lol tu réduis la charge serveur au lieu de laisser ssh écouter et répondre
à tout le net... (valable pour tous les types d'authentification ssh)
Merci de me faire savoir si je me trompe
T'es le meilleur Daniel
On Thu, Jun 6, 2019, 19:42 Daniel Caillibaud wrote:
> Le 06/06/19 à 16:51, Florian
Le 06/06/19 à 16:51, Florian Blanc a écrit :
> 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
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
Le 06/06/19 à 10:31, Arnaud Gambonnet a écrit :
> 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.
Pourquoi faire (compliqué) ?
> Ce qui n’empêche pas de
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
> Le 6 juin 2019 à 09:09, Daniel Caillibaud a écrit :
>
> Le 06/06/19 à 08:30, Pierre Malard 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
Le 06/06/19 à 08:30, Pierre Malard 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,
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 «
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
|??
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->). Peut-être faudrait-il que je
mette un port moins
Oui oui ça fait partie de l’Internet standard.
Si cela t’inquiète vraiment, le programme fail2ban peut t’aider.
Cyrille
> Le 5 juin 2019 à 08:37, Belaïd a écrit :
>
> Bonjour,
>
> Pour ma part, tout le temps ! et la quasi totalité des tentatives de
> connexions viennent d'Asie (sans
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.
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
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??:
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,
Bonjour,
Pour ma part, tout le temps ! et la quasi totalité des tentatives de
connexions viennent d'Asie (sans cité un paye en particulier ! )
Le mer. 5 juin 2019 08:32, steve a écrit :
> Salut à tous,
>
> Depuis une dizaine de jours, j'observe une augmentation massive de scans
> sur
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):
28 matches
Mail list logo
