Wie groß ist das Problem, ein Loch in die DMZ eines Webservers zu stanzen?

Wir haben derzeit unseren Webserver in einer DMZ. Der Webserver kann nichts im internen Netzwerk sehen, aber das interne Netzwerk kann den Webserver sehen. Wie sicher wäre es, ein Loch in die Firewall zwischen der DMZ und dem internen Netzwerk für nur einen Webserver im Intranet zu schlagen? Wir arbeiten an einer Lösung, die mit mehreren unserer Back-Office-Anwendungen (die sich alle auf einem Server befinden) zusammenarbeitet, und es wäre so viel einfacher, dieses Projekt durchzuführen, wenn wir direkt mit dem IBM i-Server kommunizieren könnten, auf dem diese Daten gespeichert sind ( über Webservices).

Nach meinem Verständnis (und ich kenne keine Marken) haben wir eine Firewall für die DMZ mit einer anderen externen IP als unsere primäre IP mit einer anderen Firewall. Eine weitere Firewall befindet sich zwischen dem Webserver und dem Intranet.

Also so etwas wie:

Web Server  <==== Firewall ===== Intranet
     |                              |
     |                              |
  Firewall                      Firewall
     |                              |
     |                              |
 Internet IP1                  Internet IP2

Es ist nichts Falsches daran, Zugriffsmechanismen für Hosts in der DMZ zu erstellen, um auf Hosts im geschützten Netzwerk zuzugreifen, wenn dies erforderlich ist, um das gewünschte Ergebnis zu erzielen. Es ist vielleicht nicht vorzuziehen, dies zu tun, aber manchmal ist es die einzige Möglichkeit, die Arbeit zu erledigen.

Die wichtigsten zu berücksichtigenden Punkte sind:

• Beschränken Sie den Zugriff auf die spezifischste Firewall-Regel, die Sie verwenden können. Nennen Sie nach Möglichkeit die an der Regel beteiligten Hosts und die verwendeten Protokolle (TCP- und / oder UDP-Ports). Öffnen Sie grundsätzlich nur ein so kleines Loch, wie Sie benötigen.

• Stellen Sie sicher, dass Sie den Zugriff vom DMZ-Host auf den Host im geschützten Netzwerk protokollieren, und analysieren Sie diese Protokolle nach Möglichkeit automatisch auf Anomalien. Sie möchten wissen, wann etwas Außergewöhnliches passiert.

• Erkennen Sie, dass Sie einen internen Host auch auf indirekte Weise für das Internet verfügbar machen. Behalten Sie den Überblick über Patches und Updates für die bereitgestellte Software und die Betriebssystemsoftware des Hosts.

• Ziehen Sie die gegenseitige Authentifizierung zwischen dem DMZ-Host und dem internen Host in Betracht, wenn dies mit Ihrer Anwendungsarchitektur möglich ist. Es wäre schön zu wissen, dass die Anforderungen, die an den internen Host gesendet werden, tatsächlich vom DMZ-Host stammen. Ob Sie dies tun können oder nicht, hängt stark von Ihrer Anwendungsarchitektur ab. Beachten Sie auch, dass jemand, dem der DMZ-Host "gehört", Anforderungen an den internen Host senden kann, selbst wenn eine Authentifizierung stattfindet (da er effektiv der DMZ-Host ist).

• Wenn Bedenken hinsichtlich DoS-Angriffen bestehen, sollten Sie die Verwendung von Ratenbeschränkungen in Betracht ziehen, um zu verhindern, dass der DMZ-Host die Ressourcen des internen Hosts erschöpft.

• Möglicherweise möchten Sie die Verwendung eines "Firewall" -Ansatzes der Schicht 7 in Betracht ziehen, bei dem die Anforderungen vom DMZ-Host zuerst an einen speziellen internen Host übergeben werden, der die Anforderungen "bereinigen", auf ihre Richtigkeit überprüfen und dann an weiterleiten kann der "echte" Backend-Host. Da es sich um eine Schnittstelle zu Ihren Back-Office-Anwendungen auf Ihrer IBM iSeries handelt, haben Sie vermutlich nur eingeschränkte Möglichkeiten, auf der iSeries selbst Sicherheitsüberprüfungen für eingehende Anforderungen durchzuführen.

Wenn Sie dies methodisch angehen und dabei den gesunden Menschenverstand wahren, gibt es keinen Grund, warum Sie nicht das tun können, was Sie beschreiben, während Sie gleichzeitig das Risiko minimieren.

Ehrlich gesagt, dass Sie eine DMZ haben, die keinen uneingeschränkten Zugriff auf das geschützte Netzwerk hat, bedeutet, dass Sie weit über die meisten Netzwerke hinausgehen, die ich gesehen habe. Für manche Leute bedeutet DMZ einfach "eine andere Schnittstelle an der Firewall, möglicherweise mit einigen anderen RFC 1918-Adressen und im Grunde genommen uneingeschränktem Zugriff auf das Internet und das geschützte Netzwerk". Versuchen Sie, Ihre DMZ so gesperrt wie möglich zu halten, während Sie gleichzeitig Ihre Geschäftsziele erreichen, und Sie werden es gut machen.

Es gibt offensichtlich einige Gefahren, aber Sie können es tun. Im Grunde öffnen Sie ein Loch, durch das jemand eindringen könnte, also machen Sie es winzig. Beschränken Sie dies auf die Server an beiden Enden und lassen Sie nur Daten an den ausgewählten Ports zu. Es ist keine schlechte Idee, die Portadressübersetzung nur zur Verwendung bizarrer Ports zu verwenden. Sicherheit durch Unbekanntheit ist jedoch überhaupt keine Sicherheit. Stellen Sie sicher, dass der Server auf der anderen Seite auf irgendeine Art und Weise überprüft, ob die Informationen, die über diese Verbindung übertragen werden, wirklich dem entsprechen, was sie zu sein scheinen. Außerdem gibt es bestimmte Firewalls, die für diese Art von Dingen entwickelt wurden. Ich weiß, dass Microsoft ISA dasselbe für OWA- und Exchange-Server tut.