Следом за выявленной (https://www.opennet.me/opennews/art.shtml?num=49094) на прошлой неделе DoS-уязвимости SegmentSmack в TCP-стеках различных операционных систем, опубликована (http://seclists.org/oss-sec/2018/q3/119) информация о другой похожей уязвимости (https://www.kb.cert.org/vuls/id/641765) (CVE-2018-5391 (https://security-tracker.debian.org/tracker/CVE-2018-5391), кодовое имя FragmentSmack (https://bugzilla.redhat.com/show_bug.cgi?id=1609664)), которая также позволяет организовать отказ в обслуживании через отправку специально оформленного набора сетевых пакетов, при обработке которого будут заняты все реcурсы CPU. Если первая уязвимость была связана с неэффективностью алгоритма обработки TCP-сегментов, то новая проблема затрагивает (https://access.redhat.com/articles/3553061) алгоритм пересборки фрагментированных IP-пакетов.Атака осуществляется через отправку потока фрагментированных IP-пакетов, в каждом из которых смещение фрагмента установлено случайным образом. В отличие от прошлой уязвимости SegmentSmack, в FragmentSmack возможно совершение атаки с использованием спуфинга (отправки пакетов с указанием несуществующего IP). При этом для новой атаки требуется большая интенсивность отправки: для полной утилизации ресурсов одного ядра CPU Intel Xeon D-1587@1.70GHz необходим поток на уровне 30 тысяч пакетов в секунду, в то время как для SegmentSmack было достаточно 2 тысячи пакетов в секунду.
Наличие проблемы подтверждено в TCP стеках Linux (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...) и FreeBSD (https://www.freebsd.org/security/advisories/FreeBSD-SA-18�...). В ядре Linux проблема проявляется начиная с выпуска ядра 3.9. Обновления с устранением проблемы подготовлены для Debian (https://security-tracker.debian.org/tracker/CVE-2018-5391), Fedora, SUSE/openSUSE (https://bugzilla.novell.com/show_bug.cgi?id=CVE-2018-5391), Ubuntu (https://people.canonical.com/~ubuntu-security/cve/2018/CVE-2...), RHEL (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-5391) и FreeBSD (https://www.freebsd.org/security/advisories/FreeBSD-SA-18�...). В качестве обходного пути защиты в Linux можно
снизить значения sysctl net.ipv4.ipfrag_high_thresh и net.ipv4.ipfrag_low_thresh до 256kB и 192kB или ещё меньших значений.sysctl -w net.ipv4.ipfrag_low_thresh=262144
sysctl -w net.ipv4.ipfrag_high_thresh=196608
sysctl -w net.ipv6.ip6frag_low_thresh=262144
sysctl -w net.ipv6.ip6frag_high_thresh=196608Во FreeBSD в качестве обходного пути защиты рекомендовано отключить пересборку фрагментированных пакетов:
sysctl net.inet.ip.maxfragpackets=0
sysctl net.inet6.ip6.maxfrags=0URL: http://seclists.org/oss-sec/2018/q3/119
Новость: https://www.opennet.me/opennews/art.shtml?num=49135
Для фряхи еще дополнительно:
net.inet.ip.maxfragsperpacket=0
net.inet6.ip6.maxfragpackets=0
> Для фряхи еще дополнительно:
> net.inet.ip.maxfragsperpacket=0
> net.inet6.ip6.maxfragpackets=0Нехилые дефолты по умолчанию:
% sysctl net.inet6.ip6.maxfrags net.inet.ip.maxfragpackets
net.inet6.ip6.maxfrags: 123777
net.inet.ip.maxfragpackets: 15478
Но враг не пройдет!
# ipfw -at list|gnumfmt --to=iec --field 3
00100 2246025 2,4G Wed Aug 15 15:10:07 2018 reass ip from any to any in
-
00100 2 256 Mon Aug 13 17:32:17 2018 deny ip from 127.0.0.0/8 to any
00100 12 1,5K Mon Aug 13 17:32:29 2018 deny ip from any to any not antispoof in
# sysctl -w net.ipv4.ipfrag_high_thresh=196608
sysctl: setting key "net.ipv4.ipfrag_high_thresh": Invalid argument
net.ipv4.ipfrag_high_thresh = 196608# sysctl -a |grep net.ipv4.ipfrag_high_thresh
net.ipv4.ipfrag_high_thresh = 4194304Ага, рабочий прям рецепт.
Телепузиков иди смотри, ну или статью почитай, ядро у тебя какое ?
Хм, у меня это отлично работает и на свежем 4.17, и на 3.10 из EL7... И даже на роутере с прошивкой Padavan и 3.4.113 ядром работает.Может у него второе ядро? :)
> Может у него второе ядро? :)Да debian 9 у меня, со свежим ядром.
У debian еще свои накрутки над ядром есть, может в этом дело.
Но факт есть факт, проверил на 2 серверах.
не в этом дело.просто ты тупишь и пытаешься поставить high_thresh ниже чем low_thresh, на что ядро справедливо возражает. фикс для подобных чуваков как раз не очень давно запилили в апстрим.
людям только бы орать что ничего не работает.
Вроде бы у pf из поставки freebsd штатно стоит политика reassemble для фрагментированных пакетов, при активации pf
Любопытно как в такой же ситуации поведет себя pf и ipfw, у которого тоже есть такая же возможность пересборки пакетов
А что значит "штатно стоит"? Там ведь вроде бы надо в директиве scrub указывать reassemble.
Выразился я косноязычно. Правильней конечно говорить об опции, но она активирована по умолчанию теперь и ее явно указывать не нужно
Не стоит.
Не пересобирает он просто так ничего.
интересно в pf.conf
set optimization normal
scrub in allрешает проблему?
> scrub in all"Во FreeBSD в качестве обходного пути защиты рекомендовано отключить пересборку фрагментированных пакетов"
Нет.
Насколько помню как минимум раньше у PF был свой код сборки пакетов.
Я бы в нём этим не пользовался, просто потому что смысла в этом нет.
че ядро то? перепутали местами hi/lo, а hi не может быть меньше lo
Не перепутали, а подняли до неприличных размеров с припиской «но код надо будет оптимизировать». И никто его, разумеется, не оптимизировал.
https://access.redhat.com/articles/3553061
готовый скрипт
мннда, чет не отрабатывает от нифига на убунте через bash результат:
net.ipv4.ipfrag_low_thresh = 196608
net.ipv4.ipfrag_high_thresh = 4194304
net.ipv6.ip6frag_low_thresh = 196608
net.ipv6.ip6frag_high_thresh = 4194304
Она ж для домохозяек. Ставь нормальный линукс.
да, мой косяк.
в исходной статье поправлено.
отключить пересборку фрагментированных пакетов нужно делать? или достаточно сделать:# freebsd-update fetch
# freebsd-update install
Afterward, reboot the system.
Достаточно.
а что поменялось, как проверить?
Посмотреть вывод uname и убедиться что патч наложен.
Следующая ошибка будет называться PacketSmack - если 10-Гбитный интерфейс сатурировать UDP или ICMP минимальной длины, CPU внезапно поплохеет.
А есть эксплойт?
есть.
А возможно на рутерах это настроить чтобы хост FreeBSD получал пакеты без эксплойта?
Конечно! Надо отключить питание роутера... И не включать больше.
> Конечно! Надо отключить питание роутера... И не включать больше.Учитывая специфику ошибки, роутер на пингвине загнется намного раньше.