Cisco IOS: Content-Filtering

Das Filtern von URLs ist eine Funktion, die ich normalerweise auf einem dedizierten Proxy implementieren würde. Aber wenn kein Proxy zur Verfügung steht, kann diese Funktion auch lokal auf dem IOS-Router ab Version 12.4(20)T konfiguriert werden. Dabei stehen drei Mechanismen zur Verfügung:

  1. Ein lokal installierter Websense oder Secure Computing Server
  2. Abfrage des “cloud-based” Trend Micro URL-Filtering Dienstes
  3. lokale Black- oder Whitelists

Um zu testen, ob die Trend Micro-Lösung als Alternative in Branch-Offices einsetzbar ist, habe ich auf meinem Cisco 1841 mit IOS 15.1(3)T die Test-Lizenz installiert. Diese kann pro Router einmal aktiviert werden und läuft dann für dreißig Tage. Der Straßenpreis der Lizenz für die 1800er oder 1900-Serie liegt für 1 Jahr bei ca. 200 Euro, was die Sache recht interessant macht.
Die Konfiguration des Content-Filters ist in die Zone-Based-Firewall integriert, was die Implementierung sehr flexibel macht (wobei böse Zungen behaupten “flexibel” wäre nur eine Umschreibung für “unnötig kompliziert”; eine Behauptung, der ich nur schwer widersprechen kann).
In der Cisco-Dokumentation ist die Konfiguration auch recht gut beschrieben, weshalb ich hier nicht näher darauf eingehe. Nach der “Fleiß-Arbeit”, mit der Cisco Common Classification Policy Language (C3PL) die Zonen-basierte Konfiguration anzufertigen, gilt es aus den 70 URL-Kategorien (wie z.B. Auctions, Games, Nudity, Pornography, Shopping, Travel, Weapons) und den 10 Security-Kategorien (wie z.B. ADWARE, HACKING, PHISHING) die richtigen auszuwählen, die geblockt werden sollen.

Was kam weiter beim Test heraus:

  • Wie ich vorher auch schon bei N2H2 — jetzt Secure Computing — festgestellt habe, ist der Filter bei deutschen Seiten bei weitem nicht so gut wie bei englischem Content (z.B. beim Zugriff auf .com-Seiten).
  • Viele Seiten, die eigentlich bei meinen Tests hätten geblockt werden sollen, wurden vom Filter erlaubt. Schade eigentlich. Oftmals zeigte sich auch, das nur Teile zu blockender Seiten nicht angezeigt wurden. Wenn ich die Kategorie “Violence-hate-racism” blocke und die Seite des Ku Klux Klan aufrufe, dann werden zwar alle Bilder und Elemente der Webseite geblockt, der Text der Hauptseite erscheint aber trotzdem. Genauso z.B. beim Blocken von “Real-estate”. Die Seite immonet.de erscheint schon, es werden aber keine sonstigen Elemente dargestellt.
  • “Photo-Searches” blockt nicht photoblog.msnbc.msn.com.
  • “Nudity” blockt kein http://www.coupe.de, keine BILD und auch keine getesteten FKK/Nudisten-Seiten.
  • Von den im Bundestag vertretenen Parteien werden in der Kategorie “Political” nur die Linken geblockt, NPD geht, die DVU hingegen nicht.
  • Die Kategorie “Auctions” filtert recht gut, wenn auch der Zugriff auf http://www.zoll-auktion.de nicht geblockt wird. Das hätte ich allerdings auch nicht erwartet.
  • Die CPU-Belastung steigt durch die Nutzung des Content-Filters natürlich auch. Mit dem getesteten Cisco 1841 an meinem 16000er DSL-Anschluss erreiche ich bei HTTP-Downloads zwar wie auch ohne Content-Filter eine Geschwindigkeit von ca. 1,6 bis 1,7 MByte/s. Die CPU-Last liegt dabei aber durchgängig bei über 95%. Der “normale” Wert bei Downloads beträgt ca. 85%, was natürlich auch grenzwertig ist, aber halt auch nur bei längeren Downloads vorkommt. Dieser Anstieg reicht aber schon, das ich diese Lösung für meine Kunden, die in den Branches meist 1800er Router haben, für nicht geeignet halte. Wenn neuere Standorte mit 1900er Routern bestückt werden sollte man die Sache aber erneut analysieren. Bei den deutlich schnelleren ISR-G2 kann ich mir aber vorstellen, das es schon ganz anders aussieht.

Weitere Informationen zum Thema IOS Content-Filter und Zone-Based-Firewalls:

Cisco IOS: Content-Filtering

Klare Worte

Na, da weiß man doch gleich, was bei der Registrierung auf Cisco.com schief gelaufen ist:

Die Bestätigungs-Mail war dann schon etwas klarer:

Sobald Sie Ihr Konto aktiviert haben, könnte es bis zu 15 Minuten aktiv zu werden. Einmal aktiviert, wenn Sie nicht anmelden können, versuchen Sie es nach 15 Minuten.

Klare Worte

Cisco IOS: DNS-Views

Heute lese ich im IPExpert-Blog über DNS-Views und sage mir, “Hey, darüber habe ich doch auch gerade geschrieben”. Nun, geschrieben schon, aber noch nicht veröffentlicht, was ich hiermit nachhole:

Über den im IOS eingebauten DNS-Server habe ich schon vor längerer Zeit berichtet. Seit einiger Zeit (genauer gesagt seit IOS 12.4(9)T) unterstützt das IOS auch sogenannte DNS-Views. Dabei werden die DNS-Anfragen in Abhängigkeit der angefragten Domains an unterschiedliche DNS-Server gesendet. Ich benutze das z.B. für Wartungszugänge zu Kunden. Wenn eine Anfrage an server.firma1.local am DNS-Server ankommt, wird die Anfrage über das Firma1-VPN weitergeleitet, bei allen anderen Anfragen aber an den DNS-Server des Providers.

Die Konfiguration startet mit den DNS Name-Lists. In diesen werden per Regular Expression die Domain-Namen oder FQDNs beschrieben, für die eine abweichende Behandlung gewünscht ist. In meinem Fall ist dies eine Namensauflösung durch einen anderen DNS-Server:

ip dns name-list 1 permit .firma.local

Als nächstes werden die DNS-Views konfiguriert:

ip dns view FIRMA
 logging
 dns forwarder 10.11.12.13
 dns forwarding source-interface Vlan254
ip dns view default
 logging
 domain timeout 2
 dns forwarder 8.8.8.8

In meinem Beispiel gibt es eine dedizierte View FIRMA und eine optionale default-View.
In der View FIRMA setze ich den zuständigen DNS-Server und die Source-Adresse der Anfrage, damit die Anfrage auch wirklich durch den VPN-Tunnel gesendet wird. Die Default-View verwendet den Google DNS-Server. Für beide Views wird das Logging aktiviert.

Die Verwendung der beiden Views muss als nächstes aktiviert werden:

ip dns view-list DNS
 view FIRMA 10
  restrict name-group 1
 view default 1000
!
ip dns server view-group DNS

Die View-List mit dem Namen DNS spezifiziert, welche View für welche Domains verwendet werden soll. Die View FIRMA wird dabei nur für die Domains verwendet, die in der name-list 1 spezifiziert wurden. Die View default wird für den gesamten Rest verwendet. Die “10” und “1000” gibt dabei die Priorität der Einträge in der List an.
Die View-List kann dann entweder Interface-basiert, oder global (wie in diesem Beispiel) angewendet werden.

Durch das Logging kann man kontrollieren ob die Views verwendet werden:

Feb 20 19:41:34.213 CET: %DNS-6-LOG_ACCESS: DNS View default used for client 10.255.253.74/1904, querying A 'time.apple.com'
Feb 20 19:42:41.301 CET: %DNS-6-LOG_ACCESS: DNS View FIRMA used for client 10.255.250.2/62733, querying AAAA 'www.firma.local'
Cisco IOS: DNS-Views

Die Herkunft des “J”

Schon oft habe ich mich gefragt, wieso so viele Leute einen Hang dazu haben, sinnlose “J” in Mail-Texten unterzubringen, wie hier z.B.:

Über einen Beitrag bei EtherealMind bin ich zu Chris Pirillos Blog gekommen, der die ganze Sache erklärt:

Essentially, you’re going to fix a problem that Microsoft has known about for several editions. Well, it’s not a “real” problem – so long as you NEVER email someone who isn’t running Windows, and so long as you DO NOT use HTML email.

War ja mal wieder klar … Wie man das (auf der Windows-Seite) abstellt wird auch in seinem Blog erklärt.

Die Herkunft des “J”