Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

Nie tylko antywirus: firewall też może być niepotrzebny

Znowu miałem pisać o czymś innym , ale poruszona niegdyś tematyka antywirusów wraca do mnie okresowo, zwyczajowo w akompaniamencie, powiedzmy, niskiej aprobaty. Niedawny wpis o bezzasadności stosowania oprogramowania antywirusowego ponownie obudził rzeszę głęboko wierzących i praktykujących posiadaczy takowego, co zazwyczaj idzie w parze z feerią przerażających argumentów, z którymi nie da się dyskutować, nie wykazując głębokiego zwątpienia w przyszłość ludzkości. Stąd też poza obowiązkowym usprawiedliwianiem błędu logicznego, jakim jest antywirus, mogłem zaobserwować również licytację w temacie całych „pakietów zabezpieczających”. O ile jestem w stanie zrozumieć (acz nie poprzeć) kwestię samego antywirusa, będącego pozostałością po okropnych przyzwyczajeniach, to pławienie się w całym arsenale zbędnego oprogramowania budzi mój głęboki niepokój.

Baza wirusów została zaktualizowana

Spróbujmy sobie przypomnieć, co to jest pakiet zabezpieczający, czyli słynne oprogramowanie „internet security”. Nazwa niezmiennie kojarzy się z rokiem 2004, co nie daje o sobie zapomnieć ani przez chwilę. Otóż, po krótkiej wycieczce po stronach producentów, możemy się dowiedzieć, że pakiet bezpieczeństwa to połączenie antywirusa, ochrony rodzicielskiej, narzędzi do kopii zapasowej oraz zapory. A więc doprawdy rok 2004, albo nawet wcześniej. Żaden z owych produktów nie jest potrzebny, a na czele rankingu zbędności znajdzie się bezsprzecznie zapora. Na zapory jeszcze nie narzekałem, ale ponieważ planuję podejść do tematu z podobnym pietyzmem, jak do antywirusów, moje narzekanie będzie dosadne i wielopłaszczyznowe.

Pozwolę sobie podzielić się szeregiem obserwacji, dowodzących, że zapór internetowych (firewalli) niemal nikt wokoło nie rozumie. Będzie trzeba nieco się pobawić, ale spróbujemy dowieść, że dodatkowa zapora w systemie jest zbędna, przypomnieć, dlaczego w ogóle jakakolwiek powinna być niepotrzebna, a na końcu podkreślić, że w praktyce w codziennych scenariuszach zapory już o dawna nic nie dają. Zacznijmy więc.

r   e   k   l   a   m   a

I will build a great wall on our southern border...

