Archiv der Kategorie: Sicherheit

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

Forefront Endpoint Protection Reporting

Wir setzen an unserer Schule Forefront Endpoint Protection (FEP) als Virenschutzlösung ein. Dies nicht, weil ich der Ansicht bin, dass es die beste Antivirenlösung auf dem Markt ist, sondern weil der FEP-Client beim School Agreement von Microsoft bereits enthalten ist und wir uns so das Geld für eine andere Antivirenlösung sparen können.

Verwalten lässt sich FEP aber nur über SCCM (System Center Configuration Manager). Da aber SCCM auch viele Vorteile bei der Verteilung von Software und Betriebssystemimages bietet, ist das für eine grössere Schule mit Schweizer School Agreement eine empfehlenswerte Kombination, vor allem, weil die Kombination aus SCCM und FEP sogar bedeutend günstiger ist, als es unsere alte Antivirenlösung war.

Nun ist aber ein “worst case” eingetroffen. Ich habe keine Meldung mehr erhalten, dass ein Virenbefall abgewehrt wurde und auch in den Berichten standen 0 infizierte/gesäuberte Systeme. Daher bin ich davon ausgegangen, dass der Virenschutz problemlos funktioniert. Dank einem Hinweis unseres ISP’s bin ich auf einen Computer aufmerksam geworden, der mit dem Zeus-Trojaner infiziert wurde. FEP hat den Trojaner erkannt und in die Quarantäne verschoben, hat also seine Hauptarbeit erledigt, ABER hat mir keine Meldung zukommen lassen, damit ich über diesen Vorfall informiert gewesen wäre.

Damit FEP seine Meldungen an SCCM melden kann, muss der “Client-Agent für die Verwaltung gewünschter Konfigurationen” aktiviert sein.

image

Der muss früher schon einmal aktiviert gewesen sein, aber ist wahrscheinlich durch ein Layer-8 Problem meinerseits mal deaktiviert worden Trauriges Smiley.

Gemäss einem Test mit EICAR funktioniert nun auch das Reporting wieder. EICAR ist eine Datei, die zu Testzwecken von allen Antivirenprodukten als Virus erkannt wird. Man muss nur die Zeichenfolge
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*
in einem Texteditor als ausführbare COM Datei abspeichern, damit das Antivirenprogramm reagiert.

image

Danach bekommt man wie gewünscht eine Mail an die konfigurierte Adresse mit den Angaben zur gefundenen Malware und den ausgeführten Aktionen.

image

Werde mir also in Zukunft angewöhnen, in einem festen Zeitintervall so eine EICAR-Testdatei auszuführen, um sicherzustellen, dass das Reporting auch wirklich funktioniert.

Zeus Trojaner

Shadowserver ist eine Seite, die verschiedene Honeypots betreibt, um festzustellen, welche Malware im Umlauf ist und von welchen Clients aus, diese aufgerufen wird. Die Swisscom als ISP hat sich bei Shadowserver angemeldet, um informiert zu werden, wenn ein Kunde von ihnen in so einen Honeypot tritt.

Das Computer Security and Incident Response Team (CSIRT) von Swisscom überwacht verschiedene Informationsquellen im Zusammenhang mit der Computersicherheit. Eine dieser Quellen ist Shadowserver (http://www.shadowserver.org). Über Shadowserver haben wir erfahren, dass eine Adresse aus Ihrem IP-Bereich versucht hat, einen Virus zu verbreiten oder die Verbindung zu einem Botnet-Command-and-Control-Server herzustellen.
Dies deutet mit hoher Wahrscheinlichkeit darauf hin, dass ein oder mehrere Rechner in Ihrem Unternehmen mit einem Virus, Wurm oder Trojaner („Malware“) infiziert sind.

Ich habe nun die entsprechende “Target Address” erhalten, die über unser Netzwerk aufgerufen wurde.

image

Dies kann man nun über die Logs der Firewall überprüfen. Meine Überprüfung hat dann gezeigt, dass tatsächlich ein Computer an diesem Tag die entsprechende IP aufgerufen hat. Dazu habe notepad++ benutzt, mit dem man gerade alle Treffer einer Suche auf einmal anzeigen lassen kann.

image

Den Namen des betroffenen Computers kann man schnell herausfinden, indem man ein nslookup “IP-Adresse” in der Eingabeaufforderung eintippt. 

image

Um aber sicherzugehen, dass am betroffenen Tag auch dieser Computer diese IP hatte, muss man noch auf dem DHCP Server anhand der Leasedauer überprüfen, ob der betroffene Computer auch an dem betroffenen Tag diese IP hatte. Dies war bei mir der Fall, also war der Computer identifiziert.

Nun eine Recherche zu Zeus. Da gibt es viele Beschreibungen, wie man überprüfen kann, ob man infiziert ist, oder wie man den Trojaner wieder wegbringt. Unter anderem gibt es von Microsoft ein Tool, das ich heruntergeladen und ausgeführt habe. Dieses hat aber keine Infektion gefunden.

image

Eine weitere Recherche hat dann gezeigt, dass nichts gefunden werden konnte, weil sich der Trojaner bereits in Quarantäne befunden hat.

image

image

Trotzdem handelt es ich um ein einmal infiziertes System und die vielen Internetressourcen deuten darauf hin, dass man nicht sicher sein kann, dass alles entfernt wurde (siehe für Informationen zu Zeus auch http://en.wikipedia.org/wiki/Zeus_(Trojan_horse))

image

Daher habe ich mich nun entschlossen, den betroffenen Computer neu aufzusetzen.

Swisscom Schulen ans Internet

Die Swisscom bietet den Schulen der Schweiz einen Internetzugang an. Dieser ist bisher gratis, was einer riesigen Investition in die Schulen gleichkommt. Vielen Dank dafür.

Wir haben unsere Firewall gewechselt und nun funktioniert der Zugang ins Internet nur noch schlecht. Scheinbar hat der Swisscom Proxy Probleme mit schnelleren/neueren Firewalls. Zumindest ist das gemäss Kantonswebseite auch ein Problem mit anderen Firewalls.

Die neuste Serie von Zyxel Firewalls (USG) ist nicht mit den Swisscom-Routern (Cisco) für Schulen ans Internet kompatibel. Das Problem zeigt sich in einer äusserst verlangsamten effektiven Internetgeschwindigkeit.

Die Swisscom stellt sich gemäss Auskunft auf den Standpunkt, dass nach ihrem Konzept nicht vorgesehen ist, dass die Schulen eine eigene Firewall einsetzen, weil sie ja hinter der Firewall des Kantons stehen. Damit wäre man ja gegenüber dem Internet geschützt, aber nicht gegenüber anderen Schulen. Ausserdem hätten wir gar nicht so viele IP Adressen zur Verfügung wie wir benötigen würden (wir haben 350 Computer und weitere Geräte wie Drucker, Kopierer, … im Einsatz). Komisches, nicht fertig gedachtes Konzept der Swisscom also.

Auch wenn ich sehr zu schätzen weiss, dass die Swisscom den Internetzugang bisher gratis angeboten hat (wenn man eine Leistungssteigerung möchte, muss man in Zukunft auch (massiv) mehr bezahlen) bin ich im Moment am studieren, ob wir wieder zurück auf unseren Kabelnetzanbieter wechseln sollen.

Im Moment empfehle ich allen grösseren Schulen, die eine neue leistungsfähige Firewall einsetzen möchten, dies genau zu testen und abzuklären (oder einen anderen ISP als die Swisscom zu verwenden). Am wenigsten Probleme gibt es scheinbar mit kleineren Firewalls aus dem SOHO Segment.