TMG Ersatz
Jahrelang hat der Microsoft ISA/TMG-Server für eine sichere Veröffentlichung von Exchange und Lync gesorgt und ganz nebenbei den Mailserver per SMTP gesichert und ausgehenden HTTP-Traffic als Proxy bedient. Nun sind die Jahre seit TMG2010 vergangen und Microsoft hat das Ende von TMG schon eingeläutet. Da stellt sich die Frage nach dem Ersatz:
TMG Funktionen
Dazu müssen Sie zuerst definieren, welche Funktionen TMG heute in ihrem unternehmen bedient und welche zukünftig durch welche Komponenten abgebildet werden. Auch wenn Microsoft TMG damals als "Firewall" platziert hat, so haben viele Mitbewerber wohl etwas geschmunzelt. Windows und Firewall würde man nicht erwarten, wobei wir damals sogar Checkpoint auf Windows installieren konnten. Dennoch ist die Funktion einer Firewall mittlerweile eher auf Basis von Appliances zu sehen, von denen aber viele durchaus Linux als unterbau nutzen. Einige der Funktionen von TMG sind.
Baustein | Einsatz | Besonderheiten |
---|---|---|
HTTP-Proxy |
Websurfen von Intern zum Internet absichern |
|
HTTP Publishing |
Sichere Veröffentlichung von Webseiten |
|
SMTP-Proxy |
Mail Relay mit SMTP-Verbfilterung |
Habe ich persönlich nie genutzt da die Funktion keinen Spamfilter enthält aber die Source-IP dem nachfolgenden Gerät verborgen hat. |
Portveröffentlichung |
Eingehende Verbindungen für "nicht-HTTP"-Protokolle, z.B. SMTP, RDP, POP etc. |
|
Ausgehend NAT |
z.B. Um von intern bestimmte Dienste (POP, IMAP) zu erreichen, zu denen es keinen Proxy gibt |
|
Eigenschutz |
Der TMG konfiguriert die Windows Firewall, damit nur bestimmte Ports offen sind. |
Normale Windows Firewall Schutzfunktionen unter einer anderen GUI |
Eigene Verfügbarkeit |
Hochverfügbarkeit und Lastverteilung per TM-Farm und NLB möglich |
|
Prüfen Sie, welche dieser Funktionen sie in welchem umfang nutzen und überlegen Sie sich, welche Alternativen zur Wahl stehen.
TMG ist selten allein
In den meisten Fällen gibt es bei den Firmen schon "Alternativen". Während mit dem ISA2004-2006 und den Anfängen von TMG2010 durchaus Firmen einen Windows Server mit dieser Software als Gateway zum Internet benutzt haben, dürften heute die meisten Firmen schon die Funktionen aufgeteilt haben und Firewalls bekannter Hersteller (Checkpoint, Palo Alto, Juniper, Sophos etc.) oder Open Source Projekte (PFSense, ipfire, IPCop, Smooth Wall, Endian)
Beim Zugriff auf das Internet gibt es auch die Dreiteilung, dass kleinere Firmen teilweise komplett auf HTTP-Proxies same Caching, Berechtigung und Filterung verzichten oder diese Filterfunktion nach extern in die Cloud abgeben. Je größer eine Firma aber wird, desto eher werden lokale spezialisierte Proxies eingesetzt, die weit filtern können, als TMG 2010 konnte. Oft kommen hierzu auch Open Source Produkte, insbesondere Squid oder Apache als Proxy zum Einsatz. Teilweise wird der Proxy auch schon durch die kommerzielle Filterlösung (z.B. Antivirenprodukthersteller oder Filterspezialisten wie WebWasher, Bluecoat etc.) bereit gestellt
Oft stellt sich mir daher die Situation dar, dass von der originären Funktion des TMG fast nur noch der Reverse Proxy übrig ist. Diese Funktion allerdings hat TMG2010 lange Zeit sehr gut erfüllt und nicht wenige Firmen würden den TMG2010 dazu gerne noch behalten. Nun ist es aber mittlerweile so, dass selbst Microsoft die Anleitungen zur sicheren Veröffentlichung der eigenen Produkte über TMG nicht weiter führt. Daher ist es höchste Zeit sich nach Alternativen umzuschauen.
Anforderungen definieren
Es wird nicht ganz einfach, eine 1:1 Ersetzung für die Reverse Proxy Funktion von TMG2010 zu finden und ich bin nicht mal sicher, ob man so eine Software dann auch einsetzen möchte. TMG2010 kann sehr viel aber ist natürlich auf dem Stand von damals stehen geblieben. Eine externe Authentifizierung per ADFS-Token z.B. kann er nicht. Diese Funktion ist nun im WAP - Web Application Proxy von Windows 2012 enthalten. Der kann allerdings nur sehr eingeschränkt URLs und Pfade umschreiben und kann z.B. gar nicht cachen oder auf mehrere Backends verteilen. Das kann aber IIS ARR Application Request Routung, der aber keine Firewall ist. Der Windows TCP-Stack kann selbst als NAT-Router (RRAS) agieren aber sogar Reverse NAT, also eine Port-Veröffentlichung bereit stellen. Microsoft positioniert den WAP - Web Application Proxy in Verbindung mit ADFS 2012R2 als Nachfolger des TMG zur sicheren Veröffentlichung von Webseiten samt Preauthentifizierung und wem das nicht reicht, kann Domainmitglieder ja per Direct Access in das LAN einbinden, um die Firewall zu passieren. Aus meiner Sicht ist das aber zumindest noch keine Lösung, so dass ich mir zuerst die Anforderungen anschaue, um dann eine Lösung mit dem Kunden zu erarbeiten.
Ich prüfe daher in der Regel, welcher der folgenden Funktionen benötigt werden und welches System diese dann auch umsetzen kann:
Baustein | Einsatz |
---|---|
HTTP-Proxy |
Ausgehend kann ein Loadbalancer nicht viel unterstützen. Ich habe aber mittlerweile den Eindruck, dass kleinere Firmen den Internet-Zugang entweder kaum noch reglementieren oder schon länger alternative Produkte im Einsatz haben. Viele Firewalls haben auch einen HTTP-Proxy an Bord. |
HTTP Publishing |
Hier ist ein aktueller Load Balancer in den meisten Fällen eine sinnvolle alternative, selbst wenn Sie bestimmte Dienste noch gar nicht "Load Balancen". vorgesehene Loadbalancer all die Funktionen erfüllt, die Sie als erforderlich ansehen. z.B.:
|
SMTP-Proxy |
Diese Funktion wurde schon beim TMG kaum genutzt und die vorhandene Firewall kann Port 25 entsprechend veröffentlichen. Wer kein Produkt wie NoSpamProxy On-Prem als Station zwischen Internet und Mailserver einsetzt, kann auch Cloud-Dienstleister oder vielleicht den Basis-Spamschutz des Mailservers nutzen. |
Portveröffentlichung |
Diese Funktion wurde beim TMG auch eher selten genutzt und kann sowohl durch eine Firewall (Reverse NAT) oder durch den Loadbalancer problemlos bedient werden. Letztlich geht es bei einer einfachen Port-Veröffentlichung eher darum, nur den konfigurierten Port zu veröffentlichen und damit die anderen Ports des Server zu schützen. |
Ausgehend NAT |
Wenn diese Funktion genutzt wird, dann ist diese im DSL-Router oder der vorhandenen Firewall vorhanden und könnte genutzt werden. |
Eigenschutz |
Einen Server direkt mit einem Bein ins Internet zu stellen, ist ein Risiko, egal ob es Windows oder ein anderes Betriebssystem ist. Eine Firewall davor, die als Portfilter alle anderen Ports blockiert ist dringend anzuraten. Insofern ist eine Änderung sogar eine Verbesserung zu einem TMG im Internet- |
Eigene Verfügbarkeit |
Die meisten Loadbalancer können auch eine Betriebsart als "Pärchen" um auch hier eine hohe Verfügbarkeit zu erreichen |
Mit der Liste der Funktionen müssen Sie dann überlegen, welches Produkt dies wie gut erfüllt. Manchmal reicht ein Produkt auf einem System, wenn Sie eventuell mit Abstrichen leben können. In anderen Umgebungen werden schon aus Skalierungsgründen und Sicherheitsüberlegungen mehrere Systeme mit unterschiedlichen Produkten eingesetzt.
Bereich |
Viele eigene Systeme |
Zentrale kommerzielle Lösung |
---|---|---|
Administration |
Jedes System kann seinen eigenen Admin haben |
Meist ein Admin, ggfls. Delegierung |
Support Statement |
Je System individuell |
Hersteller und Partner |
Patch/Update |
Individuell pro System. Kann auch ein Vorteil sein, oft aber eher Nachteil |
Hersteller gibt Verhalten vor |
Sicherheit |
Je System individuell zu bewerten. Wechselwirkungen und Abhängigkeiten oft nicht klar. |
Wenige Systeme zu patchen. Updates durch Hersteller/Partner, Gesamtsystem besser |
Komplexität |
Oft in der Summe höher |
Größeres System aber Synergie-Effekte von Definitionen z.B. von URLs, Zertifikaten, |
Auditing |
Je System individuell |
Einmal zentral |
SingleSignOn |
Über SAML zwar möglich aber aufwändig |
Einfacher wenn das zentrale |
Endpoint Policies |
Je System umzusetzen |
Einmal zentral |
DoS Schutz |
Je System umzusetzen, Systeme wissen nichts voneinander |
Einmal zentral |
Produkte |
Je Produkt immer wieder „neu erfinden“ |
Templates des Hersteller, Best Practices |
Eine allgemeingültige Antwort gibt es hier also nicht.
Alternative: Reverse HTTP Proxy oder Loadbalancer
Je kleiner eine Firma ist, desto weniger Komponenten will man betreiben und sucht nach Möglichkeiten zur Konsolidierung. Wer heute Firewalls platziert, kann sich nicht mehr auf "Portfilterung" und TCP-Connection Establishment beschränken. Da immer mehr Protokolle das "Universelle Firewall Tunnel Protokoll" (ich meine HTTPS) erkennen und auch immer mehr Dienste per HTTPS als Webseite, WebService oder SOAP/Rest/JSON-Schnittstelle veröffentlicht werden, muss eine Firewall auch HTTPS in beide Richtungen besser unterstützen.
Auf der anderen Seite haben diese geänderte Anforderungen auch für Loadbalancer neue Herausforderungen gebracht. Konnten früher einfach Dienste über den Port und anhand der Source-IP verteilt werden, so ist dies nicht mehr einfach möglich, wenn viele Systeme sind hinter einer Source-IP verstecken. Das kann eingehend auch schon die Firewall sein. Wenn das Protokoll aber HTTPS ist, muss auch ein Loadbalancer diese Verschlüsselung terminieren um mit Header und Content das richtige Ziel zu ermitteln. Wenn der Loadbalancer aber schon die Klartext-Anfragen sieht, dann kann er diese auch gleich auf "Kompatibilität" untersuchen und z.B. Ungültige URLs Blocken. Und dann ist es nur noch ein kleiner Schritt, dass der Loadbalancer zum vollwertigen Reverse Proxy aufgebaut wird, der gleich noch die Preauthentication übernimmt. Dann ist so ein Tausendsassa schon fast eine vollwertige Application-Firewall, die oft sogar noch viel mehr von den Applikationen kennt, als eine normale Firewall. Die Firewall kann sich dann wieder auf die niederen Schichten beschränken und Ports filtern, Spoofing und DoS-Angriffe abwehren etc.
Wenn ich die letzten Jahre mit anschaue, dann werden Load Balancer aufgrund der gestiegenen Anforderungen an die Verfügbarkeit immer häufiger eingesetzt. Dies gilt um so mehr, wenn zwei oder mehr WebServer sich die Arbeit teilen oder bei einer Unterbrechung den Betrieb aufrecht erhalten.
Sobald dann ein Loadbalancer dann auch die anderen Anforderungen an eine "Application Firewall" für HTTPS erfüllt, dann haben Sie schon ihren TMG-Ersatz gefunden.
Übrigens stellt Kemp aktuell kostenfrei einen Loadbalancer als VM zur Verfügung. Unter http://freeloadbalancer.com/ können Sie sich einen virtuellen Loadmaster herunter laden, der allerdings auf 20MBit und 50 SSL-TPS beschränkt ist. für viele kleine Firmen ist das aber als Reverse Proxy aus dem Internet vermutlich ausreichend. Und Sie können so natürlich problemlos alle Funktionen auch erst mal testen und sich über ihre Anforderungen klar werden, ehe Sie sich dann entscheiden.
Ein leistungsfähiger Loadbalancer kann in Verbindung mit einer sowieso erforderlichen Firewall eine geeignete Konfiguration für die sichere Veröffentlichung von Webdienste
Lassen Sie uns doch gemeinsam ihre aktuelle Konfiguration und die zukünftige Anforderungen zusammenstellen um eine auf ihre Umgebung, Größe und Budget passende Konfiguration zu erarbeiten, die Sie verstehen und möglichst selbst verwalten können. Sie erreichen und unter Net at Work oder 0800-MSXFAQ (0800-638 289 67)
Zusammenfassung
Es gibt nicht "dir Ablösung" des TMG 2010 durch ein anderes kostenfreies oder kommerzielles Produkt. Es ist vielmehr an der Zeit, nach einer so langen Betriebsdauer die aktuelle Umgebung und zukünftigen Anforderungen zu analsieren um eine neue Plattform für heute und morgen bereit zu stellen.
Es ist natürlich ein „Schritt“ nicht nur den TMG zu
ersetzen sondern generell über eine adäquate
„Veröffentlichungstechnologie“ nachzudenken. Früher war der
TMG aber die eine Plattform, die als Reverse Proxy
verschiedene Dienste veröffentlicht hat.
Durch den Rückzug von Microsoft haben Dritthersteller den
Markt übernommen (z.B. Citrix Netscaler, F5, Bluecoat, Kemp)
und teilweise natürlich OpenSource-Lösungen auf Linux. Dabei
ist zu beobachten, dass die Funktion „Lastverteilung“ und
„Reverse Proxy“ eng miteinander zusammen hängen und daher
verschiedene Loadbalance um Sicherheitsfunktionen ergänzt
wurden während Application Proxies mittlerweile auch Last
verteilen können. Dies ist auch erforderlich, da durch den
Reverse Proxy Einsatz der „Next Hop “ nicht zwingend den
Client sieht und daher nicht mehr anhand von Source-IP
verteilen kann.
Auf der anderen Seite sind auch Angriffe von intern durchaus real, so dass ein einfacher Loadbalancer seine veröffentlichten Dienste sonst nicht mehr ausreichend sicher kann. Wenn diese Dienste die Authentifizierung abnehmen, können Schutzfunktionen (DoS, Kennwort-Guessing, URL-Probing etc.) schon auf diesen vorgelagerten Systemen erfolgen und die eigentliche Dienste bekommen nur noch vorgefilterte Anfragen, die zudem schon das Authentifizierungstoken enthalten.
Insofern ist die Wahl relativ frei, ob im Rahmen der TMG 2010-Abschaltung ein eigener „Veröffentlichungs-Service“ für die Funktionen „Exchange-OWA, SharePoint, ActiveSync bereit gestellt wird, ein bestehendes System genutzt wird oder für diese einfache Anforderung z.B. mit dem Web Application Proxy eine einfache Bereitstellung erreicht wird.
Auch für den Zugriff auf das Internet sind natürlich neue Herausforderungen zu bewältigen. Früher musste ein HTTP-Proxy einfach nur das "Web Surfen" erlauben. Mittlerweile ist HTTPS das universeller Transportprokoll für viele andere Dienste und wird insbesondere mit Office 365 (MAPI/http, OneDrive, SharePoint, Teams u.a.) deutlich intensiver genutzt. Auch dies muss in die Überlegung mit eingehen.
Weitere Links
- TMG
- UAG
- TMG 2010 und UAG 2010
- RPCFirewall
- IISADMPWD
- Web Application Proxy
- ADFS 2012R2
- IIS ARR Application Request Routung
- Die Suche nach einem
Forefront TMG Ersatz (Das Fazit)
http://www.frankysweb.de/die-suche-nach-einem-forefront-tmg-ersatz-das-fazit/