Willkommen

Dienstleistungen

Qualifikation

Projekte

Zertifizierungen

Über mich

Kontakt




Projekte / Case Studies

Im Laufe meiner selbständigen Tätigkeit als Security Consultant habe ich zahlreiche Projekte durchgeführt. Ich möchte Ihnen hier einen kleinen Auszug dieser Projekte vorstellen.

Bitte wählen Sie ein Projekt aus, um direkt zu der Projektbeschreibung zu gelangen.
Aufbau eines Check Point Firewall Clusters
Integration Netscreen Monitoring in IBM Netcool
Aufbau eines Netscreen Client VPN mit Zertifikaten
Troubleshooting - Firewall-Performance
Aufbau einer vollständigen Security-Infrastruktur
Migration einer Umgebung auf neue F5 Loadbalancer
Migration einer SQUID Installation auf BlueCoat ProxySG
Automatisierung von F5 Loadbalancern
Mandantenfähige Proxy Infrastruktur mit BlueCoat ProxySG
Migration von PIX Firewalls auf einen Astaro Cluster

** NEW ** Netzwerk Troubleshooting (ERP auf AS/400)
** NEW ** Migration Astaro Cluster nach CheckPoint via Script
** NEW ** F5 iRule Programmierung - Webform Authentisierung


Projektbeschreibungen

Projekt: Aufbau eines Check Point Firewall Clusters
Unternehmen: Finanzdienstleister
Anforderung: Das Unternehmen setzte eine Firewall der Firma Check Point ein. Dieses System war einfach ausgelegt. Aufgrund der gestiegenen Anforderungen an die Verfügbarkeit, sollte das System durch einen Cluster ersetzt werden.
Umsetzung: Für die Umsetzung wurde wieder Check Point Firewall-1 gewählt. Die Cluster-Funktionalität übernimmt die Cluster-Software von Nokia (Nokia IP Clustering). Die bestehende Konfiguration wurde übernommen und auf den Cluster portiert, inkl. sämtlicher VPN Verbindungen. Dies war insbesondere im Hinblick auf die vielen VPN Clients eine Herausforderung, da ein Ausfall bzw. eine Neukonfiguration dieser VPN Tunnel nicht akzeptabel gewesen wäre. Regelmäßige Failover-Tests stellen seit der Migration sicher, dass der Cluster korrekt funktioniert.
>> back


Projekt: Integration Netscreen Monitoring in IBM Netcool
Unternehmen: Internet Provider / Carrier
Anforderung: Das Unternehmen betreibt für einen Großkunden ca. 100 Netscreen Cluster. Die Überwachung dieser Netscreen Cluster sollte in das Monitoring System IBM Netcool integriert werden. IBM Netcool ist in der Lage Logdaten von verschiedenen Netzwerk-Devices zu lesen und damit das Monitoring durchzuführen. Für Netscreen existiert jedoch kein Log-Modul. Die Aufgabe bestand nun in der Schaffung einer Schnittstelle zwischen den Netscreen Firewalls und IBM Netcool. Eine Herausforderung stelle das Logformat der Netscreen Firewall dar. Die Logdaten enthalten keinen eindeutigen Log-Identifier, anhand dessen ein Event zweifelsfrei zugeordnet werden kann.
Umsetzung: Um das Problem des fehlenden Log-Identifiers zu lösen, habe ich einen Log-Parser in Perl entwickelt, welcher die Logdaten mittels regulärer Ausdrücke (regular expressions) eindeutig identifiziert und den einzelnen Events eindeutige Event-IDs zuweist. Aufgrund der Vielzahl der möglichen Log-Einträge, werden die regulären Ausdrücke automatisch aus einer Excel Datei generiert, welches der Kunde bei Bedarf erweitert, um neue Events hinzuzufügen. Als Basis für die Excel Datei diente die Netscreen Beschreibung des Logformats. Der Logparser nimmt die Logdaten von einem zentralen Syslog Server entgegen, parst die Daten und weist Ihnen eine eindeutige Event-ID zu. Gleichzeitig findet eine Vor-Selektion der Events statt, so dass nur die relevanten Events an IBM Netcool weitergereicht werden. Performance-Tests zeigten, dass das System auf diese Weise in der Lage ist bis zu 9.000 Events pro Sekunde zu verarbeiten. Im Rahmen dieses Projekts habe ich ca. 10.000 Zeilen Perl Code geschrieben.
>> back


