Palo Alto und Lync

Lange Jahre haben Firmen wie Checkpoint, Cisco mit ihren klassischen Firewalls den Markt dominiert. Die meisten Regelwerke beschränkten sich auf Source-IP, Destination-IP und Ports. Ob über den frei geschalteten Port aber dann tatsächlich das Protokoll abgewickelt wurde, wurde nicht weiter untersucht. Der Port 443, der eigentlich nur für HTTPS gedacht war, ist mittlerweile schon ein "universeller Firewall Tunnel Port", über den sehr viele andere Dienste mit abgewickelt werden, sei es Dateitransfer, Fernsteuerung (z.B. TeamViewer etc.) oder mittlerweile auch SIP.

Daher mussten die Firewall-Anbieter "schlauer" werden und am Beispiel einer Palo Alto konnte ich die Entwicklung einer "Next Generation Firewall" selbst betrachten. Diese Seite soll nun nicht die Palo Alto oder andere Firewalls im Detail beschreiben, sondern ich möchte an einem aktuellen Supportcase die Fallen und Komplexität mit aufzeigen.

Federation und Office 365

Angefangen hat alles damit, dass ich über meinen Lync Server samt Edge Server eine Federation zu verschiedenen anderen Firmen hatte und auch die Federation zu Office 365 aktiviert hatte. Das hat jahrelang sehr gut funktioniert. Nur im Zeitraum Nov/Dez 2013 war die Federation zu Office 365 plötzlich unterbrochen. Im ersten Moment schreckt das erst mal nicht auf. Es kann schon mal passieren, dass eine Verbindung zu einem anderen Edge-Server nicht möglich ist und vielleicht hat jemand ja den sipfed.online.lync.com:5061 einfach geflutet o.ä.

Aber als das Thema nach mehreren Tagen noch nicht ausgesessen war, musste doch eine tiefere Fehlersuche folgen.

SIP-Trace und NetMon

Also rauf auf den Edge und mit Snooper so ein Paket angeschaut und auch schnell fündig geworden:

Hier kommt ausgehend ein "504 Server time-out" zurück, weil die TLS-Verbindung zum nächsten Edge-Server nicht aufgebaut werden konnte. Nächster Schritt war ein Packet-Trace mit Netmon oder Wireshark. Die Ergebnisse sind zweifelsfrei

Der Client versucht eine Verbindung zum Edge Server und der "drei Wege Handshake" kommt zustande. Dann sendet der Client den Start des SSL-Tunnels mit einem "Client Hello". Hier werden noch keine Zertifikate o.ä., verwendet, sondern der Client sagt erst mal, dass er TLS machen will und welche Cipher-Suiten er versteht. Aber darauf kommt anscheinend von der Gegenseite dann ein "RESET" zurück.

Office 365 ist Schuld ?

Zuerst habe ich natürlich dennoch den Fehler bei mir gesucht. DNS-Einträge waren in Ordnung, auch die Zertifikate waren alle noch gültig. Die Intermediate-CAs waren sauber installiert und die Liste der Stammzertifizierungsstellen nicht aufgebläht. Zudem wurden in den letzten Wochen keine größeren Änderungen durchgeführt. Eigentlich spricht alles dafür, dass auf der Gegenseite was passiert sein könnte.

Zum Glück habe ich auch einen Office 365-Vertrag, auch wenn ich dort weder Exchange noch Lync produktiv nutze. Aber für DirSync, ADFS, SharePoint etc. ist Office 365 schon interessant. Also habe ich dort gegen 20:00 abends ein Ticket eingestellt und bin nach Hause gefahren.

Im Homeoffice habe ich am PC noch etwas weiter gearbeitet, als um 23:00 uhr MEZ ein Anruf von "anonym" ankommt. Und natürlich war es ein Supporter von Office 365 der aus Indien in der "Pacific Time Zone" arbeitet und das Ticket abarbeiten wollte. Vielleicht waren einfach aktuell keine sonstigen Tickets da aber eine Reaktionszeit von unter 4h fällt mir positiv auf. Noch positiver überrascht war ich von der Fachkompetenz, mit der er per Fernwartung geflissentlich meine Konfiguration überprüft, und natürlich nicht gefunden, hat.

Was mir aber wichtiger war, war seine Versicherung, dass Microsoft auf ihrem Office 365 Edge kein Throttling oder DoS-Filter nutzt, Es konnte also nicht sein, dass mein Edge-Server aufgrund eines negativen Ratings o.ä. geblockt wurde. Das ist schon mal eine wichtige Information.

Wir haben uns dann nach ca. 1h den Call unterbrochen, damit er die gezogenen Logs weiter betrachtet und ich am nächsten Tag doch noch mal die Firewall genauer anschaue.

Die Firewall ist immer Schuld

Konfrontiert mit der Information, dass wir von Office 365 einen "RESET" bekommt und die Bitte diese Pakete in der Firewall zu tracken ist dann doch schnell aufgefallen, dass nicht Office 365 oder eine Zwischenstation auf dem Internet das Problem ist, sondern das Paket schon gar nicht auf die WAN-Leitung gesendet wurde und die Firewall aktiv einen RESET generiert. Es ist aber kein ICMP-Not Reachable, sondern die Firewall lässt den 3-Wege-Handshake erst einmal zu und erst beim SSL-ClientHello kommt der Rest. Und das war sogar im Log zu sehen.

Beim Versuch die "Allow"-Regel entsprechend anzupassen ist uns dann etwas interessantes aufgefallen. Es gibt neben der "Gruppe" ms-lync", welche die einzelnen Funktionen von Lync zusammen fasst nun noch drei weitere "Application"-Einträge:

Die Palo Alto unterscheidet nun auch noch die Lync Verbindung zu Microsoft Online und diese drei Einträge sind nicht Bestandteil der "ms-lync"-Gruppe. Ich kann nun nicht genau sagen, wann diese neue Regeln dazu gekommen sind, aber erst nachdem wir diese ebenfalls explizit erlaubt haben, funktionierte auch die Federation zu Office 365-Firmen auf Anhieb.

Auf der Seite https://applipedia.paloaltonetworks.com/ können Sie gut sehen, welche "Applikationen" die Palo Alto alles unterscheiden kann. Und hier ist gut zu sehen, dass die Lync-Einträge für Office 365 in der Office 365 Gruppe enthalten sind

Wer also eine Palo Alto mit Lync On-Prem einsetzt und hierbei bislang die normale "ms-lync"-Gruppe im Policy-Regelwerk verwendet hat, muss nun nachrüsten

Zudem scheint die Palo Alto nicht 100% die Zuordnung korrekt vornehmen zu können. Denn zeitgleich zu dem Update konnte auch Remote Anwender mit dem Lync Client für Windows zwar noch von extern arbeiten aber die Funktion "Screensharing" und "File Transfer" war nicht mehr möglich. Interessanterweise konnte der Anwender weiterhin Presenz und IM aber auch Audio/Video nutzen. Ein neues Regelwerg/Patternupdate/Firmware oder was auch immer hat ein neue „Wissensdatenbank“ addiert und damit Datenverkehre, die bislang unter "ms-lync" gelandet sind, neu klassifiziert.

Bewertung

Auf der einen Seite ist es schon beeindruckend, was heute Firewalls bezüglich Inspektion von Daten auf dem Netzwerk zu leisten im Stande sind. Es ist auf völlig klar, dass diese Erkennung über Muster immer mal wieder aktualisiert werden muss. Hersteller und Produkte verändern ihre Protokolle und daher muss auch eine "Next Generation Firewall" regelmäßig aktualisiert werden.

Besonders interessant finde ich, dass die Palo Alto trotz verschlüsseltem SIP-Verkehr anscheinend allein anhand des ICE-Handshakes oder der Datenlast ermitteln kann, welche Nutzlast hier versucht wird. Das kann sicher nicht nur eine Firewall in ihrer Firma sondern wir sollten davon ausgehen, dass die auch Router-Systeme bei Providern oder Weitverkehrslinks können. Das zeigt einmal mehr, welche AnalyseMöglichkeiten nicht nur Providern sondern sicher auch Geheimdiensten offen steht.

Auf der anderen Seite sind natürlich diese "Updates" der Erkennungslogik auch immer ein Risiko. Neue Erkennungsmuster erlauben bislang falsch oder nicht klassifizierte Inhalte besser zu kennzeichnen und über Policies zu behandeln aber manchmal kann das auch nach hinten los gehen. In Zukunft werden wird also nicht mehr nur mit dem Risiko leben müssen, dass ein Update einer Antivirendatenbank Dienste auf dem Server irrtümlich blockt, sondern auch dass Firewalls einen bislang erlaubten Datenverkehr behindern oder unterbinden. Umso mehr sollten Sie sich Gedanken über ein aktives Monitoring und Funktionskontrolle machen und Zugriff auf die Protokolldateien haben. Auch sollte ein Update entsprechend kommuniziert werden.

Weitere Links