Sécurité SSH

[Lolo1234567]

Bonjour,

Je voudrais exposer mon problème actuel sur la sécurité SSH,
Durant cette année on s'est fait hacké 3 fois, ce qui commence à faire beaucoup, c'est synonyme de stress et de perte de temps, et franchement je commence en avoir pompom de ses hackers. En ce moment je suis dans une phase pour renforcer la sécurité sur mes serveurs. Il faut dire que j'ai manqué de vigilences sur certains points, notamment pour le dernier hack, mais bon ca c'est l'expérience qui rentre par force brute.

Je voudrais m'intéresser sur un point particulier, celui de la restriction du SSHD.
Suite au dernier hack, j'ai failli perdre totalement le controle de la machine, c'est à dire perdre mon mot de passe root, le hacker s'est introduit car il connaissait plusieurs mot de passe de user (déjà ca commence très mal).A partir de ses comptes non privilégiés il a réussi à devenir à root, et à commencer à faire ses affaires (diffusion de mails et virus). Pour accéder à root directement il a mis en place une clé SSH, confort oblige. Ensuite, quand il s'est aperçu que je l'avais vu, il a mis en place un nouveau ssh et sshd qui permettait d'enregistrer les mots de passe en clair dans un fichier caché, le fait de recevoir un avertissement SSH sur une nouvelle clé j'ai vite fouillé pour trouver ce fichier est effacé le contenu (dans l'immédiat, car maintenant le système a été réinstallé et patché).

Donc déjà premier point, si je devais me logguer uniquement sur ma machine par clé SSH, j'aurais déjà perdu mon accès à distance (J'habite à 600 km de mes serveurs, urggh, difficile de commander en local). Cette solution d'après ce que je vois sur internet beaucoup de personne l'adopte pour améliorer la sécurité. D'un autre coté j'ai besoins des clés pour transmettre des sauvegardes quotidiennes vers des serveurs distants.

Deuxième point, il était à la recherche de mon mot de passe root, surement pour le changer(demande obligatoire de Mdp root dans ce cas), mon PermitRootLogin était sur Yes, donc je pouvais me connecter directement root et ne pas être bloqué.
Imaginons que mon PermitRootLogin était sur No, et qu'il puisse changer les Mdp des users qualifiés pour devenir root (possible car on ne lui demande pas le mdp de root dans ce cas), là aussi j'aurais perdu le controle root de ma machine.

La vraie question est : est-il possible de demander le mot de passe root pour tout changement de passe des users qualifiés à devenir root ? Et dans ce cas comment faire ?


Dans un futur proche mon plan d'attaque serait de mettre 2 process sshd, un sur le port X et l'autre sur le port Y.

