Опубликована техника атаки (CVE-2019-14899), позволяющая подменить, изменить или подставить пакеты в TCP-соединения, пробрасываемые через VPN-туннели. Проблема затрагивает Linux, FreeBSD, OpenBSD, Android, macOS, iOS и другие Unix-подобные системы, поддерживающие технику защиты от спуфинга rp_filter (reverse path filtering) для IPv4. Для IPv6 атака может быть совершена независимо от применения rp_filter...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=51986
/*Для IPv4 атака возможна в случае перевода rp_filter в режим "Loose" (sysctl net.ipv4.conf.all.rp_filter = 2). Изначально в большинстве систем применялся режим "Strict", но начиная с systemd 240, выпущенного в декабре прошлого года, режим работы по умолчанию был заменён на "Loose" и данное изменение отразилось в настройках по умолчанию многих дистрибутивов Linux.
*/
cчитaeм этo шикapнo
И в этом тоже systemd виноват?
тут налицо вина сисдамина!
Да, можно и тае сказать. А вот не надо было идти на поводу.
А разве нет? Почитайте текст в оригинале. Таки да.
notabug, closed!
Угу, ожидаемое следствие когда решения о настройках по умолчанию принимают дилетанты (то есть авторы systemd).
Ну так где были не дилетанты? Вы же, не дилетанты, знали что вот-вот в режиме Loose будет обнаружена уязвимость. Знали ведь, да? А почему молчали?
Потому что я не нанимался тестировщиком systemd
По умолчанию должен быть сторогий режим. Админ на свой стах и риск может понижать его.
И ведь действительно, в GRUB же дистрибутивы не приписывают по-умолчанию отключение тормозилок для интела (ну и амд):
GRUB_CMDLINE_LINUX_DEFAULT="quiet"Уверен сам - вот и дописывай сам на свой страх и риск:
GRUB_CMDLINE_LINUX_DEFAULT="quiet mitigations=off"
Не-дилетанты используют Икспишечку. ;)
Windows XP has implemented the weak host model [RFC1122] on IPv4
> Windows XP has implemented the weak host model [RFC1122] on IPv4И?
> Не-дилетанты используют Икспишечку. ;)Может еще и IE6? А то у меня как раз в бэкапах эксплойт для активиксов нашелся.
>> Не-дилетанты используют Икспишечку. ;)
> Может еще и IE6? А то у меня как раз в бэкапах
> эксплойт для активиксов нашелся.Давай. Я его запущу и покажу результат.
ХЗ, лично мне казалось очевидным, что любой режим, кроме strict, это по умолчанию уязвимая к таким атакам система. И даже мысли не было, что это необходимо кому-то разжёвывать.
И по этому режим по умолчанию сначала был strict. Но потом его сменили на loose, и сменили условно у всех через обновления, другими словами удалённо ослабили защиту. И год никто не знал, что это уязвимо... Как бы никто не знал, это должно выглядеть так, что ”никто не знал..","обнаружили...", "оказывается..." "Нас поосто год не было.. Мы разрабатываем это.. но мы не знаем"
И чем же, спрашивается, это лучше десяточки от Майкрософта?
Такое же отношение в плане безопасности и принудительных обновлений...
> Значение sysctl "net.ipv4.conf.all.rp_filter" теперь по умолчанию выставляется в значение 2 (устанавливается режим Loose вместо Strict), что более приемлемо для хостов с несколькими сетевыми линками, маршрутизируемыми через одну сеть (например, когда клиент одновременно подключен через Wi-Fi и Ethernet);Да, это явно внедряемая уязвимость с расчётом на то, что большинство пользователей используют настройки по умолчанию.
Уточним: в этом виноваты создатели системды.
Нет, авторы его концепции - что пироги и сапоги может строгать один комбайнер.
Систамм да стал использовать балансировку нагрузки по умолчанию или что? Есть же какой-то смысл в этом?
А ничего, что в системах, не использующих systemd, rp_filter вообще 0, т.е. выключен? См. ниже в исходном сообщении об уязвимости:
**Operating Systems Affected:Here is a list of the operating systems we have tested which are
vulnerable to this attack:...
Devuan (sysV init)
MX Linux 19 (Mepis+antiX)
Void Linux (runit)Slackware 14.2 (rc.d)
И как это оправдывает авторов systemd?
А при чём здесь вообще systemd? Уязвимость в systemd? - нет, не в systemd. Значение rp_filter == 2 некорректно? - нет, корректно. В системах без systemd уязвимости нет? - есть. Так в чём в данном случае вина systemd?Я понимаю, что systemd на данном ресурсе многие люто ненавидят - но должна же быть объективность, тем более у тех, кто считает себя людьми с аналитическим складом ума. "Кошка бросила котят - systemd тут виноват" - это позиция людей, у которых эмоциональная компонента преобладает над разумом.
> А при чём здесь вообще systemd? Уязвимость в systemd? - нет, не в systemd.если я неткатом проброшу 23й порт напрямую в рутовый шел - это уязвимость в netcat, шелле или таки руках того кто создал такую конструкцию?
до системды ничем не воняло - кому надо, тот и так знал, что особенность линуксного ядра (скопипащеная сейчас почти всеми) - принимать пакеты на _любой_ из принадлежащих хосту адресов через любой интерфейс, а не только тот, которому принадлежит адрес.
Конфигурация ядра по умолчанию была безопасна. Любитель "как в винде" в очередной раз залез руками куда не надо. Причем бы тут вообще, действительно, его рукожопие, виновато ядро!
> Конфигурация ядра по умолчанию была безопасна.В дистрибутивах, не использующих systemd, используется как раз конфигурация ядра по умолчанию: rp_filter == 0. При этом они тоже подвержены данной уязвимости, что указано в оригинальном сообщении. Вопрос: каким образом уязвимая конфигурация по умолчанию превратилась у вас в безопасную?
> В дистрибутивах, не использующих systemd, используется как раз конфигурация ядра по умолчанию:grep rp_filter /etc/sysctl.conf
net.ipv4.conf.all.rp_filter = 1
таким, примерно. Это дистрибутивный конфиг.
Нормального дистрибутива, конечно, а не слаквари.
> Это дистрибутивный конфиг.Сначала заявили про безопасную конфигурацию *ядра* по умолчанию, а теперь вдруг про дистрибутивные модификации заговорили...
> Нормального дистрибутива, конечно, а не слаквари.
Как называется этот "нормальный дистрибутив"?
>> В дистрибутивах, не использующих systemd, используется как раз конфигурация ядра по умолчанию:
> grep rp_filter /etc/sysctl.conf
> net.ipv4.conf.all.rp_filter = 1
> таким, примерно. Это дистрибутивный конфиг.
> Нормального дистрибутива, конечно, а не слаквари.Оговорка нужная. // Чтоб вы понимали, анонимы, почему я говорю, что пох знаёт всё. :)
В Девуане так, как ты написал, но строки закомментированы:
#net.ipv4.conf.default.rp_filter=1
#net.ipv4.conf.all.rp_filter=1В RHEL 4 строка одна и не закомментирована:
net.ipv4.conf.all.rp_filter = 1
> # sysctl net.ipv4.conf.all.rp_filter
> net.ipv4.conf.all.rp_filter = 1openSUSE. Почему-то systemd не помешал мэйнтейнеру поменять значение на "Strict".
>> # sysctl net.ipv4.conf.all.rp_filter
>> net.ipv4.conf.all.rp_filter = 1
> openSUSE. Почему-то systemd не помешал мэйнтейнеру поменять значение на "Strict".Системда помешала SUSE жить и развиваться. Конвульсии вызывают сожаления и взывают к состраданию, но помочь умирающему, увы, мы ничем не можем.
Пруфы буду про конвульсии? А пока я вижу, что в Сусе пакеты новее, чем в Дебиане, но "умирает" почему-то Суся.
Какие же дeбилы линуксоиды. Пока не было интернета, не знал, что на свете столько идиoтoв.
> Пруфы буду про конвульсии? А пока я вижу, что в Сусе пакеты
> новее, чем в Дебиане, но "умирает" почему-то Суся.
> Какие же дeбилы линуксоиды. Пока не было интернета, не знал, что на
> свете столько идиoтoв.ERROR: Peer certificate cannot be autentificated with known CA certificates: (60)
>> Пруфы буду про конвульсии? А пока я вижу, что в Сусе пакеты
>> новее, чем в Дебиане, но "умирает" почему-то Суся.
>> Какие же дeбилы линуксоиды. Пока не было интернета, не знал, что на
>> свете столько идиoтoв.
> ERROR: Peer certificate cannot be autentificated with known CA certificates: (60)ЗЫ
These products have reached their end of general support
and thus do not provide new updates anymore.In case that your subscription contains extended support,
please make sure that you have activated the extension.Contact us if you need further assistance.
SUSE Linux Enterprose Server 11 SP4
Умерло, пишут, закапывай.
>Значение rp_filter == 2 некорректно?Для систем на которых поднят vpn некорректно, причем systemD в курсе подняты они или нет. Очередной пример того что его лабают и нахваливают те, кто в нем не разбирается.
> Для систем на которых поднят vpn некорректноАргументируйте, почему rp_filter == 0 корректно, а более строгое rp_filter == 2 - вдруг некорректно. Или же придётся, кинув камень в systemd, кинуть гораздо больший камень в разработчиков ядра.
https://github.com/systemd/systemd/commit/230450d4e4f - описание, зачем была сделана права с 2 на 1, читали? Я понял, что чтобы VPN-соединение продолжило работать, когда с Wi-Fi переключились на кабель, например. Сомнительный юзкейс.
> когда с Wi-Fi переключились на кабель, например. Сомнительный юзкейс.Это когда гребёшь на работе с ноута подключённого кабелем, затем отключаешь его и несёшь в переговорку на митинг, отчитаться о проделаной работе за день. Лёня так каждый день делает.
А как они получают ключ, длинной, например, 2048 бит ?, ведь openvpn по сути это udp(например) инкапсулированный в ip.
ip доставляется через сеть интернет, демультиплексирует udp, а вот его содержимое уже шифровано, и расшифрованно может быть только при помощи ключа, ну после расшифровки мы опять получаем ip, но уже виртуальный, вида 10.8.0.1, а в нем инкапсулированное tcp/udp/icmp.
Причем ключ никуда не передается, он серкретный, просто им на месте данные шифруются, а на удаленной стороне расшифровываются.
В том-то и дело, что ни ключ, ни логин-пароль не нужны. Пакет прилетает из внешнего интерфейса, а ядро воспринимает его как пакет из VPN-интерфейса.
Но тогда причем тут ВПН, если точно так же можно подделать ТСП и без ВПНа ? (но по факту надо подобрать 2 пары ip/порт и номера seq, все это и так известно 100500 лет как, но не очень просто реализуется на сколько то нагруженных концах соединения)
vpn тут притом, что траффику из vpn'а обычно доверяют (речь, если что, Васян, не о твоей порнухе с малолетками, а о корпоративных vpn, наивно полагаемых многими - надежным средством связи через ненадежные каналы)
Почему «наивно»?
то есть если vpn основан на udp а не на tcp - данный метод не сработает ?
Вообще для атаки нужно, чтобы под контролем был роутер, роутер подключенный к компу жертвы - вопрос при чему тут vpn вообще ?
сработает. Подделать можно - только udp, тот что внутри vpn - для tcp слишком много надо знать, и ответный пакет все равно не получишь.При том что пользователи vpn и админы vpn-хабов обычно полагают траффик, приходящий с внутривпнских адресов - доверенным. Более того, типовые железо и софт очень непросто перенастроить по-другому.
(что на них никогда и низачто не должно быть отключенного rp-filter - неважно, поцтеринг уже позаботился о тех из них, кто по дурости использовал наколеночное линукс-решение вместо железки.)
Они пишут сразу в декодированный канал, что там н6а уровне шифрования им фиолетово.
насколько понимаю, на *BSD со включенным в pf antispoof - работать не будет, а ведь там, где есть pf - обычно есть и antispoof из файла-примера по умолчанию...
Не увидел бага. Это особенность.
Rp filter отключается только на маршрутизаторах с асинхронным трафиком. Отключать rp filter на оконечных устройствах tcp сессий - как бы говорит об уровне компетенции дистростроителей.
полагаю, стильномодномолодёжные девляпсы не поймут.
у нормальных людей это брандмауером прикрывается на этапе проектирования. а те кто доверяет шлюзу провайдера и принимает с него даже для внутреенних ип - ссзб
нет идеальных людей... не одно, так другое...кто-то доверяет провайдерским шлюзам, а кто-то проприетарным биосам/уефи, не заморачиваясь прошивкой коребута...
идеальных людей нет. но есть (пока еще) квалифицированные специалисты.
нету. В смысле, в IT - уже нету. Кинолога одного знаю.
>Отключать rp filter на оконечных устройствах tcp сессий - как бы говорит об уровне компетенции дистростроителей.Это дефолтная фишка systemd -- поднаcрать там где не ждали.
Ох, как я с Вами согласен!
>>Отключать rp filter на оконечных устройствах tcp сессий - как бы говорит об уровне компетенции дистростроителей.
> Это дефолтная фишка systemd -- поднаcрать там где не ждали.Теперь даже до
"FreeBSD, OpenBSD, [...] macOS, iOS и другие Unix-подобные системы"
долетает. "щикарно", да...
Для этого, а точнее не (только) этого, а и много чего еще (например не давать своим юзерам быть DDoS'ерами), много лет как существует ipfw verrevpath.
и - для любителей last match, хитрых policy NAT'ов и гигантских таблиц - antispoof quick в pf.conf
> и - для любителей last match, хитрых policy NAT'ов и гигантских таблиц
> - antispoof quick в pf.conf# ipfw show | grep anti
00010 14 882 deny ip from any to any not antispoof in
что у вас за устаревшая немодная вонючая портянка в конце текста и что она вообще означает? Мы понимаем только синтаксис nft!(К сожалению, прекрасная утилита iptables-translate выдала только какую-то х-ню при попытке интерпретировать вашу портянку.)
Значит она пока не такая прекрасная, как хотелось бы.
> Значит она пока не такая прекрасная, как хотелось бы.в соседней новости с вами не согласны ;-)
(скормил, чисто поржать. Результат, в общем, неудивительный.)
> что у вас за устаревшая немодная вонючая портянка в конце текста и что она вообще означает?О, ДеВоПсЫ подтянулись.
>> что у вас за устаревшая немодная вонючая портянка в конце текста и что она вообще означает?
> О, ДеВоПсЫ подтянулись.девопсы правила фиревола руками не пишут - у них на то доскер в доскере под управлением впопенштифта есть. Он за них все настроит, и безопастность обеспечит, им незачем эту новость читать, да и слов понятных тут нет - "кажется, это куда-то в сетевой отдел".
У правильного девопа вообще нет фаервола
потому как это не задача девопса вообще,
его задача показать красивый график, и,
чтоб все вроде как работало. Да и мало вероятно
что девопс вообще знает что это - вы про монги и тп
открытые без авторизации не слышали что ли?
дык, у самого монга такая же. Если ее закрыть - она, внезапно, и работать не будет.А авторизацию - это надо положить прод, надолго - и непонятно, каков будет результат. Не говоря уже о том что авторизация в ha-кластере этой монги - это сплошная попоболь в принципе.
Она тебе еще и тормозов добавит туда, где их как раз быть не должно.
Так что - улыбаемся и машем, парни. В конце-концов, всегда можно прикинуться ту...м девляпсом, который просто не ведает что творит. Сказали поставь монгу - поставил монгу. А поскольку она не работала - sudo firewall-cmd --permanent --add-port=27017/tcp ; sudo firewall-cmd --reload - понятия не имею, что это такое, но на stackoverflow так было написано!
вот это дельная вещь - допишу в ТЗ коллегам
а то чот у них не запускается монга-то
Спасибо
> ДеВоПсЫДевоПсы! Сначала РедхатОвцы а потом и ДебианОвцы.
> К сожалению, прекрасная утилита iptables-translate выдала только какую-то х-ню при попытке интерпретировать вашу портянку.Сам iptables по умолчанию работает через nftables, если дистрибутив явно не взял iptables-legacy как умолчание.
> iptables-nft -t raw -I PREROUTING ! -i wg0 -d 10.182.12.8 -m addrtype ! --src-type LOCAL -j DROPБерём сию команду, после неё выполняем "nft list ruleset", адаптируем увиденное под стиль команд и вуаля:
> nft add table ip raw
> nft add chain ip raw prerouting '{ type filter hook prerouting priority 0; }'
> nft add rule ip raw prerouting 'iifname != "wg0" ip daddr 10.182.12.8 fib saddr type != local drop'Всё, выглядит вполне прилично.
> Всё, выглядит вполне приличноВыгляди отвратительно, три строки вместо одной, постоянное дублирование слов ip ip raw raw prerouting prerouting hook prerouting.
Ужас.
Таблицы и цепи сами собой не возникают, как на iptables, да.
В nft list ruleset оно преобразуется в
> table ip raw {
> chain prerouting {
> type filter hook prerouting priority filter; policy accept;
> iifname != "wg0" ip daddr 10.182.12.8 fib saddr type != local drop
> }
> }Можно прямо в таком виде положить в файл и сделать "nft -f файл".
# cat /proc/sys/net/ipv4/conf/all/rp_filter
0Проклятый системдос! И до openwrt добрался!
openwrt это маршрутизатор с поддержкой ассимитричного трафика
> openwrt это маршрутизатор с поддержкой ассимитричного трафикаа ведь некоторые, не будем показывать пальцем, тащат на него openvpn!
Системдос выставляет значение 2.
2 — это там, где он установлен.
а меня 1
CentOS 7
cat /proc/sys/net/ipv4/conf/all/rp_filter
1Fedora 30
cat /proc/sys/net/ipv4/conf/all/rp_filter
2пойду поменяю на Fedora
я только не понял, с rp_filter=0 оно работает или нет?
А самому попробовать первую стадию (определение локального адреса VPN) ну вообще что-ли никак?
насколько понял, если вы сидите из мухосранска где только ipv4 - настройки rp_filter достаточно. Если есть возможность подключиться через ipv6 - нужно подкручивать iptables
а если ipv6 недоступен внутри тунеля?
если у меня в openVPN только ipv4?
походу тебя поимеют
Слишком надумано
Я правильно понимаю, что включение strict приведёт к проблемам с доступом, например нельзя будет пропинговать внешний адрес роутера из внутренней сети?
включение strict будет проверять, что отправитель и адресат совпадают, так сказать. На этом все
*адресат и получатель же
> Слишком надумано
> Я правильно понимаю, что включение strict приведёт к проблемам с доступом, например
> нельзя будет пропинговать внешний адрес роутера из внутренней сети?нет, неправильно.
Проверяется _reverse_path.
ребята, объясните - правильные параметры выставляются через
sudo sysctl -w "net.ipv4.conf.all.rp_filter=1"
да?
>/etc/sysctl.conf147-# Enables source route verification
148:net.ipv4.conf.default.rp_filter = 1
149-# Enable reverse path
150:net.ipv4.conf.all.rp_filter = 1
151:#note rpfilter now will be enabled in iptables
если я правильно помню заметку фильтрация могла быть включена отдельно в файрволе
>etc/sysctl.confна манжаре вообще нет этого файла
Его надо создать. Ну или/run/sysctl.d/*.conf
/etc/sysctl.d/*.conf
/usr/local/lib/sysctl.d/*.conf
/usr/lib/sysctl.d/*.conf
/lib/sysctl.d/*.conf
/etc/sysctl.confman sysctl.conf
/etc/sysctl.d/100-manjaro.conf имеется. С единственной записью:
vm.swappiness = 1
Дописать после этого?
Какие кошмарные дефолты, впрочем, в рачике всё нужно настраивать самому. Можно сделать /etc/sysctl.d/999-custom.conf и записать туда, в том числе vm.swappiness = 90.
**Operating Systems Affected:Here is a list of the operating systems we have tested which are
vulnerable to this attack:Ubuntu 19.10 (systemd)
Fedora (systemd)
Debian 10.2 (systemd)
Arch 2019.05 (systemd)
Manjaro 18.1.1 (systemd)Devuan (sysV init)
MX Linux 19 (Mepis+antiX)
Void Linux (runit)Slackware 14.2 (rc.d)
Deepin (rc.d)
FreeBSD (rc.d)
OpenBSD (rc.d)
Devuan опасносте!😱
А в коментариях выше местные иксперды уже пришли к выводу, что виноват systemd
А о чём вы спорите? Там где systemd — это решение принимал systemd, это же у них в release notes написано. Странно было бы считать их не виновными.
OpenBSD - Only two remote holes in the default install, in a heck of a long time!
> Only two remote holes in the default install, in a heck of a long time!бгг.. фраза звучит довольно фальшиво (уже как несколько лет), но фанатики хавают и это главное...
Вы знаете, а я почему-то полагал, что люди её применяют - после тщательного анализа всех "за" и "против", конечно - в качестве, например, маршрутизатора либо балансера. Выходит, я ошибался, и всё дело в банальном фанатизме?..
ну вон перечитай жизенный путь одного местного, гхм... нефанатика, изложенный частями в тредике про флэш под статейкой про очередную мурзилу. Какой там анализ, о чем вы.Дело даже не в настоящем фанатизме, а в том что люди очень легко разводятся сказками об "особом подходе", "тщательном ревью кода" и так далее. Хотя если поглядеть в историю - сразу же понятно, что нет ни особого подхода, ни какого либо ревью, так, набегами на отдельные места что-то когда-то понаулучшали, но это было давно, и никакой особой пользы не принесло никому.
Ну и да, конечно же многим просто хочется быть "не такими как все".
Первый и последний раз применение openbsd по делу я видел в 2007м году, когда в ней уже был позаимствованный из nmap os fingerprint match в пакетном фильтре, а в других еще скопипастить не успели.
В качестве маршрутизатора или балансера она уныла чуть более чем полностью.
>что-то когда-то понаулучшали, но это было давно, и никакой особой пользы не принесло никому.Напомнить, как после обнародования уязвимости Spectre в процессорах только у OpenBSD проблема не выявлялась? Все остальные OS глубоко соснули. Это называется не принесло пользы?
>Первый и последний раз применение openbsd по делу я видел в 2007м году
Что же сейчас модно применять у благородных мусье?
> Что же сейчас модно применять у благородных мусье?Десяточку, вестимо.
лолшта? spectre не имеет отношения к героической поебде над гипертредингом, с которой вы, видимо, перепутали (да и та постфактум). Проблема была тщательно замазана Тео, как якобы несущественная, и исправляющий ее очень мутный код старательно перемешан с мелтдауновским - так что непонятно даже, исправлена ли она на самом деле (впрочем, кому тот неуловимый джо сдался), или вся надежда на компилятор с trampolines. Что не помешало через день снова заявить о невиданной поебде, когда оказалось что та же проблема существует на arm, где никакого мелтдауна нет и интеловский патч неприменим.
В любом случае эта уязвимость преимущественно в userspace, и переделывать надо в основном userspace.DAWG реализовать - это вот нет, это не для опенбсдшников, это сложно, это в очень хитрых механизмах надо разбираться на самом деле, а не болтать о них и о том какой интел плохой, плохой. (нет, понятно что ни kib@, ни ms'овские индусы на такое в принципе неспособны, а Линусу не занесут - но где же, где же решение от тех парней, с security in mind? А, ну да... "и так сойдет!")
> Что же сейчас модно применять у благородных мусье?
что угодно, начиная от server2019 и заканчивая rtos - в зависимости от места применения. А вот места для openbsd в мире как-то не нашлось.
Ну кроме компьютеров "не-таких-как-все", которым оно не для работы, а для погордиться собой.
Бред не неси. Причём тут Meltdown? Я где-то про него писал? Может ещё какие нибудь уязвимости приведёшь которых у процов Intel миллион?Факт в том, что когда стало известно про Spectre эта уязвимость на OpenBSD не воспроизводилась. Что из себя представляет patch не важно, важно что этот patch работает. Более того, Тео задолго до этого, минимум за полгода говорил, что гипертрединг это потенциальная уязвимость и оказался прав.
Для справки, в то время даже через браузер можно было экплуатировать Spectre на любой OS которая работает на проце где есть спекулятивное исполнение кода, но только не на OpenBSD.
> Бред не неси. Причём тут Meltdown?бред нес твой божок Тео, перемешав две проблемы в своих широковещательных заявлениях как они их героически поебдили. (при этом катил баллоны на интел, что это они первые начали)
> Факт в том, что когда стало известно про Spectre эта уязвимость на OpenBSD не воспроизводилась.
это твоя религиозная фантазия.
Даже обсуждать не вижу смысла - ты вообще не в теме и не понимаешь ни в чем уязвимость, ни как работала. Зачем, вот же икона, надо молиться и поклоны бить.
Нет для spectre никакого волшебного патча, кроме патча на компилятор. В ядрах патчат в основном потерю производительности - при наличии в процессоре ibrs.До кучи,
внезапно: OpenBSD/armv7 and OpenBSD/arm64 now flush the Branch Target Buffer (BTB) on processors that do speculative execution to mitigate Spectre variant 2 attacks. Это из relnotes к все той же пресловутой 6.3
Не воспроизводилось-невоспроизводилось.Тео десять лет нес всякий бред про уязвимости во всем чем только можно, и, наконец, ему повезло - один раз попал таки пальцем в небо. Правда, бормотал до этого совсем о другом, но никто уже не вспомнит и не проверит (интел очень кстати удалил у себя документы).
Замечу, что механизм, включающий (отключенный по умолчанию!) гипертрединг - в freebsd был не в 2018м году, когда до него додумались твои божки, а в 2003м. Потом от него отказались, разумеется. Никому нафиг было не нужно.
>Нет для spectre никакого волшебного патча, кроме патча на компилятор.Что? ЧТО???
В виртуальных машинах тоже патчи на компилятор помогут?
В интерпретаторах типа bash, python, да даже в javascript тоже патч на комплятор поможет?Разумеется нет.
Разве не было инфы, что патчи на ядро от Spectre роняют производительность до 50% в определённых сценариях?Разумеется такая инфа была и это вызвало сильное бурление против Intel.
Дальше обсуждать нету смысла ты просто ноль, ты просто школоло.
> В виртуальных машинах тоже патчи на компилятор помогут?да. В смысле, наоборот - кроме них ничего не поможет. Причем понадобится собирать патченным и хостовую систему, и виртуализированную.
> В интерпретаторах типа bash, python, да даже в javascript тоже патч на комплятор поможет?нет. Их самих надо патчить (и попатчено уже - загрублены таймеры жабаскрипта во всех браузерах из ныне живых - как ты думаешь, зачем это пришлось сделать, если бы волшебное ведро волшебно заботилось само, мистическим образом?) И еще sql-серверы с хранимыми процедурами и еще дохрена всего.
> Разве не было инфы, что патчи на ядро от Spectre роняют производительность до 50% в
> определённых сценариях?не было. Ты опять слышал звон. Ее роняют изменения для поддержки kpti - причем, что характерно - в линуксе (единственном, в котором на самом деле меряли) они это делают в режиме когда этот самый kpti не включен (потому что для только _возможности_ его включения - попереломали очень тонкое место, вызываемое тысячи раз в секунду). Потому что так сделал интел, а все остальные, включая твоих божков, не нашли ничего лучшего, чем скопипастить один и тот же вокараунд (ок, фришники врут что скопипастили правильно, _выключенный_ ничего не ломает).
Альтернатива существует, теоретически должна быть заметно менее тормозной (включенной, разумеется), называется DAWG, реализована нигде.P.S. ну вот вам типичный образчик фаната openbsd. Не знает вообще ничего, зато свято верит в какие-то легенды. Которые непонятно даже, из какого пальца высосал.
да, кому поржать над пастушком с заевшей пластинкой "Волки!" - гугль притащил из прошлого, уловив тенденцию:https://marc.info/?l=openbsd-misc&m=118296441702631&w=2
- типичный такой Тео.И, где же, массовые ужастные и опастные уязьвизьгмости в отвратительном intel core2? А нету их. Уже и про core2-то забыли все, а уязвимости только в теории и остались.
Не смотря на весь визг.
> Например, для OpenVPN шифрованный пакет с размером 79 позволяет точно судить, что внутри содержится ACK-подтверждение.Ну блин, padding уже везде должен быть жеж поидее
Даже ничего изменять не пришлось.
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.tcp_max_orphans = 65536
net.ipv4.tcp_fin_timeout = 10
net.ipv4.tcp_keepalive_time = 1800
net.ipv4.tcp_keepalive_intvl = 15
net.ipv4.tcp_keepalive_probes = 5
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_synack_retries = 1
net.ipv4.tcp_mem = 50576 64768 98152
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_orphan_retries = 0
net.ipv4.tcp_syncookies = 0
net.ipv4.netfilter.ip_conntrack_max = 16777216
net.netfilter.nf_conntrack_max = 16777216
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_congestion_control = htcp
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.route.flush = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.lo.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.lo.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_rfc1337 = 1
net.ipv4.ip_forward = 0
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_echo_ignore_all = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 1000
net.core.rmem_default = 65536
net.core.wmem_default = 65536
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
fs.inotify.max_user_watches = 16777216P.S. Да, держу в курсе, а также может кто-то посоветует чего-то добавить/убрать/изменить.
Надеюсь ты сам понимаешь что тут столько настроек чтобы сам ты тут ничего поменять не смог. И то что ты просишь некоего Анонимуса помочь показательно.
> Надеюсь ты сам понимаешь что тут столько настроек чтобы сам ты тут
> ничего поменять не смог. И то что ты просишь некоего Анонимусаон похоже не понимает, что эти настройки означают и как работают - судя по мешанине с .default .all и per-interface.
> помочь показательно.
Б-г поможет!
На дефолтные из убунты не похоже видимо он их сам правил.
на копипасту из вопросов со stackoverflow похоже - до ответов, видимо, опять недочитано.
> Надеюсь ты сам понимаешь что тут столько настроек чтобы сам ты тут
> ничего поменять не смог. И то что ты просишь некоего Анонимуса
> помочь показательно.Я понимаю для чего они изменяются, но не понимаю до конца все последствия и накладные расходы связанные с ними.
Хорошо что ты сам смог это более четко сформулировать.
Да я это и не говорил никогда что разбираюсь в параметрах настройки ядра и в фильтрации пакетов.
От того что Вы притворяетесь всезнающим, умнее Вы не становитесь.
Ох, мать-перемать, вот это простыня. Это ты на своем десктопе/лэптопе такое фигачишь? А зачем? Про просьбу пояснить каждое значение я уж вообще молчу.
> Ох, мать-перемать, вот это простыня. Это ты на своем десктопе/лэптопе такое фигачишь?
> А зачем? Про просьбу пояснить каждое значение я уж вообще молчу.Вообще-то это веб-сервер (nginx/php/redis), настроенный на высокую нагрузку.
На десктопе я тоже это использую, у меня мой десктоп дев-сервер и я хочу чтобы у него конфиг был максимально приближённый к проду, и в крайнем случае мог подстраховать его.Настраивалось для защиты от DDOS-а и способность обрабатывать много соединений.
ЕМНИП
sysctl net.ipv4.conf.all.rp_filter = 1
net.core.somaxconn = 65535
И отключение больших прозрачных страниц в параметрах загрузки требовал redis.
> И отключение больших прозрачных страниц в параметрах загрузки требовал redis.А это ничего, что его требования - перпендикулярны "большим нагрузкам" и вообще нормальному серверному применению? И предназначены для выделенного сервера, где кроме редиса вообще ничего нет (ну можешь еще монгу рядом запустить, у нее аналогичные заморочки), никаких пехепе с апачами, а обрабатывает тот редис гигабайты данных и тысячи соединений в секунду, а не хранит унылые пехепешные session id?
Может, прежде чем копипастить неведомые параметры, стоило бы посмотреть в гугле, что они на самом деле меняют и почему умолчания отличаются? Ладно, я готов поверить что древние 128 somaxconn стоит хотя бы удвоить, но у тебя правда бывает 64k соединений в состоянии ДО accept? И что с ними будет, когда таки аксептнутся - твое унылое корыто с пехепеапачом сможет их переварить? Да не смеши мои тапочки, оно лопнет не по памяти так по cpu.
Кстати, о хайлоаде - что-то помнится ank@ говорил, что список там - линейный.Впрочем, машина железная, а "хайлоад" тебе только снится, поэтому и с такими кривыми параметрами работать будет, а разницу ты даже и не заметишь.
>> И отключение больших прозрачных страниц в параметрах загрузки требовал redis.
> А это ничего, что его требования - перпендикулярны "большим нагрузкам" и вообще нормальному серверному применению?Вы можете обосновать своё заявление?
Я читал про них в то время, уже подзабыл что именно они делают, что-то связанное с оптимизацией выделения памяти, которая не требует никаких действий от этих приложений, что в теории должно дать положительный эффект.
Как это проверить на практике я не знаю до сих пор.
Сначала TokuDB (движок для MariaDB), требовал её отключения для работы.
Я забил на этот движок, тем более потом RocksDB появился который и производительнее и работал с THP.
Но redis мне был нужен и у меня не было выбора.
И при этом если достаточно много серверов требуют отключения THP то это тоже о чём-то говорит.https://habr.com/ru/company/tinkoff/blog/446342/
Конечно Тинькофф никак не авторитет, его разработчики даже в логи redis-а не удосужились посмотреть и сразу устранить проблему, да и через socket redis сразу подключить, а не использовать стандартный конфиг, но тем не менее у них из-за THP был лишний расход CPU в системном режиме.
И конфиги у нас очень похожи, за исключением что у меня СУБД MariaDB.> но у тебя правда бывает 64k соединений в состоянии ДО accept
Скорее всего нет и я пока не знаю что это означает.
> Впрочем, машина железная, а "хайлоад" тебе только снится...
Я и не утверждал что работаю с хайлодом и тем более разбираюсь в нём.
Собственно по тому и не разбираюсь, что у меня хватает интересной работы и без него, поработать с настоящим хайлодом мне никак не удаётся, от того в нём и не разбираюсь вообще, так как без реальной практики и возможности пощупать, что-то теоретически заучивать бессмысленно.
Это как учить ЯП без компьютера.
> Вы можете обосновать своё заявление?лень. Можно просто включить обратно huge pages и убедиться, что мир не рухнет, и ничего кроме жалобных вяков в логах (не помню, редис или монга вякает, обнаружив что их ценными рекомендациями пренебрегли) не происходит вообще.
> Как это проверить на практике я не знаю до сих пор.
при копеечных нагрузках и дохлых машинках эффект в любом случае малозаметен. Вот если четверть терабайта памяти порезать по 4k, и начать потом их суматошно перебирать - проблема может стать заметна банально глазом, поскольку ни в какие кэши эта таблица не влезет.
Но конкретно этот совет - в принципе вредный, потому что дающие его изготовители тазок банных почему-то упорно не хотят принять во внимание, что обычно-то их поделки работают не на выделенном сервере, а в целой куче другого софта, и сами - вовсе не являются главными.У пенькова проблемы начинались с 1,5k rps - куда тебе столько, у тебя сервер лопнет от понафоркавшихся 1500 апачей в первую же секунду.
Когда и если я отдам под редис целиком сервер - я, безусловно, сделаю как он просит (ему ни своп не нужен и вреден, свопящийся редис - мертвый редис, ни huge pages, он там внутри себя все равно оперирует своими собственными страницами). Правда, so_maxconn больше пресловутых 512 все равно вряд ли зачем нужен - по cpu лопнет. Не 64ядерный же монстр ему достанется.
Но пока мне с нашим весьма специфичным "хайлоадом" нужен больше HA, а это значит - по редису на каждом сервере рядом с вебней. Которая как раз жрать здорова, и huge pages ей пригодятся.
А в редисе один хрен мегабайты а не гигабайты.> поработать с настоящим хайлодом мне никак не удаётся
ну и радуйся - ничего там хорошего нет. Все течет, все сыплется, костыли подпираются табуретками, а те шваброй, а швабру ты среди ночи держишь, и даже при наличии знаний и понимания как и что работает (включая пресловутые параметры tcp) - не всегда удается починить, потому что не все ты можешь изменить. Я был безумно рад, оба раза, когда от такого сбежать удалось, и очень надеюсь в третий не вляпаться.
P.S. внезапно, в самом последнем комментарии под тиньковской промо-статьей - кто-то владеющий темой детально разжевал про huge pages, как на самом деле они работают и как устроен tlb. Только это было еще до kpti, учти, с его flush на каждый свитч.
> ... у тебя сервер лопнет от понафоркавшихся 1500 апачейЯ месяц назад перешёл на nginx+php-fpm апач со своим htaccess уже в прошлом.
Подумать только, ЧПУ на nginx можно сделать просто...
error_page 403 /en/error/;
error_page 404 /en/error/;
location = /index.php
{
return 404;
}
location ^~ /.
{
return 404;
}
location /
{
try_files $uri @php;
}
location @php
{
fastcgi_pass unix:/run/php-fpm.sock;
fastcgi_param SCRIPT_FILENAME $document_root/index.php;
include fastcgi_params;
}
Всё что не статика и разрешено, nginx отправляет в php $_SERVER['REQUEST_URI'], которое я могу эффективно и просто распарсить на $_GET-параметры вообще без единой регулярки!
И всё это время так можно было... в nginx.Правда как эффективно в php-пуле выставлять:
pm.max_children
pm.start_servers
pm.min_spare_servers
pm.max_spare_servers
pm.max_requests
Относительно имеющегося железа и нагрузки пока не понял.
Видимо буду мониторить нагрузку экспериментировать и повышать по мере необходимости, если это будет давать ощутимый положительный эффект.> Когда и если я отдам под редис целиком сервер - я, безусловно, сделаю как он просит
Я не претендую на истинность, но мне кажется redis, PHP и MariaDB должны стоять на одном сервере, чтобы быстро обмениваться данными по сокетам, и не тратится на сетевые задержки.
> P.S. внезапно, в самом последнем комментарии
Благодарю, читаю его сейчас, про включение THP вопреки redis тоже подумаю.
> Я не претендую на истинность, но мне кажется redis, PHP и MariaDB
> должны стоять на одном сервере, чтобы быстро обмениваться данными по сокетам,
> и не тратится на сетевые задержки.у тебя основные задержки - на установление соединения с клиентом и рестарт пхп-инстанса.
На этом фоне твоего редиса в сетке с rtt 0.3ms никто и не увидит и не отличит локальный от сетевого сокеты ни в какой микроскоп - отмеряно микрометром, отмечено мелом, отрублено топором.
И уже тем более - никто не увидит mariadb.Там где станет видно - уже пора обратно о мемкэше думать. Но таких мест, к счастью, очень мало.
Добавь вот это
vm.swappiness=0
vm.dirty_ratio=60
vm.dirty_background_ratio=40
vm.dirty_writeback_centisecs=3000
vm.dirty_expire_centisecs=5000net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1
net.ipv6.conf.lo.disable_ipv6=1
> net.ipv6.conf.all.disable_ipv6=1
> net.ipv6.conf.default.disable_ipv6=1
> net.ipv6.conf.lo.disable_ipv6=1Какая прекрасная идея! Фигак и нет у тебя больше IPv6! Вот только что был, но ты добавил фигню по совету анона с опеннета и все отвалилось :-D :-D :-D
Нет IPv6, а значит и нет дырок в IPv6 и дырок эксплуатируемых с помощью IPv6. Это называется мудрость.
Что такое «дырки в IPv6»?
А так отруби тогда вообще сетевой стек, что уж мучиться
Блинский ёж, у меня ВСЯ работа с серверами идет по IPv6, вот просто вся, а ты тут даешь людям советы его отрубать. Ты откуда сбежал? Из 2000 года?
IPv6 слишком молод, чтобы его использовать. Ещё даже в IPv4 не все дырки отловили, лет через 25 можно будет присматриваться к IPv6, но не раньше.
Живу на IPv4 и горя не знаю.
> Блинский ёж, у меня ВСЯ работа с серверами идет по IPv6,
> вот просто вся, а ты тут даешь людям советы его отрубать."Сижу на героине весь, просто весь, а ты тут предлагаешь дилеров отстреливать" (логика та же)
Миша, мы все знаем, что логика не твоя сильная сторона, а мозг у тебя отсутствует. IPv6 — стандарт в индустрии уже, то что в твоем отделе ФСБ об этом не знают ничего не значит, они и о существовании интернета узнали только на 10ый год правления ботоксного карлика.
>узнали только на 10ый год правления ботоксного карлика.20 год не хочешь? Пу сидит со второй половины 1999 года, сидит уже больше чем Брежнев. Уже выросло поколение которое родилось при Пу и начало делать своих детей. Они ничего кроме Пу не видел.
А об интернете они узнали 10 лет назад, как раз тогда начали первые законы о цензуре принимать.
> Вот только что был, но ты добавил фигню по совету анона с опеннета и все отвалилосьпричем одного раза выстрелить самому себе из ружья в задницу показалось мало, сделал контрольный, и еще прикладом добил. Какое нелепое самоубийство!
> Добавь вот это
> net.ipv6.conf.all.disable_ipv6=1
> net.ipv6.conf.default.disable_ipv6=1
> net.ipv6.conf.lo.disable_ipv6=1ipv6 полноценно отключается только через параметр загрузки ядра.
От этого же у меня, как минимум, почтовые логи будут забиты, предупреждениями о невозможности в ipv6.
Выруби логи, делов-то.
Как раз наоборот. Именно это рекомендуемый, например, красношапкой способ отключния.
Ибо есть приложениия, точно postfix, которыйе неистово верят в существование ipv6 всегда. И очень плачут, когда ядро его не поддерживает.
Про inet_protocols=ipv4 не слышали?
тебе же сказали - выключи логи! Они ВСЕ проблемы так решают.
> тебе же сказали - выключи логи! Они ВСЕ проблемы так решают.Читая, что пишет этот чувак, держусь за лицо уже двумя руками. А он ведь не только пишет, но и где-то делает.
Отличная иллюстрация того, зачем надо использовать HTTPS.Сначала был KRACK, который позволял прослушивать трафик беспроводной сети Wi-Fi без знания пароля. Теперь можно влезть в VPN-туннель.
Используйте HTTPS, пригодится в таких вот случаях, когда предыдущий уровень защиты облажался.
Да-да, особенно умиляет HTTPS _вместо_ FTP.
кто-то ещё пользуется FTP? :D
И это только один системдосовский нотэбаг.
Я писал о похожей атаке в 2015 году:
https://habr.com/ru/post/273523/Использовал похожую технику, но отправлял пакеты через UDP, что работало (работает?) не только на Linux, но и на OS X, Windows и Android.
Я отправлял пакеты на порт старого p2p Skype, который позволял получить IP-адрес клиента по его логину, с помощью специальных "резолверов" (было такое ПО и сервисы). После получения IP-адреса, достаточно было отправить UDP-пакет на все порты на этот адрес, после чего Skype отправит ответ, который придёт с source IP VPN-сервера, а не с IP-адреса, на который отправляли пакет.
Таким образом можно было узнать, подключен ли конкретный пользователь Skype к VPN, и если подключен, то к какому конкретно, если пользователь подключался к интернету без NAT.Данная атака до сих пор работает с Bittorrent uTP-протоколом, и, вероятно, с другим ПО, которое работает по UDP и прослушивает порт.
Важное отличие от описанной атаки в том, что мой вариант можно эксплуатировать через обычный интернет, не требуется прямая связность атакующего с жертвой, Wi-Fi-точка или что-то подобное. Даже возможность подмены source IP не требуется.
Так вот мне засирал порты в 2015 году.
Так вот кто тебе в порты наcpaл... и совсем и не абама...
Это у тебя там Рика-тяма на аватарке или просто похожа?
> Важное отличие от описанной атаки в томчто тебе надо откуда-то узнать ip-адрес. А если у тебя при подключенном vpn и перенаправленном в него default gateway утекают реальные адреса - через сцайп, или чере моднявый webrtc - то поздно уже пить боржом.
Не говоря уже о том что речь в описанном случае совсем о другом впн, не том что для cp и вареза, и суть эксплойта не узнать айпишник (его никто и не скрывает) а под видом доверенного траффика подсунуть левый.
user@laptop $ sysctl net.ipv4.conf.all.rp_filter
net.ipv4.conf.all.rp_filter = 1
user@laptop $ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.3 LTS
Release: 18.04
Codename: bionicnet.ipv4.conf.all.rp_filter не менял, все в дефолте. То есть в LTS'е проблемы нет, а те кто сидит на тестовых ветках делают это добровольно и осознают что делают(а если не осознают, то сами виноваты)
+
> То есть в LTS'е проблемы нетдавно обновления-то не ставил? "проблемы нет", ага. Пока завтра не приползет новая-улучшенная версия сцыстемды, и порулит за тебя сетью.
Сегодня обновления ставил. Дальше фантазировать будешь?
Блин, iptables и nftables, конечно, мощные инструменты. Но какой же вырвиглазный синтактсис. Сравнить, хотя бы, с pf
а в FreeBSD что править и патчить?
В ipfw - deny ip from any to any not verrevpath in
Я тут недавно обнаружил, что через NAT-сервер и так утекают локальные адреса. Тупо некоторые FIN и RST -пакеты не натятся и улетают как есть. Для FIN-пакетов я подобрал параметры в sysctl, которые это фиксят, а вот RST-пакеты всё-равно не все натятся - по-моему это баг ядра.Поснифайте внешний интерфейс на своём NAT, у кого есть такая возможность.
на бордере - _любом_ бордере, а не только натящем, является хорошей традицией не "снифать внешний интерфейс", а иметь либо маршруты для rfc1918 сетей в blackhole или иной местный аналог /dev/null, либо правило drop в пакетном фильтре.Это не баг ядра, это баг твоих настроек скорее всего. Отправлять эти rst дальше null не имеет никакого смысла.
Это давно известная багофича. В iptables можно фильтровать как-то вроде "-m conntrack --ctstate INVALID -j DROP"
Так это для впн...)) можно и на ноль сидеть, Оперой не пользуюсь и другими впнками тоже.
#cat /proc/sys/net/ipv4/conf/all/rp_filter
1
> Для проведения атаки необходимо узнать назначенный VPN-сервером IP-адрес сетевого интерфейса туннеля, а также определить, что в данный момент через туннель активно соединение к определённому хосту.Ну и root-доступ бы ещё неплохо.
А какого хрена вообще какие-то режимы влияют на изоляцию VPN-туннелей? Какого хрена вообще для этого используется rp_filter?
Потому что vpn туннель реализован в виде виртуального сетевого интерфейса
кто полагается на IP-адреса в вопросах безопасности VPN тот сам себе злобный буратино
на Archlinux всё в порядке
>на Archlinux всё в systemD.Этим всё сказано.
> но начиная с systemd 240, выпущенного в декабре прошлого года,
> режим работы по умолчанию был заменён на "Loose"Понятно, что все высказались; кто-нить уже git grep, git blame и git show насчёт хоть каких-то аргУментов?
>> но начиная с systemd 240, выпущенного в декабре прошлого года,
>> режим работы по умолчанию был заменён на "Loose"
> Понятно, что все высказались; кто-нить уже git grep, git blame и git
> show насчёт хоть каких-то аргУментов?Сам-то побрезговал?...
https://github.com/systemd/systemd/search?q=Loose&type=Commits
https://github.com/systemd/systemd/commit/230450d4e4f1f5fc9f...
lkundrak authored and poettering committed on 28 Nov 2018
https://fedoraproject.org/wiki/User:Lkundrak
LP и S-D в едином порыве с F-d и NM....
...встречаются роковые мгновения, когда он беспощадно рвет со своим прошлым...
....рвут прошлое rp_filter-а.
> включение которого в режим "Strict" нейтрализует данную проблему.Где там чего менять?
Сразу видно уровень местных экспертов - все побежали включать.rp_filter - я всегда выключал в линухах потому что эта херня мешается работе с мультикастом. При этом мультикаст мне нужен а на спуфинг плевать - ему взятся неоткуда, да и там только ссш открыт.
Уровень авторов антиспуфинга в линухе тоже зашкаливает - антиспуфить мультикаст из 224/4 - это надо быть особо одарённым.
И ровно по той же причине в опенврт эта херня отключена.
Первым делом при настройке любого маршрутизатора запрещаю приём пакетов на интерфейс не из его сети. Это прям базовая вещь. Но да, девопсяры обычно не в курсе.
Ecли у меня UDP с TLS на pfsense, мне стоит беспокоится по поводу сабжа?
> Опубликована техника атаки (CVE-2019-14899), позволяющая подменить, изменить или подставить пакеты в TCP-соединения, пробрасываемые через VPN-туннели.Примерно ~15 лет назад данная техника атаки на шифрованные тунели была разработана и опубликована мною лично на одном украинском форуме.
И другой человек, с этого украинского форума, предложил патч для выравнивания всех пакетов тунеля до MTU.
Там же предлагали защиту с помощью сетевого экрана.