Konfiguracja usług

Jak możemy zapewnić podstawowe usługi internetowe za pomocą tej architektury? HTTP i HTTPS Mamy kilka możliwości udostępnienia sieci WWW użytkownikom wewnętrznym: Pozwolić im na bezpośrednią łączność, stosując filtrowanie pakietów.

Uruchomić prosty serwer proxy. Uruchomić buforujący serwer proxy. Jak już mówiliśmy, użycie filtrowania pakietów wiąże się albo z ograniczeniem liczby serwerów dostępnych dla użytkowników, albo z zezwoleniem na niemal wszystkie połączenia wychodzące. Jest to rozwiązanie możliwe do zaakceptowania, ale wymaga pełnego zaufania użytkownikom wewnętrznym. Uruchomienie prostego serwera proxy (takiego jak SOCKS) w samym firewallu dałoby nam możliwość rejestrowania zdarzeń i ściślejszej kontroli, nie ograniczając znacząco użytkowników

1 nie obciążając zbytnio firewalla. Uruchomienie buforującego serwera proxy w firewallu nie byłoby najlepszym pomysłem. Serwery buforujące są dość skomplikowane i wymagają sporo przestrzeni dyskowej na buforowane strony. Mają jednak także wiele zalet, zatem moglibyśmy umieścić taki serwer w wewnętrznym hoście usługowym.

Nie chcemy natomiast publikować stron WWW w wewnętrznym hoście usługowym, który zawiera wiele wewnętrznych danych. Nie chcemy także publikować ich bezpośrednio w firewallu, ponieważ serwer WWW zagrażałby bezpieczeństwu fire walla i stanowił spore obciążenie. Do publikowania stron WWW potrzebny będzie oddzielny serwer w sieci peryferyjnej.

Skorzystamy zatem z serwera HTTP w sieci peryferyjnej, aby świadczyć usługi HTTP w Internecie. Dla użytkowników wewnętrznych łączących się z Internetem uruchomimy buforujący serwer proxy w wewnętrznym hoście usługowym. Filtr pakietów w firewallu będzie przepuszczał żądania serwera proxy.

Serwer WWW w sieci peryferyjnej mógłby świadczyć nie tylko usługi HTTP, ale także HTTPS wymagałoby to niewielkich zmian w regułach filtrowania pakietów. Z drugiej strony, nie ma żadnego powodu, aby prosty, nieinteraktywny serwer obsługiwał HTTPS, a z kolei skomplikowany serwer WWW, który musiałby obsługiwać HTTPS (na przykład na potrzeby handlu elektronicznego), niemal na pewno wymagałby także usług pomocniczych (na przykład bazy danych). Ponieważ w naszym przykładzie nie konfigurujemy żadnych dodatkowych usług, nie ma powodu, żeby przepuszczać HTTPS do sieci peryferyjnej, więc nie będziemy uaktywniać tego protokołu.