Sur le port X, PermitRootLogin no (si j'arrive la réponse de la question précédente)
PubkeyAuthentication no,
PasswordAuthentication yes
avec 1 ou 2 users qualifiés pour accéder à root pour un usage normal

Sur le port Y, PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
avec aucun users qualifiés pour accéder à root, cela servira principalement pour le transfert quotidien de mes sauvegardes sur d'autres serveurs.

Et sur le fond SELinux activé (pour l'instant j'apprends), cet outil me semble très efficace contre les hackers qui sont déjà introduits, mais il semble assez difficile à mettre en place avec apache.

Que pensez-vous de ses configs de SSHD ?

Merci de vos réponses

[vanvan]

Juste une petite idée aussi, tu pourrais mettre en place des vservers. Ce qui te permettrait de limiter l'impact du hacker s'il éclate l'un des serveurs virtuels et pour éviter qu'il remonte plus haut et qu'il te colle un rootkit sur le noyau.
De plus, en mettant un firewall avant ta ferme de serveurs n'autorisant que l'accès à certains services dont la connexion ssh seulement depuis ton ip avec l'adresse mac en plus, ça donnera plus de fil à retordre à ton hacker.

Par contre, une fois hacké, ne jamais oublier de remettre completement à plat son serveur pour éviter les rootkit planqués. Car il peuvent initialiser les connexions vers l'extérieur et si tu n'as pas mis de filtrage sortant, passe sans soucis ton firewall.

La mise en place de tripware te permettrait de capter les rootkits.

Voilà quelques idées.

[yean0693]

Je rebondis sur ce qu'a conseillé vanvan. En effet, est-ce que ta préocupation première est ta configuration SSH ?
3 intrusions en 1 an (et combien non détectées ?). Il faut réagir !

Est-ce que les préoccupations élémentaires ont été respectées :
- mise en place d'une passerelle avec firewall (attention à tous les types de spoofing IP ou ARP, mettre en place les règles adaptées + filtrer les connexions sortantes)
- firewall sur les serveurs
- désactivation des services inutiles sur toutes les machines
- mise-à-jour régulière des services (et surtout mise-à-jour de OpenSSH !)
- utilisation systématique de clés avec passphrase, mots de passe de bonne qualité...
Je ne garantie pas que ces règles de bon sens solutionneront ton problème, mais comme le dit vanvan, cela donnera du fil à retordre à tes adversaires.

Autres questions importantes à se poser :
- qui est ton adversaire ? (la plupart des problèmes sont dus à des menaces internes !)
- comment a-t-il pu escalader les privilèges ? (n'y aurait-il pas des applications obsolètes sur lesquelles il aurait utilisé des exploits ?)
- par quel moyen s'est-il introduit au commencement ? (il y a forcément un problème quelque part !)

De plus il est effectivement nécessaire de faire un peu de nettoyage sur tes serveurs. Une réinstall complète si tes utilisateurs peuvent patienter... En effet, cela peut être vu comme une perte de temps, mais que feras-tu le jour où ton serveur sera complètement compromis et que tu ne pourras plus y accéder ? La perte de temps lié à cet incident n'en sera que plus préjudiciable.

J'imagine que tu connais déjà ces recommandations, et que c'est plus facile à dire qu'à faire. Peut-être que tu les suis déjà et que ton adversaire est talentueux.
J'aurais aimé répondre à tes questions sur SSH, mais je pense que les questions importantes portent sur d'autres choses... Le problème vient aussi du fait que tu as difficilement accès à tes serveurs (physiquement j'entends) et que c'est clair que ça corse le problème.

Bon courage

[Walkyrie_II]

Une approche complémentaire pourrai consister à l'imiter la prise de risque en lancant les demons sensibles sur reception d'un événement particulier. (aproche similaire à une backdoor mais maitrisée)

Ex : Sur reception d'un mail signé par un certificat precis à une adresse particuliere, lancement du demon sshd. Tu peux généraliser cette aproche à d'autre processus en fonction d'un tag dans le corp du message. ou faire de reload d'un service avec un fichier de configuration différent.

Cela peut etre fait assez facilement via postfix et repremant le principe du script d'autoreply.

[arapaho]

Une approche complémentaire pourrai consister à l'imiter la prise de risque en lancant les demons sensibles sur reception d'un événement particulier. (aproche similaire à une backdoor mais maitrisée)

Port Knocking : http://www.portknocking.org/

[S0l0]

hello,

Trouver les reponses aux questiosn de yean0693 te permettra de profiler ton hacheurs ( de bois ) .

Pour ce qui est des rootkit si ton serveur se trouve a 600 km , c'est que tu ne peut pas vraiment upgrader tout en permanence et donc construit toi un kernel statique ( on insmod rien gna!!!! ).
Es-tu sure qu'il connaissait les mot de passe des users n'as t-il pas bute forcer un compte qui avait un mot de passe alakon (genre soleil , jolie , etc.... ).
Pense a chrooter aussi tes services/demons meme si c'est pas une securite absolue sa te permettra de ne pas compromettre tout le systeme si tu te (re)fait hacker , squash root comme ca pas de log direct a distance passe par un utilisateur normal , creer un goupe wheel , tout ca pour faciliter l'audit ( l'etude forensic ) lors d'une nouvelle attaque.

ps n'oublie pas d'enlever les programmes suids , et de faire tourner les services sous le nom d'un utilisateur particulier(autre que root).

[Lolo1234567]

Bonjour,

Est-ce que les préoccupations élémentaires ont été respectées :
- mise en place d'une passerelle avec firewall (attention à tous les types de spoofing IP ou ARP, mettre en place les règles adaptées + filtrer les connexions sortantes)
- firewall sur les serveurs
- désactivation des services inutiles sur toutes les machines
- mise-à-jour régulière des services (et surtout mise-à-jour de OpenSSH !)
- utilisation systématique de clés avec passphrase, mots de passe de bonne qualité...
Je ne garantie pas que ces règles de bon sens solutionneront ton problème, mais comme le dit vanvan, cela donnera du fil à retordre à tes adversaires.

Tout cela ont été bien fait, sauf quand on avait une redhat 9 et que yum ne fournissait plus de RPM mise à jour, pour patcher il fallait le faire en manuel.

- qui est ton adversaire ? (la plupart des problèmes sont dus à des menaces internes !)

le premier émané d'un cybercafé israélien, et faisait du phishing,la faille "openssl too open" sur Redhat 8
le deuxième un voleur de bande passante pour diffuser des films porno, faille "apache"
le dernier depuis un serveur hacké roumain (et maintenant bloqué car je suis entré en contact avec la boite détenteur du serveur pour leur informer) pour diffuser des virus, faille de la librairie mremap Redhat 9 qui peut etre d'actualité pour tous les noyaux 2.2, 2.4, 2.6

Heureusement j'ai un système de log assez sophisitiqué pour contrer les effacements systématique après un hack, c'est plutot ça qui m'a sauvé à chaque fois.

En interne, il y a eu une faille involontaire type mot de passe trop simple du à un de mes clients dont le 2ème et 3ème ont profité. je pense passer en proftpd+mysql pour l'authentification FTP des clients et éliminer un max de comptes unix avec accès shell. En interne, les actions sont quand même très limités, c'est surtout l'extérieur.

Le coup du mail signé c'est pas mal comme idée, je vais étudier l'affaire.

Merci pour vos réponses

[Walkyrie_II]

Une approche complémentaire pourrai consister à l'imiter la prise de risque en lancant les demons sensibles sur reception d'un événement particulier. (aproche similaire à une backdoor mais maitrisée)

Port Knocking : http://www.portknocking.org/

synpatique ton lien ca completer bien le mail chiffré/signé pour l'ouverture des port sur un Firewall.

[foobar47]

Bonjour tout le monde,

Je me permets d'intervenir afin de proposer une solution pour renforcer la "sécurité" des accés SSH.
Je mets le mot "sécurité" en italique car ce n'est pas vraiment une approche sécuritaire...

La méthode consiste à passer par une sorte de sas ssh.

On se connecte d'abord sur une machine sur laquelle on ne peut rien faire d'autre que du ssh vers un serveur.

Ainsi, on n'accède pas directement sur le serveur.

Sur le sas, on est en environnement chrooté ou l'on ne peut rien faire, vraiment rien mis à part faire du ssh.
On désactive l'autocompletion.
On change le port par défaut de ssh sur toutes les machines.
On désactive l'accés root via ssh.
On met des mots de passe complexes.
On remonte les logs du sas.
On configure le sas pour ne recevoir que les mises à jour yum, envoyer des mails et faire du ssh.
Pas d'historique de commandes.
On change le shell par défaut de bash à rbash.
On force le protocole 2.

L'inconvénient est qu'il faut faire 2 fois la commande SSH :

Code: Tout sélectionner

ssh -t -p autre_port_que_22 votre_login@A ssh -p autre_port_que_22 votre_login@B

Bonne journée.

[fabzz007]

Et l'authentification par certificat (RSA, DSA...) en ssh ? ça évite les attaques par force brut. J epense que quelque soit le choix que tu va faire c'est important d'y associer une authentification par certificat

Courage !

[Lolo1234567]

Merci pour vos réponses, ca me donne pas mal de directions vers lesquels chercher, Tout autre moyen pour sécuriser un serveur sont les bienvenues