На конференции Usenix Security Symposium группа исследователей из Калифорнийского университета в Риверсайде и исследовательской лаборатории армии США обнародовали (https://ucrtoday.ucr.edu/39030) сведения о возможности совершения пассивных атак на TCP (http://www.cs.ucr.edu/~zhiyunq/pub/sec16_TCP_pure_offpath.pdf), позволяющих удалённо инициировать разрыв сетевого соединения или осуществить подстановку своих пакетов в TCP-поток к клиенту или серверу.

В отличие от MITM-атак, новый метод не требует контроля за коммуникациями - для атаки достаточно знать IP-адрес сервера, IP-адрес клиента и сетевой порт сервера. В рамках доклада был продемонстрирован рабочий пример атаки, в результате которой в запрошенную одним из пользователей web-страницу с известного новостного сайта была осуществлена подстановка стороннего блока данных.

Суть проблемы в недоработке механизмов ограничения интенсивности обработки ACK-пакетов, описанных в спецификации RFC 5961 (https://tools.ietf.org/html/rfc5961), что позволяет вычислить информацию о номере последовательности, идентифицирующей поток в TCP-соединении, и со стороны отправить подставные пакеты, которые будут обработаны как часть атакуемого TCP-соединения.

Представленный метод не специфичен для конкретных TCP-стеков и проявляется при наличии расширений ограничения интенсивности обработки пакетов (RFC 5961 (https://tools.ietf.org/html/rfc5961)), реализованных для борьбы с подбором номера последовательности TCP. Атакующий может создать "шумовую завесу" для обхода защиты от наводнения ACK-пакетами и применить типовые методы подбора номера последовательности.

Проблема уже подтверждена (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2016-5696) в Linux (CVE-2016-5696 (https://security-tracker.debian.org/tracker/CVE-2016-5696)) и проявляется c 2012 года в выпусках ядра Linux c 3.6 по 4.7. В качестве обходного метода защиты рекомендуется (https://github.com/torvalds/linux/commit/75ff39ccc1bd5d3c455...) увеличить лимит на число одновременно обрабатываемых ACK-пакетов, установив переменную  /proc/sys/net/ipv4/tcp_challenge_ack_limit в значение 1000 вместо ранее принятого по умолчанию 100.

URL: http://arstechnica.com/security/2016/08/linux-bug-leaves-usa.../
Новость: http://www.opennet.me/opennews/art.shtml?num=44945

• Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,Аноним, 10:24 , 11-Авг-16
• Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,AS, 10:29 , 11-Авг-16
  • Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,eRIC, 10:50 , 11-Авг-16
    • Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,Аноним, 19:27 , 11-Авг-16
      • Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,Аноним, 00:42 , 12-Авг-16
        • Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,Аноним, 21:25 , 12-Авг-16
          • Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,Аноним, 23:47 , 12-Авг-16
• Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,Нанобот, 10:33 , 11-Авг-16
  • Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,Аноним, 22:29 , 12-Авг-16
  • Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,parad, 04:13 , 13-Авг-16
• Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,t28, 10:54 , 11-Авг-16
  • Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,Аноним, 21:10 , 12-Авг-16
• Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,Ващенаглухо, 11:10 , 11-Авг-16
• Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,Moomintroll, 11:28 , 11-Авг-16
• Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,Аноним, 12:03 , 11-Авг-16
• Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,freehck, 12:08 , 11-Авг-16
  • Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,_KUL, 04:33 , 12-Авг-16
    • Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,freehck, 11:49 , 12-Авг-16
      • Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,_KUL, 09:22 , 13-Авг-16
  • Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,snmp agent, 17:36 , 15-Авг-16
• Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,Аноним, 12:16 , 11-Авг-16
• Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,слакварявод, 12:18 , 11-Авг-16
  • Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,слакварявод, 12:22 , 11-Авг-16
• Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,angra, 12:29 , 11-Авг-16
• Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,aurved, 12:41 , 11-Авг-16
  • Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,Аноним, 12:43 , 11-Авг-16
    • Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,aurved, 12:45 , 11-Авг-16
      • Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,parad, 04:20 , 13-Авг-16
  • Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,zanswer, 13:54 , 11-Авг-16
  • Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,Аноним, 14:02 , 11-Авг-16
  • Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,rvs2016, 19:15 , 24-Сен-16
• Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,Аноним, 13:42 , 11-Авг-16
  • Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,Ъ, 14:11 , 11-Авг-16
• Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,Аноним, 13:51 , 11-Авг-16
  • Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,pkdr, 14:34 , 11-Авг-16
    • Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,Sluggard, 15:00 , 11-Авг-16
      • Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,fx, 09:30 , 22-Авг-16
  • Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,Аноним, 14:40 , 11-Авг-16
    • Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,Аноним, 14:41 , 11-Авг-16
      • Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,Evolve32, 16:48 , 11-Авг-16
        • Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,Аноним, 17:11 , 11-Авг-16
          • Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,MPEG LA, 18:48 , 11-Авг-16
    • Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,Аноним, 19:35 , 11-Авг-16
      • Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,freehck, 11:58 , 12-Авг-16
• Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,Аноним, 14:48 , 11-Авг-16
• Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,Аноним, 15:17 , 11-Авг-16
• Уязвимость, позволяющая вклиниться в стороннее TCP-соединение,Аноним, 16:10 , 11-Авг-16
  • Уязвимость, позволяющая вклиниться в стороннее TCP-соединение,Аноним, 19:54 , 11-Авг-16
  • Уязвимость, позволяющая вклиниться в стороннее TCP-соединение,angra, 00:32 , 12-Авг-16
• Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,j3qq4, 17:27 , 11-Авг-16
  • Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,h31, 23:17 , 11-Авг-16
• Уязвимость, позволяющая вклиниться в стороннее TCP-соединение,Анончик, 21:28 , 11-Авг-16
• Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,Аноним, 19:17 , 12-Авг-16
  • Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,Аноним, 19:23 , 12-Авг-16
    • Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,Аноним, 19:25 , 12-Авг-16
  • Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,Аноним, 21:21 , 12-Авг-16
    • Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,Аноним, 16:17 , 13-Авг-16
    • Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,Аноним, 16:22 , 13-Авг-16
• Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,Аноним, 19:21 , 12-Авг-16
• Уязвимость, позволяющая вклиниться в стороннее TCP-соединени...,Аноним, 05:40 , 13-Авг-16

Проверил у себя...

@sidbox:~$ cat  /proc/sys/net/ipv4/tcp_challenge_ack_limit
1000

Fedora21 -
[root@sef21 ~]# cat  /proc/sys/net/ipv4/tcp_challenge_ack_limit
100
[root@sef21 ~]#

Fedora24server -
[root@asterisk001 filter.d]# cat  /proc/sys/net/ipv4/tcp_challenge_ack_limit
1000
[root@asterisk001 filter.d]#

они знали !

> Fedora24server -
> [root@asterisk001 filter.d]# cat  /proc/sys/net/ipv4/tcp_challenge_ack_limit
> 1000

1000 vs 999999999

1- Open /etc/sysctl.conf, append a command “net.ipv4.tcp_challenge_ack_limit = 999999999”.
2- Use “sysctl -p” to update the configuration.

В Linux Mint не пашет. Все-равно 100 определяет.

Ой! :)) Теперь так:
cat  /proc/sys/net/ipv4/tcp_challenge_ack_limit
999999999

> Ой! :)) Теперь так:
> cat  /proc/sys/net/ipv4/tcp_challenge_ack_limit
> 999999999

Как ты думаешь, твоя система реально прожует 999 миллионов записей в очереди? Мысль налить тебе таких пакетов побольше, чтобы проверить это - тоже вариант атаки :)

Ладно, уговорили. Оставил 1000. :)

