Wieso die tägliche Arbeit unter Administratorrechten keine gute Idee ist!

Wieso die tägliche Arbeit unter Administratorrechten keine gute Idee ist – und wie man es besser macht!

Jedem sollte klar sein das ein Windows System das mit einem Benutzer verwendet wird, der in der Gruppe der „Lokalen Administratoren“ (schlimmer noch „Domänenadmin“) ist, ein offenes Scheunentor darstellt. Viren, Trojaner, Spyware wird damit der Weg bereitet sich ungestört auszubreiten.

Dieses komische verhalten würde ich mit einem offenen Haus vergleichen.

Du kaufst dir die teuerste und beste Alarmanlage die es gibt. Lässt Gitterstäbe an die Fenster montieren und lässt ein Sicherheitsschloss einbauen… du musst schnell weg hast keine Zeit und bum du lässt die Türe offen stehen.

Horrende ausgaben und es hat alles nichts genützt … dein Haus wurde ausgeraubt.

Gerade wenn man Systemadministrator ist hat man eine hohe Verantwortung zu tragen und sollte seine Arbeitsumgebung entsprechend sicher gestalten um sich seine Firma und seine Mitarbeiter zu schützen.

Es ist auch unverständlich wenn ständig über die Sicherheitsmängel von Windows gemeckert wird, aber die grundlegenden Sicherheitsregeln nicht eingehalten werden.

In einer Unix/Linux-Umgebung würde niemals jemand auf die Idee kommen ständig als „root“ zu arbeiten. Wieso interessiert das keinen in der Windowswelt?

Was kann passieren wenn ein Virus ein bekanntes Sicherheitsloch ausnützt:

• Installation von "kernel-mode rootkits" und/oder „keyloggers“ (Welche fast nicht entdeckt werden können)
  
• Installation und start von Systemdiensten
  
• Installation ActiveX controls, IE Add-Ins eingeschlossen (Spyware, Adware)
  
• Zugriff auf Daten dritter
  
• Automatische Codeausführung bei jeder Anmeldung (z.B. Passwortklau vom Strg-Alt-Entf Dialog)
  
• Austausch von Betriebssystem- und anderen Programmdateien durch Trojanische Pferde
  
• Zugriff auf LSA (Local Security Authority ) Geheimnisse, evt. Zugriff auf Domänenkonteninformationen
  
• Beenden o. Deinstallieren von Antivirussoftware
  
• Spurenverwischung in der Ereignisanzeige
  
• Den Computer in einen “nicht-startfähigen” Zustand versetzen.
  
• wenn dein Benutzerkonto Adminrechte auf einem anderen Computer hat, kann die Malware auch die Kontrolle über diese System übernehmen.
  
• und vieles mehr
  

Um so weniger Rechte unser Benutzeraccount innehat umso weniger kann auch ein Schädling am System anrichten.

Deswegen sollte klargestellt sein, dass wir nur Mitglied der Gruppe Benutzer sein sollten. Jetzt müssen wir uns aber überlegen was wir dann noch für Änderungsrechte am System haben.

Grob gesagt wenig ziemlich wenig… aber so sollte es ja sein!

Keine Softwareinstallation, Kontenverwaltung usw.

Details siehe hier: http://www.grurili.de/Grundlagen/Wer_darf_was.htm

Wie können wir nun unsere Administratortätigkeiten trotzdem durchführen?

Durch Verwendung des sekundären Anmeldedienstes von 2k/XP/2k3 um einen Prozess unter anderem Benutzerkontext ausführen.

Bevor wir den Dienst nutzen können muss dieser natürlich gestartet sein. Dies kontrollieren wir kurz über folgende Eingabe:

Windows-Taste + R => services.msc

Dort suchen wir nach dem Dienst „Sekundäre Anmeldung“ der sollte gestartet sein und der Starttyp sollte auf „Automatisch“ gesetzt sein.

Wie können wir nun die Sekundäre Anmeldung verwenden?

Zuerst bietet sich die GUI von 2k/XP/2k3 an. Sie bietet eine integrierte Funktion mit der man Prozesse unter anderem Benutzerkontext ausführen kann.

Beispiel wir sind als Benutzer angemeldet und möchten die Kommandozeile als Administrator starten.

Dazu öffnen wir das Startmenü klicken mit der rechten Maustaste auf die Kommandozeile und klicken im erscheinenden Kontextmenü auf „Ausführen als“ nun geben wir den Benutzernamen und das Passwort des Admins ein und dann auf OK. Mit welchem Benutzer die Kommandozeile jetzt läuft können wir auch im Taskmanager kontrollieren.

http://www.kohnonline.de/images/runas-gui-01.JPG

http://www.kohnonline.de/images/runas-gui-02.JPG

Dazu bitte Windows-Taste + R => taskmgr

