Powershell – Die zugrunde liegende Verbindung wurde geschlossen: Unerwarteter Fehler beim Senden…

Beim Abfragen von Webservices über Powershell kommt es immer wieder mal zu folgender Fehlermeldung:

PS N:\> Invoke-Webrequest -Uri https://tls-v1-2.badssl.com:1012/
Invoke-Webrequest : Die zugrunde liegende Verbindung wurde geschlossen: Unerwarteter Fehler beim Senden..
In Zeile:1 Zeichen:1
+ Invoke-Webrequest -Uri https://tls-v1-2.badssl.com:1012/
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc
eption
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

So wirklich schlau wird man aus der Meldung „Die zugrunde liegende Verbindung wurde geschlossen: Unerwarteter Fehler beim Senden..“ jetzt auf den ersten Blick nicht. (In Englisch: The underlying connection was closed: An unexpected error occurred on a send..)
Der Fehler tritt bei Problemen mit der TLS Verschlüsselung auf. Speziell wenn der Client (also die Powershell in diesem Fall) mit einer nicht unterstützten TLS Version beim Server ankommt.
Bei Windows Server 2016, 2012R2 oder älteren Windows Client Betriebssystemen ist die Standard Verschlüsselung TLS 1.1/1.0 welche von vielen Betreibern von Websites mittlerweile wegen der Sicherheit deaktiviert wurde.
Bein Windows Server 2019 und Windows 10 (1909) hatte ich bei Tests mit dem Powershell Invoke-Webrequest standardmäßig TLS 1.2 vorgefunden.

Wie kann man per Powershell die TLS Verschlüsselung ändern?

Über folgende Befehle vor dem Invoke-Webrequest bzw. Invoke-RestMethod kann die TLS Version gesteuert werden.

TLS 1.2

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

TLS 1.1

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls11

TLS 1 ( 1.0 )

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls

Beispiel

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
$a = Invoke-Webrequest -Uri https://tls-v1-2.badssl.com:1012/

Dies kann man über folgende URL’s auch direkt testen (Quelle: Stackexchange.com):

This subdomain and port only supports TLSv1.2

https://tls-v1-2.badssl.com:1012/

This subdomain and port only supports TLSv1.1

https://tls-v1-1.badssl.com:1011/

This subdomain and port only supports TLSv1.0

https://tls-v1-0.badssl.com:1010/

Nützliche Links

IISCrypto

Mit dem kostenfreien Tool IISCrypto lässt sich speziell der IIS aber auch die Grundlegenden Systemstandards und TLS Protokolle definieren.

Cipherlist

Unter Cipherlist bekommt man jeweils immer die aktuellen SSL Einstellungen für viele Webserver, wie apache2, nginx, oder auch andere Dienste.

Ähnliche Fehlermeldungen

Auch bei der PowerShell Gallery muss man mittlerweile TLS 1.2 einsetzen. Ansonsten bekommt ihr folgende Fehlermeldung:

Install-Module -Name SqlServer
WARNUNG: Unable to resolve package source 'https://www.powershellgallery.com/api/v2'.
PackageManagement\Install-Package : Für die angegebenen Suchkriterien und den Paketnamen "SqlServer" wurde keine
Übereinstimmung gefunden. Verwenden Sie Get-PSRepository, um alle verfügbaren, registrierten Paketquellen anzuzeigen.
In C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1:1772 Zeichen:21
+ ... $null = PackageManagement\Install-Package @PSBoundParameters
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (Microsoft.Power....InstallPackage:InstallPackage) [Install-Package], Ex
ception
+ FullyQualifiedErrorId : NoMatchFoundForCriteria,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackage

Philips Fernseher – Ins Service Menü gelangen (55PUS6401/12)

Wer das Service Menü der Philips sucht, kann folgende Tastenkombinationen über die Fernbedienung ausprobieren:

0 + 6 + 2 + 5 + 9 + 6 + Menu/Info/Status
0 + 6 + 2 + 5 + 9 + 7 + Menu/Info/Status
0 + 6 + 1 + 5 + 9 + 6 + Menu
0 + 6 + 1 + 5 + 9 + 7 + Menu
1 + 6 + 2 + 5 + 9 + 6 + Menu/Status
1 + 2 + 3 + 6 + 5 + 4

Die Menüeinträge können mit CURSOR HOCH/RUNTER angesprochen werden. Die Einträge selbst mit CURSOR LINKS/Rechts verändert werden.
Manche Einstellungen können aktiviert und deaktiviert werden, dazu die OK Taste drücken.
Achtung: Nur anfassen, wenn man weiß was man macht! Falsche Einstellungen können das Gerät beschädigen!

Linux – Recursiv Dateien in Unterordnern entpacken und löschen

Entpacken von allen Archiven in ihren eigenen Unterordnern:

find /pfad/Ordner -name '*.rar' -execdir unrar e -o- {} \;

Aufklärung der Parameter für unrar:
e = extract (alternativ x = behält die Verzeichnisstruktur)
-o- = Kein überschreiben von Dateien, wenn diese schon existieren.
Anschließend löschen wir alle Dateien die dem Winrar Dateimuster (.rar; .r01; usw…) entsprechen:

find . -type f -name "*.r??" -exec rm {} \;

Dell Inspiron 3480 – Under the hood

Da die Spezifikationen des Dell Inspiron 3480 nicht 100%ig wiederspiegeln, welche Anschlüsse auf dem Mainboard noch frei sind, habe ich mir erlaubt ein paar Screenshots des aufgeschraubten Gerätes zu zeigen.

Wie man sieht gibt es
1 x M.2 Anschluss
1 x 2,5 HDD Sata Anschluss
sowie
2 x SODIMM Bänke für DDR 4 Speicher

den Akku sowie die Mainboard Batterie lassen sich noch eigenständig tauschen und sind zum Glück nicht verklebt.

Schrauben für den Einbau einer 2,5 Zoll Festplatte liegen sogar am Klebeband befestigt bei.

FATA: Module wireguard not found – Kernel modul fixen

Ich spare mir die Erläuterung was wireguard ist und macht, das gibt es denke ich zur genüge.

Was man wissen sollte ist: Wireguard ist nicht direkt im Linux Kernel enthalten, und basiert auf einer Erweiterung (Modul) dazu.
Das bedeutet, wenn man Wireguard installiert und anschließend Updates des Kernel macht, kann es sein das Wireguard nicht mehr funktioniert. Dann muss nämlich das Kernel-Modul neu (für die neue Kernel Version) kompiliert werden.

Beim Installieren unter Debian 9 kam ich auf folgende Meldung:

Vorbereitung zum Entpacken von .../12-wireguard_0.0.20190905-1_all.deb ...
Entpacken von wireguard (0.0.20190905-1) ...
make (4.1-9.1) wird eingerichtet ...
sudo (1.8.19p1-2.1) wird eingerichtet ...
linux-headers-4.9.0-11-common (4.9.189-3) wird eingerichtet ...
wireguard-tools (0.0.20190905-1) wird eingerichtet ...
linux-compiler-gcc-6-x86 (4.9.189-3) wird eingerichtet ...
dkms (2.3-2) wird eingerichtet ...
linux-kbuild-4.9 (4.9.189-3) wird eingerichtet ...
Trigger für libc-bin (2.24-11+deb9u4) werden verarbeitet ...
libfakeroot:amd64 (1.21-3.1) wird eingerichtet ...
Trigger für systemd (232-25+deb9u11) werden verarbeitet ...
wireguard-dkms (0.0.20190905-1) wird eingerichtet ...
Loading new wireguard-0.0.20190905 DKMS files...
Building for 4.9.0-4-amd64
Module build for kernel 4.9.0-4-amd64 was skipped since the
kernel headers for this kernel does not seem to be installed.
linux-headers-4.9.0-11-amd64 (4.9.189-3) wird eingerichtet ...
fakeroot (1.21-3.1) wird eingerichtet ...
update-alternatives: /usr/bin/fakeroot-sysv wird verwendet, um /usr/bin/fakeroot (fakeroot) im automatischen Modus bereitzustellen
wireguard (0.0.20190905-1) wird eingerichtet ...
Module build for kernel 4.9.0-4-amd64 was skipped since the
kernel headers for this kernel does not seem to be installed.

  Ein Reconfigure des Modules brachte auch keine Besserung:

# dpkg-reconfigure wireguard-dkms
-------- Uninstall Beginning --------
Module: wireguard
Version: 0.0.20190905
Kernel: 4.9.0-11-amd64 (x86_64)
-------------------------------------
Status: Before uninstall, this module version was ACTIVE on this kernel.
wireguard.ko:
- Uninstallation
- Deleting from: /lib/modules/4.9.0-11-amd64/updates/dkms/
- Original module
- No original module was found for this module on this kernel.
- Use the dkms install command to reinstall any previous module version.
depmod.....
DKMS: uninstall completed.
------------------------------
Deleting module version: 0.0.20190905
completely from the DKMS tree.
------------------------------
Done.
Loading new wireguard-0.0.20190905 DKMS files...
Building for 4.9.0-4-amd64
Module build for kernel 4.9.0-4-amd64 was skipped since the
kernel headers for this kernel does not seem to be installed.

  Testen ob das Wireguard Module geladen ist:

modprobe wireguard
modprobe: FATAL: Module wireguard not found in directory /lib/modules/4.9.0-4-amd64

 Ursache: Die notwendigen Pakete zum Kompilieren waren nicht vorhanden.

Lösung: Fehlenden Pakete installieren und ein Reconfigure des wireguard-modules machen.

apt-get install libmnl-dev libelf-dev linux-headers-$(uname -r) build-essential pkg-config
# dpkg-reconfigure wireguard-dkms
------------------------------
Deleting module version: 0.0.20190905
completely from the DKMS tree.
------------------------------
Done.
Loading new wireguard-0.0.20190905 DKMS files...
Building for 4.9.0-11-amd64
Building initial module for 4.9.0-11-amd64

 

Freenas 11 – Fix "Boot failed efi misc device"

In einer frisch angelegten Ubuntu 16.04.4 VM unter der bhyve Virtualisierungsplattform in Freenas hatte ich das Problem, dass die VM nicht korrekt unter UEFI bootete.
Bei jedem Neustart hing die Maschine im EFI und zeigte: „boot failed efi misc device“ an. Wie sich im Freenas Forum herausstellte, ist man nicht der einzige mit dem Problem.
Im Efi selbst kann man dann zwar via „exit“ in in den „Boot Maintenance Manager“ gelangen und unter „Boot File“ auch die grubx64.efi zum Starten auswählen. Allerdings ist das Prozedere beim nächsten Neustart wieder notwendig.
Was ist die Ursache?
Warum auch immer wird der Bootloader unter folgendem Pfad vermutet:

 root@ubuntu:/boot/efi# ls /boot/efi/EFI/BOOT/bootx64.efi
/boot/efi/EFI/BOOT/bootx64.efi

Dies war bei mir nicht der Fall, also musste ich den BOOT Ordner anlegen und kopierte die grubx64.efi als bootx64.efi in das Verzeichnis, sodass es wie folgt aussieht:

mkdir /boot/efi/EFI/BOOT
cp /boot/efi/ubuntu/grubx64.efi /boot/efi/EFI/BOOT/bootx64.efi
root@ubuntu:/boot/efi# tree -L 3 .
.
└── EFI
├── BOOT
│   └── bootx64.efi
└── ubuntu
├── grub.cfg
├── grubx64.efi
├── mmx64.efi
└── shimx64.efi
3 directories, 5 files

Anschließend die VM neustarten um zu prüfen ob alles korrekt funktioniert hat.

HAProxy vor Squid Proxy – Client IP-Adressen weiterleiten

Verwendet man einen Loadbalancer wie z.B. HAProxy um Webzugriffe von Clients auf mehrere Squid Proxy Server zu verteilen, sieht es im access.log des Squid Proxy so aus, als kämen die Zugriffe alle vom HAProxy nicht vom eigentlichen Client. Da das HTTP Forwarding des HAProxy auf Applikationsebene basiert, ist dieses Verhalten korrekt. Wenn man TCP Offloading machen würde, wäre dies wahrscheinlich nicht der Fall.

Um beim HTTP Forwarding dennoch die originale Client-IP im Squid access.log zu sehen, kann man diese über den HTTP Header X-Forwarded-For (Beschreibung) weiterleiten.

In Squid kommen die Requests alle von der IP-Adresse des HAProxy:

1514450659.711  40186 10.0.0.5 TCP_MISS/200 31540 CONNECT images.outbrain.com:443 - HIER_DIRECT/2.19.240.34 -
1514450660.977  40078 10.0.0.5 TCP_MISS/200 3753 CONNECT www.summerhamster.com:443 - HIER_DIRECT/52.27.8.169 -

In HAProxy müssen die folgenden beiden Optionen gesetzt werden. Diese setzen den Header „X-Forwarded-For“ auf die Client IP-Adresse. Dadurch wird die eigentliche Client IP im Header mitgegeben:

option http-server-close
option forwardfor

Der Squid Proxy registriert den veränderten Header, verwirft ihn aber aus Sicherheitsgründen standardmäßig – sofern nicht anderweitig konfiguriert. Also muss in der Konfiguration des Squid der QuellIP des HAProxy vertraut werden. Dies wird dementsprechend über eine acl in der squid.conf angepasst:

acl haproxy src 10.0.0.5
follow_x_forwarded_for allow haproxy

Abschließend den Squid neustarten und den Webzugriff über ein Client testen. Wie man nun im access.log sieht, ist die Client-IP jetzt korrekt weitergeleitet.

1514451557.721      5 10.0.0.10 TCP_MISS/200 910 POST http://ocsp.digicert.com/ - HIER_DIRECT/93.184.220.29 application/ocsp-response
1514451557.749      5 10.0.0.10 TCP_MISS/200 2194 POST http://ocsp2.globalsign.com/gsalphasha2g2 - HIER_DIRECT/104.31.74.124 application/ocsp-response

Exchange 2016 – Enable & Troubleshoot Certificate Based Authentication for OWA/Active Sync

Um die zertifikatsbasierte Authentifizierung des Exchange 2016 zu aktivieren empfehle ich, sich an folgenden Technet-Artikel zu halten. Dieser beschreibt die Konfiguration schritt für schritt.
Der anschließende Test war jedoch wenig erfolgreich und brachte auf den Client Geräten immer den Fehler „Anmeldung fehlgeschlagen“. Die Analyse des IIS Logfiles bestätigte in dem Fall die Fehlermeldung:

2018-01-17 14:14:41 W3SVC1 MSEXCHSRV 10.0.1.212 OPTIONS /Microsoft-Server-ActiveSync/default.eas Cmd=OPTIONS&User=domain%5CUser.Name&DeviceId=SEC15BF1D9F90A8E&DeviceType=SamsungDevice 443 - 10.0.0.213 HTTP/1.1 Android-SAMSUNG-SM-G955F/101.700 - - oma.fqdn.net 403 16 2148204809 184 375 452
2018-02-22 08:24:54 W3SVC3 EXCHANGESRV 10.0.1.212 GET / - 9943 - 10.0.0.5 HTTP/1.1 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/63.0.3239.132+Safari/537.36 - - exchangesrv.fqdn.info:9943 403 16 2148204809 1423 434 4230

Da der Microsoft Exchange Health Manager (+ Recovery) durchgängig Testaufrufe machen, wird das IIS Logfile schnell unübersichtlich gefüllt. Daher hatte ich einfach eine neue Site im IIS Manager erstellt und dort unter einem anderem Port Binding die Authentifizierung via Client Zertifikate getestet. (Unterer Logeintrag) Man kann aber auch den Health Manager Dienst temporär deaktivieren, dass funktioniert auch.
Zurück zur Fehlermeldung, welche im Detail wie folgt aussieht:

403 16 2148204809
  • 403 = HTTP Statuscode (Authentication Failed)
  • 16 = Subfehler (Client certificate is untrusted or invalid.)
  • 2148204809 = Detaillierter Fehlercode (0x800b0109 CERT_E_UNTRUSTEDROOT)

Sucht man nach der Fehlermeldung findet man folgenden Technet-Artikel, der eigentlich auf den IIS 8 bezogen ist. Windows Server verwendet IIS 10 – aber der Artikel trifft auch darauf zu.
Hintergrund: Seit Windows Server 2012 wurden strengere Überprüfungen für die zertifikatsbasierte Authentifizierung eingeführt. Einer dieser Checks prüft ob sich im Zertifikatsspeicher (Trusted Root Certification Authorities) auch wirklich nur sogenannte Root-Zertifikate befinden. Ein Root Zertifikat muss logischerweise immer selbst-signiert sein. Wenn sich dort ein Zertifikat befindet, was von einer anderen Zertifikatstelle ausgestellt wurde, ist dies eigentlich ein „Zwischenzertifikat / Intermediate“ und gehört an einen anderen Zertifikatsspeicherort.
In meinem Fall befand sich das „StartCom Class 3 OV Server CA“ in den Root-CA’s welches den Fehler produzierte. Um den Fehler zu beheben, müssen alle nicht selbst-signierten Zertifikate aus dem Root-CA entfernt bzw. zu den Zwischenzerifikaten verschoben werden.
Um bei der Vielzahl von Zertifikaten nicht alle händisch zu überprüfen kann man dies per Powershell identifizieren:

Get-Childitem cert:\LocalMachine\root -Recurse |
    Where-Object {$_.Issuer -ne $_.Subject}

Um die Zertifikate anschließend in den Speicher für „Intermediate Certification Authorities“ zu verschieben kann man folgenden Befehl nutzen:

Get-Childitem cert:\LocalMachine\root -Recurse |
    Where-Object {$_.Issuer -ne $_.Subject} |
    Move-Item -Destination Cert:\LocalMachine\CA

Anschließend den kompletten Server neustarten. Eventuell reicht auch nur ein Neustart des IIS (W3SVC). Hatte in meinem Fall jedoch nicht ausgereicht.

Winbuilder (Win10PE) hinter Proxy benutzen

Wer sich selbst ein Windows PE erstellen will, kommt um den WindowsBuilder nicht herum. Ein Tool aus der Sammlung, nämlich GetWaikTools (GWT.exe) lädt die Windows Imaging Features (ADK, Dism etc.) herunter und benötigt daher Internetzugriff. Wer hinter einem Proxy sitzt, bekommt hier eine Fehlermeldung und muss den Proxy von Hand konfigurieren.
Das Tool verwendet Curl als Downloader, für den über die Umgebungsvariablen ein Proxy eingerichtet werden kann:

C:\>netsh winhttp set proxy http://1.2.3.4:3128
Aktuelle WinHTTP-Proxyeinstellungen:
    Proxyserver     :  http://1.2.3.4:3128
    Umgehungsliste  :  (keine)

Anschließend funktioniert die Verbindung über den Proxyserver 😉

Windows 10 – Standarddrucker verwalten

Ihr wundert euch warum euer Standard Drucker immer wechselt? Ein neues „Feature“ in Windows 10 setzt den aktuellen Standarddrucker immer auf den zuletzt benutzten Drucker.
Hierbei wird auch berücksichtigt, an welchem Standort sich das Gerät im Moment befindet. Sprich zuhause wird der Heimdrucker automatisch als Standard ausgewählt und im Büro ein anderer.
Das kann ganz praktisch sein, stört aber vielleicht auch. Daher beschreibe ich hier kurz wie ihr die Funktion „Windows verwaltet Standarddrucker“ entweder per Hand oder via Gruppenrichtlinie / Registry deaktivieren könnt.

Von Hand

  1. Öffnet die Einstellungen von Windows 10 (z.B. Windows Taste + i)
  2. Navigiere zu Geräte und anschließend Drucker & Scanner
  3. Entferne den Haken bei „Windows verwaltet Standarddrucker“

Per Registry

  1. Navigiere zu folgendem Pfad:
    HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows
  2. Ändere den Wert „LegacyDefaultPrinterMode“ (DWORD) auf 1 ab.

 

Per Gruppenrichtlinie

Per GPO findet ihr die Option „Turn off Windows default printer management“ unter:

User Configuration\Administrative Templates\Control Panel\Printers\