Jump to content

addy0604

Members
  • Content Count

    75
  • Joined

  • Last visited

Community Reputation

11 Neutral

About addy0604

  • Rank
    Newbie
  • Birthday 04/06/1971

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Bei dem Pentest ging es lediglich darum von extern aus dem Internet zu prüfen, welche Schwachstellen die Systeme aufzeigen. Er hat uns lediglich darüber zu informieren und eine Einschätzung über die Risiken und Eintrittswahrscheinlichkeiten aufzuzeigen. Was wir mit den Informationen machen ist dann nicht sein Bier. Und auch wenn TLS 1.0 in der "üblichen Praxis" nicht mehr genutzt wird, so besteht zumindest die theoretische Möglichkeit. 100%ige Sicherheit gibt es sowieso nicht, aber man sollte zumindest versuchen, die Risiken im akzeptablen Rahmen zu minimieren.
  2. Nee oder... ähm, guten Morgen... die Zahl dort im Link ist die KB-Nummer? Da wäre denen kein Zacken aus der Krone gefallen, wenn sie das auf der Seite noch mal erwähnt hätten... Naja, egal, wenn damit wirklich das Update KB3140245 gemeint ist, dann ist es schon knapp 3 Jahre alt und auch schon per WSUS im Netzwerk verteilt. Ich hab gestern Abend die Reg-Datei getestet und auf meiner Testbüchse hat das prima funktioniert. Ich werde die Reg-Datei nun über die Gruppenrichtlinien verteilen und am nächsten Wochenende das TLS 1.0 auf dem Exchange deaktivieren. Vielen herzlichen Dank für die Hilfe Und ja, auch um das CU12 werde ich mich bei Gelegenheit kümmern Grüße Matthias
  3. Welches Update meinst du? Auf der Microsoft-Seite sehe ich nur: To apply this update, the DefaultSecureProtocols registry subkey must be added. Note To do this, you can add the registry subkey manually or install the "Easy fix" to populate the registry subkey. Das liest sich für mich so, als wenn ich entweder die Einträge manuell vornehme oder automatisch von einem "Easy fix" eintragen lasse. Es ist zwar noch von einem hotfix-installer die Rede... Note The hotfix installer doesn't add the DefaultSecureProtocols value. The administrator must manually add the entry after determining the override protocols. Or, you can install the "Easy fix" to add the entry automatically. ... aber einen Download-Button oder eine KB-Nummer hab ich nicht gefunden... oder bin ich blind? Ich habe jedenfalls mal diese Einträge für das Reg-File zusammengestellt: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client] "DisabledByDefault"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client] "DisabledByDefault"=dword:00000000 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings] "SecureProtocols"=dword:00000a80 [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings] "SecureProtocols"=dword:00000a80 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp] "DefaultSecureProtocols"=dword:00000a00 [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp] "DefaultSecureProtocols"=dword:00000a00
  4. Wie Nils schon richtig vermutet hat, hat der Pentester uns einfach nur darauf hingewiesen, das TLS 1.0 noch aktiv ist. Also hab ich es mal abgeschaltet, ist schließlich auch Teil von diversen Anleitungen für das "Härten" von Exchange, und bin daraufhin auf das oben genannte Problem gestoßen. Klar könnte ich es bei TLS 1.0 belassen, funktioniert ja, aber es würde mir bei jedem Test wieder vor die Füße fallen, und so ein klein bissl Ehrgeiz hat man ja auch noch... Ich hab mir mal die Registry-Key von der Microsoft-Seite herausgeschrieben und eine Reg-Datei gebaut. Ich teste das heute Abend mal und gebe euch morgen Bescheid... Grüße Matthias
  5. Hmmm, ich bin mal blauäugig davon ausgegangen, das Win7 auch TLS 1.1 und TLS 1.2 verwendet, wenn man schon in den Internetoptionen einen Haken bei "TLS 1.1 verwenden" und "TLS 1.2 verwenden" setzen kann. Dem scheint ja nicht so zu sein... ich schau mir den Artikel von Microsoft mal genauer an... vielen Dank schon mal für den Tipp
  6. Hallo zusammen, ich bin momentan etwas ratlos und weiß nicht so richtig wo das Problem sein soll. Wir haben von einem Dienstleister einen externen Penetrationstest durchführen lassen. Der hat angemosert, das auf dem Mail-Server noch TLS 1.0 aktiv ist. Also hab ich es einfach mal über die Registry deaktiviert. HKLM\System\CurrentControleSet\Control\SecurityProviders\Schannel\Protocols\TLS 1.0\Server - DisabledByDefault 1 - Enabled 0 Nach einem Neustart war keine Verbindung mehr vom Outlook 2016 Client mehr zum Server möglich. Auch das Löschen des Profils und neu Hinzufügen klappt nicht: Es steht keine verschlüsselte Verbindung mit Ihrem E-Mail-Server zur Verfügung. Mit einem Klick auf weiter kommt die Meldung: Probleme beim Herstellen einer Verbindung mit ihrem Konto.... Wenn ich die Änderungen in der Registry rückgängig mache läuft alles wieder reibungslos wie bisher. Hier mal meine Umgebung: Ganz normale Windows-Domäne. Seit letzten Sommer haben wir einen Exchange 2016 mit CU10 auf Windows Server 2012 R2 (Migration von Exchange 2010) Alle Clients laufen auf Windows 7 mit Office 2016 HB bzw. Standard. Autodiscover läuft normal, Verbindungsstatus zeigt keine Auffälligkeiten, Protokoll http, Verschlüsseln ssl etc. Ich habe gerade gesehen, das auf den Clients noch TLS 1.0 aktiv ist. Kann das damit zusammen hängen? Ich hatte es vor einigen Monaten mal per GPO ausgeschaltet. Da es einige Zugriffsprobleme zu internen und externen Seiten gab hatte ich es wieder aktiviert... Grüße Matthias
  7. Nee oder? Ich krieg die Kriese.... wieso funktioniert das nun plötzlich... Ich hab mir die Scripte mal angeschaut und noch mal durchprobiert. Es liegt echt daran, das die Parameter in einer bestimmten Reihenfolge angeordnet sein müssen. An die Möglichkeit hab ich nicht gedacht und ist auch nirgends extra erwähnt worden. Ich hab dein Script vom letzten Donnerstag übernommen und damit experimentiert. Dort war hinter -out und -sign immer erst die XML-Datei und zum Schluss der Schalter -passin angegeben. Auf die Idee, die Reihenfolge der Schalter mal zu ändern, bin ich auch nicht gekommen. Du hast nun den Schalter -passin direkt hinter -sign gesetzt und zum Schluss die zu signierende XML-Datei... und schon geht es.... kleine Ursache, große Wirkung... 1000 Dank, das du so hartnäckig warst... ihr seid echte Profis Beitrag kann erfolgreich geschlossen werden. Grüße Matthias
  8. Hallo Zusammen, ich hab mir das am Wochenende noch mal angeschaut. So wie ich das verstanden habe, wird der Schalter -passin genutzt, um ein Zertifikat mit Kennwort mittels openssl zu erstellen. Zusammen mit -dgst funktioniert das nicht. Ich hab auch keine Möglichkeit und kein Argument gefunden, in dem ich das Kennwort irgendwie automatisiert mitgeben kann. Wenn ich -dgst -sha512 -binary -out $outfile -sign $CertFile $_.FullName normal ausführe, werde ich nach dem Kennwort gefragt. Sobald ich aber irgendein weiteres Argument hinzufüge, in welcher Syntax auch immer, auch wenn es nur ein schnödes -x ist, kommt sofort die Meldung: dgst: Can only sign or verify one file. Wenn der Schnaps demnächst nach Eisen schmeckt, nicht wundern, ich hab die Flinte in den Korn geworfen... Trotzdem besten Dank Matthias
  9. Hmpf... auch mit der Variable hat es nicht geklappt.... :( Aber ich schau mir am Wochenende noch mal die Optionen von openssl an. Unter https://github.com scheint es auch eine Art Forum für openssl zu geben. Vielleicht finde ich da was... Euch schon mal ein schönes Wochenende Matthias
  10. Ich glaub ich gebe auf. Ich habe gelesen, das Microsoft nun endlich die Funktion Strg+C und V in die cmd.exe und Powershell eingebaut hat. Zumindest bei Windows 10 und Server 2016. Dann drück ich halt 1000 mal Strg+V und Enter, aber immerhin besser als 1000 mal das Kennwort einzugeben. Aber das Powershell-Video werde ich mir auf jeden Fall mal anschauen. Vielleicht werde ich ja noch warm damit :) Viele Grüße und Danke für die Hilfe Matthias Hallo Testperson, danke für den Hinweis, wieder was gelernt. Damit passt zwar nun die Signaturdatei, aber es ändert leider nichts an der Tatsache, das ich für jede XML-Datei das Kennwort eingeben muss :( Wie gesagt, unter Windows 10 kann ich das Kennwort zumindest mit Strg+V eingeben...
  11. Hab ich gleich mal getestet: Es kommt zwar keine Fehlermeldung mehr und die Signatur-Datei hat jetzt einen Inhalt, heißt aber nach wie vor Testdatei.sig anstatt Testdatei.xml.sig. Aber das ist nicht so tragisch. Es funktioniert halt nach wie vor nur ohne -passin pass:Kennwort und einer manuellen Eingabe des Kennwortes. Ich glaube fast, das openssl bzw. der Schalter -passin gar nicht dafür ausgelegt ist, um das Zertifikatskennwort automatisiert angeben zu können. Denn das ist das gleiche wie bei meiner for-Schleife in der Batchdatei...
  12. Guten Morgen, hier noch einmal der Code: $SourcePath = 'C:\Test\Signaturdateien\' $CertFile = 'C:\Test\Signaturdateien\Zertifikat.pem' Get-ChildItem -Path $SourcePath -Filter *.xml | ForEach-Object { $outfile = $_.BaseName + '.sig' Start-Process -FilePath c:\test\signaturdateien\openssl.exe -ArgumentList "dgst -sha512 -binary -out $outfile -sign $CertFile $_.FullName -passin pass:""Kennwort""" -wait -nonewwindow } Als Ausgabe kommt die oben genannte Meldung: dgst: Can only sign or verify on file. Wenn ich den Passus -passin pass:""Kennwort"" komplett herausnehme, werde ich nach einem Kennwort für das Zertifikat gefragt. Nach Eingabe des Kennwortes kommt allerdings die Meldung: Testdatei.xml.FullName: No such file or directory Es wird dann eine Testdatei.sig erstellt, die aber leer ist. Erst wenn ich den richtigen Dateinamen in das Script schreibe... Start-Process -FilePath c:\test\signaturdateien\openssl.exe -ArgumentList "dgst -sha512 -binary -out Testdatei.xml.sig -sign $CertFile Testdatei.xml" -wait -nonewwindow ... wird eine Testdatei.xml.sig mit Inhalt erstellt. Aber auch wieder erst nach Eingabe eines Kennwortes. Grüße Matthias
  13. Ich fürchte ich muss mir das wirklich irgendwann mal zur Gemüte führen. Wahrscheinlich mal an einem Wochenende. Denn selbst in der Zeit, in der ich gerade deinen Text gelesen hab, war der Vorstand bei mir, weil die Mails nicht schnell genug auf seinem Blackberry landen und ein anderer mit Papierstau im MFP 2 Etagen über mir. Ich kann manchmal froh sein, wenn ich mal 30 min konzentriert an einer Sache arbeiten kann. Aber ich will auch nicht jammern oder mich beklagen, sind alles liebe Kollegen ;) Aber zurück zum Script... Ich hab also den ganzen Pfad der OpenSSL.exe angegeben und auch die beiden Schalter angehangen. Nun sieht man auch was gemacht wird. Leider kommt wieder die altbekannte Meldung: dgst: Can only sign or verify one file. Ich denke das wird mit dem Schalter -passin zusammenhängen. Das Problem hatte ich schon in der Batchdatei. Dann wird es wohl kein generelles Problem mit Batch oder Powershell sein, sondern eher ein Problem mit openssl....
  14. Grundsätzlich hast du natürlich recht, das immer mehr mit Powershell gemacht wird. Leider, ich gestehe, ich bin eingefleischter Mausschubser und finde Powershell zum... übergeben, sorry. Ich finde da echt keinen Draht hin. Aber auch Grundlagen (selbst wenn ich sie hätte) verblassen, wenn man einmal im Jahr ein kleines Script braucht. Eine Batchdatei ist für mich halbwegs nachvollziehbar, Powershell ist für mich ein Sack voll Hieroglyphen und bin da völlig überfordert. Wenn du noch etwas Geduld mit mir hast würde ich gern noch einmal zu deinem Script zurückkommen. Nachdem die Hochkommata eingefügt sind kommt zumindest keine Fehlermeldung mehr. Es erscheint nur ganz kurz ein Konsolenfenster. Allerdings wird auch keine Signaturdatei erstellt. Ich hab mal versucht mit > Output.txt eine Ursache zu finden, aber die Datei bleibt leider leer. Wäre auch zu einfach gewesen ;) Gibt es da andere Möglichkeiten herauszufinden, wo es klemmt?
  15. Hallo BOfH_666, es knirschelt noch etwas. Mit dem SourcePath scheint etwas nicht zu stimmen und das Script will das Zertifikat öffnen und fragt nach einem entsprechenden Programm... siehe Screenshot
×
×
  • Create New...