UWAGA: Nie jestem zainteresowany przekształceniem tego w wojnę z ogniem! Rozumiem, że wiele osób mocno wierzyło w ten temat, w niemałej części, ponieważ włożyli wiele wysiłku w swoje rozwiązania zapory ogniowej, a także dlatego, że zostali indoktrynowani, by wierzyć w ich konieczność.

Jednak szukam odpowiedzi od osób, które są ekspertami w dziedzinie bezpieczeństwa. Uważam, że jest to ważne pytanie, a odpowiedź przyniesie więcej korzyści niż tylko mnie i firmie, dla której pracuję. Prowadzę naszą sieć serwerów od kilku lat bez kompromisów, bez żadnej zapory ogniowej. Żadnemu z kompromisów bezpieczeństwa, które mieliśmy , nie można było zapobiec za pomocą zapory ogniowej.

Wydaje mi się, że pracuję tu zbyt długo, ponieważ kiedy mówię „serwery”, zawsze mam na myśli „usługi oferowane społeczeństwu”, a nie „tajne wewnętrzne bazy danych rozliczeniowych”. W związku z tym wszelkie reguły, które mielibyśmy w dowolnych zaporach, musiałyby umożliwiać dostęp do całego Internetu. Ponadto nasze serwery z dostępem publicznym znajdują się w dedykowanym centrum danych oddzielnym od naszego biura.

Ktoś inny zadał podobne pytanie, a moja odpowiedź została przegłosowana na liczby negatywne. To prowadzi mnie do przekonania, że ​​albo głosujący za nim nie zrozumieli mojej odpowiedzi, albo nie rozumiem bezpieczeństwa na tyle, by robić to, co obecnie.

Oto moje podejście do bezpieczeństwa serwera:

1. Przed podłączeniem serwera do Internetu postępuj zgodnie ze wskazówkami bezpieczeństwa mojego systemu operacyjnego .

2. Użyj opakowań TCP, aby ograniczyć dostęp do SSH (i innych usług zarządzania) do niewielkiej liczby adresów IP.

3. Monitoruj stan tego serwera za pomocą Munin . I napraw rażące problemy bezpieczeństwa związane z węzłem Munin w jego domyślnej konfiguracji.

4. Nmap mój nowy serwer (także przed podłączeniem mojego serwera do Internetu). Gdybym miał zaporę ogniową na tym serwerze, powinien to być dokładny zestaw portów, do których połączenia przychodzące powinny być ograniczone.

5. Zainstaluj serwer w serwerowni i nadaj mu publiczny adres IP.

6. Zabezpiecz system, korzystając z funkcji aktualizacji zabezpieczeń mojego systemu operacyjnego.

Moja filozofia (i podstawa pytania) jest taka, że ​​silne zabezpieczenia oparte na hoście eliminują konieczność zapory ogniowej. Ogólna filozofia bezpieczeństwa mówi, że silne zabezpieczenia oparte na hoście są nadal wymagane, nawet jeśli masz zaporę ogniową (zobacz wytyczne dotyczące bezpieczeństwa ). Powodem tego jest to, że zapora ogniowa, która przekazuje usługi publiczne na serwer, umożliwia atakującemu tyle samo, co brak zapory ogniowej. Słaba jest sama usługa, a ponieważ oferowanie tej usługi w całym Internecie jest wymogiem jej działania, ograniczanie dostępu do niej nie jest celem.

Jeśli na serwerze są dostępne porty, do których dostęp nie musi być uzyskiwany przez cały Internet, to oprogramowanie musiało zostać zamknięte w kroku 1 i zostało zweryfikowane w kroku 4. Jeśli osoba atakująca z powodzeniem włamie się na serwer za pośrednictwem podatnego na atak oprogramowania i samodzielnie otworzyć port, atakujący może (i robi) równie łatwo pokonać dowolną zaporę ogniową, nawiązując połączenie wychodzące na losowym porcie. Bezpieczeństwo nie polega na tym, by bronić się po udanym ataku - który już okazał się niemożliwy - ma przede wszystkim powstrzymać atakujących.

Sugeruje się, że oprócz otwartych portów istnieją inne względy bezpieczeństwa, ale dla mnie to brzmi jak obrona wiary. Wszelkie luki w zabezpieczeniach systemu operacyjnego / stosu TCP powinny być równie narażone na atak, niezależnie od tego, czy istnieje zapora ogniowa - w zależności od tego, że porty są przekazywane bezpośrednio do tego systemu operacyjnego / stosu TCP. Podobnie, uruchamianie zapory ogniowej na samym serwerze w przeciwieństwie do posiadania go na routerze (lub co gorsza, w obu miejscach) wydaje się dodawać niepotrzebne warstwy złożoności. Rozumiem filozofię „bezpieczeństwo przychodzi warstwami”, ale przychodzi moment, w którym przypomina budowanie dachu przez ułożenie X warstw warstw sklejki jeden na drugim, a następnie wywiercenie przez nie otworu. Kolejna warstwa sklejki nie powstrzyma wycieków przez tę dziurę, którą „

Szczerze mówiąc, jedynym sposobem, w jaki widzę zaporę ogniową w jakimkolwiek celu, jest użycie dynamicznych reguł zapobiegających wszelkim połączeniom ze wszystkimi serwerami od znanych atakujących - takich jak RBL dla spamu (który przypadkiem jest właściwie tym, co robi nasz serwer pocztowy) . Niestety nie mogę znaleźć żadnych zapór ogniowych, które to robią. Następną najlepszą rzeczą jest serwer IDS, ale zakłada się, że atakujący nie atakuje najpierw twoich prawdziwych serwerów i że atakujący zadają sobie trud sondowania całej sieci przed atakiem. Poza tym wiadomo, że wytwarzają dużą liczbę fałszywych trafień.

Zalety zapory ogniowej:

1. Możesz filtrować ruch wychodzący.
2. Zapory warstwy 7 (IPS) mogą chronić przed znanymi lukami w zabezpieczeniach aplikacji.
3. Możesz zablokować określony zakres adresów IP i / lub portu centralnie, zamiast próbować upewnić się, że nie ma usługi nasłuchującej na tym porcie na każdym komputerze lub odmówić dostępu za pomocą opakowań TCP .
4. Zapory ogniowe mogą pomóc, jeśli masz do czynienia z mniej świadomymi pod względem bezpieczeństwa użytkownikami / administratorami, ponieważ stanowili drugą linię obrony. Bez nich trzeba mieć absolutną pewność, że hosty są bezpieczne, co wymaga dobrego zrozumienia bezpieczeństwa od wszystkich administratorów.
5. Dzienniki zapory dostarczałyby dzienników centralnych i pomagały w wykrywaniu skanów pionowych. Dzienniki zapory mogą pomóc w określeniu, czy jakiś użytkownik / klient próbuje okresowo łączyć się z tym samym portem wszystkich serwerów. Aby to zrobić bez zapory ogniowej, należałoby połączyć dzienniki z różnych serwerów / hostów, aby uzyskać scentralizowany widok.
6. Zapory ogniowe są również wyposażone w moduły antyspamowe / antywirusowe, które również zwiększają ochronę.
7. Bezpieczeństwo niezależne od systemu operacyjnego. W zależności od systemu operacyjnego hosta wymagane są różne techniki / metody, aby zapewnić bezpieczeństwo hosta. Na przykład opakowania TCP mogą nie być dostępne na komputerach z systemem Windows.

Przede wszystkim, jeśli nie masz firewalla, a system jest zagrożony, to jak byś go wykrył? Nie można ufać próbie uruchomienia komendy „ps”, „netstat” itp. W systemie lokalnym, ponieważ te pliki binarne można zastąpić. „nmap” ze zdalnego systemu nie jest gwarantowaną ochroną, ponieważ osoba atakująca może zapewnić, że root-kit akceptuje połączenia tylko z wybranych źródłowych adresów IP w wybranych momentach.

Zapory sprzętowe pomagają w takich sytuacjach, ponieważ zmiana OS / plików zapory jest niezwykle trudna w porównaniu z plikami OS / plików hosta.

Wady zapory ogniowej:

1. Ludzie czują, że zapora ogniowa zadba o bezpieczeństwo i nie będzie regularnie aktualizować systemów oraz zatrzymywać niechcianych usług.
2. One kosztują. Czasami należy uiścić roczną opłatę licencyjną. Zwłaszcza jeśli zapora ma moduły antywirusowe i antyspamowe.
3. Dodatkowy pojedynczy punkt awarii. Jeśli cały ruch przechodzi przez zaporę ogniową, a zapora zawodzi, sieć przestaje działać. Możemy mieć zbędne zapory ogniowe, ale poprzedni punkt dotyczący kosztów jest dalej wzmacniany.
4. Stanowe śledzenie nie ma żadnej wartości w systemach publicznych, które akceptują wszystkie połączenia przychodzące.
5. Stanowe zapory ogniowe są ogromnym wąskim gardłem podczas ataku DDoS i często są pierwszą rzeczą, która zawodzi, ponieważ próbują utrzymać stan i sprawdzić wszystkie połączenia przychodzące.
6. Zapory ogniowe nie widzą wewnątrz zaszyfrowanego ruchu. Ponieważ cały ruch powinien być szyfrowany od końca do końca, większość zapór ogniowych wnosi niewielką wartość przed serwery publiczne. Niektóre zapory nowej generacji mogą otrzymać prywatne klucze do zakończenia TLS i zobaczenia ruchu, jednak to jeszcze bardziej zwiększa podatność zapory na DDoS i łamie kompleksowy model bezpieczeństwa TLS.
7. Systemy operacyjne i aplikacje są usuwane z luk w zabezpieczeniach znacznie szybciej niż zapory ogniowe. Dostawcy zapór często siedzą przez lata na znanych problemach bez łatania, a łatanie klastra zapory zwykle wymaga przestoju dla wielu usług i połączeń wychodzących.
8. Zapory ogniowe są dalekie od ideału, a wiele z nich jest notorycznie wadliwych. Zapory ogniowe to po prostu oprogramowanie działające na jakiejś formie systemu operacyjnego, być może z dodatkowym układem ASIC lub FPGA oprócz (zwykle wolnego) procesora. Zapory ogniowe zawierają błędy, ale wydają się zapewniać niewiele narzędzi do ich usunięcia. Dlatego zapory ogniowe zwiększają złożoność aplikacji i dodatkowe źródło trudnych do zdiagnozowania błędów w stosie aplikacji.

Opakowania TCP można prawdopodobnie nazwać implementacją zapory opartej na hoście; filtrujesz ruch sieciowy.

W przypadku atakującego, który wykonuje połączenia wychodzące na dowolnym porcie, zapora ogniowa zapewniłaby również sposób kontrolowania ruchu wychodzącego; właściwie skonfigurowana zapora zarządza wejściem i wyjściem w sposób odpowiedni do ryzyka związanego z systemem.

Jeśli chodzi o to, w jaki sposób zapora sieciowa nie ogranicza luki w zabezpieczeniach TCP, nie wiesz, jak działają zapory. Cisco udostępnia całą masę reguł do pobrania, które identyfikują pakiety zbudowane w sposób, który spowodowałby określone problemy z systemem operacyjnym. Jeśli złapiesz Snorta i zaczniesz go uruchamiać z właściwym zestawem reguł, zostaniesz również powiadomiony o tego rodzaju rzeczach. I oczywiście Linux iptables może odfiltrowywać złośliwe pakiety.

Zasadniczo zapora ogniowa stanowi ochronę proaktywną. Im bardziej odejdziesz od proaktywności, najprawdopodobniej znajdziesz się w sytuacji, w której reagujesz na problem, zamiast go zapobiegać. Skoncentrowanie ochrony na granicy, tak jak w przypadku dedykowanej zapory ogniowej, ułatwia zarządzanie, ponieważ masz centralny punkt dławienia, a nie wszędzie powielające się reguły.

Ale żadna rzecz nie jest koniecznie ostatecznym rozwiązaniem. Dobrym rozwiązaniem bezpieczeństwa jest na ogół wielowarstwowy, w którym masz firewall na granicy, owijarki TCP na urządzeniu i prawdopodobnie pewne reguły na wewnętrznych routerach. Zazwyczaj należy chronić sieć przed Internetem i chronić węzły przed sobą. To wielowarstwowe podejście nie przypomina wiercenia dziury w wielu arkuszach sklejki, jest bardziej jak zakładanie pary drzwi, aby intruz miał dwa zamki do złamania zamiast jednego; w fizycznym bezpieczeństwie nazywa się to pułapką człowieka, a większość budynków ma jeden z jakiegoś powodu. :)

(Możesz przeczytać „ Życie bez zapór ogniowych ”)

