Check Point Maestro – Hyperscaling Performance
Die CPX360 in Wien ist vorüber. Über 4000 Security-Speziallisten aus ganz EMEA konnten sich über die neusten Entwicklungen im Security Umfeld und im speziellen über die neuesten Trends und Produkte von Check Point informieren. Auch ich war dabei und konnte erstmalig die neue Maestro Technologie live bestaunen.
Kurz zusammengefasst handelt es sich bei Maestro Orchestrator um einen Switch, der mehrere normale Firewall Gateways ansteuern kann und so die gesamte Last auf diese verteilt. Durch das Hinzufügen von weiteren Gateways erhält man eine fast lineare Durchsatzsteigerung.
Ein völlig neuartiger Ansatz
Diese Technologie ist ein völlig neuartiger Ansatz, der von den bekannten Firewall-Herstellern bisher nur Check Point im Portfolio hat. Klar gibt es die Scalable Plattforms, d.h. die Check Point Chassis Systeme mit der Hardwareblade-Architektur schon länger, aber bei Maestro kann man ganz gewöhnliche Gateways hinzufügen. Selbst für ganz kleine Unternehmen wird nun eine skalierbare Firewallumgebung, z.B. für die interne Netzwerksegmentierung, realisierbar. Übrigens die Scalable Plattforms werden auch zukünftig weiterentwickelt; Maestro ist somit keine Ablösung dieser Systeme, sondern eine Ergänzung der bisherigen Produktpalette.
Für Check Point ist diese neue Technologie sehr wichtig. Mehrere R&D Engineers waren vor Ort, um den Besuchern jegliche Fragen zu beantworten. Abseits der bisher veröffentlichen Marketing-Folien konnte ich so auch ein paar neue Erkenntnisse gewinnen, welche auch im öffentlichen Check Point Webcast nachzuhören sind.
News, die Begeisterung auslösen
Begeistert bin ich vom Ansatz immer noch. Analog wie Google mit dem Vernetzen von kostengünstigen Servern startete, macht dies Check Point nun genauso. Dazu ist nur die richtige Software nötig und Check Point ist gewissermassen immer noch eine Software Company. Aber gut, jetzt zu den neuen Informationen:
Der Maestro Orchestrator ist ein Mellanox Switch, auf welchem neben dem Switch OS auch GAIA läuft. D.h. es existiert eine GAIA WebGUI zur Administration vom Orchestrator. Der Switch unterhält eine physische Verbindung zu den Gateways mittels redundanter Kupfer-DAC (Direct Attached Cable) und verteilt den Netzwerkverkehr auf diese. Erste Erkenntnis meinerseits: Eine einzelne Verbindung ist maximal nur so schnell wie die Bandbreite eines einzelnen DAC, d.h. 10Gbps oder 40Gbps. Schlussendlich verarbeitet ja auch nur ein Gateway diese Verbindung und der ist auch nur maximal so schnell wie die Performance-Werte auf dem Datasheet.
Security Groups
Security Groups umfassen gleichartige Gateways und definieren so jeweils ein Gateway, d.h. für das Management ist eine Security Group ein Gateway (= 1 Gateway-Lizenz auf dem Management und ein konsolidiertes Log). Es ist auch möglich VSX (bis zu 250 VS) innerhalb von einer Security Group zu verwenden. Durch die Verwendung von Security Groups ist es zum Beispiel möglich, unterschiedliche Anforderungen abzudecken. Z.B. eine Security Group für NGTP und eine weitere für Low Latency-Anwendungen wie zum Beispiel VoIP. Der Maestro Orchestrator kann via RESTful API angesprochen werden und so ist es möglich, völlig automatisch einzelne Gateways von der einen in die andere Security Group zu verschieben, je nach Lastaufkommen. Das Hinzufügen eines neuen Gateways in eine Security Group benötigt manuell nur ein paar Klicks und dann dauert es maximal 6 Minuten, bis der neue Gateway sich den aktuellen Hotfix Accumulator von der Security Group geholt hat, installiert und rebootet. Sobald das Gateway bereit ist, erhält er vom Orchestrator Netzwerktraffic. Analog verhält es sich mit Upgrades oder Ausfällen von einzelnen Gateways. Der Orchestrator erkennt dies und verwendet diese Gateways nicht mehr. Das Ziel ist höchste Verfügbarkeit, Redundanz und Skalierbarkeit.
Vereinzelte Wermutstropfen
Natürlich gibt’s auch hier ein paar Wermutstropfen. Geo-redundante Maestro Umgebungen sowie das Mischen von unterschiedlichen Gateway-Modellen innerhalb einer Security Group wird’s erst im Laufe dieses Jahres geben. Openserver sowie VMware sind nicht supportet und die eingesetzte Check Point Version ist R80.20 SP (Scalable Platforms), welche ein paar Einschränkungen (z.B: beim QoS, Policy Based Routing usw.) aufweist.
Aber aus meiner Sicht überwiegen die Vorteile, gerade in einer dynamischen Umgebung, die jährlich immer mehr Performancebedarf aufweist (z.B.: Private Cloud, SSL-Interception oder Segmentierung), hat man endlich eine passende Antwort parat.
Weitere Informationen zu Check Point findet man auf der AVANTEC Website.
Links
- Mellanox und Check Point: https://www.mellanox.com/page/press_release_item?id=1734
- Webcast: https://pages.checkpoint.com/webinar-maestro.html
- Check Point auf der AVANTEC-Website: https://www.avantec.ch/checkpoint
Der Beitrag Check Point Maestro – Hyperscaling Performance erschien zuerst auf Tec-Bite.
How to secure your containerized web applications with a FortiWeb WAF
These days more and more web applications are being migrated into containers. While this is generally a good idea which increases security (if done right), it is creating some new challenges regarding the protection with a web application firewall (WAF). As long as you run the containers in your own network, you can still use the existing WAF in your network to handle the traffic. But when you deploy the containers in the cloud this will not work anymore. The cloud providers do provide some basic WAF functionality which you can enable (generating additional costs) but this does not really compete with a full blown WAF yet. The good thing is, that Fortinet was the first vendor which released a Docker image for its FortiWeb product. In this post I am going to show you how you can deploy a FortiWeb with Docker to protect your containerized web application.
What is a FortiWeb?
FortiWeb is the web application firewall in the product portfolio of Fortinet. Since they released the product a few years back it has done an amazing journey and is now a leader in the market (Gartner) and independent tests from NSS labs show, that the product is very capable to protect web applications from various attacks while not impacting their performance. You can get a FortiWeb in different flavors, starting with hardware appliances, virtual machines, images for all of the leading public cloud providers and nowadays even as a Docker image.
Dockerized web application
To show you how stuff works I have deployed a DVWA (damn vulnerable web application) in a Docker environment. DVWA is an application created to demonstrate various vulnerabilities in web applications. The app is vulnerable to all of the OWASP top 10 web vulnerabilities. To dockerize the app I have created the following docker-compose.yml file. I have used Docker-Compose to orchestrate the application, obviously you can use any other solution like Kubernetes or anything else. On the right side is a schema of the application.
As you can see, the application consists out of 3 containers so far. A nginx webserver which is serving the static files of the application and exposes port 80 (HTTP) to the outside world. Nginx is talking to a PHP container which is handling all of the PHP files and serves them back to nginx. Finally, the app needs a MySQL database here I used a MariaDB container. There are two persistent volumes which contain the files of the DVWA application and the database. Additionally, the nginx container needs some configuration file so it knows what it should do.
When I bring up the containers on my local machine, I can afterwards access the app via http://localhost. The first time you need to setup the database connection and after that you can login to the DVWA application (Username: admin / Password: password).
Now let’s run some code and SQL injection on the site to show that it is actually vulnerable.
Go to the “Command Injection” page and enter something like “1.1.1.1; cat /etc/passwd” or any other command you like.
Also run some SQL injection on the “SQL Injection” page. Enter “%‘ and 1=0 union select null, concat(user,‘:‘,password) from users #” as the UserID. It will give us back all of the users with their password for the app.
We have proven that the app is vulnerable and now we are going to protect it with our WAF. Obviously in the real world you would also fix the issues in the application itself :-).
Build and deploy the FortiWeb Docker Image
Now we are going to deploy the FortiWeb before the nginx container. The FortiWeb will act as reverse proxy filtering out all of the evil stuff and forwarding only the good requests to the nginx. To do that, we need to stop exposing port 80 to the nginx container and assign that port to the FortiWeb container. You can see our new schema below.
As you can see I have added some more exposed ports. We could use the FortiWeb to serve the application with SSL (tcp/443) if we want. I also added the port 8443 and 8022 so that I can manage the FortiWeb. This is only for the initial configuration, when we deploy the web application we should remove these ports to reduce the attack surface.
I have also added two more persistent volumes to store the data and logs of the FortiWeb.
First we have to build our fortiweb Docker image. When we download the FortiWeb docker release from the Fortinet Support-Portal, we will get a Dockerfile and some filesystems along with it.
Let’s build the image with: docker build –t fortiweb .
Then we will change our docker-compose.yml file and add the FortiWeb to it. We add the following service and remove the exposed port from nginx.
fortiweb: container_name: 'fortiweb' build: ./image-docker-64 image: 'fortiweb' restart: always environment: - FWB_ADMIN_PASSWORD=password volumes: - fortiweb-data:/data - fortiweb-log:/var/log ports: - "80:80" - "443:443" - "8443:43" - "8022:22" networks: - dvwa-network
To bring up our app with the FortiWeb in front of it, run „docker-compose up –d“.
We should be able to access our FortiWeb Admin-Webinterface via https://localhost:8443. Login with admin user and the password you specified in the docker-compose file.
Now we need to configure the FortiWeb, so it is acting as reverse proxy and protecting our web application. I have created a policy which is listening on port 80 and forwarding requests to the nginx container. Please note that I have added the builtin „Inline High Level Security“ profile to the policy which should stop all attacks.
As soon as the policy is in place, I am able again to connect to the web application via http://localhost. The app looks exactly the same but if I try the SQL Injection or any other vulnerability, I get blocked by the FortiWeb.
And in the logs of the FortiWeb I can also see that an attack was blocked.
The containerized web application is now protected by the FortiWeb WAF! After everything is tested you can deploy your setup to production. If it is possible you should also deploy the persistent volume (fortiweb-data) along with it since it contains the whole configuration and other data. If you cannot deploy the whole volume, you can extract the configuration from the volume under „/data/config/“. There should be two .gz files which contain the configuration.
Links
More details on FortiWeb: https://www.avantec.ch/loesungen/fortinet/fortiweb/
Web application firewall (WAF): https://en.wikipedia.org/wiki/Web_application_firewall
NSS Labs test on FortiWeb: https://www.fortinet.com/content/dam/fortinet/assets/analyst-reports/Brochure-NSS-Lab-Independent-Validation.pdf
Der Beitrag How to secure your containerized web applications with a FortiWeb WAF erschien zuerst auf Tec-Bite.
SPF/DKIM/DMARC oder warum Google meine Mails nicht mag
Hast Du schon einmal ein Mail an eine Gmail Adresse geschickt und das Mail wurde mit folgender Fehlermeldung abgewiesen?
Reason: 4.3.2 – Not accepting messages at this time (‚421‘, This message does not have authentication information or fails to pass authentication checks. To best protect our users from spam, the message has been blocked. Please visit https://support.google.com/mail/answer/81126#authentication for more information.
Und nach ein paar weiteren Versuchen des Mailservers dann:
Reason: 5.4.7 – Delivery expired (message too old) [Outgoing] (‚421‘, This message does not have authentication information or fails to pass authentication checks. To best protect our users from spam, the message has been blocked. Please visit https://support.google.com/mail/answer/81126#authentication for more information
Oder noch besser, das Mail wurde von Gmail angenommen, aber klammheimlich in den Spam-Folder einsortiert, auch wenn es sich um eine ganz normale persönliche Mitteilung handelt, weder Spam noch sonstiges Massenmail?
Das Verhalten von Google ist für Aussenstehende völlig intransparent: Manche Mails werden abgewiesen, manche gelöscht, manche werden problemlos zugestellt. Es scheint, dass die Mailzustellung per IPv6 restriktiver eingeschränkt wird als per IPv4. Was genau aber Google an den Mails zu kritisieren hat, wird aber leider nicht bekanntgegeben.
Laut der Fehlermeldung und den Angaben unter obigem Link möchte Google also, dass unsere Mails authentisiert sind. Abgesehen davon, dass man die Authentizität von Mails besser durch eine S/MIME Signatur sicherstellen würde: Zur hier gemeinten Authentisierung von Mails gibt es aktuell zweieinhalb Verfahren: SPF, DKIM und DMARC. Weil diese entgegen der obigen Aussage von Google nichts mit der Vermeidung von Spam zu tun haben, möchte ich diese Verfahren hier und den folgenden Artikeln (etwas vereinfacht) erklären.
SPF
- Ziel: Verhinderung von Mail Spoofing: Kein Fremder soll Mails in meinem Namen verschicken können.
- Wie: In einem DNS TXT Record wird hinterlegt, welche Server Mails mit einer bestimmten Absenderdomain schicken dürfen und welche nicht.
- Der empfangende Mailserver
- überprüft den Hostnamen im EHLO/HELO und vergleicht ihn mit dem SPF Record.
- überprüft die Domain im Envelope MAIL FROM und vergleicht sie mit dem SPF Record.
Beispiel
dig avantec.ch txt +short
„v=spf1 MX -all“
Dies bedeutet, dass nur die im MX DNS Record hinterlegten Mailgateways Mails mit der Absenderadresse «avantec.ch» verschicken dürfen. Dies wären also folgende 4 IP Adressen:
$ dig avantec.ch mx +short
20 mail2.avantec.ch.
10 mail.avantec.ch.
$ dig mail.avantec.ch a mail.avantec.ch aaaa +short
194.191.40.74
2001:67c:1300:141::74
$ dig mail2.avantec.ch a mail2.avantec.ch aaaa +short
194.191.40.94
2001:67c:1300:141::94
Probleme
Somit dürfen nur noch unsere eigenen Mailgateways Mails in unserem Namen verschicken. Dies war in diesem Fall ja einfach!
Als Mail-Admin in einem Firmenumfeld aber herauszufinden, wer alles (berechtigterweise) seine Maildomäne benutzt, ist gar nicht so einfach. Werden gewisse Dienste bei AWS oder Azure betrieben und verschicken Statusmails? Wird ein Webserver irgendwo extern gehostet? Verschickt die Marketing-Abteilung Newsletter via einen externen Dienstleister? Verwendet das HR eine Recruitment Plattform, welche Mails verschickt? All diese Quellen müssen in den SPF DNS Record aufgenommen werden, sonst werden diese potentiell von den Empfängern abgelehnt.
Angenommen, auch diese Hürde ist genommen und alle berechtigten Mailsender sind identifiziert: Sind damit nun alle meine Mailprobleme gelöst? Keineswegs! Zwar nimmt jetzt Google (wenn ich Glück habe) meine Mails an, dafür habe ich mir ein anderes Problem eingehandelt: Hat einer meiner Mailempfänger eine Mailweiterleitung eingerichtet (bei der nicht ein neues Envelope MAIL FROM gesetzt wird), so werden meine Mails nicht beim Ziel ankommen. Denn der weiterleitende Server ist natürlich nicht im SPF Record als berechtigter Sender hinterlegt.
«Damit kann ich leben, dafür kann jetzt niemand mehr Mails spoofen und sich als mich ausgeben!» Leider nein, denn SPF stützt sich nur auf den sogenannten Envelope. Ich erkläre dies an einem normalen Brief in einem Couvert: Auf dem Couvert steht die Absender- und Empfänger-Adresse. Diese werden von der Post zur Briefzustellung verwendet. Entsprechend verwendet ein Mailserver (MTA) den Envelope zur Mailzustellung. Dieser Envelope wird durch SPF geschützt. Die Person, welche den Brief erhält, schaut aber primär auf den Kopf des eigentlichen Briefes. Entsprechend zeigt ein Mailclient wie Outlook nicht den Envelope, sondern den Absender aus dem Mailheader.
Ein Phisher, welcher sich als Absender meiner Maildomäne ausgeben will, fälscht also nicht den Envelope, sondern den Mailheader und wird in seinem Vorhaben durch SPF keineswegs eingeschränkt!
Zusammenfassung
- SPF hilft nicht gegen Spam.
- Google und andere grosse Mailempfänger zwingen uns unter dem Vorwand der Spam-Verhinderung SPF einzuführen.
- SPF hilft nur beschränkt gegen Spoofing und Phishing.
- SPF macht Probleme mit Mailweiterleitungen.
- Es ist schwierig herauszufinden, welche Absender in den SPF Record eingetragen werden müssen.
Zugegeben, das Mail Protokoll SMTP stammt aus den Anfangszeiten des Internets und ist tatsächlich nicht mehr ganz zeitgemäss. Andererseits ist es – wie es schon der Name sagt – simpel, zuverlässig, dezentral und funktioniert. Ergänzungen wie SPF erhöhen die Komplexität, sorgen dafür, dass Mails nicht mehr zuverlässig zugestellt werden können und lösen Probleme, welche gar nicht bestehen. Aus diesen Gründen bin ich kein grosser Fan von SPF. Trotzdem nötigen uns die paar wenigen grossen Mailboxbetreiber, diese Technologien umzusetzen.
Ob die weiteren Mail Authentisierungs-Erweiterungen DKIM und DMARC besser abschneiden und wie man diese am besten implementiert, werde ich in einem der folgenden Artikel erläutern.
Links:
Alles über E-Mail Security: https://www.avantec.ch/themen/e-mail-security/
Der Beitrag SPF/DKIM/DMARC oder warum Google meine Mails nicht mag erschien zuerst auf Tec-Bite.
Insights from CPX – what’s new?
Back from attending Check Point’s employee, partner and customer event CPX360 in Vienna, I have been asked by colleagues and customers “what’s the most noteworthy news or announcement this year?”
Most noteworthy announcement this year
While there’ve been quite a range of interesting sessions on various emerging technologies and products (including CP Maestro, CloudGuard Dome9, extension of CloudGuard IaaS, new appliances, new accelerator cards and much more (including a new partner programme that was received controversially among the partners), I think the most important, and at the same time probably most overlooked announcement, was Check Point’s Infinity 2.0 architecture.
The Check Point Infinity architecture has now been around for a couple of years providing a coherent and consolidated approach to enterprise security. Infinity 2.0 is not just an upgrade or extension to the Infinity architecture, but rather a major strategic announcement of Check Point communicating the ambitions to become a cloud security company.
Infinity 2.0 is the approach of Check Point of dealing with the ever increasing number of (a) potential attack vectors (e-mail, web, mobile, IoT, VMs, SaaS, private cloud, containers etc.) and (b) security technologies (Threat Prevention, Identity Protection, Data Security etc.) that lead to a growing number of attack vector – security technology combinations (think of a table with vectors as rows and security technologies as columns). The new architecture is moving from a quadratically growing approach (number attack vectors multiplied by number of technologies) to linear complexity. This is achieved by differentiating between Security Delivery (channels where attack vectors apply) and Security Services (technologies).
Security Services, Security Delivery and the «fog»
Security Services are centrally available and generic security technologies in the Infinity Cloud that can be instantiated on individual “form factors” by means of Nano Agents (Service Delivery), including for example, on a traditional appliance, a new IoT security gateway, a cloud environment (VM, container, etc.) or via API/SDK directly integrated in third party products. A further element in the new architecture blueprint is the so called “Fog”: a security orchestration piece that sits between the Nano Agents and the Infinity Cloud. Whether the “Fog” will reside on premise or in a local cloud (in the country of the customer) is not clear to me yet, but it seems to have been devised to solve potential challenges of the new architecture model in the areas of privacy, performance or availability.
Admittedly, the concept appears to be still quite “foggy” and it is unclear how and in what time frame it will be implemented. Nevertheless, it is a surprisingly clear commitment of Check Point to becoming a cloud-driven company and the often-omitted part of their company name (“Software Technologies”) might become even more relevant in the future.
Der Beitrag Insights from CPX – what’s new? erschien zuerst auf Tec-Bite.
News zu Fortinet SD-WAN
Ich habe diese Woche an einem Webinar zur SD-WAN Lösung von Fortinet teilgenommen. Das Webinar wurde von Markus Frey, einem SE des Fortinet Schweiz Teams, gehalten. In knapp 45 Minuten wurde die SD-WAN Lösung von Fortinet vorgestellt. Die Präsentation wurde mit einer Live-Demo abgeschlossen. Aber erst einmal von vorne…
SD-What ?
SD-WAN steht für «Software-Defined-Networking in a Wide-Area-Network». Grundsätzlich geht es also darum, dass physikalische Hardware von ihrem Kontroll-Mechanismus separiert werden. Als Beispiel kann man sich einen Router vorstellen, welcher mehrere WAN-Anschlüsse und eventuell noch MPLS Anbindung hat. Die SD-WAN Komponente überwacht die Verfügbarkeit und Qualität aller Pfade. Wenn man nun eine neue Verbindung aufbauen will, wählt die SD-WAN Komponente automatisch den bestmöglichen Pfad für mich aus.
SD-WAN mit Fortigate
Fortinet hat bereits seit der Version 5.6 (2017) das sogenannte «sd-wan» Interface eingeführt welches die SD-WAN Funktionalität ermöglicht. Da ich damals noch einige Probleme damit hatte, habe ich das Feature in produktiven Umgebungen nicht eingesetzt. In der aktuellen Version 6.0 hat sich nun aber einiges geändert und verbessert. Es lassen sich neu auch SLA-Ziele für die einzelnen Links definieren. Ich kann also die Qualität der Anbindung mittels den Parametern Latency, Jitter und Paketverlust messen. Sobald eine Anbindung die Ziele nicht mehr erfüllt, werden die Verbindungen entsprechend auf ein anderes Interface migriert. Sobald sich die Anbindung wieder erholt wird wieder zurückgewechselt. Mit den SD-WAN Regeln, kann ich zudem das Verhalten steuern. Wenn ich z.B. eine Applikation wie Office365 immer über die gleiche Anbindung senden möchte, kann ich dies entsprechend konfigurieren. Das SD-WAN Feature ermöglicht mir also nicht nur die Auswahl des bestmöglichen Pfades, sondern auch ein Load-Balancing über mehrere Anbindungen.
Die SD-WAN Funktionalität auf der FortiGate erfordert keine zusätzlichen Lizenzen und kann auf jeder Hardware eingesetzt werden. Ein grosser Vorteil von der Fortinet Lösung gegenüber der Konkurrenz ist, dass diese die bewährten Security-Features der FortiGate mit SD-WAN kombiniert. Ich benötige also nur ein Gerät für beide Funktionen was gerade in Aussenstellen ein Vorteil sein dürfte.
Use Case: Redundante Branch-Office Anbindung
Ein möglicher Use-Case für SD-WAN wäre zum Beispiel die Anbindung von Branch-Offices an den Firmen-Hauptsitz. Oftmals wird dies heute noch mit dedizierten MPLS-Verbindungen, welche meist sehr teuer sind, gemacht. Nun könnte man zusätzlich noch einen IPSec-Tunnel über eine WAN-Verbindung konfigurieren, oder man spart sich die MPLS-Verbindung gleich komplett und benutzt stattdessen zwei WAN-Verbindungen. Über beide Anbindungen wird ein IPSec-Tunnel zum Hauptsitz konfiguriert. Das SD-WAN Feature wählt dann entsprechend meiner Konfiguration den bestmöglichen Pfad aus.
NSS Labs Test zu SD-WAN
Die Unabhängige Test-Agentur NSS-Labs hat 2018 verschiedene SD-WAN Lösungen getestet (Link Fortinet NSS-Labs). Fortinet hat dabei als einziger Security-Hersteller das Label «Recommended» erhalten. Zudem bietet laut NSS Labs Fortinet das beste Preis-Leistungs-Verhältnis (TCO) aller getesteten Hersteller.
Fazit
Die SD-Wan Lösung von Fortinet bietet mittlerweile einen echten Mehrwert für die Kunden. Gerade bei Firmen mit weltweiten Standorten bietet sich ein grosses Einsparungspotenzial. Durch die Kopplung mit den Security-Features der FortiGate kann auf ein zusätzliches Gerät verzichtet werden.
Falls ihr das Ganze nun noch «live» sehen wollt, könnt ihr das angesprochene Webinar auf Youtube (Link) nachschauen. Oder ihr testet es einfach selbst auf eurer FortiGate!
Links:
NSS-Labs Test: https://www.fortinet.com/content/dam/fortinet/assets/analyst-reports/brochure-nss-lab-independent-validation.pdf
Alles über Secure SD-WAN: https://www.avantec.ch/themen/secure-sd-wan/
Der Beitrag News zu Fortinet SD-WAN erschien zuerst auf Tec-Bite.
Zscaler Customer Group Event – oder wohin die Zscaler-Reise geht
Ich bewege mich nun schon seit 10 Jahren in der Zscaler-Welt – zumindest als Partner – und freue mich immer wieder Manoj Apte zu begegnen. Manoj ist bei Zscaler seit der ersten Stunde, ist Chief Strategy Officer, hat das Produkt Management unter sich und kennt die Architektur in- und auswendig. Manoj ist klug, redegewandt, begeisterungsfähig und unterhaltsam und er gibt Einblicke in die Welt unterhalb der Zscaler-Oberfläche. So auch am Donnerstag, 24. Januar im Zunfthaus zur Zimmerleuten in Zürich am 2. Zscaler Customer Group Event der AVANTEC.
Begeisterung für Zscaler Private Access
Manoj beginnt mit der Zscaler-Story und wie die Cloud Plattform den Unternehmen die Transformation in die Cloud ermöglicht. Sein Lieblingsthema ist längst nicht mehr der cloud-basierte Web Proxy mit dem alles begann. Nein, Manoj ist geradezu begeistert von der neuen Zscaler Lösung Private Access, die es Mitarbeitenden erlauben soll überall auf dieser Welt schnell und sicher auf alle Applikationen zuzugreifen – egal ob im eigenen Rechenzentrum oder in der Cloud. Ein always-on Remote Access quasi ohne die Nachteile von klassischem VPN und damit sicherer und benutzerfreundlicher. Zscaler bringt dabei Applikationen und User zusammen wie früher als die Telefonschaltzentrale noch einzelne Gesprächspartner miteinander verknüpft hat.
Etwas verschwiegen gibt sich Manoj wenn es um die in diesem Zusammenhang längst erwartete Funktionalität einer nahtlosen Verbindung für Server und IOT Devices geht. Auch diese Geräte sollen sicher auf die entsprechenden Applikationen zugreifen können. Site-to-Site VPN würde dann der Vergangenheit angehören. Selbst im Internet findet sich nur wenig dazu. Yogi Chandiramani, Technical Diecctor EMEA von Zscaler, geht auf der Zscaler Community Webseite auch kaum auf eine entsprechende Frage ein. Die sogenannte Zscaler Network Function (ZNF) stehe noch ganz am Anfang. In der Pause vetraut mir Manoj dann doch noch an, dass ihm eine erste Version vorliegt. Gut möglich, dass sie Ende Jahr für alle Kunden zur Verfügung stehen wird. Die Techniker bei AVANTEC gehen davon aus, dass es sich um eine VM handeln wird, die in Aussenstellen installiert werden kann, damit sich alle Systeme nahtlos und sicher mit Internet und Applikationen verbinden können.
Wo Zscaler investiert
Zscaler ist seit letztem Jahr an der Börse und wächst erfolgreich und schnell. Zudem bringt die vermehrte Nutzung von Office 365 massiv Datenverkehr auf die Zscaler Cloud. Da stellt sich natürlich auch die Frage nach den Kapazitäten, der Verfügbarkeit und Zuverlässigkeit der angebotenen Cloud Services. Manoj hat diesen Punkt ganz zuoberst auf der Übersicht, wohin die Reise gehen soll: Investitionen in die Cloud. Für noch mehr Kapazitäten und weiterhin höchste Verfügbarkeit. Tatsächlich können wir uns bei AVANTEC noch gut daran erinnern, als die Zscaler Cloud noch nicht so stabil war wie heute, als wir noch Ausfälle zu beklagen hatten. Aber das ist Cloud Sei Dank schon einige Jahre her 
Und auch unsere österreichischen Kollegen sollten bald ein eigenes Zscaler Datacenter erhalten. Ein definitives Datum ist aber leider noch ausstehend.
Als zweiter Punkt auf der Übersicht folgen Investitionen in die Zscaler App. Die Zscaler App ist mittlerweile die bevorzugte Deployment-Variante für Clients. Grund dafür ist auch, dass die Zscaler App für Zscaler Private Access Grundvoraussetzung ist. Es ergeben sich aber auch für die Zscaler Internet Access Lösung diverse Vorteile und mittlerweile ist die Client-Software stabil und bei vielen unseren Kunden erfolgreich im Einsatz.
In Q2 2019 wird die neuste Version der Zscaler App auch endlich alle Ports und Protokolle unterstützen – ein langerwartetes Feature unserer AVANTEC-Engineers und von vielen Kunden. Die Zscaler Firewall kann dann auch für mobile User vollumfänglich eingesetzt werden. Zu guter letzt wird die Zscaler App schon bald Full Packet Capture unterstützen, was das Troubleshooting zusammen mit AVANTEC und dem Hersteller-Support massiv vereinfachen wird.
Auch ins Reporting wird investiert. Was ich dabei sehr spannend finde: Ein Operations Dashboard, das betriebliche Risiken im Zusammenhang mit der Zscaler-Konfiguration aufzeigen soll. Tunnel-Status, Connectivity, Latenzzeiten – eine Übersicht die frühzeitg auf operationelle Risiken hinweisen soll.
What about Security ?
Zscaler ist aber auch immer noch ein Security Produkt. Manoj sagt, keine Webseite der Welt ist sicher. Damit spricht er die Grenzen von DNS Security und darauf basierende Lösungen wie Cisco Umbrella an. Aber was macht Zscaler in diesem Bereich um mit den Bedrohungen mitzuhalten? Im August 2018 hat Zscaler die AI/Machine Learning Firma TrustPath gekauft. Diese Technologie wird zukünftig in Zscaler Internet Access integriert. Fokus liegt dabei auf dem Erkennen von infizierten Rechnern erklärt Manoj. Beispielsweise sollen DNS Tunnelings analysiert werden oder die Generierung neuer Domänen durch Botnetze. Bots und Botnetze generieren diese unabhängig voneinander auf Basis des gleichen Algorithmus. Machine Learning soll helfen, diese vorauszuberechnen und vorzeitig zu blockieren. Zudem können generelle Anomalien im Kommunikationsverhalten ein Anzeichen für eine Infektion sein. Mit Machine Learning will man dies erkennen und frühzeitig Alarm schlagen.
Und was ist mit Web Isolation? Ein aktuelles Hype-Thema. Ich habe Manoj in den letzten Jahren schon 2x danach gefragt. Bisher bin ich auf taube Ohren gestossen. Zu aufwändig, zu teuer, zu wenig Nachfrage. Manoj schmunzelt beim dritten Mal. Er habe sich erste Gedanken gemacht, wie Zscaler eine skalierbare Isolationslösung aus der Cloud anbieten könne. Wir dürfen gespannt sein!
Link:
Alles über Zscaler: www.avantec.ch/zscaler
General Electric's Network Transformation Journey in 2 Minuten
(Video-Empfehlung von Manoj)
Der Beitrag Zscaler Customer Group Event – oder wohin die Zscaler-Reise geht erschien zuerst auf Tec-Bite.
Im Sandkasten mit den bösen Buben – ein Versuch einer Auslegeordnung zum Thema Sandboxing
An Sandboxing scheiden sich vermutlich die Geister. Die einen Kunden schwören darauf, die Hersteller sowieso, andere leben scheinbar ganz gut ohne diese Technologie. Dennoch lässt sich feststellen, dass die Werbetrommeln dafür auch schon lauter gerührt wurden. Ist der Hype vorbei? Gab es überhaupt jemals einen Hype? Wie viele Kunden setzen Sandboxing ein? In welcher Form und was sind ihre Erfahrungen damit? Und wohin geht die Reise?
Am Anfang stand FireEye
2011 hatten wir erstmals Leute von FireEye bei uns im Büro. 2012 wieder und dann mit viel mehr Begeisterung für die eigene Technologie. So viel Begeisterung, dass wir uns anstecken liessen. Es klang nach einer Wunderwaffe. Einer Wunderwaffe gegen neue unbekannte Bedrohungen, gezielte Angriffe, gegen Exploits, die noch nicht einmal veröffentlicht waren. Eine Hardware mit 64 virtuellen Systemen, die alle möglichen Betriebssystem-Versionen und Softwarestände simulieren, dabei alle Codeschnipsel aus Web Traffic und E-Mail Attachments ausführen und bösartiges Verhalten erkennen können. FireEye kann Angriffe über die Zeit beobachten – vom initialen Befall bis zum Nachladen der eigentlichen Malware – was nur möglich ist, wenn der Exploit zur Beginn der Angriffskette erkannt wird.
Die Realität war aber leider auch, das die Technologie nicht ganz günstig war und in zeitlich begrenzten Teststellungen meist nur wenig Gefährliches gefunden werden konnte. Viele Kunden taten sich schwer damit hohe Investitionen für eine zusätzliche «Versicherung» auszugeben. Das Thema war neu und Aufklärung braucht auch Zeit.
In der Zwischenzeit hat die Konkurrenz aufgeholt und heute bieten fast alle IT-Security Anbieter am Perimeter eine Sandbox an – als Hardware oder als Cloud-Service oder beides.
Wer macht Sandboxing?
Bei AVANTEC setzen heute knapp 40% aller Kunden eine Sandbox-Lösung ein. Zwei Drittel davon nur für E-Mail Security. Dies lässt sich hauptsächlich damit erklären, dass kritische und gezielte Attacken zumeist über den E-Mail Kanal ablaufen oder zumindest E-Mail als einen wichtigen Angriffsvektor nutzen. Die Sandbox wird dabei in 4 von 5 Fällen aus der Cloud bezogen. Die Vorteile dafür liegen auf der Hand: Einfachste Inbetriebnahme, keinen Betriebsaufwand und bzgl. Kosten deutlich günstiger als eine inhouse-Variante.
Ein Viertel unserer Sandbox-Kunden setzt diese Technologie ausschliesslich für den Netzwerk- und Web-Verkehr ein. Dabei halten sich Hardware-Lösung und Cloud Service noch knapp die Waage. Der Trend geht aber klar in Richtung Cloud. Denn Hardware-Lösungen haben einen grossen Nachteil. Sie schützen in der Regel nur die Clients innerhalb des Firmennetzwerks, ja in den meisten Fällen sogar nur am Hauptstandort. Mitarbeitende sind heute jedoch immer mehr ausserhalb des Perimeters anzutreffen. Eine Cloud-Lösung bietet hier den umfassenderen Schutz bei gleichzeitig weniger Betriebsaufwand und tieferen Kosten.
Gerade mal 10% unserer Sandbox-Kunden setzen eine einheitliche Lösung für beide Kanäle ein – E-Mail und Web. Dies mag verschiedene Ursachen haben wie beispielsweise die hohen Investitionskosten, aber auch, dass verschiedene Teams innerhalb der Firma über verschiedene Lösungsbereiche entscheiden.
Zu letzterem Punkt passt auch die folgende Beobachtung: In 4 von 5 Fällen wird die Sandbox als Zusatzlösung oder Service von einer bestehenden Perimeter-Lösung hinzugekauft anstelle der Evaluation und Beschaffung einer komplett neuen Lösung. Ein Trend der sich vermutlich weiter fortsetzen wird.
Sandboxing ist keine reine Security-Technologie für die Finanzbranche. Dies zeigt sich klar, wenn wir uns die Kunden etwas genauer anschauen. Sie stammen aus allen Branchen: nicht nur Banken und Versicherungen, sondern augenfällig in der Industrie oder auch im Retail. Sandboxing wird dort eingesetzt wo das Sicherheitsbedürfnis hoch ist und vielleicht auch gerade dort, wo es zum Zeitpunkt des Sandbox-Hypes einen entsprechenden Vorfall gab.
Erfahrungen aus der Praxis
Sandboxing funktioniert, keine Frage. Die Technologie bietet Chancen noch unbekannte Bedrohungen zu erkennen, welche durch herkömmliche Signaturen und Reputation nicht blockiert werden. Das Thema, dem sich alle Kunden stellen müssen: Wie viel wert ist ein bisschen mehr Security?
Wir hatten beispielsweise bei einem grösseren Industriekunden einen Sandbox-POC durchgeführt und dabei festgestellt, dass mit dieser Technologie durchschnittlich eine zusätzliche Infektion pro Tag verhindert werden könnte. Die Kosten der Lösung lagen bei 180 CHF pro Tag. 180 CHF um eine Infektion verhindern zu können? Mit allen Kosten und Aufwänden, die mit einem solchen Malware-Befall verbunden sind? Das schien vernünftig. Der Kunde hat dennoch nicht gekauft.
Eine interessante Beobachtung ist auch, dass der Fingerprint und Abgleich mit einer weltweiten Datenbank zu bereits getesteten Files den grössten Mehrwert einer Sandbox-Lösung ausmacht. Dies weil die Malware meist schon bei einem anderen Kunden durch die Sandbox lief. Hier konnten wir in verschiedenen Projekten feststellen, dass eine Sandbox-Lösung gerade im Bereich der E-Mail Security eine Vielzahl zusätzlicher gefährlicher Files erkennen und blockieren kann.
Sandbox-Lösungen bringen auch eine minimale Konfiguration mit sich. Ein wichtiger Entscheid gilt jeweils der Frage, ob die Sandbox inline genutzt werden soll, Files zuerst scannt und erst nach erfolgreicher Prüfung freigibt oder ob ein noch unbekanntes Files direkt vom User bezogen werden kann zur Verbesserung der Benutzerfreundlichkeit. Das Risiko dabei ist natürlich einen Patient Zero zu erzeugen.
Unsere Erfahrung zeigt, dass Sandboxen schon mal 5 bis 10 Minuten benötigen um ein File eingehend zu prüfen. Dies ist bei E-Mail in der Regel akzeptabel, im Web-Bereich für Benutzer aber eher nervig. Der gute alte Trade-off zwischen Security und Benutzerkomfort.
Ein interessanter Ansatz bietet hier die Check Point Sandblast-Lösung: Das Extraction-Feature. Der User erhält zunächst das File ohne aktiven Code, später nach erfolgreicher Prüfung das Original-File.
Es gibt Sandboxen die mit einer Vielzahl vorkonfigurierter VM-Systeme versuchen verschiedene Client-Installationen möglichst gut abzudecken. Andere setzen auf die Philosophie, dass der eigentliche Unternehmens-Client mit all seinen Softwareständen auf der Sandbox installiert und konfiguriert werden soll. Letzteres bietet sicher genauere Analysen und gute Sicherheit, aber nur solange die beiden Konfigurationen auch wirklich übereinstimmen, was aufwändig ist.
Die erste Variante hat zudem den Vorteil, dass auch Angriffe erkannt werden, die vielleicht wegen falschen Software-Versionen fehlschlagen, aber die Tatsache, dass es einen Angriff gab ist sichtbar für die Security-Verantwortlichen.
Sandboxing – quo vadis?
Es gibt heute nicht nur diverse Sandbox-Lösungen am Markt, sondern auch alternative Technologien um die Sicherheit nachhaltig zu erhöhen. Einer dieser Trend sind Next Generation Endpoint Security Lösungen, die direkt auf dem Client ansetzen und diesen mit neuen Ansätzen besser schützen. Das Spektrum reicht hier von Privilege Management bis zu Machine Learning und Verhaltensanalyse. Ein anderer Trend ist Isolation. Isolation kann ebenfalls direkt auf dem Endpoint eingesetzt werden oder Server/Cloud-basiert im Netzwerk-Traffic. Hierbei wird aktiver Code in einer isolierten Umgebung ausgeführt und kann auf dem Client keinen Schaden anrichten.
Diese neuen Lösungsansätze werden das Geschäft mit Sandboxing nicht ankurbeln – unabhängig davon, dass Sandboxing seinen Mehrwert für einen höheren Schutzlevel bereits mehrfach unter Beweis stellen konnte. Ich vermute daher, dass Sandboxing mit der Zeit mehr und mehr zu einem Feature werden wird. Die Preise dafür werden sinken und die Technologie kann einfach zum bestehenden Setup hinzu lizenziert werden – vorzugsweise aus der Cloud.
Der Beitrag Im Sandkasten mit den bösen Buben – ein Versuch einer Auslegeordnung zum Thema Sandboxing erschien zuerst auf Tec-Bite.
Check Point Maestro
Es ist wieder so weit, Check Point zelebriert die Neuigkeiten und zeigt diese an den CPX360 Events, die auf fast jedem Kontinent nacheinander stattfinden. Ich plane ja die CPX360 in Wien zu besuchen, aber die CPX360 in Bangkok (CPX Asia 2019) liefert jetzt schon recht interessante Neuigkeiten. Nebst den neuen Firewall Appliances (23900, 6800 und 6500), die ein bisschen schneller und preiswerter sein werden, fällt mir sofort das neue Produkt «Maestro» ins Auge.
Funktionsweise
So wie’s aussieht, werden mehrere Firewalls von einem intelligenten Load Balancer, genannt Maestro Orchestrator, gesteuert. Das aktuelle Schlagwort ist «Hyperscale», was schon in der Public Cloud funktioniert, sollte doch auch im lokalen Datacenter möglich sein. Mehr Bandbreite kann erreicht werden indem man den Verkehr mittels Load Balancer auf verschiedene Appliances aufteilt und somit einen linearen Performancegewinn erreichen soll. Also eine 6500er Appliance liefert 3.4 Gbps Threat Prevention Throughput (=NGTP). Zwei Appliances sollten den doppelten und drei Appliances sollten den dreifachen Durchsatz liefern. Der Ausbau ist, gemäss Datasheet, bis zu 52(!) Appliances möglich. Sehr eindrücklich!
Der Trick besteht darin, dass der Maestro Orchestrator sozusagen das Gehirn ist und die Appliances einzeln ansteuern kann. Gemäss meinem Verständnis wird es eine neue GUI geben, in welcher man die Appliances zu einzelnen «Security Groups» zuweisen kann. Im übertragenen Sinne ist eine Security Group eine virtuelle Firewall, die jeweils aus mehreren physischen Gateways besteht. Eine Appliance kann von einer Security Group «on-the-fly», d.h. ohne Unterbruch, in die andere verschoben werden, um den Durchsatz dieser Security Group zu erhöhen. Auch Upgrades sollen während des laufenden Betriebs, d.h. ohne Unterbruch der Services, möglich sein. Maestro übernimmt die Provisionierung von neuen Gateways – Software Version, Konfiguration und Firewallpolicy werden automatisch aktualisiert und installiert. Also ein echtes «Plug&Play» System. Redundanz über mehrere Datacenter ist auch möglich mittels zwei Maestro Orchestrators, die sich synchronisieren.
Maestro Bundles
Aktuell gibt’s sechs verschiedene Maestro Bundles:
| Maestro Bundle mit | Threat Prevention Performance (Gbps) |
| zwei 6500 Appliances | 6.8 |
| drei 6500 Appliances | 10.2 |
| zwei 6800 Appliances | 17.8 |
| drei 6800 Appliances | 26.7 |
| zwei 23800 Appliances | 21 |
| drei 23800 Appliances | 31.5 |
Ich bin gespannt, ob die versprochenen Durchsatzzahlen auch wirklich eingehalten werden können. An der CPX360 in Wien werde ich mich genauer damit befassen und eine Live Demo verlangen.
Einsatzmöglichkeiten
Nach der anfänglichen Begeisterung («endlich wieder mal etwas Neues in der Firewallszene») frage ich mich selber, wo man so ein Setup sinnvoll nutzen könnte. Von den Check Point Videos entnehme ich, dass man z.B. den Peak am «Black Friday» einfach abdecken könnte. Jedoch frage ich mich, was man anschliessend mit den zusätzlichen Appliances machen soll?
Eine andere Idee ist es eine bestehende Check Point Umgebung mittels weiteren Gateways auszubauen, um so die bestehende Investition zu schützen. Jedoch macht dies nur Sinn, wenn schon von Anfang an das Setup mit Maestro konzipiert wurde.
Wie gesagt, an der CPX360 in Wien werde ich weitere Infos erhalten und darüber berichten.
Links:
- CPX360 Asia: https://www.checkpoint.com/cpx/asia/
- Appliance Comparision Chart: https://www.checkpoint.com/downloads/products/check-point-appliance-comparison-chart.pdf
- Homepage: https://www.checkpoint.com/products/maestro-hyperscale-network-security/
- Datasheet: https://www.checkpoint.com/downloads/products/maestro-hyperscale-orchestrator-datasheet.pdf
- Video (Comic): https://www.youtube.com/watch?v=TR5IfFLUkho
- Video (Marketing): https://www.youtube.com/watch?v=lftPDsao4MM
- Video (technical Overview): https://www.youtube.com/watch?v=ssGmQ8fVTQw
- Weitere allgemeine Informationen zu Check Point auf der AVANTEC-Webseite: https://www.avantec.ch/checkpoint
Der Beitrag Check Point Maestro erschien zuerst auf Tec-Bite.
IoT – wie mit Sicherheits-Risiken umgehen?
Treiber und Business-Nutzen von IoT
Die Kombination verschiedener technologischer Fortschritte wie Miniaturisierung, Connectivity (LoRa, 5G), Energie-effizientes Design und nicht zu letzt auch «Big Data» spannen das grosse Wachstumsfeld der vernetzten Dinge, sprich des Internet of Things (IoT), auf. Gartner sagt voraus, dass im Jahr 2020 über 30 Milliareden IoT-Geräte in Gebrauch sein werden – sowohl im «Consumer» IoT Bereich (man denke an Amazon Alexa oder Philips Hue) wie auch im «Industrial» Umfeld. Hier ergeben sich durch IoT in allen Branchen inkl. Retail, Logistik, Produktion, Energie und Gesundheitswesen neue Anwendungs- und Geschäftsfelder.
Durch IoT lassen sich z.B. verbesserte Produkt- und Kundenerfahrungen erreichen (Produkt-Analytics, personalisierte Produkte), Effizienzsteigerungen umsetzen (Predictive Maintenance, Real-time Monitoring, Optimierungen, Automation) und auch komplett neue Service- und Geschäftsmodelle aufbauen.
Security-Challenges: Limitationen der Devices
Aus Security-Perspektive bringt IoT jedoch auch Risiken durch steigende Komplexität, eine erweiterte Angriffsoberfläche und neue Schwachstellen mit sich. Insbesondere stellen sich bei der Umsetzung von Sicherheits-Controls direkt auf IoT-Devices einige Herausforderungen:
- IoT-Devices sind in der Regel klein, günstig und bieten praktisch keine physische Security
- CPU-, Speicher- und Batterie-Leistung sind limitiert und erschweren oder verunmöglichen klassische Krypto-Mechanismen
- Install-, Upgrade- und Patching-Möglichkeiten sind sehr eingeschränkt
- Grosse Zahl und Heterogenität der Geräte (inkl. komplexer Lieferketten bei der Herstellung)
Security-Mechanismen auf dem Device sind deshalb bei vielen bestehenden Geräten sehr eingeschränkt oder gar nicht möglich. Für laufende und zukünftige Geräte-Entwicklungen ist deshalb essentiell, dass ein Umdenken von «Security as an afterthought» zu «Security by design» stattfindet. Dazu gehören z.B. die Umsetzung von Applikations-Sicherheit, Patch-Management und auch Identity-Management auf dem Endgerät.
Kompensation durch Netzwerk-Security
Der Netzwerk-Security kommt deshalb im Kontext von IoT eine sehr hohe Bedeutung zu, um die Limitationen der bestehenden IoT-Geräte zu kompensieren.
Als erste Massnahme kann über die klassische Netzwerk-Zonierung (z.B. mit Firewalls) und Mikro-Segmentierung von IoT-Geräte-Klassen eine stärkere Kontrolle der Datenströme erreicht werden. Hier stellt sich dann häufig die Frage des Trade-Offs wie weit «ins Feld hinaus» (d.h. zum Edge hin) man aus Kostengründen (Firewall-Kosten) sinnvollerweise segmentieren soll.
Die zweite wichtige Massnahme ist, Visibilität zu schaffen und die daraus gewonnene Sicht zu analysieren. Die Verbindungspfade und Netzwerk-Verhaltensmuster von IoT Geräten geben sehr viel Aufschluss darüber, ob sich ein Gerät gemäss den Erwartungen, also seinem Zweck folgend, verhält. Die Sammlung und Analyse von solchen Netzwerkdaten inklusive intelligente Einordnung von Verhaltensmuster kann heute weitgehend automatisiert erfolgen und somit Security-Analysten und SOC-Mitarbeitende entlasten.
Als dritte Massnahme können dedizierte Kontroll- und Orchestration-Lösungen eingesetzt werden, um IoT-Geräte zu klassifizieren, zu authentisieren oder deren Netzwerkzugang steuern. Da auf den IoT-Geräten selber keine Agents installiert werden können, müssen diese Lösungen «agentless» funktionieren.
Zum Schluss noch eine weitere Vorhersage von Gartner (FWIW): Das IoT-Security Budget eines CIOs wird von 1% (2018) auf 20% im 2020 steigen.
IoT Security Webinar (Deutsch)
Der Beitrag IoT – wie mit Sicherheits-Risiken umgehen? erschien zuerst auf Tec-Bite.