Because security matters

SELinux Regeln erstellen

2009-12-23T18:12:00.005+01:00

Eines der Hauptprobleme bei SELinux ist sicherlich die Erstellung von geeigneten Regeln. Mancher Benutzer wird aufgrund der schieren Masse an Logeinträgen sicherlich verzweifeln. Doch das musst nicht sein. Mit einigen wenigen Schritten lassen sich Regeln erstellen, die sowohl sicher als auch einfach zu administrieren sind.

In diesem Szenario verwendete ich Gentoo Linux mit einem entsprechenden Kernel um eine Unterstützung für SELinux bieten zu können. Es wird davon ausgegangen das SELinux bereits installiert ist und grundlegend funktioniert.

1. SELinux im sog. "permissive mode" laufen lassen

Im permissive mode lässt SELinux zwar noch alle Aktionen zu, die im strict mode verboten wären jedoch werden die Verstöße an verschiedenen Stellen geloggt. Diese werden später genutzt um dann daraus die Regeln zu erstellen.

Um zu überprüfen, ob SELinux im richtigen Modus läuft reicht es, folgenden Befehl in der Konsole einzugeben:

getenforce

Dies sollte als Ergebnis Permissive liefern. Sollte dies nicht der Fall sein, so sollte man einen Blick auf seine SELinux Config werfen, die sich unter /etc/selinux/config findet. Dort sollte SELINUX=permissive eingetragen werden. Um sicher zu gehen, dass dies übernommen wird starten wir anschließend neu.

2. SELinux lernen lassen

Nun ist es an der Zeit SELinux lernen zu lassen. Am besten macht ihr dies, indem ihr das System wie gewohnt benutzt, alle Dienste die später darauf laufen sollen testet usw. Ich demonstriere dies am Beispiel eines FTP-Daemons. Diesen habe ich gestartet, mich darauf verbunden mit einem FTP-Client wie z.B. Filezilla und dort z.B. Ordner erstellt, gelöscht, umbenannt usw. Ihr solltet all das machen, was ihr erwartet was die Benutzer später tun werden.

3. SELinux Policies erstellen

Nun da ihr euer System schon etwas getestet habt, ist es an der Zeit die Meldungen, die SELinux protokolliert hat in sog. Policies umzuwandeln. Bitte beachtet jedoch: Natürlich kann es sein, dass sich während dem zweiten Schritt schon ein Angreifer Zutritt zu eurem System verschaffen hat. Somit würden wir die vom Angreifer erzeugten Regelverstöße ebenfalls erlauben. Es ist also mehr als ratsam die Regeln nicht nur blind zu kopieren sondern diese auch zu untersuchen.

Genug geredet. Jetzt geht es los.Wie bereits anfangs erwähnt nehmen wir die Logeinträge, die SELinux erstellt hat als Grundlage für unsere neuen Regeln. Doch wo werden diese gespeichert? In meinem Fall habe ich diese direkt aus dmesg bezogen, da sie in keiner anderen Log auftauchten.

Doch nun einmal gleich zum Anfang eine gute Nachricht: Die Entwickler von SELinux haben gute Arbeit geleistet und ein Tool erstellt, welches es erlaubt aus den Logeinträgen fertige Regeln zu bauen. Ich verwende es folgendermaßen:

audit2allow -d -l >> ~/a2a

Nun wird eine Datei namens "a2a" im Homeverzeichnis des aktuellen Benutzers angelegt. Diese enthält alle erforderlichen Informationen die wir zum erstellen von unseren Policies benötigen.

Diese öfnnen wir nun z.B. mit nano:

nano ~/a2a

Dort finden wir nun einige Einträge, die ähnlich wie dieser aussehen:

#============= dmesg_t ==============

allow dmesg_t etc_t:file { read getattr };
allow dmesg_t file_t:file { write getattr };

Jeder Eintrag, der mit #=============... beginnt steht hierbei für einen Dienst. Es empfiehlt sich aus Gründern der Übersichtlichkeit später für jedes dieser Dienste eine eigene Policy zu erstellen. Ich habe unter / ein Verzeichnis namens selinux-policies erstellt. Dort findet sich für jede Policy ein Unterverzeichnis mit dem Namen des Dienstes.

Doch wie sieht nun z.B. die Policy für dmesg aus? Hierzu erstellen wir nun eine Textdatei namens dmesg.te und öffnen diese mit nano. Meine dmesg.te sieht in diesem Fall so aus:

policy_module(dmesg,1.0.0)

require {
type dmesg_t;
type file_t;
}
#============= dmesg_t ==============
allow dmesg_t etc_t:file { read getattr };

allow dmesg_t file_t:file { write getattr };

Nun erklären wir das ganze noch fix. Das 1.0.0 steht für die Versionsnummer der Policy. Ich habe mir angewöhnt bei jeder Änderung an der Policy diese Nummer zu erhöhen und die Änderungen zu dokumentieren. Unter require müssen alle Typen aufgeführt werden, die weiter unten in der Policy auftauchen. Das war es eigentlich auch schon! Eine Policy vollständig zu erklären würde den Rahmen sprengen.

Nun speichern wir das ganze ab und machen uns unsere erste eigene Policy mit folgendem Befehl (hierzu muss man in dem Ordner sein, in dem wir gerade die .te-Datei gespeichert habem):

make -f /usr/share/selinux/strict/include/Makefile

