©Alexey Pinchuk, 123RF.com

Segmentierbar, virtualisierbar und ganz auf die Kontrolle der Anwendungen im LAN bezogen: Die neueste Windmaschine auf dem Firewallmarkt kommt aus Kalifornien und heißt PA-4020. Das Linux-Magazin durfte als Erster exklusiv ein Gerät testen .

Auf Konferenzen und in Hersteller-Prospekten gilt es offenbar als schick, den Tod der traditionellen Perimeter-Firewall zu verkünden. B2B, E-Commerce und das Web 2.0 weichen den klassischen Aufbau zum Schutz des lokalen Netzes, zum Beispiel mit einer dedizierten DMZ, immer weiter auf, so der Tenor.

Manche Quellen ([1],[2]) prognostizieren sogar einen generellen Bedeutungsverlust von Firewalls und vermelden den Übergang zu granularen Sicherheits-Checks auf den einzelnen Hosts und Clients. Doch es geht auch anders. Ein Gegenbeispiel, das zeigt, wie eine innovative Firewall auch aussehen kann, stammt aus dem Silicon Valley: Seit vier Jahren entwickelt die Firma Palo Alto Networks Appliances und hat nach eigener Aussage einige Neuerungen zu bieten, die mit Open-Source-Mitteln so noch nicht möglich sind. Als erstes Zeitschrift in Europa hat das Linux-Magazin die Chance bekommen, die PA 4020 (Kasten “Palo Alto Networks PA 4020”) im Testlabor unter die Lupe zu nehmen.

Leichtgewicht?

Laut der Dokumentation des Herstellers ist die PA 4020 eine Enterprise-Firewall und für Durchsätze von 2 GBit/s Wirespeed geeignet. Unter IPsec bleibt davon immer noch ein stattliches Gbit/s, und die maximal möglichen 500 000 Sessions dürften nur die wenigsten Kunden ausschöpfen. Die Appliance ist zwei Rack-Units hoch, beim Auspacken und Einbauen ins Rack fällt sofort das für die Abmessungen ungewöhnlich schwere, verplombte Gehäuse auf.

Abbildung 1: Das Dashboard ist übersichtlich und aufgeräumt. Wie die gesamte Web-GUI wirkt es auf den ersten Blick ein wenig zu schlank, beinhaltet aber umfangreiche Funktionen.

Im Gegensatz dazu erweist sich das Browser-basierte GUI der PA-Firewall -Appliance als wahres Leichtgewicht (Abbildung 1). Der erfahrene Admin fragt sich zunächst, ob das wirklich reichen kann, um die Firewall neu zu erfinden. Aber während des weiteren Tests zeigte sich, dass sich damit angenehm arbeiten lässt, alle Features sind gut zugänglich. Zwar fehlen einige Kleinigkeiten wie zum Beispiel die Ping-Funktion zur Prüfung der L3-Verbindungen (von der Firewall ausgehend) im GUI, aber viele davon hat der Hersteller wohl ganz bewusst ausschließlich auf der Kommandozeile implementiert.

Die neue Philosophie, ein Firewall-Regelwerk zu bilden ist dagegen omnipräsent. Im Gegensatz zu gängigen Firewalls muss der Admin das Regelwerk der PAN-Firewall nicht zwingend über IP-Adressen und TCP-/UDP-Ports aufbauen. Besser ist es, wenn er sich auf den neuen Weg einlässt und seine bestehenden Regeln auf den applikationsorientierten Ansatz migriert. Im Lieferumfang der PA stehen gegenwaertig 900 Applikationen (Abbildung 2) die sich in den Firewall-Rules verwenden lassen, ihre Anzahl wächst ständig.

Abbildung 2: Applikationsbasierter Ansatz für die Firewalladministration. Die Paloaltonetworks Firewall kennt bereits 900 Anwendungen und kann deren Verhalten im Netz überwachen und steuern.

Topologien

