Question:
Utilisateurs non valides essayant de se connecter à mon serveur
mk_89
2012-10-03 18:28:50 UTC
view on stackexchange narkive permalink

Je vois de nombreuses entrées de journal qui semblent être des tentatives de connexion infructueuses à partir d'adresses IP inconnues.

J'utilise des clés privées et publiques pour me connecter avec SSH mais j'ai remarqué que même avec des clés privées et publiques définies, je suis capable de me connecter à mon serveur avec filezilla sans exécuter pageant . Est-ce normal? Que dois-je faire pour me protéger davantage de ce qui semble être une attaque par force brute?

Voici le journal: 

  3 oct 14:11:52 xxxxxx sshd [29938] : Utilisateur non valide postgres du 212.64.151.233Oct 3 14:11:52 xxxxxx sshd [29938]: input_userauth_request: postgres utilisateur non valide [préauth] 3 octobre 14:11:52 xxxxxx sshd [29938]: Déconnexion reçue de 212.64.151.233: 11 : Bye Bye [preauth] 3 oct 14:11:52 xxxxxx sshd [29940]: Utilisateur non valide postgres du 212.64.151.233Oct 3 14:11:52 xxxxxx sshd [29940]: input_userauth_request: postgres d'utilisateur non valide [preauth] 3 oct 14 14 : 11: 52 xxxxxx sshd [29940]: Déconnexion reçue de 212.64.151.233: 11: Bye Bye [préaut] 3 oct 14:11:52 xxxxxx sshd [29942]: postgres utilisateur non valide de 212.64.151.233 3 oct 14:11: 52 xxxxxx sshd [29942]: input_userauth_request: utilisateur non valide postgres [préauth] 3 oct 14:11:52 xxxxxx sshd [29942]: Déconnexion reçue de 212.64.151.233: 11: Bye Bye [préauth] 3 oct 14:11:52 xxxxxx sshd [29944]: postgres utilisateur non valide depuis 212.64.151.233Oct 3 14:11:52 xxxxxx sshd [29944]: input_userauth_request: postgres utilisateur non valide [préaut] 3 oct 14:11:52 xxxxxx sshd [29944]: Déconnexion reçue de 212.64.151.233: 11: Bye Bye [préauth] 3 oct 14 14 : 11: 52 xxxxxx sshd [29946]: Déconnexion reçue de 212.64.151.233: 11: Bye Bye [preauth] 3 oct 14:11:52 xxxxxx sshd [29948]: Déconnexion reçue de 212.64.151.233: 11: Bye Bye [préautorisation ] 3 oct 14:11:52 xxxxxx sshd [29950]: déconnexion reçue de 212.64.151.233: 11: Bye Bye [préaut] 3 oct 14:11:52 xxxxxx sshd [29952]: déconnexion reçue de 212.64.151.233: 11: Bye Bye [préaut] 3 oct 14:11:53 xxxxxx sshd [29954]: administrateur utilisateur non valide de 212.64.151.233
3 oct 14:11:53 xxxxxx sshd [29954]: input_userauth_request: utilisateur non valide admin [preauth] 3 oct 14:11:53 xxxxxx sshd [29954]: Déconnexion reçue de 212.64.151.233: 11: Bye Bye [préauth] 3 oct. 14:11:53 xxxxxx sshd [29956]: administrateur utilisateur non valide à partir de 212.64.151.233 3 octobre 14:11:53 xxxxxx sshd [29956]: input_userauth_request: administrateur utilisateur invalide [préauth] 3 octobre 14:11:53 xxxxxx sshd [29956] ]: Déconnexion reçue de 212.64.151.233: 11: Bye Bye [preauth] 3 oct 14:11:53 xxxxxx sshd [29958]: Admin utilisateur non valide de 212.64.151.233Oct 3 14:11:53 xxxxxx sshd [29958]: input_userauth_request : utilisateur non valide admin [préaut] 3 oct 14:11:53 xxxxxx sshd [29958]: déconnexion reçue de 212.64.151.233: 11: Bye Bye [préauth] 3 oct 14:11:53 xxxxxx sshd [29960]: utilisateur mysql non autorisé car le compte est verrouilléOct 3 14:11:53 xxxxxx sshd [29960]: input_userauth_request: utilisateur non valide mysql [préauth] 3 oct 14:11:53 xxxxxx sshd [29960]: Déconnexion reçue de 212.64.151.233: 11: Bye Bye [ préauth] 3 octobre 14:11:53 xxxxxx s shd [29962]: Utilisateur mysql non autorisé car le compte est verrouilléOct 3 14:11:53 xxxxxx sshd [29962]: input_userauth_request: utilisateur non valide mysql [préauth] 3 octobre 14:11:53 xxxxxx sshd [29962]: Déconnexion reçue de 212.64 .151.233: 11: Bye Bye [preauth] 3 oct 14:11:53 xxxxxx sshd [29964]: Utilisateur non valide prueba de 212.64.151.233Oct 3 14:11:53 xxxxxx sshd [29964]: input_userauth_request: utilisateur invalide prueba [preauth ] 3 oct 14:11:53 xxxxxx sshd [29964]: déconnexion reçue de 212.64.151.233: 11: Bye Bye [préaut] 3 oct 14:11:53 xxxxxx sshd [29966]: utilisateur non valide prueba de 212.64.151.233Oct 3 14:11:53 xxxxxx sshd [29966]: input_userauth_request: utilisateur invalide prueba [préauth] 3 oct 14:11:53 xxxxxx sshd [29966]: Déconnexion reçue de 212.64.151.233: 11: Bye Bye [préauth] 3 oct 14: 11:53 xxxxxx sshd [29968]: Utilisateur non valide usuario de 212.64.151.233Oct 3 14:11:53 xxxxxx sshd [29968]: input_userauth_request: utilisateur non valide usuario [préauth]
3 oct 14:11:53 xxxxxx sshd [29968]: Déconnexion reçue de 212.64.151.233: 11: Bye Bye [préaut] 3 oct 14:11:54 xxxxxx sshd [29970]: Utilisateur non valide usuario de 212.64.151.233Oct 3 14 : 11: 54 xxxxxx sshd [29970]: input_userauth_request: utilisateur non valide usuario [preauth] 3 oct 14:11:54 xxxxxx sshd [29970]: Déconnexion reçue de 212.64.151.233: 11: Bye Bye [préauth] 3 oct 14:11 : 54 xxxxxx sshd [29972]: Administrateur utilisateur non valide depuis 212.64.151.233 3 octobre 14:11:54 xxxxxx sshd [29972]: input_userauth_request: administrateur utilisateur non valide [préauth] 3 octobre 14:11:54 xxxxxx sshd [29972]: Reçu déconnecter de 212.64.151.233: 11: Bye Bye [preauth] 3 oct 14:11:54 xxxxxx sshd [29974]: Utilisateur non valide nagios de 212.64.151.233Oct 3 14:11:54 xxxxxx sshd [29974]: input_userauth_request: utilisateur non valide nagios [préaut] 3 oct 14:11:54 xxxxxx sshd [29974]: Déconnexion reçue de 212.64.151.233: 11: Bye Bye [préauth] 3 oct 14:11:54 xxxxxx sshd [29976]: utilisateur non valide nagios de 212.64. 151.233Oct 3 14:11:54 xxxxxx sshd [29976]: entrée _userauth_request: utilisateur non valide nagios [préauth] 3 oct 14:11:54 xxxxxx sshd [29976]: déconnexion reçue de 212.64.151.233: 11: Bye Bye [préauth] 3 oct 14:11:54 xxxxxx sshd [29978]: utilisateur non valide nagios du 212.64.151.233 3 octobre 14:11:54 xxxxxx sshd [29978]: input_userauth_request: utilisateur non valide nagios [préauth] 3 octobre 14:11:54 xxxxxx sshd [29978]: Déconnexion reçue de 212.64.151.233: 11: Bye Bye [preauth] 3 octobre 14:11:54 xxxxxx sshd [29980]: nagios utilisateur non valide du 3 octobre 212.64.151.233 14:11:54 xxxxxx sshd [29980]: input_userauth_request: utilisateur nagios non valide [préauth] 3 octobre 14:11: 54 xxxxxx sshd [29980]: Déconnexion reçue de 212.64.151.233: 11: Bye Bye [préaut] 3 oct 14:11:54 xxxxxx sshd [29982]: oracle utilisateur non valide de 212.64.151.233 3 oct. 14:11:54 xxxxxx sshd [29982]: input_userauth_request: utilisateur non valide oracle [preauth] 3 octobre 14:11:54 xxxxxx sshd [29982]: déconnexion reçue de 212.64.151.233: 11: Bye Bye [préauth]
3 oct 14:11:54 xxxxxx sshd [29984]: oracle utilisateur non valide de 212.64.151.233 3 oct 14:11:54 xxxxxx sshd [29984]: input_userauth_request: utilisateur non valide oracle [préauth] 3 oct 14:11:54 xxxxxx sshd [29984]: Déconnexion reçue de 212.64.151.233: 11: Bye Bye [préaut] 3 oct 14:11:54 xxxxxx sshd [29986]: oracle utilisateur non valide de 212.64.151.233Oct 3 14:11:54 xxxxxx sshd [29986] : input_userauth_request: utilisateur non valide oracle [préauth] 3 oct 14:11:54 xxxxxx sshd [29986]: déconnexion reçue de 212.64.151.233: 11: Bye Bye [préauth] 3 oct 14:11:55 xxxxxx sshd [29988]: invalide utilisateur oracle de 212.64.151.233Oct 3 14:11:55 xxxxxx sshd [29988]: input_userauth_request: utilisateur non valide oracle [préauth] 3 octobre 14:11:55 xxxxxx sshd [29988]: Déconnexion reçue de 212.64.151.233: 11: Bye Bye [preauth] 3 oct 14:11:55 xxxxxx sshd [29990]: Utilisateur ftpuser non valide depuis 212.64.151.233Oct 3 14:11:55 xxxxxx sshd [29990]: input_userauth_request: utilisateur ftpuser non valide [préauth] 3 oct 14:11 : 55 xxxxxx sshd [29990]: Dis reçu se connecter depuis 212.64.151.233: 11: Bye Bye [préauth] 3 oct 14:11:55 xxxxxx sshd [29992]: Utilisateur non valide ftpuser depuis 212.64.151.233Oct 3 14:11:55 xxxxxx sshd [29992]: input_userauth_request: utilisateur invalide ftpuser [preauth] 3 oct 14:11:55 xxxxxx sshd [29992]: Déconnexion reçue de 212.64.151.233: 11: Bye Bye [preauth] 3 oct 14:11:55 xxxxxx sshd [29994]: ftpuser utilisateur non valide de 212.64. 151.233Oct 3 14:11:55 xxxxxx sshd [29994]: input_userauth_request: utilisateur non valide ftpuser [préauth] 3 oct 14:11:55 xxxxxx sshd [29994]: Déconnexion reçue de 212.64.151.233: 11: Bye Bye [préauth] oct 3 14:11:55 xxxxxx sshd [29996]: Invité utilisateur non valide à partir de 212.64.151.233Oct 3 14:11:55 xxxxxx sshd [29996]: input_userauth_request: invité utilisateur non valide [préauth] 3 octobre 14:11:55 xxxxxx sshd [ 29996]: Déconnexion reçue de 212.64.151.233: 11: Bye Bye [préaut] 3 oct 14:11:55 xxxxxx sshd [29998]: Invité d'utilisateur non valide de 212.64.151.233
3 oct 14:11:55 xxxxxx sshd [29998]: input_userauth_request: invité utilisateur non valide [préauth] 3 oct 14:11:55 xxxxxx sshd [29998]: Déconnexion reçue de 212.64.151.233: 11: Bye Bye [préauth] 3 oct. 14:11:55 xxxxxx sshd [30000]: Invité utilisateur non valide à partir de 212.64.151.233Oct 3 14:11:55 xxxxxx sshd [30000]: input_userauth_request: invité utilisateur non valide [préauth] 3 octobre 14:11:55 xxxxxx sshd [30000 ]: Déconnexion reçue de 212.64.151.233: 11: Bye Bye [preauth] 3 oct 14:11:55 xxxxxx sshd [30002]: Invité utilisateur non valide de 212.64.151.233Oct 3 14:11:55 xxxxxx sshd [30002]: input_userauth_request : invité utilisateur non valide [préaut] 3 oct 14:11:55 xxxxxx sshd [30002]: déconnexion reçue de 212.64.151.233: 11: Bye Bye [préauth] 3 oct 14:11:56 xxxxxx sshd [30004]: test utilisateur non valide de 212.64.151.233Oct 3 14:11:56 xxxxxx sshd [30004]: input_userauth_request: test utilisateur non valide [préauth] 3 oct 14:11:56 xxxxxx sshd [30004]: Déconnexion reçue de 212.64.151.233: 11: Bye Bye [ preauth] 3 octobre 14:11:56 xxxxxx sshd [30006]: Test utilisateur non valide du 3 octobre 212.64.151.233 14:11:56 xxxxxx sshd [30006]: input_userauth_request: test utilisateur non valide [préaut] 3 octobre 14:11:56 xxxxxx sshd [30006]: Déconnexion reçue de 212.64.151.233: 11: Bye Bye [preauth] 3 oct 14:11:56 xxxxxx sshd [30008]: test utilisateur non valide du 212.64.151.233 oct.3 14:11:56 xxxxxx sshd [30008]: input_userauth_request: test utilisateur invalide [preauth] 3 oct 14: 11:56 xxxxxx sshd [30008]: Déconnexion reçue de 212.64.151.233: 11: Bye Bye [préaut] 3 oct 14:11:56 xxxxxx sshd [30010]: test utilisateur non valide de 212.64.151.233 3 oct. 14:11:56 xxxxxx sshd [30010]: input_userauth_request: test utilisateur non valide [préauth] 3 oct 14:11:56 xxxxxx sshd [30010]: Déconnexion reçue de 212.64.151.233: 11: Bye Bye [préauth] 3 oct 14:11:56 xxxxxx sshd [30012]: Déconnexion reçue de 212.64.151.233: 11: Bye Bye [préauth] 3 octobre 14:11:56 xxxxxx sshd [30014]: utilisateur non valide de 212.64.151.233Oct 3 14:11:56 xxxxxx sshd [30014] : input_userauth_request: utilisateur non valide [préauth]
3 oct 14:11:56 xxxxxx sshd [30014]: Déconnexion reçue de 212.64.151.233: 11: Bye Bye [preauth] 3 oct 14:11:56 xxxxxx sshd [30016]: utilisateur non valide de 212.64.151.233Oct 3 14 : 11: 56 xxxxxx sshd [30016]: input_userauth_request: utilisateur non valide [préauth] 3 oct 14:11:56 xxxxxx sshd [30016]: Déconnexion reçue de 212.64.151.233: 11: Bye Bye [préauth] 3 oct 14:11 : 56 xxxxxx sshd [30018]: Utilisateur non valide de 212.64.151.233 3 oct 14:11:56 xxxxxx sshd [30018]: input_userauth_request: utilisateur non valide [préauth] 3 octobre 14:11:56 xxxxxx sshd [30018]: Reçu déconnecter de 212.64.151.233: 11: Bye Bye [preauth] 3 oct 14:11:57 xxxxxx sshd [30020]: Utilisateur non valide de 212.64.151.233Oct 3 14:11:57 xxxxxx sshd [30020]: input_userauth_request: utilisateur non valide user [préauth] 3 oct 14:11:57 xxxxxx sshd [30020]: Déconnexion reçue de 212.64.151.233: 11: Bye Bye [préauth] 3 oct 14:11:57 xxxxxx sshd [30022]: utilisateur jboss invalide à partir de 212.64. 151.233Oct 3 14:11:57 xxxxxx sshd [30022]: input_userauth_req uest: utilisateur invalide jboss [preauth] 3 oct 14:11:57 xxxxxx sshd [30022]: déconnexion reçue de 212.64.151.233: 11: Bye Bye [preauth] 3 oct 14:11:57 xxxxxx sshd [30024]: utilisateur invalide jboss du 212.64.151.233Oct 3 14:11:57 xxxxxx sshd [30024]: input_userauth_request: utilisateur invalide jboss [préauth] 3 oct 14:11:57 xxxxxx sshd [30024]: Déconnexion reçue de 212.64.151.233: 11: Bye Bye [preauth] 3 oct 14:11:57 xxxxxx sshd [30026]: utilisateur non valide squid du 212.64.151.233 oct.3 14:11:57 xxxxxx sshd [30026]: input_userauth_request: utilisateur non valide squid [préauth] 3 oct 14:11: 57 xxxxxx sshd [30026]: Déconnexion reçue de 212.64.151.233: 11: Bye Bye [préaut] 3 oct 14:11:57 xxxxxx sshd [30028]: Squid utilisateur non valide de 212.64.151.233Oct 3 14:11:57 xxxxxx sshd [30028]: input_userauth_request: utilisateur non valide squid [preauth] 3 oct 14:11:57 xxxxxx sshd [30028]: Reçu une déconnexion de 212.64.151.233: 11: Bye Bye [préauth] 3 oct 14:11:57 xxxxxx sshd [30030 ]: Température utilisateur non valide de 212.64.151.233
3 oct 14:11:57 xxxxxx sshd [30030]: input_userauth_request: temp utilisateur non valide [préauth] 3 oct 14:11:57 xxxxxx sshd [30030]: Déconnexion reçue de 212.64.151.233: 11: Bye Bye [préauth] 3 oct. 14:11:57 xxxxxx sshd [30032]: utilisateur non valide svn du 3 octobre 212.64.151.233 14:11:57 xxxxxx sshd [30032]: input_userauth_request: utilisateur non valide svn [preauth] 3 octobre 14:11:57 xxxxxx sshd [30032 ]: Déconnexion reçue de 212.64.151.233: 11: Bye Bye [preauth] 3 oct 14:11:57 xxxxxx sshd [30034]: Utilisateur non valide ts de 212.64.151.233Oct 3 14:11:57 xxxxxx sshd [30034]: input_userauth_request : utilisateur non valide ts [preauth] 3 oct 14:11:57 xxxxxx sshd [30034]: Reçu une déconnexion de 212.64.151.233: 11: Bye Bye [preauth]
Sept réponses:
Thomas Pornin
2012-10-03 20:12:41 UTC
view on stackexchange narkive permalink

