Death man walking

Hallo zusammen, das hier ist genau genommen kein Artikel wie ein Problem gelöst werden kann. Vielmehr soll es darum gehen wie ein Problem erst gar nicht entsteht, konkret geht es um einen potenziellen Angriffsvektor der nur zu gerne übersehen und vergessen wird – der lokale Admin!

Installiert man einen Windows Server neu, dann muss im Verlauf des Setups das Admin Passwort vergeben werden … der sich immer in Eile befindliche Admin (Installateur) verwendet hier gerne mal etwas Einfaches wie admin, 1234, … und vergisst nachdem der Server in die Domäne integriert wurde den lokalen Admin zu ändern oder zu deaktivieren. Bei Windows 10, also mit dem Client verhält es sich nicht viel anders, hier muss ein Benutzer angelegt werden und fällt die Wahl auf admin/admin dann ist hier ebenfalls ein Angriffsvektor vorhanden.

Erfolgt dann eine Exposition des Servers per RDP ins Internet, steht der lokale Administrator mit seinem trivialen Passwort eine leichte Aufgabe für Hacker dar.

Darum an dieser Stelle der Rat, ein schwieriges Passwort zu verwenden und im Nachgang den lokalen Administrator zu deaktivieren. Sollte ein lokaler Administrator zwingend benötigt werden, dann lege ich immer einen weiteren Admin, der dann auch nicht Administrator sondern irgendwie anders heißt.

image

Das sieht dann wie oben aus.

Enjoy it, b!

TimeSync mit pool.ntp.org

Für meine auf Windows basierten AD Server verwende ich als Zeitquelle pool.ntp.org. Dort gibt es inzwischen eine Beschreibung wie den der Server zu konfigurieren ist:

# Neuere Windows Versionen

w32tm /config /syncfromflags:manual /manualpeerlist:"0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org 3.pool.ntp.org"

# Ältere Windows Version, ohne w32tm

net time /setsntp:"0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org 3.pool.ntp.org"

Natürlich gibt es auch für Linux entsprechende Hinweise wie die Konfiguration zu erfolgen hat.

Enjoy it, b!

IPv6 Configuration OpenSuse Leap

Verwendet man eine FRITZ!Box in seinem LAN dann kann einem die schwer kontrollierbare Vergabe von IPv6-Adressen durchaus Probleme machen. Das Deaktivieren von IPv6 auf allen Windows Systemen halte ich hier für keine saubere Lösung, vielmehr habe ich mich dazu entschlossen die IPv6-Adressen selbst zu vergeben. Darüber will ich in diesem Blog aber gar nicht schreiben, sondern wie einem openSUSE Server eine funktionierende IPv6 Konfiguration eingestellt werden kann.

Eckdaten

  • IPv6 Adresse für den OpenSuse Server: fd8e:5644:167b:100a::18
  • IPv6 Adresse für den Router / Gateway: fd8e:5644:167b:100a::1
  • Interface für die Konfiguration: eth0

Konfiguration

Im Gegensatz zu Windows, ist es bei Linux möglich IP-Adressen nur zur Laufzeit zu konfigurieren oder aber statisch, damit die Konfiguration einen Neustart überlebt.

Die Konfiguration zur Laufzeit ist dabei recht einfach, benötigt aber die Rechte des SU.

# ip -6 address add fd8e:5644:167b:100a::18/64 dev eth0

# ip -6 route add default via fd8e:5644:167b:100a::1 dev eth0

Statisch erfolgt die Konfiguration wie folgt:

# cd /etc/sysconfig/network

# vi ifcfg-eth0

# hinzufügen der folgenden Zeilen ans Ende der Datei (ifcfg-eth0)
LABEL_0='0'
IPADDR_0='fd8e:5644:167b:100a::18'
PREFIXLEN_0='64'

# echo 'default fd8e:5644:167b:100a::1 - -' >> /etc/sysconfig/network/routes

Damit die Konfiguration aktiv wird, entweder den Server neu starten oder den folgenden Befehl ausführen.

# service network restart

Enjoy it, b!

WSE und Shared Folders

Historisch gesehen, hat man Laufwerke aus dem Netzwerk schon immer verbunden. Das war nicht erst mit Windows schon, auch unter Novell Netware und OS/2 gab es Laufwerksmappings.

net use * \\server\share 

Was vielleicht für den Anwender aus heutiger Sicht immer noch sehr praktisch sein mag, stellt die Administratoren (zumindest seit wir mit der Verschlüsselungsthematik durch Cryptlocker kämpfen müssen) vor ungeahnte Probleme.

1. Kann so ein Virus problemlos der Reihe nach alle Laufwerke verschlüsseln, er findet einfach durch deren Zuordnung

2. Ist die Anzahl der Laufwerke durch die freien Buchstaben im Alphabet begrenzt.

Zusätzlich binden sich immer mehr Cloud-Laufwerke in den Windows Explorer ein (OneDrive, Amazon, …) und lassen sich nicht mehr so ohne weiteres mit net use im klassischen Sinne verbinden. Mein Gefühl sagt mir, Laufwerke sind out und das folgende Bild zeigt die neue Welt.

image

Die Freigaben des Windows Server Essentials tauchen als “Shared Folders” genauso im Explorer auf wie das oder die OneDrives. Nun lässt sich mit den Share Folders des WSE ausgezeichnet im Explorer arbeiten, möchte ich aber an der Eingabeaufforderung zum Beispiel eine Datei aus meinem OneDrive in meine Eigenen Dateien kopieren, wird die Sache doch recht gruselig, Anführungszeichen sind wegen den Leerzeichen in folder redirection notwendig und die automatische Erweiterung der Pfade funktioniert auch erst ab genau dieser Ebene.

xcopy \Users\hans\OneDrive\_Config\keepass\MyPasswords-2018-09-25-01.kdbx "\\sbe\folder redirection\hans\_config\keepass" 

Um nicht wieder zu den über net use zugewiesenen Laufwerken zurück kehren zu müssen, habe ich auf meinem WSE eine kurze Freigabe über die folder redirection gelegt:

net share fr$="D:\ServerFolders\Folder Redirection" /grant:users,change 

und für Server in deutscher Sprache

net share fr$="D:\ServerFolders\Folder Redirection" /grant: benutzer,change 

Damit kann ich nun wieder Dateien einfacher kopieren:

xcopy \Users\hans\OneDrive\_Config\keepass\MyPasswords-2018-09-25-01.kdbx \\sbe\fr$\hans\_config\keepass 

Vielleicht hilft dieser kleine Workaround dem einen oder anderen von Euch weiter.

Enjoy it, b!

Windows (Vista) ++: Start des “elevated Command Prompt” in einem definiertem Verzeichnis

Startet man unter Windows Vista oder in einer der neueren Versionen den “Command Prompt” (auch Experten GUI genannt 😉 ) mit erhöhten Rechten (elevated rights) so landet man im Verzeichnis %windir%\system32.

image

Da dieses Verzeichnis das Systemverzeichnis des Betriebssystems darstellt und hier ein unachtsam abgesetzter Befehl fatale Folgen haben kann, ist es unter Umständen wünschenswert in einem anderen Verzeichnis, z.B. c:\temp per Default zu arbeiten. Dazu muss lediglich die Verknüpfung welche den Command Prompt startet, modifiziert werden.

Das kann durch eine Änderung des Target in den Eigenschaften der Verknüpfung erreicht werden. Der folgende Aufruf definiert für den Command Prompt egal, ob elevated oder nicht, dass Verzeichnis c:\temp als Arbeitsverzeichnis:

%SystemRoot%\system32\cmd.exe /k cd /d c:\temp

image

Der Wert in Start in muss nicht zwingend geändert werden, es reicht wenn der Target wie oben geschrieben, gesetzt wird.

Nach der Änderung sieht das dann so aus:

image

Wer dann meint er muss im Systemverzeichnis irgendwelche Dummheiten machen, kann immer noch dahin wechseln 🙂

Update 21.03.2019:
Da der Blog 2009 noch auf der Microsoft Blogging Plattform Live erschienen ist und für mich seine Aktualität behalten hat, habe ich nochmals die verloren gegangenen Screenshots korrigiert und diesen Beitrag auf Vordermann gebracht.

Dazu noch eine kleine Erinnerung, obwohl es viele von Euch immer noch lieben, Windows 7 geht langsam aber sich seinem Ende zu. Hier lohnt sich ein Blick in die Support-Lifecycle Datenbank bei Microsoft:

https://support.microsoft.com/de-de/lifecycle/search

Cheers Enjoy it, b!

Windows Server 2012 R2 “Signing out”

Immer mal wieder habe ich bei einem Windows Server 2012 R2 das Problem, dass dieser Ewigkeiten mit einer Abmeldung beschäftigt ist und dieser Prozess zu hängen scheint.

image

Ein ähnliches Problem wird in diesem Blog beschrieben und auch dafür eine Lösung geboten, ich habe mir aber wie folgt beholfen.

  1. Öffnen einer Session mittels PsExec auf den betroffenen Server
  2. Abfrage der Sessions mit query session
  3. Logoff der Session über die ID

Die im Blog empfohlenen Fixes waren oder sind ja auf dem Windows Server noch nicht installiert.

# Aufbau einer Session mit PsExec
psexec \\server cmd.exe

# Abfrage der aktiven Sessions (hier die ID heraussuchen)
query session

# Abmelden der Session, logoff ID
logoff 3

Das sieht dann wie folgt aus.

image

Enjoy it, b!

WTF ist mein Amazon MP3 Download

Bei Amazon bekommt man zu einer Musik CD auch gleich die MP3s als Download dazu, diese Option nutze ich sehr gerne. Genau genommen sammle ich die CD nur aus nostalgischen Gründen, Musik liegt als MP3 auf einer Reihe von Endgeräten vor. Das ist aber nicht der Grund für diesen Blog, sondern die Suche nach meinem MP3 Download!

Das Problem

Mit Amazon Music, bietet Amazon eine App welche die bei Amazon erworbenen MP3s nicht nur Verwalten, sondern auch herunterladen kann.

image

Das Herunterladen ist für mich wichtig, da ich meine MP3s gerne im Auto oder auch offline auf dem Smartphone höre. Der Download selbst gestaltet sich unproblematisch, hat man einmal das Album gefunden lassen sich einzelne Titel oder das ganze Album problemlos in den folgenden Ordner herunterladen.

%USERPROFILE%\Music\Amazon MP3

Was für die Mäuseschubser unter uns, dieser Ordner ist.

image

Da der Ordner Music (oder Musik auf einem Windows mit deutscher Sprache) zum Benutzer-Profil gehört, kann dieser über eine Gruppenrichtlinie oder manuell umgeleitet werden, seine Position im Dateisystem damit verändert werden. Früher hatte ich alle Ordner auf den Server umgeleitet, habe das aber aufgrund von vielen Programmen (Adobe) welche mit umgeleiteten Applikationsdaten (AppData) Probleme haben auf die folgenden Ordner reduziert.

  • Videos
  • Music
  • Documents
  • Pictures

Meine MP3s von Amazon sollten also im Ordner Music landen, welcher hier auf den folgenden Server zeigt, dort waren sie aber nicht.

\\scotia\Folder Redirection\%USERNAME%\music

Lokal konnte ich einige MP3s finden, nur nicht das neu erworbene Album.

Wo zur Hölle sind also die MP3s? Zuerst hatte ich Amazon im Verdacht, vielleicht findet der Download nur noch in einen geschützten Container statt um die Dateien nicht mehr beliebig auf seinen Geräten abspielen zu können. So etwas würde aber Amazon bestimmt nicht tun, oder man bekommt solche Maßnahmen auf die eine oder andere Art mit.

Die Analyse

Damit blieb mir nur die Möglichkeit die Sache eingehend zu analysieren und dazu griff ich auf den Process Monitor von Sysinternals zurück. Der Download einer MP3 Datei war ausreichend, um dem Problem auf die Spur zu kommen.

Dazu waren die folgenden Schritte notwendig.

  1. Start des Process Monitors als Administrator und Rücksetzen aller Filter
  2. Start von Amazon Music unter den angemeldeten Benutzer und Auswahl eines Liedes zum Download
  3. Auswahl der Amazon Music App mit der Zielscheibe (Fadenkreuz) des Process Monitors

Ups, der Download erfolgt schon aber in einem Pfad, bzw. auf einen Server den es schon lange nicht mehr gibt.

image

Damit hat wohl auch Amazon Music seine Probleme mit der Umleitung von Ordnern, vor allem wenn irgendwann noch eine Migration dieser erfolgt ist.

Durch das Ergebnis neugierig geworden, wollte ich mir den Inhalt des CSC Ordners genauer anschauen, dieser wird aber von Windows besonders geschützt und verweigert per Default auch einem Admin den Zugriff. Lediglich der SYSTEM Account hat hier die notwendigen Berechtigungen. Eine Eingabeaufforderung für eben diesen, kann aber recht einfach mit PsExec, ebenfalls aus der Sysinternals Suite gestartet werden.

c:\Windows> "\Program Files (x86)\Windows Sysinternals Tools\psexec.exe" -s cmd.exe

image

Damit ist ein Zugang zum CSC Ordner möglich, in dem sich zwei Namespaces befinden. Neben dem aktuellen auch der im Process Monitor angezeigte alte.

image

Der sich darin befindliche Ordner Music zeigte auch das Datum und die Uhrzeit des ersten Downloads …

Mittels eines weiteren Tools aus der Sysinternals Suite konnte ich die Verwendung des Ordners durch die Amazon Music App weiter analysieren. Handle zeigt, dass Amazon Music einige Ordner und Dateien verwendet.

C:\Windows\CSC\v2.0.6\namespace> "\Program Files (x86)\Windows Sysinternals Tools\handle.exe" -nobanner -accepteula cardhu

image

Der Aufruf von Handle erfolgte innerhalb der über PsExec gestarteten Eingabeaufforderung.

Meine Absicht war nun, den Ordner dort einfach zu löschen. Durch das Schließen von Amazon Music waren nur noch fünf Handles offen, aber ein Löschen des Verzeichnisses eben wegen dieser, immer noch nicht möglich.

image

Während dem Windows Explorer noch mit einer Terminierung beizukommen wäre, lässt sich der System Prozess von Windows nicht stoppen.

Die Amazon Music App zeigte sich zudem unbeeindruckt und wählte nach einem Neustart eben genau dieses Verzeichnis zum wiederholten Download.

Die Lösung

Die Lösung des Problems war nun das folgende Vorgehen.

  1. Löschen des CSC\v2.0.6\namespace Ordners über ein Windows 10 Installations Medium (USB Stick oder DVD)
  2. Deinstallation der Amazon App, löschen aller Fragmente und Neuinstallation über den Windows Store.

Nach dem Start des PCs mit einem Windows 10 ISO, kann über die Kombination SHIFT+F10 eine Eingabeaufforderung geöffnet werden Smile mit deren Hilfe sich das Verzeichnis ohne Probleme löschen läßt.

Untitled

C:\Windows\CSC\v2.0.6\namespace> rd <Youf-F...-Namespace> /s /q

Nach der Deinstallation von Amazon Music, habe ich an den folgenden Stellen im Betriebssystem nach Fragmenten gesucht.

Windows Registry:

image

Im Dateisystem:

C:\Temp> dir %USERPROFILE%\Appdata\Roaming

C:\Temp> dir %USERPROFILE%\AppdataLocal

C:\Temp> dir %ProgramFiles%

C:\Temp> dir %ProgramFiles(x86)%

C:\Temp> dir %ProgramData%

Amazon Music muss nicht zwingend an allen Stellen Informationen ablegen. Da auf dem Rechner noch Reste einer alten Installation vorhanden, habe ich alle Einträge gelöscht und danach aus dem WIndows Store Amazon Music erneut installiert.

Die neu installierte App war dann zwar der Meinung, dass C.\Windows\System32\Amazon Music der richtige Download Ordner wäre, was man aber in den Preferences/Einstellungen korrigieren kann.

image

Damit ist sogar die Speicherung in einem um geleiten Ordner möglich.

image

So, alles gut.

Enjoy it, b!