судя по последней ссылке, там не просто увеличение tcp_challenge_ack_limit со 100 до 1000, а ещё какие-то изменения в коде

Да, я б даже сказал само собой или очевидно.

ну так в новости написано и про изменения в коде.

> проявляется c 2012 года в выпусках ядра Linux c 3.6 по 4.7

Всё ясно.

>> проявляется c 2012 года в выпусках ядра Linux c 3.6 по 4.7
> Всё ясно.

Новость не читал, но Linux осуждаешь? Казалось бы, при чем тут RFC...

А в grsecurity давным давно есть фича Truly random TCP ISN.

Напомнило дедушкины страшилки про Кевина Митника...

root@www01:/# cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.1 LTS"
root@www01:/# cat  /proc/sys/net/ipv4/tcp_challenge_ack_limit
100

% cat /etc/debian_version
8.3
% cat  /proc/sys/net/ipv4/tcp_challenge_ack_limit
100

Это'ж Вам не винда, что бы версию оси смотреть ... Нужно сразу ядро!

# apt-cache policy linux-image-4.6.0-1-amd64
linux-image-4.6.0-1-amd64:
  Установлен: 4.6.4-1
  Кандидат:   4.6.4-1
  Таблица версий:
*** 4.6.4-1 990
        990 http://ftp.debian.org/debian testing/main amd64 Packages
        100 /var/lib/dpkg/status
