Archive for the ‘Network’ Category
Hochverfügbarkeit

Immer wieder kommt die Frage auf was zu tun ist, um ein System hochverfügbar (HA) zu bekommen. Daher hier mal ein paar Punkte die zu beachten sind.

Geografische Trennung: Um eine hohe Verfügbarkeit eines Systems garantieren zu können, muss ein System vollständig redundant aufgebaut sein und alle notwenigen Komponenten in zwei geografisch getrennten Rechenzentren vorhanden sein. Optimal ist hier ein Cluster mit jeweils einem aktiven Knoten in einem der Rechenzentren. Es sollte dabei jedoch sicher gestellt sein, dass jeder Knoten für sich in der Lage ist die volle Last tragen zu können. Wichtig ist auch, dass alle notwendigen Dienste wie z. B. Active Directory, DNS, DHCP oder auch Zertifikatsdienste in beiden Lokationen funktionsfähig sind.

Internetanbindung: Muss die Anwendung extern zur Verfügung stehen oder bestehen Netzwerkverbindungen zu anderen Lokationen, so sollte die Anbindung der Rechenzentren über eine redundante Netzwerkverbindung realisiert werden. Hierbei sollten möglichst unterschiedliche Provider mit eigenen Backbones verwendet werden.

Netzwerkinfrastruktur: Um eine hohe Verfügbarkeit sicher zu stellen, müssen auch alle internen Netzwerkkomponenten wie z. B. Router, Switches und Firewalls redundant ausgelegt sein bzw. mehrere Routen zu einem Ziel bestehen. Server sollten grundsätzlich über zwei Netzwerkkarten mit dem eigenen Netzwerk verbunden sein.

Stromversorgung: Ohne Strom geht nichts. Daher muss man hier bei der Planung besonders gewissenhaft vorgehen. Zuerst wird sicher gestellt, dass die Anbindung der Rechenzentren durch zwei Stromversorger mit eigener Infrastruktur erfolgt. Zudem sollte intern sicher gestellt werden, dass eine ausreichende Menge an USV’s vorhanden ist. Von den USV’s ausgehend sollten die Server über zwei getrennte Stromkreise (z. B. Boden und Decke) angebunden werden (redundante Netzteile sollten zwischenzeitlich Standard sein). Um längeren Ausfällen vorzubeugen ist das vorhandensein von Notstromgeneratoren unabdingbar. Für die Versorgung der Generatoren mit z. B. Diesel, ist ein Abkommen (inkl. Reaktionszeit) mit einem Energieversorger notwendig, der im Fall der Fälle schnell liefern kann.

Feuer: Da ein Feuer in kurzer Zeit sehr große Teile der eigenen Infrastruktur zerstören kann, ist sparen hier keine gute Idee. Eine ausreichende Menge an Feuerlöschern gehört dabei zum guten Ton. In richtigen Rechenzentren sollte zudem eine aktive Feuerbekämpfung (und natürlich Meldung) installiert sein. Gas-Löschanlagen stellen hierbei die für die elektrischen Systeme verträglichsten Installationen da. Es sollte hierbei immer genügend Gas für min. 2 Löschungen vorgehalten werden (Feuer können wieder aufflammen). Des Weiteren sollte man seinen Mitarbeitern zu Liebe optische und aktustische Warnsysteme installieren, die bei Auslösung der Löschung aktiviert werden. Will man ganz sicher gehen gibt es zusätzlich noch die Möglichkeit dem Serverraum permanent Sauerstoff zu entziehen. Menschen (ausgenommen z.B. schwangere Frauen und Herzkranke) können in solchen Räumen ganz normal arbeiten – Feuer können jedoch (fast) nicht ausbrechen.

Backup: Redundanz ist kein Ersatz für ein Backup. Ein versehentlich ausgeführter Befehl z. B. “drop table xy” wird auf einem redundaten System auf beiden Seiten ausgeführt und würde damit die Daten in der entsprechenden Tabelle löschen. Ohne Backup steht man dann vor einem sehr großen Problem. Beim Backup selbst ist zu beachten, dass man diese nicht nur in einem Rechenzentrum aufbewahren sollte, sondern diese am besten an zwei Stellen lagert.

Klimatisierung: Ein Rechenzentrum muß gekühlt werden. Insebesondere moderne Systeme wie Bladecenter geben sehr viel Wärme pro qm ab. Ein Ausfall der Klimatisierung hat somit mittelfristig i. d. R. auch den Ausfall des Rechenzentrums zur Folge. Somit sollten auch die Klimageräte redundant ausgelegt sein.

Testen, Testen, Testen: Ganz wichtig für die Garantie einer hohen Verfügbarkeit  ist das Testen. Das fängt bei Lasttests für die Stromgeneratoren und die USV’s an und hört beim Wiederherstellungstest von Backups noch lange nicht auf. Ganz wichtig ist auch die Dokumentation der Tests.

Anonymous SMTP Verbindung auf einen Exchange 2007

Hi,

beim einrichten meines neuen Exchange 2007 hatte ich gleich das Vergnügen mich etwas näher mit der PowerShell zu beschäftigen. Einige (für mich wichtige) Befehle sind nämlich nur noch auf diesem Weg erreichbar. Folgender Aufbau: Ich erhalte meine Mails direkt via SMTP (MX Eintrag in meiner Maildomäne). Sicherheitsbewusst wie ich bin werden die Mails von einem System in meiner DMZ (ja, ich habe privat eine zweistuffige Firewall) entgegen genommen und dann an meinen Exchange weiter gegeben. Das Problem war nun, den Exchange Server dazu zu bekommen die Mails auch anzunehmen. Alle Einstellungen auf dem HubTransport Server bzw. dessen Receive Connectoren brachte leider nichts – mails gingen nicht durch. Nach ca. 3 Stunden klicken und googeln fand ich dann folgenden Artikel auf den technet Seiten:

http://technet.microsoft.com/en-us/library/bb232021.aspx

Dieser, zusammen mit den anderen ergoogelten Informationen brachten dann folgende Lösung des Problems (alles cmdlets):
# Erstellt einen neuen receive connector mit dem Namen “Firewall SMTP Proxy” auf dem Exchange Server “JSW006″ Die Firewall von der die Mails kommen hat die IP 10.10.0.1 und die Maildomain wäre hier schmidtjohannes.de

new-ReceiveConnector -Name 'Firewall SMTP Proxy' -Usage 'Custom' -Bindings '0.0.0.0:25' -Fqdn 'schmidtjohannes.de' -RemoteIPRanges '10.10.0.1' -Server 'JSW006'

# Setzt die PermissionGroups auf Anonymous

set-ReceiveConnector -identity “Firewall SMTP Proxy″ -PermissionGroups AnonymousUsers

# Ordnet dem Connector die Notwendigen Rechte zu

Get-ReceiveConnector "Firewall SMTP Proxy" | Add-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "Ms-Exch-SMTP-Accept-Any-Recipient"

Die ersten beiden Aufgaben könnte man auch mit etwas klicken über die GUI erledigen. Den letzten kann man nur als cmdlet ausführen.

Einmalpasswörter

Hi,

Einmalpasswörter sind zwischenzeitlich insbesondere in Form von RAS Tokens in vielen Firmen sehr verbreitet. Das Einsatzgebiet ist dabei primär die authentifizierung für eine externe Einwahl z. B. via VPN. Heise Security hat vor kurzem einen guten Artikel mit Beispielszenarien für den SoHo Einsatz dieser Technik vorgestellt:

http://www.heise.de/security/artikel/87555

 Viel Spass beim lesen!

Security Logging und Monitoring

Hallo!

Also wenn das mit meinen HowTo’s so weiter geht dann müssen wir ServerHowTo bald in JohannesHoTo umtaufen. Mein neuestes Dokument beschäftigt sich mit dem, bei allen Administratoren, sehr beliebten Thema „Security Logging und Monitoring“. In der aktuellen Version geht es weniger um die tatsächliche Implementierung einer bestimmten Technologie. Es geht vielmehr um die Grundlegenden Entscheidungen wie und was geloggt und gemonitort werden sollte sowie welche Techniken dafür verwendet werden können. Sobald ich etwas mehr Zeit in meinem TestLab verbringen kann (plane gerade meinen Umzug) werde ich die Implementierung am Beispiel vom MOM als HowTo veröffentlichen.

ServerHowTo: Security Logging und Monitoring

Fragen und Feedback sind wie immer willkommen. Das Forum sowie dieser Blog stehen Ihnen hierfür gerne zur Verfügung!

Patchmanagement

Hallo!

… und weiter geht’s. Dieses Mal beglücke ich Sie mit einem HowTo zum Thema „Patchmanagement“. Die technische Implementierung mit Hilfe von WSUS wurde von einem MCSEboard.de Expert bereits dokumentiert.

ServerHowTo: Windows Server Update Services

Ich kümmere mich daher ein weiteres Mal um die ebenso wichtigen Grundsätze und Prozesse die hinter einem guten Patchmanagement stehen sollten. Viel Spaß beim lesen!

ServerHowTo: Patchmanagement

Auch hier gilt Anregungen, Wünsche sowie Diskussionen sind gerne gesehen und können sowohl hier wie auch im MCSEboard.de an mich gerichtet werden.