🚀 go-pugleaf

Marcin Jagodzinski wrote:
> 
> Czy moglby ktos wyjasnic, co to jest IP-spoofing (chodzi o metode jaka
> uzyl Kevin Mitnick wlamujac sie do komputera Shimomury).

Jest to po prostu rodzaj "podsłuchiwania" pakietów IP. Podsłuchujący
uruchamia oprogramowanie, które pozwala mu takie pakiety latające w
sieci przechwycić i następnie przeglądając ich zawartość może
przechwycić hasła administratorów i inne interesujące rzeczy. Oczywiście
robi to za niego automatycznie odpowiednie oprogramowanie.

Michał


-- 
********     MEMBER OF THE INTERNATIONAL PROGRAMMERS GUILD    ********
WWW: http://www.pdi.lodz.pl/~mimo   tel: Int. Acc. Code + 48 42 148340
add: Michal Mosiewicz  *  Bugaj 66 m.54 *  95-200 Pabianice  *  POLAND

In article <3298E56F.39125D6F@lodz.pdi.net>, =?iso-8859-2?Q?Micha=B3?= Mosiewicz <mimo@lodz.pdi.net> writes:
>Marcin Jagodzinski wrote:
>> =
>
>> Czy moglby ktos wyjasnic, co to jest IP-spoofing (chodzi o metode jaka
>> uzyl Kevin Mitnick wlamujac sie do komputera Shimomury).
>
>Jest to po prostu rodzaj "podsluchiwania" pakietow IP. Podsluchujacy
>uruchamia oprogramowanie, ktore pozwala mu takie pakiety latajace w
>sieci przechwycic i nast=EApnie przegladajac ich zawartosc moze
>przechwycic hasla administratorow i inne interesujace rzeczy. 

Absolutnie nie... Owszem, mozna podsluchiwac pakiety, ale to wymaga 
fizycznego dostepu do sieci ofiary ataku. IP-spoofing jest to dosc trudna i 
skomplikowana forma ataku polegajaca najogolniej na wysylaniu do atakowanej 
maszyny pakietow IP ze sfabrykowanym adresem nadawcy. Jezeli cel ataku 
uzywa adresow IP jako autoryzacji (znaczy pakiety wydaja sie pochodzic z jego 
'trusted host') i przy spelnieniu pewnych dodatkowych zalozen taki atak 
moze pozwolic atakujacemu na zainstalowanie w celu swojego uprzywilejowanego 
programiku, ktory pozwoli mu na dostep do czego bedzie chcial. Trudne jest
przede wszystkim dlatego, ze atakujacy nie ma zadnego 'kanalu zwrotnego'
podczas dzialania - atakowana maszyna wysyla wszak potwierdzenia i odpowiedzi 
pod falszywy adres IP...

Czytalem kiedys dokladna analize takiego ataku na ktorejs z grup poswieconych
security - wiec pewnie mozna cos znalezc grzebiac w odpowiednich archiwach.

Oczywiscie dobry router (firewall) nie powinien wpuszczac w ogole w siec
pakietow ktore wydaja sie przychodzic 'ze zlej strony' - taki router stanowi
zabezpieczenie przed atakiem metoda IP-spoofing.

JMP

Jerzy Michal Pawlak <jmp@fuw.edu.pl> wrote:

: Absolutnie nie... Owszem, mozna podsluchiwac pakiety, ale to wymaga 
: fizycznego dostepu do sieci ofiary ataku. IP-spoofing jest to dosc trudna i 

Nie trzeba fizycznego dostepu... wystarczy chyba odpowiedni program, sa
tego odmiany na kazdy system (rozne NetMony i takie inne maja to jako
czesc pakietu).
A spoofing to wysylanie pakietow ze sfalszowanym adresem nadawcy. Co do
ataku uzytego przez Mitnicka to jeszcze uzywal metody blokujacej komputer
ktory udawal (ICMP flooding) zeby nie mogl odpowiedziec na dochodzace do
niego "bez powodu" pakiety. 
Prawie wszystkie routery wywalaja (juz) pakiety ktore zdaja sie pochodzic z
wnetrza sieci a przychodza z zewnatrz.
Artykuly o spoofingu ukazaly sie ostatnio w paru czasopismach
internetowych. Gdzies na sieci jest dostepny "IP Spoofing white paper" ale
pelen jest niejasnosci i wogole trudny do zrozumienia.

-- 
  /-= ID =----------/-= Adress =-------==-------= HTTP =-/-= IRC =-------/\
 | Stanislaw Pasko | smoku@serek.arch.pwr.wroc.pl       | #rpg-pl       |  |
 |    AKA SMoku    | http://www.arch.pwr.wroc.pl/~smoku | #hack #hackpl |  |
  \-----------------\------------------------------------\---------------\/

In article <57c9ps$3eg@sun1000.pwr.wroc.pl>, Staszek Pasko <smoku@serek.arch.pwr.wroc.pl> writes:
>Jerzy Michal Pawlak <jmp@fuw.edu.pl> wrote:
>
>: Absolutnie nie... Owszem, mozna podsluchiwac pakiety, ale to wymaga 
>: fizycznego dostepu do sieci ofiary ataku. IP-spoofing jest to dosc trudna i 
>
>Nie trzeba fizycznego dostepu... wystarczy chyba odpowiedni program, sa
>tego odmiany na kazdy system (rozne NetMony i takie inne maja to jako
>czesc pakietu).

Zaraz, bo chyba sie nie rozumiemy... Jak niby taki program ma 'podsluchiwac'
nie majac fizycznego dostepu do kabli w atakowanej instytucji? Magicznie?
Mierzac zmiany pola E-M wywolane transmisja?
Piszac 'fizyczny dostep do sieci' nie mam na mysli dostepu do atakowanego
komputera, tylko do jakiegos kabla po ktorym plyna pakiety z/do niego,
czyli na ogol do lokalnego Ethernetu danej instytucji (bo, mam nadzieje,
niewielu adminow jest tak glupich zeby bez specjalnych narzedzi 
autoryzujacych loginowac sie na uprzywilejowane konta przez telefon albo 
publiczna siec).

JMP

Staszek Pasko <smoku@serek.arch.pwr.wroc.pl> wrote:
: Jerzy Michal Pawlak <jmp@fuw.edu.pl> wrote:

: : Absolutnie nie... Owszem, mozna podsluchiwac pakiety, ale to wymaga 
: : fizycznego dostepu do sieci ofiary ataku. IP-spoofing jest to dosc trudna i 

: Nie trzeba fizycznego dostepu... wystarczy chyba odpowiedni program, sa
: tego odmiany na kazdy system (rozne NetMony i takie inne maja to jako
: czesc pakietu).
W tym wypadku "fizyczny dostęp" == "dostęp (może być zdalny, byle 
z prawami roota) do komputera fizycznie przyłączonego do danej podsieci 
(tak żeby można było zapuścić sniffer na danym segmencie Ethernetu)".
-- 
                   Szymon Sokol -- Network Manager
U   U M   M M   M  University of Mining and Metallurgy, Computer Center
U   U MM MM MM MM  Mickiewicza 30, 30-059 Krakow, POLAND.    FAX +48 12 338907
 UUU  M M M M M M  http://galaxy.uci.agh.edu.pl/~szymon/     TEL +48 12 172894

Jerzy Michal Pawlak <jmp@fuw.edu.pl> wrote:

: czyli na ogol do lokalnego Ethernetu danej instytucji (bo, mam nadzieje,
: niewielu adminow jest tak glupich zeby bez specjalnych narzedzi 
: autoryzujacych loginowac sie na uprzywilejowane konta przez telefon albo 
: publiczna siec).                 
                                                              ^^^^^^^
Nie masz zaufania do TPSA? ;-)
-- 
                   Szymon Sokol -- Network Manager
U   U M   M M   M  University of Mining and Metallurgy, Computer Center
U   U MM MM MM MM  Mickiewicza 30, 30-059 Krakow, POLAND.    FAX +48 12 338907
 UUU  M M M M M M  http://galaxy.uci.agh.edu.pl/~szymon/     TEL +48 12 172894

Jerzy Michal Pawlak <jmp@fuw.edu.pl> wrote:
: Oczywiscie dobry router (firewall) nie powinien wpuszczac w ogole w siec
: pakietow ktore wydaja sie przychodzic 'ze zlej strony' - taki router stanowi
: zabezpieczenie przed atakiem metoda IP-spoofing.

Problem w tym, ze 'dobra' siec wewnetrzna, to tez taka, gdzie sa petle
na wypadek awarii routerow. Wiec niestety, pakiety moga dochodzic roznymi
dziwnymi drogami. 


Jaroslaw Lis

+------------------------------------------------------------------------+
| lis@ict.pwr.wroc.pl         | Institute of Engineering Cybernetics     |
| tel  48-71-202636           | Technical University of Wroclaw, Poland  |
| fax  48-71-203408 or 517398 |                                          |
+------------------------------------------------------------------------+

Jarek Lis <lis@ict.pwr.wroc.pl> wrote:
: Jerzy Michal Pawlak <jmp@fuw.edu.pl> wrote:
: : Oczywiscie dobry router (firewall) nie powinien wpuszczac w ogole w siec
: : pakietow ktore wydaja sie przychodzic 'ze zlej strony' - taki router stanowi
: : zabezpieczenie przed atakiem metoda IP-spoofing.

: Problem w tym, ze 'dobra' siec wewnetrzna, to tez taka, gdzie sa petle
: na wypadek awarii routerow. Wiec niestety, pakiety moga dochodzic roznymi
: dziwnymi drogami. 

Jest jednak raczej mało prawdopodobne, żeby do routera przyszedł 
przez interfejs A pakiet z podsieci przyłączonej *bezpośrednio* do 
interfesju B, nieprawdaż?
-- 
                   Szymon Sokol -- Network Manager
U   U M   M M   M  University of Mining and Metallurgy, Computer Center
U   U MM MM MM MM  Mickiewicza 30, 30-059 Krakow, POLAND.    FAX +48 12 338907
 UUU  M M M M M M  http://galaxy.uci.agh.edu.pl/~szymon/     TEL +48 12 172894

Szymon Sokol wrote:
> : Nie trzeba fizycznego dostepu... wystarczy chyba odpowiedni program, sa
> : tego odmiany na kazdy system (rozne NetMony i takie inne maja to jako
> : czesc pakietu).
> W tym wypadku "fizyczny dostêp" == "dostêp (mo¿e byæ zdalny, byle
> z prawami roota) do komputera fizycznie przy³±czonego do danej podsieci
> (tak ¿eby mo¿na by³o zapu¶ciæ sniffer na danym segmencie Ethernetu)".

Piszemy o sniffing'u czy spoofing'u ? Bo juz sie powoli gubie... a moze
co poniektorzy nie widza roznicy ? 

Szymonie akurat w to, ze ty rozrozniasz to nie watpie ;)

Z pozdrowieniami,

Grzegorz BRZESKI

-- 
++++++++++++>>> WEB Corporation <<<============
Gregory BRZESKI           gregory@webcorp.co.uk
	
           http://www.webcorp.co.uk/

=============Your Internet Partner+++++++++++++

Gregory BRZESKI <gregory@webcorp.co.uk> wrote:
: Szymon Sokol wrote:
: > : Nie trzeba fizycznego dostepu... wystarczy chyba odpowiedni program, sa
: > : tego odmiany na kazdy system (rozne NetMony i takie inne maja to jako
: > : czesc pakietu).
: > W tym wypadku "fizyczny dostęp" == "dostęp (może być zdalny, byle
: > z prawami roota) do komputera fizycznie przyłączonego do danej podsieci
: > (tak żeby można było zapuścić sniffer na danym segmencie Ethernetu)".

: Piszemy o sniffing'u czy spoofing'u ? Bo juz sie powoli gubie... a moze
: co poniektorzy nie widza roznicy ? 

Jak łatwo wywnioskować z kontekstu: o sniffingu. Dla wyjaśnienia: 
komentowałem twierdzenie, że do sniffingu nie jest potrzebny dostęp 
fizyczny do danej sieci, tylko wystarczy jakiś magiczny program.
-- 
                   Szymon Sokol -- Network Manager
U   U M   M M   M  University of Mining and Metallurgy, Computer Center
U   U MM MM MM MM  Mickiewicza 30, 30-059 Krakow, POLAND.    FAX +48 12 338907
 UUU  M M M M M M  http://galaxy.uci.agh.edu.pl/~szymon/     TEL +48 12 172894

Szymon Sokol <szymon@galaxy.uci.agh.edu.pl> wrote:
: Gregory BRZESKI <gregory@webcorp.co.uk> wrote:
: : Szymon Sokol wrote:
: : > : Nie trzeba fizycznego dostepu... wystarczy chyba odpowiedni program, sa
: : > : tego odmiany na kazdy system (rozne NetMony i takie inne maja to jako
: : > : czesc pakietu).
: : > W tym wypadku "fizyczny dostęp" == "dostęp (może być zdalny, byle
: : > z prawami roota) do komputera fizycznie przyłączonego do danej podsieci
: : > (tak żeby można było zapuścić sniffer na danym segmencie Ethernetu)".

: : Piszemy o sniffing'u czy spoofing'u ? Bo juz sie powoli gubie... a moze
: : co poniektorzy nie widza roznicy ? 

: Jak łatwo wywnioskować z kontekstu: o sniffingu. Dla wyjaśnienia: 
: komentowałem twierdzenie, że do sniffingu nie jest potrzebny dostęp 

bo wystarczy, jest to teoretycznie mozliwe do zrobienia..  Podejrzewam
ze w starszych implementacjach tcp/ip rowniez i praktycznie.
Skomentowac raczej nalezalo bzdury "smoka" o icmp w przypadku wspomnianego
ataku. Opis tego ataku jest pod :
http://www.wcmh.com/uworld/archives/95/security/001.txt.html

(jeden z lepszych jakie sa na sieci)

A jesli ktos tego nie rozumie jak Smok white papers jakichs to niech
powstrzyma sie od pisania bzdur.

-adam

Jerzy Michal Pawlak (jmp@fuw.edu.pl) wrote:

: Zaraz, bo chyba sie nie rozumiemy... Jak niby taki program ma 'podsluchiwac'
: nie majac fizycznego dostepu do kabli w atakowanej instytucji? Magicznie?
: Mierzac zmiany pola E-M wywolane transmisja?
: Piszac 'fizyczny dostep do sieci' nie mam na mysli dostepu do atakowanego
: komputera, tylko do jakiegos kabla po ktorym plyna pakiety z/do niego,
: czyli na ogol do lokalnego Ethernetu danej instytucji (bo, mam nadzieje,
: niewielu adminow jest tak glupich zeby bez specjalnych narzedzi 
: autoryzujacych loginowac sie na uprzywilejowane konta przez telefon albo 
: publiczna siec).
rozdzielmy sniffing od spoofingu....
gdzie rzym a gdzie krym?
sniffing wymaga dostepu do sieci lokalnej bo,polega na nasluchiwaniu
co tez  w niej lata po kabel;lkach...
spofing polega na podeslaniu ramek z falszywym adresem zwrotnym...
wiec wymagany jest tylko dostep do internetu...

pozdrawiam


--
Jacek Matusiak,  Warsaw University of Technology
E-mail : st1043@meil.pw.edu.pl,    cyb@irc.pl
URL    : http://www.meil.pw.edu.pl/~st1043  IrcNick: Cyb
Faculty of Power & Aeronautical Engineering 

Jarek Lis (lis@ict.pwr.wroc.pl) wrote:
: Jerzy Michal Pawlak <jmp@fuw.edu.pl> wrote:

: Problem w tym, ze 'dobra' siec wewnetrzna, to tez taka, gdzie sa petle
: na wypadek awarii routerow. Wiec niestety, pakiety moga dochodzic roznymi
: dziwnymi drogami. 
niekoniecznie...
bardzo czesto jest trak ze jakas siec ma tylko 1 router do lacznosci z inetem...
wystarczy kontrolowac to i juz po spoofingu....
a zreszta nawet jak jest kilka routerow to nie mozna przy kazdym postawic 
firewall??
pozdrawiam


--
Jacek Matusiak,  Warsaw University of Technology
E-mail : st1043@meil.pw.edu.pl,    cyb@irc.pl
URL    : http://www.meil.pw.edu.pl/~st1043  IrcNick: Cyb
Faculty of Power & Aeronautical Engineering 

Szymon Sokol <szymon@galaxy.uci.agh.edu.pl> wrote:
: Jarek Lis <lis@ict.pwr.wroc.pl> wrote:
: : Problem w tym, ze 'dobra' siec wewnetrzna, to tez taka, gdzie sa petle
: : na wypadek awarii routerow. Wiec niestety, pakiety moga dochodzic roznymi
: : dziwnymi drogami. 

: Jest jednak raczej mało prawdopodobne, żeby do routera przyszedł 
: przez interfejs A pakiet z podsieci przyłączonej *bezpośrednio* do 
: interfesju B, nieprawdaż?

Jak sie kabelek z interfejsu B wysunal? Czemu nie. 
Widac 'bezpieczna' siec musi byc najpierw 'porzadna'.

 
Jarek.

In article <57f1hi$9im@gemini.coi.pw.edu.pl>, st1043@PROBLEM_WITH_INEWS_DOMAIN_FILE (Jacek_Matusiak) writes:

>rozdzielmy sniffing od spoofingu....
>gdzie rzym a gdzie krym?
>sniffing wymaga dostepu do sieci lokalnej bo,polega na nasluchiwaniu
>co tez  w niej lata po kabel;lkach...
>spofing polega na podeslaniu ramek z falszywym adresem zwrotnym...
>wiec wymagany jest tylko dostep do internetu...

Nieuwaznie czytasz. Moj posting byl wlasnie odpowiedzia na wypowiedz
kogos, kto tego nie odroznial, a na dodatek wydawal sie twierdzic, ze do
sniffingu nie jest potrzebny fizyczny dostep do atakowanej sieci
a tylko jakis magiczny software.

Swoja droga - popraw swoja konfiguracje, albo zmus kogos zeby to zrobil.
Wlasciwie to powinienem byl poslac te odpowiedz prywatnym e-mailem, ale nie
chcialo mi sie rekonstruowac Twojego adresu wiec odpowiadam na liste...

JMP

Jerzy Michal Pawlak <jmp@cocos.fuw.edu.pl> wrote:

: Nieuwaznie czytasz. Moj posting byl wlasnie odpowiedzia na wypowiedz
: kogos, kto tego nie odroznial, a na dodatek wydawal sie twierdzic, ze do
: sniffingu nie jest potrzebny fizyczny dostep do atakowanej sieci
: a tylko jakis magiczny software.

mial kawalek racji. ramek ethernet nie da sie podluchac, ale praktycznie
wszystkie wyzszego poziomu da sie nie majac fizycznego dostepu. Kwestia
protokolu/implementacji

-adam

From: czeslaw@octopuss.ternet.pl (Czeslaw Mierzejewski)

szymon@galaxy.uci.agh.edu.pl wrote:

>komentowalem twierdzenie, ze do sniffingu nie jest potrzebny dostep 
>fizyczny do danej sieci, tylko wystarczy jakis magiczny program.

Taak, nie ma jak to magia. Ja bym jednak zwrocil uwage na co innego.
Dla mnie siec, to nie trzy kable miedzy pokojami, tylko rowniez sieci rozlegle.
I gdy gosc z Sokolej Wolki chce wejsc do centralnej bazy. KTOREDYS musi
wedrowac do tej centrali, bo nie wyobrazam sobie zbyt wielu firm majacych
WLASNE kable miedzymiastowe. W takim wypadku sytuacja sie jakby zmienia, nie ?
-- 

                               Czeslaw /e-mail for PGP-key/
                               czeslaw@octopuss.ternet.pl

mikee@galaxy.uci.agh.edu.pl (Adam Kubicki) writes:

> mial kawalek racji. ramek ethernet nie da sie podluchac, ale praktycznie
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
???

Mozesz to troche rozwinac? Czy to na tej samej zasadzie, na ktorej na
Linux'ie nie da sie zrobic dobrego firewall'a?

> wszystkie wyzszego poziomu da sie nie majac fizycznego dostepu. Kwestia
> protokolu/implementacji

Interesujace. Czy te wyzsze poziomy mozna podsluchac, jesli sa kierowane
z/do naszej maszyny (zdalnej), czy tez wystarczy by lecialy po Ethernecie?

Swoja droga ciekawych rzeczy sie czasem czlowiek dowiaduje.
-- 
Krzysztof Halasa
Network Administrator of The Palace of Youth in Warsaw

 	Przy okazji tej dyskusji chcialbym sie spytac czy jest jakis sposob na
zabezpieczenie sie, albo chociaz szybkie (automatyczne) wykrycie sniffingu w
podsieci.

				
-- 
					 ====================
					 Tomasz Baczynski     
					 tbaczyns@pg.gda.pl    
					 ====================

On 29 Nov 1996, Tomasz Baczy/nski wrote:

> 
>  	Przy okazji tej dyskusji chcialbym sie spytac czy jest jakis sposob na
> zabezpieczenie sie, albo chociaz szybkie (automatyczne) wykrycie sniffingu w
> podsieci.

ssh praktycznie uniemozliwia sniffowanie, ale to trzeba polaczyc z
calkowitym zaprzestaniem uzywania:
telnet, ftp, POP*, IMAP*

a co do wykrycia to nie sadze, bo to dziala na zasadzie biernego
podsluchu. musialbys miec pelna kontrole nad wszystkimi hostami w podsieci
i sprawdzac, co na nich chodzi, a to sie raczej rzadko zdarza
(przynajmniej na uczelniach)

pozdrawiam
--
/  irl: Bohdan 'Nexus' Horst |  mailto:nexus@irc.pl  | irc: Nexus  \
>----------------------------^---------v-------------^-------------<
\  http://www.physd.amu.edu.pl/~nexus/ | IF UAM Unix Administrator /

Krzysztof Halasa <khc@hq.pm.waw.pl> wrote:
: mikee@galaxy.uci.agh.edu.pl (Adam Kubicki) writes:

: > mial kawalek racji. ramek ethernet nie da sie podluchac, ale praktycznie
:                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
: ???

: Mozesz to troche rozwinac? Czy to na tej samej zasadzie, na ktorej na
: Linux'ie nie da sie zrobic dobrego firewall'a?

kurde, przeczytaj zdanie do konca, ok?


: > wszystkie wyzszego poziomu da sie nie majac fizycznego dostepu. Kwestia
: > protokolu/implementacji

: Interesujace. Czy te wyzsze poziomy mozna podsluchac, jesli sa kierowane
: z/do naszej maszyny (zdalnej), czy tez wystarczy by lecialy po Ethernecie?

: Swoja droga ciekawych rzeczy sie czasem czlowiek dowiaduje.

wystarczy zeby lecialy po ethernecie
jak leca do naszej zdalnej maszyny to przeciez mam bezposredni dostep ..

-adam

Bohdan Horst <nexus@hoth.amu.edu.pl> wrote:
: On 29 Nov 1996, Tomasz Baczy/nski wrote:

: > 
: >  	Przy okazji tej dyskusji chcialbym sie spytac czy jest jakis sposob na
: > zabezpieczenie sie, albo chociaz szybkie (automatyczne) wykrycie sniffingu w
: > podsieci.

: ssh praktycznie uniemozliwia sniffowanie, ale to trzeba polaczyc z
: calkowitym zaprzestaniem uzywania:
: telnet, ftp, POP*, IMAP*
                     ^^^^
Nie koniecznie. Wystarczy żeby klient IMAP zamiast rsh używał ssh. Np. w pine
wymaga to drobnej zmiany w źródłach (w Makefile zmienić RSHPATH z
/usr/bin/rsh na /usr/bin/ssh). Niestety windziaże są tutaj w takich
wypadkach upośledzeni, gdzyż wykonanie takich zmian w win apps graniczy
najczęściej z cudem 8-)) (brak źródeł).
Nie daje to co prawda full zabezpieczenia ale przynajmniej autoryzacja jest
bezpieczna i pozwala zrezygniować z .rhosts. Treść listów przesyłanych via
IMAP zdalnie będzie nadal nieszyfrowana ale tutaj w ostateczności może pomóc
PGP.
Ważne, że rozwiązanie takie uniemożliwia łatwe przechwycenie hasła.

kloczek
-- 
-----------------------------------------------------------
"Ludzie nie maja problemów, tylko sobie sami je stwarzają" 
-----------------------------------------------------------
Tomasz Kłoczko, student, PG FTiMS | e-mail : kloczek@rudy.mif.pg.gda.pl

In article <57mlhp$768@sunrise.pg.gda.pl>, tbaczyns@sunrise.pg.gda.pl (Tomasz Baczy/nski) writes:
>
> 	Przy okazji tej dyskusji chcialbym sie spytac czy jest jakis sposob na
>zabezpieczenie sie, albo chociaz szybkie (automatyczne) wykrycie sniffingu w
>podsieci.

Wykrycia? Przy standardowej technologii nie da sie chyba wykryc, Ethernet
z samej swojej definicji medium typu 'broadcast' - nadawca jest slyszany
przez wszystkich odbiorcow na danym segmencie i nie ma mozliwosci 
stwierdzenia ilu ich jest ani kto oni zacz.

Zabezpieczenie sie - jasne! Osprzet sieciowy i servery zamykac na mocne 
zamki, w pokoju bez okien i z solidnymi drzwiami. Nie wpuszczac do firmy 
obcych. Nie zostawiac 'aktywnych' a nieuzywanych gniazdek sieci do ktorych 
ktos moglby sie przylaczyc bez odlaczenia czegos innego. Nie wpuszczac 
na siec (albo co najmniej wydzielic 'bezpieczny' segment i nie wpuszczac 
na niego) maszyn dajacych  mozliwosc sniffowania nieuprzywilejowanym 
uzytkownikom (wszyscy wiemy o ktore chodzi - prawda?). Stosowac 'bezpieczne' 
narzedzia autoryzacji, jak np. wspomniany ssh. I wreszcie - nie uzywac 
Ethernetu do przesylania informacji takiej jak uprzywilejowane hasla (uzywac 
do tego wylacznie polaczen typu point-to-point). I pewnie jeszcze wiele 
innych sposobow ktorych akurat nie pamietam...

Stosowac, w zaleznosci od potrzeb i mozliwosci, dowolny podzbior powyzszych
zabiegow terapeutycznych.

JMP

Jerzy Michal Pawlak <jmp@fuw.edu.pl> wrote:

: In article <57mlhp$768@sunrise.pg.gda.pl>, tbaczyns@sunrise.pg.gda.pl (Tomasz Baczy/nski) writes:
: >
: > 	Przy okazji tej dyskusji chcialbym sie spytac czy jest jakis sposob na
: >zabezpieczenie sie, albo chociaz szybkie (automatyczne) wykrycie sniffingu w
: >podsieci.

: Wykrycia? Przy standardowej technologii nie da sie chyba wykryc, Ethernet
: z samej swojej definicji medium typu 'broadcast' - nadawca jest slyszany
: przez wszystkich odbiorcow na danym segmencie i nie ma mozliwosci 
: stwierdzenia ilu ich jest ani kto oni zacz.

najczesciej jesli ktos snifuje podsiec, ustawia ethernet adapter w promiscous 
mode, jesli ifconfig ci taki tryb pokaze a nie uzywasz wlasnie programu 
do monitorowania sieci to jest zle. Jesli jednak ktos snifuje tylko pakiety
przychodzace/wychadzace z hostu na ktorym sniffer chodzi wykrycie tego wymaga
troche zabiegow (bedac tam oczywiscie zalogowanym -  to zeby znow ktos zle 
nie zrozumial). Jesli chodzi o stwierdzenie ile komputerow wlasnie
slucha na kablu - dosc proste, jednak dziala w zaleznosci od protokolow
i implementacji. Dla TCP/IP np. wystarczy wyslac broadcast z nieprawidlowym
naglowkiem IP, zgodnie z rfc host powinien odpowiedziec ICMP bad parameter
albo zignorowac taki pakiet. wiec zalezy. Generalnie malo kto
uzywa sniferow lapiacych ramki ethernet, raczej lapia tylko te ktore niosa 
pakiety IP iwiec ich "tcp/ip" stack moze odpowiedziec ICMP na zly pakiet.
Mozna sluchac pakietow nie do siebie nie bedac w promiscous mode rowniez,  
(mala kombinacja arp/ip-forwarding) ale czesc systemow nie da sie tak 
oszykac (pakietow IP rzecz jasna).  Tak wiec jest mozliwe napisanie programu
ktory z duzym prawdopodobienstwem stwierdzi czy ktos nas podsluchuje, jednak
wyniki beda zalezne od systemow znajdujacych sie na kablu, stad wynika ze 
przy odpowiednim systemie bedzie to niemozliwe.
Natomiast jesli chodzi o zabezpieczenia przed snifowaniem, dobrym
ale drogim sposobem jest uzywanie switchees zamiast prostuch hubow.
Dana stacja dostanie wtedy tylko te pakiety ktore dla niej sa przeznaczone,
no i broadcasty.

-adam

Jerzy Michal Pawlak <jmp@fuw.edu.pl> wrote:

: In article <57mlhp$768@sunrise.pg.gda.pl>, tbaczyns@sunrise.pg.gda.pl (Tomasz Baczy/nski) writes:
: >
: > 	Przy okazji tej dyskusji chcialbym sie spytac czy jest jakis sposob na
: >zabezpieczenie sie, albo chociaz szybkie (automatyczne) wykrycie sniffingu w
: >podsieci.

: Wykrycia? Przy standardowej technologii nie da sie chyba wykryc, Ethernet
: z samej swojej definicji medium typu 'broadcast' - nadawca jest slyszany
: przez wszystkich odbiorcow na danym segmencie i nie ma mozliwosci 
: stwierdzenia ilu ich jest ani kto oni zacz.
Wg starego dowcipu: zalogować się na roota telnetem, słuchać, skąd 
krzyczą "JEEEEST!" :-)

: Zabezpieczenie sie - jasne! Osprzet sieciowy i servery zamykac na mocne 
: zamki, w pokoju bez okien i z solidnymi drzwiami. Nie wpuszczac do firmy 
: obcych. Nie zostawiac 'aktywnych' a nieuzywanych gniazdek sieci do ktorych 
: ktos moglby sie przylaczyc bez odlaczenia czegos innego. Nie wpuszczac 
: na siec (albo co najmniej wydzielic 'bezpieczny' segment i nie wpuszczac 
: na niego) maszyn dajacych  mozliwosc sniffowania nieuprzywilejowanym 
: uzytkownikom (wszyscy wiemy o ktore chodzi - prawda?). Stosowac 'bezpieczne' 
: narzedzia autoryzacji, jak np. wspomniany ssh. I wreszcie - nie uzywac 
: Ethernetu do przesylania informacji takiej jak uprzywilejowane hasla (uzywac 
: do tego wylacznie polaczen typu point-to-point). I pewnie jeszcze wiele 
: innych sposobow ktorych akurat nie pamietam...

Rozwiązanie drogie, ale niezłe: 
switche Ethernetowe, i każdy komputer podpiąć do osobnego portu.
-- 
                   Szymon Sokol -- Network Manager
U   U M   M M   M  University of Mining and Metallurgy, Computer Center
U   U MM MM MM MM  Mickiewicza 30, 30-059 Krakow, POLAND.    FAX +48 12 338907
 UUU  M M M M M M  http://galaxy.uci.agh.edu.pl/~szymon/     TEL +48 12 172894

	Przyznam, ze nie spodziewalem sie takiego odzewu na moje pytanie,