http://www.kohnonline.de/images/runas-gui-03.JPG

Die GUI ist aber nicht immer die schnellste Methode Programme unter anderem Benutzerkontext ausführen.

Der Befehl „runas“ ist öfters die schnellere Lösung da man seine Desktop-Verknüpfungen einfach so umschreiben kann, dass diese über „runas“ laufen.

Syntax:

Windows-Taste + R =>

runas /user:Computer/Domänenname \Administrator “cmd”

Beispiel 1 (Lokaler Administrator):

Windows-Taste + R =>

runas /user:workstation1\Administrator “cmd”

Beispiel 2 (Domänen – Administrator von nwtraders):

Windows-Taste + R =>

runas /user:nwtraders\Administrator “cmd”

Interessant wird es aber erst wenn wir alle Administrativen Tätigkeiten darüber ausführen können, also auch die Domänenverwaltung.

Wie man eine XP-Workstation grundsätzlich mit den nötigen MMC´s zur Domänenverwaltung ausstattet habe ich hier beschrieben:

http://www.mcseboard.de/showthread.php?threadid=64276

Hier ein kurzer Überblick über Möglichkeiten mit runas:

MSC-Konsolen:

Active Directory Benutzer und Computer:

runas /user:Domänenname\Administrator “mmc dsa.msc”

Active Directory Standorte und Dienste:

runas /user:Domänenname \Administrator “mmc dssite.msc”

DNS Management:

runas /user:Domänenname \Administrator “mmc dnsmgmt.msc”

Eine kleine Liste der Standard-MSC´s gibt’s hier:

http://www.ilopia.com/FAQ/Q50.aspx

Systemsteuerungs-Anwendungen (CPL-Dateien)

runas /user:Computername\Administrator "rundll32.exe shell32.dll,Control_RunDLL sysdm.cpl"

runas /user:Computername\Administrator "rundll32.exe shell32.dll,Control_RunDLL appwiz.cpl"

BTW: Diesen Artikel werde ich in den nächsten Tagen noch erweitern und auch noch alternative Möglichkeiten zu “runas” und “Ausführen als” zeigen.

Weitere Informationen zur "Sekundären Anmeldung":

http://support.microsoft.com/?kbid=225035

http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/Default.asp?url=/resources/documentation/Windows/XP/all/reskit/en-us/prdp_log_gvra.asp

http://www.petri.co.il/run_control_panel_applets_as_another_user.htm

http://www.petri.co.il/run_ad_tools_as_another_user.htm

LG Gadget

Mein Tipp: Ich lasse W2K3-Server und SBS 2003 im Kontext des Druckeroperators laufen. Alle Dienste funktionieren tadellos, auch Antivirenprogramme, der Druckeroperator kann nur an Druckern und Druckaufträgen herumfummeln, hat aber im Notfall dss Recht, den Server neu zu starten.

@Kohn

Super Thread, vielleicht arbeite ich an meinem PC zu Hause jetzt auch nur noch mit eingeschränkten Rechten, wobei mit Adminrechten ist es doch viel bequemer. :D ;)

Hi Necron,

Super Thread, vielleicht arbeite ich an meinem PC zu Hause jetzt auch nur noch mit eingeschränkten Rechten, wobei mit Adminrechten ist es doch viel bequemer.

danke...

Zwecks Bequemlichkeit... hm ...bequemer ist es eigentlich nur solange keine Malware im System rumgefuhrwerkt hat. Wenn was passiert und du dein System neu aufsetzen musst, ist die Arbeit mit einem LUA-Account (Least-Privileged User Account) bequemer und sicherer.

Ich muss dir aber recht geben, dass bei 2k/XP/2k3 System die Integration und das Handling diesbezüglich noch nicht perfekt ist. In Longhorn wird sich die Arbeit mit einem LUA-Account aber höchstwahrscheinlich bedeutend einfacher gestalten und auch zum Standard werden.

LUA in Longhorn (part 1):

http://www.windowsitpro.com/Windows/Article/ArticleID/46906/46906.html

LUA in Longhorn (part 2):

http://emea.windowsitpro.com/Article/ArticleID/47022/47022.html

Mehr zum Thema LUA (empfehlungen vom MS):

Using a Least-Privileged User Account:

http://www.microsoft.com/technet/security/secnews/articles/lpuseacc.mspx

LG Gadget

Hi, sehr schöne Zusammenstellung.

Hier nochwas - LowRights

Hi Urmel,

Hier nochwas - LowRights

du nimmst mir die Worte aus dem Mund .... über Dropmyrights wollte ich auch noch was schreiben. :D

Dropmyrights dreht den Spieß um und versucht erhöhte Sicherheit durch verringerung der Rechte einzelner Anwendungen zu erzielen. Ein Ansatz der imho erhöhtem Sicherheitsbedürfnis nicht ganz gerecht wird.

