Ist es möglich, eine Firewall zu erstellen, die nur legitimen Webserververkehr auf Port 443 und keinen anderen Dienst zulässt?


19

Ich habe immer den einfachen Trick verwendet, um die meisten Firewalls zu umgehen, wodurch ich keine Ports verwenden konnte. Ich habe einfach ssh auf einem meiner Server auf Port 443 geöffnet und den gesamten Datenverkehr durch diesen getunnelt.

Allerdings bin ich jetzt in einem Netzwerk, das eine Firewall hat, die ich noch nie gesehen habe, und ich wusste nicht einmal, dass es möglich ist.

In diesem Netzwerk können Sie den 443-Port nur für legitimen Webserver-Datenverkehr verwenden. Wenn ich ssh oder irgendetwas anderes auf Port 443 öffne und versuche, von diesem Netzwerk aus eine Verbindung herzustellen, wird es sofort beendet. Wenn ich Apache auf diesem Server starte, funktioniert es.

Wie ist das überhaupt möglich? Gibt es einige hochentwickelte Firewalls, die sogar verschlüsselten Datenverkehr analysieren können, um sicherzustellen, dass es sich um legitimen https-Datenverkehr handelt? Wie?


4
Die als SPI bezeichneten High-End-Geräte können erweiterte Inspektionen durchführen und unerwünschte Verbindungen beenden.
Linef4ult

Sie könnten eine Whitelist erstellen und nur den Datenverkehr zulassen. Das Problem besteht darin, dass sich der legitime Webserver-Datenverkehr ändern kann. IP-Adressen können neu zugewiesen werden. Was also heute Microsoft sein könnte, könnte morgen Google sein. Verwenden Sie besser einen sicheren Tunnel, um mit Ihren Servern zu kommunizieren, und erstellen Sie eine Whitelist mit zulässigen Clients. Legen Sie dann fest, wie in Zukunft weitere Clients hinzugefügt werden sollen (da sich diese Liste ändert).
Ramhound

Sie könnten zB Obfsproxy verwenden, um den SSH-Verkehr als harmlosen HTTP (S) -Verkehr zu verschleiern.
Michael

Antworten:


26

Ja, und sie brauchen hier keine Magie, nur triviale Übereinstimmungen in Bezug auf den TCP-Paketinhalt. Obwohl SSH und TLS (SSL) ihre Nutzdaten verschlüsseln , sind die Protokollheader selbst immer noch unterscheidbar und sehr unterschiedlich voneinander. Beispielsweise beginnt eine SSHv2-Verbindung immer mit dem Senden des Clients SSH-2.0-(client name and version). In ähnlicher Weise , obwohl Ihre Firewall kann wirklich wissen , ob die TLS - Verbindung überträgt HTTP nach innen, kann es erkennen TLS selbst .

Eine solche Überprüfung von Schichten über TCP fällt im Allgemeinen unter "Deep Packet Inspection", ein relativ häufiges Merkmal.

Eine naheliegende Möglichkeit, dies zu umgehen, besteht darin, SSH in TLS zu tunneln - beispielsweise mithilfe von Stunnel, Haproxy oder Sniproxy. (Zusätzlich zum einfachen Tunneln, bei dem Port 443 für SSH-over-TLS reserviert ist, können sie auch SSH / HTTP / andere Protokolle auf der Basis von SNI und ALPN über denselben Port multiplexen.)

Dies würde zwar nicht immer eine wirklich ausgefeilte Verkehrsanalyse zunichte machen, aber dennoch die meisten Filter umgehen, bei denen lediglich geprüft wird, ob dies wie ein TLS-Header aussieht.


Und dann gibt es noch die nervigen Firewalls, die TLS abfangen , um den gesamten Datenverkehr zu entschlüsseln und neu zu verschlüsseln. Diese können tatsächlich in TLS sehen und HTTP-Anforderungen weiterleiten, während alle anderen blockiert werden. (Beachten Sie, dass einige Antivirenprogramme dasselbe tun.) Sie können diese Art erkennen, indem Sie sich die Serverzertifikate ansehen. Alle vom Proxy generierten Zertifikate sehen gleich aus und bestehen die Validierung häufig nicht, während echte Zertifikate von verschiedenen Zertifizierungsstellen ausgestellt werden.


1
Also macht SSH seine eigene Sicherheit auf Anwendungsebene, anstatt nur ein anderes Protokoll über TLS zu sein (welches standardmäßig nicht verwendet wird)?
Medinoc

2
@Medinoc: Ja, es implementiert ähnliche Merkmale (im SSHv2 „Transport“ und „Authentifizierung“ Schichten ) und nicht TLS für etwas brauchen.
Grawity

Gibt es eine zuverlässige Möglichkeit, diese schnüffelnden Firewalls zu erkennen? Mir gefällt die Idee nicht, dass jemand meine Passwörter abfängt, während er https verwendet. Ich wusste nicht einmal, dass es bis jetzt möglich ist.
Petr

2
POST / HTTP / 1.0 base64garbage HTTP / 200 200 OK base64garbage erstellt ein Transportprotokoll
Joshua

3
@Petr Wenn es sich bei grawity um einen arbeitgebereigenen Computer handelt, wurden die Zertifikate wahrscheinlich installiert, bevor sie Ihnen übergeben wurden. und die MITM-Firewall wird so konfiguriert, dass, wenn Sie ihr Zertifikat nicht verwenden, kein https-Datenverkehr zugelassen wird, sodass Ihre Auswahl den Richtlinien entspricht oder keine https-Daten enthält. In diesem Fall sagt OTOH beim Überprüfen des Zertifikats wahrscheinlich etwas wie "Geprüft durch den Arbeitgebernamen" und etwas Ähnliches im CA-Namen, wenn Sie tiefer gehen. zB auf meinem Arbeitscomputer ist es bluecoat.companyname.com (wobei bluecoat die Marke der verwendeten Firewall ist).
Dan Neely
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.