Nun sollten wir im selben Ordner eine .pp Datei haben. Glückwunsch dies ist unsere erste Policy! Nun laden wir das ganze noch mit

semodule -i dmesg.pp

Nun sollte die Policy geladen sein. Jetzt kommt der ultimative Test. Wir schalten SELinux auf "strict" und schauen ob es wirklich funktioniert

setenforce 1

Nun solltet ihr ausprobieren ob alles wie gewünscht funktioniert. Nicht der Fall? Dann schnell wieder in den Permissive Mode!

newrole -r sysadm_r

Nun werdet ihr nach eurem root-Passwort gefragt. Danach könnt ihr die Policy wieder folgendermaßen entfernen

semodule -r dmesg

So geht ihr nun mit allen Policies vor bis alles funktioniert.

Hardened Gentoo mit SELinux-Unterstützung

2009-11-20T15:03:00.000+01:00

Zugegebenermaßen: SELinux ist eine wirklich sehr schwer verdauliche Kost. Da kommen diese Jungs der NSA daher und schmeißen alles über den Haufen was man bisher in Sachen Sicherheit für das Maß der Dinge hielt. Doch hat man sich erstmal reindenken können in die Thematik eines MAC (Mandatory Access Control) erscheint das ganze, man mag es kaum glauben, doch recht logisch.

Ausgangssituation war: Mein "Auftraggeber" wünschte einen FTP-Server. Als ich das hörte schrie der kleine paranoide Mann in meinem Ohr gleich lautstark "Linux!". Zugegebenermaßen bin ich kein Fan von Microsoft-Produkten. Daher stellte sich für mich die Frage welche Distribution wohl am besten meinen Ansprüchen gerecht wird. Bis dahin hatte ich mich immer erfolgreich davor gedrückt Gentoo zu benutzen. Doch wenn man Wert auf Skalierbarkeit und ein schlankes System legt kommt man kaum um Gentoo herum. Das erste was mir auffiel war das Hardened Projekt von Gentoo. Dies war auch mein erster wirkliches Berührungspunkt mit SELinux.

Mein erster Schritt war nun einen Kernel zu basteln, der sowohl auf einem VMWare vSphere Server läuft als auch Unterstützung für besagtes SELinux bietet. Nach etlichen Versuchen (Learning by doing :-) ) und unzähligen Kernel Panics habe ich es schließlich doch geschafft.

Im Nachhinein habe ich dann festgestellt, das es gar nicht so schwer ist wie viele Benutzer behaupten SELinux zum laufen zu bringen. Man muss sich nur etwas mit der Materie auseinandersetzen.

Der Server läuft nun schon seit ca. einem Monat und hatte laut diversen Logs schon mit einigen Hacker-Angriffen zu tun. Bis jetzt erwies er sich als sicher. Dies wurde dadurch erreicht indem die sog. "Strict-Policy" von SELinux zum Einsatz kam. Hierbei werden standartmäßig alle Zugriffe verboten wenn sie nicht explizit durch eine Policy erlaubt wurden. Natürlich ist das mit einer Menge Arbeit verbunden allerdings zählt ja bekanntlich nur das Ergebnis :-)

Nun ist das ganze produktiv im Einsatz und der Server brauch nur 35 MB Arbeitsspeicher unter Volllast.

Ich werde in Kürze hier ein HowTo veröffentlichen falls jemand das selbe plant.

Katastrophaler Bug in Acronis Backup u. Recovery 10

2009-09-12T14:12:00.002+02:00

In der aktuellen Version von Acronis Backup & Recovery 10 befindet sich ein Fehler, der durchaus dafür sorgen kann, dass Administratoren einen Herzinfarkt erleiden können.

Ein guter Administrator zeichnet sich dadurch aus, dass er ein schlüssiges Backupkonzept umgesetzt hat und dieses auch aktiv nutzt. Doch dank Acronis ist auch dies keine Garantie dafür, dass Administratoren ruhig schlafen können.

Zuerst einmal das Positive: Mit Backup & Recovery 10 ist Acronis eine wirklich intuitiv zu bedienende Backuplösung gelungen, die es nach kurzer Einarbeitungszeit ermöglich seine Systeme effektiv zu sichern.

Doch was passiert, wenn sich die Backups nicht mehr einspielen lassen im Ernstfall? Diese Erfahrung musste ich leider selbst machen. Nachdem es zu einem Ernstfall kam in dem mehrere Server wiederhergestellt werden mussten die zuvor mit Acronis Backup & Recovery 10 gesichert wurden, kam ein Fehler zum Vorschein der schon fast unwirklich erschien.

Es lassen sich nur Festplatten/Volumes wiederherstellen, die kleiner wie 108 GB sind!

Nach einem hitzigen Gespräch mit einem Support-Mitarbeiter von Acronis gestand dieser, dass diese 108-GB Grenze von den Entwicklern schlichtweg vergessen wurde wieder zu entfernen.
Eine Behebung des Fehlers konnte dieser nicht versprechen und vertröstete mich auf eines der nächsten Updates, die in 1-2 Monaten erscheinen.

Da stellt sich mir die Frage wie gründlich Acronis seine Produkte vor einem Release testet? Anscheinend wird nur überprüft ob das Programm überhaupt startet. Andernfalls hätte dies wohl auffallen müssen!

Ich kann allen nur raten: Hände weg von Acronis Backup & Recovery 10 bis dieser Fehler beseitigt wurde!

