Archiv der Kategorie: Sicherheit

Wlan mit Zertifikaten: Migration auf neuen Server

Es gibt verschiedene Möglichkeiten, wie sich ein Client an einem WLAN Accesspoint authentifizieren kann. Wir haben es so umgesetzt, dass die Laptops ein Zertifikat erhalten, mit dem sie sich an einem Radiusserver ausweisen müssen, damit sie Zugang ins Netzwerk erhalten.

wlan mit radius

  1. Der Laptop bekommt über eine Gruppenrichtlinie ein Zertifikat vom Zertifikatserver. Dazu muss der Laptop über ein Kabel am Netzwerk angeschlossen sein (z.B. beim Neuaufsetzen).
  2. Der Laptop stellt eine Verbindung mit dem Accesspoint her und weist sich mit seinem Zertifikat aus.
  3. Der Accesspoint gibt die Anfrage mit dem Zertifikat an den Radiusserver weiter. Dieser heisst bei einem Windowsserver NPS und muss nicht auf dem gleichen Server wie die PKI laufen.
  4. Der Radiusserver bestätigt dem Accesspoint die Gültigkeit des Zertifikates. Nun kann der Laptop eine Verbindung ins Netzwerk herstellen.

Diese Lösung hat diverse Vorteile. Zum einen lässt sie sich zentral verwalten. Ein weiterer Vorteil ist, dass niemand ein Passwort eingeben muss, dass vergessen oder weitergegeben werden kann. Ausserdem gilt diese Lösung als sehr sicher.

Migration Zertifikatserver

Wie man eine bestehende CA (Certificate Authority) migriert, wird auf dieser Technet Seite beschrieben. Auf dem Blog von Rachfahl findet man eine bebilderte Schritt-für-Schritt Anleitung. Dabei sollte der neue Server den gleichen Namen wie der alte haben. Ausserdem sollte der alte Server entfernt werden, bevor der neue eingesetzt wird. Wenn sich ein Problem ergeben sollte, ist der Rückweg versperrt. Auf dem Blog von Rachfahl wird die alte Zertifizierungsstelle zwar erst entfernt, nachdem die neue aufgesetzt wird, aber dies entspricht nicht dem empfohlenen Vorgehen gemäss der Technet Seite. Wenn man nach der Installation der neuen Zertifizierungsstelle die alte entfernt, könnte dies zu Problemen im Active Directory führen. Wie man die Einträge der CA im Active Directory findet, ist hier beschrieben. So habe ich mich aus diversen Überlegungen dazu entschieden, einen neuen Zertifikatserver aufzusetzen und den alten gar nicht zu migrieren.

Neuer Zertifikatserver

Gemäss diesem Technet-Blog-Beitrag spricht nichts dagegen, zwei PKI’s parallel zu betreiben. Aus den oben angetönten Gründen habe ich mich für diesen Weg entschieden. So habe ich also einen weiteren Server in der Domäne erstellt (diesmal kein Domänencontroller).

Dazu muss man eine neue Rolle hinzufügen.

image

image

image

Hier kann man die Zertifikatsdienste auswählen und muss diese dann auch noch bestätigen.

image

Nach diversen Klicks auf “Weiter” habe ich als Rollen “Zertifizierungsstelle” und “Zertifizierungsstellen-Webregistrierung” ausgewählt.

image

image

Nach erfolgter Installation wird im Servermanager angezeigt, dass man die Zertifikatsdienste noch konfigurieren muss.

image

image

image

Als Installationstyp wählt man Unternehmenszertifizierungsstelle und danach Stammzertifizierungsstelle. Dies genügt für unsere Zwecke. Wer sich dafür interessiert, wie man eine deutlich komplexere Struktur (multi-tier hierarchy) einsetzt findet in diesem Technetblog einen guten Einstieg.

image

image

image

image

Beim Namen für die Zertifizierungsstelle wird ein Name vorgeschlagen. Diesen kann man ändern, was ich aber nicht gemacht habe.

image