Gdy kilkanaście lat temu przechodziłem z Windows Millennium na Auroksa (a następnie Fedorę), pierwszą rzeczą, jaką robiłem, była konfiguracja zapory iptabes (chain INPUT policy DROP). Wcześniej na Windowsach stosowałem zaporę Zone Alarm i antywirusa Dr. Web (od czasu do czasu dokonywałem też skanu offline programem SpyBot Search & Destroy). Dokonałem więc organizacyjnej kalki: nasłuchałem się, że na Linuksa wirusów nie ma, ale nikt mi nie mówił nic o zaporach. Dziarsko więc tkałem polityki dla łańcuchów iptables, nie zawsze w pełni wiedząc, co tak naprawdę robię. Kończyło się to kilkoma zabawnymi zakleszczeniami: pierwszym problemem, jaki na siebie ściągnąłem, było zablokowanie odpytań DNS. Na początku nawet tego nie zauważyłem (!), ale oczywiście mowa tu o minutach, a nie dniach. Internet w roku 2004 działał nieco inaczej, niż obecnie, połączenie z jedną stroną nie wywoływało eksplozji zapytań w stronę setek serwerów CDN, nierzadko dało się żyć w błogiej nieświadomości braku DNSów, lecąc na danych z pamięci podręcznej. Problem dostrzegłem nie wskutek nieładowania stron przez Mozillę 1.7, a przez… awarię X11. Nie rysowało się bowiem żadne nowe okno. Dlaczego? Bo system był skonfigurowany tak, by nazwa hosta z DNS miała bezwarunkową precedencję wobec pliku hostów :D W konsekwencji czego żadne okno nie widziało, gdzie ma się wyświetlić. Była to pouczająca lekcja, ale bardziej dotyczyła X11, niż specyfiki działania zapory. Los zmusił mnie do pogłębienia wiedzy, gdy ustawiłem iptables bez wskazania ujścia dla logów. Dzięki temu, każdy filtrowany pakiet skutkował litanią wyrzucaną na standardowy błąd, a więc każdy terminal tty i każde aktywne okienko konsoli (zaszalałem). Wszelkie programy z interfejsem ncurses ulegały erozji, ponieważ iptables pisał po nich, wyrywając dziury, nierzadko w innym kolorze. Musiałem to prędko naprawić, więc udałem się na polowanie po forach. Prędko znalazłem odpowiedź, ale przy okazji zapytałem też na polskim kanale IRC (co oznacza, że siedzę na nim od 12 lat co najmniej). Przedstawiłem swoją sytuację: że odfiltrowałem wszystko – pingi, infrastrukturalny multicast, NTP… Zanim zapytałem o śmieci na terminalu, to mnie zadano pytanie, brzmiające „po co”?

...and I will have Mexico pay for that wall!

Początkowo go nie zrozumiałem. No bo jak to „po co”? Żeby złoczyńcy nie dostali się do komputera! Więc niech nie odrzuca połączeń, tylko w ogóle zrzuca wszystkie niechciane pakiety! Postanowiono mi otworzyć oczy na to, jak działa firewall. A żeby wiedzieć, co robi firewall, trzeba przez chwilę poczytać, jak działają programowe gniazda sieciowe (sockets).

Otóż: połączenie z zewnątrz nie zostanie zestawione, jeżeli po lokalnej stronie nic nie „słucha”. Innymi słowy, musi istnieć proces (serwer), który następnie dzierżawi gniazdko na jakimś porcie TCP i ustawia je w tryb LISTEN. Gdy połączenie z zewnątrz zechce zestawić łącze z owym serwerem, gniazdko „wiąże się” z nim (bind), tryb zmienia się na ESTABLISHED, a następnie (zazwyczaj) następuje rozwidlenie procesu serwera, gdy mógł on słuchać dalej, celem obsłużenia nowych połączeń. Nie wspominając oczywiście o tym, że obie strony muszą do siebie mówić tym samym językiem – klient FTP nie dogada się z serwerem SSH…

A co się stanie, gdy z zewnątrz przyjdzie próba połączenia, a na żadnym porcie nic nie będzie słuchać? Teoretycznie nic. Connection refused. Odpowie system operacyjny. Gdy dzielnie usiłowałem napisać „niezniszczalne” reguły zapory dla mojego Auroksa, zasugerowano mi, żebym zaniechał prób i skupił się na wyłączeniu wszystkich słuchających usług. Ponieważ był to komputer czysto biurkowy, sprowadziło się to jedynie do zatrzymania serwera OpenSSH. Po owej operacji, żaden port nie znajdował się w trybie „LISTEN”, więc nic nie obsłużyłoby połączeń z zewnątrz. Przestawiłem więc zaporę na domyślne ustawienia. Ale nie wyłączyłem jej. Dlaczego? Przecież po wyłączeniu usług była już „teoretycznie niepotrzebna”. Owszem. A jaka jest różnica między teorią, a praktyką? Teoretycznie żadna…

Klient sieci Microsoft Windows

Dobrze, odstawmy więc na chwilę Linuksa, ale obiecuję, że wrócimy do niego. Odwiedźmy na chwilę Windowsy, na których to uparcie używałem przez wiele lat zapory ZoneAlarm. Używałem jej mimo upływu lat i postępującej zmiany konfiguracji. Windowsy to ciekawe zagadnienie w kwestii usług. Przede wszystkim dlatego, że Windows, na którym pracowałem posiadał pewien mechanizm, który doprowadził do jego popularyzacji w latach 90-tych: był to komponent „Windows for Workgroups”, czyli „Klient sieci Microsoft Network”. Microsoft żył wtedy w swoim świecie, uparcie chcąc sprzedać go wszystkim wokół, przez co klient ów nosił znamiona projektu dostosowanego do zupełnie innych protokołów niż internet. Świetnie spisywał się w sieciach osiedlowych: wspomniana usługa odpowiadała za obecność systemu w Otoczeniu Sieciowym, więc wejście do lokalizacji „Moje Miejsca Sieciowe” pozwalało zobaczyć wesołą gromadkę sąsiedzkich pecetów. Nieco gorzej sprawa się miała, gdy system z klientem Microsoft Network był podpięty bezpośrednio do internetu, tj. posiadał publiczny adres IP. A było to całkiem częste na początku obecnego wieku. Wtedy „Otoczeniem Sieciowym” stawał się cały zakres maski podsieci, a system udostępniał otwarty port 135. Ponieważ mapa sieci była rysowana przez broadcast, dostawca internetu zazwyczaj wyciał taki ruch, więc Miejsca Sieciowe były puste. Niemniej, system słuchał dalej. Na szczęście, udostępnianie plików w WANie nie ma zbyt wiele sensu, więc mogłem wyłączyć wszystkie usługi klienckie, w praktyce zamykając port. Czy ZoneAlarm ucichł? Nie. Od czasu do czasu pokazywał próby skanowania portów oraz próby dziwnych żądań skierowanych na porty 135, 139, 445 i 3127 z komputerów o rev-DNS z końcówką „adsl.tpnet.pl”. Były to więc niedobitki komputerów z Windows XP, zarażonych legendarną triadą Blaster, Sasser i MyDoom.

Tego typu zagrożenia były mi niestraszne, a Windows Update pobierał jedynie aktualizacje dla Internet Explorera 6 oraz wyłączonego Klienta Microsoft Network. Czułem się bezpieczny. Przygody z zaporą na Auroksie i cenna lekcja o zbędności zrzucania pakietów na systemie, gdzie nic nie słucha poskutkowała więc odinstalowaniem ZoneAlarma. Stworzony w czasach „dla grup roboczych” Windows Me nie posiadał własnego filtra pakietów, ale wedle mojej bezkresnej wiedzy, nie był mi już potrzebny. Efekt? Po dwóch tygodniach system został zdemolowany – zdalnie. Dramat. Szok i niedowierzanie. Jakże to możliwe? Otóż Windows Millennium był systemem nowoczesnym. Dlatego zawierał stos protokołu Universal Plug and Play. Rzecz jasna dziurawy. I zapomniany przez wszystkich poza typami spod ciemnych portów. Tymczasem ja nie miałem pojęcia, że na (absurdalnym i oczywiście niestandardowym) porcie 5000 słucha u mnie usługa SSDP. Dzięki temu przyswoiłem drugą lekcję – wyłączaj nie tylko usługi, o których wiesz, ale i te, o których nie wiesz. Przy okazji zraziłem się do Windowsów na tyle, że wróciłem do nich dopiero w roku 2008, po nabyciu ThinkPada z Windows XP.