Allerdings lässt sich sagen, dass die englische Version, die man unter Acronis.com herunterladen kann um einiges stabiler läuft wie die Deutsche Version.

Auch Windows kann sicher sein! [ Teil 4: Sicherheitskonfiguration ]

2009-05-08T11:45:00.003+02:00

Hier findest Du Teil 1 des Guides [Installation]
Hier findest Du Teil 2 des Guides [Hardening]
Hier findest Du Teil 3 des Guides [Windows Komponenten]

In diesem Kapitel soll es nun um die Sicherheitskonfiguration gehen. Diese findest du bereits wie in Teil 3 dieses Guides beschrieben unter Start > Verwaltung > Lokale Sicherheitsrichtlinie.

Bitte beachte jedoch, dass es sich bei den hier gemachten Einstellungen lediglich um Empfehlungen handelt!

Wenn wir das Programm Lokale Sicherheitsrichtlinie gestartet haben, navigieren wir zu dem Punkt Lokale Richtlinien / Überwachungsrichtlinie. Dort werden wir nun folgende Änderungen anwenden:

Anmeldeereignisse überwachen: Erfolgreich und fehlgeschl.
Kontenverwaltung überwachen: Erfolgreich und fehlgeschl.
Anmeldeversuche überwachen: Erfolgreich und fehlgeschl.
Verzeichnisdienstzugriff überwachen: Erfolgreich und fehlgeschl.
Richtlinienänderungen überwachen: Erfolgreich
Rechteverwendung überwachen: Keine Überwachung
Prozessverfolgung überwachen: Keine Überwachung
Systemereignisse überwachen: Erfolgreich

Sobald Du diese Einstellungen übernommen hast geht es auch schon weiter. Einen weiteren wichtigen Teil des Hardenings macht nämlich das Zuweisen von Benutzerrechten aus (Lokale Richtlinien/Zuweisen von Benutzerrechten). Bitte rufe diese jetzt auf!

Zugriff vom Netzwerk auf diesen Computer verweigern: SUPPORT_388945a0, ANONYMOUS-ANMELDUNG
Anmeldung als Batchauftrag verweigern: GAST
Anmeldung über Terminaldienste verweigern: Administrator , Gast, SUPPORT_388945a0
Wiederherstellung von Dateien und Verzeichnissen: Administratoren

Hätten wir das also auch geschafft :-)

Auch Windows kann sicher sein! [ Teil 3: Windows Komponenten ]

2009-05-08T11:28:00.003+02:00

Hier findest Du Teil 1 des Guides [Installation]
Hier findest Du Teil 2 des Guides [Hardening]

Wie bereits zu Anfang dieses Kapitels beschrieben, ist es unabdingbar für eine sichere IT-Infrastruktur nur das anzubieten, was wirklich benötigt wird. Dies wirkt sich nicht nur positiv auf die Performance des Systems aus, sondern minimiert auch die Einbruchchancen. Hierbei kann z.B. auf Systemkomponenten wie DHCP, WINS und RIS getrost verzichtet werden.

Es sollten folgende Windows Komponenten entfernt werden, da diese nicht benötigt werden:

Aktualisierung von Stammzertifikaten
MSN Explorer
Netzwerkdienste
Outlook Express
Windows Messenger

Einschränkungen der administrativen Zugriffe
Nach der erfolgreichen Installation von Windows Server 2003 sollte der Administrator-Account sowie der Gast-Account umbenannt werden. Ebenso darf nicht vergessen werden, die entsprechende Benutzerbeschreibung so zu ändern, dass nichts darauf hinweist, wer oder was sich hinter den geänderten Benutzernamen befindet.

Als weiteren Schritt sollte man einen weiteren administrativen Account erstellen und diesem ein sehr langes, kryptisches Passwort zuordnen, an denen sich Hacker dann mit Brute-Force Attacken austoben können.

Des Weiteren gilt für die tägliche Arbeit am Windows-Server, dass die Arbeit mit einem administrativen Account auf ein Minimum beschränkt werden sollte. Dies sollte nur geschehen, wenn es absolut notwendig ist. Weiterhin sollte das Surfen im Internet über den Windows Server möglichst vermieden werden, da die Rechte des aktuellen Benutzers sich auf einen evtl. eingefangenen Schädling vererben.

Erstellung und Einsatz von Sicherheitsvorlagen

Ein bewährtes Prinzip zur Sicherung einer Windows 2000 / 2003 Maschine nach einem festen Schema sind so genannte Sicherheitsvorlagen. Sicherheitsvorlagen sind strukturierte Textdateien (.INF Dateien) die als Basis für eine Sicherheitskonfiguration mit dem Security Configuration Editor (SCE) verwendet werden können. In den Sicherheitsvorlagen werden Einstellungen wie Kontenrichtlinien, Überwachungsrichtlinien, Registrierungseinstellungen, Konfiguration für Systemdienste uvm. definiert.

Nach erfolgter Definition kann man das aktuelle System anhand der Sicherheitsvorlage konfigurieren. Mit Hilfe der Sicherheitsvorlage ist sichergestellt, dass man immer ein und dieselbe Sicherheitskonfiguration auf Ihre Systeme anwendet.

Dies kann man konfigurieren, indem man Start > Verwaltung > Lokale Sicherheitsrichtlinie startet.

In dieser Konsole lassen sich nun sehr viele Sicherheitsaspekte einstellen und anschließend exportieren. Hier lassen sich z.B. auch einige empfohlene Einstellungen bezüglich der lokalen Accounts einstellen. Diese dienen primär dazu Brute-Force Attacken zu unterbinden.

Die folgenden Einstellungen bezüglich der Passwortsicherheit lassen sich einfach mit Hilfe des Tools „Lokale Sicherheitsrichtlinie“ ändern. Die folgenden Empfehlungen werden in Kontorichtlinien / Kennwortrichtlinien und Kontorichtlinien / Kontosperrungsrichtlinien gemacht.

Kontosperrdauer: 30 Minuten
Kontosperrungsschwelle: 5 Falsche Loginversuche
Zurücksetzung des Konto-sperrungszählers: 30 Minuten
Erzwingen einer Passwortchronik: 24 Passwörter
Maximales Kennwortalter: 60 Tage
Minimales Kennwortalter: 2 Tage
Minimale Kennwortlänge: 8 Zeichen
Kennwortkomplexität: Username oder Teile davon verboten
Zeichen, die verw. werden müssen: A-Z, a-z, 0-9
Passwortverschlüsselung: Keine umkehrbare Verschlüsselung verwenden

Hier geht es weiter mit Teil 4 des Guides

Auch Windows kann sicher sein! [ Teil 2: Hardening ]

2009-05-08T11:09:00.005+02:00

Hier findest Du Teil 1 des Guides

Wenn Du alle Rätschläge befolgt hast, die ich hier gegeben habe, befolgt hast kann das eigentliche Hardening nun beginnen. Ich hoffe, Du lässt dich von dem Umfang des Guides nicht abschrecken. Es lohnt sich! Das Ergebnis ist ein sicherer Windows Server.

Beginnen wir nun mit den Basics.

Physikalische Sicherheit
Für einen sicheren ISA Server Betrieb muss man sich auch um die physikalische Sicherheit der Systeme kümmern. Unter den Begriff "Physikalische Sicherheit" fallen:

Zugangsschutz zum Serverraum / IT-Infrastruktur (verstärkte Türen, Sicherheitsglas, Bewegungsmelder uvm.)

Zutrittsschutz zum Serverraum / EDV-Raum (z. B. Zahlenschloss).

Diebstahlschutz für die Server (zum Beispiel Montage in Racks mit abschließbaren Türen, spezieller Diebstahlschutz für Server)

Es gilt der Grundsatz: Kein System ist vor Angreifern sicher, wenn für den Angreifer ein physikalischer Zugriff auf die Systeme besteht.

Systemupdates für ISA und Windows

Der erste Schritt einer erfolgreichen Verteidigungslinie gegen potentielle Angriffe auf unsere Infrastruktur ist das zeitnahe einspielen von Updates sowohl für WindowS Server 2003 als auch für die darauf laufende Software wie z.B. den ISA Server. Diese Updates sollten zuerst auf einem Testserver überprüft werden, bevor sie auf dem Produktivsystem eingespielt werden. Desweiteren sollten die Updates dokumentiert werden um evtl. auftretende Probleme leichter eingrenzen zu können.

Deaktivierung nicht benötigter Dienste
Ein Grundsatz im Betrieb von Servern ist: Biete nichts an, dass du nicht wirklich brauchst. Dies wurde leider von Microsoft nicht konsequent umgesetzt und es werden viele Dienste angeboten, die nicht gebraucht werden und nur die Angriffsfläche erhöhen. Es folgt nun eine Liste von Diensten, die auf keinen Fall deaktiviert werden dürfen, da sie für das funktionieren des Systems unerlässlich sind.

COM+ Event Manager
Cryptographic Services
Event Log
IPSec Services
Logical Disk Manager
Logical Disk Manager Administrative Service
Microsoft Firewall
Micros. ISA Server Control
Micros. ISA Server Job Scheduler
Micros. ISA Server Storage
MSSQL$MSFW
Network Connections
NTLM Security Support Provider
Plug and Play
Protected Storage
Remote Access Connection Manager
Remote Procedure Call (RPC)
Secondary Logon
Security Accounts Manager
Server
Smartcard
SQLAgent$MSFW
System Event Notification
Telephony
Virtual Disk Service (VDS)
Windows Management Instrumentation (WMI)
WMI Performance Adapter

Es gilt das Prinzip: deaktivieren, um die Angriffsfläche und unnötige Risiken zu minimieren. Möglicherweise sinkt dadurch die Flexibilität von Windows Server 2003 und der Administrationsaufwand steigt. Aus Sicherheitsgründen sollten deaktivierte Funktionen trotzdem nur mit entsprechender Begründung bzw. Dokumentation wieder aktiviert werden. Es sollte genau überlegt werden, welche Funktionen für den konkreten Einsatz eines Windows Servers 2003 benötigt werden, so dass nur diese aktiviert werden.

Hier gehts weiter mit Teil 3 des Guides

Auch Windows kann sicher sein! [ Teil 1: Installation ]

2009-05-08T10:52:00.004+02:00

Ich als eingefleischter Linux-Fan bin zwar, was dies betrifft etwas voreingenommen allerdings muss ich zugeben, dass man auch ein Windows-Server System hinreichend absichern kann. Auf meiner Arbeit gab es nämlich die Aufgabe eine neue Firewall-Lösung in das Netzwerk zu integrieren. Hier fiel die Entscheidung auf Microsoft ISA 2006. Und ich muss gestehen: Ich bin begeistert! Nahezu unendliche Möglichkeiten und trotzdem eine sehr einfache Bedienung. Aber darum soll es hier nicht gehen. Vielmehr geht es um die Grundlage: Microsoft Windows Server 2003 R2. In Zeiten von Windows 2008 wird der ein oder andere einwenden, wieso noch so ein altes Betriebssystem eingesetzt wird. Dies liegt schlicht und ergreifend daran, dass sich Microsoft ISA 2006 zwar unter Windows 2008 installieren lässt, aber die Dienste starten nicht und die Software ist somit nicht nutzbar.

Ich werde hier nun hier einen Hardening Guide für Windows Server 2003 R2 veröffentlichen.

Bitte beachte: Sicherheit ist kein Zustand sondern ein ständiger Prozess! Ein System, das heute noch als relativ sicher galt kann schon morgen durch die Veröffentlichung einer Sicherheitslücke unsicher sein. Somit bedarf es einer ständigen Überwachung der IT-Infrastruktur bezüglich möglicher Sicherheitsrisiken. Bei den genannten Sicherheitsrisiken ist meist der Mensch das schwächste Glied in der Kette. Denn z.B. sein Geburtsdatum als Passwort zu benutzen ist für jemanden der sich Zutritt verschaffen will so gut wie keine Hürde.

Sichere Installation des Windows 2003 Servers

Auch bei der Installation des Servers gibt es schon einige wichtige Dinge in Bezug auf Sicherheit zu beachten. Eine saubere Installation ist nämlich eine notwendige Basis für alle weiteren Schritte. Diese werden in diesem Kapitel behandelt.

Kein Standart-Installationsverzechnis verwenden
Anstelle von C:\Windows sollte z.B.: C:\Win2k3 verwendet werden. Somit laufen viele Viren, die ohne Systemvariablen arbeiten schon ins Leere ( Oldie but goodie :-) ).

NTFS-Dateisystem für alle Partitionen einsetzen
Es sollte das NTFS-Dateisystem verwendet werden, um grundlegende Sicherheitsmechanismen auf Dateiebene zu implizieren. Des Weiteren werden erst unter NTFS Dateien, die größer als 4 Gigabyte sind unterstützt.

Keine Installation von Client-Software
Es sollte auf dem Server keine Client-Software wie z.B. Microsoft Office installiert werden. Hierdurch erhöht sich nur das Risiko einer Sicherheitslücke in der verwendeten Software. Auch das Surfen im Internet vom Server aus sollte wenn möglich vermieden werden

Installation des aktuellsten Service Packs
Ein Service Pack ist die Zusammenfassung aller bis dahin erschienenen Patches. Die Installation eines Service Packs noch bevor der Server mit dem Internet verbunden wird ist unumgänglich. Der Server sollte ohnehin erst mit dem Internet verbunden werden, wenn alle Sicherheitsratschläge aus diesem Sicherheitskonzept angewendet wurden.

Konfiguration der automatischen Updates
Dieser Punkt sollte für jeden sicherheitsbewussten Administrator selbstverständlich sein. Allerdings empfiehlt es sich, größere Updates erst auf einem Testserver zu installieren um evtl. Fehlfunktionen oder Wechselwirkungen mit anderen Systemkomponenten feststellen zu können ohne das Produktivsystem zu gefährden. Weiterhin sollten Updates dokumentiert werden, um eine spätere Fehlersuche zu beschleunigen.

Konfigurieren der Domänenweiten Zeitsynchronisation
Das Missachten dieser Option stellt zwar kein unmittelbares Risiko dar, allerdings würden Logs möglicherweise falsche Informationen liefern. Dies gilt nur, wenn sich der Server in einer Domäne oder Netzwerk befindet.

Einschalten des Remote-Desktop Zugriffs
Rechtsklick auf Arbeitsplatz -> Eigenschaften -> Reiter „Remote“ -> Häkchen bei „Remotedesktop auf diesem Computer aktivieren“
Danach bei „Remotedesktopverbindung“ alle nicht benötigten Benutzer löschen.

Installation und Konfiguration eines Virenscanners
Hierbei sollte darauf geachtet werden, dass die Virendefinitionen mindestens 1-mal täglich automatisch aktualisiert werden.

Setzen eines starken Passwortes für den lokalen Administrator
Es gelten dieselben Sicherheitsbestimmungen für Passwörter, wie sie bereits hier erläutert wurden.

Hier gehts weiter mit Teil 2 des Guides

Ratgeber für Passwörter

2009-05-08T10:35:00.003+02:00

Ein Passwort kann wie ein Schlüssel zu einem Haus angesehen werden. Mit dem Unterschied, dass ein Schlüssel nur mit verhältnismäßig großem Aufwand kopiert werden kann. Ganz anders bei Passwörtern. Hier reicht ein einfacher Blick auf die Tastatur bei der Eingabe eines Passwortes. Deswegen führt der leichteste Weg in ein System nicht etwa über Sicherheitslücken in einer Anwendung sondern so gut wie immer über ein bekannt gewordenes Passwort.

Um Euch hierbei ein wenig zu helfen, habe ich nun einige Ratschläge für Passwörter zusammengetragen:

Nutze alle verfügbaren Zeichen!
Nutze den kompletten Zeichenraum aus, der für das Passwort zur Verfügung steht. Darf das Passwort Zahlen und Buchstaben enthalten, kombiniere diese. Verwende explizit Groß- und Kleinschreibung, wenn dies möglich ist. Vermeide jedoch bei Kombinationen jegliche nachvollziehbare Systematik.

