Juniper 5GT und das ALG (Application Level Gateway) – Anwendungen laufen nicht

Problem:

Wir sind da bestimmt in eine Falle reingetappt.

Eigentlich wollten wir an einigen Standorten nur die alten Netscreen NS5-XT durch neuere Juniper 5GT tauschen. Die Konfiguration haben wir handverlesen übernommen.

Nach dem Umbau funktionierte alles – bis auf eine Anwendung, die Oracle Requests nutzt. Könnte es sein, dass es an der uns bisher nicht bekannten ALG Funktionalität liegen kann ? Das Entfernen von bestimmten Häkchen führte zum Erfolg.

Wozu ist denn ALG da und wie kann man es generell ausschalten ? Was muss man noch bedenken ?

Antwort:

Juniper Info zu ALG

Die Anwendung wurde wahrscheinlich durch das SQL ALG blockiert. Verwenden Sie z.B. für Oracle nicht Standard Ports werden diese erkannt und blockiert.  

ALG: Application Layer Gateways kontrollieren den Dateninhalt der Protokolle und erkennen Protokollverletzungen.
Sie können ALG’s entweder Global deaktivieren oder pro Regel.  Global indem Sie die einzelnen Anwendungen im ALG deaktivieren oder in der Regel die Application auf IGNORE stellen.

ALG Global deaktivieren

Alle Häkchen hauf dieser Seite herausnehmen.

ALG pro Regel deaktivieren

Ignore = Kein ALG für diese Regel trotz aktiviertes ALG für diese Anwendung

Die Option IGNORE wird verwendet wenn man z.B. in den Einstellungen von ALG SQL aktiviert hatte aber für diese eine bestimmte Regel dieses ALG nicht verwenden will.

None = Aktivierte ALG Anwendungen werden berücksichtigt

Bei NONE wird auf die ALG Einstellungen zurückgegriffen und alles überprüft was aktiviert ist.

Eine Application wurde ausgewählt = Eine ausgewählte Anwendung wird berücksichtigt, wenn sie in ALG aktiviert wurde.

Wenn man in Application z.B. FTP auswählt, so wird für diese Regel nur die ALG FTP genommen.
Dies funktioniert aber nur, wenn FTP in den ALG Einstellungen aktiviert ist.

Auszug aus der Onlinehilfe von Juniper :

Application: The application specifies the Layer 7 application that maps to the Layer 4 service that you reference in the policy. A predefined service already has a mapping to a Layer 7 application. However, for custom services, you must link the service to an application explicitly, especially if you want the policy to apply an application layer gateway (ALG) or Deep Inspection to the custom service.

 

Weitere Informationen :
Die ALGs sind leider etwas spartanisch dokumentiert. Aber den ALG für FTP sollte man definitiv aktivieren. Sonst werden Control und Data session nicht einer Verbindung zugeordnet.
Das sieht dann meistens so aus: Anmeldung am FTP-Server funktioniert, aber Datentransfer nicht mehr. In den meisten Fällen sind ALGs dazu da, eine Application als Session/Verbindung zu erkennen und zu behandeln, insbesondere wenn dynamische Ports verwendet werden.

Wo ist denn der Einsatzzweck des ALG Gateways und warum gibt es das eigentlich ? Einen generellen Einsatzzweck für ALG gibt es nicht. Man dies immer im Einzelfall abhängig von der Anwendung entscheiden.

Das globale Abschalten kann leider zu ungewünschten Ergebnissen führen, insbesondere wenn nicht-standard Ports verwendet werden. Es kommt aber auch auf das FTP-Port-Verhalten des FTP-Servers und des Clients ankommt (aktiv/passiv FTP).

Den ALG für FTP gibt es schon länger, eigentlich schon seit Sie „FTP-put“ und „FTP-get“ in der Regel verwenden können (mindestens 5 Jahre seit ScreenOS 5.0).
Beim aktiven FTP wird i.d.R. ein Data channel (für den FTP-Client) mit Port eins niedriger (21->20)als der Control-Port (vom FTP-Server) auf der FW aufgemacht. Sollte dies nicht der Fall sein, wird die Antwort vom Client nicht zur Session zugehörig interpretiert, der ALG sorgt dann dafür, dass die dynamische Portwahl des Servers der Session/Verbindung zugeordnet werden kann.

Mit der Einführung der UTM-features, also AV-Scanning, Deep Inspection usw. sind diese ALGs weiterentwickelt worden. Es sind alles Entwicklungen, die über Layer 3/4 hinausgehen und das Verhalten der ScreenOS-FW spezifisch auf Applikationsebene konfigurierbar machen.

Diese ALGs sind eigene Module im ScreenOS und werden protokollspezifisch entwickelt. Deshalb ist die Existenz und auch das Verhalten release abhängig.

Also Voricht !!