Mon serveur est constamment attaqué [fermé]

Je suis assez nouveau dans le monde de l'administration système. Je travaille sur une application récemment et lorsque je vérifie les journaux de mon serveur d'applications, je reçois constamment diverses adresses IP essayant de ssh sur mon serveur par force. Voici un exemple de journal de mon serveur:

Feb 14 04:07:20 foodwiz3 sshd[1264]: error: Could not load host key: /etc/ssh/ssh_host_ed25519_key
Feb 14 04:07:21 foodwiz3 sshd[1264]: reverse mapping checking getaddrinfo for coenamor.columbiansabbatical.com [23.249.167.223] failed - POSSIBLE BREAK-IN ATTEMPT!
Feb 14 04:07:21 foodwiz3 sshd[1264]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=23.249.167.223  user=root
Feb 14 04:07:23 foodwiz3 sshd[1264]: Failed password for root from 23.249.167.223 port 32997 ssh2
Feb 14 04:07:23 foodwiz3 sshd[1264]: Received disconnect from 23.249.167.223: 11: Bye Bye [preauth]
Feb 14 04:13:04 foodwiz3 sshd[1289]: error: Could not load host key: /etc/ssh/ssh_host_ed25519_key
Feb 14 04:13:05 foodwiz3 sshd[1289]: reverse mapping checking getaddrinfo for coenamor.columbiansabbatical.com [23.249.167.223] failed - POSSIBLE BREAK-IN ATTEMPT!
Feb 14 04:13:05 foodwiz3 sshd[1289]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=23.249.167.223  user=root
Feb 14 04:13:07 foodwiz3 sshd[1289]: Failed password for root from 23.249.167.223 port 41562 ssh2

Est-ce quelque chose qui est assez normal, ou devrais-je être inquiet / faire quelque chose à ce sujet?

Bienvenue dans le monde merveilleux d'Internet ... Avez-vous:

• mettre votre serveur derrière un pare-feu matériel?
• activé le pare - feu du logiciel ? (juste au cas où le pare-feu HW pépinait)
• renforcé votre serveur?
• installé rkhunter avant de le mettre en ligne?
• activé les mises à jour quotidiennes de sécurité automatiques ?
• changé le port par défaut de ssh?
• ...

Mais la vraie réponse est: oui, c’est normal : la BotNet Maffia peut toujours utiliser quelques serveurs très mal protégés ...

Il est assez normal d'avoir suffisamment d'essais de connexion pour créer un journal d'inondation.

Changer de ports SSH est plutôt une solution de type 'sécurité par obscurité', mais elle aide à éviter les inondations. J'insiste sur le fait que ce n'est pas très élégant; il existe des ports de facto pour des services pour une raison.

Comme il devrait être activé par défaut, mais assurez-vous que vous ne pouvez pas utiliser SSH sur votre serveur en tant que root. C'est le nom d'utilisateur qui est assez cohérent entre les serveurs et donc la cible principale pour les tentatives de connexion brutale par mot de passe. Appliquez le paramètre avec la ligne suivante dans sshd_config:

PermitRootLogin no

Vérifiez également fail2banque les journaux sshd surveillent les récidivistes. Par exemple, 5 connexions échouées en 3 minutes à partir d'une certaine adresse IP seraient bloquées pendant 10 minutes. J'ai porté ce délai d'interdiction à 24 heures pour réduire davantage le spam de journalisation - avec succès. :)

Je vous suggérerais de faire quelques choses:

1. Changez le port sur lequel ssh écoute (à un niveau bien supérieur à 1024) et assurez-vous de ne pas utiliser la version 1 du protocole:

/ etc / ssh / sshd_config

# What ports, IPs and protocols we listen for
Port 50022
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2

2. Instal fail2ban- surveille les fichiers journaux et interdit de manière temporaire ou persistante les adresses sujettes aux pannes en mettant à jour les règles de pare-feu existantes ( iptables).

3. Assurez-vous d'avoir répertorié en blanc vos emplacements de confiance.

Oui, soyez inquiet . Vous ne serez peut-être jamais brûlé, mais vous devriez suivre les meilleures pratiques informatiques. Mieux vaut prévenir que guérir.

Je suis un administrateur de réseau dans un hôpital. C'est toujours une mauvaise idée de connecter une boîte directement à Internet. Ce que vous voyez, ce sont les milliers de scanners automatisés qui recherchent les vulnérabilités sur Internet. Je vois cela et toutes sortes de choses (analyses de ports, tests de vulnérabilités connus) pour tous les types de logiciels (ssh, telnet, ftp, etc.) apparaissant sur notre boîte d'identifiants
Votre machine doit se trouver derrière une solution pare-feu / NAT et vous devriez uniquement transférez les ports requis sur Internet (80, 443, etc.). C'est relativement facile à faire.
Avoir quelque chose que vous pouvez utiliser pour gérer (SSH telnet) est une mauvaise idée de faire face à Internet car si - pour une raison quelconque - le logiciel SSH / telnet présente un bogue sur ce serveur, le bot automatisé le détectera immédiatement. et vous serez foutus. Les bogues logiciels se produisent tout le temps et cela peut prendre un certain temps pour qu'un correctif soit publié ou pour que vous vous souveniez de le corriger.