Mach es kompliziert!
Passwörter sollten für den Benutzer leicht zu merken, aber für den Fremden schwer zu erraten sein. Nimm in sensiblen Umgebungen lieber ein komplizierteres Passwort in Kauf. Nehme beispielsweise die Anfangsbuchstaben einer bestimmten Wortfolge als Passwort. Aus "Dies ist eine Wortfolge für ein Passwort" beispielsweise "DieWfeP".

Nutze die volle Länge, mindestens jedoch 8 Zeichen!
Je länger ein Passwort ist, desto schwieriger wird es, es einfach durch Ausprobieren von Zeichenfolgen herauszufinden. Darf ein Passwort beispielsweise acht Stellen haben, solltest Du auch diese acht Stellen dazu nutzen. Generell solltest Du ein Passwort mindestens acht Zeichen groß dimensionieren. Je länger, desto besser.

Keine Systematik bei Passwörtern!
Verzichte auf Systematik bei Passwörtern. Personennamen, Kosenamen, Telefonnummern, 0815, abfolgende Zahlen- und Buchstabenreihen sind unsicher. Benutze bei mehreren Passwörtern, die Du verwaltest, ebenfalls keine Systematik (z.B. alle benutzten Passwörter sind Autoteilenamen etc.).

Niemals Passwörter aufschreiben!
Passwörter gehören weder an einen Zettel, der an den Monitor geklebt wird, noch auf die Pinwand oder eine andere Stelle, die auch anderen ersichtlich sein könnte. Passwörter gehören in erster Linie in den Kopf derjenigen Personen, die sie kennen müssen und als Kopie mindestens in einen Safe.

Lies Passwörter nicht laut vor!
Gerade bei der Eingabe von Passwörtern passiert es schnell, dass man während der routinierten Zeicheneingabe das Passwort vor sich hinmurmelt. Das kann fatal sein, wenn Dir jemand, bemerkt oder unbemerkt, zuhört.

Niemals Passwörter auf dem Bildschirm stehen lassen!
Lasse Passwörter nie unbeaufsichtigt auf dem Bildschirm stehen, auch wenn sie mit Sternchen "verschlüsselt" sind. Viele Programme speichern so verschlüsselte Passworte während der Anzeige auf dem Bildschirm im Hintergrund in Klartext, außerdem gibt es Werkzeuge, die Inhalte von Texteingabefeldern anzeigen lassen können, auch von solchen, die eigentlich Passwörter verschlüsselt anzeigen.

Speicher Passwörter nicht ab!
Manche Programme bieten an, eingegebene Passwörter für die Zukunft lokal abzuspeichern. Mach dies nicht, wenn Du nicht genau weißt, dass dieses Passwort so verschlüsselt abgespeichert wird, dass es nicht mehr zurückübersetzt werden kann.

Ändere Passwörter!
Ändere Passwörter regelmäßig in unregelmäßigen Abständen. Gehe bei der Auswahl eines neuen Passwortes nicht systematisch vor (z.B. Passwörter mit Städtenamen). Ändere ein Passwort auch dann, wenn Du weißt, dass Unbefugte das Passwort kennen, auch beim leisesten Verdacht. Informiere bei Änderungen von Passwörtern nur die Personen, die die jeweiligen Passwörter kennen müssen oder verantwortlich für das betreffende System sind.

Keine Passwortlisten!
Verwende schon einmal verwendete Passwörter nie wieder und veröffentliche auch alte Passwörter nicht.

Ich hoffe mit dieser Aufstellung habe ich Euch bei dem Umgang mit Passwörtern etwas geholfen!

Neue Logindaten unter Gameranger nutzen

2009-05-08T09:38:00.002+02:00

Viele von Euch werden GameRanger warscheinlich noch nicht kennen. Hierbei handelt es sich ähnlich wie bei Hamachi um eine Plattform, über die man Spiele über das Internet spielen kann, als wäre es ein Netzwerkspiel.

Doch leider gibt es bei GameRanger einen kleinen Haken: Sollte man sich mit einem anderen Account einloggen wollen, wie der, der bei der Installation genutzt wurde hat man ein kleines Problem. Dieser lässt sich auf normalem Wege nämlich nicht mehr ändern.

[Schritt 1] Herausfinden wohin GameRanger installiert wurde

Dies war in meinem Fall
%Homedrive%/%Appdata%/Gameranger

Für was %Homedrive% und %Appdata% steht könnt Ihr folgendermaßen herausfinden:

Start > Ausführen > "cmd" eingeben
Danach öffnet sie die Eingabeaufforderung von Windows. Dort gebt Ihr als Befehl set ein. Windows listet euch nun bereitwillig alle hinterlegten Variablen auf. Da der Ordner "Anwendungsdaten" aber normalerweiße nicht sichtbar ist, müsst Ihr dies folgendermaßen ändern:

Arbeitsplatz öffnen > Extras > Ordneroptionen
Dort wechselt Ihr nun oben auf den Reiter Ansicht. Hier aktiviert Ihr nun unter dem Punkt Versteckte Dateien und Ordner die Option Alle Dateien und Ordner anzeigen.

Nun müsstet Ihr unter C:\Dokumente und Einstellungen\DeinUsername einen Ordner namens Anwendungsdaten sehen. In diesem befindet sich ein Ordner GameRanger. Dieser wiederrum beinhaltet einen Ordner namens GameRanger Prefs.

Wenn Ihr diesen Ordner nun umbenennt oder löscht, so wird euch GameRanger beim nächsten Start wieder danach fragen, welche Login-Daten ihr benutzen wollt und das Problem ist gelöst :)

PoC: Alle Clients in einem Windows Netzwerk den Internetzugriff kappen

2009-04-29T17:37:00.003+02:00

Mehr durch Zufall als durch probieren kam ich zu folgendem Sachverhalt:

Angenommen wir haben ein Firmennetzwerk, dass durch einen Microsoft ISA Server geschützt ist. Dieser dient als Proxy für alle Clients, die geschützt hinter ihm liegen. Soweit so gut. So lassen sich zwar z.B. Webinhalte super filtern allerdings hat Zentralisierung wie so oft auch seine Nachteile.

Angenommen die ISA-Firewall hat die IP 192.168.1.123, die ihr statisch (fest) zugewiesen wurde. Was würde nun passieren wenn wir einem Client in diesem Netzwerk genau diese IP auch statisch zuordnen würden? Richtig geraten! Der gute alte "IP-Adressen Konflikt" tritt auf. Somit können Pakete nicht mehr ordnungsgemäß zugestellt werden und der Internetzugang für alle Clients ist bis zur Behebung dieses Zustandes nicht mehr möglich.

Doch wie behebt man dieses Problem am besten? Normalerweiße denkt man bei Windows-Systemen als erstes daran: "Rechner neustarten, wird danach schon wieder gehen!". Ganz so leicht ist es aber diesmal nicht :-)

Lösung: Ihr weißt euren Netzwerkadministrator eures Vertrauens freundlich aber bestimmt darauf hin, dass Ihr während der Arbeitszeit leider nicht mehr auf eBay herumsurfen könnt, da eure Internetverbindung "spinnt". Anschließend gebt Ihr ihm freundlich wie Ihr seid einen kleinen Tipp: Er soll doch mal bitte seinen DHCP-Server untersuchen (Den Tipp, dass es an zwei gleichen IP's liegt behaltet ihr natürlich für euch! Ein Tipp ist genug :-) ). Sollte er technisch versiert sein, wird er selbst darauf kommen was zu tun ist !

Winamp Visualisierung als Desktophintergrund

2009-04-26T14:54:00.002+02:00

Unter Windows XP und sicherlich auch Vista lässt sich die Winamp Visualisierung so einstellen, dass sie als Bildschirmhintergrund auf dem Desktop läuft.

Benötigt wird:

Winamp und natürlich Windows XP.

Nachdem Ihr nun Winamp heruntergeladen und installiert habt, startet ihr es wie gewohnt über die Verknüpfung auf dem Desktop.

Danach startet Winamp und es befindet sich unten in der Taskleiste.

Nun lasst Ihr euch Winamp anzeigen falls noch nicht geschehen, so
dass es im Vordergrund ist und drückt:

STRG + K

um folgende Visualisierung auszuwählen:

MilkDrop 2.0e [vis_milk2.dll]

Danach klickt Ihr auf 'Schließen'. Sollte diese Visualisierung nicht bei euch aufgeführt sein benutzt ihr warscheinlich eine zu alte Winamp-Version.

Nachdem ihr die richtige Visualisierung ausgewählt habt, startet Ihr sie mit:

STRG + Umschalt (Die Taste über Strg) + K

Nun sollte die Visualisierung in einem kleinen Fenster starten. Fast geschafft!

Nun nur noch rechtsklicken auf die Visualisierung und Desktop-Modus aktivieren. Alternativ könnt ihr auch

ALT + D

drücken. Nun sollte die Visualisierung als Bildschirmhintergrund laufen.

Viel Spaß wünscht,

Nerdbert

"Unbekanntes Gerät" unter Windows

2009-04-26T14:06:00.000+02:00

Wer kennt das nicht: Man installiert sein Windows neu und möchte danach die passenden Treiber installieren. Doch welchen Treiber sollte man benutzen wenn Windows im Geräte Manager ein "Unbekanntes Gerät" angezeigt wird?

Dies deutet darauf hin, dass Windows nicht selbsständig identizieren konnte, um welches Gerät es sich tatsächlich handelt. Allerdings bietet uns der Geräte Manager einige Informationen, die uns dabei helfen, das Gerät zu identifizieren.

Den Geräte Manager kann man einfach starten indem man folgende Tastenkombination betätigt:
[WINDOWS-Taste] + [PAUSE]

Danach öffnet man den Reiter "Hardware" und startet dann den Geräte Manager. Ein Unbekannts Gerät erkennt man an dem Symbol eines "?" auf gelbem Hintergrund.
Dieses wählt man nun an und öffnet das Menü mit einem Rechtsklick und wählt dort Eigenschaften. Dort geht man nun auf den Reiter Details und wählt in dem Dropdown-Menü den Punkt Geräteinstanzkennung. Dort sehen wir nun einen Eintrag der z.B. so aussieht:

PCI\VEN_1002&DEV_4E50...

VEN steht hierbei für den Vendor (Hersteller) in diesem Falle steht 1002 für ATI. DEV bezeichnet den Device (Gerät). Hier ist es eine Mobility Radeon 9700. Diese scheinen in Windows eindeutig vergeben zu werden. Diese Daten können nun dazu verwendet werden, eine Google-Recherche durchzuführen. Gibt man nun z.B. bei Google VEN_1002&DEV_4E50 ein, findet man sofort Suchergebnisse, mit der betreffenden Hardware. Eine weitere Möglichkeit diese Daten zu verwenden, ist nicht passende Treiber so umzuschreiben, dass sie die eingebaute Hardware unterstützen. Dies erkläre ich aber ein anderes mal :)

