The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Удалённо эксплуатируемые уязвимости в подсистемах Intel AMT ..., opennews (??), 13-Июн-20, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


31. "Удалённо эксплуатируемые уязвимости в подсистемах Intel AMT ..."  +/
Сообщение от пох. (?), 13-Июн-20, 12:36 
белки-истерички, напихавшие ipv6 в систему управления (заметим, интелом предусмотрительно выключенный) да и вообще в серверный сегмент - должны же ж страдать?

А в твоем амуде это называется Platform Security Processor.

Причем информация о нем не публикуется, доступна только под nda (то есть найдя дыру ты не имеешь права сообщать о ней кому-то кроме амуде) и лишь избранным.

Так, конечно, гораздо надежнее. Пока кто-нибудь пальчиком не потыкает, или китайцы не решат приколоться.

Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

68. "Удалённо эксплуатируемые уязвимости в подсистемах Intel AMT ..."  +/
Сообщение от Аноним (90), 13-Июн-20, 14:34 
Грешно смеяться над больными людьми.
Ответить | Правка | Наверх | Cообщить модератору

73. "Удалённо эксплуатируемые уязвимости в подсистемах Intel AMT ..."  +3 +/
Сообщение от Клоун Творожок (?), 13-Июн-20, 14:58 
> А в твоем амуде это называется Platform Security Processor.

Уязвимости бывают во всем, что сложнее Hello world.
Другой момент, что нормальный админ просто так не выставит управление серверами в публичный интернет.
Третий момент: а накой черт удаленное управление вставили в мой домашний ПК?
А четвертый момент: если уж запилили эту фичу, то дайте возможность отключения кому она не нужна.

У Intel отключение AMT/ME не предусмотрено. Даже палки в колеса вставлены для отключения. Туда еще энергосбережение, управление вентиляторами повесили до кучи.

В моем "амуде" эта фича просто отключается штатным образом из BIOS.

> Грешно смеяться над больными людьми.

Грешно, но зато забавно наблюдать, как у интелфанбоев бомбит

Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

93. "Удалённо эксплуатируемые уязвимости в подсистемах Intel AMT ..."  +/
Сообщение от Anonymoustus (ok), 13-Июн-20, 15:53 
> Третий момент: а накой черт удаленное управление вставили в мой домашний ПК?

А ты думал, что добренький Штеуд специально для твоего домашнего ПыКа будет придумывать какие-то другие чипсеты? Ешьте с лопаты, что дают.


> А четвертый момент: если уж запилили эту фичу, то дайте возможность отключения
> кому она не нужна.
> У Intel отключение AMT/ME не предусмотрено. Даже палки в колеса вставлены для
> отключения. Туда еще энергосбережение, управление вентиляторами повесили до кучи.

Так и задумано. Одно из её важных свойств в том, чтобы она была неотключаемой, это часть её функциональности. Если хочешь отключаемую, покупай те материнские платы, для которых она опциональна (на отдельной плате). На барахолках поищи -- там ещё есть, я видел.

Ответить | Правка | Наверх | Cообщить модератору

100. "Удалённо эксплуатируемые уязвимости в подсистемах Intel AMT ..."  +2 +/
Сообщение от Онаним (?), 13-Июн-20, 15:59 
> это часть её функциональности. Если хочешь отключаемую, покупай AMD.

Fixed

Ответить | Правка | Наверх | Cообщить модератору

331. "Удалённо эксплуатируемые уязвимости в подсистемах Intel AMT ..."  +/
Сообщение от Аноним (-), 19-Июн-20, 19:29 
>> это часть её функциональности. Если хочешь отключаемую, покупай AMD.
> Fixed

Да нихрена она там не отключаемая, декоративный фэйк в bios не влияет на существование фичи и что на нее ранний старт платформы завязан. А в bios setup любую фигню можно нарисовать для успокоения общественности, ясен перец. Только вот быть такими наивными - чревато.

Ответить | Правка | Наверх | Cообщить модератору

338. "Удалённо эксплуатируемые уязвимости в подсистемах Intel AMT ..."  +/
Сообщение от Anonymoustus (ok), 20-Июн-20, 06:00 
>> это часть её функциональности. Если хочешь отключаемую, покупай AMD.
> Fixed

А ты всё бегаешь минусуешь мои и поха комментарии? Красавчик.

Ответить | Правка | К родителю #100 | Наверх | Cообщить модератору

340. "Удалённо эксплуатируемые уязвимости в подсистемах Intel AMT ..."  +/
Сообщение от Онаним (?), 21-Июн-20, 10:01 
> А ты всё бегаешь минусуешь мои и поха комментарии? Красавчик.

Чо? Я вообще тех же краёв, и мне пох, как и поху. Но так-то это тут шаред ник, может кто и бегает, хз.