chcialbym sie jeszcze zorientowac czy istnieje jakies oprogramowanie
pod DOSa np.klient ssh , poniewaz wiekszosc polaczen jest realizowana wlasnie
spod  tego systemu (NCSA Telnet), windoze sluzy do uruchomienia netszkapy, a
przekonanie wszystkich userow do korzystania z F-Secure SSH (Windows) jest
raczej nierealna.

Szymon Sokol (szymon@galaxy.uci.agh.edu.pl) wrote:
: Jerzy Michal Pawlak <jmp@fuw.edu.pl> wrote:

: : In article <57mlhp$768@sunrise.pg.gda.pl>, tbaczyns@sunrise.pg.gda.pl (Tomasz Baczy/nski) writes:
: : >
: : > 	Przy okazji tej dyskusji chcialbym sie spytac czy jest jakis sposob na
: : >zabezpieczenie sie, albo chociaz szybkie (automatyczne) wykrycie sniffingu w
: : >podsieci.

: : narzedzia autoryzacji, jak np. wspomniany ssh. I wreszcie - nie uzywac 
: : Ethernetu do przesylania informacji takiej jak uprzywilejowane hasla (uzywac 
: : do tego wylacznie polaczen typu point-to-point). I pewnie jeszcze wiele 
: : innych sposobow ktorych akurat nie pamietam...

: Rozwiązanie drogie, ale niezłe: 
: switche Ethernetowe, i każdy komputer podpiąć do osobnego portu.
-- 
					 ====================
					 Tomasz Baczynski     
					 tbaczyns@pg.gda.pl    
					 ====================

In article <57n5lu$4q4@galaxy.uci.agh.edu.pl>, szymon@galaxy.uci.agh.edu.pl (Szymon Sokol) writes:
>Jerzy Michal Pawlak <jmp@fuw.edu.pl> wrote:
>:I wreszcie - nie uzywac 
>: Ethernetu do przesylania informacji takiej jak uprzywilejowane hasla (uzywac 
>: do tego wylacznie polaczen typu point-to-point). I pewnie jeszcze wiele 
>: innych sposobow ktorych akurat nie pamietam...

>Rozwiązanie drogie, ale niezłe: 
>switche Ethernetowe, i każdy komputer podpiąć do osobnego portu.

Slusznie, to podpada pod szeroko pojmowane 'uzywanie wylacznie polaczen
typu point-to-point' - bo efektywnie wtedy kazdy komputer ma swoje 
prywatne lacze do switcha. Warto jeszcze dodac ze jezeli juz ktos 
wydal pieniadze na ten switch, to nie powinien tez zalowac na pancerne
drzwi do pokoju w ktorym on stoi - bo majac fizyczny dostep do switcha
wlamywacz jest w stanie wszystko podsluchac...

JMP

In article <57n9dq$rki@sunrise.pg.gda.pl>,
	tbaczyns@sunrise.pg.gda.pl (Tomasz Baczy/nski) writes:
>	Przyznam, ze nie spodziewalem sie takiego odzewu na moje pytanie,
>chcialbym sie jeszcze zorientowac czy istnieje jakies oprogramowanie
>pod DOSa np.klient ssh , poniewaz wiekszosc polaczen jest realizowana 
>wlasnie spod  tego systemu (NCSA Telnet), windoze sluzy do uruchomienia 
>netszkapy, a przekonanie wszystkich userow do korzystania z 
>F-Secure SSH (Windows) jest raczej nierealna.

Jest jeszcze ssh pod OS/2, ale to i tak bylaby "przesiadka".

Tam, gdzie pracuję, przekonaliśmy znajomych do uzywania ssh w prosty sposób - 
zesniffowaliśmy im hasła, głośno wykrzykując każde nowo znalezione. :)

Jak ręką odjął, każdy kto ma Windows siedzi na ssh...

Niestety, dotyczyło to tylko ludzi pracujących w obsłudze sieci, a nie
wszystkich użytkowników (nie każdy może odpalić Windows)...

Może by wziąć się za port ssh do DOS'a?

-- 

              << Marcin Cieslak // saper@sgh.waw.pl >>

mikee@galaxy.uci.agh.edu.pl (Adam Kubicki) writes:

> : > mial kawalek racji. ramek ethernet nie da sie podluchac, ale praktycznie
> :                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> : ???
> 
> : Mozesz to troche rozwinac? Czy to na tej samej zasadzie, na ktorej na
> : Linux'ie nie da sie zrobic dobrego firewall'a?
> 
> kurde, przeczytaj zdanie do konca, ok?
> 
> 
> : > wszystkie wyzszego poziomu da sie nie majac fizycznego dostepu. Kwestia
> : > protokolu/implementacji


No dobra, czytam jeszcze raz:

AK> ramek ethernet nie da sie podluchac, ale praktycznie wszystkie wyzszego
AK> poziomu da sie nie majac fizycznego dostepu.

Wnioskuje, ze wg Ciebie nie da sie podsluchac ramek Ethernet (dobrze
zrozumialem?).

Jest to niestety ewidentny falsz, z latwoscia mozna podsluchac wszelkie ramki
Ethernet, nie wiedzac nic o ich typie (Ethernet II, albo jakis SNAP, Novell
802.3 itd, wlaczajac rowniez ramki stworzone przez siebie). Do podsluchiwania
ramek nie jest potrzebny zaden protokol (w sensie protocol stack). Nie jest
wymagane takze zadne specjalne oprogramowanie (w sensie unikalnosci).

Mozna wyswietlic sobie np. tresc calych ramek (np. 1514 bajtow Ethernet),
zaczynajac np. od adresu docelowej karty sieciowej. Jesli skonstruujesz taka
ramke, ktora nie bedzie miala w naglowku zadnych adresow, a np. bedzie to
list do sw. Mikolaja (teraz na czasie), to takze mozna to bez zadnego
problemu podsluchac.

Oczywiscie na tej samej maszynie mozna w tym samym czasie normalnie prowadzic
zwykla dzialalnosc TCPIP itp.
-- 
Krzysztof Halasa
Network Administrator of The Palace of Youth in Warsaw

In pl.comp.security Bohdan Horst <nexus@hoth.amu.edu.pl> wrote:

> ssh praktycznie uniemozliwia sniffowanie, ale to trzeba polaczyc z
> calkowitym zaprzestaniem uzywania:
> telnet, ftp, POP*, IMAP*

POP3 można bardzo łatwo puścić po szyfrowanym połączeniu 
(ssh -L 110:pop-serwer:110). 


-- 
Pawel Krawczyk, Krakow, Poland  .  Politechnika Krakowska  .  Fido 2:486/23
http://pipeta.chemia.pk.edu.pl/~kravietz/ PGP fingerprint: F00B602435AC9521

In pl.comp.security Marcin Cieslak <saper@sgh.waw.pl> wrote:

> Niestety, dotyczyło to tylko ludzi pracujących w obsłudze sieci, a nie
> wszystkich użytkowników (nie każdy może odpalić Windows)...
> Może by wziąć się za port ssh do DOS'a?

Kiedyś zacząłem coś takiego robić na wersji o ile pamiętam 1.2.14.
Kupa roboty, chyba żeby spróbować to skompilować pod DJGPP. Część
bibliotek można uzupełnić na podstawie DOSowych źródeł do PGP (chodzi
głównie o MPI, większość szyfrów i ewentualnie zlib). Funkcje sieciowe
chciałem zrobić w oparciu o bibliotekę Waterloo, bo akurat mi wpadła
w ręce. Ale ostatecznie nic z tego nie wyszło, bo nie miałem czasu ;(
Myślę, że prościej byłoby wziąć jakąś starszą wersję SSH i na początek
nieco ją okroić, na przykład o kilka szyfrów.

Natomiast sam chcę rozwiązać problem telnetów spod DOSa przygotowując
sobie dyskietkę bootującą z jądrem Linuxa, getty i statycznie 
zlinkowanym SSH ;)


-- 
Pawel Krawczyk, Krakow, Poland  .  Politechnika Krakowska  .  Fido 2:486/23
http://pipeta.chemia.pk.edu.pl/~kravietz/ PGP fingerprint: F00B602435AC9521

Pawel Krawczyk <kravietz@pipeta.chemia.pk.edu.pl> writes:

> Natomiast sam chcę rozwiązać problem telnetów spod DOSa przygotowując
> sobie dyskietkę bootującą z jądrem Linuxa, getty i statycznie 
> zlinkowanym SSH ;)

getty? Not required...
-- 
Krzysztof Halasa
Network Administrator of The Palace of Youth in Warsaw

In pl.comp.security Krzysztof Halasa <khc@hq.pm.waw.pl> wrote:
> > Natomiast sam chcę rozwiązać problem telnetów spod DOSa przygotowując
> > sobie dyskietkę bootującą z jądrem Linuxa, getty i statycznie 
> > zlinkowanym SSH ;)
> getty? Not required...

A wirtualne konsole bez niego będą działać?

-- 
Pawel Krawczyk, Krakow, Poland  .  Politechnika Krakowska  .  Fido 2:486/23
http://pipeta.chemia.pk.edu.pl/~kravietz/ PGP fingerprint: F00B602435AC9521

Marcin Cieslak <saper@sgh.waw.pl> wrote:

: Może by wziąć się za port ssh do DOS'a?
[----]

Robi to aktualnie 2 studentów na pracę dyplomową - jeden na PWr, 
jeden na AGH. Może któryś zrobi...
-- 
                   Szymon Sokol -- Network Manager
U   U M   M M   M  University of Mining and Metallurgy, Computer Center
U   U MM MM MM MM  Mickiewicza 30, 30-059 Krakow, POLAND.    FAX +48 12 338907
 UUU  M M M M M M  http://galaxy.uci.agh.edu.pl/~szymon/     TEL +48 12 172894

>>>>> "Tomek" == kloczek  <Tomasz>:
 Tomek> Bohdan Horst <nexus@hoth.amu.edu.pl> wrote:
 >> On 29 Nov 1996, Tomasz Baczy/nski wrote:

 >> > > Przy okazji tej dyskusji chcialbym sie spytac czy jest jakis
 >> sposob na > zabezpieczenie sie, albo chociaz szybkie (automatyczne)
 >> wykrycie sniffingu w > podsieci.

 >> ssh praktycznie uniemozliwia sniffowanie, ale to trzeba polaczyc z
 >> calkowitym zaprzestaniem uzywania: telnet, ftp, POP*, IMAP*
 Tomek> ^^^^ Nie koniecznie. Wystarczy żeby klient IMAP zamiast rsh
 Tomek> używał ssh. Np. w pine wymaga to drobnej zmiany w źródłach 
[...]

  Prościej jest użyć "port-forwarding" w ssh, czyli ustawić bezpieczny
kanał pomiędzy serwerem POP/IMAP, a lokalnym komputerem.

  Oczywiście zakładam, że na lokalnym komputerze działa jakiś system
operacyjny.

--J.

>>>>> "Adam" == Adam Kubicki <mikee@galaxy.uci.agh.edu.pl>:
 Adam> Jesli chodzi o stwierdzenie ile komputerow wlasnie slucha na
 Adam> kablu - dosc proste, jednak dziala w zaleznosci od protokolow i
 Adam> implementacji. Dla TCP/IP np. wystarczy wyslac broadcast z
 Adam> nieprawidlowym naglowkiem IP, zgodnie z rfc host powinien
 Adam> odpowiedziec ICMP bad parameter albo zignorowac taki pakiet. wiec
 Adam> zalezy.

[...]

  Magiczna i niepewna ta metoda -- moim zdaniem o wiele prosciej jest do
tego uzyc broadcastow ARP. Nawet naglowkow IP nie trzeba wtedy
podrabiac, hosty same sie pokaza.

  Inna sprawa, ze zaden wlamywacz z prawdziwego zdarzenia nie uzyje
standardowego stosu TCP/IP bez przeróbek.

--J.

Jerzy Michal Pawlak <jmp@cocos.fuw.edu.pl> wrote:
: >Rozwiązanie drogie, ale niezłe: 
: >switche Ethernetowe, i każdy komputer podpiąć do osobnego portu.

: Slusznie, to podpada pod szeroko pojmowane 'uzywanie wylacznie polaczen
: typu point-to-point' - bo efektywnie wtedy kazdy komputer ma swoje 
: prywatne lacze do switcha. Warto jeszcze dodac ze jezeli juz ktos 
: wydal pieniadze na ten switch, to nie powinien tez zalowac na pancerne
: drzwi do pokoju w ktorym on stoi - bo majac fizyczny dostep do switcha
: wlamywacz jest w stanie wszystko podsluchac...

Niekoniecznie musi byc tak drogo - jesli ktos planuje Fast Ethernet,
to 100VG , a przynajmniej w rozwiazaniu HP tez zapewniaja "utajnienie"
pakietow, za pieniadze porownywalne z hubem FE 100bTX.

Co prawda osobiscie uwazam, ze 100baseTX w najblizszej przyszlosci 
znacznie potanieje, a HP-100VG juz nie...


Jarek.

Krzysztof Halasa <khc@hq.pm.waw.pl> wrote:
: mikee@galaxy.uci.agh.edu.pl (Adam Kubicki) writes:

: > : > mial kawalek racji. ramek ethernet nie da sie podluchac, ale praktycznie
: > :                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
: > : ???
: > 
: > : Mozesz to troche rozwinac? Czy to na tej samej zasadzie, na ktorej na
: > : Linux'ie nie da sie zrobic dobrego firewall'a?
: > 
: > kurde, przeczytaj zdanie do konca, ok?
: > 
: > 
: > : > wszystkie wyzszego poziomu da sie nie majac fizycznego dostepu. Kwestia
: > : > protokolu/implementacji


: No dobra, czytam jeszcze raz:

: AK> ramek ethernet nie da sie podluchac, ale praktycznie wszystkie wyzszego
: AK> poziomu da sie nie majac fizycznego dostepu.

: Wnioskuje, ze wg Ciebie nie da sie podsluchac ramek Ethernet (dobrze
: zrozumialem?).

ok, napisze jasniej - ramek ethernet nie da sie podluchac bez bezp. dostepu,
natomiast da sie wyzsze protokoly (IP itd) bez owego bezp. dostepu (
zwanego czasem fizycznym) - juz ok?

-adam

Jan Rychter <jwr@icm.edu.pl> wrote:
: >>>>> "Adam" == Adam Kubicki <mikee@galaxy.uci.agh.edu.pl>:
:  Adam> Jesli chodzi o stwierdzenie ile komputerow wlasnie slucha na
:  Adam> kablu - dosc proste, jednak dziala w zaleznosci od protokolow i
:  Adam> implementacji. Dla TCP/IP np. wystarczy wyslac broadcast z
:  Adam> nieprawidlowym naglowkiem IP, zgodnie z rfc host powinien
:  Adam> odpowiedziec ICMP bad parameter albo zignorowac taki pakiet. wiec
:  Adam> zalezy.

: [...]

:   Magiczna i niepewna ta metoda -- moim zdaniem o wiele prosciej jest do
: tego uzyc broadcastow ARP. Nawet naglowkow IP nie trzeba wtedy
: podrabiac, hosty same sie pokaza.

to byl przyklad, istnieje kilka sposobow zaleznycvh glownie od systemow
jakie wisza na kablu. Chodzilo mi tylko o to ze czasami mozna sprawdzic
czy ktos jeszcze wisi na kabelku

:   Inna sprawa, ze zaden wlamywacz z prawdziwego zdarzenia nie uzyje
: standardowego stosu TCP/IP bez przeróbek.

wozi laptopa i wpina go w kabelki? :) czasami sie nie da

-adam

Jerzy Michal Pawlak <jmp@cocos.fuw.edu.pl> wrote:

: In article <57n5lu$4q4@galaxy.uci.agh.edu.pl>, szymon@galaxy.uci.agh.edu.pl (Szymon Sokol) writes:
: >Jerzy Michal Pawlak <jmp@fuw.edu.pl> wrote:
: >:I wreszcie - nie uzywac 
: >: Ethernetu do przesylania informacji takiej jak uprzywilejowane hasla (uzywac 
: >: do tego wylacznie polaczen typu point-to-point). I pewnie jeszcze wiele 
: >: innych sposobow ktorych akurat nie pamietam...

: >Rozwiązanie drogie, ale niezłe: 
: >switche Ethernetowe, i każdy komputer podpiąć do osobnego portu.

: Slusznie, to podpada pod szeroko pojmowane 'uzywanie wylacznie polaczen
: typu point-to-point' - bo efektywnie wtedy kazdy komputer ma swoje 
: prywatne lacze do switcha. Warto jeszcze dodac ze jezeli juz ktos 
: wydal pieniadze na ten switch, to nie powinien tez zalowac na pancerne
: drzwi do pokoju w ktorym on stoi - bo majac fizyczny dostep do switcha
: wlamywacz jest w stanie wszystko podsluchac...

switche tylko generalnie sa dobre.
Dam przyklad - komputer A, B, C polaczone switchem. TCP/IP siec.
wysylam arp'a do A ze (IP)B=moje MAC. komputer A wysyla teraz TCP pakiet do
B - trafia to do mnie, a ja forwarduje do B. I tu pojawia sie slowko
implementacja arp'a - solaris z tego co pamietam przyjmie taki pakiet tylko
po wczesniejszym wyslaniu zapytania. 
dosc latwo wskazac cechy(wady?) wyzszych protokolow ktore umozliwiaja 
podobny trick.
kurcze, kiedy wy zauwazycie ze tego hipotetycznego sniferka malo co obchodza
ramki ethernet ? jego interesuja TCP pakiety, a czesto wyzej.

-adam

Pawel Krawczyk <kravietz@pipeta.chemia.pk.edu.pl> writes:

> A wirtualne konsole bez niego będą działać?

Oczywiscie... jak masz init'a to po prostu /etc/inittab:

c1:1235:respawn:/bin/bash - </dev/tty1 >/dev/tty1 2>/dev/tty1
c2:1235:respawn:/bin/bash - </dev/tty2 >/dev/tty2 2>/dev/tty2

Chyba nie chcesz sie logowac do tego terminala, a dopiero z niego na
jakas maszynke?
-- 
Krzysztof Halasa
Network Administrator of The Palace of Youth in Warsaw

Pawel Krawczyk <kravietz@pipeta.chemia.pk.edu.pl> wrote:

: Natomiast sam chcę rozwiązać problem telnetów spod DOSa przygotowując
: sobie dyskietkę bootującą z jądrem Linuxa, getty i statycznie 
: zlinkowanym SSH ;)

Problem powstanie tylko, gdy posadzą cię do 286 lub gorzej... albo 
nawet do 386 ale z RAM<2MB (nie wiem, czy ktoś takich używa, ale 286 
i nawet 86 u nas są wciąż jako terminale używane) ;-)
-- 
                   Szymon Sokol -- Network Manager
U   U M   M M   M  University of Mining and Metallurgy, Computer Center
U   U MM MM MM MM  Mickiewicza 30, 30-059 Krakow, POLAND.    FAX +48 12 338907
 UUU  M M M M M M  http://galaxy.uci.agh.edu.pl/~szymon/     TEL +48 12 172894

Adam Kubicki <mikee@galaxy.uci.agh.edu.pl> wrote:
: switche tylko generalnie sa dobre.
: Dam przyklad - komputer A, B, C polaczone switchem. TCP/IP siec.
: wysylam arp'a do A ze (IP)B=moje MAC. komputer A wysyla teraz TCP pakiet do
: B - trafia to do mnie, a ja forwarduje do B. I tu pojawia sie slowko
: implementacja arp'a - solaris z tego co pamietam przyjmie taki pakiet tylko
: po wczesniejszym wyslaniu zapytania. 
: dosc latwo wskazac cechy(wady?) wyzszych protokolow ktore umozliwiaja 
: podobny trick.
: kurcze, kiedy wy zauwazycie ze tego hipotetycznego sniferka malo co obchodza
: ramki ethernet ? jego interesuja TCP pakiety, a czesto wyzej.

Mówiliśmy na razie o pasywnym snifferze. To co opisujesz powyżej, to 
już nie jest sniffer, tylko aktywna ingerencja w komunikację między 
hostami - i przy odpowiednim oprogramowaniu, wykrywalna. Krotko 
mowiąc, coś takiego jest możliwe tylko dlatego, że twórcy niektórych 
implementacji TCP/IP nie byli przewidujący - ale nie jest to (jak mi 
się wydaje) inherentna wada TCP/IP.
-- 
                   Szymon Sokol -- Network Manager
U   U M   M M   M  University of Mining and Metallurgy, Computer Center
U   U MM MM MM MM  Mickiewicza 30, 30-059 Krakow, POLAND.    FAX +48 12 338907
 UUU  M M M M M M  http://galaxy.uci.agh.edu.pl/~szymon/     TEL +48 12 172894

Adam Kubicki <mikee@galaxy.uci.agh.edu.pl> wrote:
: : >Rozwiązanie drogie, ale niezłe: 
: : >switche Ethernetowe, i każdy komputer podpiąć do osobnego portu.

: switche tylko generalnie sa dobre.
: Dam przyklad - komputer A, B, C polaczone switchem. TCP/IP siec.
: wysylam arp'a do A ze (IP)B=moje MAC. komputer A wysyla teraz TCP pakiet do
: B - trafia to do mnie, a ja forwarduje do B. I tu pojawia sie slowko
: implementacja arp'a - solaris z tego co pamietam przyjmie taki pakiet tylko
: po wczesniejszym wyslaniu zapytania. 
: dosc latwo wskazac cechy(wady?) wyzszych protokolow ktore umozliwiaja 
: podobny trick.

Dobry switch, z wbudowanym routerem TCP/IP. 
No i jak sie chce byc bezpiecznym, to sie z servera arp'a wywala, a adresy
wpisuje na stale - bo inaczej to sie tylko ulatwia wystawienie falszywego
hosta do rlogina.

J.

Adam Kubicki <mikee@galaxy.uci.agh.edu.pl> wrote:
: Krzysztof Halasa <khc@hq.pm.waw.pl> wrote:
: : mikee@galaxy.uci.agh.edu.pl (Adam Kubicki) writes:
: : AK> ramek ethernet nie da sie podluchac, ale praktycznie wszystkie wyzszego
: : AK> poziomu da sie nie majac fizycznego dostepu.

: : Wnioskuje, ze wg Ciebie nie da sie podsluchac ramek Ethernet (dobrze
: : zrozumialem?).

: ok, napisze jasniej - ramek ethernet nie da sie podluchac bez bezp. dostepu,
: natomiast da sie wyzsze protokoly (IP itd) bez owego bezp. dostepu (
: zwanego czasem fizycznym) - juz ok?

Hm, moglbys opisac dokladniej co nazywasz 'fizycznym dostepem'?
I dac pare przykladow w jaki sposob mozna podsluchiwac wyzsze protokoly, a 
ramek ethernetowych juz nie?

J.

mikee@galaxy.uci.agh.edu.pl (Adam Kubicki) writes:

> ok, napisze jasniej - ramek ethernet nie da sie podluchac bez bezp. dostepu,
> natomiast da sie wyzsze protokoly (IP itd) bez owego bezp. dostepu (
> zwanego czasem fizycznym) - juz ok?

Stary, mialo byc jasniej, a cos sciemniles. To naprawde nie jest
skomplikowane. Nie ma zadnej wielkiej roznicy pomiedzy podsluchaniem ramek
Ethernet a podsluchaniem wyzszych protokolow. Jedno i drugie mozna zrobic
bez "fizycznego" dostepu do podsluchiwanej sieci, wystarczy wejsc na konto
root'a na jakiejs maszynie, ktora jest w tej sieci. To chyba nie jest
"fizyczny" dostep? (Bo fizyczny to on jest, jako ze kabel, routery itp.
sa fizyczne).
-- 
Krzysztof Halasa
Network Administrator of The Palace of Youth in Warsaw

Krzysztof Halasa <khc@hq.pm.waw.pl> wrote:
: mikee@galaxy.uci.agh.edu.pl (Adam Kubicki) writes:

: > ok, napisze jasniej - ramek ethernet nie da sie podluchac bez bezp. dostepu,
: > natomiast da sie wyzsze protokoly (IP itd) bez owego bezp. dostepu (
: > zwanego czasem fizycznym) - juz ok?

: Stary, mialo byc jasniej, a cos sciemniles. To naprawde nie jest
: skomplikowane. Nie ma zadnej wielkiej roznicy pomiedzy podsluchaniem ramek
: Ethernet a podsluchaniem wyzszych protokolow. Jedno i drugie mozna zrobic
: bez "fizycznego" dostepu do podsluchiwanej sieci, wystarczy wejsc na konto
: root'a na jakiejs maszynie, ktora jest w tej sieci. To chyba nie jest
: "fizyczny" dostep? (Bo fizyczny to on jest, jako ze kabel, routery itp.
: sa fizyczne).

to chyba zaczyna sie przeradzac w jakas klotnie miedzy nami ;-) wiec krociutko
dla mnie to ty teraz herezje gadasz - loknij na moj nastepny mail 

-adam

Jarek Lis <lis@ict.pwr.wroc.pl> wrote:
: Adam Kubicki <mikee@galaxy.uci.agh.edu.pl> wrote:
: : Krzysztof Halasa <khc@hq.pm.waw.pl> wrote:
: : : mikee@galaxy.uci.agh.edu.pl (Adam Kubicki) writes:
: : : AK> ramek ethernet nie da sie podluchac, ale praktycznie wszystkie wyzszego
: : : AK> poziomu da sie nie majac fizycznego dostepu.

: : : Wnioskuje, ze wg Ciebie nie da sie podsluchac ramek Ethernet (dobrze
: : : zrozumialem?).

: : ok, napisze jasniej - ramek ethernet nie da sie podluchac bez bezp. dostepu,
: : natomiast da sie wyzsze protokoly (IP itd) bez owego bezp. dostepu (
: : zwanego czasem fizycznym) - juz ok?

: Hm, moglbys opisac dokladniej co nazywasz 'fizycznym dostepem'?
: I dac pare przykladow w jaki sposob mozna podsluchiwac wyzsze protokoly, a 
: ramek ethernetowych juz nie?

cale to zamieszanie w tej grupie bierze sie z tego ze troche inaczej 
rozumiemy niektore pojecia. Po pierwsze, snifing to dosc szerokie pojecie
- moze byc ethernet snifing, snifing hasel (a wiec z reguly TCP) itd.
Warto wiec, szczegolnie piszac jakies kategoryczne stwierdzenia (jak to, ktorego
sie doczepilem ze nie da sie snifowac bez bezp. dostepu) sprecyzowac o co nam dokladnie chodzi.
Wiec:
Fizyczny czy tez bezposredni dostep dla mnie maszyna ma wzgledem drugiej jesli
ruch pakietow miedzy nimi *nie* odbywa sie na podstawie wartosci pakietow 
(headerow) - sa to wiec np. cienki ethernet, skretka z glupim hubem itp.
*NIE* sa bezposrednio polaczone komputery poprzez router czy nawet switch,
wiec jesli "cos" decyduje o tym czy do mnie poslac pakiet na podstawie jego 
wartosci - jest oczywiste ze w tym przypadku "pasywny" sniffer nie ma szans
na przechwycenie pakietow nie kierowanych do niego.

Czasami mozna mimo braku fizycznego dostepu przechwytywac pakiety kierowane 
nie do mnie, ale jest to wowczas jak ladnie Szymon ujal "aktywny" sniffer,
i wykorzystuje po pierwsze cechy protkololow a po drugie cechy
danej implementacji protokolu. W niektorych przypadkach jakby sie wydawalo 
moge podsluchac nawet ramki ethernet (przyklad z switch'em i arp'em)- to blad.
to *NIE* byl ten sam pakiet ktory polecialby do tamtego komputera, podsluchalem
*wyzszy* protokol, IP, a pakiet ktory zlapalem mial pewne roznice na nizszym
poziomie (dest. adres ethernet) ktore na szczescie malo mnie obchodza.
Wiec, smialo moge twierdzic ze o ile do podsluchiwania ramek ethernet
konieczny jest dostep fizyczny , to aby podsluchac inne, wyzsze protokoly
nie jest to konieczne. Oczywiscie raczej nie dotrrze do mnie nizszy protokol
w niezmienionym stanie, generalnie jednak na nim mi nie zalezy.
Mozliwe sa wiec "magiczne" programy, osobiscie nie wierze jednak w takie
ktore dzialaja "zawsze i wszedzie" - beda to raczej programy pod konkretne
protkololy, a co najwazniejsze dana siec, to jak ona jest zorganizowana.
Np. jest siec z loghost'em, icmp redirect/RIP/arp itp moga doprowadzic
do tego ze pakiety z komputera w tamtej sieci kierowane do loghost'u
trafia do mnie (akurat w takim przypadku cale IP trafi, nie tylko UDP)
naciagajac dalej jesli tam sa dwa gateway'e to nawet moga dotrzec przeze
mnie do przeznaczenia - jednak takie kroki byly poniewaz tamta siec akurat
tak jest zrobiona - na innej, o innej "architekturze", z innymi systemami
to nie mialo by szans zadzialac.
Chcialbym zaznaczyc ze caly czas mowie o TCP/IP, nie mam pojecia co jest
mozliwe/niemozliwe z IPX, DECnet itd.
Mowiac o tym co mozliwe a co nie naprawde prosze o sprecyzowanie o jakim
snifingu mowimy, jestem w stanie sobie wyobrazic sytuacje w ktorej
bardzo zalezalo by mi na snifowaniu "dns query" jakie sle dns server np.
Wiec, cos wyzej niz tcp/udp/icmp/ip. 
Te wszystkie "aktywne" snifery sa oczywiscie dosc latwo zauwazalnie ,
jednak *sa mozliwe* w niektorych przypadkach. A czy magiczne czy nie
to juz tylko zalezy od naszego poziomu wiedzy.
Mam nadzieje ze wyjasnilem o co mi caly czas chodzilo - zwlaszcza khc ;-)

-adam

mikee@galaxy.uci.agh.edu.pl (Adam Kubicki) writes:

> Mam nadzieje ze wyjasnilem o co mi caly czas chodzilo - zwlaszcza khc ;-)

Ciesze sie ze w koncu zrozumialem o ci Ci chodzilo :)

Tyle ze mogles napisac, ze w przypadku braku Twojego "fizycznego dostepu"
niemozliwe jest podsluchanie ramek Ethernet, natomiast od czasu do czasu,
w przypadku blednej konfiguracji sieci, mozliwe jest wykorzystanie tych
bledow konfiguracyjnych w celu przechwycenia pakietow np. IP.

Nie twierdze oczywiscie, ze takie bledy nie zdarzaja sie w 50% instalacji,
ale w poprawnej sieci masz do wyboru:
- podsluchac wszystkie pakiety zaczynajac od ramek Ethernet - jesli masz
  dostep do sieci fizycznej, np. [Win]DOSa, konto root'a itp.
- nie podluchasz nic, jesli dostepu nie masz.

(Istnieje jeszcze 3 mozliwosc - jesli ISP atakowanego posluguje sie takimi
protokolami routingu, ktore daja sie oszukac, to da sie podsluchac
pakiety przesylane pomiedzy Internet'em i atakowana siecia.)
-- 
Krzysztof Halasa
Network Administrator of The Palace of Youth in Warsaw