web-dev-qa-db-fra.com

Comment puis-je auditer les utilisateurs et accéder aux tentatives de SSH sur mon serveur?

J'ai eu quelques problèmes de sécurité avec un de mes serveurs, quelques utilisateurs de SSH ont provoqué des incendies, c’est-à-dire donnant des problèmes.

J'aimerais:

  • Suivre les connexions et déconnexions des utilisateurs
  • Suivre l'activité de ces SSH, afin de découvrir toute activité malveillante
  • Empêcher les utilisateurs de supprimer des journaux

Je ne suis pas vraiment un administrateur système et je suis assez inexpérimenté à ce sujet, tout type de conseil serait donc le bienvenu et très utile. :)

serversecurityssh
28
RadiantHex

Comme nous parlons de serveurs SSH, je vais vous donner des solutions en ligne de commande.

  • Suivre les connexions et déconnexions des utilisateurs. C'est facile, le fichier /var/log/auth.log devrait avoir cette information.

  • Suivre l’activité de ces utilisateurs: s’ils sont assez innocents, vous pouvez consulter le fichier .bash_history dans leur répertoire personnel. Vous verrez une liste des commandes qu'ils ont exécutées. Le problème est bien sûr qu’ils peuvent supprimer ou éditer ce fichier.

  • Empêcher les utilisateurs de supprimer les journaux: les utilisateurs ne devraient pas pouvoir toucher auth.log. Afin de les empêcher de jouer avec .bash_history, vous devez faire quelques astuces .

  • Que se passe-t-il si l'utilisateur parvient à obtenir un accès root? : T'es foutu. À moins qu'ils ne commettent une erreur, ils pourront cacher tous leurs pas.

27
Javier Rivera

[AVERTISSEMENT] Je me rends compte que je suis en retard pour le parti, mais j'aimerais coller une réponse que j'ai donnée à une autre question =, car j’ai l’impression que cela peut offrir de bonnes informations aux lecteurs, et cette question semble être le lieu de prédilection pour obtenir des informations de base sur ssh.

Il y avait un problème similaire qui m'a frappé après avoir lu this question ici sur AskUbuntu et vérifié mon VPS, seulement pour voir un bazillion de tentatives de force brute. C'est alors que j'ai décidé d'agir.

Maintenant, selon la question à laquelle je me suis référé, si vous souhaitez voir les tentatives de connexion infructueuses sur votre machine via ssh (essayez des tentatives de force brute ou quoi que ce soit), essayez de taper ceci:

grep sshd.\*Failed /var/log/auth.log | less

Si la sortie comporte plusieurs lignes, c’est-à-dire de nombreuses tentatives de force brute, en particulier si elles se sont produites entre de courts intervalles, vous souhaiterez peut-être effectuer les actions suivantes:

Changer le fichier de configuration ssh

Pour ce faire, ouvrez le fichier situé dans /etc/ssh/sshd_config avec votre éditeur favori, comme ceci vim /etc/ssh/sshd_config.

1. Essayez de déplacer ssh du port 22 : localisez maintenant la ligne qui se lit comme suit:

# What ports, IPs and protocols we listen for
Port 22

et commentez le port 22, et utilisez qui vous voulez. Exemple:

# What ports, IPs and protocols we listen for
# Port 22
Port 28934

N'oubliez pas que les ports inférieurs à 1024 nécessitent une autorisation spéciale (racine). Je ne sais pas comment cela pourrait interférer, mais je dis simplement.

2. Désactiver les connexions root via ssh : étant donné que le nom d'utilisateur root est prévisible et fournit un accès complet à votre système, il est déconseillé de fournir un accès sans entrave à ce compte via SSH. Recherchez la valeur de ligne PermitRootLogin et définissez-la sur no .

PermitRootLogin no

3. Désactiver l'authentification par mot de passe : Générez et utilisez des clés SSH pour vous connecter à votre système. Sans mot de passe activé, les attaquants devront deviner (ou voler) votre clé privée SSH pour pouvoir accéder à votre serveur. Quelque chose de très très difficile. Continuez pour trouver la ligne qui lit PasswordAuthentication et réglez-la sur no 

PasswordAuthentication no

! AVERTISSEMENT! Avant de le faire, veuillez consulter ce guide ici pour savoir comment configurer l'authentification par certificat.

REMARQUE: Après avoir apporté les modifications, utilisez Sudo /etc/init.d/ssh restart. Pour vous connecter à un autre port via ssh, utilisez: ssh [email protected] -p <port_number>.

Installer un pare-feu

S'il vous plaît consulter ce guide sur la façon de configurer le pare-feu extrêmement puissant et efficace, qui est intégré dans Linux, IPTables .

Scripts d'installation pour vous aider avec la sécurité

Celui que j’utilise personnellement et qui me vient rapidement à l’esprit est Fail2Ban . Fail2ban surveillera vos fichiers journaux à la recherche de tentatives de connexion infructueuses. Lorsqu'une adresse IP a dépassé le nombre maximal de tentatives d'authentification, elle est bloquée au niveau du réseau et l'événement est enregistré dans /var/log/fail2ban.log. Pour l'installer: Sudo apt-get install fail2ban

Vérifier l'historique des commandes via ssh

Il existe une commande linux, nommée history, qui vous permet de voir quelles commandes ont été entrées jusque-là. Essayez de taper history dans un terminal pour voir toutes les commandes jusque-là. Cela pourrait aider si vous étiez root .

Pour rechercher une commande particulière , essayez: history | grep command-name

Pour lister toutes les commandes après ssh : fc -l ssh

Vous pouvez également éditer les commandes à l'aide de vi (je ne l'ai pas essayé, bien que je suppose que cela fonctionne aussi): fc -e vi

Vous pouvez également supprimer l'historique : history -c

REMARQUE: Si vous n'êtes pas fan de la commande history, il existe également un fichier dans votre répertoire personnel (cd ~), appelé . bash_history (si vous utilisez bash), vous pouvez cat voir tout ce qui a été saisi dans le shell bash.

6
NlightNFotis

Un peu exagéré, mais vous pouvez voir tout ce qui est exécuté sur votre système à l'aide du "connecteur d'événement de processus":

http://www.outflux.net/blog/archives/2010/07/01/reporting-all-execs/

4
Kees Cook
  1. Javier a déjà répondu à cette question: /var/log/auth.log
  2. J'ai trouvé un excellent article à ce sujet ici .
  3. Si vos utilisateurs n'ont pas accès à root, vos fichiers journaux doivent être sécurisés. Vous pouvez essayer de créer des règles personnalisées dans le fichier sudoers pour restreindre ce à quoi vos utilisateurs peuvent accéder et comment. Vous pouvez également augmenter le niveau de journalisation du démon sshd.
3
Radu Cotescu

Hormis la connexion elle-même, il n’existe aucun moyen sûr de suivre/consigner les actions des utilisateurs une fois qu’ils se sont connectés, en supposant que leurs connaissances de base en Linux leur permettent de désactiver la journalisation Shell ou d’exécuter simplement des commandes à partir d’autres shells (python, par exemple).

Au lieu de cela, vous devriez faire preuve de prudence en ce qui concerne l'accès ssh, en ont-ils vraiment besoin? Il n'est pas très courant d'accorder un accès SSH à moins que votre entreprise Shell ne fournisse des services.

3
João Pinto