Vraag Hoe maak je 'logjam' kwetsbaarheid in Apache (httpd) op te lossen


Onlangs is een nieuwe kwetsbaarheid in Diffie-Hellman, informeel 'logjam' genoemd, gepubliceerd deze pagina is samengesteld om de kwetsbaarheid te verhelpen:

We hebben drie aanbevelingen voor het correct inzetten van Diffie-Hellman   voor TLS:

  1. Schakel Cipher-suites exporteren uit. Hoewel moderne browsers niet langer   export-suites ondersteunen, de FREAK- en Logjam-aanvallen staan ​​een   man-in-the-middle aanvaller om browsers te misleiden tot het gebruik van export-grade   cryptografie, waarna de TLS-verbinding kan worden gedecodeerd. Exporteren   cijfers zijn een overblijfsel van het beleid uit de jaren 90 dat sterk verhinderde   cryptografische protocollen worden niet geëxporteerd vanuit de Verenigde Staten. Nee   moderne klanten vertrouwen op exportsuites en er is weinig nadeel aan   ze uitschakelen.
  2. Implementeer (Ephemeral) Elliptic-Curve Diffie-Hellman   (ECDHE). Elliptic-Curve Diffie-Hellman (ECDH) sleuteluitwisseling vermijdt alles   bekende haalbare cryptanalytische aanvallen en moderne webbrowsers nu   geef de voorkeur aan ECDHE boven het originele, eindige veld, Diffie-Hellman. De   discrete logalgoritmen die we gebruikten om standaard Diffie-Hellman aan te vallen   groepen winnen niet zo sterk van een voordeel uit precomputation, en   individuele servers hoeven geen unieke elliptische curves te genereren.
  3. Genereer een sterke, unieke Diffie Hellman Group. Een paar vaste groepen zijn   gebruikt door miljoenen servers, waardoor ze een optimaal doelwit zijn   precomputation, en potentiële afluisteren. Beheerders zouden dit moeten doen   genereer unieke, 2048-bits of sterkere Diffie-Hellman-groepen met   "veilige" prime-lenzen voor elke website of server.

Wat zijn de best-practice-stappen die ik moet nemen om mijn server te beveiligen volgens de bovenstaande aanbevelingen?


56
2018-05-20 09:34


oorsprong


Verwant: Wat is Logjam en hoe voorkom ik dit? - Martin Schröder


antwoorden:


Van de artikel dat u hebt gekoppeld, er zijn drie aanbevolen stappen om jezelf tegen dit beveiligingslek te beschermen. In principe zijn deze stappen van toepassing op alle software die u mogelijk gebruikt met SSL / TLS, maar hier zullen we de specifieke stappen behandelen om deze toe te passen op Apache (httpd), omdat dat de betreffende software is.

  1. Schakel Cipher-suites exporteren uit

In combinatie met de configuratiewijzigingen die we in 2 hieronder zullen maken (!EXPORT tegen het einde van de SSLCipherSuite regel is hoe we exporteren cipher-suites uitschakelen)

  1. Implementeer (Efemerale) elliptische curve Diffie-Hellman (ECDHE)

Hiervoor moet je een paar instellingen in je Apache-configuratiebestanden bewerken - namelijk SSLProtocol, SSLCipherSuite, SSLHonorCipherOrder om een ​​"best-practices" -instelling te hebben. Iets als het volgende is voldoende:

SSLProtocol             all -SSLv2 -SSLv3

SSLCipherSuite          ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

SSLHonorCipherOrder     on

Opmerking: waarvoor SSLCipherSuite instelling om te gebruiken, dit is altijd aan het veranderen, en het is een goed idee om middelen zoals te raadplegen deze om te controleren op de nieuwste aanbevolen configuratie.

3. Genereer een sterke, unieke Diffie Hellman Group

Om dit te doen, kunt u uitvoeren

openssl dhparam -out dhparams.pem 2048.

Merk op dat dit de server aanzienlijk zal belasten terwijl de params worden gegenereerd - je kunt dit potentiële probleem altijd omzeilen door de params op een andere machine te genereren en te gebruiken scpof vergelijkbaar om ze op de betreffende server te zetten voor gebruik.

Om deze nieuw gegenereerde te gebruiken dhparams in Apache, van de Apache-documentatie:

Gebruik de opdracht openssl dhparam om aangepaste DH-parameters te genereren.   Als alternatief kunt u voeg het volgende toe standaard 1024-bits DH   parameters van RFC 2409, sectie 6.2 naar de respectieve   SSLCertificateFile-bestand:

(nadruk van mij)

welke wordt gevolgd door een standaard 1024-bits DH-parameter. Hieruit kunnen we afleiden dat de op maat gemaakte DH-parameters eenvoudig kunnen worden toegevoegd aan de relevante parameters SSLCertificateFile in kwestie.

Hiertoe voert u iets uit dat lijkt op het volgende:

cat /path/to/custom/dhparam >> /path/to/sslcertfile

Als alternatief, volgens de Apache subsectie van het artikel dat u oorspronkelijk hebt gekoppeld, kunt u ook het aangepaste dhparams-bestand opgeven dat u hebt gemaakt als u het certificaatbestand zelf niet wilt wijzigen, en dus:

SSLOpenSSLConfCmd DHParameters "/path/to/dhparams.pem"

in welke Apache-configuratie (s) ook relevant zijn voor uw specifieke SSL / TLS-implementatie - meestal in conf.d/ssl.confof conf.d/vhosts.conf maar dit zal verschillen afhankelijk van hoe je Apache hebt geconfigureerd.

Het is vermeldenswaard dat, als per deze link,

Vóór Apache 2.4.7 is de DH-parameter altijd ingesteld op 1024 bits en   kan niet door de gebruiker worden geconfigureerd. Dit is opgelost in mod_ssl 2.4.7   Red Hat is met hun RHEL 6 Apache 2.2-distributie teruggestuurd naar   httpd-2.2.15-32.el6

Op Debian Wheezy upgrade apache2 naar 2.2.22-13 + deb7u4 of hoger en opensl naar 1.0.1e-2 + deb7u17. De bovenstaande SSLCipherSuite werkt niet perfect, maar gebruikt in plaats daarvan het volgende deze blog:

SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-DSS-AES128-SHA256:DHE-DSS-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!DHE-RSA-AES128-GCM-SHA256:!DHE-RSA-AES256-GCM-SHA384:!DHE-RSA-AES128-SHA256:!DHE-RSA-AES256-SHA:!DHE-RSA-AES128-SHA:!DHE-RSA-AES256-SHA256:!DHE-RSA-CAMELLIA128-SHA:!DHE-RSA-CAMELLIA256-SHA

U moet controleren of uw Apache-versie later is dan deze versienummers, afhankelijk van uw distributie, en zo niet - werk deze indien mogelijk bij.

Nadat u de bovenstaande stappen hebt uitgevoerd om uw configuratie bij te werken en de Apache-service opnieuw hebt opgestart om de wijzigingen toe te passen, moet u controleren of de configuratie naar wens is door de tests uit te voeren SSLLabs en verder het artikel gerelateerd aan deze specifieke kwetsbaarheid.


81
2018-05-20 09:50



Wat betreft de belasting die op de server wordt gezet door het genereren van de params, kunt u deze altijd genereren op een andere machine en het bestand eenvoudigweg scp of zelfs kopiëren-plakken naar de doelserver. Het is niet nodig om de params in productieserver te genereren. - Erathiel
Nadat u uw configuratie heeft gewijzigd, wilt u misschien een vinkje zetten bij SSLLabs.com zo goed als zeker. - user2428118
Is er een manier om dit beveiligingslek te verhelpen in Apache / 2.2.22 (Ubuntu 12.04)? Ik heb dhparams.pem toegevoegd aan certificate.crt maar weakdh.org/sysadmin.html klaagt nog steeds - tersmitten
@tersmitten Dat is een compleet andere vraag dan deze. - Michael Hampton♦
je kunt altijd de sleutelgeneratie uitvoeren door een 'mooie' opdracht. dus, je kunt het zo zeggen: nice 19 openssl dhparam -out dhparams.pem 2048. Dit werkt langer, maar verbruikt alleen ongebruikte cpu-tijd. - Znik


Op basis van een patch van Winni Neessen heb ik een oplossing voor Apache / 2.2.22 gepubliceerd (Debian Wheezy, misschien ook bruikbaar op Ubuntu): https://flo.sh/debian-wheezy-apache2-logjam-fix/ - Dankje. voor uw feedback.


0
2018-05-21 02:32



dit is meer een hack hack dan een oplossing. een recente nginx voor uw apache plaatsen, omdat reverse-proxy veel eenvoudiger zou zijn en u niet afhankelijk bent van apache van derden. - that guy from over there
Waarom zouden we deze binaries moeten vertrouwen? - α CVn
U hoeft de binaries niet te vertrouwen; je kunt apache2.2.x zelf heel eenvoudig hercompileren door de stappen te volgen die worden uitgelegd als je de tijd neemt. Dit zou bovendien uw veiligheid verhogen, omdat uw opstelling dan unieke primaire sleutels heeft. - Flo
Zou suggereren dat mensen niet klagen over patches die een probleem oplossen in een opensourcesoftware. - Florian Heigl
@FlorianHeigl Ik weet niet eens zeker wat ik van die opmerking moet maken ... - BE77Y


In plaats van de complexe route van de bovenstaande hacks te gebruiken, overweeg dan overschakelen naar nginx als uw belangrijkste webserver-software (niet alleen caching of proxy). Het lijkt duidelijk meer aan de huidige normen te voldoen, qua veiligheid dan de oude apache-engines. Door de repository van nginx te gebruiken, krijgt u een meer up-to-date stabiele webserver-engine dan apache.

Ik ben helemaal overgestapt. Bespaarde me veel tijdrovende problemen oplossen met betrekking tot TLS, en - voor onze configuraties - het ook vrij veel RAM in dezelfde mate. Sterker nog, ik vond de tewerkstelling van nginx verfrissend eenvoudig en ongecompliceerd, vergeleken met de talloze config-complicaties van httpd / apache waaraan ik gewend was geraakt. Zou een kwestie van smaak kunnen zijn, ik was behoorlijk vloeiend geworden in httpd / apache rewrite / config / maintenance voordat ik me draaide, en het was gemakkelijker dan ik vreesde dat het zou zijn. Er is geschikte recente informatie over nginx-config online beschikbaar en de gebruikersbasis is enorm, zeer actief en ondersteuningsvriendelijk. https://news.netcraft.com/wp-content/uploads/2018/03/wpid-wss-top-1m-share.png


-7
2017-11-04 11:16



nginx opgezet om exportcijfers toe te staan ​​zou zijn precies zo kwetsbaar voor de Logjam-aanval als een Apache-server die is ingesteld om exportcodes toe te staan. Ook vraagt ​​de vraag naar oplossingen in Apache. - α CVn
Niet waar. De belangrijkste reden dat ik ooit een conversie naar nginx heb uitgevoerd, was juist omdat distributiepakketbeheer, zowel yum als apt, toentertijd niet geef een up-to-date versie van apache. Terwijl de geleverde nginx alles inhield wat ik op dat moment nodig had tegen de exploit. Nogmaals, het was meer aan de normen, en ik vermoed dat de updatecyclus veel korter is. Nu is het logjam, maar op het werk kom ik hetzelfde probleem tegen met apache 2.2 en de distro levert geen backport tegen verschillende SSL / TLS-gerelateerde problemen. Oplossing: Vervang apache door nginx. Probleem opgelost. - Julius
Werkelijk, oplossing: ofwel overschakelen naar een distributie die up-to-date pakketten voor software biedt waar je absoluut een nieuwere versie nodig hebt (niet alleen bugfixes die zijn teruggezet, zoals bijvoorbeeld het geval is met Debian of CentOS), of bouw pakketten zelf op vanaf de bron (het is niet moeilijk) en installeer ze met behulp van de pakketbeheerder, of gewoon oud installeren vanaf broncode (ook niet moeilijk, maar het kost wat meer werk om te beheren). Voor een vraag die vraagt ​​"hoe kan ik kwetsbaarheid X in Y-software verminderen?", Is een antwoord dat stelt "Y-software vervangen door Z-software" vaak geen bruikbaar antwoord. - α CVn
Welnu, er is nog steeds dat itsy-bitsy probleem dat afhankelijkheden wordt genoemd, plus zijn niet-gloednieuwe hardware, en afgezien van dat het een systeem is dat ik niet repareer door zijn distro.version te veranderen, hebben we te maken met server-software verschillen met betrekking tot marionet -beheer. Het is niet zo dat we genoeg tijd in de wereld hebben om te besluiten om hele OS-kernen om te wisselen. Eén pakket-upgrade (d.w.z. Apache naar Nginx) is in vergelijking hiermee mogelijk. - Julius
Apache naar Nginx is geen upgrade, het is een vervanging. Backporting is een mogelijkheid. Als je veel werk hebt geïnvesteerd in de Apache-oplossing, kost het volledig weggooien en vervangen van iets met iets anders ook veel werk. En deze vraag is nog steeds over oplossingen rond gecentreerd Apache, niet Nginx. Ik ga hier niet langer over ruzie maken; wanneer je antwoorden plaatst, zorg er dan voor dat ze de vraag beantwoorden zoals gevraagd aan de bovenkant van de pagina. Als je een antwoord wilt plaatsen om mensen aan te moedigen om van Apache naar Nginx over te schakelen, doe dat dan zeker, maar dan voor een vraag die Nginx mogelijk maakt. - α CVn