Projekt: Aufbau eines Netscreen Client VPN mit Zertifikaten
Unternehmen: Deutscher Energieversorger
Anforderung: Das Unternehmen betreibt einen Netscreen Firewall Cluster und benötigt einen VPN Zugriff für die mobilen Mitarbeiter. Dieser Zugang soll den Mitarbeitern Zugriff auf einen internen Citrix Server gewähren und mittels X509 Zertifikaten (auf einem Token) abgesichert sein.
Umsetzung: Für die Umsetzung wurde der VPN Client von Netscreen gewählt, in Kombination mit Aladdin eToken als Zertifikatsspeicher. Da beim Kunden keine PKI vorhanden war, wurde für dieses Projekt eine CA, basierend auf Microsoft CA aufgebaut. Über diese CA werden die Zertifikate für die User ausgestellt welche dann auf den eToken abgelegt werden. Das Projekt umfasste die Konfiguration des Client VPNs auf dem Netscreen Cluster, die Installation eines Windows 2003 Servers inkl. Microsoft CA in einer virtuellen Maschine (VMWare Server), die Integration der eToken in das Gesamtkonzept und eine Schulung für die Administratoren um das Client VPN eigenständig betreiben zu können.
>> back



Projekt: Troubleshooting - Firewall Performance
Unternehmen: Rechenzentrumsdienstleister für Banken
Anforderung: Das Unternehmen betreibt mehrere Firewall Cluster basierend auf verschiedenen Technologien. Bei einem dieser Cluster (Check Point Firewall-1) kam es in unregelmäßigen Abständen zu Performance Problemen. Die Ursache konnte nicht geklärt werden. Die Performance Probleme waren immer nur von kurzer Dauer und fanden zu unterschiedlichen Zeiten statt.
Umsetzung: Eine Untersuchung der Firewall-Konfiguration zeigte, dass hier kein Fehler vorliegt. Das Problem musste demnach durch äußere Einflüsse verursacht werden. Um herauszufinden was die Ursache für die Performanceeinbrüche war, entwickelte ich mehrere Shell- und Perl-Skripte die verschiedene Parameter des Systems im Betrieb überwachten und aufzeichneten. Nach dem Auftreten weiterer Performanceprobleme, untersuchte ich die gesammelten Daten. Es stellte sich heraus, dass zu den fraglichen Zeitpunkten die Anzahl der "gedroppten" Pakete/Verbindungen extrem schnell anstieg. Dies wurde bis dahin nicht bemerkt, da der fragliche Datenverkehr nicht protokolliert wurde. Daraufhin wurden die Monitoring-Skripte so angepasst, dass bei einem Anstieg dieses Parameters automatisch ein Sniffer (tcpdump) gestartet wurde, welcher über einen begrenzten Zeitraum Daten sammelte. Eine Auswertung ergab letztendlich, dass eine Fehlkonfiguration des Routings zu dem Problem führte. Ein Rechner der nur selten und nur kurzzeitig online war verschickte IP Pakete, die zur Firewall geroutet wurden. Der Routingfehler führte dazu, dass diese Pakete zwischen dem letzten Router und der Firewall solange "im Kreis" geschickt wurde, bis das Paket aufgrund des TTL verworfen wurde. Das führte dazu, dass die Firewall in sehr kurzen Abständen sehr viele Pakete filtern musste, welche zudem immer aufgrund der letzten Regel verworfen wurden. Das große Regelwerk und die schnelle Folge von Paketen führte dann zu dem Performance-Problem. Ein einziger Routing-Eintrag auf dem Router löste das Problem.
>> back


