Dlaczego miałbym potrzebować zapory ogniowej, jeśli mój serwer jest dobrze skonfigurowany?

Administruję garstką serwerów w chmurze (VPS) dla firmy, dla której pracuję.

Serwery to minimalne instalacje Ubuntu, które uruchamiają bity stosów LAMP / kolekcję danych przychodzących (rsync). Dane są duże, ale nie są danymi osobowymi, finansowymi ani nic podobnego (tzn. Nie są tak interesujące)

Najwyraźniej tutaj ludzie zawsze pytają o konfigurację zapór ogniowych itp.

Używam różnych podejść do zabezpieczenia serwerów, na przykład (ale nie tylko)

• ssh na niestandardowych portach; bez wpisywania hasła, tylko znane klucze ssh ze znanych adresów IP do logowania itp
• https i ograniczone powłoki (rssh) ogólnie tylko od znanych kluczy / ips
• serwery są minimalne, aktualne i regularnie załatane
• używaj rzeczy takich jak rkhunter, cfengine, lynis denyhosts itp. do monitorowania

Mam duże doświadczenie w administrowaniu systemem UNIX. Jestem pewien, że wiem, co robię w moich konfiguracjach. Konfiguruję pliki / etc. Nigdy nie czułem potrzeby instalowania takich rzeczy jak zapory ogniowe: iptables itp.

Odłóż na chwilę na bok kwestie bezpieczeństwa fizycznego VPS.

Q? Nie mogę zdecydować, czy jestem naiwny, czy też ochrona przyrostowa, którą może zaoferować fw, jest warta wysiłku nauki / instalacji i dodatkowej złożoności (pakietów, plików konfiguracyjnych, możliwej pomocy technicznej itp.) Na serwerach.

Do tej pory (dotyk drewna) nigdy nie miałem żadnych problemów z bezpieczeństwem, ale nie jestem z tego powodu zadowolony.

Zauważam, że wykonałeś świetną robotę, łącząc kilka różnych demonów i z tego, co powiedziałeś, uważam, że nie jest prawdopodobne, abyś naraził się na kłopoty za pośrednictwem usług, które już zabezpieczyłeś. To wciąż pozostawia cię w stanie „wszystko jest dozwolone, z wyjątkiem tego, co zabroniłem” i nie możesz wyjść z tego stanu, ścigając demona za demonem i zabezpieczając je jeden po drugim.

Zapora sieciowa skonfigurowana tak, aby NIE ODCZYTAŁA KAŻDEGO domyślnie przenosi cię do trybu działania „wszystko jest zabronione oprócz tego, co jest dozwolone”, i przez wiele lat odkryłem, że są lepsze.

W tej chwili, biorąc pod uwagę uprawnionego użytkownika z uzasadnioną powłoką w twoim systemie, mogłaby zdecydować się na uruchomienie lokalnego nieuprzywilejowanego demona do proxy żądań internetowych do Internetu lub rozpocząć udostępnianie plików na porcie 4662 lub przypadkowo otworzyć słuchacza za pomocą -g z tunelowaniem portów ssh, nie rozumiejąc, co robi; lub instalacja sendmaila może sprawić, że uruchomisz MUA na porcie 587, który został nieprawidłowo skonfigurowany pomimo wszystkich prac, które wykonałeś w celu zabezpieczenia sendaila MTA na porcie 25; lub może zdarzyć się sto rzeczy, które mogą ominąć twoje staranne i przemyślane bezpieczeństwo po prostu dlatego, że nie było ich w pobliżu, kiedy dokładnie zastanawiałeś się, co zabronić.

Czy rozumiesz mój punkt widzenia? W tej chwili włożyłeś wiele wysiłku w zabezpieczenie wszystkich rzeczy, o których wiesz, i wygląda na to, że nie ugryzą cię. To, co może cię gryźć, to rzeczy, o których nie wiesz, lub których nawet teraz nie ma.

Zapora, która domyślnie ma wartość DENY ANY ANY, to sysadminowy sposób mówienia, że jeśli pojawi się coś nowego i otworzy nasłuchiwanie sieci na tym serwerze, nikt nie będzie mógł z nim rozmawiać, dopóki nie udzielę wyraźnego pozwolenia .

Zasada co najmniej przywileju. Zapora ogniowa pomaga się tam dostać. Zasada obrony w głębi. Zapora ogniowa pomaga również się tam dostać. Każda dobrze zaprojektowana konfiguracja wyraźnie polega na tych dwóch sposobach.

Inną rzeczą jest to, że twoje serwery najprawdopodobniej będą sprzętem towarowym lub sprzętem specyficznym do obsługi oprogramowania serwera działającego na standardowym serwerze OS (Unix, NT, Linux). Oznacza to, że nie mają specjalistycznego sprzętu do wydajnej obsługi i filtrowania ruchu przychodzącego. Czy chcesz, aby Twój serwer obsługiwał każdą nadchodzącą multiemisję, pakiet ICMP lub skanowanie portów?

Najprawdopodobniej chcesz, aby serwery fizycznie obsługiwały żądania tylko do niektórych portów (80, 443, twój port ssl, typowy port Oracle 1521, port rsync itp.) Tak, oczywiście, że konfigurujesz zapory programowe na swoim serwery tylko nasłuchują tych portów. Ale twoje karty sieciowe będą nadal ponosić ciężar niechcianego ruchu (czy to złośliwego, czy normalnego w Twojej organizacji). Jeśli twoje karty sieciowe są hamowane, to również ścieżki sieciowe przechodzą przez twoje serwery (i ewentualnie między twoimi serwerami a klientami wewnętrznymi i połączenia z inne wewnętrzne serwery i usługi).

