| 0
- 07.02.2013 - 14:14
|
Пока рекомендуют отрубить UPnP http://habrahabr.ru/post/168613/      | | |
| 1
- 07.02.2013 - 14:21
|
Это несколько из другой оперы, но что бы не плодить тем: «Пакет смерти» для сетевых карт Intel http://habrahabr.ru/post/168607/ | | |
| 2
- 07.02.2013 - 15:40
|
у меня этих карт около 30, почти 20 торчит в интернет, не помню чтобы помирали вчера было обновление ядра | | |
| 3
- 07.02.2013 - 15:44
| развеселая инфа | | |
| 4
- 07.02.2013 - 16:01
| OpenWRT на последнем транке [*****]) | | |
| 5
- 07.02.2013 - 16:01
| to2 если они построены на базе контроллера 82574L, то проблема в них теоретически должна быть. Там же есть даже пакет для тестов ;) | | |
| 6
- 07.02.2013 - 16:36
|
да какой нахрен пакет для тестов) нужное значение по нужному смещению, и все вечером проверю, как народ из офисов разбредется | | |
| 7
- 07.02.2013 - 16:40
|
проверил и получил отчет: Congratulations! Your router did not respond to a UPnP discovery request. обычный зухель кинетик | | |
| 8
- 07.02.2013 - 16:48
| to7 а upnp у него включен в настройках? | | |
| 9
- 07.02.2013 - 19:38
|
на принимающей стороне # lspci -n|grep 8086:10d3 03:00.0 0200: 8086:10d3 04:00.0 0200: 8086:10d3 на передающей # nping -c1 --tcp -p 24 --data-string 222....222 target.host на принимающей # tcpdump -nnX -i ppp0 port 24 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes 20:30:36.039038 IP so.u.r.se.52124 > de.sti.nat.ion.24: Flags [S], seq 3220508356:3220509483, win 1480, length 1127 0x0000: 4568 048f a83b 0000 3606 da4d 5571 33c0 Eh...;..6..MUq3. 0x0010: 50ea 235d cb9c 0018 bff5 0ec4 0000 0000 P.#]............ 0x0020: 5002 05c8 4133 0000 3333 3333 3333 3333 P...A3..33333333 0x0030: 3333 3333 3333 3333 3333 3333 3333 3333 3333333333333333 .... 0x0460: 3333 3333 3333 3333 3333 3333 3333 3333 3333333333333333 0x0470: 3333 3333 3333 3333 3333 3333 3333 3333 3333333333333333 0x0480: 3333 3333 3333 3333 3333 3333 3333 33 333333333333333 никто не умер, пробовал 032h, результат тот же | | |
| 10
- 07.02.2013 - 19:53
|
а, ну да, мух центось 6.3, ядро вчерашнее 2.6.32-279.22.1.el6 версия модуля e100e 1.9.5-k, совпадает с версией модуля в предыдущем 2.6.32-279.19.1.el6 | | |
| 11
- 07.02.2013 - 19:54
| очепятка, e100e=e1000e | | |
| 12
- 07.02.2013 - 19:57
| «Пакет смерти» срабатывает под любыми ОС, независимо от настроек файрвола, если только файрвол не блокирует на уровне OSI 2/3. а вот это уже смешно | | |
| 13
- 07.02.2013 - 20:42
| нужно по делам съездить, вернусь - проверим без файрвол на уровне OSI 2/3 ) | | |
| 14
- 07.02.2013 - 23:07
|
разрешил во входящих tcp 24, теперь на принимающей стороне так: 00:05:05.568043 IP x.x.x.x.52718 > y.y.y.y.24: Flags [S], seq 827757046:827758173, win 1480, length 1127 ... 0x0400: 3333 3333 3333 3333 3333 3333 3333 3333 3333333333333333 0x0410: 3333 3333 3333 3333 3333 3333 3333 3333 3333333333333333 0x0420: 3333 3333 3333 3333 3333 3333 3333 3333 3333333333333333 0x0430: 3333 3333 3333 3333 3333 3333 3333 3333 3333333333333333 0x0440: 3333 3333 3333 3333 3333 3333 3333 3333 3333333333333333 0x0450: 3333 3333 3333 3333 3333 3333 3333 3333 3333333333333333 0x0460: 3333 3333 3333 3333 3333 3333 3333 3333 3333333333333333 0x0470: 3333 3333 3333 3333 3333 3333 3333 3333 3333333333333333 0x0480: 3333 3333 3333 3333 3333 3333 3333 33 333333333333333 00:05:05.568071 IP y.y.y.y.24 > x.x.x.x.52718: Flags [R.], seq 0, ack 827758174, win 0, length 0 и никто не умер, что за возня на хабре, непонятно | | |
| 15
- 07.02.2013 - 23:25
|
ага, похоже на хабре водятся разумные люди) Т.е. один конкретный байт из середины пакета должен содержать одно из двух значений в пределах 256-и доступных для байта. По статистике, в среднем каждый 128-й пакет будет таким. У меня вот на большинстве интерфейсов pps исчисляется минимум десятками тысяч пакетов в секунду, вовсе не маленьких. В общем, похоже на утку, расчитанную на идиотов, которые сходу внедрят соответствующее правило IPS и найдут массу проблем на свою жопу. короче, вброс незасчитан 5-TVV1 > садись, 2! | | |
| 16
- 07.02.2013 - 23:39
|
Я таки соглашусь что вброс какой то слабый получился. Тут либо это фейк либо дело далеко не в одном байте это в принципе то ясно ;) Да и с upnp тоже фигня какая то. Специально разрешил upnp на роутере и запустил тот тест. Тест сказал что все зашибись. Может надо еще upnp в системе разрешить, а то он у меня там то же вырублен. Короче хабар нынче не тотрт. | | |
| 17
- 07.02.2013 - 23:58
|
to15 вот мне стало интересно про этот пакет и полез я в первоисточник и что то он от того что напереводили несколько отличается как тестировать (там есть и пакеты а не просто пакет забитый 2 или 3) http://www.kriskinc.com/intel-pod а вот еще один пакет https://www.cloudshark.org/captures/944a3224514e | | |
| 18
- 08.02.2013 - 00:08
| 17+ да и еще там http://www.kriskinc.com/intel-pod приводят отличия eeprom для карточек подверженных этим фокусам, т.е. наличие определенного контролера еще не гарантирует проблемы | | |
| 19
- 08.02.2013 - 00:13
|
17-TVV1 > а ты сам по этим ссылкам ходил? вторая открылась минут через 5, а первая так и висит пустая ретранслятором подрабатываешь? | | |
| 20
- 08.02.2013 - 00:15
|
а теми пакетами, которые в оригинале http://www.kriskinc.com/intel-pod (внизу страницы) кто-нить пробовал ? я ток в пнд смогу похоже... 4-droidman > а чего там в последнем ? да и потом в транке исправят быстро ) | | |
| 21
- 08.02.2013 - 00:16
| ну у меня пропала одна из сетевок - Intel(R) 82579LM на рабочке, вторую видно, есть подозрение, что мну троллят коллеги таким незатейливым способом , в пнд узнаю наверняка ) | | |
| 22
- 08.02.2013 - 00:16
|
ходил обе открываются влет, вот текст из первой http://www.kriskinc.com/intel-pod Цитата:
pod-http-post.pcap (1k) http://www.kriskinc.com/intel-pod/po...edirects=0&d=1 pod-icmp-ping.pcap (1k) http://www.kriskinc.com/intel-pod/po...edirects=0&d=1 | | |
| 23
- 08.02.2013 - 00:17
|
ага, первая таки открылась, и вот что там пишут For this simplified test you'll need two machines (one to replay the packet and one to receive it) and you'll need to be on the same ethernet segment. No routers or VLAN aware switches should be in the mix (but dumb switches/hubs should be fine). | | |
| 24
- 08.02.2013 - 00:20
|
для масс-ретрансляторов выдержка ou'll need two machines and you'll need to be on the same ethernet segment. | | |
| 25
- 08.02.2013 - 00:22
| ну и далее по тексту разжевано, для тех кто не понял про сегмент) | | |
| 26
- 08.02.2013 - 00:32
|
to25 раз уж поставили двойку, то можно и потупить :) мне кажется что такие ограничения могут быть связаны с использованием tcpreplay и выложенными pcap файлами. | | |
| 27
- 08.02.2013 - 00:49
|
тогда больше смахивает на фиксированое смещение в кадре ethernet, что выглядит уже более похожим на правду это проверить не смогу, к сожалению, ибо все эти красавцы далеко от меня, не в сегменте ) | | |
| 28
- 08.02.2013 - 10:06
|
сегодня почитал вимательнее смещение 47fh от начала кадра, не от начала ip, но все равно, в моем пакете нужный байт был на месте опять же после, "смертельного" пакета, согласно хабровской статье, стек успевал отвечать, т.е. по идее виноват не ресивер, и еще непонятный экивок на фиьтрацию на уровне OSI 2/3, совсем ни в какие ворота сегодня-завтра, в удаленном офисе обещали организовать хост с такой картой, попробую пристрелить еще раз, теперь уже с соблюдением всех условий | | |
| 29
- 08.02.2013 - 12:05
| to28 Еще раз пакет должен быть с определенным содержимым - тем что у автора, а на хабаре что то наколхозили с переводом вот оригинал http://blog.krisk.org/2013/02/packets-of-death.html | | |
| 30
- 08.02.2013 - 12:35
|
вот в оригинале пишут you could easily configure an HTTP 200 response to contain the packet of death - and kill client machines behind firewalls! что противоречит требованию о едином сегменте из ссылки с пакетами посмотрим | | |
| 31
- 08.02.2013 - 14:04
|
8-TVV1 >а как же. Код: Домашняя сеть - UPnP - Разрешить UPnP (галка стоит) | | |
| 32
- 08.02.2013 - 17:27
|
не получилось, карта 8086:10d3, eeprom отличается и от гуд и от бэд 0x0010: ff ff ff ff 6b 02 00 00 86 80 d3 10 ff ff 5a c0 bad 01 01 ff ff 6b 02 d3 10 d9 15 d3 10 ff ff 58 85 good 69 e4 05 81 6b 02 1f a0 86 80 d3 10 ff ff 58 9c мой 0x0030: c9 6c 50 31 3e 07 0b 46 84 2d 40 01 00 f0 06 07 bad c9 6c 50 21 3e 07 0b 46 84 2d 40 01 00 f0 06 07 good c9 6c 50 31 3e 07 0b 46 84 2d 40 01 00 f0 06 07 мой bad 0x0060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff bad 20 01 00 40 16 13 ff ff ff ff ff ff ff ff ff ff good 00 01 00 40 15 13 03 40 ff ff ff ff ff ff ff ff мой попробовал сначала юникастом послать, потом как есть, воспроизвести не удалось | | |
| 33
- 08.02.2013 - 20:03
| Ну что же ждем SERGIUSF с его картинкой ;) | | |
| 34
- 08.02.2013 - 20:10
|
отниму хлебу брехлайна пиздау него под шапкой | | |
| 35
- 11.02.2013 - 11:58
| Цитата:
| | |
| 36
- 11.02.2013 - 15:01
|
to35 какой код нужно послать чтобы сетевуха откинула пачкорд :) Intel подтвердил проблему, но сказал что она свойственна только для материнских плат какого то производителя, но не уточнил какого именно http://communities.intel.com/communi...ller-statement | | |
| 37
- 11.02.2013 - 17:45
|
угу, аж 7-го числа intel как не в ответе за содержимое eeprom от oem, коих пруд пруди | | |
| 38
- 11.02.2013 - 18:45
|
36-TVV1 >среднестатистическая команда уборщиков может ) З.Ы. проверять броадкастом где не попадя я пока не решился. | | |
| 39
- 11.02.2013 - 19:47
|
38-701054 > ну дык, можн файл поправить, а можно tcpreplay-edit --enet-dmac=00:11:22:33:44:55 -v -i eth1 pod-icmp-ping.pcap это касается только встроенных | |
Интернет-форум Краснодарского края и Краснодара |
