[Walid]

l'hôte tu peux toujours sauver la mise via netboot rescue mode, mais ça implique un reboot hard ce qui n'est pas cool.

pour l'hôte c'est si problématique que ça de changer le port d'écoute ? (ou mettre un fail2ban méchant qui ban 20 mins / mauvais login-pass ?)

ou encore, mieux, pour l'hôte, pour régler le problème, désactive l'authentification par password et n'alloue que les clés SSH, c'est ce que je fais pour mes comptes "sensibles" (qui ont accès à sudo), le root étant interdit par PermitRootLogin, avec fail2ban (pas pour protéger du dictionnaire mais plus pour se débarasser des appels inutiles) sur ban 5 mins / 3 mauvais login-pass, ça permet à mes users d'utiliser les pass (pour les serveurs où j'ai des users et où je n'ai pas la possibilité de les obliger à passer par des clés ssh) & ça me permet d'être certain de protéger le plus important.

[issambox]

est si le knockd crach sur le hôte c'est ça qui va être problématique, dans le cadre d'utilisation pour la sécurisation de l’accès a l'interface web proxmox par exemple, bloquer l’accès sur le port 80 jusqu’à réception de la séquence d'ouverture du port...

sinon pour l'encombrement de la tache c'est pour ca que j'ai pensé a une app mobile qui peut être jumeler à un script coté interface d'administration du serveur (php ==> fsockopen() par exemple ou du perl)...

je teste sur le kimsufi dé réception.

[Walid]

Perso j'ai jamais été fan du port knockin, je sais qu'en pratique c'est + de sécurité mais je trouve ça trop encombrant (surtout si tu dois donner accès à d'autres personnes).

Donc ce que je fais je met PermitRootLogin à no (après avoir installé & configuré sudo au préalable) et je met en place fail2ban (avec une limite de 3 tentatives)

Sinon pour le point 1 (si knockd crash), si openvz tu peux toujours modifier à partir de l'hôte via vzctl (vmid) enter pour fixer (ou tout simplement le désactiver) sans même avoir à reboot la machine, je ne sais pas pour le kvm je ne l'utilise pas et je n'ai pas d'expérience dessus.

[issambox]

Bonsoir,

J’ai besoin de votre avis / retours d’expériences concernant un point de sécurisation.

Comme vous le savez et en consultant vos logs (/var/log/secure) vous avez peut être remarquer que des gentils (robots ou humains) essaye de rentrer chez vous (votre serveur) en défonçant la porte (utilisation de dictionnaire de mot de passe généralement) dans mon cas c’est souvent des VIETs, Coréens, RUSSES…

Sachant que actuellement sur certains system (VMs) je ne souhaite pas changer le port d’écoute SSH (22), et je souhaite garder aussi la connexion en root.

Je m’appuis actuellement sur une politique de bannir toute adresses IP qui enregistre une seule tentative de connexion en échec sur le port 22
Mais bon voilà, Je cherche à leurs rendre la tache plus difficile, donc je me penche naturellement vers le Port Knocking pour renforcer ma politique de sécurisation.

le Port Knocking consiste à se connecter à une série de ports sur le serveur, dans un ordre bien précis, dans un délais bien précis, afin d'ouvrir un port donné, C'est en fait la même chose qu'un code de verrouillage et déverrouillage d’un coffre-fort la différence c’est que les codes chiffrées sont remplacées par des numéros de ports.

Ca me semble le top en matière de sécurisation pour le moment, mais bon voilà je me pose quelques questions avant de me lancer :

1) Est si un jour mon démon (knockd ou autres) plante aill je vais surement être forcer a relancer la machine et peut être que la aussi le démon plantera au démarrage pour x ou y raison, je vais me retrouver en face d’une situation assez délicate

2) Sinon deuxième point sur certains serveur j’ai du CSF ou le super Fridu est ce que cette technique peut être jumelé sans problème avec ??

3) Je songe a automatiser la séquence qui permet d’ouvrir la porte (22 ou autres) je suis tenté de développer une app iphone (IOS) ou androïde qui va me permettre de déclencher tactilement et facilement les requêtes vers le dit serveur, pour m’ouvrir la porte… votre avis ???

J’attends vos retours d’expériences et vos avis.
Merci