Teraz: A co z posiadaniem starszego systemu, dla którego nie będą już publikowane żadne łatki? Co powiesz na to, że nie będziesz w stanie zastosować poprawek do N-maszyn w tym samym czasie, gdy będziesz musiał to zrobić, a jednocześnie możesz zastosować je w mniejszej liczbie węzłów w sieci (zapory ogniowe)?

Nie ma sensu dyskutować o istnieniu lub potrzebie zapory. Liczy się to, że musisz wdrożyć politykę bezpieczeństwa. Aby to zrobić, użyjesz wszelkich narzędzi, które go wdrożą i pomogą Ci zarządzać, rozszerzać i rozwijać. Jeśli do tego potrzebne są zapory ogniowe, to w porządku. Jeśli nie są potrzebne, to też dobrze. Najważniejsze jest sprawne i możliwe do zweryfikowania wdrożenie polityki bezpieczeństwa.

Większość twoich wyjaśnień wydaje się zaprzeczać potrzebie zapory ogniowej, ale nie widzę wady, by mieć taką zaporę, z wyjątkiem małej ilości czasu na jej skonfigurowanie.

Niewiele rzeczy jest „koniecznością” w ścisłym znaczeniu tego słowa. Bezpieczeństwo polega bardziej na ustawianiu wszystkich blokad, które możesz. Im więcej pracy potrzeba włamać się na serwer, tym mniejsze szanse na udany atak. Chcesz sprawić, by włamanie się do twoich maszyn było więcej pracy niż gdzie indziej. Dodanie zapory sprawia, że ​​więcej pracy.

Myślę, że kluczowym zastosowaniem jest nadmiar bezpieczeństwa. Kolejną zaletą zapór ogniowych jest po prostu porzucenie prób połączenia z dowolnym portem zamiast odpowiadania na odrzucone żądania - spowoduje to, że nmapping będzie nieco bardziej niewygodny dla atakującego.

Najważniejsze dla mnie w praktycznej uwadze twojego pytania jest to, że możesz zablokować SSH, ICMP i inne usługi wewnętrzne do lokalnych podsieci, a także ograniczyć połączenia przychodzące, aby złagodzić ataki DOS.

„Bezpieczeństwo nie polega na obronie po udanym ataku - który już okazał się niemożliwy - ma przede wszystkim na celu powstrzymanie atakujących”.

Nie zgadzam się. Równie ważne może być ograniczenie szkód. (pod tym ideałem, dlaczego hasła hashowe? lub trzymać oprogramowanie bazy danych na innym serwerze niż aplikacje internetowe?) Myślę, że stare powiedzenie „Nie wkładaj wszystkich jajek do jednego koszyka” ma tutaj zastosowanie.

Should I firewall my server?Dobre pytanie. Wydaje się, że nie ma sensu umieszczać zapory ogniowej na stosie sieci, który już odrzuca próby połączenia ze wszystkimi, oprócz garści portów, które są legalnie otwarte. Jeśli w systemie operacyjnym istnieje luka, która pozwala złośliwie spreparowanym pakietom na zakłócenie / wykorzystanie hosta, czy zapora ogniowa uruchomiona na tym samym hoście zapobiegałaby wykorzystaniu tego? Cóż, może ...

Jest to prawdopodobnie najsilniejszy powód, aby uruchomić zaporę ogniową na każdym hoście: zapora ogniowa może uniemożliwić wykorzystanie luki w zabezpieczeniach stosu sieciowego. Czy to wystarczający powód? Nie wiem, ale przypuszczam, że można powiedzieć: „Nikt nigdy nie został zwolniony za zainstalowanie zapory ogniowej”.

Innym powodem uruchomienia zapory ogniowej na serwerze jest rozłączenie tych dwóch silnie skorelowanych obaw:

1. Skąd i do jakich portów, czy akceptuję połączenia?
2. Które usługi działają i nasłuchują połączeń?

Bez zapory ogniowej zestaw uruchomionych usług (wraz z konfiguracjami tcpwrapperów itp.) Całkowicie określa zestaw portów, które serwer będzie miał otwarty i od których będą akceptowane połączenia. Zapora oparta na hoście zapewnia administratorowi dodatkową elastyczność w instalowaniu i testowaniu nowych usług w kontrolowany sposób przed ich szerszym udostępnieniem. Jeśli taka elastyczność nie jest wymagana, istnieje mniej powodów, aby instalować zaporę ogniową na serwerze.

Na koniec, jest jeden element niewymieniony na twojej liście kontrolnej bezpieczeństwa, który zawsze dodaję, a mianowicie oparty na hoście system wykrywania włamań (HIDS), taki jak AIDE lub samhain . Dobry HIDS sprawia, że ​​intruzowi niezwykle trudno jest wprowadzić niepożądane zmiany w systemie i pozostać niewykrytym. Uważam, że na wszystkich serwerach powinien być uruchomiony jakiś rodzaj HIDS.

Zapora ogniowa to narzędzie. Nie zapewnia bezpieczeństwa samego w sobie, ale może przyczynić się jako warstwa w bezpiecznej sieci. To nie znaczy, że potrzebujesz go i na pewno martwię się o ludzi, którzy na oślep mówią: „Muszę zdobyć zaporę ogniową”, nie rozumiejąc, dlaczego tak myślą i którzy nie rozumieją mocnych i słabych stron zapór ogniowych.

Istnieje wiele narzędzi, które możemy powiedzieć, że nie są nam potrzebne ... Czy można uruchomić komputer z systemem Windows bez programu antywirusowego? Tak, to jest ... ale miło jest mieć ubezpieczenie.

Powiedziałbym to samo o zaporach ogniowych - wszystko, co możesz o nich powiedzieć, to niezły poziom ubezpieczenia. Nie zastępują łatania, blokowania maszyn, wyłączania usług, których nie używasz, logowania itp., Ale mogą być przydatnym uzupełnieniem.

Sugeruję również, aby równanie zmieniło się nieco w zależności od tego, czy mówisz o umieszczeniu zapory ogniowej przed grupą starannie utrzymanych serwerów, jak się wydaje, czy typową siecią LAN z mieszanką stacji roboczych i serwerów , z których niektóre mogą być włochate, pomimo najlepszych starań i życzeń zespołu IT.

Jeszcze jedną rzeczą do rozważenia jest korzyść z utworzenia wyraźnie zahartowanego celu. Widoczne bezpieczeństwo, niezależnie od tego, czy są to jasne światła, ciężkie zamki i oczywista skrzynka alarmowa na budynku; lub oczywista zapora ogniowa w zakresie adresów IP firmy może zniechęcić przypadkowego intruza - będą szukać łatwiejszej ofiary. Nie zniechęci to zdecydowanego intruza, który wie, że masz informacje, których chcą i jest zdeterminowany, aby je zdobyć, ale odstraszanie przypadkowych intruzów jest nadal opłacalne - szczególnie jeśli wiesz, że każdy intruz, którego sondy przetrwają po odstraszaniu, musi być potraktowany szczególnie poważnie .

Wszystkie świetne pytania. ALE - jestem bardzo zaskoczony WYDAJNOŚĆ nie pojawiła się na stole.

W przypadku wysoce (pod względem CPU) używanych interfejsów WWW lokalna zapora ogniowa naprawdę obniża wydajność, okres. Wypróbuj test obciążenia i zobacz. Widziałem to mnóstwo razy. Wyłączenie zapory zwiększyło wydajność (żądanie na sekundę) o 70% lub więcej.

Ten kompromis należy wziąć pod uwagę.

Zapora ogniowa stanowi dodatkową ochronę. Trzy szczególne scenariusze, przed którymi chroni, to ataki na stos sieciowy (tj. System operacyjny serwera ma luki w specjalnie spreparowanych pakietach, które nigdy nie osiągają poziomu portów), udany włamanie nawiązujące połączenie z „telefonem do domu” (lub wysyłanie spamu lub cokolwiek innego ) lub udanego włamania do otwarcia portu serwera lub, co jest mniej wykrywalne, obserwuj sekwencję pukania portów przed otwarciem portu. To prawda, że ​​ostatnie dwa dotyczą łagodzenia obrażeń włamań, a nie zapobiegania, ale to nie znaczy, że jest bezużyteczne. Pamiętaj, że bezpieczeństwo nie jest propozycją „wszystko albo nic”; jeden stosuje podejście warstwowe, pas i szelki, aby osiągnąć poziom bezpieczeństwa wystarczający dla twoich potrzeb.

W żadnym wypadku nie jestem ekspertem od bezpieczeństwa, ale brzmi to tak, jakbyś był zaporą ogniową. Wygląda na to, że wziąłeś niektóre z podstawowych funkcji zapory i włączyłeś ją do swoich zasad i procedur. Nie, nie potrzebujesz firewalla, jeśli sam wykonujesz tę samą pracę, co firewall. Jeśli chodzi o mnie, wolałbym zrobić wszystko, co w mojej mocy, aby zachować bezpieczeństwo, ale niech zapora spogląda mi przez ramię, ale w pewnym momencie, gdy możesz zrobić wszystko, co robi zapora, zaczyna to tracić znaczenie.

Zapora ogniowa z pewnością nie jest potrzebna w przypadku mniejszych konfiguracji. Jeśli masz jeden lub dwa serwery, zapory programowe można konserwować. Powiedziawszy to, nie działamy bez dedykowanych zapór ogniowych i istnieje kilka powodów, dla których utrzymuję tę filozofię:

Rozdzielenie ról

Serwery przeznaczone są do aplikacji. Zapory ogniowe służą do kontroli pakietów, filtrowania i zasad. Serwer WWW powinien martwić się o wyświetlanie stron internetowych i to wszystko. Umieszczenie obu ról w jednym urządzeniu jest jak poproszenie księgowego o ochronę.

Oprogramowanie jest ruchomym celem

Oprogramowanie na hoście zawsze się zmienia. Aplikacje mogą tworzyć własne wyjątki zapory. System operacyjny został zaktualizowany i załatany. Serwery są obszarem „administratora” o dużym natężeniu ruchu, a Twoje zasady zapory / zasady bezpieczeństwa są często o wiele ważniejsze dla bezpieczeństwa niż konfiguracje aplikacji. W środowisku Windows załóżmy, że ktoś popełnia błąd na pewnym poziomie zasad grupy i wyłącza Zaporę systemu Windows na komputerach stacjonarnych i nie zdaje sobie sprawy, że zostanie zastosowane na serwerach. Jesteś szeroko otwarty za sprawą kilku kliknięć.

Mówiąc tylko o aktualizacjach, aktualizacje oprogramowania zapory zwykle pojawiają się raz lub dwa razy w roku, podczas gdy aktualizacje systemu operacyjnego i usług są stałym strumieniem.

Usługi / zasady / zasady wielokrotnego użytku, łatwość zarządzania

Jeśli raz skonfiguruję usługę / zasadę o nazwie „Serwer WWW” (powiedzmy TCP 80 i TCP 443) i zastosuję ją do „grupy serwerów WWW” na poziomie zapory ogniowej, będzie to znacznie bardziej wydajne (kilka zmian w konfiguracji) i wykładniczo mniej podatny na błędy ludzkie niż konfigurowanie usług zapory na 10 urządzeniach i otwieranie 2 portów x 10 razy. Kiedy ta polityka musi się zmienić, jest to 1 zmiana vs. 10.

Nadal mogę zarządzać zaporą ogniową podczas ataku lub po kompromisie

Powiedz, że mój firewall + serwer aplikacji został zaatakowany, a procesor nie działa. Aby nawet dowiedzieć się, co się dzieje, jestem na łasce, że mój ładunek jest mniejszy niż atakujący, aby nawet wejść i spojrzeć na to.

Rzeczywiste doświadczenie - kiedyś zawiodłem regułę zapory ogniowej (pozostawiłem porty KAŻDEM zamiast określonej, a serwer miał wrażliwą usługę), a atakujący faktycznie miał sesję Pulpitu zdalnego na żywo. Za każdym razem, gdy zaczynam mieć sesję, atakujący zabija / rozłącza moją sesję. Gdyby nie to, że udało się zamknąć atak z niezależnego urządzenia zapory ogniowej, mogłoby być znacznie gorzej.

Niezależne monitorowanie

Logowanie do dedykowanych jednostek zapory jest zwykle znacznie lepsze niż zapory programowe oparte na hoście. Niektóre są na tyle dobre, że nie potrzebujesz nawet zewnętrznego oprogramowania do monitorowania SNMP / NetFlow, aby uzyskać dokładny obraz.

Ochrona IPv4

Nie ma powodu, aby mieć dwa adresy IP, jeśli jeden jest przeznaczony do Internetu, a drugi do poczty. Usługi należy przechowywać w osobnych skrzynkach i odpowiednio trasować porty za pomocą urządzenia do tego przeznaczonego.

Blockquote Cóż, masz rację, nie włożyłem żadnych wad. Wady: zwiększona złożoność sieci, pojedynczy punkt awarii, pojedynczy interfejs sieci, przez który przepustowość jest wąska. Podobnie błędy administracyjne popełnione na jednej zaporze mogą zabić całą sieć. I bogowie zabraniają ci się przed tym zamykać, gdy jest 20 minut podróży do serwerowni.

Po pierwsze, dodanie co najwyżej jednego dodatkowego skoku z trasy przez sieć nie jest skomplikowane. Po drugie, żadne zapora ogniowa zaimplementowana z żadnym punktem awarii nie jest całkowicie bezużyteczna. Podobnie jak klaster ważnego serwera lub usług i korzystanie z połączonych kart sieciowych, wdrażasz wysoce dostępne zapory ogniowe. Niezrobienie tego lub nie rozpoznanie i nie wiedząc, że to zrobisz, jest bardzo krótkowzroczne. Samo stwierdzenie, że istnieje jeden interfejs, nie powoduje automatycznie wąskiego gardła. To twierdzenie pokazuje, że nie masz pojęcia, jak właściwie zaplanować i wdrożyć zaporę o rozmiarze odpowiednim do obsługi ruchu, który przepływałby przez twoją sieć. Masz rację mówiąc, że błąd w zasadach może wyrządzić szkodę całej sieci, ale twierdzę, że utrzymywanie indywidualnych zasad na wszystkich twoich serwerach jest znacznie bardziej podatne na błędy niż w jednym miejscu.

Co do argumentu, że nadążasz za łataniem zabezpieczeń i postępujesz zgodnie z instrukcjami bezpieczeństwa; to w najlepszym razie niepewny argument. Zwykle łaty bezpieczeństwa są dostępne dopiero po wykryciu podatności. Oznacza to, że przez cały czas korzystania z publicznie adresowalnych serwerów są one podatne na atak, dopóki nie zostaną załatane. Jak zauważyli inni, systemy IPS mogą zapobiegać zagrożeniom wynikającym z takich luk.

Jeśli uważasz, że twoje systemy są tak bezpieczne, jak to tylko możliwe, to jest to wystarczające zaufanie. Zalecam jednak przeprowadzenie profesjonalnego audytu bezpieczeństwa w sieci. Może po prostu otworzyć oczy.

Ogólnie rzecz biorąc, bezpieczeństwo jest rzeczą cebulową, jak już wspomniano. Istnieją powody, dla których istnieją zapory ogniowe, i nie tylko wszystkie inne lemingi są głupimi kretynami.

Ta odpowiedź pochodzi, ponieważ wyszukiwanie hasła „fail2ban” na tej stronie nie dało mi żadnych wyników. Więc jeśli podwoję inne treści, zachowajcie mnie. I przepraszam, jeśli trochę wygaduję, zapewniam proste doświadczenie, ponieważ może się przydać innym. :)

Uwagi dotyczące sieci, lokalne a zewnętrzne

Jest to raczej specyficzne dla Linuksa i koncentruje się na firewallu opartym na hoście, co zwykle jest przypadkiem użycia. Zewnętrzna zapora ogniowa idzie w parze z odpowiednią strukturą sieci i zwykle uwzględniają to inne względy bezpieczeństwa. Albo wiesz, co to sugeruje, prawdopodobnie nie będziesz potrzebować tego postu. Albo nie, to po prostu czytaj dalej.

Uruchamianie zapór zewnętrznych i lokalnych może wydawać się sprzeczne z intuicją i podwójną pracą. Daje to jednak również możliwość zmiany reguł na zewnętrznym, bez narażania bezpieczeństwa wszystkich pozostałych hostów za tym stojących. Potrzeba może wynikać z przyczyn debugowania lub dlatego, że ktoś właśnie spieprzył. Kolejny przypadek użycia pojawi się w sekcji „globalna zapora ogniowa adaptacyjna”, do której potrzebne będą również zapory globalne i lokalne.

Koszt i dostępność i ta sama historia przez cały czas:

Zapora ogniowa jest tylko jednym z aspektów odpowiednio zabezpieczonego systemu. Nie instalując zapory ogniowej, ponieważ „kosztuje” pieniądze, wprowadza SPOF lub cokolwiek innego, to bzdury, przepraszam za mój francuski tutaj. Wystarczy skonfigurować klaster. Och, ale co, jeśli komórka ogniowa ma awarię? Następnie ustaw klaster na dwa lub więcej przedziałów ogniowych.

Ale co, jeśli całe centrum danych jest nieosiągalne, ponieważ oba zewnętrzne nośniki są nieczynne (koparka zabiła twoje włókno)? Po prostu spraw, aby twój klaster obejmował kilka centrów danych.

To jest drogie? Klastry są zbyt złożone? Cóż, za paranoję trzeba zapłacić.

Samo marudzenie na temat SPOF, ale nie chcieć płacić więcej pieniędzy lub tworzyć nieco bardziej skomplikowane konfiguracje, to wyraźny przypadek podwójnych standardów lub po prostu małego portfela po stronie firmy lub klienta.

Ten wzór dotyczy WSZYSTKICH tych dyskusji, bez względu na to, która usługa jest aktualną sprawą dnia. Bez względu na to, czy jest to brama VPN, Cisco ASA używana tylko do zapory ogniowej, bazy danych MySQL lub PostgreSQL, systemu wirtualnego lub sprzętu serwerowego, zaplecza pamięci, przełączników / routerów, ...

Do tej pory powinieneś mieć pomysł.

Po co zawracać sobie głowę zaporą ogniową?

Teoretycznie twoje rozumowanie jest rozsądne. (Można korzystać tylko z uruchomionych usług.)

Ale to tylko połowa prawdy. Zapora ogniowa, szczególnie zapora ogniowa stanowa, może zrobić dla ciebie znacznie więcej. Bezstanowe zapory ogniowe są ważne tylko wtedy, gdy występują problemy z wydajnością, takie jak wspomniane wcześniej.

Łatwa, centralna, dyskretna kontrola dostępu

Wspomniałeś o opakowaniach TCP, które implementują tę samą funkcjonalność do zabezpieczenia twojego. Dla argumentu załóżmy, że ktoś nie wie tcpdi lubi używać myszy? fwbuildermoże przyjść na myśl.

Pełny dostęp z sieci zarządzania jest czymś, co powinieneś włączyć, co jest jednym z pierwszych przypadków użycia zapory opartej na hoście.