# cat /proc/sys/net/ipv4/tcp_challenge_ack_limit
100

> Это'ж Вам не винда, что бы версию оси смотреть ... Нужно сразу ядро!

Тогда уж "uname -a". А то мало ли какие ядра у вас там стоят в системе... :)

Но вернее всё же версию дистрибутива, поскольку речь идёт о его дефолтах. По версии дистра, к тому же, можно в некотором роде и о ядре. Вот например в Debian 8 сейчас 3.16.7.

Иногда на бизнес-критичных узлах, админы собирают ручками ядро, с тонкой настройкой под специальные драйвера или стевой стек, и жить такое ядро может отдельно от дистрибутива долгое время ... Но да, вы правы, для чистоты нужно было сделать сначала dpkg -l | linux-image и ll /boot

% cat /etc/debian_version
8.3

Обновляться? Зачем?

# cat /etc/centos-release
CentOS Linux release 7.2.1511 (Core)

# uname -r
3.10.0-327.28.2.el7.x86_64

# cat  /proc/sys/net/ipv4/tcp_challenge_ack_limit
100

bash-4.3# cat /etc/slackware-version
Slackware 14.2
bash-4.3#  cat  /proc/sys/net/ipv4/tcp_challenge_ack_limit
1000

и довесок:
bash-4.3# uname -a
Linux 7-21a-226-o1182 4.7.0 #1 SMP PREEMPT Wed Jul 27 12:41:05 SAMT 2016 x86_64 Intel(R) Core(TM) i5-3330 CPU @ 3.00GHz GenuineIntel GNU/Linux

а вот на дефолтных серверах:
root@serslack:~# uname -a
Linux serslack 4.4.14 #2 SMP Fri Jun 24 13:38:27 CDT 2016 x86_64 Intel(R) Xeon(R) CPU E5-2609 0 @ 2.40GHz GenuineIntel GNU/Linux

root@serslack:~# cat  /proc/sys/net/ipv4/tcp_challenge_ack_limit
100

вот так что...

Уязвимость конечно серьезная, но надо по дефолту исходить, что интернет не является безопасной средой передачи и tcp пакеты могут быть подменены или просто прочитаны сторонними лицами. Собственно ssh, https и прочая придуманы именно ради этого и на тех, кто их применяет, данная уязвимость не скажется.

P.S. даешь еще сотню сообщений о том, у кого какое значение в net.ipv4.tcp_challenge_ack_limit

А как насчет FreeBSD?

Пишут что вроде ни OSX, ни Windows, ни FreeBSD не подвержены этой уязвимости,
так как в них не реализован RFC 5961. Хотя в тоже время пишут что чувак разрабатывавший этот RFC -- Randal Stewart, is a FreeBSD source committer.

> чувак разрабатывавший этот RFC -- Randal Stewart, is a FreeBSD source committer

Красиво уделал конкурентов, те готовы кушать все эксперементы на собственной шкуре.

))) ну все-таки линукс и фрюха не совсем конкуренты, линукс уже давно в другой весовой категории...

> ))) ну все-таки линукс и фрюха не совсем конкуренты, линукс уже давно
> в другой весовой категории...

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

Мы с вами можем говорить о том, что FreeBSD имеет частичную поддержку: https://wiki.freebsd.org/TransportProtocols/tcp_rfc_compliance

>  Randal Stewart, is a
> FreeBSD source committer.

Угу. Упоминание в каммитах 2010, поддержка мипсов в 2008,
а потом

Date:   Tue Dec 20 09:24:04 2005 +0000
    Add protocol number for SCTP.
    
    Submitted by:   Randall Stewart rrs at cisco.com

И все.