Bei der Gültigkeitsdauer habe ich grosszügig 10 Jahre genommen. So bekommen wir sicher keine Probleme bis zum nächsten Serverwechsel.

image

Nach ein paar “Weiter” Klicks ist die Konfiguration beendet.

image

Zertifikate automatisch verteilen

Die Zertifikate lassen sich automatisch über eine Gruppenrichtlinie verteilen.

Computerkonfiguration –> Richtlinien –> Windows-Einstellungen –> Sicherheitseinstellungen –> Richtlinien für öffentliche Schlüssel –> Zertifikatdienstclient – Automatische Registrierung

image

Computerkonfiguration –> Richtlinien –> Windows-Einstellungen –> Sicherheitseinstellungen –> Richtlinien für öffentliche Schlüssel –> Zertifikatdienstclient – Zertifikatregistrierungsrichtlinie

image

Computerkonfiguration –> Richtlinien –> Windows-Einstellungen –> Sicherheitseinstellungen –> Richtlinien für öffentliche Schlüssel –> Einstellungen der automatischen Zertifikatanforderung

Hier ein Zertifikat auswählen, das automatisch verteilt werden soll.

image

Tipp: Wenn man eine eigens erstellte Vorlage verwenden möchte (statt der Standardvorlage Computer), muss man die Schemaversion der Vorlage von 2 auf 1 ändern. Dazu kann man ADSI-Edit verwenden.

image

WLAN Profile verteilen

Da wir keine Passwörter eingeben, sondern uns mit einem Computerzertifikat authentifizieren wollen, verwenden wir ein PEAP-TLS Verbindungsprofil, das wir über eine Gruppenrichtlinie verteilen.

Computerkonfiguration –> Richtlinien –> Windows-Einstellungen –> Sicherheitseinstellungen –> Drahtlosnetzwerkrichtlinien (IEEE 802.11)

Durch einen Rechtsklick kann man eine neue Richtlinie hinzufügen.

image

Nun kann man der Richtlinie einen Namen geben und ein Infrastrukturprofil hinzufügen.

image

Hier kann man für ein Profil die entsprechenden SSID Namen hinzufügen.

image

Als Sicherheitsmethoden wird bereits WPA2-Enterprise mit AES Verschlüsselung vorgeschlagen, was im Moment die beste Sicherheit bietet.

Bei “Authentifizierungsmodus” wählt man “Computerauthentifizierung”. Ansonsten verliert der Computer die Verbindung, sobald sich jemand anmeldet. Dies könnte man umgehen, indem man auch Zertifikate für die Benutzer verteilen würde, was aber für unseren Einsatz nicht wirklich etwas bringt.

Bei “Netzwerkauthentifizierungsmethode” wählt man “Microsoft: Smartcard- oder anderes Zertifikat”. Durch einen Klick auf “Eigenschaften” kann man das Zertifikat angeben. Hier kann man einfach den Vorschlag “Zertifikat auf diesem Computer verwenden” akzeptieren. Unten muss man noch die Stammzertifizierungsstelle auswählen.

image

Radius Server konfigurieren

Die Clients bekommen nun also automatisch über eine Gruppenrichtlinie ein Zertifikat von der Zertifizierungsstelle (CA) und die passenden WLAN Einstellungen. Nun muss noch der Radiusserver (bei Microsoft Netzwerkrichtlinienserver NPS) konfiguriert werden. Dieser meldet den Accesspoints ob der Client eine Verbindung herstellen darf oder nicht (vgl. Grafik ganz oben).

Um NPS zu installieren, muss man über den Servermanager eine neue Rolle Netzwerkrichtlinien- und Zugriffsdienste hinzufügen.

image

image

image

Auf dem Radiusserver muss man nun die Clients (Accesspoints oder die Managementstation für die AP’s) hinzufügen und eine Richtlinie erstellen.

Um einen Client hinzuzufügen, macht man einen Rechtsklick auf “RADIUS-Clients” und wählt “Neu”.

image