Czy mój Windows Millennium byłby bezpieczny, gdybym wyłączył naprawdę wszystkie usługi? Prawdopodobnie tak. Nie byłoby usługi, którą dałoby się wykorzystać do włamania. Trzeba by próbować walczyć bezpośrednio ze stosem TCP/IP. A to znacznie trudniejsze, niż podatność w jakiejś usłudze. Czy dałoby się zatem zaszkodzić mojemu systemowi? Cóż, tak. Stos TCP/IP w Windows 9x miał wiele błędów, jednym z nich była podatność na „ping of death”. Zapytanie tak zniekształcone, że system nie potrafi go obsłużyć i w konsekwencji zawiesza się. Niestety, nie pomogłaby na to zapora. Problem zachodzi bowiem „pod spodem”…

Sieciowe systemy operacyjne

Co takiego zmieniło się podczas mojego kilkuletniego wygnania z Windowsów? Dorobiłem się routera. Od tego momentu wszystkie komputery za nim były widoczne w internecie jako jeden. Próba dobicia się do któregokolwiek z nich była w praktyce próbą dobicia się do mojego routera. Zapora niniejszym stała się „jeszcze niepotrzebniejsza”. Aurox zdechł, przesiadłem się na Fedorę i nie zmieniałem w niej już domyślnych ustawień zapory. Zostawiłem nawet działające ssh, bo zdążyłem odkryć jego zalety. Jedyną dodatkową warstwą zabezpieczeń był SELinux, co wydawało mi się bardzo rozsądną konfiguracją domyślną. Cóż, Red Hat. Na laptopie miałem z kolei Windows XP. System, dla którego specjalnie wstrzymano prace nad Longhornem, by wydać Service Pack 2. Pakiet wprowadzający Centrum Zabezpieczeń i nową Zaporę. SP2 był wpychany z uporczywością porównywalną z Windows 10, a błękitne płyty z Service Packiem były rozdawane jak cukierki. No więc chyba jakiś sens ta zapora miała, prawda?

Owszem, sporo w tym prawdy. Wyjaśnijmy, dlaczego. Windows XP, podobnie jak wszystkie systemy NT, to system sieciowy. Oznacza to nie tylko, że „umie w internety”, ale również, ogólnie rzecz biorąc, udostępnia wiele funkcjonalności w formie usług sieciowych, a więc lokalnych mini-serwerów. Nie muszą to być usługi szczególnie użyteczne, w większości są to interfejsy programistyczne. Dzięki temu NT jest z definicji zaopatrzony w rozproszony system komunikacji międzyprocesowej, czyli niesławny RPC. Funkcjonalnie, jest to genialna decyzja. Pozwala zatrzeć granicę między lokalnym komputerem a zasobami sieciowymi, z czego rozlegle korzysta na przykład bezkonkurencyjne Active Directory. Funkcje Windows są nierozerwalnie uzależnione od DCOM RPC i owej usługi nie da się wyłączyć. Można żądać poświadczeń. Można filtrować ruch. Można robić wiele innych cudów, ale efektywnie wyłączyć się jej nie da. Niestety, przez wiele lat Windows żył w alternatywnej rzeczywistości i siłą inercji wmawiał sobie, że pracuje w korporacyjnej sieci operującej na własnościowym protokole, a żadne urządzenie nie będzie wykazywać wrogich zamiarów względem pozostałych. Zestawienie owego podejścia z sieciowym systemem operacyjnym to recepta na katastrofę. I tak w istocie było: w stosie RPC/DCOM/LSASS znaleziono niezliczone dziury i w erze internetu trzeba to było zacząć wreszcie porządnie filtrować, a całość przekompilować z zabezpieczeniem przeciwko przepełnieniu bufora (obie te rzeczy załatwił Service Pack 2).

Ale czy przypadkiem Linux też nie jest systemem sieciowym? Ależ jest, z tym, że rozwiązano kwestie komunikacji sieciowej w zupełnie inny sposób. Najlepiej widać to na gołym poleceniu netstat. Wykonane pod Linuksem wyświetli dwie listy. Pierwszą dla gniazdek internetowych (TCP i UDP), a drugą dla gniazdek domenowych (Unix). Już ten podział wskazuje, że funkcje systemowe porozumiewają się przez gniazda nieprzechodzące przez internet (systemd, D-Bus, X11), a jeżeli potrzebne jest jakieś zdalne wywoływanie procedur, jak RPC, ostanie ono zahostowane przez demona demonów inetd. Gniazdka internetowe będą zawierać zestawione połączenia ze światem oraz słuchające usługi sieciowe. To jednak nie wszystko. System domyślnie tworzy oddzielny, wirtualny interfejs sieciowy sprzężenia zwrotnego (loopback), służący do komunikacji wewnętrznej. Możemy wyciągnąć kabel ethernetowy, ale interfejs loopback będzie istniał dalej. Możemy też nuklearnie wyciąć na zaporze całą komunikację z zewnętrzem, ale sieciowe usługi funkcjonalne dalej będą pracować.

Jak radzi sobie z tym Windows? No cóż… Tutaj jest gorzej. Wypisanie pełnego netstat da nam tylko połączenia TCP i UDP. Wśród nich będzie serwer RPC, słuchające 135 i 445 oraz parę innych straszydeł. A więc wszystkie usługi komunikują się przez stos sieciowy. Najbliższe do interfejsu sprzężenia zwrotnego są tzw. „named pipes”, ale to nie to samo. Zwłaszcza, że w Linuksie też są named pipes. To nie są droidy, których szukamy. Loopback w Windows mapuje się mniej więcej na to samo, co „localhost”. A to niedobrze. Co ciekawe, da się doinstalować interfejs loopback jako wirtualne urządzenie… ale nikt o tym nie wie. Więc jesteśmy zmuszeni do do posiadania usług sieciowych wystawionych do internetu. A więc niejako „zmuszeni” do stosowania zapory. Nie powinno tak być. Takie coś nie powinno być architekturalnie możliwe. Dlaczego Windows działa w taki sposób? Nie mam pojęcia :D Może zabrakło czasu? Może wyobraźni? A może Windows nigdy nie miał pracować na protokole TCP/IP, wykorzystując zamiast tego własny, płatny i niejawny protokół, podobnie, jak dawny Netware? Jest to w każdym razie zaszłość historyczna, za którą przyszło nam sporo zapłacić (dosłownie).

Czy Windows ma wbudowaną zaporę? Tak. Czy jest ona dobra? Tak, jest doskonała. Domyślnie w domenie blokuje wręcz niezbędny administracyjnie ruch, a jak udało mi się pokazać w zeszłym roku, da się nią całkowicie zablokować również telemetrię. Co więcej, bez problemu można w niej kontrolować również ruch wychodzący, stosować ostrzeżenia, wprowadzać gradację uprawnień… Pełny serwis. Zastępowanie systemowego „Windows Firewall with Advanced Security” innym produktem jest zbędne, ponieważ wprowadzamy do systemu mechanizm w praktyce mniej przetestowany (a więc mniej bezpieczny), niż systemowa zapora. Niektórzy producenci pakietów bezpieczeństwa to zauważyli. Na przykład F-Secure reklamuje swój produkt jako zawierający zaporę, ale w praktyce jest to nakładka na UI dla Windows Firewall. I bardzo dobrze. W następnej wersji sugeruję zamiast antywirusa nakładkę na Windows Defendera, a zamiast ochrony rodzicielskiej – nakładkę na Windows Family Safety :D Za roczną subskrypcję 399 PLN ;)

Jeżeli problem będzie ze stosem TCP/IP, to zewnętrzna zapora i tak nie pomoże. Chyba, że będzie podmieniać tak dużo obsługi sieci, że samo to stanie się oddzielnym problemem.