Es ist aber natürlich immer noch besser als mit Adminrechten zur surfen und zu mailen und könnte vielleicht eine Lösung für Anwendungen auf Servern sein, die auch mit Weniger rechten laufen.

Meiner Meinung nach sollte man wirklich nur mit Adminrechten arbeiten wenn alle anderen Möglichkeiten ausgeschöpft sind.

EDIT: Achja noch ein kleiner Hinweis auf eine Toolbar für den IE. Umso mehr man mit der Sekundären Anmeldung arbeitet umso öfter möchte man gerne wissen unter welchem Kontext eine geöffnete Anwendung gerade läuft.

Aaron Margosis hat für den IE eine Toolbar geschrieben die, dieses Problem löst:

Aaron Margosis' Weblog: PrivBar -- An IE/Explorer toolbar to show current privilege level

LG Gadget

Was ich absichtlich in den letzten Posts unterschlagen habe will ich jetzt nachholen.

Seit XP bietet das Tool Runas die Option per Parameter "/savecred" ein einmal benutzes Paswort abzuspeichern.

Beispiel:

runas /savecred /user:Computer/Domänenname \Administrator “cmd”

/savecred:

Verwendet Anmeldeinformationen, die von einem anderen Benutzer gespeichert wurden. Die Option steht auf Windows XP Home Edition nicht zur Verfügung und wird ignoriert.

Was in der Hilfe nicht steht => Diese Option stellt ein große Sicherheitslücke dar, da jede beliebige Anwendung mit runas gestartet werden kann und jedesmal kein Kennwort eingegeben werden muss.

Deswegen: Falls ihr die Option /savecred schon verwendet habt solltet ihr die gespeicherten Anmeldeinformationen unbedingt löschen. Der Speicherpfad der Andmeldeinformationen ist %APPDATA%\Microsoft\Credentials

Hier gibts mehr Infos =>

http://tinyurl.com/cng72

http://archives.neohapsis.com/archives/ntbugtraq/2003-q3/0069.html

und falls man erhöhte Sicherheiterfordernisse hat sollte man evt. darüber nachdenken "runas" an den Nicht-Admin-Clients per "Software Restriction Policies" zu unterbinden:

http://www.windowsdevcenter.com/pub/a/windows/2004/03/16/serverhacks_runas.html

(Obwohl das wiederrum einige Umstände verursacht da man sich ohne runas fast Zwangsweise Ab u. Anmelden muss, solange keine Drittherstellersoftware verwendet wird , wenn Wartungsarbeiten an den Clients anstehen.)

BTW: Falls jemand eine Möglichkeit findet den Parameter /savecred zu unterbinden so, dass runas aber noch läuft. Der würde mir echt ne Freude machen!

Stay tuned - in den nächsten Tagen kommt noch mehr zum Thema!

Viel Mühe und ein gutes Thema.

Toll gemacht Kohn. :D :thumb1:

Danke :D

Wieso hat sich die Nutzung von LUA (Least-privileged User Accounts) immer noch nicht durchgesetzt?

Das liegt wohl daran, dass viele Programmierer immer noch nicht das Konzept hinter Microsofts Multiusersystem verstanden haben. Die Registry ist in Computereinstellungen (Hive Key Local Machine) und Benutzereinstellungen getrennt (Hive Key Current User) getrennt.

Viele Programme wollen aber immer noch Benutzereinstellungen unter HKLM schreiben oder den Programmstatus unter %programfiles% statt unter %appdata% abspeichern, was dem Sicherheitskonzept von MS völlig widerspricht.

Eine Auflistung verschiedener Anwendungen (sind natürlich nicht alle) die nicht korrekt mit einem LUA laufen hat unter anderem Susan Bradley (SBS MVP) erstellt:

http://www.threatcode.com/

einen KB Artikel dazu gibt’s auch:

http://support.microsoft.com/default.aspx?scid=kb;en-us;307091

Um eine gesicherte Umgebung aufzubauen sollte man versuchen die Benutzung solcher Software zu minimieren oder auf das Drittherstellerprodukt von Desktopstandard „Application Security“ zurückgreifen, welches übrigens bei der Verwaltung per Lokaler Richtlinie kostenlos ist.

Mit Application Security kann man per Gruppenrichtlinie einer Anwendung Berechtigungen zuweisen, d.h. man weist ihr die Berechtigung zu die sie benötigt.

http://nonadmin.editme.com/PolicyMakerApplicationSecurity

Wie kann ich Software installieren während ich einen LUA benutze?

Normalerweise würde die Verwendung von Runas kein Problem, darstellen doch leider kommt es häufig wie oben beschrieben vor das Programme unter HKLM u. HKCU schreiben wollen.

