Jak dużym problemem jest wybicie dziury w strefie DMZ na jednym serwerze WWW?

Obecnie mamy nasz serwer internetowy w strefie DMZ. Serwer sieciowy nie widzi niczego w sieci wewnętrznej, ale sieć wewnętrzna może zobaczyć serwer sieciowy. Jak bezpieczne byłoby wybicie dziury w zaporze między DMZ a siecią wewnętrzną tylko dla jednego serwera WWW w intranecie? Pracujemy nad czymś, co będzie współpracować z kilkoma naszymi aplikacjami back-office (wszystkie na jednym serwerze) i byłoby znacznie łatwiej wykonać ten projekt, gdybyśmy mogli komunikować się bezpośrednio z serwerem IBM i przechowującym te dane ( za pośrednictwem usług internetowych).

Z mojego zrozumienia (i nie znam marek) mamy jedną zaporę ogniową dla DMZ z innym zewnętrznym adresem IP niż nasze podstawowe IP z inną zaporą ogniową. Kolejna zapora ogniowa znajduje się między serwerem WWW a intranetem.

Więc coś takiego:

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

Nie ma nic złego w tworzeniu mechanizmów dostępu dla hostów w strefie DMZ w celu uzyskania dostępu do hostów w chronionej sieci, gdy jest to konieczne do osiągnięcia zamierzonego rezultatu. Być może nie jest to zalecane, ale czasami jest to jedyny sposób na wykonanie pracy.

Kluczowe rzeczy do rozważenia to:

• Ogranicz dostęp do najbardziej szczegółowej reguły zapory, jaką możesz. Jeśli to możliwe, nazwij określonych hostów uczestniczących w regule wraz z konkretnymi protokołami (porty TCP i / lub UDP), które będą używane. Zasadniczo otwórz tylko tak małą dziurę, jak potrzebujesz.

• Upewnij się, że logujesz dostęp z hosta DMZ do hosta w chronionej sieci i, jeśli to możliwe, analizuj te dzienniki w sposób zautomatyzowany pod kątem anomalii. Chcesz wiedzieć, kiedy dzieje się coś niezwykłego.

• Rozpoznaj, że udostępniasz wewnętrzny host, nawet jeśli jest to pośredni sposób, w Internecie. Bądź na bieżąco z łatkami i aktualizacjami dla ujawnianego oprogramowania i samego oprogramowania systemu operacyjnego hosta.

• Rozważ wzajemne uwierzytelnianie między hostem DMZ a hostem wewnętrznym, jeśli jest to wykonalne w przypadku architektury aplikacji. Byłoby miło wiedzieć, że żądania przychodzące do hosta wewnętrznego pochodzą w rzeczywistości z hosta DMZ. To, czy możesz to zrobić, czy nie, będzie w dużym stopniu zależne od architektury aplikacji. Należy również pamiętać, że osoba, która „jest właścicielem” hosta DMZ, będzie mogła wysyłać żądania do hosta wewnętrznego, nawet jeśli nastąpi uwierzytelnienie (ponieważ będzie to host DMZ).

• Jeśli istnieją obawy dotyczące ataków DoS, rozważ użycie ograniczenia prędkości, aby zapobiec wyczerpaniu się zasobów hosta wewnętrznego przez host DMZ.

• Możesz rozważyć zastosowanie metody „zapory” w warstwie 7, w której żądania od hosta DMZ są najpierw przekazywane do specjalnego hosta wewnętrznego, który może „zdezynfekować” żądania, sprawdzić je, a następnie przekazać je do „prawdziwy” host zaplecza. Ponieważ mówisz o interfejsie z aplikacjami back-office na swoim IBM iSeries, domyślam się, że masz ograniczone możliwości sprawdzania poprawności względem przychodzących żądań na samym iSeries.

Jeśli podchodzisz do tego w sposób metodyczny i zachowujesz zdrowy rozsądek, nie ma powodu, aby nie robić tego, co opisujesz, jednocześnie minimalizując ryzyko.

Szczerze mówiąc, że masz strefę DMZ, która nie ma nieograniczonego dostępu do chronionej sieci, sprawia, że ​​skaczesz poza granice wielu sieci, które widziałem. Wydaje się, że dla niektórych osób DMZ oznacza po prostu „inny interfejs zapory ogniowej, prawdopodobnie z różnymi adresami RFC 1918 i zasadniczo nieograniczonym dostępem do Internetu i chronionej sieci”. Staraj się trzymać DMZ tak zablokowane, jak to tylko możliwe, jednocześnie realizując cele biznesowe, a będziesz dobrze.

Oczywiście istnieją pewne niebezpieczeństwa, ale możesz to zrobić. Zasadniczo otwierasz otwór, przez który ktoś mógłby się dostać, więc zmniejsz go. Ogranicz to tylko do serwerów po obu stronach i zezwalaj tylko na dane na wybranych portach. Nie jest złym pomysłem, aby używać translacji adresów portów tylko do dziwnych portów. Mimo to bezpieczeństwo przez zaciemnienie nie jest wcale zabezpieczeniem. Upewnij się, że czymkolwiek jest serwer po drugiej stronie, ma jakiś sposób na sprawdzenie, czy informacje przechodzące przez to połączenie są naprawdę tym, czym się wydaje ... lub przynajmniej mają jakąś zaporę kontekstową. Ponadto istnieją pewne zapory ogniowe przeznaczone do tego typu rzeczy ... Wiem, że Microsoft ISA robi to samo dla serwerów OWA i Exchange.