[EMAIL PROTECTED] wrote: > Dnia Tue, 07 Feb 2006 19:27:57 +0100, Marek Guevara Braun > <[EMAIL PROTECTED]> napisał: > >> Czyli coś takiego jak dane na temat jakości generatorów losowych danej >> maszyny - parę lat temu Michał Zalewski (lcamtuf) generował ładne >> rysunki przestrzenne obrazujące jakość generatorów liczb losowych >> wykorzystywanych przy generacji numerów sekwencyjnych TCP na różnych >> platformach - niby nikt się już chyba nie bawi w przejmowanie połączeń >> TCP (nikt ???), > > To nie tak. Całkiem do niedawna znaczna większość systemów (wszystkie > swego czasu) generowały kolejne numery sekwencyjne dla różnych transmisji > TCP. W ten sposób można było przy pomocy maszyny zombie skanować porty > zdalnej maszyny poprzez porównanie zmiay numerów sekwencyjnych TCP. Tak > samo można było przewidzieć numer sekwencyjny kolejnych wysyłanych z > komputera pakietów, więc można było przechwytywać sesje TCP i w ogóle > dobrze się bawić.
IMHO "to nie tak" - idle scan przy użyciu "zombie" [1] wykorzystuje 16-bitowy ID z nagłówka IP, natomiast numer sekwencyjny TCP (aka ISN dla pierwszego pakietu) to 32 bitowe pole nagłówka, ale TCP. Na numerze sekwencyjnym i 32-bitowym numerze potwierdzenia opiera się sesja TCP - jeśli jesteśmy w stanie wymyślić, jakich numerów będą używały strony - można próbować podszyć się pod jednego z rozmówców i coś tam wkleić do transmitowanych danych lub zakończyć sesję wysyłając RST bez konieczności dostępu do "drutu". Teoretycznie mamy 2^64 możliwości, ale jak wykazał lcamtuf [2] tak do końca nie jest - i dla wielu platform wystarczy wiedzieć jakie numery są wybierane - stąd heurystyka - bo dokładnie jest to takie samo zgadywanie zachowania (ograniczanie przestrzeni) wykorzystanego algorytmu. W każdym razie w dobie połączeń SSH wartość jaką przynosi możliwość wymyślenia numerów sesyjnych jest dużo mniejsza niż za czasów telneta. > Pierwsze zablokowało tę możliwosć OpenBSD i hardneningi jajek kernela. > Teraz każde nowe połączenie TCP dosatje losową liczbę jako numer > sekwencyjny TCP. > > Jakość sprzętowego generatora liczb losowych, systemowych funkcji > realizujących losowania i specjalnych bibliotek do tego celu to osobny > problem. OpenSSL nieźle sobie na tym polu radzi i również ten problem > wział pod uwagę, więc raczej nie ma się co specjalnie przejmować. Dobry generator implementowany w software jest niestety drogi/wolny - używając systemu do obsługi wielu sesji SSL/TLS OpenSSL możesz wpaść w pułapkę wydajności - zwykle rozwiązania wybierają "wydajność" ponad "losowość" (tj. wybierają metody tańsze/szybsze). Sprzętowe generatory liczb losowych to już inna historia. Nasz Linux obsługuje od niedawna PadLock/xcrypt VIA, - czy coś jeszcze - wątpie. Nieco lepiej jest w Open/Free/NetBSD bo tam są jeszcze różne HiFn i inne. Dodatkowo dostępność tego w Polsce niemal zerowa. W sumie szkoda że nowe AMD czy Intele nie zaimplementowały tego tak jak VIA. > Generalnie nie ma co peniać, w 'normlanych' warunkach, choć trzeba być > świadomym, że włamanie się jest kwestią nie możliwośći, a środków > zainwestowanych ( w najprostrzym przłożeniu $ ). Czasami te warunki nie są normalne, a czasem ktoś pisze narzędzie i nagle to co wydawało się tylko wydumaną teorią może wyklikać każdy śmiertelnik na swoim WinXP. No ale zawsze jest jeszcze instancja wyższa dla paranoidalnych secure-maniaków - przychodzą smutni panowie i zabierają całego kompa wraz z kompletem kopii backup na CD/DVD :-) > Chyba EOT co? EOT, EOT. Pozdrawiam, Marek [1] http://www.insecure.org/nmap/idlescan.html [2] http://lcamtuf.coredump.cx/newtcp/ _______________________________________________ pld-users-pl mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
