ktos zrywa mi polaczenia ssh

[elceef]

Skąd podejrzenie, że za Twoim problem stoi właśnie ten administrator? Dlaczego obiektem jego ataków są tylko sesje SSH, a nie inne długotrwałe połączenia?
Użyj tcpdump/wireshark lub innego dobrego sniffera pakietów. Następnie odfiltruj wszystkie pakiety TCP z flagą RST oraz wszystkie pakiety ICMP odbierane od serwera SSH. Jeśli rzeczywiście ten administrator utrudnia Ci życie może stosować atak TCP Reset (o którym pisał TQM) lub atak z użyciem "twardych" komunikatów ICMP (Protocol unreachable/Port unreachable). Efektem obu jest zerwane połączenie. Sniffer na pewno zapisze także adres źródłowy ramki w takich pakietach. W oparciu o ten adres będziesz mógł ustalić, który komputer w sieci lokalnej generuje fałszywe pakiety oraz zdobędziesz potrzebne dowody.

[rip]

icmp napewno wplywa na (udana) sesje tcp?
Cos mi sie wydaje ze byloby zaprosto, w koncu tcp wymaga id ramki takiego jaki wysle w ostatnim pakiecie w polu next frame.

[TQM]

rip - ICMP jest jedna z molzliwosci ale wymaga (tak jak slusznie zauwazyles) podsluchania i wstawienia w taki pakiet ICMP calego naglowka ktoregos z pakietow sesji SSH. Ja bym stawial ze to bedzie RST flood na slepo...

[elceef]

icmp napewno wplywa na (udana) sesje tcp?

Oczywiście. Skonfiguruj firewall w taki sposób aby odrzucał cały protokół ICMP. Wtedy zobaczysz jak bardzo.

Cos mi sie wydaje ze byloby zaprosto, w koncu tcp wymaga id ramki takiego jaki wysle w ostatnim pakiecie w polu next frame.

Ramka ethernet nie zawiera żadnego identyfikatora, natomiast protokół TCP nie może wymagać istnienia czegokolwiek w nagłówku warstwy łącza danych. Powyższe zdanie nie ma sensu.

ICMP jest jedna z molzliwosci ale wymaga (tak jak slusznie zauwazyles) podsluchania i wstawienia w taki pakiet ICMP calego naglowka ktoregos z pakietow sesji SSH.

Nie jest wymagany cały nagłówek, tylko przynajmniej 64 bitów (8 oktetów) nagłówka warstwy czwartej (w tym przypadku TCP). Osiem oktetów nagłówka TCP przenosi informacje o porcie źródłowym i docelowym, a także numer sekwencyjny pakietu.

Ja na ślepo strzelam, że to nie jest żaden atak tylko timeout sesji SSH. Ale dowiemy się tego dopiero gdy zobaczymy (jeśli w ogóle zobaczymy) zapis przebiegu sesji SSH.

[TQM]

Rozne firewall'e maja limit czasu przy bezczynnosciach sesji - wtedy efekt jest wlasnie taki jak mowisz... leci sobie polaczenie leci i nagle cos je 'uwala' - mam to u sibie w paru sieciach - kwestia konfiguracji firewall'a.

[ds1978]

dzieki za odpowiedzi.

widze ze rozgorzala dyskusja w jaki sposob ten gosc ten "atak" przeprowadza.

mnie bardziej interesowaloby jak temu zapobiec.

TQM, skoro scenariusz o ktorym mowilem w poprzednim poscie jest jak najbardziej mozliwy, to czy mozliwe jest ukrycie mojego polaczenia? VPN?
jakie to programy gosc moze wykorzystywac? znajac chorobe moze znajde i lekarstwo..

[TQM]

Rozwiazanie jest z pozoru proste - odpal sesje SSH na inny serwer najpierw, pozniej idz dalej do tego na ktory chcesz sie dostac. Jesli koles nie widzi (tzn nie moze sniffowac Twoich polaczen) to nawet wiedzac ze pracujesz nie bedzie w stanie za bardzo sesji zerwac.

Aby urwac taka sesje musialby wiedziec z ktorego do ktorego kompa sie laczysz - albo od ciebie do pierwszego serwera albo miec podglad maszyny docelowej aby stwierdzic skad przychodzi polaczenie - wtedy bedzie w stanie je zerwac.

Mozesz sprobowac VPN cos opartego o UDP na przyklad ale wtedy nadal ma do dyspozycji ICMP. Na to za wiele nie poradzisz, no chyba ze zrecznie wytniesz na wszystkich hostach po drodze ICMP - mozliwe ale ja bym odradzal!

[elceef]

mnie bardziej interesowaloby jak temu zapobiec.

Najpierw ustal przyczynę. Teoretyzować można tygodniami. Nie przedstawiłeś nam żadnych informacji, poza tym, że Ci coś lub ktoś zrywa połączenie SSH.