[superkikim]

Merci pour vos réponses constructives.

J'aurais du commencé par venir ici m'énerver, ça répond plus facilement et c'est très aidant

@Abazada

En effet, le guide en question contient une liste de host, je vais vérifier si c'est bien les hosts qui m'occupent, et entrer les règles.

Je suis sur des VPS Cloud et un VPS Classic. Dès lors, le monitoring hardware ne m'intéresse aucunement. OVH est à même de monitorer ses hosts directement. Ca ne craint donc rien... Et je dois dire que côté fiabilité, c'est irréprochable jusqu'ici. Il se pourrait donc que je désactive ce monitoring car si quoi que ce soit se passe à l'intérieur de la VM, c'est pas OVH qui va le prendre en charge... Si le réseau ou le stockage arrête de fonctionner, je ne serai pas le seul concerné

Merci pour l'info pour la clé root. En effet, je n'ai pas vérifié J'avais juste envie de mettre de l'huile sur le feu Y a des jours comme ça.

@nowwhat

Pas d'accord avec toi pour iptables. Depuis que j'ai sécurisé mon serveur en verrouillant tout, je suis bien plus tranquille qu'avant. Et encore plus depuis que j'ai changer le port de SSH. Que du bonheur. Car même si tu utilises fail2ban, ça n'empêche pas l'assaillant de faire des tentatives depuis d'autres IP. Quand c'est des bot-farms qui attaquent, c'est la galère, et ça m'est arrivé en série il y a quelques temps. C'est vrai que j'ai galéré pour avoir le set de règles IP qu'il me fallait, et aujourd'hui, tout mes services fonctionnent "as expected". Donc tout ce qui est bloqué par iptables n'est pas vital pour ma production.

Pour ce qui est de la clé privée, si tu l'article de mon blog, tu verras que c'est ce que j'ai fait Pas de password et pas de login root par ssh, et un sudo limité. Aujourd'hui, je suis particulièrement content de mon niveau de sécurité, même si c'est certain qu'on peut faire mieux. Je ne suis pas un pro de la sécurité. Si je l'étais, j'aurais même implémenté et configuré SELinux Mais ça, comme beaucoup, j'ai abandonné

[Abazada]

Ouais ben moi ça me gonfle un peu, même beaucoup.....

Euh.... Faut pas pousser quand même. Mise à part déjà le fait que la plupart des réponses à tes questions sont dans les guides OVH, il est logique qu'OVH contrôle le ping de ton serveur vu que c'est ce qu'il garantit par contrat! Le monitoring des serveurs, je suis certains que plus de 90% des personnes le réclame; c'est donc logique que ce soit activé par défaut.
Bloquer les monitoring OVH via iptables c'est une méthode de bourrin... Tu cours en plus le risque qu'OVH reboot ton serveur à tout moment vu que n'ayant plus de ping il va croire à un problème.
Le détail des IP à exclure et à autoriser est donné dans les guides - encore - par exemple ici: http://guide.ovh.com/firewall
Maintenant si tu veux faire ça propre et renoncer au "ping contractuel d'OVH", tu va dans ton ManagerV6 et tu cliques sur le switch "SLA Monitoring" qui par défaut est à "Yes". Il va passer à "No" et OVH ne viendra plus t'incommoder .... et accessoirement n'interviendra peut-être plus en cas de panne
Pour la clef root, OVH n'en installe plus depuis pas mal de temps déjà. Tu aurais pu le vérifier toi-même sur ton serveur , mais tu préfère critiquer sur un soi-disant problème de sécurité qui en fait n'existe pas...

Bonne journée

[Nowwhat]

Ouais ben moi ça me gonfle un peu, même beaucoup....
....
....
Tant qu'ils font le monitoring hardware, le reste, je n'en ai pas besoin.

Ou alors OVH nous fournit des règles iptables une bonne fois pour toute qui permet d'autoriser leurs serveurs sur tous les ports, avec la liste des IPs pour chaque hosts. Mais reste que je ne serais pas très à l'aise avec ça.
...

Fait comme moi, VIRE toutes les règles iptables et passe les policies sur ACCEPT. Fini. T'es bon.
Car : surprise : inutile de protéger des "trou-noirs" (portes non-servis).
Par contre - l'outil fail2ban est très utile pour protéger des portes qui ont une service attaché (ftp, ssh, telnet,pop, smtp, http,dns,https, etc). C'est lui qui injecte des règles "iptables" si nécessaire.

Le monitoring hardware, a ton avis, ça se fait comment ? => Un scripts appelé "rtm" s’exécute chaque 5 minutes, puis il va envoyer (UDP) les données vers le serveur "OVH" de collecte. Tu trouveras facilement quel IP et quel porte il s'agit - protocole = UDP.

Il est possible de arrêter le montoring d'OVH. ca se fait dans le Manager. Mais attention: dès que ton serveur s'écrase, il ne va pas te prévenir non plus ...

Saviez-vous qu'OVH installe sur ses distributions une clé privée pour l'utilisateur root ? J'appelle pas ça vraiment de la sécurité. Si la clé est volée, c'est pour tous les serveurs.

Oui, c'est comme ça depuis le début. Vire-le si tu le souhaite.
Vire aussi la possibilité de rentrer avec un mot de passe, fait pareil que OVH : CLE-privé uniquement et coté SSH t'es blindé.

[superkikim]

Ouais ben moi ça me gonfle un peu, même beaucoup....

Déjà, j'aimerais bien savoir pourquoi un serveur linux est monitoré pour le port 3389. Ensuite, pour augmenter la sécurité de mon serveur, j'ai changé le port de SSH, donc que OVH vérifie le port 22 ne fait que me pourrir mon log iptables. Et ça fait au moins la troisième IP OVH que je dois ajouter dans mes exceptions...

On peut pas désactiver tout ça ? Le monitoring intra-OS, je le fais moi-même... Tant qu'ils font le monitoring hardware, le reste, je n'en ai pas besoin.

Ou alors OVH nous fournit des règles iptables une bonne fois pour toute qui permet d'autoriser leurs serveurs sur tous les ports, avec la liste des IPs pour chaque hosts. Mais reste que je ne serais pas très à l'aise avec ça.

Saviez-vous qu'OVH installe sur ses distributions une clé privée pour l'utilisateur root ? J'appelle pas ça vraiment de la sécurité. Si la clé est volée, c'est pour tous les serveurs.

Bref. Un peu de sécurité, de nos jours, c'est indispensable. Pour ceux que ça intéresse, j'ai rédigé un article sur mon blog sur le sujet. Il n'y a pas mes dernières modifications, mais ça donne déjà des pistes.

[buddy]

les adresses qui finissent par 250 ou 251 sont les adresses de monitoring ( 249 pour les HG aussi )

[Moof26]

Donc au final on ne sait toujours pas ce que fait cette IP. Mais je suis presque sur que c'est une IP d'ovh qui scan les ports pour pouvoir afficher les couleurs rouge ou verte en face des services DNS, SMTP, etc... dans le manager VPS.

Pour en avoir le coeur net, j'ai banni complètement cette ip avec iptables, et effectivement, tout s'est affiché en rouge dans le manager VPS. C'est donc bien ce que tu pensais.
Merci !

[gaboul49]

L'avant dernière ip que j'obtiens, c'est 178.33.100.126
Donc ça si je comprends bien, c'est la passerelle de mon vps (désolé si je dis de la merde, je débute) ?

Non c'est le serveur physique qui fait tourner des machines virtuelles (vps). L'une de ces machines virtuelles est ton VPS.

je loggue tout ce qu'iptables n'a pas accepté, mais dans la limite de 5 par minute. Ca ne suffit pas pour éviter que tu satures mon disque ?

Oui c'est très bien, tu peux laisser ça comme ça.


Donc au final on ne sait toujours pas ce que fait cette IP. Mais je suis presque sur que c'est une IP d'ovh qui scan les ports pour pouvoir afficher les couleurs rouge ou verte en face des services DNS, SMTP, etc... dans le manager VPS.

[Moof26]

C'est peut-être le monitoring OVH qui vérifie tes services.
Fait un traceroute vers ton vps et regarde si cette IP correspond à ton host (l'avant dernière ligne).

L'avant dernière ip que j'obtiens, c'est 178.33.100.126
Donc ça si je comprends bien, c'est la passerelle de mon vps (désolé si je dis de la merde, je débute) ?

PS : c'est bien de loguer iptables dans syslog pour tester mais en production il faut que tu désactives ça. Sinon je peux par exemple bombarder ton serveur sur un port fermé et saturer ton disque.

Merci pour le conseil. Cependant, si j'ai bien pigé la règles d'iptables que j'utilise (à savoir : "-A INPUT -m limit --limit 5/min -j LOG ..." qui se trouve après tous les -A INPUT ... -j ACCEPT), je loggue tout ce qu'iptables n'a pas accepté, mais dans la limite de 5 par minute. Ca ne suffit pas pour éviter que tu satures mon disque ?

[gaboul49]

C'est peut-être le monitoring OVH qui vérifie tes services.

Fait un traceroute vers ton vps et regarde si cette IP correspond à ton host (l'avant dernière ligne).

PS : c'est bien de loguer iptables dans syslog pour tester mais en production il faut que tu désactives ça. Sinon je peux par exemple bombarder ton serveur sur un port fermé et saturer ton disque.

[Moof26]

Bonjour,

J'ai basculé il y a quelques jours du monde du mutualisé vers le VPS.
C'est pas forcément facile, mais c'est passionnant !

Bref, après avoir commencé par ce post pour débuter, j'ai ensuite fait en sorte de sécuriser du mieux que je peux mon VPS, et notamment en configurant iptables.

J'ai commencé par le plus restrictif : je n'autorise que les requêtes, ssh, http et https, ainsi que les requêtes loopback. Lorsque j'aurais réussi à configurer le serveur mail, j'ouvrirai les ports approriés, idem avec les autres services (dns, ...).

En regardant dans /var/log/syslog, je constate qu'iptables rejette de nombreuses requêtes qui proviennent de l'adresse ip 37.187.64.250 (celle de mon VPS étant 37.187.64.***) sur les ports 25, 3389, et 53.
Qu'est-ce ? J'imagine que ça vient d'un serveur OVH (ip quasi identique à l'ip de mon VPS), mais pourquoi interroge-t-il le mien ? Est-ce problématique si ces requêtes sont rejetées ?

Merci !