[nicis]

bonjour,
comme vous tous, je suis bombarde de tentative d'acces. evidement, l'access n'est pas possible car dans la vm, n'est autorise que l'IP du support OVH (et l'identification est par cle.
(encore que, je suppose que l'ip est celle du support d'ovh)

juste 2 questions :

au lieu d'ouvrir l'accès a tout le monde, est ce que je peux changer les regles du firewall (windows) pour n'autoriser QUE les IP source que je veux ? je met celle d'OVH et a la limite mon IP publique ADSL pour le cas ou ...

2eme question : en dehors du support et de moi, qu'elle est l'utilisation qui est faite de cet acces ?
est que le host vmware l'utilise pour monitorer la vm ? j'ai arrete le service et alors pleins de warning vmware dans les events logs.
([ warning] [vmusr:vmusr] Error in the RPC receive loop: RpcIn: Unable to send.)

en gros, qu'est ce que je risque a bloquer openssl ?

merci d'avance

[databeille]

Les mails de bann fail2ban ne servent dans les 3/4 des cas à rien à part spammer votre boite mail.

Ou inciter à passer à des solutions plus radicales et sûres (cf. message de shirokoweb http://forum.ovh.com/showthread.php?...l=1#post629642 que je remercie au passage).

[janus57]

Bonjour,

vous utilisez une R3 je suppose, si la réponse est oui y a des tuto sur le forum OVH section dédié, sur le forum kimsufi et sur ce site : http://www.how-to.ovh

Les mails de bann fail2ban ne servent dans les 3/4 des cas à rien à part spammer votre boite mail.

Cordialement, janus57

[jeromedu30]

bonjour

je suis nouveau ici et je viens de prendre un VSP classic (sans réelle connaissance) depuis vendredi matin
je viens de paramétrer webmin grace à un tuto sur internet et j'ai réussi enfin à installer mon cms et tout le bazar !

maintenant je recois continuellement depuis 3 jours des mails de ce type :
[Fail2Ban] SSH: banned 61.174.xx.xxx from vpsxxxxxx.ovh.net

maintenant je comprend mieux ! c'est dingue quand meme ! comment ils ont trouvé mon serveur ? depuis 3 jours chez OVH lol

je suis preneur si vous avez un tuto pour débutant pour paramétrer encore plus Fail2Ban
car j'ai regardé dans webmin (dans Fail2Ban Intrusion Detector)
et je n'ai rien trouvé pour paramétrer : Global Configuration ? Edit Config Files ?

merci

[Nowwhat]

Ceci : est complètement normal http://www.papy-team.org/munin/papy-.../fail2ban.html
Pour m'énerver, je regarde le log de fail12ban
Bien sur, désactive l'envoi d'un mail a chaque ban.
Bien sur, désactive le login par mot de passe, met le système des certificats en place.
L'idée de Abazada, .... trop fort car très logique : je l'ai appliqué de suite. L'accès sur mon serveur passe par UN IPv4 et UN ipv6 maintenant.

[janus57]

passez simplement votre serveur SSH sur un autre port.... Vous aurez bcp bcp bcp moins de problèmes....
Ceci n'empêche pas de configurer fail2ban bien entendu, mais cela évite déjà les zombies...

Bonjour,

perso je préfère avoir un zombie pris dans le SSH au bou_t de 1tentative qu'un zombie qui spam le reste des mes services 1 à 2 fois pour éviter de déclencher fail2ban.

économie de ressources et de toute façons changer de port ne change rien si le zombie est un peu évolué et fait un nmap juste avant.

Changer de port est une "protection" illusoire, cela empêche juste de voir les zombies "basic" venir sur SSH, mais si déjà autant le bloquer sur du SSH port 22 que de le voir plus tard à chercher phpmyadmin en tambourinant apache/nginx.

Ou carrément si on a la flemme de bannir des zombies on utilise knock port, comme ça plus de port SSH ouvert sur le serveur sauf en cas de besoin (après faut pas que le soft plante pour une raison X).

Cordialement, janus57

[sich]

passez simplement votre serveur SSH sur un autre port.... Vous aurez bcp bcp bcp moins de problèmes....
Ceci n'empêche pas de configurer fail2ban bien entendu, mais cela évite déjà les zombies...

[janus57]

pourquoi ne pas bloquer le port 22 sur le pare feu ovh , sauf pour l'ip du propriétaire du serveur.
Cela supprime tout risque non?

Bonjour,

et si on a pas une IP fixe ?

Sinon autant bloquer le port 22 sur le firewall du serveur c'est la même chose, encore faut-il avoir une IP qui est sûre d'être 100% fixe, ce qui n'est pas le cas pour tous les clients Orange (et SFR aussi il me semble).

Donc oui si on a une IP fixe déjà on se whiteliste sur son propre serveur et après on bloque l'accès SSH à notre seule IP.

Cordialement, janus57

[namidaka]

pourquoi ne pas bloquer le port 22 sur le pare feu ovh , sauf pour l'ip du propriétaire du serveur.
Cela supprime tout risque non?

[janus57]

Mois aussi je suis attaqué plus de 10 fois par jours par des russes et autres pays lointains, je pensais qu'il s'agissait d'erreurs sur mes sites !!

Est ce que les VPS sont assez protegés contres ces attaques, y a t'il des failles de sécurité qui pourrait rendre mon pass inefficace ?


a++

Franck

Bonjour,

déjà faut considérer son système de login/password faible face à un login via clé privé/public avec passphrase.

Ensuite non ce sont pas des erreurs juste le bruit de fond de l'internet, vous n'en aviez peut être pas conscience, mais si vous étiez sur du mutualisé avant c'était pareil voir pire.

Donc du moment que son VPS est maintenu à jour, que l'on maintient le site qui est dessus et que l'on sécurise un minimum les logiciel "critique" les "chances" de se faire hack sont faible.

Après si vous installer votre VPS, ne faite jamais les MAJs de votre OS + site + 0sécurisation == très fort risque de hack.

Cordialement, janus57

[CF74]

Mois aussi je suis attaqué plus de 10 fois par jours par des russes et autres pays lointains, je pensais qu'il s'agissait d'erreurs sur mes sites !!

Est ce que les VPS sont assez protegés contres ces attaques, y a t'il des failles de sécurité qui pourrait rendre mon pass inefficace ?


a++

Franck

[janus57]

Bonjour,

regarde tu verra peut être que ces serveur zombies utilisent un panel (plesk, cpanel ou autre) car en général c'est ça, les personnes utilise un panel mais ne font pas les MAJ serveur/panel et il tombe au main des hacker.

Du coup fail2ban n'est pas vraiment inutile, cela bloque 668 zombie à l'entré de votre serveur, donc sa fait 668 zombies en moins qui vont taper vos autres services (web, mail, TS, mumble ou autre).

Et cela fait "juste " 668 tentative si on config fail2ban a 1tentative.

Cordialement, janus57

[Abazada]

A propos d'attaque SSH:

Il est 13h12 et j'en suis déjà depuis 12h02 à 668 IPs qui ont essayé successivement de se connecter root via ssh sur un Vps Classic.
Pas grand chose à faire à part les regarder échouer lamentablement
Fail2ban totalement inutile car chaque IP fait sa série de tentative puis une autre prend le relai.
J'ai checké quelques IP; ça vient de partout: USA, Brésil, Chine, Ukraine, France,...

[Abazada]

Petite remarque:
Un moyen simple de limiter les attaque SSH est de limiter le nombres d'entrées sur votre serveur

Par défaut en effet sshd écoute sur toutes les interfaces, donc toutes les IpFo. Nombre de serveurs aujourd'hui ont 10, 20 (ou plus!) IpFo; ça multiplie donc par autant la probabilité de recevoir une attaque sur le serveur...

Ca dépend bien sûr de la manière dont vous donnez les accès à votre serveur, mais perso le sshd n'est dispo que sur l'adresse Ip physique du serveur, pas sur les IpFo. Il suffit pour cela d'une clause ListenAddress dans le /etc/ssh/sshd_config sur Debian.

[janus57]

Bonjour,

Merci Janus57 voici cet avis constructif , cela sent le vécu !
Pour le login 'root' curieusement il n'y a JAMAIS de tentative de connexion sur ce compte privilégié.

Il y en a toujours mais c'est noyé dans la masse des autres, suffit de mettre en place logwatch, on le vois très bien que root est encore utilisé.

Je viens de mettre en place la connexion par clé , cela fonctionne parfaitement,
je désactiverai la connexion par mot de passe dès que j'aurai pris mes repères...
et pour le port 22 je crois que je ne vais toucher à rien.

Christian

Si vous allez mettre des sites web vous pouvez à la limiter passer par cloudflare, perso j'y vois 2avantages : cache CDN au niveau des fichiers statique + DNS ET un petit pré-filtrage des robots niveau web.

Et aussi si c'est des sites "sensibles" qui risque de se faire (D)DoS, un cloudflare bien config empêche de voir l'IP originale du site (cela la masque mais c'est pas une solution magique hein).

Cordialement, janus57

[cricri68]

Merci Janus57 voici cet avis constructif , cela sent le vécu !
Pour le login 'root' curieusement il n'y a JAMAIS de tentative de connexion sur ce compte privilégié.

Je viens de mettre en place la connexion par clé , cela fonctionne parfaitement,
je désactiverai la connexion par mot de passe dès que j'aurai pris mes repères...
et pour le port 22 je crois que je ne vais toucher à rien.

Christian

[janus57]

Bonjour,

le changement de port est superflus si le robot est assez intelligent pour passer un coup de nmap avant de venir sur le SSH.

De plus même si il viens sur le port SSH par défaut (le 22 donc) si il rencontre fail2ban il vous fera bonjour et fail2ban lui dira au-revoir pour la durée que vous avez programmé, donc 1zombie en moins qui vous fera chier, que ce soit sur le 22 ou le 80, faut résonner dans le sens ou que si le pirate utiliser des zombie sur SSH il peu faire la même sur vos site web, donc si il arrive pas à contacter votre port 22 il va peut être faire chier votre serveur web, donc au finale vaux mieux qu'il se fasse bann pour bruteforce SSH que du bruteforce web avec au passage de la consommation du serveur web pour encaisser le bruteforce.

Surtout si vous utilisé des CMS de type wordpress, les robots zombies adorent.

Pour le login root le mieux serait de mettre ceci : permitrootlogin without-password
comme cela root accepte seulement et uniquement les connexion par clé privé/public RSA/DSA.

couplé au fail2ban à 1connexion puis bann 1mois et voilà de 100 à 1000 zombies bloqué par mois.

Cordialement, janus57

[Rizz]

Shirokoweb t'a fait un beau résumé des 36 tutaux que tu trouvera sur le net pour protéger ton acces SSh.
Pourquoi tu fais de la crotte ? XD

[cricri68]

Merci 'shirokoweb' pour tes conseils, je vais regarder du coté des clés RSA, c'est ce qui semble le mieux.

Quelques détails supplémentaires sur mes attaques : deux noms de logins très courants sont : "PlcmSpIP" et "vyatta"
quel est l'intérêt d'utiliser ce genre de logins qui n'existent nulle part ? et surtout en provenance de dizaines d'IP différentes ?

Bon, pour le moment j'ai fermé tout accès SSH mis à part celle de mon FAI en utilisant les possibilités
de /etc/hosts.allow et /etc/hosts.deny

Joyeux Noël
Christian

[shirokoweb]

En complément de ce qui a été dit, les bases de la sécurisation SSH, outre les jailkit, f2b etc etc : (en assumant qu'il s'agisse d'une distro linux, type Debian au hasard )

Modifier le mot de passe root :

passwd

Ajouter un nouveau groupe avec un nouvel utilisateur :

groupadd sshusers

useradd -m NomUtilisateurImprobableHaHa
passwd NomUtilisateurImprobableHaHa
usermod -a -G sshusers NomUtilisateurImprobableHaHa

Configuration du SSH avec votre éditeur préféré (vi, nano...) :

vim /etc/ssh/sshd_config

Changer le port par défaut (22) :

Port 2222 (choisir un port qui n'est pas / ne sera pas utilisé hein)

Interdire la connexion en SSH à l'utilisateur 'root' :

PermitRootLogin no

et n'autoriser que les utilisateurs du groupe sshusers :

AllowGroups sshusers (il faut créer la ligne)

Check de la version du protocole utilisée :

Protocol 2

Redémarrer SSH :

/etc/init.d/ssh restart

ATTENTION ! Avnat de fermer le terminal, ouvrir un nouveau terminal et s'assurer :
- Quel le root ne peut pas se connecter à la machine via SSH
- Que l'utilisateur NomUtilisateurImprobableHaHa arrive à se connecter...

Encore plus de sécurisation ? Utiliser des clefs de connexion

Créer un répertoire .ssh (s'il n'existe pas) :

cd
mkdir .ssh
touch .ssh/authorized_keys

Générer la clef :

ssh-keygen -t rsa

Répondre aux questions :

Enter file in which to save the key (/Users/NomUtilisateurImprobableHaHa/.ssh/id_rsa): --> valider avec Entrée
Enter passphrase (empty for no passphrase): choisir un mot de passe pour protéger la clef

Copier la clef dans le répertoire de l'user :

ssh @ -p  "echo $(cat ~/.ssh/id_rsa.pub) >> .ssh/authorized_keys"

Voilà, à présent toute connexion au serveur se fera au moyen de clefs.
Si vous avez besoin de 'connecter' le root, faites un switch user: 'su -' et saisir le mot de passe associé au root.

[janus57]

Bonjour,

attention lors des bann de plage IP, non seulement vous allez bloquer les robots d’indexation, mais en plus vous allez bloquer les français avec des IP étrangères et/ou avec des VPN.

Le plus simple est de config fail2ban (1tentative) et mettre SSH en accès clé privé/public, pas de risque de bann niveau SSH et tout les robots ou serveur infectés se font bann, perso le temps de bann est 14jours, certaines mettent plusieurs mois.

Cordialement, janus57

[databeille]

Tout pareil, en provenance de Chine, Hong-Kong, Brésil, FRANCE (!!!)...
Des machines infectées ou des serveurs corrompus, probablement.

J'ai abaissé la tolérance de fail2ban à 2 tentatives échouées sur SSH, avec bannissement de 1 mois.
Je me suis banni moi-même l'autre jour :P, mais on peut toujours gérer iptables depuis webmin.

Mon serveur n'étant destiné qu'à la France, j'envisage de bloquer purement et simplement toutes les IP non françaises.

[cricri68]

Bonjour,

J'ai de plus en plus d'attaques sur le port ssh de mon vps déjouées pour le moment par un 'fail2ban' efficace.
Ces attaques viennent de nombreuses IP différentes, ceci est inquiétant.

Quelques exemples d'ip avec un nom du login 'arbab'
62.14.231.74 42.120.48.236 221.231.143.4 49.212.18.109 222.87.19.131

Toutes ces machines hébergent-elles des pirates, humain ou robot, ou bien s'agit-il d'usurpation d'IP afin d'arriver à contourner les fail2ban ?
Avant de fermer complètement l'accès de mon vps et ne laisser rentrer que les plages ip connues j'aurais aimé avoir votre avis.

Bonnes fêtes de Noël
Christian