Ответить | Правка | Наверх | Cообщить модератору

156. "Удалённо эксплуатируемые уязвимости в подсистемах Intel AMT ..."  –1 +/
Сообщение от пох. (?), 13-Июн-20, 22:19 
> Другой момент, что нормальный админ просто так не выставит управление серверами в
> публичный интернет.

последнее время беда в том, что оно норовит это сделать либо без спроса админа, либо после включения фич, казалось бы, не связанных. (ну да, ipv6, он же чтоб каждый холодильник был подключен к инету. можно бы было и догадаться)

> Третий момент: а накой черт удаленное управление вставили в мой домашний ПК?

еще один...

А поинтересоваться, где там удаленное управление, хотя бы на уровне викивракии ты не пробовал? Нет у тебя там никакого удаленного управления, тебе на те платы в жизни не заработать.

> У Intel отключение AMT/ME не предусмотрено. Даже палки в колеса вставлены для

AMT - предусмотрено. Но сначала надо заплатить за возможность включения, и найти где продается. Может в леновских ноутах, вроде там обещали. ME - именно потому и не предусмотрено штатным образом, что это и есть система для управления питанием, вентиляторами (на самом деле не, но энергосбережением таки да), инициализацией всего на свете и всем прочим барахлом. Которого стало слишком много, чтобы размениваться на отдельные глюкала в кремнии.

> В моем "амуде" эта фича просто отключается штатным образом из BIOS.

ты не знаешь ни что там отключается, ни отключается ли вообще.
Кстати, какой еще нахрен биос в 2020?

Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

193. "Удалённо эксплуатируемые уязвимости в подсистемах Intel AMT ..."  +2 +/
Сообщение от Клоун Творожок (?), 14-Июн-20, 11:01 
> Нет у тебя там никакого удаленного управления, тебе на те платы в жизни не заработать.

А почему у меня тогда на обычной десктопной плате в локалке появлялся дополнительный сетевой интерфейс и открывался порт на прослушку?
Это что: "удаленное управление" или просто зонд?

> ты не знаешь ни что там отключается, ни отключается ли вообще.

Я знаю, что AMD PSP само не лезет в сеть. Оно просто предоставляет операционной системе Trusted Platform Scurity..., и, его можно попросить не работать.
То, что на дополнительный процессор навешали другие функции и он продолжает их выполнять - отдельный разговор.

> Кстати, какой еще нахрен биос в 2020?

Не придирайтесь к словам. Все поняли о чем речь.

Ответить | Правка | Наверх | Cообщить модератору

214. "Удалённо эксплуатируемые уязвимости в подсистемах Intel AMT ..."  –1 +/
Сообщение от пох. (?), 14-Июн-20, 14:57 
> А почему у меня тогда на обычной десктопной плате в локалке появлялся дополнительный сетевой
> интерфейс

может ты ее из офисного компа сп-л? Воровать нехорошо!
У меня вот ничего не появляется. А хотелось бы, поскольку их в доме сильно не один.

> Это что: "удаленное управление" или просто зонд?

а документацию почитать к плате - не? Предварительно убрав загрузочные носители - а то может и не зонд, а просто хакнул кто твой васянский рачик.

> Я знаю, что AMD PSP само не лезет в сеть.

"знаешь"? Очень навряд ли.
Равно как какие там еще интересные технологии, не слишком афишируемые широкой публике.

psp это какой-то аналог скорее me чем amt, интерфейсом смотрит внутрь твоей системы. Наружу будет смотреть что-то другое. Впрочем, это тоже догадки, а не знание. Вполне могли и совместить.


Ответить | Правка | Наверх | Cообщить модератору

261. "Удалённо эксплуатируемые уязвимости в подсистемах Intel AMT ..."  +/
Сообщение от Аноним (258), 15-Июн-20, 04:18 
> и, его можно попросить не работать.

...однако что он там после этой просьбы де-факто решит сделать - на усмотрение какого-то непонятного мутного блоба без сорцов :)

> То, что на дополнительный процессор навешали другие функции и он продолжает их
> выполнять - отдельный разговор.

Да, может предоставить немного других сервисов, типа "поимения системы" и "дистанционного управления", например. Или демонстрации фиги "сегодня грузиться не будем".

Ответить | Правка | К родителю #193 | Наверх | Cообщить модератору

91. "Удалённо эксплуатируемые уязвимости в подсистемах Intel AMT ..."  +/
Сообщение от Онаним (?), 13-Июн-20, 15:52 
> белки-истерички, напихавшие ipv6

Должны страдать априори, это овнище 30 лет не взлетело, и настолько монструозно-удолбищное, что пора бы уже закопать и сделать IPv7, единственным отличием которого будет ASN в адресе. Да, опять весь софт передалбывать, но по крайней мере базовые протоколы не пострадают, и трансляция делается линейно, ASN 0 = IPv4.

Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