Wenn wir jetzt aber ein Programm per Runas als Administrator installieren so können die Einträge nicht im richtigen Benutzerprofil gemacht werden und der Start schlägt evtl. fehl.

Also was bleibt uns übrig unser LUA muss kurzzeitig Administratorrechte erhalten. Wenn wir das per GUI machen hat dies erst eine Auswirkung nach An/Abmeldung was die praktische Arbeit zu Tortur machen würde.

Doch Gott sei Dank hat Aaron Margosis ein kleines Batch-Skript veröffentlich welches dieses lästige Problem umgeht: Makemeadmin.cmd

http://blogs.msdn.com/aaron_margosis/archive/2004/07/24/193721.aspx

http://blogs.msdn.com/aaron_margosis/archive/2005/03/11/394244.aspx

Makemeadmin.cmd öffnet eine Kommandozeile unter dem aktuell angemeldeten Benutzer unter Administratorrechten.

Was bringt uns das: Alle Prozesse die aus der Kommandozeile gestartet werden haben Zugriff auf HKLM u. HKCU. Wir können also daraus wunderbar Anwendungen installieren die solche Rechte benötigen. (Auch MSI-Pakete funktionieren einwandfrei)

Ist die Verwendung eines Benutzers mit Hauptbenutzerrechten nicht Sicher genug?

Nein auf keinen Fall! Ein Hauptbenutzer besitzt soviel Rechte das er sich bzw. eine Malware sich erhöhte Rechte (Adminberechtigungen) beschafft und so das System kompromittiert.

MS hat dazu einen KB veröffentlicht:

KB825069: A member of the Power Users group may be able to gain administrator rights and permissions in Windows Server 2003, Windows 2000, or Windows XP

http://support.microsoft.com/default.aspx?scid=kb;en-us;825069

Wo bekomme ich noch mehr Info zur Arbeit mit einem LUA?

In Zukunft werde ich alle Ressourcen die ich zum Thema LUA finde hier abpseichern:

http://www.furl.net/members/kohn/lua

RSS gibts auch:

http://www.furl.net/members/Gadget/rss.xml?topic=lua

und wer sich für das Thema Security interessiert sollte sich unbedingt auch Aaron´s Technet Webcast von der TechED 2005 reinziehen:

TechNet Webcast: Tips and Tricks to Running Windows with Least Privilege (Level 300)

LG Gadget

Wie kann ich Programmverknüpfungen einrichten die standardmäßig unter anderem Benutzerkontext laufen:

1. Eigenschaften der Verknüpfung aufrufen:

http://www.kohnonline.de/images/runas-gui-04.jpg

2. Erweiterte Eigenschaften der Verknüpfung aufrufen u. bei "unter anderen Anmeldeinformationen ausführen" einen Haken setzen:

http://www.kohnonline.de/images/runas-gui-05.jpg

Wie kann ich den Explorer per runas aufrufen?

Wenn man den Befehl:

runas /user:computername\Benutzername "explorer.exe"

so aufruft wird man ein langes Gesicht machen weil nichts passiert.

Also welche Alternativen bieten sich uns:

1. Den Internet Explorer zu Dateiverwaltung verwenden (Verwendung von Privbar von Aaron Margosis würde ich empfehlen)

2. Als Administrator (oder den Benutzer den man angeben will bei Verwendung von Runas) anmelden u. Explorer starten / Extras / Ordneroptionen / Ansicht / Ordnerfenster in eigenem Prozess starten anhaken

Nun kann man sich wieder mit seinem LUA Benutzer anmelden und die Verwendung des Explorers mittels runas sollte funktionieren. (Es kann öfters mal vorkommen, dass man die Ansicht aktualisieren muss, da der Explorer nicht ursprünglich dafür entwickelt wurde per Runas gestartet zu werden.)

LG Gadget

Hallo Kohn,

danke für die ausführlichen Infos und Links.

Kann man auch die komplette Systemsteuerung unter einem anderen Benutzer ausfüren?

So dass man sich nicht für jede einzelne cpl eine Verknüpfung anlegen muß.

Tobias

Hi Hercules,

ich führe die CPL´s per Tastatureingabe aus... hab mir deswegen noch keine gedanken darüber gemacht.

Hab aber gerade nen Test gemacht und konnte die Systemsteuerung über foldenen Befehl starten:

runas /user:domainname\username "control"

Scheint aber erst seit XP zu funktionieren.

LG Gadget

runas /user:domainname\username "control"

 

Scheint aber erst seit XP zu funktionieren.

LG Gadget

Geht auch mit 2k man muss nur in den Ordneroptionen des Explorer den Haken setzen "Ordnerfenster im eigenen Prozess starten" wie ich hier auch schon beschrieben hab:

https://www.mcseboard.de/showpost.php?p=396742&postcount=12

LG Gadget