7 votes

avertissement de sshd, "POSSIBLE BREAK-IN ATTEMPT !" pour échec de reverse DNS

Chaque fois que je SSH quelque part, j'obtiens quelque chose comme ceci dans les journaux :

sshd[16734]: reverse mapping checking getaddrinfo for
    1.2.3.4.crummyisp.net [1.2.3.4] failed - POSSIBLE BREAK-IN ATTEMPT!

Et il es Exact : si je le fais host 1.2.3.4 il retourne 1.2.3.4.crummyisp.net , mais si je le fais host 1.2.3.4.crummyisp.net il n'est pas trouvé.

J'ai deux questions :

  1. Quelle est la menace pour la sécurité ? Comment quelqu'un pourrait-il falsifier un DNS à sens unique à sens unique de manière menaçante ?

  2. Ai-je un recours pour réparer cela ? Je vais envoyer un rapport de bug à mon FAI, mais qui sait où cela mènera.

6voto

voretaq7 Points 78924

Quelle est la menace pour la sécurité ?
Comment quelqu'un pourrait-il falsifier un DNS à sens unique d'une manière menaçante ?

Toute partie ayant le contrôle d'une zone DNS inverse peut définir ses enregistrements PTR comme elle le souhaite. Il est concevable que quelqu'un puisse définir son enregistrement PTR comme étant legithost.example.com et essaient ensuite de s'introduire par force brute dans votre environnement.

Si vous avez des utilisateurs à gros doigts qui ont tendance à mal saisir leurs mots de passe, et si vous n'avez pas de mesures anti-brute-force, une série d'entrées de journal pour des mots de passe échoués provenant de legithost.example.com pourrait être rejetée comme "Oh, c'est juste Bob - il ne peut pas taper pour sauver sa vie !" et donner à un attaquant l'occasion de continuer à deviner les mots de passe jusqu'à ce qu'ils entrent.

(L'avantage théorique de sécurité de ce message est que l'attaquant ne peut pas créer/modifier le A record pour legithost.example.com dans votre zone DNS, de sorte qu'il ne peut pas faire taire l'avertissement - à moins d'une attaque par empoisonnement DNS de quelque sorte...)


Ai-je un recours pour réparer cela ?

Option 1 : Corrigez votre DNS pour que le forward ( A ) et inverse ( PTR ) correspondent.
Option 2 : Ajouter UseDNS no de votre système sshd_config pour faire taire l'avertissement.

1voto

Gert van den Berg Points 165

Si HostbasedAuthentication est configuré, vous pouvez spécifier les noms d'hôtes qui peuvent se connecter à l'application /etc/hosts.equiv , ~/.shosts y ~/.rhosts . (Il y a également une vérification de la clé publique sur l'hôte client. known_host au serveur)).

Ceci peut être exploité si la clé fuit (dans ce cas, vous avez déjà un problème) et HostbasedUsesNameFromPacketOnly est réglé sur yes (Possiblement UseDNS no peut également être nécessaire) et un attaquant, avec les clés pertinentes, donne le nom d'hôte d'un hôte autorisé.

Une autre attaque peut consister à ce qu'un serveur connu se fasse passer pour un autre serveur connu afin d'obtenir des privilèges plus élevés.

Afin d'éviter ces attaques, le DNS inverse et le DNS direct sont comparés (et une entrée de journal apparaît s'ils ne correspondent pas).

L'autre chose qui pourrait être attaquée : le authorized_keys host= et le paramètre Match pour un Host qui peut être activé pour le mauvais hôte dans le cas où les noms d'hôtes sont utilisés (au lieu des adresses IP) et que les entrées DNS sont modifiées. ( UseDNS yes est nécessaire pour utiliser les non-IP à cette fin)

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X