> А как насчет FreeBSD?
> Пишут что вроде ни OSX, ни Windows, ни FreeBSD не подвержены этой
> уязвимости

Да-да. Но интересует только FreeBSD. Остальные винды там всякие сидят у меня внутри локальной сети после своего шлюза, работающего на FreeBSD.

Ничоси бывает :)
Рандумность - не рандумна!

Еще можно подключить фургончик начиненный ФСБ'шниками и следить за генерацией случайности помех на клавиатуре жертв

> следить за генерацией случайности помех на клавиатуре жертв

Излучения то вовсе не случайные и вполне неплохо декодируются.

Compromising electromagnetic emanations of wired and wireless keyboards
http://lasecwww.epfl.ch/keyboard/

Оборудование для этого по сути доступно любому (при условии, что есть несколько десятков тысяч $ на него), а не только спецслужбам.

> и проявляется c 2012 года в выпусках ядра Linux c 3.6 по 4.7

Почему по? В 4.7 устранена же.

Вообще-то с "3.6 по 4.7" означает "больше, чем 3.6, меньше чем 4.7, но не включая их". Так что правильно, иначе там должно стоять слово "включительно".
Этому учат на уроках математики даже в школе.

Как раз включая 3.6, но не включая 4.7, математик.

"по 4.7" = "включая 4.7", гуманитарий. это "до" обычно не включая.

Linux (≥  3.6 || < 4.7)

> Linux (≥  3.6 || < 4.7)

Спасибо капитан!

Капитан вообще-то прокапитанил
(≥  3.6 && < 4.7)

Спасибо граммар-капитан я вас ждал, редактировать нельзя!

С любовью ваш искренний поклонник #22 #27

ты снова попутал, он буль-капитан, а не граммар

> Linux (≥  3.6 || < 4.7)

[3.6..4.7)
Или вообще
{x € Linuxversion| Linuxversion <: R, x >= 3.6,  x<4.7}
Как-то так.

Евро. Евро, блин. :)

> {x € Linuxversion| Linuxversion <: R, x >= 3.6,  x<4.7}

s/€/∈/

rhel6 подвержен, 5 - нет.

offtop: @gOldfisk и @rancidbacon открыли для мира анальные зонды, в прямом и переносном смысле

> в выпусках ядра Linux c 3.6 по 4.7

Тогда почему RHEL 5 и 6 подвержены? Там ядра 2.6.

Бэкпортов много.

Во-первых, только RHEL6, но не RHEL5
Во-вторых, номер ядра у RHEL показывает только от какой версии был изначальный fork, но никак не из каких версий в нем бекпорты. Там в 2.6.32 могут быть фичи и драйверы хоть из 4.x.

интересно, уязвим ли ТОР за НАТ-ом...

Смотря где. Соединение между узлами Tor-сети - там должна быть защита от инъекции пакетов, так что по идее нет. Между exit node-ой и сервером - уязвимо, если не используешь TLS или другое шифрование.

# uname -r
4.7.0-gentoo

# cat  /proc/sys/net/ipv4/tcp_challenge_ack_limit
1000

Сайт может сбрасывать суммы страницы браузеру через Тор.
2 соединения: Прямое и Через Тор - работают как одно.

Можно попытаться заменить Тор чем-то более лёгким и быстрым, да хотя бы VPN-switcher cо случайными из списка адресами.

Суммы не совпадают - браузер не показывает пользователю сайт и временно блочит до решения пользователя: "Попробовать снова" "Уходим Отсюда" "Добавить в личный фаервол" "Добавить комментарий"

Ну и разумеется: "Отправить Жалобу"

> Можно попытаться заменить Тор чем-то более лёгким и быстрым, да хотя бы
> VPN-switcher cо случайными из списка адресами.

Это еще что за левый софт? Алсо, приватность VPN ниже, т.к. нет цепочки хостов, а справиться с dns leak и пр может не каждый. А главное толку мало: атакующие могут с тем же успехом атаковать траффик выходящий с vpn серверов (а также траффик с проксей и проч).

Они должны знать, что именно им нужно атаковать, в этом и фишка.

Я вот тут подумал, а ведь список всех Tor nodes открыт и всем известен.
Почему бы не атаковать их постоянно. И это не говоря о том, что треть или больше уже принадлежат спецлужбам.

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

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