>
> Ale konsekwencją jest niezamykanie połączeń TCP w prawidłowy sposób. Nie
> dociera FIN+ACK od klienta z prawidłowego IP. Cięcie pakietów nie
> wyeliminuje tej konsekwencji.

Ale wytnie ruch z priv IP w całości. O tyle możesz mieć mniej. Reszta i tak
będzie musiała expirować, jak to się dzieje dotychczas. Zyskujesz więc
trochę, ale nie rozwiążesz problemu, bo to wymaga pracy u źródła. BTW - jak
w sieciach będą cięte privIP skutecznie, to i tak będą wisiały u Ciebie
sesje z braku FIN+ACK, które opisujesz. Dla algorytmu rozważań nie ma
znaczenia, czy cięcie privIP nastapi u Ciebie, czy np.w PLIXie.

Masz lepszy pomysł - posłucham z ciekawością.


--
---
Zboj (Piotr Marciniak)
zboj \at/ mnc.pl

do góry

On 03-11-10 13:01, Sławek Lipowski wrote:
> Ale konsekwencją jest niezamykanie połączeń TCP w prawidłowy sposób. Nie
> dociera FIN+ACK od klienta z prawidłowego IP. Cięcie pakietów nie
> wyeliminuje tej konsekwencji.

Jesteś pewien, że nie dociera? IMHO te nienatowane, co widzisz, to
retransmisje.

--
Grzegorz Janoszka

do góry

On 03.11.2010 13:06, Grzegorz Janoszka wrote:
> On 03-11-10 12:46, Sławek Lipowski wrote:
>> Nie mam żadnego problemu. Chciałbym wyeliminować przyczynę ich
>> generowania i uniknąć konsekwencji.
>
> To idź i napraw wszystkie sieci na świecie. Popraw też embedded code w
> milionach ruterków soho. Może będzie prościej, jak zupgradujesz
> wszystkich do IPv6, nie uważasz? Przy okazji zadbaj też o to, żeby nie
> było głodu, wojen, a drób żeby siedział w kurniku/kaczniku i nie wtrącał
> się do polityki. Postrasz rosołem.
>
> BtW - jakie są konsekwencje tego, że dostajesz pakiety fin/ack z
> prywatnych adresów?
>

Jeśli dostaje z prywatnych to tym bardziej z tej sieci mogą wyjść
spoofowane adresy, co już groźniejsze, szczególnie przy UDP.

--
wer <",,)~~
http://szumofob.eu

do góry

Dnia 03.11.2010 Grzegorz Janoszka <G...@n...Janoszka.pl> napisał/a:
> adresów, ale kto w PL to robi? Ostatni raz z firmami typu Netia,
> Crowley, GTS/Energis, TKTelekom itp miałem do czynienia jakieś 3 lata
> temu i nikt wtedy nie filtrował. Wątpię, czy od tamtego czasu zmieniło
> się wiele. Ktoś może przetestować?
netia jakies "3 lata temu" filtrowala.

Przynajmniej mnie, w Poznaniu ;)

--
Andrzej 'The Undefined' Dopierała
HomePage: http://andrzej.dopierala.name/
Reprezentuję siebie i wyrażam tylko moje zdanie!

do góry

W dniu 03.11.2010 13:10, Zboj pisze:
>>
>> Ale konsekwencją jest niezamykanie połączeń TCP w prawidłowy sposób. Nie
>> dociera FIN+ACK od klienta z prawidłowego IP. Cięcie pakietów nie
>> wyeliminuje tej konsekwencji.
>
> Ale wytnie ruch z priv IP w całości.

Z priv IP dostaję tylko FIN+ACK.

> O tyle możesz mieć mniej. Reszta i tak
> będzie musiała expirować, jak to się dzieje dotychczas. Zyskujesz więc
> trochę, ale nie rozwiążesz problemu, bo to wymaga pracy u źródła. BTW - jak
> w sieciach będą cięte privIP skutecznie, to i tak będą wisiały u Ciebie
> sesje z braku FIN+ACK, które opisujesz. Dla algorytmu rozważań nie ma
> znaczenia, czy cięcie privIP nastapi u Ciebie, czy np.w PLIXie.

O tym już pisaliśmy, nie chodzi o to, żeby TYLKO wyciąć ten ruch
(nigdzie nie stwierdziłem, że uważam, że go nie należy ciąć), ale też
wyeliminować jego źródło i ewentualne konsekwencje tych nieprawidłowości.

> Masz lepszy pomysł - posłucham z ciekawością.

Poza odfiltrowaniem ruchu, ustalenie, kto go generuje i kontakt z danymi
sieciami.

--
Sławek Lipowski

do góry

W dniu 03.11.2010 13:18, Grzegorz Janoszka pisze:
> On 03-11-10 13:01, Sławek Lipowski wrote:
>> Ale konsekwencją jest niezamykanie połączeń TCP w prawidłowy sposób. Nie
>> dociera FIN+ACK od klienta z prawidłowego IP. Cięcie pakietów nie
>> wyeliminuje tej konsekwencji.
>
> Jesteś pewien, że nie dociera? IMHO te nienatowane, co widzisz, to
> retransmisje.
>

Postaram się potwierdzić w wolnej chwili i dam znać.

--
Sławek Lipowski

do góry

3 Lis, 12:58, Sławek Lipowski <s...@l...org> napisał:

> No tak, ale odfiltrowanie ruchu z nieprawidłowym adresem źródłowym,
> który przychodzi od klienta końcowego nie jest chyba głupim pomysłem
> chociażby w kontekście uniemożliwienia takiemu klientowi wykonania DoSa
> poprzez wygenerowanie ruchu z losowym IP.

Jaka jest różnica w skuteczności ataku z wykorzystaniem losowego
adresu z puli prywatnych, a losowego adresu z puli publicznych?

> Tak że czy na pewno ISP nie
> powinien sprawdzać adresu źródłowego pakietów pochodzących od klienta
> końcowego?

Jako dobra praktyka byłoby to wskazane, ale nie możesz tego wymagać od
swojego operatora. W końcu jego zadaniem jest kierowanie ruchu jaki do
Ciebie próbują inni przesłać.

Herlok Sz.

do góry

W dniu 03.11.2010 20:45, Airen pisze:
> 3 Lis, 12:58, Sławek Lipowski<s...@l...org> napisał:
>
>> No tak, ale odfiltrowanie ruchu z nieprawidłowym adresem źródłowym,
>> który przychodzi od klienta końcowego nie jest chyba głupim pomysłem
>> chociażby w kontekście uniemożliwienia takiemu klientowi wykonania DoSa
>> poprzez wygenerowanie ruchu z losowym IP.
>
> Jaka jest różnica w skuteczności ataku z wykorzystaniem losowego
> adresu z puli prywatnych, a losowego adresu z puli publicznych?

Miałem na myśli łącze dostarczane przeciętnemu Kowalskiemu, więc
nieprawidłowy adres źródłowy w tym wypadku = każdy inny niż np. jeden mu
przyznany.

>> Tak że czy na pewno ISP nie
>> powinien sprawdzać adresu źródłowego pakietów pochodzących od klienta
>> końcowego?
>
> Jako dobra praktyka byłoby to wskazane, ale nie możesz tego wymagać od
> swojego operatora. W końcu jego zadaniem jest kierowanie ruchu jaki do
> Ciebie próbują inni przesłać.
>
> Herlok Sz.

IMHO ISP dostarczając łącze klientowi końcowemu nie powinni przechodzić
do porządku dziennego nad możliwością puszczenia przez ich klientów
końcowych pakietów z dowolnym adresem źródłowym.

--
Sławek Lipowski

do góry

> Ale konsekwencją jest niezamykanie połączeń TCP w prawidłowy sposób. Nie
> dociera FIN+ACK od klienta z prawidłowego IP. Cięcie pakietów nie
> wyeliminuje tej konsekwencji.

nie, konsekwencja dla mnie jest to ze musze sprawdzic pol miliona pakietow
na sekunde zeby odfiltrowac te z niechcianych adresow. Bez sensu. Jak do
tego dodam cala mase rzeczy ktore chcialbym filtrowac na routerze brzegowym
to juz wychodzi pewne obciazenie. Tak jak pisalem bez sensu. Jak ktos ma
problem ze zlym zamykaniem sesji TCP to pisz do tego kto ma ten problem i
niech sobie radzi wlasnie ten ktos




Icek

do góry

> > To idź i napraw wszystkie sieci na świecie. Popraw też embedded code w
> > milionach ruterków soho. Może będzie prościej, jak zupgradujesz
> > wszystkich do IPv6, nie uważasz? Przy okazji zadbaj też o to, żeby nie
> > było głodu, wojen, a drób żeby siedział w kurniku/kaczniku i nie wtrącał
> > się do polityki. Postrasz rosołem.
> >
> > BtW - jakie są konsekwencje tego, że dostajesz pakiety fin/ack z
> > prywatnych adresów?
> >
>
> Jeśli dostaje z prywatnych to tym bardziej z tej sieci mogą wyjść
> spoofowane adresy, co już groźniejsze, szczególnie przy UDP.

a spoofowane z innych adresow nie moga wyjsc ?????




Icek

do góry