W dniu 03.11.2010 14:39, Sławek Lipowski pisze:
> 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ć.
>

Udało mi się powiązać część ruchu z FIN+ACK z src IP z klas prywatnych z
połączeniami TCP, które nie zostały zamknięte przez zdalny host.
Jednakże to gównie poszlaki. Pasuje TTL i id pakietów IP układają się
wiarygodnie. Część takiego ruchu nie udało mi się z niczym powiązać.
Może niepotrzebnie łączę te fakty, aczkolwiek to, że te pakiety mają
praktycznie zawsze ustawioną flagę FIN sprawia, że bardzo mocno wydaje
mi się, że nie jest to jakoś bardzo ogólny problem, tylko dość
szczególny przypadek.

Być może faktycznie głównie są to retransmisje, które nie łapią się już
w NAT. Jeśli by tak było, to nie ma dramatu (oczywiście to też nie
powinno mieć miejsca), przy czym dalej uważam, że to strona generująca
takie pakiety powinna zadbać o ich odfiltrowanie. Inaczej to trochę tak,
jak by zamiast ścigać złodziei samochodów nakazać wszystkim instalację
super zabezpieczeń antykradzieżowych w autach. Zabezpieczenia i tak
można i pewnie powinno się montować, ale to nie znaczy bynajmniej, że
nie trzeba chociażby próbować łapać złodziei. :)

--
Sławek Lipowski