Nun kann man Anzeigename, IP-Adresse und den gemeinsamen geheimen Schlüssel eintragen. Selbstverständlich muss man auf der Accesspoint-Seite die IP dieses Servers eingeben (resp. in meinem Fall anpassen) und den gleichen Schlüssel eintragen.

image

Mit einer Richtlinie kann man angeben, welche Voraussetzungen erfüllt sein müssen, damit der Radiusserver das OK für die Verbindung gibt. Man kann die Richtlinien manuell erstellen oder über den Szenario Assistenten erstellen lassen. Dazu wählt man bei “Erste Schritte” bei Standardkonfiguration “Radius-Server für drahtlose oder verkabelte 802.1X-Verbindungen” aus und klickt auf “802.1X konfigurieren”.

image

Im ersten Fenster wählt man “Sichere Drahtlosverbindungen” und gibt einen Namen für die Richtlinien.

image

Im nächsten Fenster könnten man die Radius-Clients hinzufügen. Einen habe ich schon vorher manuell hinzugefügt (vgl. oben).

image

Bei der Authentifizierungsmethode wählt man “Microsoft: Smartcard- oder anderes Zertifikat”

image

Nun kann man noch Benutzergruppen angeben. Dies habe ich nicht gemacht. Alle Computer mit gültigem Zertifikat dürfen sich bei uns über WLAN am Netzwerk anmelden, unabhängig vom angemeldeten Benutzer.

image

Auch Datenverkehrssteuerelemente werden in unserem Fall nicht benötigt.

image

Und so werden nun eine Verbindungsanforderungsrichtlinie und eine Netzwerkrichtlinie erstellt, die man manuell überprüfen kann.

image

Wichtig ist nun noch, dass man die Radius-Clients auch so umstellt, dass sie sich mit dem neuen Radiusserver verbinden.

Zusätzliche Aufgaben bei einer Ablösung eines alten Servers

So wie das oben beschrieben ist, kann man WLAN mit Zertifikaten neu aufsetzen. Wenn man aber wie ich einen alten Server ohne Unterbruch der WLAN Verbindungen ablösen möchte, gibt es noch ein paar Dinge, die man beachten sollte.

Zertifikat des Radiusservers

Wir haben bei der Verteilung der WLAN-Profile über Gruppenrichtlinien angegeben, dass die Identität des Servers über dessen Zertifikat überprüft werden soll. Wenn wir nun den Radiusserver wechseln, weist sich der neue mit dem neuen Zertifikat aus, was vom Client nicht automatisch akzeptiert wird. Daher muss man beim WLAN Profil beide Server als vertrauenswürdige Stammzertifizierungsstellen angeben.

image

Damit der Client diese Änderung bei den Gruppenrichtlinien erfährt, muss er einmal am Netzwerk gestartet werden. Dies bedeutet, dass man einen Zeitpunkt festlegen und dies den Mitarbeitern mitteilen muss, bis zu dem alle Laptops einmal gestartet werden müssen. Falls ein Laptop in dieser Zeit nicht gestartet wurde, kann er danach nicht mehr automatisch eine Verbindung mit dem Netzwerk herstellen. Am einfachsten startet man ihn dann einmal mit eingestecktem Netzwerkkabel, damit er die Einstellung erhält und danach auch wieder automatisch eine Verbindung über WLAN herstellt.

Zertifikate der Clients

Da die beiden Zertifizierungsstellen (CA’s) im Active Directory eingetragen sind, vertrauen sie einander und auch den Zertifikaten voneinander. So spielt es also keine Rolle, von welcher Zertifizierungsstelle das Zertifikat des Clients ausgestellt wurde.

Solange die alte CA auch noch vorhanden ist, können beide Zertifikate ausliefern. Es kann aber nur eine CA Zertifikate ausliefern, die auch die entsprechende Zertifikatvorlage besitzt. Um die alte CA davon abzuhalten, neue Zertifikate auszuliefern, kann man also einfach die entsprechende Vorlage auf der alten CA löschen (in meinem Fall war das die Vorlage “Computer”).