C'est très courant. De nombreux botnets tentent de se propager de cette façon, il s'agit donc d'une attaque irréfléchie à grande échelle. Les mesures d'atténuation incluent:

  • Utilisez des mots de passe à entropie élevée qui sont très peu susceptibles d'être forcés brutalement.
  • Désactivez la connexion SSH pour root .
  • Utilisez un nom d'utilisateur "improbable", que les botnets n'utiliseront pas.
  • Désactivez complètement l'authentification par mot de passe.
  • Exécutez le Serveur SSH sur un autre port que 22.
  • Utilisez fail2ban pour rejeter automatiquement l'adresse IP des attaquants ou les ralentir.
  • Autoriser les connexions SSH uniquement à partir d'une liste blanche de IP (attention à ne pas vous verrouiller si votre IP domestique est nominalement dynamique!).

La plupart de ces mesures consistent à garder vos fichiers journaux petits; même lorsque la force brute échoue, les milliers d'entrées de journal posent problème car elles peuvent masquer les attaques ciblées réelles. Un peu de sécurité par l'obscurité (comme le nom d'utilisateur improbable et le changement de port) fait des merveilles contre les attaquants stupides: oui, la sécurité par l'obscurité est mauvaise et mauvaise et ainsi de suite, mais parfois cela fonctionne et vous ne serez pas grillé par une vengeance deity si vous l'utilisez de manière sensible.

Un mot de passe à haute entropie sera efficace contre les attaquants intelligents, cependant, et ne peut être recommandé que dans toutes les situations.

J'ajouterais également «SSH interdit d'Internet» ou «SSH autorisé uniquement à partir de certaines IP». J'autorise SSH à mon routeur domestique uniquement à partir de mes adresses IP internes et de mon adresse IP professionnelle.
AilixeofrcCMT FAIT.
Un mot de passe à haute entropie n'est-il pas la sécurité ultime par l'obscurité? :)
@MichaelKjörling: He. C'est la sécurité par l'obscurité totale. Muuuuch mieux. (Sérieusement, cependant, toute la différence est la quantification: si je peux mesurer combien il est sécurisé, comme l'entropie de mot de passe, alors ce n'est pas "par obscurité".)
@ThomasPornin Déplacer SSH vers un port TCP aléatoire ajoute environ 16 bits d'entropie à toutes les autres mesures de sécurité que vous avez en place, car il y a 16 bits disponibles pour chaque port (source et destination) dans TCP. C'est donc certainement mesurable. Je suppose que vous pouvez également affirmer que cela ajoute plus d'entropie dans la pratique, car avant que l'attaquant n'obtienne cette partie correctement, rien d'autre n'a d'importance (vous ne savez même pas que SSH est disponible). Cela dit, j'ai quand même voté à la hausse parce que je pensais que c'était une excellente liste d'options possibles pour aider dans la situation du PO.
@MichaelKjörling: malheureusement, cela ne fonctionne pas ainsi: les bits d'entropie ne s'additionnent que lorsque les données secrètes ne peuvent être attaquées que d'un seul coup. Avec SSH, vous pouvez d'abord localiser le serveur en essayant les valeurs de port (un serveur SSH répondra avec une bannière). Une fois le serveur SSH localisé, les mots de passe peuvent être essayés sur ce port, sans se soucier des autres. Pour obtenir 16 bits d'entropie supplémentaire, vous devez en fait exécuter 65000 faux serveurs SSH qui ne peuvent pas être distingués du vrai, sauf qu'ils rejettent tous les mots de passe (mmh ... cela pourrait être fait avec _un_ faux sshd, et certains iptables).
@ThomasPornin Bon point.
Je suis un grand fan de ce que vous avez mentionné - la désactivation totale des connexions par mot de passe.Forcer la connexion par clé ssh, puis ne générer que des clés «rsa 4096» ou plus puissantes.Je recommande, en outre, d'ajouter google-authentication pour exiger l'authentification multifacteur à chaque fois qu'un mot de passe serait utilisé (sudo, par exemple).
user10211
2012-10-03 19:02:59 UTC
view on stackexchange narkive permalink

