Vraag:
Wordt het de moeite waard geacht om het modulibestand van OpenSSH te vervangen?
evaryont
2015-01-13 03:58:21 UTC
view on stackexchange narkive permalink

Gevolgen van tampered / etc / ssh / moduli beschrijft een mogelijk risico als er met het modulibestand voor een OpenSSH-server is geknoeid.

Met de logica een stap verder, is er enige bezorgdheid over het standaardbestand dat met OpenSSH wordt meegeleverd? Vraag ik omdat het artikel Secure Secure Shell dit vermeldt:

Als je ervoor kiest om 5 [diffie-hellman-group-exchange-sha256] in te schakelen, open dan / etc / ssh / moduli indien aanwezig, en verwijder regels waarvan de 5e kolom kleiner is dan 2000. Als deze niet bestaat, maak het dan aan: 

  ssh-keygen -G "$ {HOME} / moduli" -b 4096ssh-keygen -T / etc / ssh / moduli -f "$ {HOME} / moduli" rm "$ {HOME} / moduli"

Dit leest als me alsof DH-priemgetallen van minder dan 2048 als onzeker worden beschouwd en moeten worden vervangen door grotere priemgetallen. De OpenSSH-ontwikkelaars, slimme mensen, hebben het bestand dat standaard wordt meegeleverd echter niet vervangen door een bestand dat grotere prime-lenzen bevat. Mis ik iets?

Het bevat grote prime-lenzen, maar ik vermoed dat kleinere niet zijn vervangen vanwege compatibiliteit met oude servers die niet zijn geüpgraded.
Aanvullende informatie over het onderwerp https://www.linode.com/docs/security/advanced-ssh-server-security/
Een antwoord:
stribika
2015-01-28 09:43:39 UTC
view on stackexchange narkive permalink

Uitwisseling / selectieproces

Waarom priemgetallen verwijderen die korter zijn dan 2000 bits? Volgens RFC4419 begint de sleuteluitwisseling met de client die zijn voorkeuren naar de server verzendt in de vorm van 3 getallen:

  • de minimaal aanvaardbare moduluslengte,
  • de maximaal acceptabele lengte
  • en de gewenste lengte.

Vervolgens kiest de server een willekeurig priemgetal dat het beste aan deze vereiste voldoet.

In de praktijk (tenminste met OpenSSH 6.7), is het minimum en maximum van de cliënt altijd 1024 en 8192. De geprefereerde lengte is 8 keer het beveiligingsniveau van het symmetrische cijfer. De server kiest dan als volgt:

  • het verwijdert de priemgetallen buiten het min-max bereik,
  • dan kiest het de kortste beschikbare lengte die niet minder is dan de gewenste lengte
  • ten slotte kiest het er willekeurig een uit.

Met AES-128 krijgen we een 1024 bit-modulus, wat meer lijkt op 2 ^ 80 pogingen om te breken . (Het is niet lineair, je kunt het niet gewoon vermenigvuldigen met 8.)

Waarom opnieuw genereren?

Waarom het bestand helemaal opnieuw genereren? Om RFC4419 te citeren: 

  Het gebruik van meerdere moduli verhindert een vastberaden aanvaller om moduli-uitwisselingswaarden voor te berekenen, en ontmoedigt het toewijzen van bronnen voor analyse van een bepaalde modulus.

Dit is aangetoond in de Logjam -aanval.

Het is niet zo effectief als iedereen hetzelfde modulibestand gebruikt dat wordt gedistribueerd met het SSH-pakket. Om deze reden heb ik op elke host verschillende modulibestanden gegenereerd.

Opmerking: moderne SSH gebruikt elliptische kromme Diffie-Hellman, wat in theorie veiliger is.

Als je nieuwe niet-elliptische-curve-priemgetallen wilt genereren, doe dit dan: 

  ssh-keygen -G moduli-2048. kandidaten -b 2048ssh-keygen -T moduli-2048 -f moduli -2048.candidates

Vervang vervolgens de inhoud van uw moduli-bestand (meestal / etc / ssh / moduli ) door de inhoud van moduli-2048

Sorry dat ik een necro doe, maar betekent uw uitspraak _ "moderne SSH gebruikt elliptische kromme Diffie-Hellman" _ dat ik niet langer nieuwe moduli hoef te genereren met de `ssh-keygen -G` en` ssh-keygen -T`procedure?
Als u alle DH-GEX-algoritmen op de server uitschakelt, heeft u deze niet nodig.Anders kunnen clients het nog steeds proberen te gebruiken, en als u helemaal geen bestand heeft (of als er geen geldige keuzes zijn), zal de server de hardgecodeerde groep 14, groep 16 of groep 18 verzenden.


ⓘ
Deze Q&A is automatisch vertaald vanuit de Engelse taal.De originele inhoud is beschikbaar op stackexchange, waarvoor we bedanken voor de cc by-sa 3.0-licentie waaronder het wordt gedistribueerd.
Loading...