image

Besser wäre eine duplizierte Vorlage, wie ich sie neu verwende. Dazu dupliziert man bei den Zertifikatvorlagen die Vorlage Computer.

image

 

Der neuen Vorlage habe ich den Namen “ComputerzertifikatWLAN” gegeben.

image

Wenn man nun nur bei der lokalen Zertifizierungsstelle des neuen Servers die Vorlage aktiviert, liefert auch nur dieser Zertifikate dieser Vorlage aus.

image

image

Sobald also alle Zertifikatvorlagen von der alten Zertifizierungsstelle gelöscht sind werden die Zertifikate von der neuen Zertifizierungsstelle ausgestellt. Wenn auf der neuen Zertifizierungsstelle die neu erstellte Vorlage die einzige für die Clientauthentifizierung ist, bekommen nun alle Clients ein solches Zertifikat, sobald sie ein neues anfordern.

Die alten Zertifikate bleiben aber bestehen, bis sie ablaufen, bei mir wäre das ein Jahr. Sinnvoll wäre es also, wenn die Clients schon vor Ablauf des Zertifikats ein neues beziehen, damit man den alten Server deinstallieren kann.

Die Zertifikate vom Computer kann man in einer Mangement Konsole (MMC) ansehen (mmc –> Datei –> Snap-In hinzufügen/entfernen –> Zertifikate –> Computerkonto) oder unter Windows 8 certlm.msc starten.

Wenn man einen Rechtsklick unter “Zertifikate (Lokaler Computer)” –> “Eigene Zertifikate” –> “Zertifikate” macht, kann man “Alle Aufgaben” –> “Neues Zertifikat anfordern…” auswählen und sich ein neues Zertifikat ausstellen lassen.

image

image

Man kann dies automatisieren, indem man bei den Zertifikatvorlagen die gewünschte auswählt und über einen Rechtsklick “Alle Zertifikatinhaber erneut registrieren” lässt.

image

Dies funktioniert aber leider nur mit duplizierten Vorlagen, die von mir damals verwendete Standard-Vorlage “Computer” lässt dies nicht zu.

Man kann auch mit dem Befehl “certreq” erreichen, dass ein neues Zertifikat von den Clients bezogen wird:

certreq -q -enroll -machine ComputerzertifikatWLAN

Diesen Befehl könnte man z.B. als renewcertificate.bat abspeichern und über SCCM an alle Clients verteilen. Windows 7 bringt aber eine Meldung wegen fehlender Berechtigung (obwohl die Berechtigung über den Weg mit der graphischen MMC ausreicht und der gleiche Befehl unter Windows 8 problemlos funktioniert).

Wenn man eine neue Vorlage erstellt und diese über die automatische Zertifikatanforderung verteilt, wird diese beim nächsten Start bezogen. So bekommen alle Computer schnell ein Zertifikat vom neuen Server. Somit kann demnächst der alte Server deinstalliert werden…

weitere Objekte im ADSI-Editor anzeigen

Um Objekte im Active Directory anzuzeigen, verwendet man oft den ADSI-Editor (adsiedet.msc).  Standardmässig werden aber nicht alle Objekte angezeigt. So sieht man z.B. die Objekte nicht,, die von einer CA (Zertifizierungsstelle) im Active Directory eingetragen werden, wenn man eine PKI (Public-Key-Infrastruktur) einsetzt. 

CN=Public Key Services, CN=Services, CN=Configuration, DC=<forestRootPartition>.

Um diese Einträge anzeigen zu lassen, muss man sich mit der Konfigurations-Partition verbinden. Dazu macht man einen Rechtsklick auf ADSI-Editor und wählt “Verbindung herstellen…”

image_thumb

Nun wählt man unter “Bekannten Namenskontext auswählen:” den Eintrag “Konfiguration” aus.

image_thumb[1]

Unter Services –> Public Key Services findet man die einzelnen Container, die von Bedeutung für eine PKI sind. Die Bedeutung der einzelnen Container ist in diesem Technet Beitrag beschrieben.

image_thumb[2]

Sophos UTM veröffentlicht keine Server mehr nach Update

Nach einem Update unserer Sophos UTM auf die Version 9.204-20 funktionierten alle von uns veröffentlichten Webseiten nicht mehr. Auch konnten die Mails nicht mehr über ActiveSync synchronisiert werden. Eine Recherche brachte mich dann auf diesen Beitrag im Sophos Forum, der mich dann zu diesem Knowledgebase Beitrag führte. 

Man muss also bei “Web Application Firewall” bei der Registerkarte “Firewall Profiles” das Häklein bei “Common Threats Filter” entfernen und dies für alle Firewallprofile wiederholen, bei denen das Häklein gesetzt ist.

image

Danach müssen alle virtuellen Webserver deaktiviert und wieder aktiviert werden.

image

Am Schluss kann man die Häklein bei “Common Threats Filter” wieder setzen.

Schwachstelle in OpenSSL

Wie man in diversen Medien erfahren konnte, wurde eine Schwachstelle in OpenSSL bekannt, die schon längere Zeit existiert. Weitere Informationen finden sich z.B. bei Heise oder bei Melani.

Auch wir waren betroffen, da unsere Firewall (Sophos UTM) auf Linux basiert und OpenSSL implementiert hat. Da wir z.B. unseren Exchangeserver mit der Sophos als Reverse Proxy veröffentlichen, ist auch diese Veröffentlichung betroffen.

Diverse Seiten bieten an, eine Verbindung auf den Heartbleed Bug zu überprüfen, so auch http://filippo.io/Heartbleed/.

image

Sophos hat aber sehr zeitnah Patches angeboten, die das Problem beheben. Nach dem Einspielen dieser meldet auch der Test, dass unser Herz nicht mehr ausblutet Zwinkerndes Smiley.

image

Ausgehende Ports auf der Firewall testen

Eine unserer Primarschulen plant ein Radioprojekt mit PowerUp Radio. Neben einer UKW Übertragung gibt’s auch einen Livestream auf der Webseite. Um das zu realisieren, werden gemäss Anfrage die TCP Ports 80, 81 und 5901 benötigt (NACHTRAG: Neu sind es die Ports 8000, 8001 und 5901). Diese müssen auf der Firewall geöffnet werden. Unser Problem ist, dass nach unserer Firewall auch noch die Firewall der Swisscom vom Projekt “Schulen ans Netz” steht.

Auf unserer Firewall (Sophos UTM) habe ich zwei “Service Definitions” und eine Gruppe für die beiden benötigten Ports erstellt.

image

Danach kann man eine Firewall Regel für die beiden Protokolle nach aussen erstellen.

image

Wenn man den Zugang nun testen möchte, benötigt man einen Server im Internet, den man auf diesen Ports ansprechen kann. Die Seite http://portquiz.net/ bietet so einen Service an. Man kann mit Telnet einen gewünschten Port ansprechen.

image

Bei einem Verbindungsfehler kann man auf der Firewall überprüfen, ob sie die Anfrage blockt.

image

In diesem Fall lässt die Firewall die Anfrage auf die IP von portquiz.net mit Port 5901 aber durch. Trotzdem wird die Verbindung nicht aufgebaut. Dies muss also an der Firewall der Swisscom liegen.

Wir haben zwei Zugänge ins Internet. Auf der einen Seite den Zugang über den Contentfilter von der Swisscom und auf der anderen Seite eine öffentliche IP von der Swisscom, um unsere Server zu veröffentlichen. Bei beiden hat es eine Firewall der Swisscom, die nur von den Kantonsverantwortlichen als eigentlicher Kunde konfiguriert werden kann.

Mit unserer Firewall kann man mit sogenannten Multipath Rules bestimmen, welcher Verkehr über welchen Zugang abgewickelt werden soll.

image

So konnte ich verifizieren, dass beim Zugang über die öffentliche IP sowohl Port 81 als auch Port 5901 von der Swisscom Firewall geblockt wird. Beim Zugang über den Contentfilter der Swisscom kommt Port 5901 durch, aber Port 81 wird geblockt.

Hier sieht man, wie sich Telnet auf dem Port 5901 verbindet und statt einer Fehlermeldung ein schwarzes Fenster angezeigt wird.

image

Jetzt muss ich also bei den Kantonsverantwortlichen ansuchen, dass sie mir den anderen Port auch noch öffnen. Schliesslich wollen wir ein erfolgreiches Projekt mit PowerUp.

Identitätsdiebstahl überprüfen mit BSI Webseite

Das deutsche Bundesamt für Sicherheit in der Informationstechnik (BSI) bietet eine Webseite an, bei der man überprüfen kann, ob die eigene Mailadresse vom neuesten Identitätsdiebstahl mit 16 Millionen Opfern auch betroffen ist.

Bei der Analyse von Botnetzen wurden 16 Millionen gestohlene digitale Identitäten entdeckt. Online-Kriminelle betreiben Botnetze, den Zusammenschluss unzähliger gekaperter Rechner von Privatanwendern, insbesondere auch mit dem Ziel des Identitätdiebstahls.
Bei den digitalen Identitäten handelt es sich jeweils um E-Mail-Adresse und Passwort. E-Mail-Adresse und Passwort werden als Zugangsdaten für Mail-Accounts, oft aber auch für Online-Shops oder andere Internetdienste genutzt.
Die zugehörigen E-Mail-Adressen wurden dem Bundesamt für Sicherheit in der Informationstechnik (BSI) übergeben. Das BSI kommt damit seiner gesetzlichen Warnpflicht nach und gibt Ihnen die Möglichkeit, zu überprüfen, ob Sie von dem Identitätsdiebstahl betroffen sind. (Quelle: BSI)

 

image

Falls die Mailadresse betroffen wäre, erhält man ein Mail mit dem entsprechenden Betreff-Code. Den Code sollte man sich notieren, damit man gefälschte Mails, die nicht vom BSI kommen, erkennen kann. Falls man nicht auf der Liste ist, bekommt man kein Mail.

image

Access Control Lists (ACL) auf HP Switch

In grösseren Netzwerken sollte aus Performance- und Sicherheitsüberlegungen mit VLAN’s gearbeitet werden. Für einen ersten Überblick zu VLAN’s bietet sich der Blog Schulnetz.info von Edi Pfisterer an. Später wird man sich mit der Anleitung des eigenen Switches auseinandersetzen müssen, die dann aber oft viel technischer verfasst ist.

Hier habe ich bereits ein paar Befehle zusammengefasst, die ich immer mal wieder benötige. Neu kann unser Switch nun auch mit ACL’s umgehen. VLAN’s ohne ACL’s bringen (nur) mehr Performance, weil Broadcastverkehr eingeschränkt wird.
(Broadcasts sind Datenpakete, die ins ganze Netzwerk gesendet werden, weil nicht bekannt ist, an welcher Adresse sich der Empfänger befindet. Je mehr solcher Broadcasts durch das Netzwerk übermittelt werden, desto weniger “Platz” hat es auf der verwendeten Leitung für “Nutzverkehr”, das Netzwerk wird also langsamer).

Wenn Datenverkehr von VLAN zu VLAN übermittelt werden muss, spricht man von Routing. Häufig wird Routing benötigt, um z.B. auf das VLAN mit den Servern zu kommen. Mit eingestelltem Routing bringen VLAN’s also nur weniger Broadcastverkehr, aber keinen Sicherheitsgewinn. Dafür werden ACL’s benötigt, in denen angegeben werden kann, was genau von einem VLAN in das andere darf. Unser neuer Switch kann nun auch mit ACL’s umgehen. So gibt es Zugangspunkte in unserem Netzwerk, die aus Sicherheitsüberlegungen nicht von allen VLAN’s aus zugänglich sein sollten (wie z.B. die Hyper-V-Hosts oder die Verwaltungswebseiten von Servern und Storage, …). Trotzdem wäre es praktisch, wenn ich zur Verwaltung Zugang von meinem Rechner aus hätte und nicht einen Verwaltungsrechner nur für diesen Zweck einsetzen müsste.

