Autor: Krzysztof Halasa (khc_at_hq.pm.waw.pl)
Data: Fri 16 Feb 1996 - 16:50:29 MET
Czesc,
Tomasz Kloczko (kloczek_at_rudy.mif.pg.gda.pl) wrote:
> Dowiedzielem sie ze jest jest mozliwe podszycie sie pod host24, ale
> jednoczesnie jest to technicznie o wiele bardziej skomplikowane od
> podsluhiwania pakietow (packet sniffing). Bez wchodzenia w szczegoly polega
> to na tym zeby spowodowac to zeby host, pod ktorego ktos chce sie podszyc
> zablokowac na chwilke tak zeby nie byl w stanie odpowiedziec na pewne
> sygnaly plynace z sieci. Prawdopodobienstwo powodzenia takiego podszycia
> powinno byc odwrotnie proporcjonalne do predkosci lacza jakim jest podaczony
> host pod ktorego sie ktos proboje podszyc i odwrotnie proporcjonalne do
> predkosci pracy tejze maszyny. Czyli ze postep technologiczny tutaj utrudnia
> zycie z dnia na dzien stosowanie takich technik.
> Wiec nadal zostaje przy swoim, ze jezeli spelni sie pewne warunki to rlogin
> jest bezpieczniejszy niz telnet.
Watpie. Podszyc sie pod jakis komputer mozna (moze nie jest to proste)
raczej w kazdym przypadku, poza takim gdzie istnieje router ktory nie
akceptuje pakietow przychodzacych od wlamywacza jako przychodzacych
ze zlego interface (firewalle to powszechnie robia). Tak wyglada IMHO
bezpieczenstwo rlogina. Zwykle jednak firewall nie dysponuje wystarczajaca
iloscia informacji nt. odleglych maszyn, by mogl odrzucac takie pakiety
(w przypadku maszyny znajdujacej sie np. w innej firmie wszystkie pakiety
ze swiata moga do niej przychodzic tym samym interfacem).
Osoba atakujaca nie musi znajdowac sie w poblizu ani na drodze pakietow.
Podobna sytuacja wystepuje zreszta w przypadku wszelkich uslug dajacych
dostep na podstawie numeru IP (i w przypadku innych protokolow, jak
np. novellowskiego IPX).
W przypadku, jesli kontrola dostepu dziala na podstawie nazwy maszyny
(np. FQDN), i komputer uzywa np. DNS do zamiany IP->nazwa, mozliwe
sa dalsze oszustwa - jesli by sie tak nieszczesliwie zlozylo,
ze server nie sprawdza adresow uzyskanej przez reverse DNS nazwy, to
mozna to wykorzystac bez zadnej (wielkiej) znajomosci jakichkolwiek
protokolow itp. Ale nawet jesli server veryfikuje odpowiedz reverse
DNS, to i tak jest to duze pole do popisu dla potencjalnych hackerow
(np. mozna udawac DNS itp).
W/g mnie nie jest mozliwe takie skonfigurowanie maszyn w Internecie,
by mozna bylo w miare bezpiecznie (tj. zupelnie bezpiecznie zakladajac
brak nieznanych dziur w oprogramowaniu) uzywac kontroli dostepu (rlogin,
NIS, nfs itp) opartej na nazwie (numerze IP) maszyny w otwartym otoczeniu
sieciowym.
Przy telnecie mozna oczywiscie podsluchac haslo, ale trzeba miec dostep
do jednego z routerow przez ktory przechodza nasze pakiety, ew. do
jakiejs maszyny dolaczonej do lacza w ktorym sa nasze pakiety, ktora
to maszynka potrafi te pakiety podsluchac. Ponadto trzeba wiedziec
kiedy dana osoba bedzie sie logowac (ew. ustawic podsluch na stale,
ale to zwieksza prawdopodobienstwo wykrycia), itp. problemy.
W przypadku, gdy nie mamy dostepu do medium, w ktorym przesylane sa
pakiety z haslami, mozemy oczywiscie sprobowac wymusic zmiane routingu
przez np. wprowadzenie host routingu do atakowanej maszyny przez
nasza maszyne, o ile oczywiscie routery dadza sie oszukac. Ale oznacza
to w/g mnie niemozliwosc podsluchania hasla w bardzo duzej czesci
przypadkow (choc np. mozna by bylo probowac podszycia sie pod
terminal pracujacej juz osoby, ale to raczej trudne).
Nalezy jednak pamietac ze prawdopodobnie kazde zabezpieczenie (poza
ODPOWIEDNIO skonfigurowanymi firewallami, gdzie nie moge wyobrazic
sobie jak mozna by je obejsc - ale maszyny za takimi firewallami
nie sa praktycznie podlaczone do Internetu) da sie zlamac, i
prawdopodobnie kazde zabezpieczenie zostanie zlamane, jesli tylko
zysk z jego zlamania bedzie odpowiednio wiekszy od poniesionych
kosztow.
W tej chwili widze tylko jedno rozwiazanie - wszystkie dane (lacznie
z haslem) musza byc szyfrowane za pomoca algorytmu RSA, natomiast
klucz publiczny servera musi byc przechowywany w terminalu (przesylanie
klucza servera w sieci jest takze bez sensu, gdyz mozna go podsluchac
i wyslac wlasny, przynajmniej w czesci przypadkow). Oznacza to jednak
koniecznosc stworzenia dosc mocnego oprogramowania zajmujacego sie
dystrybucja kluczy, autoryzacja itp.
Greetings,
KHC
--------------------------------------------------------------------
Krzysztof Halasa
Network Administrator of The Palace of Youth in Warsaw
Palac Mlodziezy Internet: khc_at_pm.waw.pl
ul. Swietokrzyska Fidonet: KHC, 2:480/40
00-901 Warsaw, Poland
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 12:39:06 MET DST