Vereinfacht ausgedrückt kennt die Ap- pliance frei definierte oder vorgefertigte Zonen wie »Trust«, »Untrust«, »DMZ1« oder aber Applikationen wie RDP, SSH, I-Tunes, wahlweise auch Profile. Nachdem sich der Admin für eine der möglichen Topologien entschieden hat, weist er jedem benötigtem Netzwerkinterface eine Zone zu. Im einfachsten Fall, wenn er die Appliance im Virtual Wire Mode betreibt, legt er sofort mit der Konfiguration des Regelwerks los (Abbildung 3). Das geht auch im CLI, Listing 1 zeigt das Äquivalent einer Firewall-Rule an der Befehlszeile.

Abbildung 3: Zonen, Applikationen oder Profile, welche Topologie darfs denn sein? Nach dieser Entscheidung baut der Admin das Regelwerk auf.

rule2 {
 from [ trust ];
 to [ untrust ];
 source [ any ];
 destination [ any ];
 service [ service-http ];
 application [ any ];
 action allow;
 source-user [ any ];
 option ;
 negate-source no;
 negate-destination no;
 disabled no;
 log-start yes;
 log-end yes;
 profile-setting {
  profiles {
  virus [ default ];
  spyware [ default ];
  vulnerability [ lm_vul_profile ];
  url-filtering [ no_porn_v2 ];
  file-blocking [ denie_pdf ];
  }
}

Dann konfiguriert der Administrator, welche Applikation(en) er von der Zone »Trust« nach »Untrust« erlaubt und welche Profile die PA wiederum auf die erlaubten Applikationen anwenden soll. Im Profil bestimmt er, ob die Appliance den Netzwerkverkehr einer bestimmten Applikation auf Viren oder ähnliche Malware scannt. Auch der Vergleich mit IDS-Patterns und der Block ganzer URLs ist möglich. Interessanterweise kann das Gerät den Netzwerk-Traffic aller möglichen Applikationen, also auch I-Tunes-Downloads oder RSS, auf Viren scannen und zum Beispiel auch einen Facebook-Chat im verschlüsselten HTTPS-Stream erkennen.

Mehr Signaturen

Noch 2008 war über die PAs zu lesen [4], dass ihre Erkennung von Viren in E-Mails relativ mäßig sei. Der Hersteller hat mittlerweile reagiert und die damals 50.000 Virensignaturen auf über eine Million aufgestockt. Da es sich bei der PAN-Appliance aber um keine Proxy-Firewall handelt, die die Protokolle der geprüften oder gescannten Applikat­ionen spricht, darf der Admin im Moment bei manchen Anwendungen wie den RSS Feeds in XML wohl keinen hundertprozentigen Schutz vor Viren erwarten. Herkömmliche Firewalls können aber in der Regel auch nur wenige TCP-Ports scannen und beherrschen nicht so viele Applikationen wie Palo Altos Gerät.

Drunter: Linux oder BSD?

Wer sich als Administrator per SSH auf der Kommandozeile der PA einloggt, stellt fest: Die Appliance meldet sich mit »admin@PA-4020«, was auf den ersten Blick recht proprietär aussieht und die Herstellerangabe eines “proprietären “PAN-OS” bestätigt. Bald nach den ersten Kommandos merkt er aber, dass hier entweder eine Linux- oder BSD-Unterlage werkelt, zu der der Hersteller Zugang über die proprietäre Shell gewährt. Interessanterweise ist das bei Juniper Jun-OS [5] und Vyatta [6] genauso gelöst. Auch im weiteren Verlauf finden sich immer wieder Ähnlichkeiten zwischen den drei Systemen, vor allem bei der hierarchischen Konfiguration an dem CLI. Auch die Einrichtung virtueller Firewall-Systeme und virtueller Router auf der PA ist der Juniper-ISG-Firewall-Implementierung sehr ähnlich, aber eindeutig übersichtlicher und angenehmer zu administrieren.

Etwas zu weich

Nach dem Kommando »show system resources« taucht verblüffenderweise eine Tabelle mit sage und schreibe 88 Prozessen auf, in der sich sogar noch der Nfsd und der Mountd finden. Die beiden Prozesse “wegzuhärten” gehört unter Admins bei der manuellen Installation von Firewalls schon seit zehn Jahren zur Best-Practice. Der Hersteller ist hier wohl zu großzügig mit dem Thema Härtung umgegangen. Verglichen mit der Check Point Secure Platform hat PA wohl etwas weniger Wert auf die Grundlage gelegt. Auf Nachfrage vertraten die Techniker von PA den Standpunkt, dass diese Dienste natürlich nicht von außen angreifbar sind. Aber zu guter Systemhärtung sollte es auch gehören, unnötige Dienste zu entfernen, auch wenn sie nicht oder nur schwer angreifbar sind.

Bei der Basis-Einrichtung zu diesem Test kam es öfters vor, dass die PA beim Neuanlegen von Objekten nicht alle Abhän- gigkeiten aus einem einzigen Menu heraus erstellen konnte. So lassen sich zum Beispiel virtuelle Router anlegen aber nicht im gleichen Menu einem virtuellen System zuweisen. Der Admin muss den Vrouter erst erstellen, um ihn dann an sein Vsys zu überweisen. Im Betrieb füllen sich aber die Profile und Objekte mit immer mehr Eigenschaften, sodass das Problem im Lauf der Zeit seltener auftritt.

Logging und IPv6

Das Thema Logging dagegen ist einer der Bereiche, wo das Gerät richtig punktet. Durch den applikationsbasierten Ansatz kennt die PAN-Firewall zu fast jedem Paket die zugehörige Applikation. Dement- sprechend informativ sind die umfangreichen Log-Dateien. Eine gelungene Anwendung daraus ist das Application Command Centre (Abbildung 4), das den Admin auf einen Blick darüber informiert, was eigentlich im Netzwerk vorgeht. In der Praxis hilf- reich sind auch die geografischen An- sichten und Informationen, die aus den Logdateien stammen, zum Beispiel als Antworten auf Fragen wie “Wohin surfen unsere Mitarbeiter?” (Abbildung 5).

Abbildung 4: Die PA entlarvt die Anwendungen im LAN: 20 000 DNS-Sessions, I-Tunes, Bittorrent, und Gnutella zeugen vom Verhalten der Mitarbeiter. Auch mit SSL verschlüsselten Traffic inspiziert die PA on-the-fly.

Abbildung 5: Auch geografisch visualisieren kann die PA: Die Karte der letzten 6 Stunden zeigt die Top Ten der ausgehenden Verbindungen nach Ländern.

Die PA-Firewall unterstützt auch IPv6 im Virtual-Wire-Mode und hat zur Überraschung der Autoren alle getesteten Applikationen richtig erkannt – unabhängig davon, ob diese unter IPv4 oder IPv6 übers Netzwerk liefen. In der GUI lassen sich auch eigens IPv6-basierte Regeln einpflegen, ein durchaus bemerkenswertes Feature bei einem so jungen Produkt. Andere, durchaus namhafte Firewall-Hersteller bringen derzeit immer noch neue Produkte ohne jeglichen IPv6-Support auf den Markt.

Virtuell

Während Virtualisierung von Hosts und Netzwerkgeräten im Verbund mit Bladeservern für höhere Dichte, Integration und einen kleineren physikalischen Footprint sorgt, schaut der Trend bei den Sicherheitsprodukten leider anders aus. Aus bestehenden Produkten koppeln die Hersteller immer mehr Features auf eigene Appliances aus. Beispiele hierfür sind Microdasys SCIP & XML Ray (jetzt XSG, [7]) oder das im Linux-Magazin besprochene Astaro Mail Gateway [8]. Die PA Firewall Appliance liegt dagegen bei der Konsolidierung von Netzwerken voll auf Kurs und integriert Features wie URL-Filtering, Antivirus-Scanning und IDS/PS auf einer Platform. Der Unterschied zu UTM-Appliances offenbart sich vielleicht nicht von Anfang an und wird erst im Betrieb deutlich: Die PA arbeitet im Streaming Mode, nicht als Proxy. Das macht die Integration der einzelnen Komponenten harmonischer, handelt es sich doch um Features, die die Firewall technologisch wie nebenbei miterledigt. Die Applikationskontrollen auf dem Gerät sind alle aus derselben GUI heraus zugänglich und präsentieren sich bei der Administration immer wie eine einzige logische Firewall und nicht wie eine Reihe dedizierter Proxies.

Keine feinen Regeln

Die Integration hat natürlich auch ihren Preis. So kann die Appliance E-Mails zum Beispiel auf Malware und Viren filtern, aber keine so fein granulierten Policies stricken, wie es zum Beispiel hoch spezialisierten Produkten von Sendmail oder dem Clearswift Mimesweeer vorbehalten ist. Auch ein Quarantäne-Konzept sucht der Admin deshalb vergebens. Javascript fürs Web auf Viren zu scannen wird Palo Alto Networks erst ab März 2010 anbieten.

Der Hersteller weist deshalb auch deutlich darauf hin, dass ein Netzwerk-Device im Streaming-Mode keine Desktop- oder Server-AV-Software ersetzt. Vielleicht wäre hier etwas mehr Mut angebracht, die eigenen Ideen weiter reifen zu lassen und konsequenter auszubauen. Gegenwärtig widersprechen sich die Whitepa- pers auch noch: In manchen steht, dass die Appliances Kosten durch Konsolidation sparen, in anderen Whitepapers will PA scheinbar einen Verdrängungswettbewerb vermeiden.

ISP-Features

Wie die Großen in diesem Marktsegment (Cisco ASA Multiple Context Mode oder Juniper Virtual Systems) kann der Admin auch die PA-Appliance in mehrere voneinander fast unabhängige Firewalls segmentieren, also virtualisieren. Jede davon lässt sich dann unabhängig von den anderen administrieren (Abbildung 6).

Abbildung 6: Virtualisierte und segmentierbare Firewalls sind in dieser Preisklasse eigentlich die Ausnahme.

Die Konkurrenz von Cisco und Juniper hat das seit 2006 auf dem Markt, wo- bei sich viele Endanwender fragen, wass sie damit anfangen sollen. Das Feature richtet sich eher an ISPs, Anbietern von Managed Security Services und Rechenzentren, die jedem Kunden eine eigene Firewall bieten wollen und das gleichzeitig möglichst ökonomisch im Rechenzen- trum implementieren müssen. Zusätzlich eignet die PA sich damit für Forschungs- und Entwicklungsumgebungen, wo Ad- mins abseits der Haupt-IT-Plattform eine Testkonfiguration brauchen.

Ein guter Anlass

Die PA-Firewall-Appliance beeindruckt vor allem durch den innovativen Ansatz, einmal ganz anders an das Thema Firewall heranzugehen. Das zieht der Hersteller dann auch von den Werbeprospekten bis in die technischen Details durch. Möchte er die Vorteile der Firewall nutzen, muss sich der Administrator aber auch auf das neue, applikationsorientierte Konzept einlassen und wahrscheinlich seine gewachsene Sicherheitspolicy daran anpassen.

Auch sollte er sich überlegen, in wie weit sich Konzepte wie De-Perimeterisierung mit der Anschaffung einer PA-Appliance verbinden lassen. Ob sie hilft, die eigene Security Policy zu vereinfachen und übersichtlicher zu gestalten, sollten sich Administratoren und Entscheider gut überlegen. Das Gleiche gilt für die Frage, ob die PA-Firewall-Apliance schon ausreichende Funktionen bietet, und wo es zusätzliche, spezialisierte Soft- und Hardware braucht. Vielleicht erweisen sich ja die Konzepte von Palo Alto Networks auch als willkommener Anlass, wieder mal die Sicherheitsanforderungen zu überdenken und abzuwägen, was der neue Ansatz bringt und alte Gewohnheiten auf den Prüfstand zu stellen. (mfe)