La méthode la plus simple et la plus sûre pour empêcher tout accès indésirable via SSH à votre serveur sera de n'autoriser l'accès SSH qu'à certains hôtes.

Ceci peut être facilement configuré avec des wrappers TCP si vous utilisez un serveur Linux. Les pare-feu pour restreindre l'accès fonctionneront également.

Contrairement aux autres réponses, je ne pense pas que changer le port par défaut du service ssh soit une bonne idée. La sécurité par l'obscurité ne fonctionne jamais et n'arrêtera pas une attaque ciblée par un attaquant déterminé. Cela pose également des problèmes de convivialité dans mon expérience.

Si la limitation de l'accès SSH à certains hôtes n'est pas une option, la liste noire des adresses IP d'où provient l'attaque pourrait également fonctionner. Cependant, notez que cela ne sera pas efficace contre les attaquants qui utilisent plusieurs adresses IP d'autres machines compromises pour vous attaquer.

Oui, j'ai remarqué que les adresses IP dans mon fichier journal semblent varier, mais la liste noire des adresses IP dissuadera sûrement quiconque de tenter de force brute
aussi je ne peux pas mettre en œuvre ce que vous avez suggéré dans le premier paragraphe car j'ai une adresse IP dynamique, je dois continuer à changer l'adresse IP dans le phpmyadmin apache.conf juste pour me connecter à phpmyadmin
OtisBoxcar
2012-10-03 18:48:06 UTC
view on stackexchange narkive permalink

