J'ai eu quelques problèmes de sécurité avec un de mes serveurs, quelques utilisateurs SSH ont mis le feu à des problèmes.

J'aimerais:

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

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

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

• Suivez les connexions et déconnexions des utilisateurs. C'est simple, le fichier /var/log/auth.logdoit contenir ces informations.

• Suivez l'activité de ces utilisateurs: s'ils sont assez innocents, vous pouvez vérifier le fichier .bash_historydans 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 modifier 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_historyvous devez faire quelques tours .

• Que faire si l'utilisateur parvient à obtenir un accès root? : T'es foutu. À moins qu'ils ne se trompent, ils pourront cacher tous leurs pas.

[AVIS DE NON-RESPONSABILITÉ] Je me rends compte que je suis en retard à la fête, mais je voudrais coller une réponse que j'ai donnée à une autre question , car je pense que cela peut offrir un bon aperçu aux lecteurs, et cette question semble être la référence place pour les informations ssh de base.

Il y a eu un problème similaire qui m'a frappé après avoir lu cette 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é de passer à l'action.

Maintenant, selon la question à laquelle j'ai lié, si vous souhaitez voir les tentatives de connexion échouées sur votre machine via ssh (il peut s'agir de tentatives de force brute ou de n'importe quoi), essayez de taper ceci:

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

Si la sortie se compose de plusieurs lignes, c'est-à-dire de nombreuses tentatives de force brute, en particulier si elles se sont produites entre de courts intervalles, vous pouvez 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 préféré, comme ceci vim /etc/ssh/sshd_config.

1. Essayez de déplacer ssh du port 22 : Localisez maintenant la ligne qui lit:

# 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 (root). Je ne sais pas comment cela pourrait interférer avec cela, mais je dis juste.

2. Désactivez 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 n'est pas judicieux de fournir un accès illimité à ce compte via SSH. Localisez la ligne lisant PermitRootLogin et définissez-la sur no .

PermitRootLogin no

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

PasswordAuthentication no

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

REMARQUE: après avoir effectué les modifications, utilisez sudo /etc/init.d/ssh restart. Pour se connecter à un autre port via l' utilisation ssh: ssh [email protected] -p <port_number>.

Configurer un pare-feu

Veuillez consulter ce guide sur la façon de configurer le pare-feu extrêmement puissant et efficace, qui est intégré à Linux, IPTables .

Configurer des scripts 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 pour les tentatives de connexion ayant échoué. Une fois qu'une adresse IP a dépassé le nombre maximal de tentatives d'authentification, elle sera bloquée au niveau du réseau et l'événement sera connecté /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 jusqu'à ce point. Essayez de taper historydans un terminal pour voir toutes les commandes jusqu'à ce point. Cela pourrait aider si vous étiez root .

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

Pour répertorier toutes les commandes après ssh :fc -l ssh

Vous pouvez également éditer des commandes en utilisant vi (je ne l'ai pas essayé vim, 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 un fan de la commande, historyil y a aussi un fichier dans votre répertoire personnel ( cd ~), appelé .bash_history (si vous utilisez bash) que vous pouvez catvoir tout ce qui a été tapé dans le shell bash.

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

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

1. Javier a déjà répondu à celle-ci: /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 en sécurité. 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.

En dehors de la connexion elle-même, il n'y a aucun moyen sûr de suivre / consigner les actions des utilisateurs après leur connexion, en supposant qu'ils possèdent des connaissances de base de Linux, ils pourront désactiver la journalisation du shell ou simplement exécuter des commandes à partir d'autres shells (par exemple python).

Au lieu de cela, vous devriez être prudent en fournissant un accès ssh, en ont-ils vraiment besoin? Il n'est pas très courant d'accorder l'accès ssh à moins que vous ne soyez sur le shell pour fournir des services.