Co powiesz na konfigurację wieloserwerową, w której baza danych działa gdzie indziej i nie możesz umieścić obu / wszystkich komputerów we wspólnej (prywatnej) podsieci z jakiegokolwiek powodu? Użyj zapory, aby zezwolić na dostęp do MySQL na porcie 3306 tylko dla jednego podanego adresu IP drugiego serwera, gotowe, proste.

I to działa również bezbłędnie dla UDP. Lub jakikolwiek protokół. Zapory ogniowe mogą być tak cholernie elastyczne. ;)

Łagodzenie Portscan

Ponadto, dzięki zaporze ogniowej, można wykrywać i ograniczać ogólne skany portów, ponieważ ilość połączeń w danym okresie czasu można monitorować za pośrednictwem jądra i stosu sieciowego, a zapora może na to działać.

Również niepoprawne lub niejasne pakiety mogą być obsługiwane przed dotarciem do aplikacji.

Ograniczanie ruchu wychodzącego

Filtrowanie ruchu wychodzącego jest zwykle uciążliwe. Ale może być koniecznością, w zależności od umowy.

Statystyka

Kolejną rzeczą, którą zapora może Ci dać, są statystyki. (Pomyśl watch -n1 -d iptables -vnxL INPUTo dodaniu kilku reguł dla specjalnych adresów IP u góry, aby sprawdzić, czy pakiety nadchodzą.)

Możesz zobaczyć w świetle dziennym, czy coś działa, czy nie. Co jest BARDZO przydatne podczas rozwiązywania problemów z połączeniami i możliwości powiadamiania drugiej osoby przez telefon, że nie otrzymujesz pakietów, bez konieczności uciekania się do rozmów tcpdump. Praca w sieci jest fajna, większość ludzi po prostu teraz wie, co robi, a często to tylko proste błędy routingu. Do diabła, nawet ja nie zawsze wiem, co robię. Chociaż pracowałem z dosłownie dziesiątkami skomplikowanych systemów i urządzeń, często także z tunelowaniem.

IDS / IPS

Zapora ogniowa w warstwie 7 jest zwykle olejem wężowym (IPS / IDS), jeśli nie jest odpowiednio obsługiwana i regularnie aktualizowana. Co więcej, licencje są cholernie drogie, więc oszczędzę sobie, jeśli nie będziesz naprawdę potrzebował wszystkiego, co mogą ci kupić pieniądze.

Maskarada

Łatwo, po prostu spróbuj tego ze swoimi opakowaniami. :RE

Lokalne przekierowanie portów

Zobacz maskarada.

Zabezpieczanie kanałów dostępu do hasła za pomocą dynamicznych adresów IP

Co jeśli klienci mają dynamiczne adresy IP i nie ma wdrożonej konfiguracji VPN? Lub inne dynamiczne podejścia do zapory ogniowej? Jest to już wskazane w pytaniu, a tutaj pojawi się przypadek użycia dla Niestety, nie mogę znaleźć żadnych zapór ogniowych, które to robią. część.

Wyłączenie dostępu do konta root za pomocą hasła jest koniecznością. Nawet jeśli dostęp jest ograniczony do niektórych adresów IP.

Ponadto posiadanie gotowego kolejnego konta blanko z logowaniem do hasła w przypadku zgubienia kluczy ssh lub niepowodzenia wdrożenia jest bardzo przydatne, jeśli coś pójdzie naprawdę nie tak (użytkownik ma dostęp administracyjny do komputera i „coś się stało”?). Jest to ten sam pomysł na dostęp do sieci, ponieważ ma on tryb pojedynczego użytkownika w systemie Linux lub korzystanie init=/bin/bashz grublokalnego dostępu jest naprawdę bardzo złe i nie może korzystać z dysku na żywo z jakiegokolwiek powodu. Nie śmiej się, są produkty do wirtualizacji, które tego zabraniają. Nawet jeśli funkcjonalność istnieje, co się stanie, jeśli uruchomiona zostanie przestarzała wersja oprogramowania pozbawiona tej funkcjonalności?

W każdym razie, nawet jeśli uruchomisz demona ssh na jakimś ezoterycznym porcie, a nie na 22, jeśli nie zaimplementowałeś takich rzeczy, jak pukanie portów (aby otworzyć nawet inny port i tym samym łagodzić skany portów, powoli granicząc z byciem zbyt niepraktycznym), skany portów wykryją twoje usługi w końcu.

Zazwyczaj wszystkie serwery są konfigurowane z tą samą konfiguracją, z tymi samymi portami i usługami ze względu na wydajność. Nie można ustawić ssh na innym porcie na każdym komputerze. Nie można go również zmienić na wszystkich komputerach za każdym razem, gdy uważa się, że jest to informacja „publiczna”, ponieważ jest już po skanie. Kwestia nmaplegalności, czy nie, nie stanowi problemu, gdy masz do dyspozycji zhakowane połączenie Wi-Fi.

Jeśli to konto nie ma nazwy „root”, ludzie mogą nie odgadnąć nazwy konta użytkownika „backdoora”. Ale będą wiedzieć, jeśli zdobędą inny serwer od twojej firmy, lub po prostu kupią trochę przestrzeni internetowej i spojrzą na niezrootowane / nieskażone / niezabezpieczone /etc/passwd.

Aby uzyskać czysto teoretyczną ilustrację, mogliby skorzystać z dostępnej na tej stronie witryny, aby uzyskać dostęp do twojego serwera i sprawdzić, jak zwykle działają u Ciebie. Twoje narzędzia do wyszukiwania włamań mogą nie działać 24 godziny na dobę, 7 dni w tygodniu (zwykle robią to w nocy ze względu na wydajność dysku podczas skanowania systemu plików?), A skanery antywirusowe nie są aktualizowane, gdy tylko nowy dzień zero ujrzy światło dzienne, więc będzie nie wykrywaj tych zdarzeń naraz, a bez innych środków ochronnych możesz nigdy nie wiedzieć, co się stało. Aby powrócić do rzeczywistości, jeśli ktoś ma dostęp do exploitów zero-day, jest bardzo prawdopodobne, że i tak nie będzie atakował twoich serwerów, ponieważ są one po prostu drogie. Ma to na celu zilustrowanie, że zawsze istnieje możliwość wejścia do systemu, jeśli pojawi się „potrzeba”.

Ale w tym temacie, po prostu nie używaj dodatkowego konta z hasłem i nie przejmuj się? Proszę czytaj dalej.

Nawet jeśli atakujący zdobędą nazwę i port tego dodatkowego konta, kombinacja fail2ban+ iptableszatrzyma ich na krótko, nawet jeśli użyłeś tylko ośmioliterowego hasła. Plus fail2ban można również wdrożyć dla innych usług, poszerzając horyzont monitorowania!

W przypadku własnych usług, jeśli kiedykolwiek zajdzie taka potrzeba: w zasadzie każda awaria logowania usługi do pliku może uzyskać obsługę fail2ban poprzez udostępnienie pliku, dopasowanie wyrażenia regularnego i liczbę dozwolonych awarii, a zapora sieciowa z przyjemnością zablokuje każdy adres IP jest powiedziane.

Nie mówię, aby używać 8-cyfrowych haseł! Ale jeśli zostaną zablokowani na 24 godziny za pięć prób podania błędnego hasła, możesz zgadnąć, jak długo będą musieli spróbować, jeśli nie będą mieli do dyspozycji botnetu, nawet przy tak kiepskim zabezpieczeniu. Byłbyś zaskoczony tym, jakich haseł używają klienci, nie tylko do ssh. Przejrzenie haseł poczty elektronicznej za pośrednictwem Plesk mówi ci wszystko, czego wolałbyś nie chcieć wiedzieć, gdybyś kiedykolwiek zrobił, ale czego nie próbuję tu oczywiście sugerować. :)

Adaptacyjna globalna zapora ogniowa

fail2banto tylko jedna aplikacja, która używa czegoś podobnego do tego iptables -I <chain_name> 1 -s <IP> -j DROP, ale możesz łatwo zbudować takie rzeczy za pomocą magii Bash dość szybko.

Aby dalej rozwinąć coś takiego, zsumuj wszystkie adresy IP fail2ban z serwerów w Twojej sieci na dodatkowym serwerze, który selekcjonuje wszystkie listy i przekazuje je z kolei do twoich podstawowych zapór blokujących cały ruch już na krawędzi sieci.

Takiej funkcjonalności nie można sprzedać (oczywiście można, ale będzie to po prostu kruchy system i zasysanie), ale trzeba ją wplecić w infrastrukturę.

Możesz na nim także używać adresów IP z czarnej listy lub list z innych źródeł, niezależnie od tego, czy są one agregowane przez ciebie, czy przez zewnętrzne.

W świecie fizycznym ludzie zabezpieczają kosztowności, umieszczając je w sejfach. Ale nie ma sejfu, w który nie można się włamać. Sejfy lub kontenery bezpieczeństwa są oceniane pod względem czasu potrzebnego na wymuszenie wejścia. Celem sejfu jest opóźnienie atakującego na tyle długo, aby zostały wykryte, a aktywne środki następnie zatrzymać atak.

Podobnie właściwym założeniem bezpieczeństwa jest to, że narażone maszyny zostaną ostatecznie zagrożone. Zapory ogniowe i hosty bastionowe nie są skonfigurowane tak, aby uniemożliwiać Twojemu serwerowi (z twoimi cennymi danymi) złamanie zabezpieczeń, ale aby zmusić atakującego, aby najpierw je skompromitował i umożliwił ci wykrycie (i powstrzymanie) ataku przed utratą kosztowności.

Należy pamiętać, że ani zapory ogniowe, ani skarbce bankowe nie chronią przed zagrożeniami z zewnątrz. To jeden z powodów, dla których księgowi bankowi biorą dwa tygodnie urlopu, a serwery mają pełne wewnętrzne środki bezpieczeństwa, nawet jeśli są chronione przez hosty bastionowe.

Wygląda na to, że sugerujesz w oryginalnym poście, że przesyłasz pakiety „świata zewnętrznego” przez zaporę bezpośrednio na serwer. W takim przypadku tak, zapora sieciowa niewiele robi. Lepszą ochronę obwodową zapewniają dwie zapory ogniowe i host bastionowy, w których nie ma bezpośredniego logicznego połączenia z zewnątrz do wewnątrz - każde połączenie kończy się w hoście bastionowym DMZ; każdy pakiet jest odpowiednio sprawdzany (i ewentualnie analizowany) przed przekazaniem.

Luki w zabezpieczeniach są trudne do przewidzenia. Praktycznie niemożliwe jest przewidzenie, w jaki sposób twoja infrastruktura zostanie wykorzystana. Posiadanie zapory ogniowej „podnosi poprzeczkę” dla osoby atakującej, która chce wykorzystać lukę, i jest to ważna część, ZANIM wiesz, czym jest ta luka. Ponadto, konsekwencje zapory ogniowej można łatwo zrozumieć z wyprzedzeniem, więc jest mało prawdopodobne, aby POWODOWAĆ problemy z zaporą ogniową, które są poważniejsze niż problemy, których można uniknąć.

Dlatego „nikt nigdy nie został zwolniony za instalację zapory ogniowej”. Ich wdrożenie wiąże się z bardzo niskim ryzykiem i ma WYSOKIE prawdopodobieństwo, że zapobiegnie lub ograniczy wykorzystanie exploita. Ponadto najbardziej nieprzyjemne luki w zabezpieczeniach są wykorzystywane przez automatyzację, więc wszystko, co „nietypowe”, spowoduje uszkodzenie bota lub przynajmniej sprawi, że pominie cię na korzyść łatwiejszego celu.

Dygresja; zapory ogniowe nie są przeznaczone tylko do Internetu. Twój dział księgowości. nie potrzebuje ssh / cokolwiek na twoim serwerze ldap, więc nie dawaj mu tego. Podział służb wewnętrznych na przedziały może mieć duży wpływ na porządki w przypadku, gdy coś ZBROJE ściany zamku.

Muszę powiedzieć Erniemu, że chociaż wydajesz się, że robisz wiele, aby wzmocnić swoje serwery i złagodzić ataki i luki, nie zgadzam się z twoją postawą na zaporach ogniowych.

Traktuję bezpieczeństwo trochę jak cebulę, ponieważ idealnie masz warstwy, przez które musisz przejść, zanim dotrzesz do rdzenia, i osobiście uważam, że rażąco błędnie jest nie mieć żadnej zapory sprzętowej na obwodzie sieci.

Przyznaję, że podchodzę do tego z „tego, do czego jestem przyzwyczajony”, ale wiem, że co miesiąc otrzymuję ładną małą listę łatek z tych miesięcy od Microsoftu, z których wiele jest wykorzystywanych na wolności . Wyobrażam sobie, że to samo dzieje się w prawie każdym systemie operacyjnym i zestawie aplikacji, o których marzysz.

Teraz nie sugeruję, aby zapory ogniowe zlikwidowały ten problem, a także nie są odporne na błędy / słabości, oczywiście zapora „sprzętowa” to po prostu oprogramowanie działające na stosie sprzętowym.

To powiedziawszy, śpię o wiele bezpieczniej, wiedząc, że jeśli mam serwer, który wymaga tylko portu 443, aby był dostępny z sieci, mój obwód Juniper zapewnia, że ​​tylko port 443 jest dostępny z sieci. Mało tego, ale mój Palo Alto zapewnia, że ​​ruch przychodzący jest odszyfrowywany, sprawdzany, logowany i skanowany w poszukiwaniu IPS / IDS - nie oznacza to, że nie trzeba utrzymywać bezpieczeństwa serwerów i ich aktualności, ale dlaczego NIE odkryłbyś tej korzyści, biorąc pod uwagę, że może ona złagodzić skutki exploitów zero-day i starych dobrych błędów ludzkich?

Po pierwsze, mówiąc o przekierowaniu portów, myślę, że łączysz firewall z NATingiem. Chociaż w dzisiejszych czasach NAT bardzo często funkcjonują jako zapory ogniowe, to nie jest to cel, dla którego zostały zaprojektowane. NAT to narzędzie do routingu. Zapory ogniowe służą do regulowania dostępu. Dla jasności myśli ważne jest, aby te pojęcia były odrębne.

Oczywiście prawdą jest, że umieszczenie serwera za polem NAT, a następnie skonfigurowanie NAT do przekazywania czegokolwiek na ten serwer, nie jest bardziej bezpieczne niż umieszczenie serwera bezpośrednio w Internecie. Nie sądzę, żeby ktokolwiek się z tym kłócił.

Podobnie zapora skonfigurowana tak, aby zezwalała na cały ruch, wcale nie jest zaporą ogniową.

Ale czy „zezwalaj na cały ruch” to tak naprawdę polityka, którą chcesz? Czy ktoś ma kiedyś potrzebę ssh na którykolwiek z twoich serwerów z rosyjskiego adresu IP? Skoro majstrujesz przy konfiguracji jakiegoś nowego eksperymentalnego demona sieciowego, czy cały świat naprawdę potrzebuje do niego dostępu?

Zaletą zapory ogniowej jest to, że pozwala ona pozostać otwartym tylko tym usługom, o których wiesz, że muszą być otwarte i utrzymywać jeden punkt kontroli w celu wdrożenia tej polityki.

Zapory ogniowe z kontrolą stanu pakietów NIE należą przed serwerami publicznymi. Akceptujesz wszystkie połączenia, więc śledzenie stanu jest całkiem bezużyteczne. Tradycyjne zapory ogniowe są ogromną odpowiedzialnością za ataki DDoS i zwykle są pierwszą rzeczą, która zawodzi podczas ataku DDoS, nawet zanim przepustowość łącza lub zasoby serwera zostaną całkowicie zużyte.

Bezstanowe filtry pakietów na routerach mają sens przed serwerami publicznymi, ale tylko wtedy, gdy potrafią obsłużyć szybkość linii całego ruchu wejściowego i wyjściowego (takiego jak sprzętowa lista ACL w routerze).

Google, Facebook, a nawet Microsoft nie stawiają tradycyjnych „zapór ogniowych” przed serwerami publicznymi. Każdy, kto prowadził publiczne usługi sieciowe w skali „więcej niż jednego serwera”, powinien to wiedzieć.

Inne funkcje występujące w tradycyjnych zaporach ogniowych, takie jak Cisco ASA lub cokolwiek, najlepiej wdrożyć na samych hostach, gdzie można je skutecznie skalować. Rejestrowanie, IDS itp. To i tak wszystkie funkcje oprogramowania w zaporach ogniowych, więc stają się ogromnym wąskim gardłem i celem DDoS, jeśli zostaną umieszczone na publicznie dostępnych serwerach.

Dlaczego wszystkie twoje serwery potrzebują adresu publicznego?

Zainstaluj serwer w serwerowni i nadaj mu publiczny adres IP.

Z około 14 serwerów, które regularnie uruchamiam, tylko 2 mają publicznie dostępne interfejsy.

Zredagowano, aby dodać : W innych sieciach, w których miałem udział w zarządzaniu, mogliśmy dowolnie włączać / wyłączać usługi, podczas gdy nie mieliśmy dostępu do zarządzania zaporą. Nie mogę nawet powiedzieć, ile razy, niechcący, niechciana usługa (SMTP) była włączana i wyłączana, a jedyną rzeczą, która uratowała nas przed zrzuceniem spamu i umieszczeniem na czarnej liście, była zapora ogniowa.

Czy cały ruch przesyłany między serwerami jest w pełni zaszyfrowany?

Z pewnością możesz prowadzić samochód 100 mil na godzinę bez pasów bezpieczeństwa, bez poduszek powietrznych i łysych opon, ale dlaczego miałbyś?

Zapory ogniowe mogą uniemożliwić użytkownikom systemu otwieranie usług dostępnych w sieci, o których administratorzy nie są świadomi, lub przekierowywanie portów na inne komputery. Korzystając z modułu hashlimit, zapory ogniowe mogą również ograniczać szybkość osób nadużywających na podstawie zdalnego adresu IP.

Zapora to kolejna sieć bezpieczeństwa, która zapewnia przestrzeganie twoich zasad. Jasne, nie uruchamiaj usług, których się nie spodziewasz.

Zdecydowanie zalecam na przykład, aby aktualizacje oprogramowania były stosowane na czas, ale zalecam także zapory na wszystkich komputerach. To jak podczas jazdy: pewnie staram się omijać przeszkody i inne samochody, ale też zapinam pasy bezpieczeństwa i mam poduszki powietrzne na wypadek nieoczekiwanego zdarzenia.

Być może nie zdajesz sobie sprawy, ile korzyści czerpiesz z zapór ogniowych, po prostu dlatego, że wszyscy inni z nich korzystają. W dniu, w którym dosłownie wszyscy, nawet użytkownicy domowi DSL mają zapory ogniowe w miejscu, wąchanie portów zostało prawie całkowicie odrzucone jako wykonalny wektor ataku. Przyzwoity haker nie marnuje czasu na sprawdzanie takich rzeczy.