Projekt: Aufbau einer vollständigen Security-Infrastruktur
Unternehmen: Startup im Banken-/Finanzwesen
Anforderung: Das Unternehmen wurde in Deutschland neu gegründet. Da noch keine Infrastruktur vorhanden war, musste diese vollständig neu aufgebaut werden. Das Design wurde im Vorfeld bereits erstellt, so dass es im Rahmen dieses Projektes um die technische Umsetzung ging.
Umsetzung: Im Rahmen dieses Projektes wurde die gesamte Security Infrastruktur neu aufgebaut. Diese bestand aus einem zweistufigen Firewall-Konzept, Content Security Scannern für E-Mail und Web und eines Split-DNS Konzepts. Als Firewalls wurden CheckPoint Firewall-1 und Linux ipchains gewählt. Im Bereich Content Security kam TrendMicro (E-Mail und Web) zum Einsatz. Als DNS Server wurde ISC bind gewählt.
>> back


Projekt: Migration einer Umgebung auf neue Loadbalancer
Unternehmen: Deutscher Industriekonzern
Anforderung: Das Unternehmen betreibt ein internes Directory (LDAP/X500), auf das zahlreiche interne Anwendungen und weltweit mehrere 10.000 User zugreifen. Das Directory stellt dabei einen zentralen Datenspeicher für den gesamten Konzern dar. Die Daten im Directory werden über mehrere Frontend Server zur Verfügung gestellt. Der Zugriff auf diese Frontend Server erfolgte über einen Loadbalancer von Cisco, welcher an Performancegrenzen gestoßen ist. Es wurde die Entscheidung getroffen, zusammen mit der Migration der gesamten Directory Umgebung auf neue Hardware, einen Loadbalancer von F5 zu verwenden.
Umsetzung: Der Cisco Loadbalancer wurde, neben dem Loadbalancing für die Directory Server, zusätzlich für das Balancing von anderen Anwendungen verwendet. Dies sollte sich durch den Einsatz von F5 BigIP nicht ändern. Aufgrund der komplexen Konfiguration und der Änderung der IP Adressen der Frontend Server (Migration auf neue Hardware), wurde eine manuelle Migration der Loadbalancer Konfiguration als zu fehleranfällig betrachtet. Ich habe daher ein Perl Script entwickelt, welches aus der Cisco Konfiguration und einigen Mapping-Tabellen die Konfiguration für den F5 Loadbalancer erstellt hat. Das Erstellen des Scripts hat nicht nur weniger Zeit in Anspruch genommen als die manuelle Migration, sondern hat auch dazu geführt, dass keinerlei Fehler bei der Migration aufgetreten sind. Der Schwenk von der alten Directory Umgebung auf das neue System verlief problemlos, obwohl die Mitarbeiter weltweit und "rund um die Uhr" auf das Directory zugegriffen haben.
>> back


Projekt: Migration einer SQUID Installation
Unternehmen: Deutsches Industrieunternehmen
Anforderung: Das Unternehmen betreibt für ca. 7000 User mehrere SQUID Proxies. Da die Filtermöglichkeiten des SQUID beschränkt sind, sollte eine Migration auf BlueCoat Porxy SG erfolgen. Es sollte die SQUID Konfiguration übernommen werden, inkl. der Funktionalität eigener Filter Module, basierend auf Perl. Zudem sollte die Umgebung von HTTP Basic Auth auf NTLM umgestellt werden
Umsetzung: In diesem Projekt war ich für die gesamte Planung um Umsetzung verantwortlich. Im Rahmen des Projekts mussten im ersten Schritt die bestehenden Systeme (SQUID) und deren Funktionsumfang untersucht werden, um eine adäquate Migration auf BlueCoat Proxy SG durchführen zu können. Eine Herausforderung war es hier die lokalen User Accounts auf dem SQUID Rechner, gegen die Accounts im Microsoft AD zu 'mappen', um herauszufinden, welche Accounts nicht mehr benötigt wurden. Dieses Mapping wurde mittels Perl und LDAP Abfragen gegen das AD durchgeführt. Des Weiteren mussten die NTLM Authentisierung geplant und getestet werden. Um SSL Verbindungen, für die User transparent, aufbrechen zu können, war es notwendig eine CA aufzubauen und den Rollout Prozess für die Zertifkate zu definieren. In diesem Projekt wurde einige kleinere Perl Scripte entwickelt, um die Konfiguation und das Management der Proxies (Backup, Logauswertungs, usw.) zu automatisieren.
>> back


Projekt: Automatisierung von Loadbalancern
Unternehmen: Deutsches Industrieunternehmen
Anforderung: Das Unternehmen betreibt mehrere F5 Loadbalancer Cluster (> 20). Diese Loadbalancer werden benötigt um den Zugriff auf zentrale Anwendungen performant und ausfallsicher zu gestalten. Die Konfiguration der Cluster erfolgte rein über die administrative Schnittstelle via https (Web-GUI). Aufgrund der Vielzahl der Loadbalancer und der Applikationen wurden Änderungen an der Loadbalancer Konfiguration immer komplexer und führten dazu, dass z.B. Releasewechsel der Applikationen nicht mehr im Rahmen eines Wartungsfensters durchgeführt werden konnten. Zudem stellte die manuelle Konfiguration eine erhebliche Fehlerquelle dar.
Umsetzung: Im Rahmen eines längerfristigen Projektes habe ich mittels Perl ein System zur automatischen Konfiguration sämtlicher F5 Loadbalancer Cluster entwickelt. Durch dieses System können die Loadbalancer nun innerhalb von wenigen Minuten konfiguriert werden (früher teilweise Stunden). Die benötigte Loadbalancer Konfiguration wird aus einer Datenbank ausgelesen, welche wiederum durch die automatische Installation und Konfiguration der Anwendungen bestückt wird. Dadurch konnte eine Fehlkonfiguration der Loadbalancer zu fast 100% eliminiert werden. Im Rahmen dieses Projekts habe ich ca. 30.000 Zeilen Perl Code geschrieben.
>> back


Projekt: Mandantenfähige Proxy Infrastruktur mit BlueCoat ProxySG
Unternehmen: Banken RZ
Anforderung: Das Unternehmen betreibt mehrere BlueCoat Proxy-Cluster (> 15). Diese Loadbalancer werden benötigt um den Kunden (Mandanten) Zugriff auf Internet-Ressourcen zu gewähren. Es sollen alle Inhalte nach Schadcode untersucht werden. Der Zugriff auf bestimmte URLs (Kategorien) soll geblockt werden und alle SSL Verbindungen sollen aufgebrochen werden. Die Herausforderung hierbei ist, dass die ca. 300 Kunden (Mandanten), mit insgesamt ca. 30.000 Usern, in der Lage sein sollen, die Filter-Policy für Ihre User selbst zu definieren. Im gleichen Projekt sollten den Mandaten die Proxy Log-Files zur Verfügung gestellt werden. Hierbei sollte jeder Mandant nur seine eigenen Log-Einträge einsehen können.
Umsetzung: Da die BlueCoat Proxies nicht mandantenfähig sind (es gibt bei der Administration kein Rollenkonzept), musste eine andere Lösung gefunden werden, um den Kunden/Mandanten die Konfiguration der eigenen Filterpolicy zu ermöglichen. Die Lösung bestand in der Entwicklung eines Web-Service, welcher es den Mandanten erlaubt bestimmte Regel zu definieren. Aus dieser Meta-Konfigurationen wird in einem Workflow die Konfiguration der Proxy-Cluster erzeugt (CPL File). Dieses Policy File wird automatisch und zyklisch auf den Proxy-Clustern installiert. An der Entwicklung des Web-Services habe ich beratend mitgewirkt und CPL Templates entwickelt.
Um die Logfiles ebenfalls mandantenfähig zur Verfügung stellen zu können musste ein "Logsplitter" entwickelt werden. Diesen Logsplitter habe ich in Perl entwickelt und der Code umfasst ca. 8000 Zeilen Code. Der Logsplitter parst die Original Proxy Log Files und extrahiert jeweils alle Log-Zielen, die einem Mandanten eindeutig zuzuordnen sind (anhand von IP Adressen, User-Namen und Domain-Gruppen). Die aufgeteilten Log-Files werden auf einem FTP Server abgelegt. Von dort können sich die Kunden/Mandaten, ihre Log-Daten herunterladen.
>> back



Projekt: Migration von zwei PIX Firewalls auf einen Astaro Firewall Cluster
Unternehmen: IT Unternehmen eines deutschen Industrie Konzerns
Anforderung: Das Unternehmen nutze zwei Cisco Pix Firewalls und eine Astaro Firewall. Die Aufgabe bestand in der Konsolidierung der drei Geräte auf ein einen einzigen Astaro Firewall Cluster. Die Herausforderung in diesem Projekt bestand zum einem in der übernahme der umfangreichen Regeln der beiden Pix Firewalls und der gesamten Netzwerk-Objekte (mehrere tausend Objekte) und zum Anderen in der gleichzeitigen Migration von Astaro V6 auf Astaro V7. Eine manuelle Migration wurde in Betracht gezogen, jedoch verworfen, da zu fehleranfällig und zu zeitintensiv.
Umsetzung: Da eine manuelle Migration aussichtslos war, musste ein Automatismus geschaffen werden um die Konfiguration der beiden Pix Firewalls in die Astaro Firewall zu übernehmen. Im Rahmen dieses Projekts habe ich einen Parser für die Pix/Astaro Konfiguration in Perl entwickelt. Mittels dieses Parsers war es möglich die Netzwerk Objekte und die Firewall-Regeln in das Astaro Format zu übertragen. Die besondere Herausforderung war hier, dass weder für die Pix Firewall noch für die Astaro Firewall Config-Parser zur Verfügung standen (z.B. in Form von OpenSource). In Folge dessen musste in einem ersten Schritt das Konfigurationsformat der Pix und der Astaro Firewall via "Reverse Engineering" entziffert werden. Ungeachtet dieser Hürde, hat es nur wenige Tage in Anspruch genommen den Parser zu schreiben. Die Migration der gesamten Konfiguration, inkl. Upgrade auf eine neue Astaro Firmware und Hardware, konnte so, im Rahmen eines Wartunsgfensters, an einem einzigen Wochenende durchgeführt werden. Mit Ausnahme von ein paar unbedeutenden Fehlern in der Konfiguration (falsche Netzmasken), ist nach der Migration kein größeres Problem aufgetreten. Es zeigte sich, dass die automatische Migration nur einen Bruchteil des Aufwand benötigte, im Vergleich zum geschätzten Aufwand bei einer manuellen Migration. Der hierbei entwickelte Perl Code umfasst ca. 5000 Zeilen.
>> back


Projekt: Netzwerk Troubleshooting (ERP auf AS/400)
Unternehmen: Kartonagen Hersteller in Dänemark
Anforderung: Das Unternehmen hatte ein neues Datacenter in Kopenhagen aufgebaut. Seit Inbetriebnahme des Datacenters kam es immer wieder zu Abbrüchen beim Datenaustausch zwischen einem Datawarehouse (Windows 2003) und einem ERP System (AS/400). Dies führte dazu, dass die Daten im Datewarehouse nicht konsistent und somit nicht brauchbar waren. Ein weiteres Problem trat beim Zugriff auf den Lotus Notes Server auf. Die Synchronisation einzelner Datenbanken war hier deutlich zu langsam. Umsetzung: Um das Problem zu analysieren wurde der Datenverkehr an verschiedenen Stellen im Netzwerk mitgeschnitten (Sniffer an Span/Mirrot-Ports der Switches). Dann wurde versucht das Problem nachzustellen, was in diesem Fall einige Stunden an Testläufen benötigte, da der Fehler nur einmal in ca. 3-5 Stunden auftrat. Die Auswertung der Files erfolgte mittels selbst entwickelter Scripte (Perl) und Wireshark. Nach einer Differenz-Analyse der Capture Files stellte sich im Falle der ERP Zugriffe heraus, dass die Konfiguration eines Cisco Routers, in Kombination mit WCCP und eines Riverbed WAN Beschleunigers, nicht korrekt arbeitete, so dass einzelne TCP Sessions dadurch abgebrochen wurden. Nach einer Re-Konfiguration des Routers war das Problem beseitigt. Für den zu langsamen Lotus Notes Zugriff reichten die Capture Files nicht aus, um das Problem zu identifizieren. Der Notes Client wurde daher im Debug-Mode betrieben und die dort gesammelten Daten wurden in Beziehung gesetzt mit den Netzwerk-Daten. Es stellte sich heraus, dass es eine Protokoll-Inkompatibilität zwischen der Version des Notes Clients und des Notes Servers gab, welche zu den Verzögerungen führte. Ein Update des Clients beseitigte das Problem, welches erst nach einem Update des Notes Servers aufgetreten war und damit nicht in Zusammenhang mit dem neuen Datacenter stand.
>> back


Projekt: Migration Astaro Cluster nach CheckPoint via Script
Unternehmen: IT Unternehmen eines deutschen Industrie Konzerns
Anforderung: Migration eines bestehenden Astaro Firewall Clusters nach CheckPoint Firewall-1. Die Aufgabe bestand in der automatischen Migration der Konfiguration, da eine manuelle Übernahme der Konfiguration nicht durchführbar erschien (> 1000 Regeln, > 50 VPNs, mehrere tausend Objekte).
Umsetzung: Für die automatische Migration der Astaro Konfiguration wurde ein Konverter entwickelt, der in der Lage ist, Objekte, Regeln und VPNs vom Astaro Format in das Objekt-Format von CheckPoint zu überführen. Hierbei werden Plausibiltäts-Checks durchgeführt und es besteht die Möglichkeit die neuen Objekte, gemäß eines vorgegebenen Namensschemas, zu erstellen. Im Rahmen dieses Projekts wurde ein Parser für die Astaro V7 Konfiguration entwickelt und ein Objekt-Generator für CheckPoint R65. Der hierbei entwickelte Perl Code umfasst ca. 3500 Zeilen.
>> back


Projekt: F5 iRule Programmierung - Webform Authentisierung
Unternehmen: Internationaler Technologiekonzern (Hersteller von Laptops, Unterhaltungselektronik, etc.)
Anforderung: Ablösung einer bestehenden Lösung für die Authentisierung via Web-Formular, inkl. SSO (Single Sign On). Das bislang genutzte Produkt, Novell iChain, wird nicht mehr weiterentwickelt und die Funktionalität sollte mittels eines F5 Loadbalancers umgesetzt werden.
Umsetzung: Im Rahmen dieses Projekts habe ich eine iRule entwickelt um die iChain Funktionalität auf einem F5 Loadbalancer umzusetzen. Die iRule weist folgende Merkmale auf.
  • Authentisierung für eine HTTP(S) VIP via Web Formular (POST Request). Das gesamte Formular, inkl. Logos (GIF, JPEG), wird von der iRule ausgeliefert.

  • Authentisierung mittels LDAP oder RADIUS (in der iRule konfigurierbar)

  • SSO (Single Sign On) für mehrere Domains. Ein Session-Cookie wird für alle Domains (konfigurierbar) gesetzt.

  • SSO mit Weitergabe der User Credentials an den Backend-Webserver (HTTP Authorization Header). D.h. der User meldet sich nur einmal am Web Formular an, und ist dann automatisch für alle konfigurierten Domains authentisiert und hat Zugriff auf die internen Anwendungen.

  • Cookie Rewriting, falls intern eine andere Domain verwendet wird.

  • Host Header Rewriting, falls intern eine andere Domain verwendet wird.

  • HTTP Request Rewriting, falls intern andere Pfade verwendet werden

  • Session Timeout (konfigurierbar). Nach dem Timeout muss sich der User an dem Web-Formular der iRule neu anmelden.

Diese iRule wird verwendet um den Zugang zu Lotus Notes Webmail und anderen Web-Portalen abzusichern.
>> back