Il y a deux choses que vous pouvez faire, et il semble que vous en faites déjà quelques-unes, donc c'est bien.

  1. Exiger un fichier clé pour vous connecter.
  2. N'exécutez pas SSH sur le port 22. C'est le premier (et généralement le seul) endroit qu'un bot recherchera, et vous pouvez éviter 90% de ces tentatives de connexion en modifiant simplement la configuration SSHD. [ Edit: Comme le dit à juste titre Terry Chia, c'est la sécurité par l'obscurité. Cela peut garder vos journaux plus propres des entrées de bot, mais cela ne ralentira pas un peu un humain. Si votre système n'est toujours pas sécurisé, déplacer l'insécurité vers un autre port n'aidera pas.]
  3. Utilisez quelque chose comme Fail2ban. Il surveille vos journaux et peut ajouter des règles de pare-feu pour supprimer les paquets de toute adresse qui échoue à se connecter trop souvent.
  4. Si possible, n'autorisez l'accès qu'à partir d'adresses IP en liste blanche.

En fin de compte, si vous avez un service comme SSH acceptant les paquets d'Internet plus large, vous ne pouvez rien faire pour empêcher les gens d'essayer de l'attaquer. Une fois que vous êtes convaincu d'avoir pris les précautions appropriées, les entrées de journal telles que celles-ci doivent être notées, mais finalement traitées comme du bruit de fond.

