Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 147
Хорошо, что у меня все критичные сервисы на 82576.
Он уже связался с инженерами Intel, и они подтвердили, что действительно, это баг в прошивке EEPROM на контроллерах 82574L.
И? Апдэйт-то будет?
Скорее всего, в свежих драйверах.
Насколько я помню, в Линуксах драйвер уже давно их EEPROM на лету патчит.
Так что не впервой :).
Насколько я помню, в Линуксах драйвер уже давно их EEPROM на лету патчит.
Так что не впервой :).
То есть достаточно один раз загрузить на компе с этой картой Linux и карта будет исправлена?
Слово EEPROM всегда тождественно слову FIRMWARE, или я что-то не понимаю?
Т.е. при включении FIRMWARE загружается из EEPROM, а при загрузке драйвера может быть загружен другой FIRMWARE, более новый и совершенный, чем тот, который загружен ранее из EEPROM, с исправлением ошибок? Но, вроде EEPROM — это не только FIRMWARE, но и всякие константы управляющие. Читал как-то в сети одну страшную историю, что запись неправильного значения байта по определённому адресу EEPROM может сразу убить сетевую карту наповал, что не лечится даже холодной перезагрузкой.
Т.е. при включении FIRMWARE загружается из EEPROM, а при загрузке драйвера может быть загружен другой FIRMWARE, более новый и совершенный, чем тот, который загружен ранее из EEPROM, с исправлением ошибок? Но, вроде EEPROM — это не только FIRMWARE, но и всякие константы управляющие. Читал как-то в сети одну страшную историю, что запись неправильного значения байта по определённому адресу EEPROM может сразу убить сетевую карту наповал, что не лечится даже холодной перезагрузкой.
Intel был удивлен, что не все пакеты обрабатывались… )))))
(по мотивам Г… удивлялся, что не все его приказы выполнялись)
(по мотивам Г… удивлялся, что не все его приказы выполнялись)
Интересно, будет ли волна падений серверов…
Я бы не отказался от такого QA инжинера )
Это уже было в модемах, когда надо было заставить клиента сделать POST request с текстом типа +++ATH и модем бросал трубку.
PS: точную последовательность я забыл. А ведь думал, что все эти atdp никогда из памяти не исчезнут… Там должна была проверяться задержка, но некоторые модемы ловили последовательность и в обычном потоке.
PS: точную последовательность я забыл. А ведь думал, что все эти atdp никогда из памяти не исчезнут… Там должна была проверяться задержка, но некоторые модемы ловили последовательность и в обычном потоке.
Ещё похожее было в CDROM — при записи некоторые «случайные» данные срабатывали как системная метка.
Да, +++ATH. И не обязательно даже в POST-запросе, я помню, в стародавние времена одному товарищу сообщение по ICQ с этим текстом вешало трубку.
Даа… Был у меня случай, еще во времена фидо. Не берется почта с ноды и все тут, хоть тресни, модем отваливается. Оказалось, письмо на меня лежало несжатое, с нехорошими AT-командами. Эх, молодость…
Вроде бы, этот фокус работал только на определённых модемах. Да и после +++, насколько помню, требовалось ожидание.
Вот так подстава (
82574L весьма популярная карта на мамках Supermicro
82574L весьма популярная карта на мамках Supermicro
Да, в сопровождении 4 сервака на супермикро со злополучной 82574L. Теперь молиться чтоб никто не потестил это на них?
проверил 4 сервера на супермикро с этой сетевухой — бак не воспроизводится. Хотя меня немного смущает, что в его файлах адрес указан как 47f, а в файлах pod-http-post.pcap и pod-icmp-ping.pcap это уже другой адрес, хотя может он имел ввиду относительный адрес, вот только относительно кого?
Просто так к теме… Когда-то мой преподаватель, работавший ранее на оборонку, утверждал, что мировые производители электроники специально оставляют подобные вещи в своих продуктах, дабы при необходимости парализовать системы неприятеля…
Но даже при выключенной паранойе кажется странной реакция кода на один единственный байт со значением именно 2 или 3.
Но даже при выключенной паранойе кажется странной реакция кода на один единственный байт со значением именно 2 или 3.
Я бы сильно удивился, если бы производители электроники не оставляли подобные вещи. Единственное что — всё-таки, думается, данное падение — скорее случайно, уж больно лёгкий триггер получается, даже случайно отловили. Наверное, для «боевого» применения будет использоваться более сложная система активации закладки.
Спасибо. Как раз хотел Intel EXPI9301CT покупать.
Т.е. если послать на эту карту пакет полностью наполненный двойками, чтобы уж наверняка, она сдохнет?
Подскажите плз какой диапазон mac у таких карт? Первые 24 bits
Кстати, вообще-то неэтично выпускать такую новость в паблик до того, как будет готова новая прошивка. Ведь соорудить эксплоит для этой уязвимости — дело нескольких десятков минут. Тем более что карточка очень популярная.
Мне интересно было бы услышать более развернутое мнение от минусующих граждан, чем просто увидеть красную цифру с черточкой. Разумеется, если они не протестуют против этической составляющей в принципе )
Я не минусую, но всё-таки — вы хотели бы купить серверов с этим багом и ещё раз убить месяцы на выяснение причины падения ваших сервисов?
А при чем здесь это? Речь идет о том, что как и при любой другой dos уязвимости, нашедший эту уязвимость обычно дает время вендору выпустить фикс, а не бежит хвастаться налево и направо, практически выдав готовый эксплоит. Задайте лучше вопрос владельцам таких серверов: «готовы ли они к возможным dos-атакам на их ресурсы при отсутствии свежих прошивок»?
Я не в курсе деталей, возможно, Intel была уведомлена уже давно, тогда никаких претензий. Но в таком случае об этом стоило написать в новости, а то иначе возникают такие вопросы, как у меня.
P.S. у Supermicro отличные мамки, а у Intel — лучшие сетевые карты и драйвера к ним (imho). И в данном инциденте у меня претензии не только к Intel, но и к тем людям (вполне возможно, что сам Кристиан к этому непричастен), которые дали в руки кулхацкерам новую игрушку.
Я не в курсе деталей, возможно, Intel была уведомлена уже давно, тогда никаких претензий. Но в таком случае об этом стоило написать в новости, а то иначе возникают такие вопросы, как у меня.
P.S. у Supermicro отличные мамки, а у Intel — лучшие сетевые карты и драйвера к ним (imho). И в данном инциденте у меня претензии не только к Intel, но и к тем людям (вполне возможно, что сам Кристиан к этому непричастен), которые дали в руки кулхацкерам новую игрушку.
Поскольку «уязвимость» воспроизводится непреднамеренно — лучше чтобы люди понимали, почему вдруг у них серваки падают.
Что-то мне подсказывает, что для некоторых радость этого понимания быстро перекроется огорчением от возросшей волны таких падений, и уж это огорчение будет ещё многократно усиленно необходимостью срочно искать новую сетевуху и дауном на время разборки сервера…
Т.е. на аппаратном файрволе, который в любом более-менее серьёзном проекте присутствует — так сложно настроить фильтрацию нежелательных пакетов? Я предпочту в подобных ситуациях быть заведомо осведомлённым относительно причины, дабы прикрыть продакшн-сервера от таких «неожиданностей».
Т.е. не владельцев аппаратных файрволов, которых 99+%, в расчет можно и не брать? Проекты у них не серьезные, чего париться?
Никому не приятно видеть такие неожиданности, но между «бегать в горячке и срочно искать решение, типа установки железного файрвола (ещё нужно, чтобы он сам не использовал эту 82574L), или замены карточки (или всего сервера)» и «загрузиться по PXE и обновить прошивку за пару минут» я предпочту второе.
Никому не приятно видеть такие неожиданности, но между «бегать в горячке и срочно искать решение, типа установки железного файрвола (ещё нужно, чтобы он сам не использовал эту 82574L), или замены карточки (или всего сервера)» и «загрузиться по PXE и обновить прошивку за пару минут» я предпочту второе.
У вас сервер прям на непосредственно Tier1 канале висит? Или всё-таки в каком-либо ДЦ стоит? Попросите технарей ДЦ и они вам организуют фильтрацию своими средствами.
Вы хоть раз пробовали просить организовать фильтрацию не на L3/L4, а на уровне байтов по заданному смещению?
Да и в ДЦ обычно присутствуют сами операторы, и при более-менее приличном количестве железа принято тянуть патч-корды напрямую от провайдерского оборудования до своего. При этом ДЦ организует лишь энергоснабжение и кондиционирование.
Я уже представляю себе, сколько лет займет проработка проекта по такого рода фильтрации у того же Билайна…
Да и в ДЦ обычно присутствуют сами операторы, и при более-менее приличном количестве железа принято тянуть патч-корды напрямую от провайдерского оборудования до своего. При этом ДЦ организует лишь энергоснабжение и кондиционирование.
Я уже представляю себе, сколько лет займет проработка проекта по такого рода фильтрации у того же Билайна…
В любом случае есть какое-либо ближайшее к вам оборудование, возможностей которого достаточно для выполнения подобных задач. Вопрос лишь в том, умеете ли вы договариваться.
В любом случае есть какое-либо ближайшее к вам оборудование, возможностей которого достаточно для выполнения подобных задач.
Вовсе не обязательно. Я не в курсе хардварных платформ (а именно такие и ставятся в ЦОДы), способных на подобный анализ.
IPS в inline там не используются (если нет подписки на какой-нибудь anti-DDOS). IDS или другие любого рода анализаторы зеркалированного трафика — запросто, но к тому моменту, когда они обнаружат совпадение — пакет уже попал в цель.
На софтверных роутерных платформах, которые и так хиленькие, тоже не принято задействовать подобный весьма тяжелый функционал.
match байта по заданному смещению — тяжёлый функционал? Видимо я чего-то не понимаю в этой жизни…
я организовывал на уровне байтов, например на длинках из 3000 серии за 5 тысяч рублей делается при помощи ACL (в основном 100мбитные порты но есть и пара гигабитных) — вот вам и аппаратный фаервол.
я организовывал на уровне байтов, например на длинках из 3000 серии
Можно пруф? Речь только про транзитный трафик, а не про следующий на control plane. Произвольные байты по произвольному смещению.
Создается ACL в котором указывается смещение и какое значение там ожидается увидеть, ну и действие — пермит или денай, можно на конкретный порт повесить.
www.dlink.ru/ru/faq/75/954.html вот тут даже мануал есть
www.dlink.ru/ru/faq/75/954.html вот тут даже мануал есть
ОХРЕНЕТЬ!!!
Задача: «РС1 обращается на ТСР порт 445 РС2. Необходимо заблокировать подобную активность.»
Решение:
А я-то привык к «deny tcp host 1.1.1.1 host 2.2.2.2 eq 445»…
Ну в принципе верю, что они и в содержимом пакета ковыряться могут, хотя примеров не видел (пока что сойдет и анализ TCP внутри GRE). Поздравляю — свитч за 5000р. хоть в чем-то обходит свитч за $100k :)
Задача: «РС1 обращается на ТСР порт 445 РС2. Необходимо заблокировать подобную активность.»
Решение:
create access_profile packet_content_mask offset_16-31 0x0 0x0 0x000000ff 0x0 offset_32-47 0x0 0x0 0xffff0000 0x0 profile_id 1
config access_profile profile_id 1 add access_id 1 packet_content_mask offset_16-31 0x0 0x0 0x00000006 0x0 offset_32-47 0x0 0x0 0x01bd0000 0x0 port 1 deny
Вот и все, ТСР destination port 445 заблокирован. Можно поступить несколько иначе, а именно:
create access_profile packet_content_mask offset_32-47 0x0 0x0 0xffff0000 0x0 profile_id 1
config access_profile profile_id 1 add access_id 1 packet_content_mask offset_32-47 0x0 0x0 0x01bd0000 0x0 port 1 deny
Т.е. не указывать протокол (offset_16-31 0x0 0x0 0x000000ff), в таком варианте будут заблокированы все пакеты с destination port 445 вне зависимости от протокола, т.е. под данное правило попадут и ТСР и UDP пакеты.
А я-то привык к «deny tcp host 1.1.1.1 host 2.2.2.2 eq 445»…
Ну в принципе верю, что они и в содержимом пакета ковыряться могут, хотя примеров не видел (пока что сойдет и анализ TCP внутри GRE). Поздравляю — свитч за 5000р. хоть в чем-то обходит свитч за $100k :)
ну да, они смешные =))) на самом деле свитч умеет так же просто(как и в вашем примере) блокировать порты. А вообще там есть L4 — в нем указывается смещение после айпи заголовка, вот там и надо матчить.
я этим свитчом контролировал арп ответы на отдельных портах, чтобы люди не могли не своими адресами отвечать в сеть. грубо говоря против арп-спуфинга.
Это омерзительно… Но да, может работать с кучей оговорок. Если нет оборудования с человеческой реализацией этого функционала. По-моему, то, что я процитировал чуть выше, принципиально невозможно поддерживать, а ошибки должны стать нормой жизни.
на самом деле это самая лучшая и 100% работающая реализация. оговорка лишь одна — все настраивается вручную. Те надо вручную создать ACL и знать на каком порту какие айпи адреса есть, чтобы их ответы разрешить в протоколе arp. Поддерживать это возможно, по крайней мере у нас в фирме это получается на более чем 800 коммутаторов. Главное тут то, что можно контролировать содержимое кадров на аппаратном уровне за вменяемые деньги, а бардак можно где угодно устроить.
на самом деле это самая лучшая и 100% работающая реализация.
Худшая. Работающая только в определенных условиях и абсолютно несопровождаемая. Серьезно. На нормальном оборудовании требуется штук 5 шаблонных команд накатить разом на все устройства, и у нехорошего человека не получится не то что arp заспуфить, но и вообще выставить себе статический адрес. И при этом полноценно работающий DHCP, легкая миграция устройств с порта на порт (BYOD же, да и корпоративные ноутбуки) и так далее.
у нас в фирме это получается на более чем 800 коммутаторов.
Т.е. у вас на 800 коммутаторов нет DHCP?
В ARP reply проверяется мак и в L2 заголовке, и в содержании пакета, как и IP адреса? На каждый порт руками прописываются допустимые src mac, src IP, а также то же самое для ARP?
Ну и само по себе наличие 800 коммутаторов (8-портовых?) — ужас. Они размазаны ровным слоем по всей стране, или же можно найти по несколько десятков на локацию?
Отвечу за автора — у меня в сети 300 коммутаторов D-Link, на каждый порт выделено по 8 ip из серого диапазона, и для них разрешены ACL'ками только ARP и IP-пакеты с этими ip.
Например:
create access_profile packet_content_mask offset1 l2 0 0xFFFF offset2 l2 16 0xFFFF offset3 l2 18 0xFFF8 profile_id 252
create access_profile ip source_ip_mask 255.255.255.248 profile_id 253
create access_profile packet_content_mask offset1 l2 0 0xFFFF profile_id 254
create access_profile ip source_ip_mask 000.000.000.000 profile_id 255
config access_profile profile_id 252 add access_id auto_assign packet_content offset1 0x0806 offset2 0x0A35 offset3 0xA008 port 1 permit
config access_profile profile_id 253 add access_id auto_assign ip source_ip 10.53.160.8 port 1 permit
config access_profile profile_id 254 add access_id auto_assign packet_content offset1 0x0806 port 1 deny
config access_profile profile_id 255 add access_id auto_assign ip source_ip 000.000.000.000 port 1 deny
Например:
create access_profile packet_content_mask offset1 l2 0 0xFFFF offset2 l2 16 0xFFFF offset3 l2 18 0xFFF8 profile_id 252
create access_profile ip source_ip_mask 255.255.255.248 profile_id 253
create access_profile packet_content_mask offset1 l2 0 0xFFFF profile_id 254
create access_profile ip source_ip_mask 000.000.000.000 profile_id 255
config access_profile profile_id 252 add access_id auto_assign packet_content offset1 0x0806 offset2 0x0A35 offset3 0xA008 port 1 permit
config access_profile profile_id 253 add access_id auto_assign ip source_ip 10.53.160.8 port 1 permit
config access_profile profile_id 254 add access_id auto_assign packet_content offset1 0x0806 port 1 deny
config access_profile profile_id 255 add access_id auto_assign ip source_ip 000.000.000.000 port 1 deny
аналогично, только у меня по 1 адресу на порт — больше и не надо
А само собержание arp пакета проверяется? Как бы ничто не заставляет содержимое arp пакета совпадать с его заголовком. Устройство может использовать правильный src IP, правильный src mac, но в самом arp пакете указать IP первого хопа и какой-нибудь левый мак. Собственно, сеть выйдет из строя, если достаточно часто слать garp'ы.
«ip source_ip_mask 255.255.255.248»
А сюда случаем не попадет первый хоп? Как-то не вижу я защиты от спуфинга наиболее важного адреса в подсети со стороны порта, которому назначен блок из первых восьми адресов подсети.
Нормальные механизмы безопасности автоматически прикрывают подобные дыры.
«ip source_ip_mask 255.255.255.248»
А сюда случаем не попадет первый хоп? Как-то не вижу я защиты от спуфинга наиболее важного адреса в подсети со стороны порта, которому назначен блок из первых восьми адресов подсети.
Нормальные механизмы безопасности автоматически прикрывают подобные дыры.
>А само собержание arp пакета проверяется?
Да, проверяется.
>Как-то не вижу я защиты от спуфинга наиболее важного адреса в подсети со стороны порта, которому назначен блок из первых восьми адресов подсети.
Не совсем понял, что вы имеете в виду. Клиенту принадлежат только эти 8 адресов. Проверяется, чтобы все исходящие от него пакеты имели IP-адрес (в содержимом ARP-пакета, заголовке ARP и заголовке IP-пакета) только этих адресов.
Да, проверяется.
>Как-то не вижу я защиты от спуфинга наиболее важного адреса в подсети со стороны порта, которому назначен блок из первых восьми адресов подсети.
Не совсем понял, что вы имеете в виду. Клиенту принадлежат только эти 8 адресов. Проверяется, чтобы все исходящие от него пакеты имели IP-адрес (в содержимом ARP-пакета, заголовке ARP и заголовке IP-пакета) только этих адресов.
Автоматически арп-спуфинг невозможно контролировать, только настройка вручную гарантирует 100% защиту. А как защититься, как не контролировать на порту арп ответы, зная заранее какой айпи на этом порту должен быть? Идеально все работает уже многие годы.
почему нет DHCP? все 800 коммутаторов по 26-28 портов.
ACL и dhcp конфигурируется скриптом, так что достаточно указать лишь номер свитча, а далее ctrl-c, ctrl-v и все.
почему нет DHCP? все 800 коммутаторов по 26-28 портов.
ACL и dhcp конфигурируется скриптом, так что достаточно указать лишь номер свитча, а далее ctrl-c, ctrl-v и все.
А как защититься, как не контролировать на порту арп ответы, зная заранее какой айпи на этом порту должен быть?
Легко. Роутер отслеживает обмен по DHCP и запоминает, куда какой адрес назначило. Заодно проверяются и DHCP запросы. Опять же, конфигурация на 100% шаблонная, не требуется никакой специфики для каждого устройства (если предположить, что наименования аплинков будут одинаковые). И никакого колхоза.
Можно прикрутить более серьезные решения — к примеру, ISE на базе 802.1x. Тут уже ограничения на порт будут применяться в зависимости от того, какое устройство к нему подключилось, залогинилось ли оно в домен (до логона один набор портовых ACL, после — другой) и так далее.
Идеально все работает уже многие годы.
Ради интереса. Назовите общий порядок числа сотрудников в компании, а также количество сетевиков, сопровождающих этот зоопарк.
Серьезно — у меня возникает ощущение, что я попал в 90-е :)
ACL и dhcp конфигурируется скриптом
Не понял. У любой машины на любом порту может смениться адрес. Каким образом скрипт отслеживает это? Он присосался к DHCP серверам и при любом изменении залезает на свитч и правит конфиги? Да и выше вы писали «у меня по 1 адресу на порт», т.е. статика на пару десятков тысяч машин?
Кстати — дэлинк умеет вставлять 82-ю опцию в обмен?
>Роутер отслеживает обмен по DHCP и запоминает, куда какой адрес назначило. Заодно проверяются и DHCP запросы. Опять же, конфигурация на 100% шаблонная, не требуется никакой специфики для каждого устройства (если предположить, что наименования аплинков будут одинаковые). И никакого колхоза.
У длинка есть и такая функция, но нам она неудобна — появляется привязка к макам и нет полной защиты от содержимого ARP-пакета, насколько я помню. А так пользуемся как раз dhcp option 82, назначаем в зависимости от порта IP и вообще не паримся по поводу MAC'ов клиента (а значит, и не требуем от них танцев со сменой MAC при смене девайсов).
У длинка есть и такая функция, но нам она неудобна — появляется привязка к макам и нет полной защиты от содержимого ARP-пакета, насколько я помню. А так пользуемся как раз dhcp option 82, назначаем в зависимости от порта IP и вообще не паримся по поводу MAC'ов клиента (а значит, и не требуем от них танцев со сменой MAC при смене девайсов).
… и тут до меня дошло, что вы не ентерпрайз, а оператор…
если роутер даже будет знать ARP записи клиентов — это не защитит самих клиентов от арп-спуфинг атаки. Все эти полумеры легко обойти, о которых вы пишете и о каких еще даже не знаете, единственный 100% вариант — вручную контролировать арп-ответы. Вы сильно заблуждаетесь в средствах защиты, которые используете. Я многие подобные вещи обходил на множестве разного рода оборудования, в длинке тоже есть автозащита, настраиваемая шаблонно — но и она не работает как надо.
3 сетевых инженера поддерживают это, но на самом деле это отнимает 20% времени лишь одного из них. Другие же заняты более серьезными задачами.
Смениться адрес не может, dhcp выдает адрес, согласно порту(по dhcp snooping) получает номер свитча и его порт — на dhcp сервере для каждой такой записи заранее сконфигурен пул адресов(из одного адреса, но можно и больше). Если человек меняет порт — меняется и айпи адрес. В лихие 90ые те технологии, которые мы сейчас используем, даже и представить не могли. А поддержку 802.1x должны иметь и оконечные устройства, а мы такого позволить себе не можем в нашем бизнесе.
3 сетевых инженера поддерживают это, но на самом деле это отнимает 20% времени лишь одного из них. Другие же заняты более серьезными задачами.
Смениться адрес не может, dhcp выдает адрес, согласно порту(по dhcp snooping) получает номер свитча и его порт — на dhcp сервере для каждой такой записи заранее сконфигурен пул адресов(из одного адреса, но можно и больше). Если человек меняет порт — меняется и айпи адрес. В лихие 90ые те технологии, которые мы сейчас используем, даже и представить не могли. А поддержку 802.1x должны иметь и оконечные устройства, а мы такого позволить себе не можем в нашем бизнесе.
если роутер даже будет знать ARP записи клиентов — это не защитит самих клиентов от арп-спуфинг атаки.
Пардон, я как человек, привычный к L3 свитчам на уровне доступа, временами называю их по роли в данном контексте.
Разумеется, весь анализ происходит на уровне порта.
единственный 100% вариант — вручную контролировать арп-ответы.
Неправильно. Автоматический механизм не менее (а то и более) надежен, но куда удобнее в работе.
в длинке тоже есть автозащита, настраиваемая шаблонно — но и она не работает как надо.
Это — d-link.
Настройте на каталисте DHCP snooping + DAI + IP source guard + port-security (по части количества mac адресов), и попробуйте это обойти.
В лихие 90ые те технологии, которые мы сейчас используем, даже и представить не могли.
Матчинг по смещению в пакете? STP размером с город? :)
еще раз повторю — вы заблуждаетесь. У меня не остается уже времени на споры с вами. Для начала вы должны перестать смотреть сверху вниз.
DHCP snooping + DAI + IP source guard + port-security — я по прежнему могу послать ложный arp-ответ(сообщить в сеть на арп-запрос, что некий IP это мой мак). Да, я не смогу через себя пропускать ложный трафик, но в арп таблице какого-нибудь Васи Пупкина будет мой мак — а значит он не получит доступ к хосту, тк айпи пакеты пойдут на мой мак, а не на мак Леши, или Пети, или вообще его шлюза. В итоге у него ничего работать не будет. Ваша защита в этом плане бессильна.
И да, когда ты оператор — ты не можешь покупать свитчи за штуку баксов, их у тебя не 10шт, а сотни и тысячи, а порт абонента надо сделать как можно дешевле — никто не хочет платить по 70тр в месяц, а хотят по 200-300р.
DHCP snooping + DAI + IP source guard + port-security — я по прежнему могу послать ложный arp-ответ(сообщить в сеть на арп-запрос, что некий IP это мой мак). Да, я не смогу через себя пропускать ложный трафик, но в арп таблице какого-нибудь Васи Пупкина будет мой мак — а значит он не получит доступ к хосту, тк айпи пакеты пойдут на мой мак, а не на мак Леши, или Пети, или вообще его шлюза. В итоге у него ничего работать не будет. Ваша защита в этом плане бессильна.
И да, когда ты оператор — ты не можешь покупать свитчи за штуку баксов, их у тебя не 10шт, а сотни и тысячи, а порт абонента надо сделать как можно дешевле — никто не хочет платить по 70тр в месяц, а хотят по 200-300р.
я по прежнему могу послать ложный arp-ответ(сообщить в сеть на арп-запрос, что некий IP это мой мак)
Нет. Содержимое arp пакета сверяется с комбинацией mac-IP, которые упоминались на этапе получения адреса по DHCP.
Почитайте www.cisco.com/en/US/products/hw/switches/ps5023/products_configuration_example09186a00807c4101.shtml к примеру.
И да, когда ты оператор — ты не можешь покупать свитчи за штуку баксов
Тут согласен. У оператора, обслуживающего хомячков, нет задачи ставить качественное и приятное в работе оборудование.
их у тебя не 10шт, а сотни и тысячи
У меня сотни… 100% — каталисты. Но опять же, у меня требования к коммутаторам иные.
а кем проверяется? DIA не имеет такого функционала, порт секьюрити тоже для других целей.
DAI проверяет содержание входящего в порт arp пакета, сверяя его с базой dhcp snooping. Собственно, только поэтому его и включают, с остальным ip source guard справится.
да, прочитал, на бумаге вроде бы это должно все работать, но по факту оператор точно не сможет это использовать — тк вылазит куча других проблем. Например у человека постоянно меняется мак, а айпи адрес ему должен выдаваться всегда один, допустим что для серых адресов мы можем выделить пул из 2 адресов на такой случай, но как быть с реальником? фиговая утилизация будет. Ну или dhcp не работает (такое бывает 1 случай на 20 компьютеров, как это не удивительно). В жестоком мире мы живем, не все так просто, как нас учили в начальной школе.
Например у человека постоянно меняется мак, а айпи адрес ему должен выдаваться всегда один
Опция 82… Свитч лишь наблюдает за обменом и запоминает согласованные адреса, но сам ничего не предлагает. А на сервере можно придумать совершенно произвольные алгоритмы выдачи адресов. Особенно если сервер не от MS как это принято в ентерпрайсах.
В жестоком мире мы живем
Вы — да :) У нас как-то принята унификация в том числе и рабочих мест. Не нужно подстраиваться под любые нестандартные виды поведения у клиента. Разрабатывается стандарт, тестируется и внедряется. Обычно рекомендации «начальной школы» прекрасно работают. Их ведь неглупые люди придумывали. И никакие костыли не нужны, и никакого колхоза нет.
Обычно операторы (не хомячковые, а нормальные) тоже задействуют этот функционал. И железо у них на CPE — вовсе не дэлинки, а чаще всего те же циски, это я по опыту говорю.
Так у нас тоже все замечательно работает, это у вас со стороны попаболь на это дело, хотя цель дастигнута и на желе гораздо дешевле. Билайн использует длинки — он хомячковый?
это у вас со стороны попаболь на это дело, хотя цель дастигнута и на желе гораздо дешевле.
Какая цель?
Нам нужно PoE, совместимость с Cisco ISE, в большинстве случаев — локальный роутинг с VRFами. Это еще самый минимум.
Билайн использует длинки — он хомячковый?
Билайн разный бывает. Есть тот, который подключает хомячков. А есть — для корпоративных пользователей. Я как корпоративный пользователь ничего кроме цисок на другом конце протянутых к нам патч-кордов не видел.
И кстати:
допустим что для серых адресов мы можем выделить пул из 2 адресов на такой случай, но как быть с реальником?
У меня дома Онлайм. Я получаю на порт сразу 5 глобально маршрутизируемых адресов, один можно зарезервировать навеки, и при этом технология подключения — банальный IPoE без всяких лишних инкапсуляций.
Ну и надо ли говорить, что провайдер, выдающий клиентам адреса за NAT, достоит сильнейшего осуждения, и по современным меркам должен считаться вымирающим динозавром, от которого все стараются убежать?
Цель — предотвратить арп-спуфинг.
Само собой мы подключаем и хомячков, и корпоративных пользователей, и крупных операторов связи, но вопрос с хомячками надо решать дешево. Вы не работали похоже в этой сфере и не догадываетесь о всех ее тонкостях, тут нельзя положить болт и сказать, раз ты такой нестандартный клиент — то не подключайся к нам, например не хочешь работать по 802.1x, который так любят использовать в корпоративном сегменте.
Мы выдаем серые адреса, НО на время сессии в интернете человеку выделяется реальный динамический адрес, можно получить и статический — за отдельную плату. Используется NAT(а не PAT) с большим пулом адресов, При этом большая утилизация реальных адресов — за что райп нас по головке гладит, а у других, менее добросовестных провайдеров — адреса забирает, выдача IPv4 адресов сейчас особенно жестко проходит. тоже IPoE кстати.
Само собой мы подключаем и хомячков, и корпоративных пользователей, и крупных операторов связи, но вопрос с хомячками надо решать дешево. Вы не работали похоже в этой сфере и не догадываетесь о всех ее тонкостях, тут нельзя положить болт и сказать, раз ты такой нестандартный клиент — то не подключайся к нам, например не хочешь работать по 802.1x, который так любят использовать в корпоративном сегменте.
Мы выдаем серые адреса, НО на время сессии в интернете человеку выделяется реальный динамический адрес, можно получить и статический — за отдельную плату. Используется NAT(а не PAT) с большим пулом адресов, При этом большая утилизация реальных адресов — за что райп нас по головке гладит, а у других, менее добросовестных провайдеров — адреса забирает, выдача IPv4 адресов сейчас особенно жестко проходит. тоже IPoE кстати.
Цель — предотвратить арп-спуфинг.
Но это лишь опциональная мелочь для нас. Потому некорректно говорить «ха-ха, ты переплатил». Для нас важна гибкость. Вариант «зарезервировать за каждым портом диапазон адресов» не годится.
Вы не работали похоже в этой сфере и не догадываетесь о всех ее тонкостях
Почему же? Догадываюсь. Поэтому и говорю, что надо стараться делать одновременно и гибко, и удобно. Тогда и с нестандартными устройствами проблем не будет.
Мой провайдер под названием «Онлайм» не позволяет слать пакеты тем, кто не получил адрес с DHCP. И почему-то это у них не вызывает проблем. Даже учитывая, что с их архитектурой можно поставить дома 5-портовый свитч вместо роутера, что, вообще говоря, встречается исключительно редко. А у вас вон не все клиенты умудряются получить адрес… Может, дэлинки слишком активно фильтруют пакеты? :)
При этом большая утилизация реальных адресов — за что райп нас по головке гладит
Вам хорошо. Клиенты страдают. Вам плевать на клиентов. Круто… Ну хоть хорошо, что не PAT.
Все очень удобно, скрипт конфиг для свитча сгенерит и никаких проблем. Гибкость тоже есть — можно вон даже пакет смерти зафаерволить, если захочется. И вообще о чем мы сейчас говорим — это мелочи, у нас помимо этого куча других технологий используется при всем этом. Например помимо юникаста так же надо разбираться и с мультикастом — iptv. А так же для VoIPa тоже кое-что подкручивать надо. И это все должно выйти дешево для клиента, при этом качественно, тк конкуренция жесткая, а мы за 3 года с 200 клиентов до 19 тысяч абонентов подняли базу(не покупкой чужих сетей — а подключениями), что говорит о многом.
Не надо конкретизировать, что вот у нас не получают, в этом чаще всего виноваты кривые драйвера сетевух и дешевые китайские роутеры, которые абоненты не пойми откуда достают. У тех, у кого нормальный софт и железо исправно получают адреса, однако даже последней зануде можно выдать статический адрес, а не отказать ему в услуге.
С чего вы взяли, что наши клиенты страдают?
И заявление — что нам плевать, не совсем уместно. Мы — как никто другие, заботимся о наших клиентах, а не ставим их в жесткие рамки.
Не надо конкретизировать, что вот у нас не получают, в этом чаще всего виноваты кривые драйвера сетевух и дешевые китайские роутеры, которые абоненты не пойми откуда достают. У тех, у кого нормальный софт и железо исправно получают адреса, однако даже последней зануде можно выдать статический адрес, а не отказать ему в услуге.
С чего вы взяли, что наши клиенты страдают?
И заявление — что нам плевать, не совсем уместно. Мы — как никто другие, заботимся о наших клиентах, а не ставим их в жесткие рамки.
можно вон даже пакет смерти зафаерволить
А как именно будете файрволить? По определенному значению одного байта? Ждите вал звонков.
Вот вы хвастаетесь IPTV. Это:
1) PIM — для роутинга мультикаста, роутер без данного функционала роутером не считается.
2) IGMP (snooping) для точечной раздачи трафика по отдельным портам. Свитч и роутер без данного функционала… ну вы поняли.
3) QoS. Стандартно.
VOIP — вариантов полно, но сводятся они к платформе, принимающей голос, и QoS на сети.
Вы с d-link'ами даже TE туннели сигнализировать наверняка не можете. Быстрая сходимость при авариях? Динамическое распределение трафика по сети в зависимости от нагрузки вместо базового load-sharing'а?
однако даже последней зануде можно выдать статический адрес, а не отказать ему в услуге.
В предложенном мной чуть выше решении ничто не мешает статические записи создать. Вот только на практике это не требуется. Даже оператору.
Может, раз только вы сталкиваетесь с этой проблемой, дело все-таки не в драйверах? Ну например периодически теряющийся discover? Или кривоватый offer?
Мы — как никто другие, заботимся о наших клиентах, а не ставим их в жесткие рамки.
И при этом NAT, в XXI веке. И по одному адресу на порт при IPoE. Вопрос: а почему другой оператор, которому всего-то три года (ага, тот самый онлайм), может сделать по-человечески и не экономить на удобстве абонентов? Может, они просто закупают нормальное оборудование? :)
Я что-то не пойму, вы меня троллите что ли?
Давайте по порядку. Я — инженер спд в операторе, опыт в бизнесе 6 лет, знаю все тонкости в этой сфере(технические и экономические), делаю выводы на основании полученного опыта. Вы — вроде сетевой инженер в сфере энтерпрайз решений, все ваши знания касательно операторов сводятся к опыту клиента одного провайдера.
Ваша точка зрения: можно ставить циски и использовать исключительно dhcp в вашей сети, статика не пройдет :)) Несколько статический ACL на коммутаторе — это плохо.
Моя точка зрения: dhcp в редких случаях не работает, так что статическим адресам тоже надо дать право на жизнь.
И после всего этого вы обвиняете меня в том, что я не предлагаю гибкие решения ?)))
Касательно одного адреса на порт — это наша задумка(легко можно использовать и 5 и 10 адресов на порт — вам тут уже один человек пример показал), основанная на анализе другого провайдера на 15 тысяч клиентов, где мы работали раньше. Там 90% абонентов имели лишь 1 адрес и этого было достаточно. Что с остальными 10% делать? да ничего страшного, они все равно в итоге поставили себе wifi-роутер, тк теперь у людей несколько компьютеров и ноутбуков + смартфоны дома. Никаких жалоб никогда не слышал, чтобы кому-то непременно нужен был второй айпи адрес. Более того людям нужен же коммутатор домой для этого, а мы продаем вайфай роутеры им ниже рыночной цены почти по цене тех же свитчей! + бесплатная настройка мастера на дом! Все рады.
Длинки — это оконечное оборудование перед DTE. В других же местах стоят дасаны и циски, алкатели даже были раньше. Да и многие операторы их используют, возможно даже тот же Олайм. Кстати и у них бывают проблемы, как-то у одной моей подруги до хостинга через один из их пиров не проходили пакеты с размером окна больше 1300 байт, они даже заявку эту не рассмотрели за 2 недели! Пришлось отключаться — она вебмастер и хостинг — ее хлеб.
Что касается того, что им тоже 3 года — так это не показатель, Это же все же Ростелеком, там инвестиций много, а нам же приходилось жить и развиваться за счет собственных оборотных средств. По тарифам мы обходим кстати, при том что работаем в области в основном, где тарифы еще выше.
NAT нужен, то, что вы утверждаете обратное — говорит лишь о том, что вы не разбираетесь в специфике вопроса. Вот PAT да, это зло, но нет ничего плохо в нате. тот же онлайн на сколько мне известно так же работает, тоже выдает серые адреса. Так же и у нас можно получить и статический реальник по желанию.
Давайте по порядку. Я — инженер спд в операторе, опыт в бизнесе 6 лет, знаю все тонкости в этой сфере(технические и экономические), делаю выводы на основании полученного опыта. Вы — вроде сетевой инженер в сфере энтерпрайз решений, все ваши знания касательно операторов сводятся к опыту клиента одного провайдера.
Ваша точка зрения: можно ставить циски и использовать исключительно dhcp в вашей сети, статика не пройдет :)) Несколько статический ACL на коммутаторе — это плохо.
Моя точка зрения: dhcp в редких случаях не работает, так что статическим адресам тоже надо дать право на жизнь.
И после всего этого вы обвиняете меня в том, что я не предлагаю гибкие решения ?)))
Касательно одного адреса на порт — это наша задумка(легко можно использовать и 5 и 10 адресов на порт — вам тут уже один человек пример показал), основанная на анализе другого провайдера на 15 тысяч клиентов, где мы работали раньше. Там 90% абонентов имели лишь 1 адрес и этого было достаточно. Что с остальными 10% делать? да ничего страшного, они все равно в итоге поставили себе wifi-роутер, тк теперь у людей несколько компьютеров и ноутбуков + смартфоны дома. Никаких жалоб никогда не слышал, чтобы кому-то непременно нужен был второй айпи адрес. Более того людям нужен же коммутатор домой для этого, а мы продаем вайфай роутеры им ниже рыночной цены почти по цене тех же свитчей! + бесплатная настройка мастера на дом! Все рады.
Длинки — это оконечное оборудование перед DTE. В других же местах стоят дасаны и циски, алкатели даже были раньше. Да и многие операторы их используют, возможно даже тот же Олайм. Кстати и у них бывают проблемы, как-то у одной моей подруги до хостинга через один из их пиров не проходили пакеты с размером окна больше 1300 байт, они даже заявку эту не рассмотрели за 2 недели! Пришлось отключаться — она вебмастер и хостинг — ее хлеб.
Что касается того, что им тоже 3 года — так это не показатель, Это же все же Ростелеком, там инвестиций много, а нам же приходилось жить и развиваться за счет собственных оборотных средств. По тарифам мы обходим кстати, при том что работаем в области в основном, где тарифы еще выше.
NAT нужен, то, что вы утверждаете обратное — говорит лишь о том, что вы не разбираетесь в специфике вопроса. Вот PAT да, это зло, но нет ничего плохо в нате. тот же онлайн на сколько мне известно так же работает, тоже выдает серые адреса. Так же и у нас можно получить и статический реальник по желанию.
Я что-то не пойму, вы меня троллите что ли?
С какой стати?
Я просто говорю, что вы можете гордиться «выкрутился имевшимися средствами», но только результат вовсе нельзя назвать красивым. И, судя по всему, красиво не получается сделать именно из-за ограничений железа.
все ваши знания касательно операторов сводятся к опыту клиента одного провайдера.
Навскидку я насчитал шесть (из наиболее крупных, и считая только Москву — по регионам с полсотни наберется). Билайн — просто пример.
Там 90% абонентов имели лишь 1 адрес и этого было достаточно.
Глобально маршрутизируемый, или за NATом?
Кстати и у них бывают проблемы
Ну у меня по логам раз месяца в 3 на пару минут физика пропадает. Больше претензий не имею.
Отдельные случаи неинтересны. Важнее, что провайдер может предоставить клиенту удобный сервис. И при выборе между получением интерфейса с глобально маршрутизируемым адресом средствами любого рода инкапсуляции (от PPPoE до L2TP) и получением NATного адреса по IPoE даже не слишком технически грамотный абонент предпочтет первое.
Это же все же Ростелеком
Их только недавно купили. Все описанное мной существовало задолго до этого. Просто парни изначально проектировали сеть «на вырост».
По тарифам мы обходим кстати
Честно? Если вы предложите мне честный гигабит за 100р. в месяц, я все равно откажусь. Причины чуть выше описаны: наличие на интерфейсе администрируемого мной железа глобально маршрутизируемого адреса является делом принципа.
NAT нужен
Кому нужен? Провайдеру? А мне из-за этого терпеть дополнительные костыли при SIP звонках, при IPSec сессиях и так далее?
И я на самом деле впервые слышу про провайдера, который делает трансляцию адресов, а не PAT. Смысл? Если можно выдать каждому клиенту по внешнему адресу, то как правило ставятся BRASы и принимают соединения по любого рода инкапсулирующим протоколам.
тот же онлайн на сколько мне известно так же работает
Онлайм?
#show ip int gi0/0
GigabitEthernet0/0 is up, line protocol is up
Internet address is 77.37.XXX.XXX/21
Broadcast address is 255.255.255.255
Address determined by DHCP
Вроде не похоже на адрес из RFC1918. Если подниму бридж-группу — смогу еще четырем устройствам выдать глобально маршрутизируемые адреса. Но так как я перестану управлять первым хопом для внутренних устройств — такого не будет.
Абоненту самое главное, чтобы было дешево, работало стабильно и просто — воткнув кабель в розетку. Про нат некоторые даже не слышали что это и откуда это.Еще есть провайдеры, которые заставляют ставить свои роутеры с кастомной прошивкой или перешивать ваш кастомной для поддержки ихнего впн — и люди ведь даже такими пользуются, там не то чтобы несколько компьютеров сразу не подключишь — там даже один подключить тяжело бывает =)
Конечно L2TP + Bras куда круче, но это нужны большие инвестиции на начальном этапе. Спроектировать такое и мы могли, но денег не было. Сейчас то уже можем и так подключать, вот только самое интересное, что мы людям еще даем пиринг с другими сетями, у которых тоже серые айпишники. Конечно для этого надо было договориться кто какой блок берет. Но в итоге немало так трафика уходит в пиринг без ограничений скорости — и что самое удивительное, люди этим пользуется, Вам этого точно не понять, ровно как и мне — но оно работает: это 20% нашего трафика.
NAT плох разве что с сипом и установкой туннелей, но для таких случаев можно попросить статический реальник и у вас все будет, не вижу в этом особой проблемы.
Конечно L2TP + Bras куда круче, но это нужны большие инвестиции на начальном этапе. Спроектировать такое и мы могли, но денег не было. Сейчас то уже можем и так подключать, вот только самое интересное, что мы людям еще даем пиринг с другими сетями, у которых тоже серые айпишники. Конечно для этого надо было договориться кто какой блок берет. Но в итоге немало так трафика уходит в пиринг без ограничений скорости — и что самое удивительное, люди этим пользуется, Вам этого точно не понять, ровно как и мне — но оно работает: это 20% нашего трафика.
NAT плох разве что с сипом и установкой туннелей, но для таких случаев можно попросить статический реальник и у вас все будет, не вижу в этом особой проблемы.
Многих абонентов и PAT устраивает. Вконтакте открывается? Всё, больше от домашнего интернета им ничего не надо. Как и мне от мобильного, вот только я на мобильнике не поднимаю ничего такого, до чего надо достукиваться извне.
Угу, и мой поднятый с роутера ipv6ip туннель до GE волшебным образом заработает, как только адрес, в который меня NATят, зафиксируется во времени и пространстве :)
Без инспектирования и подмены данных в пакетах будет абсолютный расколбас с приемом вызовов по SIP без предварительной регистрации. С инспектированием — много других забавных проблем, если не повезет.
IPSec — см. SIP.
Итого: вы как провайдер неинтересны гикам, да и просто технически продвинутым людям…
NAT плох разве что с сипом и установкой туннелей, но для таких случаев можно попросить статический реальник и у вас все будет
Угу, и мой поднятый с роутера ipv6ip туннель до GE волшебным образом заработает, как только адрес, в который меня NATят, зафиксируется во времени и пространстве :)
Без инспектирования и подмены данных в пакетах будет абсолютный расколбас с приемом вызовов по SIP без предварительной регистрации. С инспектированием — много других забавных проблем, если не повезет.
IPSec — см. SIP.
Итого: вы как провайдер неинтересны гикам, да и просто технически продвинутым людям…
А как именно будете файрволить? По определенному значению одного байта? Ждите вал звонков.
А зачем нам фаерволить всех? кому надо — тому и можно прописать, речь идет о гибкости, а не о том, что это DPI решение, в которое можно реестр запрещенных сайтов загнать)))
Вы зря сравниваете онлайм, который сразу строил решение на сотни тысяч абонентов и нагнул Zyxel, кажется, на поставку домовых свичей по списку фич ( считайте что они кастомные ) потому что гарантировал закупку десятков тысяч единиц оборудования и обычного оператора, который сеть развивает по возможности, покупает свичи потому что они дешевле и вынужден подстраиваться как под оборудование так и под клиентов.
Скриптинг настройки — вполне вменяемое и рабочее решение, я знаю несколько операторов разного размера, которые так и работают.
С другой стороны правильная схема — это хорошо, правда бывает что не работает, или глючит, если зоопарк. А у старых операторов зоопарк — всегда.
Скриптинг настройки — вполне вменяемое и рабочее решение, я знаю несколько операторов разного размера, которые так и работают.
С другой стороны правильная схема — это хорошо, правда бывает что не работает, или глючит, если зоопарк. А у старых операторов зоопарк — всегда.
Ну и да — то что у нас, это колхозом тоже нельзя назвать. Просто может 20 строчек в конфиге вас смущают больше, чем три у вас.
На аппаратном файрволе как раз непросто матчить по конкретным байтам в содержимом пакета. Скажем, очень популярная ASA так не может. Хотя IOS роутеры могут, но они как раз редко под такие задачи ставятся.
Тут поможет IPS (строго inline). Но потом гарантированно придется разбираться с кучей глюков на сети из-за планомерного дропа случайных пакетов.
Вообще, что-то в этой истории не так.
Т.е. один конкретный байт из середины пакета должен содержать одно из двух значений в пределах 256-и доступных для байта. По статистике, в среднем каждый 128-й пакет будет таким. У меня вот на большинстве интерфейсов pps исчисляется минимум десятками тысяч пакетов в секунду, вовсе не маленьких. В общем, похоже на утку, расчитанную на идиотов, которые сходу внедрят соответствующее правило IPS и найдут массу проблем на свою жопу.
Тут поможет IPS (строго inline). Но потом гарантированно придется разбираться с кучей глюков на сети из-за планомерного дропа случайных пакетов.
Вообще, что-то в этой истории не так.
Отключение интерфейса происходит, если по адресу 0x47f находится значение 2 или 3.
Т.е. один конкретный байт из середины пакета должен содержать одно из двух значений в пределах 256-и доступных для байта. По статистике, в среднем каждый 128-й пакет будет таким. У меня вот на большинстве интерфейсов pps исчисляется минимум десятками тысяч пакетов в секунду, вовсе не маленьких. В общем, похоже на утку, расчитанную на идиотов, которые сходу внедрят соответствующее правило IPS и найдут массу проблем на свою жопу.
Я так понял, что проблема именно в INVITE пакетах SIP. Т.е. возможно в сетевом интерфейсе были заложены какие-либо оптимизации для конкретных протоколов реального времени, и возможно части кода этих оптимизаций по недосмотру программистов наложились друг на друга. Ну, например, неверная вложенность if, т.к. на столь критичных к времени выполнения задачах никаких изысков архитектуры, естественно, нет.
А организовать фильтр — так для этой задачи можно даже любой level1-фильтр прикрутить, если там всё же один критичный байт, не обязательно даже level3-устройств.
А организовать фильтр — так для этой задачи можно даже любой level1-фильтр прикрутить, если там всё же один критичный байт, не обязательно даже level3-устройств.
проблема именно в INVITE пакетах SIP
Неправильная постановка вопроса.
Для сетевой карты есть заголовки L2-L4 и следующая за ними мешанина байтов. Для них не существует такой вещи как SIP.
Судя по написанному, в той мешанине байтов один конкретный байт должен принять одно значение из двух.
Если дело именно в пакете SIP (а судя по написанному, это не так) — потребуется еще ряд совпадений ближе к началу пакета.
для этой задачи можно даже любой level1-фильтр прикрутить
Назовите пример. Из тех, что продаются.
Ну и L1 — это уровень электрических сигналов и вспышек света, а не байтов…
Прошу прощения, конечно же L2, т.е. ethernet-фреймы.
Для сетевой карты есть заголовки L2-L4 и следующая за ними мешанина байтов. Для них не существует такой вещи как SIP.Если бы всё было столь строго, то продукция разных вендоров не отличалась бы между собой — ведь стандарты одни на всех.
Судя по написанному, в той мешанине байтов один конкретный байт должен принять одно значение из двух.Сомнительно, т.к. тогда машина висла бы сразу после старта, т.к. вероятность слишком велика.
Если бы всё было столь строго, то продукция разных вендоров не отличалась бы между собой
А они и не отличаются друг от друга на уровне выше L4. Но и в пределах этих уровней у них можно много чего придумать.
Сомнительно, т.к. тогда машина висла бы сразу после старта, т.к. вероятность слишком велика.
Ага. Потому и говорю, что новость на липу смахивает.
Не поленился, скачал PoD-пакеты с сайта автора. Следом за заголовками HTTP и ICMP идут куски именно INVITE-пакетов, так что вероятнее всего, моё предположение о необходимости выполнения двух условий верно.
Неверно. В одном случае это — HTTP. В другом — ICMP. Ни одно устройство, не оснащенное суровым DPI (DLP к примеру), не распознает там SIP. Скорее, автор не до конца проработал вопрос, и по факту должно совпасть куда больше байтов в мешанине, следующей за L4 заголовками.
I know how the OSI stack works. I know how software is segmented. I know that the contents of a SIP packet shouldn’t do anything to an ethernet adapter. It just doesn’t make any sense.
Ага, он понимает, что сетевухе нет дела до SIP.
With a modified HTTP server configured to generate the data at byte value (based on headers, host, etc) you could easily configure an HTTP 200 response to contain the packet of death — and kill client machines behind firewalls!
Т.е. в ICMP и HTTP «убийца» запаковывался лишь чтобы сквозь файрволы было легче проходить. А содержание схожее, так как все-таки ему не удалось найти конкретные байты, ответственные за падение, и он тупо поместил в пакет все (в случае HTTP вырезав кусок посередине). Я его понимаю: это требует невероятного количества времени, так как придется побайтово менять значения пакета и каждую минуту перезагружать машину.
зачем побайтово? можно вырезать половину? есть изменения, потом половину от половины и тд. Байты обрабатываются последовательно — значит и дело должно быть в последовательности наверняка, так что разные фрагменты в произвольных местах не должны будут повлиять. Лично я не смог даже с его pod реализовать отключение интерфейса на своих сетевухах. Да и у кого-нибудь получилось?
Байты обрабатываются последовательно — значит и дело должно быть в последовательности наверняка
Ни разу не факт. Может, по какой-то причине каждый шестнадцатый байт должен соответствовать определенному правилу, а также нужна определенная длина пакета. Где-то была статья, какими костылями приходилось подпирать MS Office первых версий на какой-то конкретной линейке ЦП из-за багов в микрокоде ЦП.
Да и у кого-нибудь получилось?
Вот и меня терзают смутные сомнения.
Матчить пакеты, может быть и можно. Сложно, но выкрутиться при необходимости получится.
Но чем это поможет, когда позвонит клиент, и с недоумением в голосе спросит, почему у него не работает «ip-телефон конкретного производителя»?
Но чем это поможет, когда позвонит клиент, и с недоумением в голосе спросит, почему у него не работает «ip-телефон конкретного производителя»?
Вот и спорьте после этого, что надо покупать только воркстейшены у системных интеграторов, с сервисом, бла-бла-бла, за запредельное количество бабла… по цене макбуков…
На компах класса «дёшево и сердито» как правило стоит сетевуха не intel
На компах класса «дёшево и сердито» как правило стоит сетевуха не intel
Ну у меня есть сетевуха не Intel, стоит $10, на ней баг в linux, два года не профикшенный. Иногда не устанавливает связь с другим компом если один из компов спал или перезагрузился. Какие-то воркэраунды есть, но что-то мне они не помогают. Проще новую сетевуху купить чем с этой возиться.
Угу, и при этом сетевуха марки «дёшево и сердито» замечательно тупит и глючит даже без «пакетов смерти». Да и вообще — уж на воркстейшнах-то экономия на сетевухе окажется копеечной, да и повисший рабочий комп как-то не смертелен для организации.
А почему вы думаете, что в других сетевых картах нет подобного бага?
и не только от intel?
и не только от intel?
Хм, только в прошлом году был фикс для 82574, но там просто были дропы о которых не сообщалось.
sourceforge.net/projects/e1000/files/e1000e%20stable/eeprom_fix_82574_or_82583/
sourceforge.net/projects/e1000/files/e1000e%20stable/eeprom_fix_82574_or_82583/
Кристиан с коллегами потратил несколько месяцев на поиск причин, почему в их случае контроллеры выдавали ошибку. В конце концов, им удалось докопаться до сути.
Интересно сколько денег стоило такое исследование и стоило оно того? Может быть проще было купить новое оборудование?!
Шрифт в картинке?
Это даже не пакет смерти, а байт смерти
Это пост о вреде проприетарных прошивок.
Хорошо, что вместо Intel EXPI9301CT взял EXPI9400PTBLK. Надеюсь, что в 82572GI такого глюка нет.
Он уже связался с инженерами Intel, и они подтвердили, что действительно, это баг в прошивке EEPROM на контроллерах 82574L.
И дополнить, Intel подтвердил, что проблема только с EEPROM в материнских плат определённого производителя:
Оригинал сообщения
Posted by Douglas Boom in Wired Ethernet on Feb 7, 2013 7:41:02 PM
Recently there were a few stories published, based on a blog post by an end-user, suggesting specific network packets may cause the Intel® 82574L Gigabit Ethernet Controller to become unresponsive until corrected by a full platform power cycle.
Intel was made aware of this issue in September 2012 by the blogs author. Intel worked with the author as well as the original motherboard manufacturer to investigate and determine root cause. Intel root caused the issue to the specific vendor’s mother board design where an incorrect EEPROM image was programmed during manufacturing. We communicated the findings and recommended corrections to the motherboard manufacturer.
It is Intel’s belief that this is an implementation issue isolated to a specific manufacturer, not a design problem with the Intel 82574L Gigabit Ethernet controller. Intel has not observed this issue with any implementations which follow Intel’s published design guidelines. Intel recommends contacting your motherboard manufacturer if you have continued concerns or questions whether your products are impacted.
Recently there were a few stories published, based on a blog post by an end-user, suggesting specific network packets may cause the Intel® 82574L Gigabit Ethernet Controller to become unresponsive until corrected by a full platform power cycle.
Intel was made aware of this issue in September 2012 by the blogs author. Intel worked with the author as well as the original motherboard manufacturer to investigate and determine root cause. Intel root caused the issue to the specific vendor’s mother board design where an incorrect EEPROM image was programmed during manufacturing. We communicated the findings and recommended corrections to the motherboard manufacturer.
It is Intel’s belief that this is an implementation issue isolated to a specific manufacturer, not a design problem with the Intel 82574L Gigabit Ethernet controller. Intel has not observed this issue with any implementations which follow Intel’s published design guidelines. Intel recommends contacting your motherboard manufacturer if you have continued concerns or questions whether your products are impacted.
Какой производитель — не уточняется.
могли бы и написать каких именно…
пы.сы. если шо, это не intel и не supermicro -)
пы.сы. если шо, это не intel и не supermicro -)
Wired: The blame lies with the company that made Kielhofner’s motherboards, Taiwan’s Lex CompuTech. Even though the networking hardware is built by Intel, the bug is in the firmware that Lex ships with its motherboards. To be specific, Lex seems to have used the wrong version of the Electrically Erasable Programmable Read-Only Memory (EEPROM) software for the controller setup that it’s shipping.
Существуют ли универсальные решения, которые фильтруют все необычные пакеты? Допустим неделя это время обучения, потом все что необычно, фильтруется + СМС админу?
Некрореплай на некрокоммент: NtopNG.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
«Пакет смерти» для сетевых карт Intel