No więc zapora w Windowsach musi niestety zostać… Ale ponownie: jesteśmy za routerem (zazwyczaj). Zakładając, że pozostałe urządzenia w domu nie chcą nas pożreć, bo wskutek dobrych praktyk (a nie antywirusa!) nie zawierają szkodliwego oprogramowania, zapora może nie jest przesadą rozmiarów antywirusa, ale zdecydowanie w większości scenariuszy równie dobrze mogłoby jej nie być. Na pewno jednak przegięciem jest zapora zewnętrzna, dodatkowa. Można się zastanawiać nad filtrowaniem ruchu wychodzącego, ale z drugiej strony można po prostu nie pozwalać programom aspirującym do takich działań na uruchomienie się.

Polecam eksperyment (za NATem): Linux z pustym iptables i bez firewalld. Windows z wyłączoną zaporą. Będzie to dalece bezpieczniejsza konfiguracja, niż Windows z antywirusem, ale bez aktualizacji. Mocno odradzam jednak takie zabawy z Windowsem użytkownikom „internetu mobilnego”, czyli połączeń pakietowych, wdzwanianych przez sieć HSPA i LTE. Dostaje się wtedy semi-publiczny adres IP, niby ruch przychodzący oraz komunikacja między węzłami jest wycięta… ale to przecież nie zawsze musi być prawda. Może lepiej nie kusić losu i nie sprawdzać.

Zestawienie

Podsumujmy zatem:


  • na poprawnie zaprojektowanym systemie, nawet sieciowym, zapora nie jest potrzebna. Należy skupić się na zabezpieczeniu usług i drugiej linii obrony, czyli redukcji przywilejów, gdy ktoś jednak usługę sforsuje
  • tosowanie zapory zrzucającej w milczeniu ruch przychodzący na sens o tyle, że zniechęca boty do dalszych prób. Za zaporą i tak nie powinna się znajdować żadna zbędna usługa
  • w Windows popełniono jakiś koszmarny błąd projektowy i usługi sieciowe są z definicji niemożliwe do pełnego zabezpieczenia. Na szczęście, systemowa zapora jest zaskakująco dobra
  • wprowadzenie zewnętrznej zapory to w praktyce dodanie kolejnego elementu, który trzeba obdarzyć zaufaniem, a im mniej takowych, tym lepiej. Fakt istnienia Windows Server można uznać za niezłą poszlakę, że systemowa zapora jednak działa.
  • większość ataków sieciowych z zewnątrz i tak rozbija się o NAT tworzony przez router. Zapora chroni wtedy przez atakami z wewnątrz sieci, która, gdy dobrze pilnowana, nie powinna stanowić zagrożenia
  • filtrowanie ruchu wychodzącego to zupełnie inna bajka ??

Sam kiedyś otaczałem się murami z antywirusów i zapór (stosowałem też antydialery!), ale nauczyłem się, że nie należy stosować tych narzędzi bezkrytycznie. Nauczyłem się też jednak, bolesnym doświadczeniem, że nie należy też beztrosko wyłączać wszystkich zabezpieczeń, ale to osobna kwestia. Nie zmienia to jednak mojej opinii na temat pakietów bezpieczeństwa. Jest to ten sam sprzeciw wobec faktów i „mentalność podkładki chłodzącej”, o których wspominałem przy okazji antywirusów. Fortyfikowanie się zasiekami z pakietów „Internet Security” nieodmiennie kojarzy mi się z widokiem małego dziecka w płetwach, czepku, kole ratunkowym i rękawkach (ileż razy widziałem coś takiego! Drodzy rodzice, nie idźcie tą drogą!). Raczej nie utonie, ale żeby sobie popływać, będzie musiało się strasznie namęczyć. A jak zacznie się wiercić i buntować, i tak z łatwością zachłyśnie się wodą.

UPDATE:

Luka, przez którą się do mnie włamano, to: Unchecked Buffer in Universal Plug and Play can Lead to System Comprom.... Wydano na nią aktualizację, której mój Windows Update nie pobrał, ponieważ zainstalowałem usługę SSDP po pobraniu aktualizacji :D
 

internet bezpieczeństwo

Komentarze