Re: atak na serwer www - apache 1.3.x
>> Z tego co Bieniu pisał wyżej największym problemem był limit połaczeń
>> w
>> ramach jednego apacza. Poza tym apacz zuzywa mniej zasobow
>> niz squid...
>
> ale mysle o squidzie ktory by tylko blokowal te 3 wywolania hmmm
>
Witam
A ja jednak pomyślałbym jednak nad iptables - wydaje mi sie jednak, że
filtr utworzony w ten sposób zeżre najmniej zasobów:
iptables -t filter -A INPUT -p tcp --dport 80 - m string --string "GET
/jakiś_syf" -j REJECT
I do tego zastanowiłbym się poważnie nad umieszceniem tej regułki na samym
początku łańcucha INPUT. Ew. można skrócić wyrażenie do "sam_syf" - być
może zaoszczędzi to kilka cykli procesora.
Za takim rozwiązaniem przemawia fakt, że netfilter działa w przestrzeni
jądra i nie jest obciążony narzutami związanymi z obsługą dodatkowych
procesów, opłączeń itp.., a w dodatku i tak przechodzi przez niego cały
ruch sieciowy wpadający do kompa, więc jeśli spędziłes kiedyś parę nocek
wymyślając różne dziwne regułki firewalla, to i tak netfilter ma kupę
roboty przez tego natchnionego kolesia.
A jeśli ktoś powie, że dzięki temu nie wie, czy atak już się skończył, czy
też trwa dalej, to przypomnę o iptables -Lv ;)
I jeszce pozwolę sobie wtrącic 0,03PLN do wątku DROP vice REJECT - REJECT
odsyła komunikat ICMP port unreachable, który zmusza prawidłowo działający
drugi koniec (czyli windzianą ofiarę) do zamknięcia połączenia, podczas gdy
DROP tylko odrzuca pakiet nic nikomu nie mówiąc, powodując bardzo szybkie
przepełnienie tabeli połączeń, w konsekwencji doprowadzając do odrzucania
wszelkich nowych połączeń (czyli kończąc atak sukcesem;)
--
Pozdrawiam
Janes
--
Pozdrawiam
Artur Jankowski
ITservice
Reply to: