Est-il normal de recevoir des centaines de tentatives d'effraction par jour ?

En plus d'utiliser un mécanisme de verrouillage automatisé comme fail2ban, vous avez une autre option : contacter réellement l'adresse d'abus ISP de l'attaquant. Cela peut sembler complètement futile mais, dans le cas du script-kiddie, son ISP est plus que disposé à prendre des mesures à son encontre.

Pour trouver l'adresse de l'abus, commencez par arin.net et rechercher l'adresse IP en utilisant whois. Il se peut que vous soyez redirigé vers un autre registre régional, mais vous pourrez éventuellement trouver le FAI responsable du bloc IP qui contient l'adresse. Recherchez l'adresse "abuse@" ou envoyez simplement un courrier au contact technique.

Envoyez-leur un message poli avec les entrées pertinentes du fichier journal (veillez à supprimer toute information privée) et demandez-leur de prendre des mesures contre l'hôte fautif.

Je recommanderais de ne pas utiliser fail2ban mais d'exécuter SSH (et d'autres) sur un port non standard. Je ne crois pas à la sécurité par l'obscurité, mais je pense que c'est un excellent moyen de réduire le bruit dans vos journaux.

Les échecs de connexion sur des ports non standard seront peu nombreux et peuvent également indiquer des attaques plus ciblées.

Vous pouvez même aller un peu plus loin et installer un pot de miel SSH tel que Kippo pour "laisser entrer" les brutes et voir ce qu'elles feraient si elles en avaient l'occasion.

Oui, c'est normal. Ce que je dis aux clients dans votre situation avec des petits sites web.

Soyez toujours prêt à être piraté.

Ayez une copie de votre site web sur un serveur de développement. Cela peut être votre bureau Windows en utilisant XAMPP que vous pouvez obtenir gratuitement.

Effectuez TOUJOURS les modifications sur votre serveur de développement, puis téléchargez-les sur votre site Web réel. S'il s'agit d'un système de gestion de contenu (CMS) comme Wordpress, créez vos articles sur le serveur de développement puis copiez et collez-les sur le serveur réel.

Ne téléchargez JAMAIS rien de votre site Web réel sur votre serveur de développement.

Surveillez régulièrement vos pages web pour détecter toute modification que vous n'avez pas effectuée. En particulier, les liens cachés vers des médicaments ou des produits "d'amélioration". Vous trouverez de nombreux modules complémentaires et programmes de navigation qui feront cela pour vous.

Si vous êtes compromis. Prévenez votre hébergeur, supprimez tout, changez tous les mots de passe et téléchargez votre serveur de développement propre sur le serveur Web désormais vide. Travaillez avec votre hébergeur pour éviter que cela ne se reproduise.

Vous ne devriez pas avoir besoin d'une équipe de sécurité pour un petit site. C'est ce que votre hébergeur est censé fournir. Si ce n'est pas le cas, trouvez un autre hébergeur, ce qui est beaucoup plus facile à faire lorsque vous avez un serveur de développement plutôt que d'essayer de déplacer le serveur réel.

J'espère que cela vous aidera.

Une autre façon de l'arrêter (car personnellement je n'aime pas déplacer le port SSH) : décidez si vous pouvez lister tous les réseaux à partir desquels vous voudrez vous connecter, puis n'autorisez que ceux-ci à accéder à votre port SSH.

Les entrées WHOIS des fournisseurs d'accès locaux m'ont aidé à réduire les attaques à 1 ou 2 tentatives de connexion par mois (à l'époque, il y en avait environ 1 000 par jour). Je les ai détectées en utilisant toujours denyhosts .

En plus des autres excellentes suggestions que vous avez déjà reçues, j'aime aussi utiliser les AllowUsers si cela est approprié pour le serveur donné. Cela permet aux seuls utilisateurs spécifiés de se connecter via SSH, ce qui réduit considérablement la possibilité d'obtenir un accès via un compte invité/service/système mal configuré.

Exemple :

AllowUsers admin jsmith jdoe

L'option AllowUsers spécifie et contrôle quels utilisateurs peuvent accéder aux services et les contrôle. Plusieurs utilisateurs peuvent être être spécifiés, séparés par des espaces.