Намерено в нета.Употреба-незадължителна. Снифери.....
Какво е снифер /sniffer/?
За какво служат сниферите?
Как работят сниферите?
Можем ли да снифим някой, който не е от нашата мрежа?
Има ли значение дали машините в мрежата са свързани чрез Hub или Switch?
Може ли все пак да се снифи трафика в мрежа, в която е използван Switch?
Какви биват някои от техниките за снифене на трафик в мрежа, в която е използван Switch?
- ARP spoofing - т.нар. man-in-the-middle attack
- Switch Jamming
- ICMP Redirect-ване
- ICMP Router Advertisements
- Fake-ване MAC address-а с този на "жертвата"
- Hardware-ни устройства
Кои са най-често снифените протоколи /protocols/?
Как можем да засечем снифер?
- ping методът
- ARP методът
- DNS методът
- Source-route методът
- Методът на примамката
- Host методът
- Latency методът
- TDR /Time-Domain Reflectometers/
- Светлините на Hub-а
- SNMP monitoring
Как да се предпазим от снифене?
- SSL /Secure Sockets Layer/
- PGP и S/MIME
- ssh /Secure Shell/
- VPNs /Virtual Private Networks/
От къде да намеря снифер за моето PC?
- Windows
- Macintosh
- Linux
- Unix
- DOS
- Други
=12= Линкове към software, сайтове и материали, свързани със снифенето
________________________ ______________ ___________ _________ _____ ___ __ _ _ _ _ _ _ _ _
________________________ ______________ ___________ _________ _____ ___ __ _ _ _ _ _ _ _ _
=1= Какво е снифер /sniffer/?
В миналото "снифер" е било hardware-но устройство, свързано физически към дадена мрежа. С напредването и развитието на
технологиите се появяват и software-ните снифери. С това се поставя началото на изкуството, наречено "network sniffing".
Както ФБР подслушват телефонни линии, така и сниферът позволява подслушване на компютърни conversations.
Компютърният трафик се извършва чрез протоколи /protocols/. Информацията се обменя във вид на пакети /packets/.
Чрез т.нар. "protocol analysis" /протоколен анализ/, сниферите декодират прихванатите пакети.
________________________ ______________ ___________ _________ _____ ___ __ _ _ _ _ _ _ _ _
=2= За какво служат сниферите?
Както много други неща, така и сниферите имат две страни. Едната легална, другата не чак толкова
Затова някои хора ги разделят на два вида: "Commercial packet sniffers" и "Underground packet sniffers".
Всъщност технологията им е еквивалента, но целта на тяхното използване е различна. Сниферите служат за намиране на
проблеми в мрежата, например защо компютър А няма връзка с компютър B. Те могат да бъдат използвани за намиране проблеми
в потока на трафика, за неговото log-ване и засичане на attackers в лошо настроение Но свойствата на packet sniffer-ите
далеч не се изчерпват с това. Чрез тях могат да се прихващат usernames и passwords в cleartext /некриптирани/, да се
подслушват разговори, да се краде информация и т.н.
________________________ ______________ ___________ _________ _____ ___ __ _ _ _ _ _ _ _ _
=3= Как работят сниферите?
Ethernet е може би най-популярният и разпространен способ днес за свързване на машини. Link-натите посредством
Ethernet машини представляват своеобразна LAN мрежа /Local Area Network/. Това означава, че всички машини в мрежата
могат да "видят" целия трафик в LAN-а. Ethernet картите имат филтър, който предотвратява прихващането на пакети, адресирани
до други машини чрез игнориране на всички frame-ове с различен MAC address от собствения.
Сниферът изключва този филтър и машината преминава в "promiscuous mode" /смесен режим/. По този начин целия трафик вече
минава през въпросната машина.
________________________ ______________ ___________ _________ _____ ___ __ _ _ _ _ _ _ _ _
=4= Можем ли да снифим някой, който не е от нашата мрежа?
Теоретично НЕ. Практически... ДА
Теоретично не може да снифим някой, който не се намира в същата мрежа, защото нямаме достъп до местата, където минава
трафика. Но практически можем да си осигурим достъп до машина от същата мрежа и да инсталираме и използваме снифер от нея.
Един троянски кон би свършил чудесна работа, но.. въпрос на вкус и въображение.
________________________ ______________ ___________ _________ _____ ___ __ _ _ _ _ _ _ _ _
=5= Има ли значение дали машините в мрежата са свързани чрез Hub или Switch?
ДA, има огромно значение.
Нека си представим, че имаме 4 компютъра /A, B, C & D/, свързани чрез Hub.
А изпраща packet към D. Всички изпратени packet-и минават през Hub-а. Но Hub-ът не знае къде точно се намира D и препраща
packet-а към всички компютри. B и C ще го игнорират, защото той е адресиран към D. Компютър D ще получи packet-а.
Очевидно е, че всички машини имат потенциален директен достъп до трафика в мрежата. Ако Network картата на компютър B беше
в promiscuous mode, той щеше да прихване packet-а, предназначен за D. Така B също щеше да получи изпратената до D
информация.
Ако на мястото на Hub-а имаше Switch, нещата щяха да изглеждат по коренно различен начин.
Switch-ът познава всички свързани към него компютри и знае къде се намират те. Когато A изпрати packet за D, той ще премине
през Switch-а и ще бъде насочен директно към D, без да преминава през B и C. Така че снифенето на data от компютър B и C e
невъзможно... теоретично.
________________________ ______________ ___________ _________ _____ ___ __ _ _ _ _ _ _ _ _
=6= Може ли все пак да се снифи трафика в мрежа, в която е използван Switch?
Както казах, това е невъзможно теоретично. Но отговорът е ДА, МОЖЕ.
Винаги можем да снифим трафика, който получава и създава нашата собствена машина. Хихи, добре де...
Нека разгледаме следната схема:
_____________ _____________
| | Switch | |
| | 1 _______ 2 | |
| |----->[_______]----->| |
| | | | |
|____________| | |____________|
Машина A | Машина B
|
______|______
| |
| |
| |
| |
|____________|
Машина C
Имаме 3 компютъра /A, B & C/, свързани чрез Switch.
A комуникира с B. packet-ите минават през Switch-а, който ги препраща към машината, за която са адресирани.
В тази ситуация C не може лесно да види трафика между A и B, но съществуват техники, позволяващи това.
________________________ ______________ ___________ _________ _____ ___ __ _ _ _ _ _ _ _ _
=7= Какви биват някои от техниките за снифене на трафик в мрежа, в която е използван Switch?
<@> ARP spoofing - т.нар. man-in-the-middle attack:
Да си представим, че A изпраща packet до B, който минава през Switch-а. Как C може да го прихване?
При тази атака /man-in-the-middle/ C заблуждава A, че всъщност е B. По този начин A изпраща packet-а, предназначен за B
към C. След това C препраща packet-а към B, претендирайки, че е A.
Ето какво се получава всъщност:
_____________ _____________
| | Switch | |
| | 1 _______ 4 | |
| |----->[_______]----->| |
| | | ^ | |
|____________| | | |____________|
Машина A 2| |3 Машина B
| |
____V__|____
| |
| |
| |
| |
|____________|
Машина C
Използвайки ARP spoofing за да направим man-in-the-middle attack, трябва да изпълним следните неща:
Първо трябва да разберем как A и B комуникират нормално.
За нормално протичаща комуникация A изисква MAC addess-а на B. За да го получи, ще провери в ARP cache-а си в случай, че
вече го има. Ако MAC address-ът на B се намира в ARP cache-а, A ще го използва. Ако MAC address-ът не се намира в ARP
cache-а, A ще изпрати ARP request. Машина B ще отговори с нейния MAC /и IP/ address. IP и MAC address-ът на B ще бъдат
запазени в ARP cache-а за бъдеща употреба.
Сега вече A може да комуникира с B. B ще извърши същата процедура за нормално протичане на комуникацията.
Приемаме, че A и B са осъществили връзка и обменят информация, минаваща през Switch-а.
Сега идва мястото на ARP spoofing-а.
Първата стъпка е да убедим A, че C всъщност е B. По този начин трафикът, предназначен за B, ще минава през C.
Но как може да стане това? Чрез "отравяне" /poisoning/ ARP cache-а на A.
ARP е протокол, за който не е нужна автентичност, т.е. всеки ARP packet, изпратен до който и да е host, ще предизвика
update на ARP cache-а.
C изпраща spoof-нат ARP packet към A, карайки A да изпраща предназначените за B packet-и на C. Чрез spoof-натия ARP packet
C принуждава A да update-не cache-а си. В update-натия ARP cache на IP address-а на B отговаря MAC adress-ът на C.
Това ще пренасочи трафика към компютър C. Ето какво би се случило:
ARP cache-ът на A ПРЕДИ получаването на spoof-натия ARP packet от C:
______________________________________________________________________
| IP address | MAC address |
|_________________________________|___________________________________|
| IP address-ът на B | MAC address-ът на B |
|_________________________________|___________________________________|
| IP address-ът на C | MAC address-ът на C |
|_________________________________|___________________________________|
| . . . | . . . |
|_________________________________|___________________________________|
ARP cache-ът на A СЛЕД получаването на spoof-натия ARP packet от C:
______________________________________________________________________
| IP address | MAC address |
|_________________________________|___________________________________|
| IP address-ът на B | MAC address-ът на C |
|_________________________________|___________________________________|
| IP address-ът на C | MAC address-ът на C |
|_________________________________|___________________________________|
| . . . | . . . |
|_________________________________|___________________________________|
C изпраща spoof-нат ARP packet и на машина B, за да смени MAC address-а на A в cache-а й със своя собствен MAC address.
Веднъж направено всичко това, packet-ите, които A изпраща за B, са route-нати към C; packet-ите, които B изпраща за A,
отново са route-нати към C. Attacker-ът ще трябва да "re-poison" ARP cache-овете периодично, защото операционната система
автоматично refresh-ва ARP cache-а през определено време /обикновено 30 секунди/.
Има още един важен детайл. Процесът може да бъде засечен чрез IP forwarding, поддържан от много операционни системи.
Много Switch-ове не поддържат "Port security" опция, позволяваща на Администратора да конфигурира кои машини могат да се
connect-нат към Switch-а. Тази опция позволява да се прекъсне връзката със Switch-а на машина с определен MAC address.
Port security не предотвратява ARP spoofing-а, защото тук става въпрос за отравяне на cache-овете на снифените машини.
Това не е нещо, което може да се избегне чрез Port security.
И нека едно малко допълнение към възможностите на man-in-the-middle attack-ата. Към прихванатия трафик могат да бъдат
добавени/изтрити/модифицирани packet-и. Това позволява hijack-ване на различни видове sessions, например telnet.
Могат да бъдат добавени команди от името на client-а или server-а в една telnet session.
Session hijack-ването не е само теоретична възможност. Снифери като ettercap например правят този процес реално приложим.
<@> Switch Jamming:
Някои Switch-ове могат да бъдат обърнати от "bridging mode" в "repeating mode", при който всички frame-ове се разпращат към
всички портове през цялото време. Този ефект може да се постигне чрез overflowing на address table-ите с голям брой фалшиви
MAC address-и. Overflowing-ът може да бъде предизвикан чрез постепенно увеличаващ се трафик или непрекъснато изпращане на
произволни packet-и към Switch-а.
<@> ICMP Redirect-ване:
ICMP Redirect-ването "казва" на машината да изпраща packet-ите в друга посока. Типичен пример е когато има две logical
subnets на същия physical segment. Машина А е на единия subnet, кореспондираща с машина B от другия subnet. Нито една от
двете машини не знае, че се намират на същия physical segment, но локалният router знае. Машина A изпраща packet
към router-а, предназначен за машина B. Тогава router-ът изпраща ICMP Redirect към A, информирайки, че всъщност A може
директно да изпраща packet-и към B. Нека присъединим още една машина - C. Тя може да промени горепосочения процес чрез
изпращане на ICMP Redirect към A, уведомявайки я, че може да изпраща packet-ите за B към C. По този начин packet-ите,
изпратени от A за B, ще бъдат насочени към машина C.
<@> ICMP Router Advertisements:
ICMP Router Advertisements информират машините в дадена мрежа кой е router-ът. Attacker може да изпрати packet-и,
деклариращ, че неговата машина е router-а. Така целият трафик ще минава през него. По-старите машини не поддържат
ICMP Router Advertisements. След като са уточнени тези детайли по въпросите със сигурността, много нови машини също не
ги поддържат.
<@> Fake-ване MAC address-а с този на "жертвата":
Идеята е Switch-ът да започне да изпраща към машина A frame-овете, предназначени за машина B. Това може да се постигне чрез
поддържането на активно изпращане на frame-ове с address-а на машина B. Switch-ът ще повярва, че машина A всъщност е B и
ще започне да изпраща frame-овете, предназначени за B на машина A. Проблемът тук е, че машина B ще продължи изпращането на
data със своя MAC address, което би върнало Switch-а към предишното състояние на пренасочване data-та към B. Друг проблем е,
че ако машина B не получи frame-а, комуникацията ще бъде преустановена и няма да има нищо, което да се снифи.
Има няколко решения на този проблем, в зависимост какво искаме да направим. Ако искаме да преустановим автентичната
комуникация, можем да принудим машина B да мине offline /чрез DoS например/ и да продължим комуникацията, все едно нищо не
се е случило. Друго решение например е изпращането на packet-и с MAC address-а на B на определени интервали от време.
В такъв случай A ще получи следващите няколко packet-а, предназначени за B, но B ще загуби връзка /timeout/ и ще
преустанови, вероятно и възобнови комуникацията. При поддържане на подобен процес, B ще забелязва от време на време
закъснения на packet-ите. Подобно решение е при прихващане на packet-а, предназначен за B, машина A да го препрати обратно.
По този начин B ще получи packet-а. Един стабилен поток би позволил успешно симулиране на оригиналния трафик към машина B.
<@> Hardware-ни устройства:
Те могат да бъдат поставени между Switch-а и въпросната машина, която искаме да снифим.
За повече информация:
www.NetOptics.com
www.Sniffer.com
www.google.com
________________________ ______________ ___________ _________ _____ ___ __ _ _ _ _ _ _ _ _
=8= Кои са най-често снифените протоколи /protocols/?
Следните протоколи са най-честно снифени, особено за пароли:
<@> Telnet и rlogin - Могат да бъдат прихванати точните клавишни комбинации, по начина, по който са въведени, включително
usernames и passwords.
<@> http - Много website-ове имат автентикация, при която usernames и passwords се изпращат в cleartext; data-та - cleartext.
<@> SNMP - Почти целия SNMP трафик е SNMPv1, слаб по отношение на сигурността. SNMP passwords - изпращат се в cleartext.
<@> NNTP - Паролите се изпращат в cleartext; data-та също.
<@> POP - Паролите се изпращат в cleartext; data-та също.
<@> FTP - Паролите се изпращат в cleartext; data-та също.
<@> IMAP - Паролите се изпращат в cleartext; data-та също.
Всички тези решения си имат и по-сигурни алтернативи. Когато става въпрос за информация, свързана с Credit Cards,
повечето сайтове използват SSL encryption вместо обикновен HTTP. S/MIME и PGP например могат да криптират e-mails на ниво,
по-високо от e-mail protocol-и като POP/IMAP/SMTP.
________________________ ______________ ___________ _________ _____ ___ __ _ _ _ _ _ _ _ _
=9= Как можем да засечем снифер?
Теоретично... е невъзможно да се засекат снифери, защото те са пасивни - само събират packet-и. Но на практика,
в повечето случаи е възможно сниферите да бъдат засечени. Самостоятелният снифер не изпраща packet-и, но несамостоятелно
инсталираният снифер на обикновен компютър често генерира трафик. Например, може да изпраща DNS reverse lookups за да
намери имена, асоциирани с IP address-и. Несамостоятелните снифери всъщност са тези, които бихме искали да засечем.
Когато attacker-и посягат на машини, те често инсталират sniffing programs. Как можем да ги засечем?
<@> ping методът:
Повечето снифери се инсталират на машини, поддържащи TCP/IP. Това означава, че ако изпратим request към тези машини, те
ще отговорят. Номерът е да изпратим на съмнителната машина request към реалния й IP address, но не към нейния
Ethernet adapter /към различен MAC address/.
Какво се получава:
Нека съмнителната машина - A, на която предполагаме, че е пуснат снифер, има IP address 10.0.0.1 и Ethernet address
/MAC address/ 00-41-7C-B4-56-02. Ние /машина B/ сме на същия Ethernet segment. Изменяме леко нашия MAC address, нека той
изглежда така:00-41-7C-B4-56-03. След това изпращаме ICMP Echo Request /ping/ с вече променения MAC address.
Никой в мрежата не би трябвало да види този packet, защото когато packet-ът минава по мрежата, всеки Ethernet adapter
сравнява MAC address-а с неговия собствен. Ако няма съвпадение, той игнорира frame-а. Ако нашата машина B получи отговор,
тогава съмнителната машина A не използва нейния филтър, следователно се намира в promiscuous mode и снифи трафика.
Има начини да се предотврати засичане чрез този метод. Някои attacker-и биха сложили виртуален MAC address filter.
Много машини /например под Windows/ имат MAC filtering в driver-ите.
Тази техника обикновено работи на мрежи, където се използва Switch. Когато Switch-ът види непознатия MAC address за пръв
път, той ще flood-не с frame-а всички segments.
Всъщност всеки protocol, който генерира response, може да бъде използван за засичане на снифера. Например TCP connection
request или UDP protocol като port 7 /echo/. Всеки protocol, който може да генерира грешка на съмнителната машина, може да
бъде използван. Например лоша стойност в IP header-а може да доведе до генериране на ICMP error.
<@> ARP методът:
ARP методът е подобен на ping метода, но при него се използва ARP packet. Най-лесният начин е да изпратим ARP на някой
non-broadcast address. Ако някоя машина отговори на този ARP packet, тогава тя се намира в promiscuous mode.
При някои варианти на тази техника се използва ARP cache-а. Когато изпратим един ARP packet на broadcast address, включваме
информация за нашите IP и MAC address-и. В такъв случай можем да изпратим ARP packet към non-broadcast, след това един
broadcast ping. Всеки, който отговори на нашия ping без да ни ARP-не, би знаел нашия MAC address от прихванатия ARP frame.
За да сме по-сигурни, препоръчвам използването на различни MAC address-и при ping-ването.
<@> DNS методът:
Както вече споменахме, много снифери правят автоматично reverse-DNS lookups на IP address-ите, които засичат. По този начин
сниферът може да бъде засечен чрез наблюдение на DNS трафика, който генерира.
Интересното е, че т. нар. "hacker-based sniffing programs" resolve-ват IP address-ите веднага, след като ги получат, докато
"commercial" програмите забавят resolve-ването докато потребителят види protocol-а декодиран.
<@> Source-route методът:
Това е друга техника, свързана с конфигурирането на source-route информация в IP header-а. Тя може да бъде използвана за
засичане на снифер на друг, близък segment.
Машина A създава ping packet към машина B, но слага loose source-route за да се препрати ping-а към машина C на същия segmet.
B не би трябвало да поддържа rooting, затова не би препратила packet-а към C. Ако машина A получи отговор от C, тогава на
C има снифер. При получен отговор е добре да се провери дали packet-ът е route-нат правилно или просто снифен.
Защо става така?
При loose source-routing една опция е добавена към IP header-а. Router-ите ще игнорират packet-а, но ще го препратят към
следващия IP address в source-route опцията. Това означава, че когато изпратим packet, казваме "моля, изпрати packet-а на
машина C, но го route-ни първо през машина B". По този начин машина B ще получи packet-а, но ще го drop-и, защото не
би трябвало да route-ва. Ако машина C отговори на ping-а, значи тя го е прихванала. Следва, че машина C е в promiscuous
mode, което означава, че на нея има инсталиран и работещ снифер. Има вероятност машина B наистина да route-ва. В такъв
случай може да бъде използван TTL field за да се провери дали C е отговорила на route-натия от B ping, или отговаря директно.
<@> Методът на примамката:
Докато ping и ARP методите работят само за локални мрежи, методът на примамката работи навсякъде.
Откакто има толкова много protocol-и, позволяващи cleartext passwords, има и хора, които се опитват да ги прихванат.
Методът се състои в създаването на client и server от двете страни на мрежата, като client-ът използва script за logon
в server-а чрез Telnet, POP, IMAP или някой plain-text protocol. Server-ът е конфигуриран със специални accounts,
които нямат истински права, или server-ът е напълно виртуален. След като attacker-ът прихване въпросните username и password,
той ще се опита да се log-не, използвайки информацията, която е получил чрез снифера. Системата на server-ът log-ва
attacker-а и съобщава, че има някой снифещ в мрежата.
<@> Host методът:
Когато attackers получат access до дадена система, те често оставят снифеща програма, инсталирана и стартирана за
прихващане на usernames и passwords. Тези програми често са прикрити /като троянски кон/ в други програми, затова
единственият начин да се намери подобна програма е да се провери дали машината е в promiscuous mode. Разбира се трябва да се
има в предвид, че вероятно attacker-ът е помислил за "ifconfig -a" и се е погрижил да скрие данните за promiscuous mode.
Има различен software, който може да провери hardware-а директно, или можем да стартираме ifconfig program-ата директно от
CD-ROM дистрибуция.
<@> Latency методът:
Този метод е по-драстичен. Използват го зли Админи)) От една страна тази техника може значително да затрудни работата на
мрежата. От друга страна може да "заслепи" сниферите чрез изпращането на прекалено много трафик.
Идеята тук е да се създаде голям мрежов трафик. Той не би засегнал машините в non-promiscuous mode, но би имал силен ефект
върху снифещите машини. Просто ping-ваме машините преди натоварването на мрежовия трафик и по време на самото натоварване и
тестването на разликата в необходимото за respone време може да индикира ако една машина е прекалено натоварена.
Съществува един проблем при тази техника. Packet-ите могат да закъснеят просто защото натоватването в мрежата е прекалено
голямо, което би коствало timeout-и и фалшиви тревоги. От друга страна, много снифери работят в "user mode", докато
ping-овете протичат в "kernel mode". Тогава независимостта на CPU ще предотврати прекаленото натоварване.
<@> TDR /Time-Domain Reflectometers/:
TDR представляват своеобразни радари за мрежа. Те изпращат сигнали по мрежата, които се връщат и правят графика. По тази
графика се следи дали има някое устройство, което не би трябвало да е свързано към мрежата. Те могат да локализират с
приблизителна точност къде се намира сниферът. TDR могат да локализират и hardware-ни снифери, които са напълно "невидими".
TDR са използвани в миналото за локализиране на снифещи устройства, но в днешно време ма мрежи със star topologies,
те се използват изключително рядко.
Съществува също и OTDR equipment, но това е за прекалено болните параноици
<@> Светлините на Hub-а:
Може ръчно да се проверят светлинките на Hub-а за да се види дали има неочаквани connections. Това дава представа за
кабелите, където може да се намира физически даден снифер.
<@> SNMP monitoring:
По-умничките Hub-ове с SNMP management могат да предоставят автоматично monitoring на Ethernet /и други/ Hub-ове. Някои
management console-и могат да log-ват connect-ването и disconnect-ването към всички port-ове. Ако сме конфигурирали
системата с информация за всички кабели, понякога можем да засечем къде вероятно се крие снифер.
________________________ ______________ ___________ _________ _____ ___ __ _ _ _ _ _ _ _ _
=10= Как да се предпазим от снифене?
Това, което бих Ви препоръчала, е едно стабилно криптиране /encryption/. Ето няколко примера:
<@> SSL /Secure Sockets Layer/:
SSL е вграден във всички популярни web browser-и и web server-и. То позволява криптирано сърфиране в Internet и почти
винаги е използвано в e-commerce когато user-ите дават информация за техните Credit cards.
<@> PGP и S/MIME:
E-mail-ите могат да бъдат снифени по много алтернативни начини. Те минават през корпоративни firewall-и, които могат да
правят monitoring на трафика. Често той се log-ва и се пази за определен период от време. Може случайно да се получи грешка
при direct-ването и да попадне в чужда mailbox. Най-добрият начин да предпазим важни e-mails е да ги криптираме. Два от
основните начини са с PGP /Pretty Good Privacy/ и S/MIME - /Secure MIME/. PGP може да се добави към много продукти. S/MIME
е built-in в e-mail program-и от Netscape и Microsoft.
<@> ssh /Secure Shell/:
ssh е станал дефакто стандарт за log-ване в UNIX машини от Internet. Препоръчвам използването на този
service вместо Telnet. Редица други protocol-и могат да бъдат достъпни чрез ssh. Продуктът е развит от Finish company
http://www.ssh.fi/ , но съществува и във вид на доста open-source/freeware продукти.
<@> VPNs /Virtual Private Networks/:
VPNs осигуряват криптиран трафик през Internet. Но ако attacker-и се "погрижат" за end-nodes на VPN connection-а, те все още
могат да снифят трафика. Типичният сценарий е един end-user, който сърфира в Internet нормално, но е заразен с троянски кон,
съдържащ sniffing plug-in. Когато user-ът установи VPN connection-а, сниферът е способен не само да прихваща криптирания
трафик, който може да се види в Internet, но също и некриптирания трафик преди да бъде изпратен през stack-а на VPN-а.
________________________ ______________ ___________ _________ _____ ___ __ _ _ _ _ _ _ _ _
=11= От къде да намеря снифер за моето PC?
------------------------------------ Windows ------------------------------------
.::Ethereal::.
Ethereal е UNIX-based program-а, достъпна и за Windows /което означава, че инсталацията е малко по-трудна/.
Това вероятно е най-добрият freeware избор за Windows.
Сниферът бива в две версии: read-only /protocol analyzer/ версия, добра колкото capture (sniffing) версията. Read-only
версията е чудесна за декодиране на прихванати packet-и. Избягва проблемът с инсталацията на packet capture driver.
http://www.ethereal....ribution/win32/
.::WinDump::.
http://windump.polito.it/
.::WinNT Server::.
WinNT Server-ът на Microsoft има вградена програма, наречена "Network Monitor". Отидете в Networking control panel,
изберете "Services" tab, после "Add..." и изберете "Network Monitor Tools and Agent". Веднъж инсталирана, можете да я
стартирате от Program menu-то под "Administrative Tools".
.::BlackICE Pro::.
BlackICE засича смущаване в системата, има възможност за log-ване във формат, който може да бъде декодиран чрез
protocol analyzers. Това може да бъде по-полезно от използването на снифер с по-широко приложение когато става въпрос
за security. Програмата поддържа машината в non-promiscuous mode, което позволява единствено снифене на трафика към и от
машината.
http://www.networkice.com/
.::CiAll::.
Това е програма, която може само да декодира. Прекрасно решение за програми като BlackICE, които само log-ват packet-и, но
не притежават вградени декодери. Програмата е shareware за 90 дни.
!!!Забележка!!! - Съществуват съмнения за вграден троянец в CiAll.
http://www.winsite.c...fo?500000005196
.::Analyzer::.
Това е toolkit за различни видове анализи.
http://netgroup-serv...to.it/analyzer/
.::Sniff-em::.
Този снифер не генерира трафик, което затруднява засичането му. Това е единственият снифер, който поддържа Dialup adapter-и
за Windows 2000 и Windows XP. Подходящ за Windows 95(abc),98(SE),ME,NT4,2000 и XP.
http://www.sniff-em.com/download.shtml
Какво е снифер /sniffer/?
За какво служат сниферите?
Как работят сниферите?
Можем ли да снифим някой, който не е от нашата мрежа?
Има ли значение дали машините в мрежата са свързани чрез Hub или Switch?
Може ли все пак да се снифи трафика в мрежа, в която е използван Switch?
Какви биват някои от техниките за снифене на трафик в мрежа, в която е използван Switch?
- ARP spoofing - т.нар. man-in-the-middle attack
- Switch Jamming
- ICMP Redirect-ване
- ICMP Router Advertisements
- Fake-ване MAC address-а с този на "жертвата"
- Hardware-ни устройства
Кои са най-често снифените протоколи /protocols/?
Как можем да засечем снифер?
- ping методът
- ARP методът
- DNS методът
- Source-route методът
- Методът на примамката
- Host методът
- Latency методът
- TDR /Time-Domain Reflectometers/
- Светлините на Hub-а
- SNMP monitoring
Как да се предпазим от снифене?
- SSL /Secure Sockets Layer/
- PGP и S/MIME
- ssh /Secure Shell/
- VPNs /Virtual Private Networks/
От къде да намеря снифер за моето PC?
- Windows
- Macintosh
- Linux
- Unix
- DOS
- Други
=12= Линкове към software, сайтове и материали, свързани със снифенето
________________________ ______________ ___________ _________ _____ ___ __ _ _ _ _ _ _ _ _
________________________ ______________ ___________ _________ _____ ___ __ _ _ _ _ _ _ _ _
=1= Какво е снифер /sniffer/?
В миналото "снифер" е било hardware-но устройство, свързано физически към дадена мрежа. С напредването и развитието на
технологиите се появяват и software-ните снифери. С това се поставя началото на изкуството, наречено "network sniffing".
Както ФБР подслушват телефонни линии, така и сниферът позволява подслушване на компютърни conversations.
Компютърният трафик се извършва чрез протоколи /protocols/. Информацията се обменя във вид на пакети /packets/.
Чрез т.нар. "protocol analysis" /протоколен анализ/, сниферите декодират прихванатите пакети.
________________________ ______________ ___________ _________ _____ ___ __ _ _ _ _ _ _ _ _
=2= За какво служат сниферите?
Както много други неща, така и сниферите имат две страни. Едната легална, другата не чак толкова
Затова някои хора ги разделят на два вида: "Commercial packet sniffers" и "Underground packet sniffers".
Всъщност технологията им е еквивалента, но целта на тяхното използване е различна. Сниферите служат за намиране на
проблеми в мрежата, например защо компютър А няма връзка с компютър B. Те могат да бъдат използвани за намиране проблеми
в потока на трафика, за неговото log-ване и засичане на attackers в лошо настроение Но свойствата на packet sniffer-ите
далеч не се изчерпват с това. Чрез тях могат да се прихващат usernames и passwords в cleartext /некриптирани/, да се
подслушват разговори, да се краде информация и т.н.
________________________ ______________ ___________ _________ _____ ___ __ _ _ _ _ _ _ _ _
=3= Как работят сниферите?
Ethernet е може би най-популярният и разпространен способ днес за свързване на машини. Link-натите посредством
Ethernet машини представляват своеобразна LAN мрежа /Local Area Network/. Това означава, че всички машини в мрежата
могат да "видят" целия трафик в LAN-а. Ethernet картите имат филтър, който предотвратява прихващането на пакети, адресирани
до други машини чрез игнориране на всички frame-ове с различен MAC address от собствения.
Сниферът изключва този филтър и машината преминава в "promiscuous mode" /смесен режим/. По този начин целия трафик вече
минава през въпросната машина.
________________________ ______________ ___________ _________ _____ ___ __ _ _ _ _ _ _ _ _
=4= Можем ли да снифим някой, който не е от нашата мрежа?
Теоретично НЕ. Практически... ДА
Теоретично не може да снифим някой, който не се намира в същата мрежа, защото нямаме достъп до местата, където минава
трафика. Но практически можем да си осигурим достъп до машина от същата мрежа и да инсталираме и използваме снифер от нея.
Един троянски кон би свършил чудесна работа, но.. въпрос на вкус и въображение.
________________________ ______________ ___________ _________ _____ ___ __ _ _ _ _ _ _ _ _
=5= Има ли значение дали машините в мрежата са свързани чрез Hub или Switch?
ДA, има огромно значение.
Нека си представим, че имаме 4 компютъра /A, B, C & D/, свързани чрез Hub.
А изпраща packet към D. Всички изпратени packet-и минават през Hub-а. Но Hub-ът не знае къде точно се намира D и препраща
packet-а към всички компютри. B и C ще го игнорират, защото той е адресиран към D. Компютър D ще получи packet-а.
Очевидно е, че всички машини имат потенциален директен достъп до трафика в мрежата. Ако Network картата на компютър B беше
в promiscuous mode, той щеше да прихване packet-а, предназначен за D. Така B също щеше да получи изпратената до D
информация.
Ако на мястото на Hub-а имаше Switch, нещата щяха да изглеждат по коренно различен начин.
Switch-ът познава всички свързани към него компютри и знае къде се намират те. Когато A изпрати packet за D, той ще премине
през Switch-а и ще бъде насочен директно към D, без да преминава през B и C. Така че снифенето на data от компютър B и C e
невъзможно... теоретично.
________________________ ______________ ___________ _________ _____ ___ __ _ _ _ _ _ _ _ _
=6= Може ли все пак да се снифи трафика в мрежа, в която е използван Switch?
Както казах, това е невъзможно теоретично. Но отговорът е ДА, МОЖЕ.
Винаги можем да снифим трафика, който получава и създава нашата собствена машина.
Хихи, добре де...Нека разгледаме следната схема:
_____________ _____________
| | Switch | |
| | 1 _______ 2 | |
| |----->[_______]----->| |
| | | | |
|____________| | |____________|
Машина A | Машина B
|
______|______
| |
| |
| |
| |
|____________|
Машина C
Имаме 3 компютъра /A, B & C/, свързани чрез Switch.
A комуникира с B. packet-ите минават през Switch-а, който ги препраща към машината, за която са адресирани.
В тази ситуация C не може лесно да види трафика между A и B, но съществуват техники, позволяващи това.
________________________ ______________ ___________ _________ _____ ___ __ _ _ _ _ _ _ _ _
=7= Какви биват някои от техниките за снифене на трафик в мрежа, в която е използван Switch?
<@> ARP spoofing - т.нар. man-in-the-middle attack:
Да си представим, че A изпраща packet до B, който минава през Switch-а. Как C може да го прихване?
При тази атака /man-in-the-middle/ C заблуждава A, че всъщност е B. По този начин A изпраща packet-а, предназначен за B
към C. След това C препраща packet-а към B, претендирайки, че е A.
Ето какво се получава всъщност:
_____________ _____________
| | Switch | |
| | 1 _______ 4 | |
| |----->[_______]----->| |
| | | ^ | |
|____________| | | |____________|
Машина A 2| |3 Машина B
| |
____V__|____
| |
| |
| |
| |
|____________|
Машина C
Използвайки ARP spoofing за да направим man-in-the-middle attack, трябва да изпълним следните неща:
Първо трябва да разберем как A и B комуникират нормално.
За нормално протичаща комуникация A изисква MAC addess-а на B. За да го получи, ще провери в ARP cache-а си в случай, че
вече го има. Ако MAC address-ът на B се намира в ARP cache-а, A ще го използва. Ако MAC address-ът не се намира в ARP
cache-а, A ще изпрати ARP request. Машина B ще отговори с нейния MAC /и IP/ address. IP и MAC address-ът на B ще бъдат
запазени в ARP cache-а за бъдеща употреба.
Сега вече A може да комуникира с B. B ще извърши същата процедура за нормално протичане на комуникацията.
Приемаме, че A и B са осъществили връзка и обменят информация, минаваща през Switch-а.
Сега идва мястото на ARP spoofing-а.
Първата стъпка е да убедим A, че C всъщност е B. По този начин трафикът, предназначен за B, ще минава през C.
Но как може да стане това? Чрез "отравяне" /poisoning/ ARP cache-а на A.
ARP е протокол, за който не е нужна автентичност, т.е. всеки ARP packet, изпратен до който и да е host, ще предизвика
update на ARP cache-а.
C изпраща spoof-нат ARP packet към A, карайки A да изпраща предназначените за B packet-и на C. Чрез spoof-натия ARP packet
C принуждава A да update-не cache-а си. В update-натия ARP cache на IP address-а на B отговаря MAC adress-ът на C.
Това ще пренасочи трафика към компютър C. Ето какво би се случило:
ARP cache-ът на A ПРЕДИ получаването на spoof-натия ARP packet от C:
______________________________________________________________________
| IP address | MAC address |
|_________________________________|___________________________________|
| IP address-ът на B | MAC address-ът на B |
|_________________________________|___________________________________|
| IP address-ът на C | MAC address-ът на C |
|_________________________________|___________________________________|
| . . . | . . . |
|_________________________________|___________________________________|
ARP cache-ът на A СЛЕД получаването на spoof-натия ARP packet от C:
______________________________________________________________________
| IP address | MAC address |
|_________________________________|___________________________________|
| IP address-ът на B | MAC address-ът на C |
|_________________________________|___________________________________|
| IP address-ът на C | MAC address-ът на C |
|_________________________________|___________________________________|
| . . . | . . . |
|_________________________________|___________________________________|
C изпраща spoof-нат ARP packet и на машина B, за да смени MAC address-а на A в cache-а й със своя собствен MAC address.
Веднъж направено всичко това, packet-ите, които A изпраща за B, са route-нати към C; packet-ите, които B изпраща за A,
отново са route-нати към C. Attacker-ът ще трябва да "re-poison" ARP cache-овете периодично, защото операционната система
автоматично refresh-ва ARP cache-а през определено време /обикновено 30 секунди/.
Има още един важен детайл. Процесът може да бъде засечен чрез IP forwarding, поддържан от много операционни системи.
Много Switch-ове не поддържат "Port security" опция, позволяваща на Администратора да конфигурира кои машини могат да се
connect-нат към Switch-а. Тази опция позволява да се прекъсне връзката със Switch-а на машина с определен MAC address.
Port security не предотвратява ARP spoofing-а, защото тук става въпрос за отравяне на cache-овете на снифените машини.
Това не е нещо, което може да се избегне чрез Port security.
И нека едно малко допълнение към възможностите на man-in-the-middle attack-ата. Към прихванатия трафик могат да бъдат
добавени/изтрити/модифицирани packet-и. Това позволява hijack-ване на различни видове sessions, например telnet.
Могат да бъдат добавени команди от името на client-а или server-а в една telnet session.
Session hijack-ването не е само теоретична възможност. Снифери като ettercap например правят този процес реално приложим.
<@> Switch Jamming:
Някои Switch-ове могат да бъдат обърнати от "bridging mode" в "repeating mode", при който всички frame-ове се разпращат към
всички портове през цялото време. Този ефект може да се постигне чрез overflowing на address table-ите с голям брой фалшиви
MAC address-и. Overflowing-ът може да бъде предизвикан чрез постепенно увеличаващ се трафик или непрекъснато изпращане на
произволни packet-и към Switch-а.
<@> ICMP Redirect-ване:
ICMP Redirect-ването "казва" на машината да изпраща packet-ите в друга посока. Типичен пример е когато има две logical
subnets на същия physical segment. Машина А е на единия subnet, кореспондираща с машина B от другия subnet. Нито една от
двете машини не знае, че се намират на същия physical segment, но локалният router знае. Машина A изпраща packet
към router-а, предназначен за машина B. Тогава router-ът изпраща ICMP Redirect към A, информирайки, че всъщност A може
директно да изпраща packet-и към B. Нека присъединим още една машина - C. Тя може да промени горепосочения процес чрез
изпращане на ICMP Redirect към A, уведомявайки я, че може да изпраща packet-ите за B към C. По този начин packet-ите,
изпратени от A за B, ще бъдат насочени към машина C.
<@> ICMP Router Advertisements:
ICMP Router Advertisements информират машините в дадена мрежа кой е router-ът. Attacker може да изпрати packet-и,
деклариращ, че неговата машина е router-а. Така целият трафик ще минава през него. По-старите машини не поддържат
ICMP Router Advertisements. След като са уточнени тези детайли по въпросите със сигурността, много нови машини също не
ги поддържат.
<@> Fake-ване MAC address-а с този на "жертвата":
Идеята е Switch-ът да започне да изпраща към машина A frame-овете, предназначени за машина B. Това може да се постигне чрез
поддържането на активно изпращане на frame-ове с address-а на машина B. Switch-ът ще повярва, че машина A всъщност е B и
ще започне да изпраща frame-овете, предназначени за B на машина A. Проблемът тук е, че машина B ще продължи изпращането на
data със своя MAC address, което би върнало Switch-а към предишното състояние на пренасочване data-та към B. Друг проблем е,
че ако машина B не получи frame-а, комуникацията ще бъде преустановена и няма да има нищо, което да се снифи.
Има няколко решения на този проблем, в зависимост какво искаме да направим. Ако искаме да преустановим автентичната
комуникация, можем да принудим машина B да мине offline /чрез DoS например/ и да продължим комуникацията, все едно нищо не
се е случило. Друго решение например е изпращането на packet-и с MAC address-а на B на определени интервали от време.
В такъв случай A ще получи следващите няколко packet-а, предназначени за B, но B ще загуби връзка /timeout/ и ще
преустанови, вероятно и възобнови комуникацията. При поддържане на подобен процес, B ще забелязва от време на време
закъснения на packet-ите. Подобно решение е при прихващане на packet-а, предназначен за B, машина A да го препрати обратно.
По този начин B ще получи packet-а. Един стабилен поток би позволил успешно симулиране на оригиналния трафик към машина B.
<@> Hardware-ни устройства:
Те могат да бъдат поставени между Switch-а и въпросната машина, която искаме да снифим.
За повече информация:
www.NetOptics.com
www.Sniffer.com
www.google.com
________________________ ______________ ___________ _________ _____ ___ __ _ _ _ _ _ _ _ _
=8= Кои са най-често снифените протоколи /protocols/?
Следните протоколи са най-честно снифени, особено за пароли:
<@> Telnet и rlogin - Могат да бъдат прихванати точните клавишни комбинации, по начина, по който са въведени, включително
usernames и passwords.
<@> http - Много website-ове имат автентикация, при която usernames и passwords се изпращат в cleartext; data-та - cleartext.
<@> SNMP - Почти целия SNMP трафик е SNMPv1, слаб по отношение на сигурността. SNMP passwords - изпращат се в cleartext.
<@> NNTP - Паролите се изпращат в cleartext; data-та също.
<@> POP - Паролите се изпращат в cleartext; data-та също.
<@> FTP - Паролите се изпращат в cleartext; data-та също.
<@> IMAP - Паролите се изпращат в cleartext; data-та също.
Всички тези решения си имат и по-сигурни алтернативи. Когато става въпрос за информация, свързана с Credit Cards,
повечето сайтове използват SSL encryption вместо обикновен HTTP. S/MIME и PGP например могат да криптират e-mails на ниво,
по-високо от e-mail protocol-и като POP/IMAP/SMTP.
________________________ ______________ ___________ _________ _____ ___ __ _ _ _ _ _ _ _ _
=9= Как можем да засечем снифер?
Теоретично... е невъзможно да се засекат снифери, защото те са пасивни - само събират packet-и. Но на практика,
в повечето случаи е възможно сниферите да бъдат засечени. Самостоятелният снифер не изпраща packet-и, но несамостоятелно
инсталираният снифер на обикновен компютър често генерира трафик. Например, може да изпраща DNS reverse lookups за да
намери имена, асоциирани с IP address-и. Несамостоятелните снифери всъщност са тези, които бихме искали да засечем.
Когато attacker-и посягат на машини, те често инсталират sniffing programs. Как можем да ги засечем?
<@> ping методът:
Повечето снифери се инсталират на машини, поддържащи TCP/IP. Това означава, че ако изпратим request към тези машини, те
ще отговорят. Номерът е да изпратим на съмнителната машина request към реалния й IP address, но не към нейния
Ethernet adapter /към различен MAC address/.
Какво се получава:
Нека съмнителната машина - A, на която предполагаме, че е пуснат снифер, има IP address 10.0.0.1 и Ethernet address
/MAC address/ 00-41-7C-B4-56-02. Ние /машина B/ сме на същия Ethernet segment. Изменяме леко нашия MAC address, нека той
изглежда така:00-41-7C-B4-56-03. След това изпращаме ICMP Echo Request /ping/ с вече променения MAC address.
Никой в мрежата не би трябвало да види този packet, защото когато packet-ът минава по мрежата, всеки Ethernet adapter
сравнява MAC address-а с неговия собствен. Ако няма съвпадение, той игнорира frame-а. Ако нашата машина B получи отговор,
тогава съмнителната машина A не използва нейния филтър, следователно се намира в promiscuous mode и снифи трафика.
Има начини да се предотврати засичане чрез този метод. Някои attacker-и биха сложили виртуален MAC address filter.
Много машини /например под Windows/ имат MAC filtering в driver-ите.
Тази техника обикновено работи на мрежи, където се използва Switch. Когато Switch-ът види непознатия MAC address за пръв
път, той ще flood-не с frame-а всички segments.
Всъщност всеки protocol, който генерира response, може да бъде използван за засичане на снифера. Например TCP connection
request или UDP protocol като port 7 /echo/. Всеки protocol, който може да генерира грешка на съмнителната машина, може да
бъде използван. Например лоша стойност в IP header-а може да доведе до генериране на ICMP error.
<@> ARP методът:
ARP методът е подобен на ping метода, но при него се използва ARP packet. Най-лесният начин е да изпратим ARP на някой
non-broadcast address. Ако някоя машина отговори на този ARP packet, тогава тя се намира в promiscuous mode.
При някои варианти на тази техника се използва ARP cache-а. Когато изпратим един ARP packet на broadcast address, включваме
информация за нашите IP и MAC address-и. В такъв случай можем да изпратим ARP packet към non-broadcast, след това един
broadcast ping. Всеки, който отговори на нашия ping без да ни ARP-не, би знаел нашия MAC address от прихванатия ARP frame.
За да сме по-сигурни, препоръчвам използването на различни MAC address-и при ping-ването.
<@> DNS методът:
Както вече споменахме, много снифери правят автоматично reverse-DNS lookups на IP address-ите, които засичат. По този начин
сниферът може да бъде засечен чрез наблюдение на DNS трафика, който генерира.
Интересното е, че т. нар. "hacker-based sniffing programs" resolve-ват IP address-ите веднага, след като ги получат, докато
"commercial" програмите забавят resolve-ването докато потребителят види protocol-а декодиран.
<@> Source-route методът:
Това е друга техника, свързана с конфигурирането на source-route информация в IP header-а. Тя може да бъде използвана за
засичане на снифер на друг, близък segment.
Машина A създава ping packet към машина B, но слага loose source-route за да се препрати ping-а към машина C на същия segmet.
B не би трябвало да поддържа rooting, затова не би препратила packet-а към C. Ако машина A получи отговор от C, тогава на
C има снифер. При получен отговор е добре да се провери дали packet-ът е route-нат правилно или просто снифен.
Защо става така?
При loose source-routing една опция е добавена към IP header-а. Router-ите ще игнорират packet-а, но ще го препратят към
следващия IP address в source-route опцията. Това означава, че когато изпратим packet, казваме "моля, изпрати packet-а на
машина C, но го route-ни първо през машина B". По този начин машина B ще получи packet-а, но ще го drop-и, защото не
би трябвало да route-ва. Ако машина C отговори на ping-а, значи тя го е прихванала. Следва, че машина C е в promiscuous
mode, което означава, че на нея има инсталиран и работещ снифер. Има вероятност машина B наистина да route-ва. В такъв
случай може да бъде използван TTL field за да се провери дали C е отговорила на route-натия от B ping, или отговаря директно.
<@> Методът на примамката:
Докато ping и ARP методите работят само за локални мрежи, методът на примамката работи навсякъде.
Откакто има толкова много protocol-и, позволяващи cleartext passwords, има и хора, които се опитват да ги прихванат.
Методът се състои в създаването на client и server от двете страни на мрежата, като client-ът използва script за logon
в server-а чрез Telnet, POP, IMAP или някой plain-text protocol. Server-ът е конфигуриран със специални accounts,
които нямат истински права, или server-ът е напълно виртуален. След като attacker-ът прихване въпросните username и password,
той ще се опита да се log-не, използвайки информацията, която е получил чрез снифера. Системата на server-ът log-ва
attacker-а и съобщава, че има някой снифещ в мрежата.
<@> Host методът:
Когато attackers получат access до дадена система, те често оставят снифеща програма, инсталирана и стартирана за
прихващане на usernames и passwords. Тези програми често са прикрити /като троянски кон/ в други програми, затова
единственият начин да се намери подобна програма е да се провери дали машината е в promiscuous mode. Разбира се трябва да се
има в предвид, че вероятно attacker-ът е помислил за "ifconfig -a" и се е погрижил да скрие данните за promiscuous mode.
Има различен software, който може да провери hardware-а директно, или можем да стартираме ifconfig program-ата директно от
CD-ROM дистрибуция.
<@> Latency методът:
Този метод е по-драстичен. Използват го зли Админи
)) От една страна тази техника може значително да затрудни работата намрежата. От друга страна може да "заслепи" сниферите чрез изпращането на прекалено много трафик.
Идеята тук е да се създаде голям мрежов трафик. Той не би засегнал машините в non-promiscuous mode, но би имал силен ефект
върху снифещите машини. Просто ping-ваме машините преди натоварването на мрежовия трафик и по време на самото натоварване и
тестването на разликата в необходимото за respone време може да индикира ако една машина е прекалено натоварена.
Съществува един проблем при тази техника. Packet-ите могат да закъснеят просто защото натоватването в мрежата е прекалено
голямо, което би коствало timeout-и и фалшиви тревоги. От друга страна, много снифери работят в "user mode", докато
ping-овете протичат в "kernel mode". Тогава независимостта на CPU ще предотврати прекаленото натоварване.
<@> TDR /Time-Domain Reflectometers/:
TDR представляват своеобразни радари за мрежа. Те изпращат сигнали по мрежата, които се връщат и правят графика. По тази
графика се следи дали има някое устройство, което не би трябвало да е свързано към мрежата. Те могат да локализират с
приблизителна точност къде се намира сниферът. TDR могат да локализират и hardware-ни снифери, които са напълно "невидими".
TDR са използвани в миналото за локализиране на снифещи устройства, но в днешно време ма мрежи със star topologies,
те се използват изключително рядко.
Съществува също и OTDR equipment, но това е за прекалено болните параноици
<@> Светлините на Hub-а:
Може ръчно да се проверят светлинките на Hub-а за да се види дали има неочаквани connections. Това дава представа за
кабелите, където може да се намира физически даден снифер.
<@> SNMP monitoring:
По-умничките Hub-ове с SNMP management могат да предоставят автоматично monitoring на Ethernet /и други/ Hub-ове. Някои
management console-и могат да log-ват connect-ването и disconnect-ването към всички port-ове. Ако сме конфигурирали
системата с информация за всички кабели, понякога можем да засечем къде вероятно се крие снифер.
________________________ ______________ ___________ _________ _____ ___ __ _ _ _ _ _ _ _ _
=10= Как да се предпазим от снифене?
Това, което бих Ви препоръчала, е едно стабилно криптиране /encryption/. Ето няколко примера:
<@> SSL /Secure Sockets Layer/:
SSL е вграден във всички популярни web browser-и и web server-и. То позволява криптирано сърфиране в Internet и почти
винаги е използвано в e-commerce когато user-ите дават информация за техните Credit cards.
<@> PGP и S/MIME:
E-mail-ите могат да бъдат снифени по много алтернативни начини. Те минават през корпоративни firewall-и, които могат да
правят monitoring на трафика. Често той се log-ва и се пази за определен период от време. Може случайно да се получи грешка
при direct-ването и да попадне в чужда mailbox. Най-добрият начин да предпазим важни e-mails е да ги криптираме. Два от
основните начини са с PGP /Pretty Good Privacy/ и S/MIME - /Secure MIME/. PGP може да се добави към много продукти. S/MIME
е built-in в e-mail program-и от Netscape и Microsoft.
<@> ssh /Secure Shell/:
ssh е станал дефакто стандарт за log-ване в UNIX машини от Internet. Препоръчвам използването на този
service вместо Telnet. Редица други protocol-и могат да бъдат достъпни чрез ssh. Продуктът е развит от Finish company
http://www.ssh.fi/ , но съществува и във вид на доста open-source/freeware продукти.
<@> VPNs /Virtual Private Networks/:
VPNs осигуряват криптиран трафик през Internet. Но ако attacker-и се "погрижат" за end-nodes на VPN connection-а, те все още
могат да снифят трафика. Типичният сценарий е един end-user, който сърфира в Internet нормално, но е заразен с троянски кон,
съдържащ sniffing plug-in. Когато user-ът установи VPN connection-а, сниферът е способен не само да прихваща криптирания
трафик, който може да се види в Internet, но също и некриптирания трафик преди да бъде изпратен през stack-а на VPN-а.
________________________ ______________ ___________ _________ _____ ___ __ _ _ _ _ _ _ _ _
=11= От къде да намеря снифер за моето PC?
------------------------------------ Windows ------------------------------------
.::Ethereal::.
Ethereal е UNIX-based program-а, достъпна и за Windows /което означава, че инсталацията е малко по-трудна/.
Това вероятно е най-добрият freeware избор за Windows.
Сниферът бива в две версии: read-only /protocol analyzer/ версия, добра колкото capture (sniffing) версията. Read-only
версията е чудесна за декодиране на прихванати packet-и. Избягва проблемът с инсталацията на packet capture driver.
http://www.ethereal....ribution/win32/
.::WinDump::.
http://windump.polito.it/
.::WinNT Server::.
WinNT Server-ът на Microsoft има вградена програма, наречена "Network Monitor". Отидете в Networking control panel,
изберете "Services" tab, после "Add..." и изберете "Network Monitor Tools and Agent". Веднъж инсталирана, можете да я
стартирате от Program menu-то под "Administrative Tools".
.::BlackICE Pro::.
BlackICE засича смущаване в системата, има възможност за log-ване във формат, който може да бъде декодиран чрез
protocol analyzers. Това може да бъде по-полезно от използването на снифер с по-широко приложение когато става въпрос
за security. Програмата поддържа машината в non-promiscuous mode, което позволява единствено снифене на трафика към и от
машината.
http://www.networkice.com/
.::CiAll::.
Това е програма, която може само да декодира. Прекрасно решение за програми като BlackICE, които само log-ват packet-и, но
не притежават вградени декодери. Програмата е shareware за 90 дни.
!!!Забележка!!! - Съществуват съмнения за вграден троянец в CiAll.
http://www.winsite.c...fo?500000005196
.::Analyzer::.
Това е toolkit за различни видове анализи.
http://netgroup-serv...to.it/analyzer/
.::Sniff-em::.
Този снифер не генерира трафик, което затруднява засичането му. Това е единственият снифер, който поддържа Dialup adapter-и
за Windows 2000 и Windows XP. Подходящ за Windows 95(abc),98(SE),ME,NT4,2000 и XP.
http://www.sniff-em.com/download.shtml
Няма коментари:
Публикуване на коментар