S

erwis NewsBlur 3 godziny po zakończeniu migracji swojej infrastruktury MongoDB na kontenery Docker doświadczył usunięcia danych. Otóż sam serwer miał włączoną zaporę sieciową UFW (ang. Uncomplicated Firewall) z ścisłą listą dozwolonych adresów IP. Co takiego się stało? Otóż okazało się, że decydując się na publikację portu MongoDB na kontenerze – Docker w standardzie robi swoją sztuczkę (znaną od 2014 roku) pod postacią dziury w zaporze otwierając dany port (tutaj: 27017) na świat. Proces ten jest opisany w dokumentacji:

This creates a firewall rule which maps a container port to a port on the Docker host to the outside world.

Wielu użytkowników jest zdziwiona takim zachowaniem – spodziewając się raczej odwrotnej polityki: świadomego włączenia funkcji otwierania portów niż konieczności ich wyłączenia (--iptables=false), czy potrzebę definiowania reguł iptables na poziomie łańcucha mangle, a nie filter. Oczywiście cała ta sytuacja nie tłumaczy uruchomienia niezabezpieczonej bazy NoSQL w kontenerze.

Więcej informacji: How a Docker footgun led to a vandal deleting NewsBlur’s MongoDB database, Docker Network bypasses Firewall, no option to disable

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ść… ]

J

eśli posiadamy podatność, która bazuje na adresie IP, ale zapora pośrednicząco-filtrująca utrudnia nam zadanie eksploatacji pamiętajmy, że adres IP od strony klienta można zapisać na wiele sposobów. Na przykład:

$ ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1): 56 data bytes

$ ping 3232235521
PING 3232235521 (192.168.0.1): 56 data bytes

$ ping 0xC0A80001
PING 0xC0A80001 (192.168.0.1): 56 data bytes

$ ping 192.168.1
PING 192.168.1 (192.168.0.1): 56 data bytes

$ ping 192.168.257
PING 192.168.257 (192.168.1.1): 56 data bytes

$ ping ::ffff:c0a8:0001
PING ::ffff:c0a8:0001(::ffff:192.168.0.1) 56 data bytes

$ ping 0000:0000:0000:0000:0000:ffff:c0a8:0001
PING 0000:0000:0000:0000:0000:ffff:c0a8:0001(::ffff:192.168.0.1) 56 data bytes

Więcej informacji: IPv4 Converter, inet_aton(3), IPv6 address formats,

J

eśli interesują nas wcześniejsze dwie części to znajdziemy je tu (1) i tu (2). Przejdźmy teraz do kolejnej części. W ciągu ostatnich lat bezpieczeństwo webaplikacji stało się bardzo ważnym tematem w dziedzinie IT. Zalety, jakie oferuje sieć sprawiły, że bardzo ważne usługi zostają opracowane jako aplikacje internetowe. Wymagania biznesowe związane z bezpieczeństwem wspomnianych aplikacji również uległy przemianie. Oprócz dobrych praktyk programistycznych wymagane są też dobre praktyki bezpieczeństwa. Stosowane są dodatkowe zabezpieczenia takie, jak WAF (ang. Web Application Firewall). Zapory sieciowe aplikacji to transparentne zapory ogniowe warstwy siódmej, które kontrolują ruch sieciowy i “próbują” chronić aplikację przed atakami.
[ 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ść… ]

A

ktualnie ceny mikrokomputerów pozwalają na masowe ich podłączanie do sieci domowych. Często pełnią rolę multimedialnych stacji lub serwerów o konkretnym zastosowaniu znajdując się za mechanizmami NAT lub ścian ogniowych lokalnych routerów. W jaki sposób możemy dostać się zdalnie do takiego urządzenia bez robienia dziur w swoich sieciowych zabezpieczeniach? Rozwiązaniem jest użycie odwrotnego tunelu SSH.
[ czytaj całość… ]

N

o właśnie, co z tymi pakietami SYN? Tutaj ponownie pojawia się problem skalowalności systemu conntrack (tak jak dla stanu listen) dla tworzenia (lub usuwania) połączeń, które spowoduje zalew pakietów SYN. Nawet jeśli uporamy się z blokadą w warstwie conntrack to kolejnym krokiem wędrówki pakietu SYN będzie stworzenie gniazda w trybie “nasłuchu”, czyli kolejną barierą wydajnościową. Normalnym procesem łagodzenia tego typu pakietów w systemie Linux będzie mechanizm SYN-cookies, który również ma ograniczenia.
[ czytaj całość… ]

P

odstawowy problem skalowalności protokołu TCP w jądrze Linuksa jest związany z liczbą nowych połączeń, jakie mogą być tworzone na sekundę. Odnosi się to bezpośrednio do obsługi gniazd powstających w trybie nasłuchu, które są blokowane. Blokady powodowane są nie tylko przez pakiety z flagą SYN, ale także SYN-ACK oraz ACK (ostatni w potrójnym uścisku dłoni). Podczas ataków DoS / DDoS za pomocą tego rodzaju pakietów atakujący ma na celu wysłanie, jak największej ilości spreparowanych pakietów, które mają na celu osiągnąć i spowodować problem z blokowaniem gniazd w trybie nasłuchu. Jedną z metod jest podniesienie bardzo niskiego limitu dla tego typu gniazd oraz kolejki oczekujących połączeń w systemie:
[ czytaj całość… ]

O

statnio Larry Seltzer wykonał prosty test w korzystaniu z otwartych sieci WiFi (tych, które nie oferują żadnego szyfrowania i najczęściej udostępniane są za darmo w restauracjach typu KFC, McDonalds, hotelach itd.). Polegał on na zbadaniu, czy rzeczywiście korzystanie z takich sieci nawet za pomocą wirtualnych sieci prywatnych zapewnia dobry stopień bezpieczeństwa.
[ 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ść… ]