Die folgenden Dinge treffen für unseren HP Switch zu. Bei anderen Herstellern muss man zu deren Dokumentation greifen.

Eine ACL (Access Control List) besteht aus einer oder mehreren ACE(s) (Access Control Entry). HP unterscheidet zwischen “standard ACLs” und “extended ACLs”. Bei den “standard ACLs” werden nur die “source addresses” (SA) betrachtet, also sind nur Regeln möglich, die den Verkehr VON xy regeln. Besser geeignet für meine Vorhaben sind die “extended ACLs”, die den Verkehr VON xy NACH uv regeln können.

image

(config)# ip access-list extended <name-str>
Mit diesem Befehl kann man eine extended ACL bearbeiten oder neu erstellen, falls es noch keine ACL mit diesem Namen gibt. Falls der <name-str> Leerzeichen enthält, muss man den Namen in einfache oder doppelte Anführungszeichen setzen. Die Namen dürfen aus 64 Zeichen (alphanumeric) bestehen.

(config-ext-nacl)# deny ip any host 192.168.1.15
Erstellt eine ACE die den Verkehr von allen Netzwerken zum Host 192.168.1.15 verhindert.
image

Um eine neue ACE in eine bereits bestehende Liste einzufügen, kann man einfach die gewünschte Zahl voranstellen, also z.B. 15 deny ip any host 192.168.1.15.

# show access-list
Zeigt eine Übersicht über die eingetragenen ACLs.

# show access-list config
Zeigt Konfigurationsdetails der eingetragenen ACLs an.

#show access-list vlan <vid>
Zeigt die ACLs an, die dem angegebenen VLAN zugeordnet sind.

# vlan <vid> ip access-group <identifier> <in out>
Ordnet eine ACL einem VLAN zu. Wenn man “no” dem Befehl voranstellt, wird die Zuordnung wieder gelöscht. <identifier> muss mit dem Namen (oder der Nummer) der ACL ersetzt werden.
image

Implicit Deny
Wenn eine ACL einem Port oder einem VLAN zugeordnet ist, werden alle nicht explizit erlaubten Fälle abgelehnt.
image

Konkret
Viel einfacher wäre es gewesen, alle Verwaltungsadressen in ein eigenes VLAN zu stecken, aber wie so oft ist man schlauer, wenn alles schon gemacht ist und eine Änderung aufwendig wird. Unsere Server sind im gleichen Subnetz/VLAN wie die Hyper-V-Hosts und die Verwaltungswebseiten von Storage/Hyper-V-Hosts. Also müssen alle Clients aus ihren VLANS Zugang zum Server-VLAN haben, aber nicht zu den einzelnen dieser Ausnahmen. Dies kann mit den ACLs erreicht werden.

Die ACL kann so angelegt werden:
ip access-list extended „Server out“
deny ip any host 192.168.13.25
deny ip any host 192.168.13.28
deny ip any host 192.168.13.35
deny ip any host 192.168.13.36
deny ip any host 192.168.13.50
deny ip any host 192.168.13.51
permit ip any any
exit

Nun muss die ACL noch dem entsprechenden Server VLAN zugewiesen werden
vlan 207 ip access-group “Server out” out

Exchange über Sophos UTM veröffentlichen

Exchange kommuniziert stark mit dem Internet, zum einen um Mails zu empfangen und zu versenden, zum anderen können aber auch Möglichkeiten angeboten werden, damit die Mitarbeiter von aussen auf ihr Postfach zugreifen können. Dazu gehören Outlook Web Access, ActiveSync und Outlook Anywhere. All dies lässt sich durch eine Sophos UTM schützen.

Weiterlesen