Twoje karty sieciowe nie tylko zostaną wkurzone, ale zapora programowa również się zaangażuje, ponieważ musi sprawdzać każdy otrzymany pakiet lub datagram.

Z drugiej strony, zapory ogniowe, szczególnie te na krawędziach podsieci (lub oddzielające podsieci od świata zewnętrznego), są zazwyczaj specjalistycznym sprzętem specjalnie zaprojektowanym do obsługi tego rodzaju woluminów.

Możesz otoczyć N liczby serwerów M liczbą zapór ogniowych (za pomocą N >> M). I ustawiasz zaporę tak, aby zrzucała wszystko, co nie jest skierowane do określonych portów. Skanowania portów, ICMP i inne bzdury są wyłączone. Następnie dostosuj zaporę programową na swoich serwerach zgodnie z ich konkretną funkcją.

Teraz właśnie zmniejszyłeś (ale nie wyeliminowałeś) prawdopodobieństwo całkowitego zaciemnienia, redukując go do podziału sieci lub w najgorszym przypadku częściowej awarii. W ten sposób zwiększyłeś zdolność swoich systemów do przetrwania ataku lub błędnej konfiguracji.

Brak zapory ogniowej, ponieważ serwery ją mają, jest jak poczucie bezpieczeństwa podczas zapinania pasa bezpieczeństwa podczas jazdy z prędkością 120 km / h przy zerowej widoczności z powodu mgły. To nie działa w ten sposób.

Istnieje wiele ataków, na które możesz być podatny, jeśli nie masz zapory ogniowej, która dokonuje kontroli poziomu pakietów:

Przykładem jest pakiet choinek

http://en.wikipedia.org/wiki/Christmas_tree_packet

Ataki DDOS mogą być przeprowadzane przeciwko Twojemu systemowi, zapora ogniowa (być może zewnętrzna, zanim którykolwiek z Twoich serwerów) zatrzyma / spowolni / zabije ruch, zanim sparaliżuje twoje serwery.

Tylko dlatego, że nie masz dane finansowe lub osobiste na serwerach nie znaczy, że nie będzie się „boli”. Jestem pewien, że płacisz za przepustowość lub użycie procesora, albo masz naliczoną stawkę. Wyobraź sobie, że w ciągu nocy (kiedy śpisz) ktoś podbiega do twojego licznika (widziałem, jak to się dzieje z dostawcami VOIP Switch, uderzonymi w nocy za MILIONY MINUT ruchu, za które trzeba zapłacić rachunek).

Bądź więc sprytny, skorzystaj z ochrony, jeśli ona istnieje, NIE jesteś PERFEKCYJNY, podobnie jak oprogramowanie. Jest bezpieczny tylko do momentu znalezienia następnego exploita. ;)

Jeśli możesz egzekwować zasadę najmniejszych uprawnień bez użycia zapory, prawdopodobnie jej nie potrzebujesz. Z mojego punktu widzenia budowanie bezpiecznego systemu bez użycia zapory wymaga większego wysiłku i jestem dość leniwy. Dlaczego powinienem zawracać sobie głowę ograniczaniem połączeń TCP za pomocą innych narzędzi i prawdopodobnie wielu plików konfiguracyjnych, skoro mogę rozdzielić uprawnienia na poziomie transportu za pomocą pojedynczej konfiguracji.

Zapora ogniowa może również przechwytywać niechciane pakiety docierające do serwerów. Zamiast zajmować się nimi na poziomie pojedynczego serwera, możesz sobie z nimi poradzić w zaporze ogniowej. Możesz zachować całą tę aktywność konfiguracyjną na pojedynczej zaporze ogniowej zamiast na wielu serwerach.

Na przykład, jeśli osoba atakująca przejęła kontrolę nad zewnętrznym adresem IP i wykleja twoje serwery z niechcianymi pakietami i chcesz złagodzić wpływ, jaki wywiera na twoje serwery ... możesz skonfigurować każdy z serwerów, których dotyczy problem, aby usuwał złośliwe pakiety lub po prostu wprowadź zmiany w zaporze ogniowej, a wszystkie serwery są chronione. Posiadanie zapory ogniowej skróciło czas reakcji.

Ty lub ktoś inny może popełnić błąd w konfiguracji serwera pewnego dnia, zapora ogniowa daje drugą szansę powstrzymania kogoś przed wejściem. Nie jesteśmy doskonali, popełniamy błędy, dlatego warto trochę „niepotrzebnego” ubezpieczenia .

(Staraj się nie uruchamiać zapory na tym samym systemie operacyjnym co serwery, ponieważ w przeciwnym razie pojedynczy błąd w systemie operacyjnym .... Uważam, że wszystkie wersje Uniksa są tym samym systemem operacyjnym, ponieważ mają one wiele wspólnego.

Zapory ogniowe są wyspecjalizowane w manipulowaniu ruchem. Robią to szybko i mają zasoby. I nie marnujesz zasobów serwera do filtrowania ruchu (dysk io / proc time / etc). Powinieneś skonfigurować pewne zabezpieczenia w środowisku serwerowym, ale wszystkie inspekcje ruchu i skanowanie antywirusowe itd. Powinny robić wyspecjalizowane serwery.

Byłbym zaniepokojony, że jeśli kiedykolwiek zostaniesz zhakowany i nie będziesz mieć zapory ogniowej. Hakerzy mogą otwierać inne porty na serwerach. Ponadto, jeśli zostanie przyprowadzony konsultant w celu przeprowadzenia czyszczenia i audytu, pierwszą rzeczą, która powie, jest „CO?!?! Nie masz zapory ogniowej!” Wtedy możesz zostać spalony.