Krzysztof Oledzki pisze:
> Neas <neas@neas.invalid> wrote:
> <CIACH>
>> Po za tym zwróć uwagę na to, że ów specjalista nie zaproponował żadnego
>> innego rozwiązania. Cały czas powtarzał, że może zablokować dst-port bo
>> nie będzie blokował iluśtam src-ip i to koniec jego inwencji.
> I teraz pomyśl chwileczkę, ile zajmuje zakładanie blokadny na kilkuset src
> i ile razy dzinnie coś takiego możnaby robić. Blokowanie danego hosta
> albo konkretnego portu jest jedynym rozwiązaniem, serio.
To nie jest żadnym rozwiązaniem, nie oszukujmy się. :) To tak jakby
przeciwdziałać włamaniom do sklepu z 50 oknami zamurowując te, przez które
ktoś się włamał. Fakt, przez to samo się nie włamie, ale któż rozsądny
będzie liczył na to, że złodziej będzie wystarczająco głupi żeby nie
skorzystać z innego?
Albo z innej strony -- po co istnieje ten ich dział bezpieczeństwa? Nie do
zgłaszania nadużyć jako takich, bo odsyłają z tym do abuse@. Nie do
zgłaszania DDoS-ów, bo nic z tym nie robią. Do zgłaszania ping -f? Też nie,
bo to w ogóle nie powinno być możliwe (kiedyś jeden technik 'zeznał', że na
icmp mają ustawione limity rzędu bodajże 300 kbps). Więc po co? Do
blokowania portów klientom i gadania głupot przez telefon? ;)
> <CIACH>
>> Nie przekonywałem do blokowania akurat po src, tylko do zrobienia
>> czegokolwiek. Nie chciałem sugerować konkretnych rozwiązań, bo nie wiem
>> jakie tam mają możliwości. Wiem natomiast, że wcześniej sobie radzili w
>> identycznych sytuacjach więc są w stanie to zrobić. :)
> Poradzić sobie można, jak atak idzie z kilu IP.
Oni sobie radzili przy dokładnie takich samych atakach, z przynajmniej setek
IP.
>> Tak jak napisałem w innym poście osobiście uwazam, ze świetnym
>> zabezpieczeniem przed tcp-syn floodem jest rate-limit na tcp-syn po
>> src-ip odnoszący się do minut (nie np. sekund), najlepiej osobne regułki
>> dla newralgicznych portów ale niekoniecznie.
> Jak sobie coś takiego wyobrażasz? Pytam poważnie.
Przecież opisałem to w kilku postach w tym wątku. :)
-- Neas, ?eas@?eas.pl, http://www.neas.plReceived on Fri May 20 01:15:18 2005
To archiwum zostało wygenerowane przez hypermail 2.1.8 : Fri 20 May 2005 - 01:40:03 MET DST