92. "Удалённо эксплуатируемые уязвимости в подсистемах Intel AMT ..."  +/
Сообщение от Онаним (?), 13-Июн-20, 15:52 
// единственным отличием от IPv4 //
Ответить | Правка | Наверх | Cообщить модератору

262. "Удалённо эксплуатируемые уязвимости в подсистемах Intel AMT ..."  –1 +/
Сообщение от Аноним (-), 15-Июн-20, 04:23 
> Должны страдать априори, это овнище 30 лет не взлетело, и настолько монструозно-удолбищное,
> что пора бы уже закопать и сделать IPv7, единственным отличием которого
> будет ASN в адресе. Да, опять весь софт передалбывать, но по
> крайней мере базовые протоколы не пострадают, и трансляция делается линейно, ASN 0 = IPv4.

Извращенское мышление, у вас ничего не получится.
1) ASN и так по сути зашит в префикс ipv6. Однако можно и что-то иное кодировать при желании, ибо прибивать на гвозди одну суб-абстракцию это голимо, если захочется немного переиграть.
2) Ваша структура протокола напрочь не годится для mobile клиентов роамящихся между разными сетями. Оно обречено жестоко отваливаться при любой смене сети.
3) Упомянутый 4 -> 6 вполне практикуется, и есть куча методов разной степени стандартности, не требующих все передалбывать. В чем их жирный плюс относительно вашего подхода.

Ответить | Правка | К родителю #91 | Наверх | Cообщить модератору

268. "Удалённо эксплуатируемые уязвимости в подсистемах Intel AMT ..."  +/
Сообщение от Онаним (?), 15-Июн-20, 09:18 
"и есть куча методов разной степени стандартности"
Вот _отчасти_ поэтому оно и не взлетает.
Потому что в 6 есть "куча методов разной степени стандартности" много для чего.
Плюс откровенные архитектурные просчёты типа /64 на линк.
Ответить | Правка | Наверх | Cообщить модератору

272. "Удалённо эксплуатируемые уязвимости в подсистемах Intel AMT ..."  +/
Сообщение от Аноним (-), 15-Июн-20, 10:05 
> Вот _отчасти_ поэтому оно и не взлетает.

"trampoline works" и ниипет.

> Плюс откровенные архитектурные просчёты типа /64 на линк.

Это как раз отлично придумали, можно раздать по дофига айпи каждому таракану - и потом, если потребуется, еще и с него раздать еще толпе тараканов. И даже с них - их выводкам. И вот это есть круто. Потому что про непотребный ад типа натов можно порсто забыть. И даже у таракана в третьем поколении будет свой айпишник, глобально доступный отовсюду. Что очень удобно для того чтобы позвать вот именно конкнретно этого таракана. Без всяких натов и тем более стремных облаков.

Ответить | Правка | Наверх | Cообщить модератору

274. "Удалённо эксплуатируемые уязвимости в подсистемах Intel AMT ..."  +/
Сообщение от Онаним (?), 15-Июн-20, 10:36 
Речь не о раздаче каждому таракану, а хотя бы о тех же p2p стыках, про которые забыли совершенно.
Про neighbor table тоже немножко подзабыли, и это до сих пор стреляет в ногу оставшимся желающим.

В итоге ныне уже используются изначально вообще не планировавшиеся /126 и прочие костыли, чтобы избежать граблей как раз в этом месте. Т.е. оно выродилось ровно до того, чем и должно быть. И это не последние грабли.

Например у той же Cisco до сих пор нет mixed реализации шейперов-полисеров на концентрации абонентов, они для v4 и v6 раздельные - слишком накладно использовать 128-битные контейнеры для всего, да и CAM-таблица v6 получается очень дорогой, и прилично ограничена по сравнению с v4, что тоже пахнет граблями.

Ответить | Правка | Наверх | Cообщить модератору

279. "Удалённо эксплуатируемые уязвимости в подсистемах Intel AMT ..."  +/
Сообщение от Аноним (279), 15-Июн-20, 12:09 
> Речь не о раздаче каждому таракану, а хотя бы о тех же p2p стыках, про которые забыли совершенно.

Всякие вторичные детали не должны принципиально нагибать работу протокола. Более того - подобная конкретика не должна быть прибита на гвозди, имхо.

Пример: cjdns использует принципиально иные подходы к маршрутизаци и вообще, являясь большой глобальной само- (или не само-) конфигуряемой сетью. И даже вот - это нормально вписывается в сам по себе IPv6 (они работают как супер-сетка 02FC:: чтоли, а остальные 14 байтов тупо рандом, на самом деле часть логики шифрования вообще. Не, пилять, щз уткнемся в ваш конкретный юзкейс и забьем на все остальное. А морда у вас таких красивых не треснет?

> в ногу оставшимся желающим.

Оставшимся? Из-за дефицита ipv4 их за последние годы стало в цать раз больше. У хостеров уже просто некультурно без v6, да и многие провы стали выдавать сие. И таки как видим решили свои проблемы с ним.

> В итоге ныне уже используются изначально вообще не планировавшиеся /126

За это вообще надо навечно в hall of shame интернета заносить как гранд-саботажников, если это клиенту в хоть каком либо виде уходит.

> выродилось ровно до того, чем и должно быть. И это не последние грабли.

Я не знаю что там у кого выродилось, но вон тот пров спокойно выдал мне /56 аж. И тут я могу каждой бактерии в каждом таракане еще айпишники дать, если мне это зачем-то потребуется. Пока не потребуется, но мало ли чего будет через цать лет.

> пахнет граблями.

Я думаю что для подобного прова должен пахнуть граблями уход клиентов. Пров либо решает свои проблемы вместо лепилова отмазок, либо нахрена он такой вообще нужен? Чтобы делать мозг NAT-ами и прочим калом по причине "не смогли решить проблемы с оборудованием"? Вы часом не из ростелекома? Хотя вроде даже эти /64 если не /56 юзерам выдают...

Ответить | Правка | Наверх | Cообщить модератору

303. "Удалённо эксплуатируемые уязвимости в подсистемах Intel AMT ..."  +/
Сообщение от Онаним (?), 15-Июн-20, 20:33 
> Всякие вторичные детали не должны принципиально нагибать работу протокола

Именно. Всякие вторичные протоколы не должны нагибать работу PPP и использовать левые механизмы для конфигурации. Нет, для желающих эти протоколы возможны, но пока что - за отдельную денежку :)

> пилять, щз уткнемся в ваш конкретный юзкейс и забьем на все остальное. А морда у вас таких красивых не треснет

Неа, не треснет. Останетесь без желанной связности с вашим блекджеком и пойдёте выбирать ISP из полутора оставшихся доступных, которые готовы конкретно ваш юзкейс реализовать. Причём они с вами тоже лояльничать не будут, и скорее всего только за дополнительные деньги, потому что единичные кастомные юзкейсы - это геморрой для поддержки.

Впрочем, мы тоже за дополнительные деньги делаем разные варианты. Если не совсем извращение. Естественно, если без PPP - никакого xDSL не будет - только выделенная оптика, с соответствующей стоимостью. В лучшем случае GPON, с отдельным VLAN, аренда которого до premises тоже не бесплатна, хотя конечно даётся "бесплатно", просто вбивается в общий ценник.

> если это клиенту в хоть каком либо виде уходит

Клиенту это уходит, просто клиент этого не знает, за его CPE он видит свои /64. Но между доступом и CPE - /126.

/56 конечно выдаётся по запросу. Поверх /126, о котором клиент снова не в курсе. Но на IPv6 подключениях обязательна аренда CPE :)

Ответить | Правка | Наверх | Cообщить модератору

320. "Удалённо эксплуатируемые уязвимости в подсистемах Intel AMT ..."  +/
Сообщение от Аноним (-), 17-Июн-20, 09:53 
> Именно. Всякие вторичные протоколы не должны нагибать работу PPP

Я бы сказал что этот пережиток диалапа стремительно отмирает. Даже в сотовых свистках уже.

> и использовать левые механизмы для конфигурации.

Это, наверное, про PPP. Вот это действительно абсолютно левый механизм, с кучей оверхеда и как таковой - левая нашлепка. Даром не нужная в ethernet, fiber и проч.

> Нет, для желающих эти протоколы возможны, но пока что - за отдельную денежку :)

Надо еще за каждый айпишник IPv6 стричь, чтобы сетевики совсем репутацию прову слили в дно.

> выбирать ISP из полутора оставшихся доступных, которые готовы конкретно ваш юзкейс реализовать.

Если это единственный вариант чтобы нормально работало - да будет так. А вы тогда умрете от отсутствия клиентов. И при всей симпатии к конкуренции, такого прова жалко не будет. Если кто не умеет работать - так и нечего людям нервы портить своими эрзац-костылями.

> всего только за дополнительные деньги, потому что единичные кастомные юзкейсы -
> это геморрой для поддержки.

Чего? Какие деньги? Во всех случаях которые мне попадались ipv6 был просто небольшим приятным бонусом к остальным услугам, о котором вообще узнавалось из морды роутера - "о, роутер раздал v6 на всю ораву".

> Впрочем, мы тоже за дополнительные деньги делаем разные варианты.

А за воздух заплатить не надо? ИМХО платить за то что в RFC прописано как mandatory - это самый эпичный булшит который я вообще встречал. Задвигающий даже ростелеком за спину.

> отдельным VLAN, аренда которого до premises тоже не бесплатна, хотя конечно
> даётся "бесплатно", просто вбивается в общий ценник.

Интересно, много болванов доплачивает за абстрактные циферки, при том что они даже и не лимитированы ничем, кроме крайней степени о...я провайдера? :)

> видит свои /64. Но между доступом и CPE - /126.

Собственно если юзерь свой /64 получает и это работает - и черт с ним. А если у юзера дюжина гаджетов, их айпишники в итоге пролезают за его premises? Или начинается камасутра как с V4, убивающая на корню весь пойнт долботни?

> /56 конечно выдаётся по запросу. Поверх /126, о котором клиент снова не
> в курсе. Но на IPv6 подключениях обязательна аренда CPE :)

Судя по описанию - какой-то ультрагеморройный пров, пытающися продавать воздух. В расфасовке по миллилитру. Как будто блин воздуха на глобусе адский дефицит.

Ответить | Правка | Наверх | Cообщить модератору

321. "Удалённо эксплуатируемые уязвимости в подсистемах Intel AMT ..."  +/
Сообщение от Онаним (?), 17-Июн-20, 10:47 
> вы тогда умрете от отсутствия клиентов. И при всей симпатии к конкуренции, такого прова жалко не будет

Понимаешь, в чём дело? Реальность такова, что для 99% - реально 99%, я не шучу, и даже на несколько десятых долей больше (!) пользователей, причём вне зависимости - домашних или корпоративных - наличие или отсутствие IPv6 на их подключении ныне полностью безразлично :)

Такие дела.

> ipv6 был просто небольшим приятным бонусом к остальным услугам
> Интересно, много болванов доплачивает за абстрактные циферки, при том что они даже и не лимитированы ничем, кроме крайней степени о...я провайдера?

Кому нужно - доплачивают. Абстрактные цифирки это только у вас, где каждый пров тянет свою бухту соплей до каждой квартиры, превращая парадные домов в логово паука.

В Европе чуть по-другому дело обстоит, ты платишь оператору последней мили за проброс клиента до твоего оборудования. За типовой проброс, который не требует дополнительной конфигурации по цепочке оборудования - платишь мало. За отдельный VLAN клиенту, пожелавшему странного, платишь больше.

Такие дела.

> Собственно если юзерь свой /64 получает и это работает - и черт с ним. А если у юзера дюжина гаджетов, их айпишники в итоге пролезают за его premises? Или начинается камасутра как с V4, убивающая на корню весь пойнт долботни?

Не, с этим-то у нас всё нормально. /64 "честный". /126 нужны для того, чтобы камасутра у клиента или у пожелавших чего-нибудь сDDoS'ить не захламила neighbor table на стыковом роутере или BRAS. Клиентская CPE для таких клиентов ставится по той же причине, она может ложиться под v6 DDoS сколько угодно, главное, чтобы это PE не затронуло.

Ответить | Правка | Наверх | Cообщить модератору

342. "Удалённо эксплуатируемые уязвимости в подсистемах Intel AMT ..."  +/
Сообщение от Аноним (-), 21-Июн-20, 19:45 
> Понимаешь, в чём дело? Реальность такова, что для 99% - реально 99%,
> я не шучу, и даже на несколько десятых долей больше (!)

Я думаю что желающих хотя-бы полноценно качать торенты уже заметно больше чем это.

> Кому нужно - доплачивают. Абстрактные цифирки это только у вас, где каждый
> пров тянет свою бухту соплей до каждой квартиры, превращая парадные домов в логово паука.

Может и небухих монтажеров отдельно оплатить?

> дополнительной конфигурации по цепочке оборудования - платишь мало. За отдельный VLAN
> клиенту, пожелавшему странного, платишь больше.

Але, гараж, у меня навалом знакомых европейцев - и им просто отсыпали v6 по дефолту.

> Такие дела.

Ога, втереть лапшу не получилось -> фэйл.

> захламила neighbor table на стыковом роутере или BRAS.

Ну собственно если оно на юзере не отражается - то и хрен с ним.

> Клиентская CPE для таких клиентов ставится по той же причине, она может ложиться под
> v6 DDoS сколько угодно, главное, чтобы это PE не затронуло.

А вот на клиентакие cpe лично я смотрю волком - если пров будет настаивать, ну, я прова сменю. Пардон, эпоха AT&T с только их телефонами в линию все же закончилась. Хотя я так понимаю что вам просто интересно чтобы с провода юзера в вас не лезли neighbor req/sol.

Ответить | Правка | Наверх | Cообщить модератору

344. "Удалённо эксплуатируемые уязвимости в подсистемах Intel AMT ..."  +/
Сообщение от Онаним (?), 21-Июн-20, 20:51 
> Я думаю что желающих хотя-бы полноценно качать торенты уже заметно больше чем это.

Если NAT-роутер не совсем анален, и не берёт на себя лишних функций - hole punching работает за NAT спокойно.

Да, проблема с NAT есть. Но v6 - ни разу не решение, даже у нас были жалобы от клиентов с v6, что скорость торрентов никакая в сравнении с v4. Посмотрели - всё правильно, маршрутизация v6, как обычно, идёт через задницу или через туннели. Ну а что вы хотели (с)?

> Может и небухих монтажеров отдельно оплатить?

У нас бухих монтажёров нет, но стоят они действительно далеко не как в "этой стране". В основном сдельные, и каждый монтажёр реально обходится в суровую копеечку, поэтому стараемся делать так, чтобы лишних выездов не требовалось.

> А вот на клиентакие cpe лично я смотрю волком - если пров будет настаивать, ну, я прова сменю.

Не смените. И даже несертифицированную CPE не поставите - оператор физической последней мили не позволит. Судя по всему, нет у вас знакомых европейцев, втереть лапшу не получилось -> фэйл.

Ответить | Правка | Наверх | Cообщить модератору

324. "Удалённо эксплуатируемые уязвимости в подсистемах Intel AMT ..."  +/
Сообщение от Онаним (?), 18-Июн-20, 08:25 
> Я бы сказал что этот пережиток диалапа стремительно отмирает. Даже в сотовых свистках уже.

Это про 4G? Я секрет открою, там вообще PPPoL2TPv3 зачастую.
Просто его пользователям не показывают, зачем им это? :)

Ответить | Правка | К родителю #320 | Наверх | Cообщить модератору

332. "Удалённо эксплуатируемые уязвимости в подсистемах Intel AMT ..."  +/
Сообщение от Аноним (-), 19-Июн-20, 19:32 
> Это про 4G? Я секрет открою, там вообще PPPoL2TPv3 зачастую.

Цитату спеков ETSI на эту тему не затруднит?

> Просто его пользователям не показывают, зачем им это? :)

Им не только не показывают - но и вывешивают совсем иные протоколы. И да, юзерам это низачем - на 100 мегабитах это недоразумение проц грузит.

Ответить | Правка | Наверх | Cообщить модератору

333. "Удалённо эксплуатируемые уязвимости в подсистемах Intel AMT ..."  +/
Сообщение от Онаним (?), 19-Июн-20, 20:31 
> Цитату спеков ETSI на эту тему не затруднит?

Google LAC LNS


Ответить | Правка | Наверх | Cообщить модератору

334. "Удалённо эксплуатируемые уязвимости в подсистемах Intel AMT ..."  +/
Сообщение от Онаним (?), 19-Июн-20, 20:31 
Если интересны вендоры - эрик, нокла, там это стандартный механизм передачи данных на APN.
Ответить | Правка | К родителю #333 | Наверх | Cообщить модератору

275. "Удалённо эксплуатируемые уязвимости в подсистемах Intel AMT ..."  +/
Сообщение от Онаним (?), 15-Июн-20, 10:38 
Автоконфигурация на линках, особенно на p2p - вообще блеск. Про PPP забыли.
Поддерживать SLAAC или DHCPv6 процесс для каждого абонента - это прекрасно.
Ответить | Правка | К родителю #272 | Наверх | Cообщить модератору

282. "Удалённо эксплуатируемые уязвимости в подсистемах Intel AMT ..."  +/
Сообщение от Аноним (279), 15-Июн-20, 12:15 
> Автоконфигурация на линках, особенно на p2p - вообще блеск.

А таки более или менее работает.

> Про PPP забыли.

Давно пора, пережиток диалапа. На него уже даже 4G модемы забили - проц жрет как не в себя на такие скорости.

> Поддерживать SLAAC или DHCPv6 процесс для каждого абонента - это прекрасно.

Не развалитесь, имхо. Или освободите рынок тому кто все это сможет. Нахрен нужен пров занимающийся отмазками и перепихиванием проблем на клиентов?

Ответить | Правка | Наверх | Cообщить модератору

302. "Удалённо эксплуатируемые уязвимости в подсистемах Intel AMT ..."  +/
Сообщение от Онаним (?), 15-Июн-20, 20:25 
Ни хрена она не работает. Выносится полностью и делается /126 с маршрутами. Не боящиеся возможности суровой атаки на оконечки делают поверх link-адресов делегацию, но это просто пока IPv6 даже спамеры ещё всерьёз не воспринимают, и никто всерьёз не занялся.

Про PPP никто не забыл, на xPON и xDSL PPP всё так же во все поля, без каких либо изменений. А за xPON будущее сейчас, тaщемта. Да и таже на FTTB/ETH у IPoE фигова туча проблем.

> освободите рынок тому кто все это сможет

Думаю, это произойдёт как раз с v6. Потому что вендоры оборудования тоже всерьёз подтягиваться перестали, больших улучшений по части юзабилити уже лет 5 как нет.

Ответить | Правка | Наверх | Cообщить модератору

319. "Удалённо эксплуатируемые уязвимости в подсистемах Intel AMT ..."  +/
Сообщение от Аноним (319), 17-Июн-20, 09:42 
> Не боящиеся возможности суровой атаки на оконечки делают поверх link-адресов делегацию,
> но это просто пока IPv6 даже спамеры ещё всерьёз не воспринимают,
> и никто всерьёз не занялся.

Пардон, все что я вообще встречал было /56, /60 или у совсем жадюг /64 на юзеря. И таки я думаю что если юзерь удумает озвереть - ну, нормальные провы нарулят постепенно мониторинг особо озверелых и будут им порт тушить. Сие они оспорить смогут только в спортлото.

А спамеры что? Вот как раз все /64 и лупят тапком. А то что у вас таких умных там под раздачу может попасть хрен знает кто и как - да это ваши проблемы, вы RFC нарушили. Никто не будет вас учитывать.

> Про PPP никто не забыл, на xPON и xDSL PPP всё так же во все поля,

DSL уже тоже почти сдох, когда по проводу лезет меньше чем по 3g свистку, смысл в таком проводе равен нулю. Pon - что-то не помню там ppp, там скорости уже не те. PPP видите ли довольно наворочен в парсинге и для современных скоростей не рулит. Даже 4G свистки от него по этой причине отказались - слишком ресурсоемко.

> без каких либо изменений. А за xPON будущее сейчас, тaщемта. Да и таже на
> FTTB/ETH у IPoE фигова туча проблем.

Обычно ppp используют голимые провы которые не смогли в управляемые свичи и прочее вменяемое оборудование.

> Думаю, это произойдёт как раз с v6.

По нему не заметно. Душняк с v4 адресами провоцирует довольно активное внедрение.

> Потому что вендоры оборудования тоже всерьёз подтягиваться перестали,
> больших улучшений по части юзабилити уже лет 5 как нет.

Правильно, потому что оно уже просто берет и работает последние лет 5. Эпоха расколбасов прошла, началась эпоха эксплуатации.

Ответить | Правка | Наверх | Cообщить модератору

323. "Удалённо эксплуатируемые уязвимости в подсистемах Intel AMT ..."  +/
Сообщение от Онаним (?), 17-Июн-20, 22:28 
> Пардон, все что я вообще встречал было /56, /60 или у совсем жадюг /64 на юзеря

Это немножко не то, ну да ладно. В v6 предполагалось /64 минимум на те же p2p интерфейсы, а это бред.

> удумает озвереть - ну, нормальные провы нарулят постепенно мониторинг особо озверелых и будут им порт тушить

Ну в общем так и делается, вот только "потушить порт" может и удалённый атакующий, просто создав проблемы.

> Обычно ppp используют голимые провы которые не смогли в управляемые свичи и
> прочее вменяемое оборудование.

В Европе вообще пачки свитчей не канают, от слова "совсем". Да и в этой стране здоровые провы используют окончания xGxPON/xDSL, ростелеком например. А там PPPoE поверх - очень себе удобно и by design, юзер его всё равно толком не видит, рядовой юзер видит порт с внутренним IP-адресом от роутера, те, кому хочется больше - пинают прова дать мост и инициируют PPPoE сами.

> Эпоха расколбасов прошла, началась эпоха эксплуатации.

Сейчас только эпоха сексплуатации, и сексу много. Настолько много, что пока живёт только как альтернатива для тех, кто страждет этот геморрой иметь.

Ответить | Правка | Наверх | Cообщить модератору

276. "Удалённо эксплуатируемые уязвимости в подсистемах Intel AMT ..."  –1 +/
Сообщение от Онаним (?), 15-Июн-20, 10:39 
> "trampoline works" и ниипет.

30 лет уже как works, а воз и ныне там.
Но в принципе да - пока реально ниип*т, всё равно спрос на IPv6 у абонентов мизерный, а с полутора желающими справляется и текущее оборудование.

Ответить | Правка | К родителю #272 | Наверх | Cообщить модератору

285. "Удалённо эксплуатируемые уязвимости в подсистемах Intel AMT ..."  –1 +/
Сообщение от Аноним (-), 15-Июн-20, 12:27 
> 30 лет уже как works, а воз и ныне там.

В смысле - там? У меня он - works, везде где мне это надо. А то что кто-то там видите ли до сих пор на дровах ездит - ну, мало ли.

> IPv6 у абонентов мизерный, а с полутора желающими справляется и текущее оборудование.

