Beinahe enzyklopädisch behandelt unser Schwerpunkt-Artikel über IPSEC verschlüsselte Verbindungen zwischen Linux, Windows, BSD, Solaris, Cisco- sowie ... (mehr)

Juniper SRX

Junipers SRX kombiniert einen Junos-basierten Router mit der Firewall-Technologie, die durch Kauf von Netscreen in das Unternehmen kam.

Auch Junos unterscheidet zwischen VPNs, die auf Policies und solchen, die darauf basieren. Im Test wurde ein auf Routing basierendes VPN gewählt. Dazu muss der Administrator zunächst ein Loopback Interface definieren, das den Namen »st0« trägt. Diesem ordnet er eine IP-Adresse zu, die in einem reinen Juniper-VPN als Gateway für andere SRX-Geräte gelten würde. Über ein proprietäres Protokoll von Juniper finden die Gateways dann automatisch die Routen zu den Partnern. Beim Einsatz von Routern anderer Hersteller gibt man IP-Adressen an, die im gleichen LAN wie die eigene liegen, und ordnet diesen ein VPN zu. Die Routen in die anderen LAN-Bereiche bekommen dann eine statische Route mit der in diesem Konfigurationsteil eingestellten IP-Adresse zugewiesen, damit die Firewall weiß, dass sie die Pakete in diesen VPN-Tunnel schicken soll.

Interfaces werden bei einer Juniper-Firewall üblicherweise Zonen zugeordnet (eine Zone kann mehrere Interfaces enthalten). Bei Firewall-Regeln gibt es immer eine Zone, aus der das Paket kommt, und eine Zone, in die das Paket möchte. Daher erzeugt der Administrator zunächst eine Zone, in der das Interface »st0« liegt, die dann in den Regeln verwendet wird. Dies geschieht mit der Konfiguration in Listing 7.

Listing 7

Juniper-Firewall

 

Die gesamte Konfiguration von Juniper ist sehr modular aufgebaut. Dies spiegelt sich auch in den VPN-Definitionen wider. Sie unterteilen sich in ein sogenanntes Proposal, das die Algorithmen, PFS-Parameter und Authentisierungsmethode enthält, dann in eine Policy, die das Proposal mit den richtigen Werten referenziert und die Auswahl zwischen Main und Aggressive Mode der IKE-Verhandlung sowie den Pre Shared Key hinzufügt. Letzte Komponente der VPN-Definition ist schließlich ein Gateway, das die Policy referenziert, eine IP-Adresse der Gegenstelle und das ausgehende Interface hinzufügt. Im Gateway lässt sich auf Wunsch auch NAT-Traversal aktivieren. Listing 8 zeigt eine IKE-Konfiguration mit den drei Komponenten.

Listing 8

Juniper-Konfiguration, Phase 1

 

Durch den logischen Aufbau der Juniper-Konfiguration lassen sich einzelne Teile sehr gut wiederverwenden. Wenn alle Partner mit dem gleichen PSK und den gleichen Phase-1-Parametern laufen sollen, müssen nach den ersten beiden Einträgen nur noch Gateway-Einträge folgen. Die Policy darf auch mehrere Proposals referenzieren, die dem Partner angeboten werden.

Phase 2

Der nächste Schritt sind die Parameter der Phase 2. Diese finden sich im Kontext »security | ipsec« . Auch hier gliedert sich die Konfiguration in drei Abschnitte: das Proposal, das die Phase-2-Algorithmen und das Protokoll (ESP oder AH) enthält, die Policy, die ein Proposal referenziert und PFS für Phase 2 definiert und schließlich VPN, das die Policy referenziert und ein Gateway aus der IKE-Definition zuordnet. In der Definition stehen auch die LAN-Segmente, zwischen denen das VPN entstehen soll, denn diese teilt der Router der Verhandlung der Gegenseite mit. Bei einem auf Routen basierenden VPN muss der Administrator noch das zu diesem VPN gehörende Loopback-Interface zuordnen. Das alles führt in der Kombination zu Listing 9.

Listing 9

Juniper-Konfiguration, Phase 2

 

Auch hier lassen sich das Proposal und die Policy wiederverwenden. Wenn die eingetragenen Werte gleich bleiben, müssen nur VPN-Einträge folgen.

Als vorletzter Schritt der Konfiguration bleibt noch eine Security-Policy einzutragen. Im Zonenkonzept von Juniper geschieht dies über zwei Regeln:

  • Aus der VPN-Zone in die Zone, in der sich das interne LAN befindet.
  • In Gegenrichtung aus der Zone des internen LAN in die VPN-Zone.

Außerdem muss der Administrator auf dem eingehenden Interface "außen" noch IKE aktivieren, damit die Firewall die IKE-Anfragen verarbeitet. Diese Definition geschieht im Kontext der Zone, die "außen" liegt (meistens heißt diese »untrust« ) und dort für jedes Interface, das IKE-Anfragen annehmen soll. Die Regeln zeigt Listing 10.

Listing 10

Firewall-Regeln für Juniper

 

»trustnet« und »remotelan« muss der Administrator erst noch im Addressbook der Zonen definieren, da Juniper als Netzwerkobjekte nur Adressbucheinträge verwendet.

Die Anweisung »traceoptions« unterhalb von »security | ike« aktiviert das Debugging. In der Konfiguration gibt »file dateiname« den Namen einer Logdatei an, während »flag ike« das Debugging startet. Die Logdatei landet im Dateisystem des SRX-Routers und kann dort mit »show log dateiname« angezeigt werden (beziehungsweise mittels »less« , wenn man aus der Juniper-Kommandozeile auf den Unix-Prompt wechselt).

Unterhalb des Kontexts »security | ipsec« kann der Administrator »traceoptions« aktivieren, um verlorene Pakete oder Änderungen in den Security Associations protokollieren zu lassen. Das so entstehende Logfile zeigt gegebenenfalls zwar, dass ein Fehler auftritt, jedoch erfährt man wie bei Cisco, Racoon oder Solaris auch keine näheren Gründe dafür.

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019