Suis-je confronté à une attaque par force brute?
Lors de la vérification du journal d'authentification d'un serveur avec la commande:
grep sshd.\*Failed /var/log/auth.log | less
Je vois des milliers de lignes comme celle-ci:
Jan 12 11:27:10 ubuntu-leno1 sshd[8423]: Failed password for invalid user admins from 172.25.1.1 port 44216 ssh2
Jan 12 11:27:13 ubuntu-leno1 sshd[8425]: Failed password for invalid user phoenix from 172.25.1.1 port 20532 ssh2
Jan 12 11:27:17 ubuntu-leno1 sshd[8428]: Failed password for invalid user piglet from 172.25.1.1 port 24492 ssh2
Jan 12 11:27:22 ubuntu-leno1 sshd[8430]: Failed password for invalid user Rainbow from 172.25.1.1 port 46591 ssh2
Jan 12 11:27:25 ubuntu-leno1 sshd[8432]: Failed password for invalid user runner from 172.25.1.1 port 57129 ssh2
Jan 12 11:27:34 ubuntu-leno1 sshd[8434]: Failed password for invalid user sam from 172.25.1.1 port 11960 ssh2
Jan 12 11:27:37 ubuntu-leno1 sshd[8437]: Failed password for invalid user abc123 from 172.25.1.1 port 5921 ssh2
Jan 12 11:27:40 ubuntu-leno1 sshd[8439]: Failed password for invalid user passwd from 172.25.1.1 port 21208 ssh2
Jan 12 11:27:43 ubuntu-leno1 sshd[8441]: Failed password for invalid user newpass from 172.25.1.1 port 65416 ssh2
Jan 12 11:27:46 ubuntu-leno1 sshd[8445]: Failed password for invalid user newpass from 172.25.1.1 port 26332 ssh2
Jan 12 11:27:49 ubuntu-leno1 sshd[8447]: Failed password for invalid user notused from 172.25.1.1 port 51126 ssh2
Jan 12 11:27:52 ubuntu-leno1 sshd[8449]: Failed password for invalid user Hockey from 172.25.1.1 port 14949 ssh2
Jan 12 11:27:56 ubuntu-leno1 sshd[8451]: Failed password for invalid user internet from 172.25.1.1 port 35105 ssh2
Jan 12 11:27:59 ubuntu-leno1 sshd[8453]: Failed password for invalid user asshole from 172.25.1.1 port 7916 ssh2
Jan 12 11:28:02 ubuntu-leno1 sshd[8456]: Failed password for invalid user Maddock from 172.25.1.1 port 26431 ssh2
Jan 12 11:28:05 ubuntu-leno1 sshd[8458]: Failed password for invalid user Maddock from 172.25.1.1 port 53406 ssh2
Jan 12 11:28:09 ubuntu-leno1 sshd[8460]: Failed password for invalid user computer from 172.25.1.1 port 23350 ssh2
Jan 12 11:28:15 ubuntu-leno1 sshd[8462]: Failed password for invalid user Mickey from 172.25.1.1 port 37232 ssh2
Jan 12 11:28:19 ubuntu-leno1 sshd[8465]: Failed password for invalid user qwerty from 172.25.1.1 port 16474 ssh2
Jan 12 11:28:22 ubuntu-leno1 sshd[8467]: Failed password for invalid user fiction from 172.25.1.1 port 29600 ssh2
Jan 12 11:28:26 ubuntu-leno1 sshd[8469]: Failed password for invalid user orange from 172.25.1.1 port 44845 ssh2
Jan 12 11:28:30 ubuntu-leno1 sshd[8471]: Failed password for invalid user tigger from 172.25.1.1 port 12038 ssh2
Jan 12 11:28:33 ubuntu-leno1 sshd[8474]: Failed password for invalid user wheeling from 172.25.1.1 port 49099 ssh2
Jan 12 11:28:36 ubuntu-leno1 sshd[8476]: Failed password for invalid user mustang from 172.25.1.1 port 29364 ssh2
Jan 12 11:28:39 ubuntu-leno1 sshd[8478]: Failed password for invalid user admin from 172.25.1.1 port 23734 ssh2
Jan 12 11:28:42 ubuntu-leno1 sshd[8480]: Failed password for invalid user jennifer from 172.25.1.1 port 15409 ssh2
Jan 12 11:28:46 ubuntu-leno1 sshd[8483]: Failed password for invalid user admin from 172.25.1.1 port 40680 ssh2
Jan 12 11:28:48 ubuntu-leno1 sshd[8485]: Failed password for invalid user money from 172.25.1.1 port 27060 ssh2
Jan 12 11:28:52 ubuntu-leno1 sshd[8487]: Failed password for invalid user Justin from 172.25.1.1 port 17696 ssh2
Jan 12 11:28:55 ubuntu-leno1 sshd[8489]: Failed password for invalid user admin from 172.25.1.1 port 50546 ssh2
Jan 12 11:28:58 ubuntu-leno1 sshd[8491]: Failed password for root from 172.25.1.1 port 43559 ssh2
Jan 12 11:29:01 ubuntu-leno1 sshd[8494]: Failed password for invalid user admin from 172.25.1.1 port 11206 ssh2
Jan 12 11:29:04 ubuntu-leno1 sshd[8496]: Failed password for invalid user chris from 172.25.1.1 port 63459 ssh2
Jan 12 11:29:08 ubuntu-leno1 sshd[8498]: Failed password for invalid user david from 172.25.1.1 port 52512 ssh2
Jan 12 11:29:11 ubuntu-leno1 sshd[8500]: Failed password for invalid user foobar from 172.25.1.1 port 35772 ssh2
Jan 12 11:29:14 ubuntu-leno1 sshd[8502]: Failed password for invalid user buster from 172.25.1.1 port 18745 ssh2
Jan 12 11:29:17 ubuntu-leno1 sshd[8505]: Failed password for invalid user harley from 172.25.1.1 port 38893 ssh2
Jan 12 11:29:20 ubuntu-leno1 sshd[8507]: Failed password for invalid user jordan from 172.25.1.1 port 64367 ssh2
Jan 12 11:29:24 ubuntu-leno1 sshd[8509]: Failed password for invalid user stupid from 172.25.1.1 port 27740 ssh2
Jan 12 11:29:27 ubuntu-leno1 sshd[8511]: Failed password for invalid user Apple from 172.25.1.1 port 22873 ssh2
Jan 12 11:29:30 ubuntu-leno1 sshd[8514]: Failed password for invalid user fred from 172.25.1.1 port 54420 ssh2
Jan 12 11:29:33 ubuntu-leno1 sshd[8516]: Failed password for invalid user admin from 172.25.1.1 port 58507 ssh2
Jan 12 11:29:42 ubuntu-leno1 sshd[8518]: Failed password for invalid user summer from 172.25.1.1 port 48271 ssh2
Jan 12 11:29:45 ubuntu-leno1 sshd[8520]: Failed password for invalid user sunshine from 172.25.1.1 port 5645 ssh2
Jan 12 11:29:53 ubuntu-leno1 sshd[8523]: Failed password for invalid user andrew from 172.25.1.1 port 44522 ssh2
Il semble que je subisse une attaque par force brute ssh. Est-ce un phénomène courant ou suis-je spécifiquement ciblé? Qu'est-ce que je devrais faire maintenant? Dois-je considérer l'attaque comme réussie et prendre des mesures?
-----Éditer-------
Le fait que l'attaque provienne d'une adresse IP interne s'explique par le fait que ce serveur dispose d'une redirection ssh de l'extérieur. Cela s'est produit très rapidement après l'ouverture du port, toutes les adresses IP publiques sont-elles analysées dans la nature à la recherche d'un serveur existant derrière?
Ajout d'une note rapide sur fail2ban, comme beaucoup de gens l'ont mentionné: le front-end est un pare-feu d'entreprise, le back-end ne voit que la redirection/proxy/adresse interne qui provient du pare-feu.
Donc non, 172.25.1.1 n'est pas une machine interne compromise (et à la fois le commentaire dans la réponse et une autre réponse ici indiquant qu'il s'agit d'une machine interne sont faux en commentant cela). Il s'agit de l'une des adresses IP internes du pare-feu.
Fail2ban dans le back-end ne bloquerait que toutes les possibilités d'utiliser SSH pour les étirements à la fois car il ne voit que les tentatives infructueuses de 172.25.1.1. Alors s'il vous plaît, lisez la suite pour ma réponse.
Il n'y a aucun doute, comme d'autres articles le mentionnent, il est douloureusement évident que vous êtes victime d'une attaque par force brute.
Cependant, cela ne signifie pas du tout que vous êtes compromis de quelque façon que ce soit des journaux que vous nous avez montrés. Hélas, de nos jours, les attaques par force brute ssh sont toutes trop commun. La plupart du temps, ils sont vraiment automatisés et vous n'êtes pas nécessairement ciblés.
Comme anecdote, il y a quelques années, le premier jour où j'ai installé de nouveaux serveurs chez un fournisseur de services Internet, le serveur ssh ouvert sur Internet a reçu 200k + ssh sondes de balayage en une seule nuit.
En ce qui concerne l '"adresse IP interne", vous utilisez au mieux SNAT ou une redirection proxy 22/TCP, et les IP Internet source ne s'affichent pas (ce qui n'est pas la meilleure pratique), ou au pire votre routeur/modem câble est compromis.
Si vous avez vraiment une configuration SNAT/proxy SSH, je vous recommande d'y réfléchir. Vous voulez des journaux des vraies adresses IP et non de votre réseau.
Quant aux mesures, j'en recommande:
- N'autorisez pas les mots de passe dans SSH; uniquement les connexions utilisant des certificats RSA;
- N'ouvrez pas ssh pour l'extérieur; restreignez-le à votre réseau interne;
- Pour accéder de l'extérieur, accédez via un VPN; n'exposez pas SSH à Internet dans son ensemble;
- sYNs limitant le débit de l'extérieur.
Si vous insistez absolument pour que l'Internet SSH soit toujours ouvert à l'extérieur, sachez que la modification du port SSH par défaut ne donne qu'un faux sentiment de sécurité, et le blocage temporaire des adresses IP ne fait que ralentir l'attaque, car nous parlons souvent de fermes coordonnées de machines zombies.
Vous voudrez peut-être jeter un œil à fail2ban si vous modifiez votre configuration pour recevoir directement des adresses IP publiques vous connectant; cependant, tenez compte du fait que si une adresse IP externe arrive avec l'adresse IP de votre passerelle, vous verrouillez efficacement tous les accès SSH externes qui l'utilisent.
Il existe également d'autres mises en garde; veuillez noter que de nos jours, les zombies/programmes malveillants prennent fail2ban en compte et reviendra après le délai d'expiration par défaut ou à tour de rôle avec des adresses IP différentes. (Je l'ai vu se produire.) Même si vous utilisez l'authentification par certificat RSA obligatoire, les attaques par mot de passe seront toujours enregistrées et brûleront les E/S, l'espace disque et les cycles du processeur.
Quant au VPN, vous n'avez pas besoin de matériel dédié; il est trivial de configurer un VPN sur un serveur Linux ou FreeBSD.
Si vous ne vous sentez pas à l'aise d'en configurer un à partir de zéro, je recommande un VM avec pfSense. pour FreeBSD; strongSwan pour la configuration un VPN dans un serveur Linux.
Si votre serveur frontal est Linux, une autre alternative est le détournement de port. Cependant, en raison de son fonctionnement inhérent, je le recommande uniquement pour les paramètres domestiques. Comme correctement souligné par @GroundZero, "le détournement de port est une sécurité par obscurité et un attaquant peut surveiller activement votre trafic réseau pour découvrir la séquence de détournement."
Comment utiliser le port knocking pour cacher votre démon SSH aux attaquants sur Ubunt
Comme mesure supplémentaire, vous pouvez également limiter le débit avec les règles SYN de pare-feu/iptables dans le port 22. De cette façon, vous ne limitez pas vos connexions légitimes, et soit iptables sous linux, soit la plupart des pare-feu commerciaux permettent cette configuration. J'ai vu des astuces désagréables comme des bots attaquant certains démons aussi rapidement que possible avant que les règles de sécurité ne se déclenchent. Cependant, je crois réellement que ssh a des défenses intégrées contre cela.
Pour vous répondre sur le balayage rampant, oui en effet. Vous avez beaucoup de mauvais acteurs, des réseaux de zombies et des logiciels malveillants qui balaient constamment l'espace d'adressage IP pour trouver des serveurs avec des versions compromises de sshd, des versions sshd vulnérables/anciennes, des serveurs avec des mots de passe par défaut/mauvais/des portes dérobées connues, et simplement des serveurs avec openssh pour gagner un point d'ancrage chez un utilisateur non privilégié via la force brute ou des attaques à deux volets via le phishing.
Après trois attaques réussies via le phishing (dans des événements distincts) dans mon hôte bastion dans mon travail actuel, j'ai décidé de faire une double configuration ssh en ce que tous les utilisateurs sont invités à fournir un certificat RSA dans sshd_config, et seul le réseau interne permet l'authentification par mot de passe, ajoutant ainsi à la fin du fichier de configuration:
# sshd configuration allowing only RSA certificates
Match Address 10.0.0.0/8,172.16.0.0/12,192.168.0.0/24
PasswordAuthentication yes
Comme autre récit anecdotique effrayant, avant de passer aux certificats RSA obligatoires, l'un des compromis de phishing a été effectué au cours de la semaine exacte, il y avait deux mises à jour du noyau pour les vulnérabilités qui permettaient une escalade de privilèges à la racine, et si je n'avais pas mis à jour sur place, je le ferais ont été compromis racine. (et si ma mémoire ne me manque pas, c'était vers le 4 juillet ... les hackers adorent sauver ces vilaines attaques pour les vacances)
En ce qui concerne les graphiques des attaques réelles en temps réel, jetez un œil à:
- L'interface graphique du projet nordique. C'est très éducatif.
- Une carte de attaques DDOS.
- ne vue gratuite du réseau central de surveillance de la sécurité de Checkpoint, où les agents sont leurs clients.
Pour terminer la réponse:
Non, vous n'êtes probablement aucunement compromis.
Oui, vous devez prendre des mesures pour augmenter votre niveau de sécurité. Je conseillerais un tunnel/client VPN de l'extérieur à votre serveur VPN d'entreprise. C'est ce que je fais en fait.
J'ai également un dernier et important conseil: pour vous assurer qu'un compte régulier n'est pas compromis, vérifiez votre /var/log/auth.log journaux d'authentification pour une authentification réussie. Il existe des moyens de se connecter à openssh avec n'importe quel compte sans qu'il soit enregistré dans /var/log/wtmp et par conséquent n'apparaissant pas dans la commande last.
Il va sans dire que si un compte normal est compromis dans une vieille machine sans mises à jour, tous les paris sont désactivés. Et dans le cas malheureux d'une élévation de privilèges à la racine, même les journaux peuvent être compromis.
Oui, il semble que vous subissiez une attaque par force brute. L'attaquant se trouve sur une adresse privée de classe B, il est donc probable que ce soit une personne ayant accès au réseau de votre organisation qui mène l'attaque. D'après les noms d'utilisateur, il semble qu'ils fonctionnent via un dictionnaire de noms d'utilisateur courants.
Jetez un œil à 'Comment arrêter/empêcher la force brute SSH' (Serverfault) et 'Prévenir les attaques SSH par force brute' (Hébergement Rimu) sur la façon de prendre des mesures pour atténuer certains du risque lié aux attaques par force brute SSH.
Oui, cela ressemble exactement à une attaque par force brute et après googler admins phoenix piglet Rainbow on dirait que c'est la liste de mots que l'attaquant utilise: https://github.com/hydrogen18/kojoney/blob/master/fake_users
Consultez la ligne 116 à partir de maintenant. La liste de mots est utilisée dans le même ordre exact.
Cela semble être une liste de mots générique car elle est également présente sur d'autres sites. par exemple. http://src.gnu-darwin.org/ports/net/kojoney/work/kojoney/fake_users
@TheJulyPlot a fourni de bonnes informations sur ce qu'il faut faire pour atténuer cette attaque.
Oui, vous êtes brutalisé. Mais je ne pense pas que vous devriez vous soucier de la force brute que vous détectez venant d'Internet. Vous devez cependant vous inquiéter des attaques par force brute provenant de votre propre réseau.
Être forcé par la force est très courant, et tant que vous n'utilisez pas de mots de passe pour SSH (ou utilisez de bons mots de passe), l'attaque ne réussira pas du tout (en particulier avec une supposition toutes les 3-4 secondes ).
Cependant, l'IP (172.25.1.1) est sur le même réseau que vous. C'est le vrai problème, et vous devriez vérifier si cette machine est compromise dès que possible.
Vous survivez à l'attaque, des apparences. SSH fait ce qu'il est censé faire. Cependant, voir ci-dessous pour certaines étapes que vous devez prendre dès que possible pour assurer la survie continue.
De plus, et malheureusement, un système à l'intérieur du réseau a été compromis. Trop courant de nos jours. Vous devez vérifier la nature de cette attaque apparemment intérieure, mais ne supposez pas que ce système est compromis simplement sur la base de ce fichier journal. Quiconque exécute un SSHD accessible sur le Web l'a déjà vu, encore et encore, pendant des années. Corrigez l'installation SSHD sur cet hôte, puis examinez le système à 172.25.1.1.
Suivez les meilleures pratiques SSHD comme celles-ci ...
Désactivez l'authentification par mot de passe en faveur de l'authentification par clé:
# grep PasswordAuth sshd_config | grep no
PasswordAuthentication no
Comme mentionné, désactivez les connexions root:
PermitRootLogin no
Ajouter des utilisateurs autorisés à sshd_config:
AllowUsers myusername the_other_sysop_guy
Si vous faites le dernier, le message du journal passera de "utilisateur non valide" à "utilisateur illégal".
En fonction de la situation de votre entreprise, vous pouvez également envisager de pare-feu le port SSHD (autoriser SSH uniquement à partir des adresses IP autorisées) ou de le changer pour utiliser un port différent (qui est vraiment une sécurité par obscurité, mais la plupart des attaques de cette nature sont en fait scriptées) . Hélas, le fait que l'attaquant semble être à l'intérieur de votre réseau local peut faire en sorte que ceux-ci n'offrent pas autant d'aide qu'ils le feraient autrement.
Par ailleurs, le fait que l'appareil soit à 1.1 me fait me demander s'ils sont entrés dans votre routeur? ;-)
L'aspect standard des journaux semble être une attaque par force brute courante car les noms inscrits dans les journaux proviennent d'un dictionnaire standard utilisé. Même les listes de mots courantes les considèrent comme les principaux noms d'utilisateurs cibles. De plus, l'injection provient d'une adresse IP privée de classe B. Ne vous inquiétez pas cependant, tant que les mots de passe que vous avez appliqués sont assez forts et que vous avez un équilibre de charge pour gérer cela ne sera pas un problème pour vous. Recherchez des mesures pour protéger cela dans SSH Brute Force Protection Protection in SSH.
Étant donné que toutes les connexions SSH à votre serveur sont redirigées via la même adresse IP locale, je vous conseille d'utiliser fail2ban avec soin, si vous décidez de l'utiliser. Installation de fail2ban sur le même serveur que sshd entraînera le blocage immédiat de l'IP 172.25.1.1. Après cela, personne ne pourra se connecter via SSH à votre serveur.
Si vous pouvez installer fail2ban sur le serveur qui redirige le trafic SSH, faites-le. J'utilise fail2ban sur mon serveur SSH public, et il fait un excellent travail en limitant l'attaquant à 3 tentatives en 10 minutes. La plupart des scripts de "cracking" utilisés par les enfants de script expireront simplement après ces 3 tentatives et ne me dérangeront plus pendant des jours.
Vous pouvez également ralentir l'attaquant devinant les mots de passe assez facilement.
Dans le fichier /etc/pam.d/sshd, vous pouvez ajouter une ligne comme celle-ci:
auth optional pam_faildelay.so delay=7000000
À chaque tentative de connexion sshd échouée, le module PAM attendra 7 secondes. Vous souhaiterez peut-être augmenter ou diminuer le délai, car si vous saisissez votre propre mot de passe, vous attendez 7 secondes pour obtenir une autre invite. Je risquerais de deviner que la plupart des programmes de devinette de mot de passe SSH sont si peu sophistiqués qu'ils n'ont pas de délai d'attente pour attendre une nouvelle invite, mais il est possible qu'un très long retard entraîne simplement un dépassement de délai des meilleurs programmes de devinette.