2009-04-03 14 views
5

Rozumiem potrzebę umieszczenia serwera WWW w strefie DMZ i zablokowania ruchu przychodzącego do wszystkich portów z wyjątkiem 80 i 443. Widzę również, dlaczego prawdopodobnie należy również zablokować większość ruchu wychodzącego w przypadku naruszenia bezpieczeństwa serwera.Czy zapora sieciowa powinna blokować wychodzący ruch HTTP przez port 80?

Ale czy należy blokować wychodzący ruch HTTP przez port 80? Jeśli tak, dlaczego? W dzisiejszych czasach wiele aplikacji internetowych polega na wysyłaniu/pobieraniu danych z zewnętrznych usług internetowych i interfejsów API, więc blokowanie ruchu wychodzącego przez port 80 uniemożliwiłoby taką możliwość. Czy istnieje problem dotyczący bezpieczeństwa, który jest wystarczająco ważny, aby to uzasadnić?

Odpowiedz

7

Jedyny powód, dla którego mogę myśleć to to, że twoja maszyna jest w jakiś sposób zdelokalizowana, to nie będzie w stanie DDoS innej strony na porcie 80. Nie jest to jednak coś, co normalnie robię.

-2

co masz na myśli z blokuje ruch wychodzący na porcie 80.

Masz dwie możliwości. Reguły dynamiczne Gernerate, które umożliwiają komunikację z klienta do serwera w tej sesji. Wyszukaj stanowe reguły zapory sieciowej.

Zasadniczo zezwalaj na nawiązane połączenia, aby komunikować się ze sobą i wychodzić.

Jeśli generalnie blokujesz cały ruch wychodzący przez port 80, serwer WWW nie może odpowiedzieć żadnemu klientowi.

W drugą stronę, jeśli Twój serwer sieciowy potrzebuje jakiegoś interfejsu API, np. biblioteka jquery nie użyje portu 80 jako swojego portu do komunikowania się z serwerem internetowym, który posiada API.

Twój serwer WWW zwykle wybiera port> 1024 i używa go do żądania przesłania interfejsu API ze zdalnego serwera.

Blokowanie całego ruchu przez port 80 (tak jak port, z którego łączysz się) nie uniemożliwiłoby serwerowi wysyłania jakichkolwiek żądań dotyczących apis i podobnych rzeczy. ponieważ nie używa portu 80, gdy działa jako klient.

+0

Chodzi o umożliwienie serwerowi WWW inicjowania wychodzących połączeń HTTP (port 80) do innych serwerów w Internecie. Na przykład możesz mieć stronę PHP, na której znajduje się widget pogody. Ten skrypt musiałby zażądać danych pogodowych z zewnętrznej usługi internetowej. –

+0

ah ok, Myślałem, że masz na myśli blokowanie portu 80 jako portu inicjującego. Jeśli to zablokujesz, nie będziesz mógł załadować apisa i podobnej rzeczy z innych stron. Prawdopodobnie możesz dodać witryny, którym ufasz, do swoich zasad. Ale powiedziałbym, że blokowanie portu 80 zasadniczo nie ma większego sensu. – evildead

+0

z innego punktu widzenia, jeśli serwer zostanie zhakowany i zablokujesz ten ruch, nie może załadować kodu z innych witryn. Ale kto gwarantuje, że haker/robot/cokolwiek używa portu 80 na jego życzenie :) – evildead

0

Zamiast tego zablokuj, dławiąc. Użyj limitu iptables -m.

0

Mam kilka aplikacji internetowych, które wywołują zewnętrzne usługi sieciowe, więc powiedziałabym, że blokowanie generowanego ruchu HTTP jest złym pomysłem. Jeśli obawiasz się o bezpieczeństwo, możesz go zablokować i zezwolić na tylko określone miejsca docelowe.

+0

Biała lista jest dobrą sugestią, ale nie będzie działać z OpenID, co wymaga, aby serwer WWW mógł zażądać dowolnego adresu URL używanego jako OpenID. –

+0

Co więcej, nie będzie działać z żadną witryną, która zmienia adres IP. W ten sposób zapora ogniowa, do której muszę żądać zmian, działa - na poziomie IP, a nie na poziomie domeny (rozumiem, że to jest ze względów wydajnościowych). To jest prawdziwy problem, ponieważ niektóre adresy IP bardzo się zmieniają. –

+0

Ponadto, czy nie zawsze będzie jakaś usługa, która mogłaby być użyta dla DDOS innego hosta? Na przykład na moim hoście wychodzącym z serwera HTTP, ping może nadal kontaktować się z dowolnym hostem. –

0

zależności od wersji SQL, można mieć świadectwo czasu uwierzytelniania się problemy z serwerem SQL 2005.

0

pierwsze - Zgadzam się z @vartec na dławienie „Raczej następnie blokując go udusić go używać limitu iptables -m. "co najmniej część rozwiązania.

Mogę jednak podać kolejny powód, dla którego nie należy blokować wyjścia z portu 80 przez cały czas. Jeśli masz włączone automatyczne aktualizacje zabezpieczeń, serwer nie może nawiązać połączenia PPA przez port 80, aby zainicjować aktualizację zabezpieczeń. Jeśli więc masz ustawione automatyczne aktualizacje zabezpieczeń, nie będą one działać. Na ubuntu auto-aktualizacji zabezpieczeń są włączone w 14.04 LTS z:

sudo apt-get install unattended-upgrades update-notifier-common && \ 
sudo dpkg-reconfigure -plow unattended-upgrades 
(then select "YES") 

Więcej wdzięku rozwiązań byłoby ansibl skrypty otwarcia portu automatycznie, ewentualnie modyfikując reguły grupy zabezpieczeń AWS poprzez CLI oprócz iptables jeśli ciebie są w AWS. Wolę chwilowo modyfikować moje reguły wychodzące za pośrednictwem interfejsu AWS zainicjowanego przez skrytkę. Wymusza to rejestrowanie aktualizacji w moich dziennikach systemu AWS S3, ale nigdy nie pojawia się w dziennikach na samym serwerze.Ponadto serwer, który inicjuje aktualizację, nie musi nawet znajdować się w prywatnej podsieci ACL.

Może zrobić jedno i drugie? Musisz czasem obliczać, że atak ma polegać na przekazywaniu wewnętrznego adresu IP w podsieci, więc warto podwoić wydajność, zachowując jednocześnie możliwość automatyzacji tworzenia kopii zapasowych i aktualizacji zabezpieczeń.

Mam nadzieję, że to pomoże. Jeśli nie, odpowiedz i podaj więcej przykładów kodu, aby były bardziej szczegółowe i dokładne. #bądź bezpieczny !

0

Jeśli maszyna została naruszona, a ruch wychodzący na porcie 80 jest dozwolony, ułatwiłby intruzom odesłanie zebranych danych do siebie. Umożliwienie ruchu wychodzącego oznacza, że ​​możesz zainicjować połączenie ze swojego komputera ze światem zewnętrznym. Lepszym rozwiązaniem byłoby zezwolenie na ruch wychodzący tylko na określone witryny internetowe/adresy, którym ufasz (tj. Na Microsoft Windows Update, Google reCAPTCHA) zamiast na jakiekolwiek miejsce docelowe na świecie.

Powiązane problemy