Si vous devez gérer à distance, envisagez de configurer quelque chose comme une solution VPN ou, si vous utilisez Windows, configurez la passerelle de services de terminal pour le bureau distant. Je sais que vous pouvez utiliser un système Linux ou Windows séparé avec 2 cartes réseau pour configurer le routage et l’accès à distance pour les réseaux privés virtuels et les réseaux NAT si vous n’êtes qu’un petit magasin. Sinon, les fournisseurs tels que Cisco ont des solutions de pare-feu / NAT (Cisco ASA).

En résumé, placez votre machine derrière NAT. Seul port transfère les ports nécessaires à l'exécution du service. Ne transférez pas les services de transfert utilisés pour la gestion sur Internet, mais utilisez plutôt le VPN pour la gestion à distance.

PS Changer les ports SSH peut aider à réduire le volume du journal, mais n'empêche pas l'accès à SSH. N'importe lequel des milliers de détecteurs de vulnérabilité automatisés peut et va effectuer des analyses de port pour déterminer quels ports écoutent quels services. Vous pouvez le faire vous-même avec un outil appelé nmap .

Vous pouvez configurer le pare-feu interne du noyau avec iptables . Ainsi, seules quelques machines pourraient ssh sur votre serveur et laisser les autres paquets IP tomber. Voir man iptablespour plus d'informations.

Par exemple, si 192.168.1.67 est l’hôte à partir duquel vous êtes ssh, sur le type de serveur:

sudo iptables -A INPUT -p tcp --dport ssh -s 192.168.1.67 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport ssh -j DROP
sudo iptables-save

Avez-vous vraiment besoin de votre serveur sur Internet? Si vous voulez vraiment l'avoir sur Internet, assurez-vous qu'il est sécurisé avant de le placer là-bas.

Changer de port, c'est simplement la sécurité par l'obscurité. Si votre attaquant est plus sophistiqué que d'exécuter des scripts, cela ne vous aidera pas.

Quelques choses déjà mentionnées que je recommande aussi:

1. Je suis d'accord avec Fail2Ban, et correctement configuré gardera les scripts et les pirates les plus sophistiqués à la baie.
2. Définir PermitRootLogin sur no est indispensable.
3. Configurez un pare-feu. En général, je modifie simplement les règles iptables, mais quelque chose comme UFW ou firehol fonctionnera également.

Je viens de rejoindre cette communauté parce qu'il y a deux choses qui, à mon avis, n'ont pas été traitées de manière adéquate.

• Dans la configuration du pare-feu, bloquez / désactivez absolument tout ce qui n'est pas complètement nécessaire. Avant d’ouvrir des ports, demandez-vous: "Ai-je vraiment besoin de ce service sur Internet?" Chaque port / service que vous ouvrez devient un autre vecteur potentiel exploitable par quelqu'un. Si ce service contient un bogue qui leur permet d’obtenir un accès root au serveur, ils pourront peut-être accéder à tout ce qu’il contient. Votre sécurité est aussi forte que le maillon le plus faible.
• Maintenant pour la dernière chose et sans doute le plus important. Les scripts que vous avez vus essayant d'accéder à ssh pourraient peut-être deviner votre mot de passe au fil du temps. Fail2Ban les ralentira beaucoup, mais ils pourraient toujours le deviner. Si tel est le cas, vous souhaitez une authentification à 2 facteurs sur les services accessibles. Pour cela, je recommande un compte gratuit avec Duo Security. https://www.duosecurity.com/docs/duounix

Un autre exemple pour répondre à @cff, si vous avez l'intention d'interdire les "tentatives" successives sur votre serveur SSH:

sudo iptables -A INPUT -p tcp -m tcp --dport ssh -m state --state NEW -m recent --update --seconds 600 --hitcount 4 --name DEFAULT --mask 255.255.255.255 --rsource -j DROP
sudo iptables -A INPUT -p tcp -m tcp --dport ssh -m state --state NEW -m recent --set --name DEFAULT --mask 255.255.255.255 --rsource
sudo iptables-save

Cette tentative de connexion par "balises" et si plus de 4 surviennent en 600 (10mn), l'origine est "bannie". Utilisez cette solution au lieu de @ cff car elle est plus sûre (si vous vous verrouillez, attendez 10 minutes et réessayez).