Liebe Grüße

Nerdbert

OTRS an LDAP anbinden

2009-04-26T12:45:00.000+02:00

Vor kurzem musste ich das Open Source Ticket System OTRS einführen. Die Installation an sich auf einem Ubuntu-Linux Server verlieg problemlos. Jedoch wurde noch gewünscht das Ticket System an eine bestehende Active Directory Datenbank anzubinden. Das hat den Vorteil, dass sich die Anwender (in diesem Fall die Mitarbeiter des Unternehmens) nicht nochmal zusätzlich anmelden müssen und ihre Windows Logindaten benutzen können.

Allerdings verlief das ganze nicht problemlos. Alle auffindbaren Quellen zu diesem Thema führten für mich nicht zum Erfolg. Deswegen werde ich hier nun kurz den Abschnitt meiner Config.pm posten, der es schlussendlich ermöglichte:

   $Self->{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::LDAP';
   $Self->{'Customer::AuthModule::LDAP::Host'} = '192.168.1.11'; 
   $Self->{'Customer::AuthModule::LDAP::BaseDN'} = 'dc=domain, dc=com';
   $Self->{'Customer::AuthModule::LDAP::UID'} = 'sAMAccountName';
   $Self->{'Customer::AuthModule::LDAP::SearchUserDN'} = 'Suchbenutzer';
   $Self->{'Customer::AuthModule::LDAP::SearchUserPw'} = 'Suchbenutzer_Passwort';

$Self->{CustomerUser} = {
    Module => 'Kernel::System::CustomerUser::LDAP',
    Params => {
      Host => '192.168.1.11',
      BaseDN => 'dc=domain, dc=com',
      SSCOPE => 'sub',
      UserDN => 'Suchbenutzer',
      UserPw => 'Suchbenutzer_Passwort',
    },
    CustomerKey => 'sAMAccountName',
    CustomerID => 'mail',
    CustomerUserListFields => ['sAMAccountName', 'cn', 'mail'],
    CustomerUserSearchFields => ['sAMAccountName', 'cn', 'mail'],
    CustomerUserPostMasterSearchFields => ['mail'],
    CustomerUserNameFields => ['givenname', 'sn'],
    Map => [
      # note: Login, Email and CustomerID needed!
      # var, frontend, storage, shown, required, storage-type
#       [ 'UserSalutation', 'Title', 'title', 1, 0, 'var' ],
#      [ 'UserFirstname', 'Firstname', 'givenname', 1, 1, 'var' ],
#      [ 'UserLastname', 'Lastname', 'sn', 1, 1, 'var' ],
      [ 'UserLogin', 'Login', 'sAMAccountName', 1, 1, 'var' ],
      [ 'UserEmail', 'Email', 'mail', 1, 1, 'var' ],
      [ 'UserCustomerID', 'CustomerID', 'mail', 0, 1, 'var' ],
#       [ 'UserPhone', 'Phone', 'telephonenumber', 1, 0, 'var' ],
#       [ 'UserAddress', 'Address', 'postaladdress', 1, 0, 'var' ],
#       [ 'UserComment', 'Comment', 'description', 1, 0, 'var' ],
    ],
  };

Host wird mit eurem Active Directory Server ersetzt. Es ist sicherer hierbei die IP und nicht einen DNS-Namen einzugeben.

BaseDN wird folgendermaßen ersetzt: Angenommen eure Domain heißt 'firma.lokal' müsse es dc=firma dc=lokal lauten.

UID darf nicht verändert werden. Diese ist zur korrekten Funktion unerlässlich.

Als SearchUserDN könnt ihr einen x-beliebigen Active Directory Benutzer wählen. Wir haben extra einen neuen eingerichtet und ihm ein eigenes Exchange-Postfach verpasst, damit man E-Mails an diesen fiktiven User schreiben kann und sie sofort als Ticket erfasst werden.

Das wars auch eigentlich schon ! Hoffe euch geholfen zu haben.

Nerdbert has just entered #www

2009-04-24T18:31:00.000+02:00

Hallo!

Willkommen auf meinem Blog! Da ich schon lange mit dem Gedanken gespielt habe mich endlich mal ansprechend im WWW zu vertreten kam ich auf die Idee einen Blog zu veröffentlichen. Soweit so gut. Doch was will ich Euch hier mitteilen?

Im Grunde genommen das was ich am besten kann:
Tutorials zu verschiedenen IT-Bereichen anbieten!

Da ich als IT-Kaufmann beschäftigt bin und im Moment mit dem Aufbau der IT-Infrastruktur betraut bin lässt es sich nicht vermeiden mich in verschiedene Gebiete einarbeiten zu müssen.
Hierzu zählen z.B. Microsoft Windows 2003 und das Hardening hierzu. Weiterhin z.B. das absichern des Netzwerkes mittels Microsoft ISA 2006.

Ein weiteres Spezialgebiet von mir ist das Open Source Ticket System "OTRS". Auch hierüber werde ich mich hier zukünftig ausgiebig auslassen :-)

Viel Spaß schonmal wünscht Euer

Nerdbert