W

zależności od przeczytanego raportu możemy dowiedzieć się, że szkodliwe oprogramowanie (ang. malware) w 80 – 90% przypadków używa systemu DNS (ang. Domain Name System) do prowadzenia swoich kampanii. Z kolei 68% (stan na 2016 rok) organizacji nie monitoruje swoich rekursywnych systemów DNS. Jakiś czas temu pokazałem jak łatwo zaimplementować mechanizm RPZ (ang. Response Policy Zones) w serwerze ISC BIND, aby automatycznie blokować domeny pochodzące z projektu CERT Polska. Co w przypadku, gdybyśmy chcieli mieć więcej takich źródeł?
[ czytaj całość… ]

O

d wersji 9.8.1 serwera BIND dostępny jest mechanizm DNS RPZ (ang. Domain Name Service Response Policy Zones). Główną motywacją do stworzenia tej funkcji była ochrona użytkowników przed zagrożeniami w internecie związanymi z złośliwymi domenami, nazwami hostów lub innymi serwerami nazw. Cyberprzestępcy zwykle używają tych samych domen na wielu ofiarach, dopóki nie zostaną im odebrane. Niestety zdolność branży bezpieczeństwa internetowego w kwestii likwidacji infrastruktury przestępczej u rejestratorów domen, dostawcach hostingu lub dostawcach usług internetowych z różnych czynników nie zawsze jest możliwa. Korzystając z RPZ administrator sieci może wdrożyć własne zasady ochrony przed niebezpiecznymi domenami w oparciu o reputację zebraną od dostawców usług bezpieczeństwa niemal w czasie rzeczywistym.
[ czytaj całość… ]

O

pisana tutaj metoda nie jest najbardziej zaawansowaną techniką obronną małych instalacji serwerów WWW na świecie, ale bazuje ona na bardzo prostym mechanizmie, który przy spełnieniu jednego warunku potrafi zablokować trochę szajsu krążącego po internecie. Zacznijmy od charakterystyki ruchu w internecie. Bardzo często porównywany on jest do infostrady, po której ciągle pędzą jakieś dane. Wyobrazimy teraz sobie, że internet to jedna wielka autostrada ułożona w linii prostej, a każdy z niej zjazd prowadzi do jakiegoś serwera. Na długości całej autostrady, jak i przy każdym zjeździe poprowadzone są osłony energochłonne. Poprawny ruch do serwera powinien zawsze odbywać się tylko i wyłącznie po wyznaczonej drodze – bez dotykania barier.
[ czytaj całość… ]

F

acebook będzie teraz wyświetlał reklamy nawet użytkownikom, którzy nie są zarejestrowani w jego sieci społecznościowej. Może by tak zablokować ich całą sieć? Jak to zrobić najprościej? Wystarczy znaleźć system autonomiczny danej firmy i wyciągnąć z niego całe bloki sieci, które można dodać do reguł blokujących na ścianie ogniowej.
[ czytaj całość… ]

Współczesne, szkodliwe oprogramowanie komunikuje się z swoimi serwerami C&C (command and control) za pomocą sieci Tor. Jeśli chcemy ochronić naszą firmową / domową sieć przed różnego rodzaju malware / ransomware lub atakami pochodzącymi z wyjściowych węzłów Tor to możemy do tego wykorzystać takie serwisy, jak Ransomware Tracker, Feodo Tracker oraz Tor Network Status, które dostarczają gotowe listy z adresami IP, które mogą zostać wykorzystane do budowy blokady:
[ czytaj całość… ]

Z

ałóżmy, że do naszego serwera DNS, który jest otwarty tylko dla sieci wewnętrznej zaczyna przychodzić niechciany ruch (od setek do tysięcy zapytań na sekundę) pochodzący od szkodliwego oprogramowania / złej konfiguracji serwerów. W zależności od oprogramowania jakiego używamy do obsługi zapytań DNS – zablokowanie konkretnego rodzaju zapytań może stać się dość trudne. Pierwszym rozwiązaniem tego problemu wydaje się zablokowanie wszystkich żądań DNS, które posiadają konkretne wyrażenie w zawartości pakietu.
[ czytaj całość… ]

P

rzez długi czas firewall w Linuksie oparty o iptables nie miał żadnego efektywnego sposobu, aby dopasowywać reguły do zbiorów adresów IP. Jeśli mieliśmy wiele adresów IP, aby dopasować do nich różne reguły (na przykład: setki lub tysiące adresów IP, które należało trzymać z daleka od portu SMTP) trzeba było tworzyć jeden wpis iptables dla każdego adresu IP, a następnie wprowadzać te wpisy sekwencyjnie. To wprowadzało wiele komplikacji w utrzymywanie takiego rozwiązania. Na szczęście w jądrach od serii 2.6.39 (Ubuntu 12.04, 14.04, Fedora 20, RHEL / CentOS 7) pojawiło się rozszerzenie ipset.
[ czytaj całość… ]

W

ielu użytkowników posiadających własny serwer WWW np. Apache – od dłuższego czasu może zaobserwować w własnych logach access_log oraz error_log występowanie następujących wpisów:

89.19.27.114 - - [20/Sep/2009:05:33:39 +0000] "GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 226 "-" "-"
[Sun Sep 20 05:33:39 2009] [error] [client 89.19.27.114] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)

Są to ślady jakie zostawia skaner DFind testujący web serwery pod kątem luk w zabezpieczeniach. Posiada on możliwość skanowania wybranego adresu IP lub całych ich zakresów. Ze względu na fakt, iż proces skanowania odbywa się z różnych adresów IP blokując ręcznie jeden adres IP – ślady w logach zaczynają pojawiać się z innego.
[ czytaj całość… ]

M

od_spamhaus jest modułem dla serwera WWW Apache 2, który korzysta z list SBL ang. Spamhaus Block List) oraz XBL (ang. Exploits Block List) serwisu Spamhaus w celu blokady dostępu do wybranej strony WWW wszystkich komputerów, które odpowiedzialne są za rozsyłanie wiadomości SPAM w Internecie lub zainfekowane są szkodliwym oprogramowaniem (robakami, końmi trojańskimi, wirusami, wbudowanymi mechanizmami do rozsyłania spamu).
[ czytaj całość… ]