Ну как мизерный, у хостингов уже душновато с V4, скоро его совсем не останется и новые серваки будут вводить с V6-only наверное, а чего еще то?! И поэтому клиенты с V6 будут в явном преимуществе, им более жирные группы серверов будут доставаться. А ряд провов вообще по сути V4 и не выдают, используя как раз забавные выходки с трансляцией, когда весь V4 оформлен как /96 в какой-нибудь подсеточке, всего-то навсего.

Ответить | Правка | Наверх | Cообщить модератору

277. "Удалённо эксплуатируемые уязвимости в подсистемах Intel AMT ..."  +/
Сообщение от Онаним (?), 15-Июн-20, 10:45 
А про тараканов - там есть ещё и обратные проблемы, о которых чтобы знать - надо о них думать.
Я только одну приведу.
Например репутационные системы антиспамов кидают и будут кидать в блоклист минимум /64. То есть тут никакого конкретного разделения тараканов не было не предвидится, при первом чихе - сразу тапком по всему стаду.
Ответить | Правка | К родителю #272 | Наверх | Cообщить модератору

283. "Удалённо эксплуатируемые уязвимости в подсистемах Intel AMT ..."  +/
Сообщение от Аноним (-), 15-Июн-20, 12:22 
> Например репутационные системы антиспамов кидают и будут кидать в блоклист минимум /64.

И это в принципе логично. Потому что /64 это минимальный выдаваемый клиенту юнит. BY DESIGN - в RFC так написано! Если какой-то кретин удумал отгрузить клиенту меньше чем это - его надо уволить с волчьим билетом, за неспособносить хотя-бы RFC на протокол прочесть.

> То есть тут никакого конкретного разделения тараканов не было не предвидится,
> при первом чихе - сразу тапком по всему стаду.

Предполагается что вся эта стайка более-менее рулится одним персонажем или группкой таковых, плюс-минус. На уровне спеков стандарта.


Ответить | Правка | Наверх | Cообщить модератору

301. "Удалённо эксплуатируемые уязвимости в подсистемах Intel AMT ..."  +/
Сообщение от Онаним (?), 15-Июн-20, 20:20 
Полно ныне клиентов с отгруженным /126, и дальше маршрутами поверх такового, потому, что только вышеописанный индивид мог придумать и единичным оконечкам в p2p давать /64. Понимаешь в чём дело, neighbor table, а память не резиновая.
Ответить | Правка | Наверх | Cообщить модератору

318. "Удалённо эксплуатируемые уязвимости в подсистемах Intel AMT ..."  +/
Сообщение от Аноним (-), 17-Июн-20, 09:26 
> Полно ныне клиентов с отгруженным /126,

Ни разу в жизни не встречал. Но если вдруг попадется - посоветую юзеру сменить такого провайдера. Але, при этом каждый девайс не сможет получить свой адрес. И чего, с nat'ом извращаться? На ipv6? Да вы с дубу рухнули.

> что только вышеописанный индивид мог придумать и единичным оконечкам в p2p давать /64.

Это придумал RFC. Имея на то хорошие причины. Там в отличие от вас относительно вменяемые люди разрабатывали. По крайней мере - по сравнению с вами.

> Понимаешь в чём дело, neighbor table, а память не резиновая.

Понимаете ли в чем дело, для юзерей нормально юзать дюжину гаджетов - и невозможность дать каждому свой айпи нагибает азы коммуникаций. Вынуждая к порнографии с натами, облаками, гуглодрайвами и прочим непотребством. Поэтому будем лить гигазы видео через половину глобуса вместо своего роутера, по причине "адресов не хватило". В 128 битном, ...,  пространстве, ... %$# @#$%! В общем, на мыло таких провайдеров: не умеешь работать - не берись. Даже гребаный ростелеком может компенетнтее этого позора, так что я не понимаю зачем нужно такое адское дно.

Ответить | Правка | Наверх | Cообщить модератору

322. "Удалённо эксплуатируемые уязвимости в подсистемах Intel AMT ..."  +/
Сообщение от Онаним (?), 17-Июн-20, 20:12 
> Але, при этом каждый девайс не сможет получить свой адрес

Сможет, поверх /126 отгружается маршрутом /64, но на стыке именно /126, а не /64. /64 суётся на клиентскую CPE или куда там клиент хочет, за demarcation point - в итоге все проблемы с засиранием neighbor table происходят там, в ЗО клиента, а не на роутере ISP.

Ответить | Правка | Наверх | Cообщить модератору

343. "Удалённо эксплуатируемые уязвимости в подсистемах Intel AMT ..."  +/
Сообщение от Аноним (343), 21-Июн-20, 20:19 
Я какжется понял - вы не хотите всю толпу neighbors в том /64 на свою железку из опасений что их может дофига оказаться. Какой-то из хостеров просил больше 32 ip одновременно не жрать, видимо из тех же соображений - мол, больше - после обсуждения.
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру