blub

du kannst dir ja mal ansehen, welche Services überhaupt das Recht/ Privilege haben, die Zeit zu verändern

get-service | foreach {sc.exe qprivs $_.name | out-string | select-string 'systemtime'}

#evtl. auf deutschen Systemen 'systemtime' durch 'zeit' ersetzen. Ich kann es grad nicht ausprobieren.

vielleicht ist auf den betroffenen Rechnern ein ungewöhnlicher Kandidat dabei. Diesen Kandidaten genauer ansehen und evtl. temporär disablen. Nur als Idee!

blub

schon klar!
Ich will nur  Aussagen (nicht von dir!) wie "installier dir mal eben eine eigene CA oder kauf dir ein kommerzielles Cert, dann sind deine Probleme weg" nicht stehen lassen. Die technischen Probleme werden genau die gleichen sein, wie bei selfsigned Certs.

Klugsc***Mode = 1

https://tools.ietf.org/html/rfc5280#section-4.2.1.13
"CRL Distribution Points" sollte(!) eine unkritische Extension sein. Also sollte(!) Exchange nach diesem RFC auch mit Zertifikaten ohne CDPs problemlos zurecht kommen.

Ja, richtige CAs können offensichtlich zusätzliche Extensions in ihre templates einbauen, die einfache selfsigned Certifikate nicht haben.

blub

Exchange ist so gar nicht mein Thema, aber etwas die Zertifikate

Kann ich das jetzt gültige Zertifikat nachträglich durch meine Zertifizierungsstelle "genehmigen" oder muss ich ein komplett neues erstellen

- Nachträglich ein Zertifikat ändern geht nicht! Sonst passt die Signatur des Zertifikats nicht mehr.

- Technisch betrachtet sind selbst erstellte Zertifikate, egal ob selfsigned oder per CA erstellt, und gekaufte Zertifikate genau gleich. Wenn es du mit einem selfsigned Zertifikat Fehler bekommst, wird es mit gekauften einem Zertifikat auch nicht  laufen. Es geht nur darum, ob jemand von außerhalb diesem Zertifikat vertrauen soll.

- Vor dem Löschen deines alten Zertifikates exportiere dieses entweder oder verschieb es erstmal in einen anderen Container (smartcard roots). Dann hast du es noch zum Vergleichen.

- was ein Zertifikat "kann", steht in der "key usage" in den Zertifikatseigenschaften. Da sollte "digital signature" drinnen stehen, dann kannst du es für TLS verwenden. Zertifikate einer MicrosoftCA basierend auf dem Computer-template haben diese usage. Bei selfsigned-certificates musst du mal nachsehen, aber normalerweise können die Alles!

BTW: ob bzw. welche TLS-Version dein Rechner kann, hängt von den erlaubten Ciphern ab. TLS1.0/ TLS1.1 sollte man -zumindest im Business Umfeld- langsam abdrehen und Richtung TLS 1.2 gehen

blub

Ich hab schon öfters mit Software zu tun gehabt, die Adminrechte vorausgesetzt hat. Zu 99,9% hat bisher ausgereicht, auf ein Verzeichnis oder auf eine Datei Schreibrechte zu setzen. Bin ich deshalb ein Bastler?

 

Und wenn er die SW länger testen muss, ist es immer noch besser an ein paar Stellen die Rechte 'anzupassen' als die unbedarften User mit Adminrechten auszustatten.

und was macht der Bäcker nach 3 Monaten, wenn plötzlich mitten im Betrieb irgendwas nicht mehr läuft (autom. Updates, Quartalsabrechnung, etc), weil es doch noch eine seltener benutzte 2.-te Datei oder Verzeichnis gibt, der die Rechte fehlen.

"Hilfe: Ich brauch wieder meinen Bastler!" :-)

Melde dich als Benutzer mit normalen Benutzerrechten an, starte den ProcessMonitor und jetzt die Bäckersoftware starten. Filtern auf die Bäckersoftware.EXE. Möglicherweise braucht es mehrere Anläufe, aber nur so kommst Du weiter.

 

Dann musst du aber alle Use-Cases der Software kennen und durchspielen und auch die Unterprozesse, die es sicher gibt, betrachten.

Alle über normale Userrechte und hinausgehende Einstellungen (incl. Privileges) muss der Hersteller konfigurieren und dokumentieren!

Es ist auch eine Frage des Supports, wenn man als Kunde selbst anfängt, Berechtigungen nach bestem Wissen und Gewissen (=Bastelbude) zu setzen.

BTW: So selten kommt die Forderung nach Adminrechten auch bei aktueller Software heute nicht vor! Ich glaube, es ist einfach eine Frage des Aufwandes für den Hersteller. Wenn 90% aller Kunden der Software ohne mit der Wimper zu zucken Adminrechte geben, warum sollte ich da als Hersteller in Security, die mir keiner anrechnet, investieren? Der Bäcker hat wahrscheinlich eh schon Dutzende von Schwachstellen.

Was die Administratorrolle eigentlich so gefährlich macht, sind die sogenannten Priviliges

https://technet.microsoft.com/en-us/library/cc771990.aspx

z.B.

"Debug Programs"

damit kann man die Rechte an laufenden Prozessen verändern, DLLs von Prozessen austauschen, Passworthashes dumpen, etc.

https://blogs.msdn.microsoft.com/oldnewthing/20080314-00/?p=23113

"Load and unload device drivers"

Warum muss die Software Treiber laden und entladen können?  

Es gibt noch weitere, sehr gefährliche Privileges ("Die berühmten bösen 7"), die kaum ein Administrator jemals braucht. Und die Bäckereisoftware garantiert nie!

Der Hersteller soll darlegen, welche Privileges sein Account warum braucht. Dann gib ihm einen User mit nur diesen Privileges in der LGPO.

Auch NTFS-Rechte können explizit gesetzt werden.

Frag den Hersteller, ob  ein "Power User" auch genügen würde :-)

blub

klar!

RSAT Tools installieren

Start - run - open "servermanager"

Zumindest bei Win10 steht dir mit entsprechenden Rechten alles offen. Bei Win8/ 8.1 wahrscheinlich auch. Win7 musst du mal selbst probieren

RDP muss meist  nicht mehr sein :-)

Bei Brandschutz geht es ja nicht nur um die Haftung für mögliche Sach- sondern auch um die Verantwortung für Personenschäden!

Daher such dir bitte verbindliche Ratschläge nur bei ausgewiesenen Experten (Feuerwehr, Experten Eurer Gebäudeschutzversicherung, Elektriker, etc.), nicht bei Laien wie uns. So sehr wie ich das IT-Expertenwissen hier sonst auch schätze.

Bis dahin nimm deine Server vom Strom!

Mal sehen, lass uns diesen Thread in 12 Monaten wieder ausgraben :-)

"Halbleeres Glas"

Einfach ignorieren darf man es jedenfalls nicht: Bash ist ein weiteres Einfallstor für Locky und Kollegen.

ich habs halt grad erst im FastRing-Update bemerkt und fand es erstaunlich. Unabhängig ob man's braucht oder nicht.

Und drwindows.de wird sicher auch nicht die erste Quelle gewesen sein, die darüber berichtet hat...

Vor zwei Jahren wäre das selbst als Aprilscherz zu albern gewesen

http://www.zdnet.com/article/ubuntu-and-bash-arrive-on-windows-10/

aber es stimmt!

Versuch eines SQL-Laien:

SELECT KdNr, Produkt,Min([bestelltAm])
GROUP_CONCAT(Produkt SEPARATOR ', ') AS Produkte
FROM verkauf
WHERE KdNr = KdNr
GROUP BY KdNr;

Auf das Result könntest du eine zweite Abfrage legen, die die Ergebnisse so aufbereitet, wie du das brauchst.

Ich versteh dich durchaus! Aber wenn du so weiter machst, hast du 2 Risiken

- irgendwann geht gar nichts mehr. Laut Murphy passiert das im denkbar ungünstigsten Moment

- du hast dir eine Malware eingefangen, die mehr oder weniger unangenehme Dinge mit deinem Rechner und deinen Passwörtern anstellen kann.

     ->Solltest du dich zu einer Neuinstallation entschließen, wechsle anschließend alle deine PWs!

Und wenn du kritische Applikationen laufen hast, überleg dir ein Update auf Win10. Man mag über die Bedienung schimpfen, aber die Securityfunktionen haben sich zu Win7 doch sehr verbessert!

Mit der Opera-Installation wollte ich eingrenzen, ob deine Probleme an im Oktober installierten Einstellungen/ Plugins in den Browsern selbst liegen, oder ob das Betriebssystem schuld ist.

Aber wenn du sowohl den IE11 nicht installieren kannst und auch das .Net-Update unbekannte Fehler liefert, dann liegt es wohl am Betriebssystem. Meiner Meinung nach ist dann tatsächlich eine Neuinstallation die sinnvollste Lösung. Zumindest fällt mir nichts Besseres ein.

vielleicht irgendein BrowserPlugin. NoScript etc.

kannst du mal den Opera - Browser installieren? Ob der auch die Probleme hat.

Flash ist offenbar aktuell.

Sind das immer https-Seiten, die Probleme machen?

Hast du eine aktuelle Flash-Version auf deinem Rechner?

Systemsteuerung - Programs - Adobe ....

Sehr viel ist ja schon gewonnen, wenn man ein bischen sensibler mit dem SecurityThema umgeht. Wie oft werden beispielsweise WindowsServer neu installiert, als erstes die Windows Firewall deaktivert und als zweites RDP ohne Nachzudenken aktiviert und genutzt.

Irgendwann später kommt die Maschine dann mal in die Domäne und wird dort erst aktuell gepatcht.  ... Zumindest bis dahin waren die Tore weit geöffnet!

(da sind auch gestandene Admins dabei, keine User und keine Geschäftsführer)

Standardadministrationstools wie der Servermanager oder die Remoteverwaltungsdienste sind einer RDP-Connection möglichst vorzuziehen. Aber wenn man RDP benutzen muss, sollte man sich der möglichen Schwachpunkte bewusst sein und auch wie man diese abfedert.

Teamviewer habe ich mir nie besondes tief angesehen.

Nur als Beispiel:

http://www.br.de/nachrichten/oberfranken/inhalt/trojaner-locky-fraunhofer-institut-bayreuth-100.html

60 Rechner wurden sicher nicht befallen, weil 60 User einen Locky-Anhang geöffnet haben, sondern weil ein User, der über diese 60 Rechner administrtative Rechte hatte, die Malware ausgeführt hat. So gesehen sagt die verlinkte Meldung nichts Neues.

Die FW könnte wirksam gegen solche Angriffe wirken, wenn sie den Zugriff auf die Homeseite von Locky etc. unterbindet.

Die FW muss dazu regelmäßig mit Black-Adressen upgedatet werden, z.b. exemplarisch von

www.malwaredomainlist.com

www.malwareurl.com

www.urlblacklist.com

....

Wenn man nicht zu den allerersten Angriffsopfern gehört, ist das ein relativ guter Schutz. Dasselbe könnte man auch über DNS erreichen (Sinkhole)

RDP ist eine gefährliche Angelegenheit, die zumindest sauber konfiguriert gehört (siehe die zugehörigen GPO-Einstellungen).

Weiter ist, wie schon angesprochen, die Problematik mit TLS 1.0/ CredSSP zu beachten, auch wenn hoffentlich der Update-Patch KB3080079 auf allen w2008R2/ win7 Systemen installiert ist.

https://support.microsoft.com/en-us/kb/3080079

https://support.microsoft.com/en-us/kb/3097192

Und auch wenn RDP mit maximaler Sicherheit konfiguriert ist, so sollten Admins trotzdem möglichst auf andere Möglichkeiten ohne interactive Anmeldung wie Powershell/ WMI etc. ausweichen um Remotemaschinen zu administrieren.

So ist zumindest meine Empfehlung an unsere Admins. Die Begeisterung über diesen Vorschlag ist riesig :cool:

Eine moderate Paranoia ist absolut hilfreich! :D

Noch ein Beispiel: Eine amerikanischer Spielzeughersteller mit seiner "Puppe" mit WLAN-Verbindung.

Wenn möglich, diesen ganzen Home IoT-Kram nur noch in einem zugedrehten Gast-Netz laufen lassen. z.b. mit der FritzBox ist dies relativ einfach zu bewerkstelligen.

NLA führt vor der eigentlichen RDP Anmeldung am Server eine Art Voranmeldung mit den Credentials durch, um Resourcen am Zielserver zu schonen und auch um DenialOfService-Angriffe zu verhindern. Diese Vor-Übertragung der Credentials beruht auf dem CredSSP-Protokoll, welches wiederum auf TLS1.0 basiert.

TLS1.0 kann man als "gebrochen" betrachten. (Google: TLS1.0 + deprecated). d.h diese vorübertragenen Credentials liegen offen für MITM-Attacks. Credentials zu verlieren ist in den meisten Fällen schlimmer als eine DOS-Attacke.

RDP sollten Administratoren aus Securitygründen wegen dieser veralteten Protokolle generell nur als letzten Ausweg benutzen. WMIconnects oder Remotepowershell sind als Verwaltungstools deutlich besser!

blub