OVH Community, votre nouvel espace communautaire.

Attaque SSH sur mon VPS


nicis
10/01/2015, 17h35
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
05/01/2015, 14h50
Citation Envoyé par janus57

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
04/01/2015, 13h41
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
04/01/2015, 09h57
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
28/12/2014, 23h48
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
28/12/2014, 20h31
Citation Envoyé par 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...
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
28/12/2014, 18h30
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
28/12/2014, 14h49
Citation Envoyé par 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?
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
28/12/2014, 14h04
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
26/12/2014, 00h13
Citation Envoyé par 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
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
25/12/2014, 19h47
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
25/12/2014, 14h12
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
25/12/2014, 13h19
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
24/12/2014, 13h25
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
24/12/2014, 13h15
Bonjour,
Citation Envoyé par 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é.
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é.


Citation Envoyé par cricri68
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
24/12/2014, 11h52
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
23/12/2014, 20h09
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
23/12/2014, 18h55
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
23/12/2014, 18h27
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
23/12/2014, 13h55
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 :
Code:
passwd
Ajouter un nouveau groupe avec un nouvel utilisateur :
Code:
groupadd sshusers
Code:
useradd -m NomUtilisateurImprobableHaHa
passwd NomUtilisateurImprobableHaHa
usermod -a -G sshusers NomUtilisateurImprobableHaHa
Configuration du SSH avec votre éditeur préféré (vi, nano...) :
Code:
vim /etc/ssh/sshd_config
Changer le port par défaut (22) :
Code:
Port 2222 (choisir un port qui n'est pas / ne sera pas utilisé hein)
Interdire la connexion en SSH à l'utilisateur 'root' :
Code:
PermitRootLogin no
et n'autoriser que les utilisateurs du groupe sshusers :
Code:
AllowGroups sshusers (il faut créer la ligne)
Check de la version du protocole utilisée :
Code:
Protocol 2
Redémarrer SSH :
Code:
/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) :
Code:
cd
mkdir .ssh
touch .ssh/authorized_keys
Générer la clef :
Code:
ssh-keygen -t rsa
Répondre aux questions :
Code:
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 :
Code:
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
23/12/2014, 13h08
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
23/12/2014, 11h53
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
23/12/2014, 10h43
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