Cependant, ils semblent tous être des idées judicieuses, car je gère réellement un site Web 4. ne serait pas possible à implémenter.
Compte tenu de ce que vous avez dit, alors, je recommande d'examiner quelque chose comme Fail2ban. Quelque chose pour garder les loups à distance pendant que vous n'êtes pas là pour bloquer manuellement chaque IP.
sudhacker
2012-10-03 18:36:44 UTC
view on stackexchange narkive permalink

Avoir un port SSH ouvert est certainement sujet à ce genre d'attaques car il y a tellement de bots qui essaient de rechercher des ports SSH ouverts et de lancer de telles attaques par force brute dans le but d'en obtenir un. Il y aura évidemment un problème si vous avez utilisé les paramètres SSHD par défaut et autoriser les connexions basées sur un mot de passe. Heureusement, non. Je crois que changer votre port par défaut pour écouter sur votre SSHD réduira certainement le nombre de tentatives puisque la plupart des scanners recherchent le port ouvert 22. Il s'agit de «sécurité par l'obscurité» et ce n'est certainement pas une solution recommandée. Mais cela résoudra votre problème actuel, jusqu'à ce que quelqu'un avec plus d'expérience fournisse une meilleure solution.

Je lisais sur le changement de port, cela semble être une bonne idée pour éliminer les bots du parfum
Ouais, essayez-le et dites-nous si cela a aidé
Martin
2012-10-04 11:37:35 UTC
view on stackexchange narkive permalink

Ou utilisez la liste noire de http://www.blocklist.de/en/export.html et signalez tous les nouveaux attaquants.

Importez le ssh.txt et bloquez toutes les adresses IP qui ont été signalées sur la liste noire au cours des 48 dernières heures sur ssh-attack ou les bloquer avec fail2ban et les signaler automatiquement à leur FAI.Iptables-blocklist-script sont dans le forum disponibles au téléchargement.

Bienvenue sur [security.se] - veuillez consulter la [FAQ], il est considéré comme une mauvaise forme de ne pas divulguer votre connexion avec un site Web dont vous faites la promotion ... ce qui ne devrait pas être du tout le point de réponse, bien sûr - voir la réponse]. Votre réponse pourrait être bien meilleure si vous expliquez comment l'utilisation de ce site Web aiderait l'OP, au lieu de simplement laisser tomber un lien. Et, veuillez divulguer votre affiliation.
Kaz
2012-10-04 02:08:19 UTC
view on stackexchange narkive permalink

Parce que je trouve que ces requêtes SSH et les rames de journaux qu'elles génèrent sont un gaspillage ennuyeux de ressources système, j'utilise le port knocking. Le port SSH n'est visible que pour les hôtes dont la séquence de coups est reçue. Pour les autres hôtes, il semble qu'il n'y ait pas de service SSH sur cette machine.

Le cliquetis de port est un peu gênant dans la mesure où pour l'utiliser de manière fiable sur des réseaux long-courriers avec un décalage variable, vous avez vraiment besoin d'un programme client pour envoyer la séquence de frappe. De plus, vous pouvez vous retrouver dans un réseau qui bloque le trafic sortant vers certains des numéros de port que vous avez choisis dans votre séquence de frappe de port.

Au lieu de frapper de port, vous pouvez implémenter le knocking Web. Si la machine exécute un serveur Web public, vous pouvez mettre une toute petite application Web (sous une URL que vous seul connaissez) de sorte que si vous parcourez cette URL et mettez une valeur correcte dans un formulaire et soumettez-le, il s'ouvrira dans le port.

La frappe de port est [la sécurité par l'obscurité] (http://security.stackexchange.com/a/1198/3644). Utilisez plutôt les clés ssh et fail2ban.
L'argument selon lequel le cliquetis de port est la sécurité par l'obscurité est purement faux (car cela implique que le cliquetis de port est la sécurité, ce qui n'est pas le cas). Bien que la séquence de frappe soit une sorte de mot de passe, il n'y a pas d'élévation significative des privilèges lorsqu'elle est utilisée. Si vous obtenez la séquence, vous n'avez pas eu accès à quelque chose d'important, seulement la possibilité de parler à un port (quelque chose que de nombreux serveurs laissent déjà ouvert). Il ne peut pas être comparé à un mot de passe en texte clair qui vous donne une invite du shell.
Donc, si, disons, 0,01% des crackers devinent ma séquence de frappe au port, je m'en fiche. Ils n'entrent pas, et les 99,99% restants ne l'ont pas deviné. Cela garde toujours mon syslog plus propre et ma machine plus calme que si je n'avais pas le coup.
`fail2ban` a l'air cool. J'ai fait ce genre de chose avec des scripts connectés à Apache. Cela ressemble à mon genre de programme.
gregg
2013-11-27 04:35:24 UTC
view on stackexchange narkive permalink

Concernant votre question filezilla / pagaent: la réponse courte est oui, c'est normal. J'appellerais cela un effet secondaire involontaire. Sur la base de mon expérience si vous utilisez du mastic, configurez-y la clé privée (Connection, SSH, Auth), & enregistre la session qui sera stockée dans le registre. Si vous nommez le 'Site' dans filezilla de la même manière que vous avez fait la session dans putty, filezilla regarde ce registre pour putty qu'& l'utilise

J'ai parlé de cela dans leurs forums (principalement dans le contexte de l'utilisation de clés protégées par mot de passe)



ⓘ
Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...