информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Атака на InternetСетевые кракеры и правда о деле ЛевинаСтрашный баг в Windows
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / networking
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Стрелки здесь переводят конкретно ! :))) 25.05.01 07:05  Число просмотров: 1439
Автор: AAT Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Во, почитай ответ Роберта Грэхема (Robert Graham)... может и пригодится что :))) Удачи !


"3.8 How can I sniff a switched network?

In theory, you cannot sniff a switched network. All that the sniffing would do would be to see your own traffic anyway. In practice, there are numerous ways.

3.8.1 Switch Jamming
Some switches can be kicked out of "bridging" mode into "repeating" mode where all frames are broadcast on all ports all the time. This is done by overflowing the address tables with lots of false MAC addresses. This can be done with a simple traffic generation phase, or by sending a continual stream of random garbage through the switch. In security terms, this is known as "fail open" behavior rather than "fail close", meaning that when the device fails, security provisions are removed. Of course, switches aren't really designed with security in mind.
See the HUNT Project at http://www.cri.cz/kra/index.html for more info.

3.8.2 ARP Redirect
ARP packets contain both the local binding as well as the desired binding. For example, let's say that Alice wants to find Bob's Ethernet MAC address. Bob has an IP address of "192.0.2.1". Alice would send out an ARP request with the following information. Operation: Request
Alice: 192.0.2.173 00-40-05-A4-79-32
Bob: 192.0.2.1 ?? ?? ?? ?? ?? ??
The entire exchange might looke like the diagram below. Alice has an IP packet of some sort (let's say an ICMP ping) to send to Bob. In order to find Bob's MAC address, Alice ARPs it. Bob responds to Alice, telling her his MAC address. Now Alice sends her IP packet to that Ethernet MAC address.
Alice ----> ARP broadcast request ----> Bob
Alice <---- ARP unicast response <---- Bob
Alice ----> ICMP ping request ----> Bob

Alice <---- ICMP ping response <---- Bob
Alice <---- ICMP ping request <---- Charles

Now Bob has an IP packet to send to Alice. In theory, Bob would need to ARP Alice in order to find her MAC address. But he doesn't. This is because he has remembered her MAC address information that was sent in the original ARP request.
In fact, everyone on the local Ethernet saw that request since it was broadcasted. So if Charles at this point wants to ping Alice, he doesn't need to ARP her either, even though he wasn't involved with the original exchange.

Broadcasts are sent to everyone on an Ethernet switch. Therefore, you can subvert the switch by sending out ARPs claiming to be somebody else as the source address. You can broadcast out an ARP claiming to be the router, in which case everyone will try to route through you. Or you can send an ARP request just to the victim's MAC address, claiming to be the router, at which point just the victim will forward packets to you. Conversely, you can send an ARP to the router's MAC address claiming to be the victim.

In all these cases, you must be prepared to forward packets in the real direction, otherwise you cut off communication.

See http://www.zweknu.org/src/MiM/ for some sample programs.

3.8.3 ICMP Redirect
An ICMP redirect tells a machine to send its packets in a different direction. A typical example is when there are two logical subnets on the same physical segment. Alice is on one subnet talking to Bob on another subnet. Neither knows they are on the same physical segment, but the local router knows. When Alice sends the router a packet destined for Bob, the router sends an ICMP Redirect to Alice informing here of the fact that she can send the packet to Bob directly.
A hacker (Mark) can subvert this by sending a redirect to Alice claiming that she should send him Bob's packets.

3.8.4 ICMP Router Advertisements
ICMP Router Advertisements inform people who the router is. A hacker can send these packets out claiming to be a router; people will believe them and start forwarding their traffic through that person.
Luckily, many machines don't support this feature because it is relatively new. Now that the security implications are well known, many new systems still won't support it.

See http://www.l0pht.com/advisories/rdp.txt for more information.

3.8.5 Fake the MAC address of the victim
The idea is to cause the switch to start fowarding you the frames destined to the victim. You can do this simply by sending out frames with the source address of the victim. The "auto-learning" feature of the switch will now believe you are the victim, and send frames your way.
The obvious problem is that victim itself will still send out frames with its MAC address (cuasing the switch to revert). Another problem is that if the victim doesn't receive the frame, then its communications breaks, and there won't be anything more to sniff.

There are a few solutions to this problem, depending upon what you want to do. You may want to subvert an authenticated connection, in which case you DoS the victim (taking it offline), redirect the switch, and continue on with the connection as if nothing happened. For example, let's say that Alice has a Telnet connection to the BOB server. You DoS Alice's machine, taking her off line. You then send out packets with Alice's MAC address, causing the switch to send you all packets destined for her. In order to pick up her connection, you cause the server to send you a TCP packet (i.e. use the talk service to prompt her for a connection). At this point, you simply start reversing the sequence and acknowledgement numbers to continue the Telnet connection.

Another solution to this problem is to "sample" traffic. Send out packets with the victim's MAC on occasional intervals. You'll likely get the next few packets destined for the victim, but the victim will timeout and recover the connection. The victimized user will notice occasional network delays.

A similar solution is that when you receive an incoming packet, turn around and broadcast it back out. This way the victim still receives the packet. A steady stream of outgong traffic and broadcasts of the incoming traffic will allow you to recover a good percentage of the original traffic.

3.8.6 Reconfigure span/monitor port on switch
Most switches allow ports to be configured as "monitor" or "span" ports that will copy some or all of the traffic going across the switch. In fact, these ports are designed for packet sniffers when the network administrator needs to solve a problem.
In many cases, a hacker can telnet to the switch or reconfigure it with SNMP. Most switches are installed with default or backdoor passwords.

SNMP is particularly fun because the hacker can 'grind' through all the passwords until he/she finds the correct one (though most come default with "public" or "private"). In some cases, the network admin configures the switch to only allow SNMP from the IP address of the network management console. However, this same network management console will likely be sending other SNMP packets about: sniffing broadcasts or just incoming SNMP directed at the host will likely reveal who the SNMP management console is, at which point IP spoofing can be used to manage the switch. Similarly DNS Zone Transfers might reveal suggestive names such as "hpov.example.com" (hpov = HP OpenView, a popular SNMP console).

3.8.7 Cable-taps
You can tap into full-duplex Ethernet cable. A couple vendors make products that do this for you. Some features of these products are:
Your packet sniffer needs two Ethernet adapters to receive the send/receive channels. Most products support sniffing from only a single adapter at a time, which means you can only sniff from one channel at a time.
All the products I know are fault tolerant, which means that if the power fails on the box, they will not interupt the flow of traffic.
Of course, you caa always tap into cables between switches or between an important host and a switch. Vendors of cable-taps are:
www.Shomiti.com
The "Century Tap" family is used for this purpose. The basic tap works as described above. They also have a fiber-optic tap. Finally, they have a 12-port tap that allows roving analysis on twelve full-duplex lines.
www.NetOptics.com
They not only have the basic tap, but also one that support fiber-optics as well. Since they don't make their own protocol analyzer, they resell their products for other packet sniffer companies.
www.Sniffer.com
Rather than a passive tap described above, they have a full "pod" that does packet capture and filtering on the unit itself. It contains several Ethernet chips, CPUs, and memory."
<networking>
Какой снифер можно использовать... 24.05.01 18:17  
Автор: Yikxx Статус: Незарегистрированный пользователь
<"чистая" ссылка>
... чтобы перехватывать пакеты не только в локалке?
Или это в принципе невозможно?
Стрелки здесь переводят конкретно ! :))) 25.05.01 07:05  
Автор: AAT Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Во, почитай ответ Роберта Грэхема (Robert Graham)... может и пригодится что :))) Удачи !


"3.8 How can I sniff a switched network?

In theory, you cannot sniff a switched network. All that the sniffing would do would be to see your own traffic anyway. In practice, there are numerous ways.

3.8.1 Switch Jamming
Some switches can be kicked out of "bridging" mode into "repeating" mode where all frames are broadcast on all ports all the time. This is done by overflowing the address tables with lots of false MAC addresses. This can be done with a simple traffic generation phase, or by sending a continual stream of random garbage through the switch. In security terms, this is known as "fail open" behavior rather than "fail close", meaning that when the device fails, security provisions are removed. Of course, switches aren't really designed with security in mind.
See the HUNT Project at http://www.cri.cz/kra/index.html for more info.

3.8.2 ARP Redirect
ARP packets contain both the local binding as well as the desired binding. For example, let's say that Alice wants to find Bob's Ethernet MAC address. Bob has an IP address of "192.0.2.1". Alice would send out an ARP request with the following information. Operation: Request
Alice: 192.0.2.173 00-40-05-A4-79-32
Bob: 192.0.2.1 ?? ?? ?? ?? ?? ??
The entire exchange might looke like the diagram below. Alice has an IP packet of some sort (let's say an ICMP ping) to send to Bob. In order to find Bob's MAC address, Alice ARPs it. Bob responds to Alice, telling her his MAC address. Now Alice sends her IP packet to that Ethernet MAC address.
Alice ----> ARP broadcast request ----> Bob
Alice <---- ARP unicast response <---- Bob
Alice ----> ICMP ping request ----> Bob

Alice <---- ICMP ping response <---- Bob
Alice <---- ICMP ping request <---- Charles

Now Bob has an IP packet to send to Alice. In theory, Bob would need to ARP Alice in order to find her MAC address. But he doesn't. This is because he has remembered her MAC address information that was sent in the original ARP request.
In fact, everyone on the local Ethernet saw that request since it was broadcasted. So if Charles at this point wants to ping Alice, he doesn't need to ARP her either, even though he wasn't involved with the original exchange.

Broadcasts are sent to everyone on an Ethernet switch. Therefore, you can subvert the switch by sending out ARPs claiming to be somebody else as the source address. You can broadcast out an ARP claiming to be the router, in which case everyone will try to route through you. Or you can send an ARP request just to the victim's MAC address, claiming to be the router, at which point just the victim will forward packets to you. Conversely, you can send an ARP to the router's MAC address claiming to be the victim.

In all these cases, you must be prepared to forward packets in the real direction, otherwise you cut off communication.

See http://www.zweknu.org/src/MiM/ for some sample programs.

3.8.3 ICMP Redirect
An ICMP redirect tells a machine to send its packets in a different direction. A typical example is when there are two logical subnets on the same physical segment. Alice is on one subnet talking to Bob on another subnet. Neither knows they are on the same physical segment, but the local router knows. When Alice sends the router a packet destined for Bob, the router sends an ICMP Redirect to Alice informing here of the fact that she can send the packet to Bob directly.
A hacker (Mark) can subvert this by sending a redirect to Alice claiming that she should send him Bob's packets.

3.8.4 ICMP Router Advertisements
ICMP Router Advertisements inform people who the router is. A hacker can send these packets out claiming to be a router; people will believe them and start forwarding their traffic through that person.
Luckily, many machines don't support this feature because it is relatively new. Now that the security implications are well known, many new systems still won't support it.

See http://www.l0pht.com/advisories/rdp.txt for more information.

3.8.5 Fake the MAC address of the victim
The idea is to cause the switch to start fowarding you the frames destined to the victim. You can do this simply by sending out frames with the source address of the victim. The "auto-learning" feature of the switch will now believe you are the victim, and send frames your way.
The obvious problem is that victim itself will still send out frames with its MAC address (cuasing the switch to revert). Another problem is that if the victim doesn't receive the frame, then its communications breaks, and there won't be anything more to sniff.

There are a few solutions to this problem, depending upon what you want to do. You may want to subvert an authenticated connection, in which case you DoS the victim (taking it offline), redirect the switch, and continue on with the connection as if nothing happened. For example, let's say that Alice has a Telnet connection to the BOB server. You DoS Alice's machine, taking her off line. You then send out packets with Alice's MAC address, causing the switch to send you all packets destined for her. In order to pick up her connection, you cause the server to send you a TCP packet (i.e. use the talk service to prompt her for a connection). At this point, you simply start reversing the sequence and acknowledgement numbers to continue the Telnet connection.

Another solution to this problem is to "sample" traffic. Send out packets with the victim's MAC on occasional intervals. You'll likely get the next few packets destined for the victim, but the victim will timeout and recover the connection. The victimized user will notice occasional network delays.

A similar solution is that when you receive an incoming packet, turn around and broadcast it back out. This way the victim still receives the packet. A steady stream of outgong traffic and broadcasts of the incoming traffic will allow you to recover a good percentage of the original traffic.

3.8.6 Reconfigure span/monitor port on switch
Most switches allow ports to be configured as "monitor" or "span" ports that will copy some or all of the traffic going across the switch. In fact, these ports are designed for packet sniffers when the network administrator needs to solve a problem.
In many cases, a hacker can telnet to the switch or reconfigure it with SNMP. Most switches are installed with default or backdoor passwords.

SNMP is particularly fun because the hacker can 'grind' through all the passwords until he/she finds the correct one (though most come default with "public" or "private"). In some cases, the network admin configures the switch to only allow SNMP from the IP address of the network management console. However, this same network management console will likely be sending other SNMP packets about: sniffing broadcasts or just incoming SNMP directed at the host will likely reveal who the SNMP management console is, at which point IP spoofing can be used to manage the switch. Similarly DNS Zone Transfers might reveal suggestive names such as "hpov.example.com" (hpov = HP OpenView, a popular SNMP console).

3.8.7 Cable-taps
You can tap into full-duplex Ethernet cable. A couple vendors make products that do this for you. Some features of these products are:
Your packet sniffer needs two Ethernet adapters to receive the send/receive channels. Most products support sniffing from only a single adapter at a time, which means you can only sniff from one channel at a time.
All the products I know are fault tolerant, which means that if the power fails on the box, they will not interupt the flow of traffic.
Of course, you caa always tap into cables between switches or between an important host and a switch. Vendors of cable-taps are:
www.Shomiti.com
The "Century Tap" family is used for this purpose. The basic tap works as described above. They also have a fiber-optic tap. Finally, they have a 12-port tap that allows roving analysis on twelve full-duplex lines.
www.NetOptics.com
They not only have the basic tap, but also one that support fiber-optics as well. Since they don't make their own protocol analyzer, they resell their products for other packet sniffer companies.
www.Sniffer.com
Rather than a passive tap described above, they have a full "pod" that does packet capture and filtering on the unit itself. It contains several Ethernet chips, CPUs, and memory."
дык это уже не снифинг а более сложные поделия с редиректом ...причем все они активного плана 25.05.01 18:31  
Автор: XR <eXtremal Research> Статус: The Elderman
<"чистая" ссылка>
дык это уже не снифинг а более сложные поделия с редиректом ...причем все они активного плана 26.05.01 14:02  
Автор: Yikxx Статус: Незарегистрированный пользователь
<"чистая" ссылка>
А поподробнее можно?
<без заголовка> 26.05.01 14:44  
Автор: XR <eXtremal Research> Статус: The Elderman
<"чистая" ссылка>
> А поподробнее можно?
Можно ... хотя в цитате основные способы были расказаны.

Фокус в том что оБщая среда передачи в случае комутатора (свитча)
упрятана в сам это свитч и до сетевых карточек не доходит (функциональность по
фильтрации MAC-ов вынесена в свитч) - по идее некоторые свитчи позволяют
запустить один из портов в promiscuous режиме и вылавливать все пакеты ...
но это привилегия администраторов ... простой юзер может сыграть
на механизмах автоматического определения MAC адреса свитчем (сбор статистики)
Если MAC адреса прописаны на портах свитча жестко то задача сильно усложняется ...

собственно на этом и основаны HUNT и dsniff - наиболее продвинутые поделия на эту тему. Они используют ARP-spoofing для введения свитча в заблуждение ...

ICMP redirect же сейчас игнорируется большинством современных осей...

Но это опять же относительно небольшая ниша свитчей...что по сути та же
среда передачи что и обычный Ethernet

Подпобности механизмов есть в документации и исходниках

ссылки:
http://www.monkey.org/~dugsong/dsniff/beta/ dsniff
http://lin.fsid.cvut.cz/~kra/index.html#HUNT HUNT

<без заголовка> 28.05.01 08:38  
Автор: Yikxx Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> > А поподробнее можно?

> Подпобности механизмов есть в документации и исходниках
>
> ссылки:
> http://www.monkey.org/~dugsong/dsniff/beta/ dsniff
> http://lin.fsid.cvut.cz/~kra/index.html#HUNT HUNT
>
Так там же все под Линух. Нафига мне это :(
<без заголовка> 28.05.01 11:28  
Автор: XR <eXtremal Research> Статус: The Elderman
<"чистая" ссылка>
> > > А поподробнее можно?
>
> > Подпобности механизмов есть в документации и
> исходниках
> >
> > ссылки:
> > http://www.monkey.org/~dugsong/dsniff/beta/ dsniff
> > http://lin.fsid.cvut.cz/~kra/index.html#HUNT HUNT
> >
> Так там же все под Линух. Нафига мне это :(

Дык отпортируй для другой платформы :) )Win/Lib)pcap в руки и вперед :)


hint: R&D в этой области в последние года 3 идут исключительно на Linux
а портирование на другие платформы это уж по необходимости ... которой видимо нет пока ...
<без заголовка> 28.05.01 15:09  
Автор: Yikxx Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> Дык отпортируй для другой платформы :) )Win/Lib)pcap в руки
> и вперед :)
>
>
> hint: R&D в этой области в последние года 3 идут
> исключительно на Linux
> а портирование на другие платформы это уж по необходимости
> ... которой видимо нет пока ...

Хм. Странно что нет.
Ну что ж, теперь осталось только машину с Линухом найти и человека в этом понимающего :)

Кстати, почему так много смайликов?
<без заголовка> 28.05.01 15:57  
Автор: XR <eXtremal Research> Статус: The Elderman
<"чистая" ссылка>

> Хм. Странно что нет.

Ничего странного, любая васококвалифицированная работа должна либо хорошо
оплачиваться, либо иметь хорошую перспективу в плане ее дальнейшего развития
т.н. "заделы" - которые в перспективевозможномогут быть конвертированы в $$ а возможно станут базой для дальнейших R&D) Win движется первым способом Linux вторым ... и как выясняется $$ на все не хватает :)

> Ну что ж, теперь осталось только машину с Линухом найти и
> человека в этом понимающего :)
>
> Кстати, почему так много смайликов?
Слишком сильное несоответствие задач и средств :)... ну если по простому что то
типа желания "участвовать в гонках F1 на девятке"
в общем случае это невозможно, сниффер могет работать только в средах с общим доступом к каналу a.k.a CSMA/CD 24.05.01 18:31  
Автор: XR <eXtremal Research> Статус: The Elderman
<"чистая" ссылка>
Уточнение 25.05.01 00:36  
Автор: :-) <:-)> Статус: Elderman
<"чистая" ссылка>
Ну CSMA/CD - тут ни причем, это только метод доступа к разделяемой среде.
Технологии ArcNet и Token Ring например его не применяют - но ведь от этого ничего не меняется - адаптеры Token Ring могут работать в promiscuous mode, и снифиинг на них так же возможен.
И на ArcNet наверное тоже были снифферы? (хотя не уверен - я ArcNet никогда не видел)
Еще Уточнение 25.05.01 18:27  
Автор: XR <eXtremal Research> Статус: The Elderman
<"чистая" ссылка>
> Ну CSMA/CD - тут ни причем, это только метод доступа к
> разделяемой среде.

там вместо a.k.a должно было стоять e.g.
Это я отвлекся и вышла очепятка :)

> Технологии ArcNet и Token Ring например его не применяют -
> но ведь от этого ничего не меняется - адаптеры Token Ring
> могут работать в promiscuous mode, и снифиинг на них так же
> возможен.

Главное чтоб был общий канал передачи а как там будут разрешаться коллизии
это фиолетово - eth был взят чисто для "примера" a.k.a "e.g." ;)
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach