The OpenNET Project / Index page

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

Уязвимость, позволяющая вклиниваться в TCP-соединения, осуществляемые через VPN-туннели

06.12.2019 13:16

Опубликована техника атаки (CVE-2019-14899), позволяющая подменить, изменить или подставить пакеты в TCP-соединения, пробрасываемые через VPN-туннели. Проблема затрагивает Linux, FreeBSD, OpenBSD, Android, macOS, iOS и другие Unix-подобные системы. Linux поддерживает механизм rp_filter (reverse path filtering) для IPv4, включение которого в режим "Strict" нейтрализует данную проблему.

Метод позволяет осуществить подстановку пакетов на уровне TCP-соединений, проходящих внутри шифрованного туннеля, но не позволяет вклиниваться в соединения, применяющие дополнительные слои шифрования (например, TLS, HTTPS, SSH). Применяемые в VPN алгоритмы шифрования не имеют значения, так как поддельные пакеты поступают из внешнего интерфейса, а обрабатываются ядром как пакеты из VPN-интерфейса. Наиболее вероятной целью атаки является вмешательство в незашифрованные соединения HTTP, но не исключается и использование атаки для манипуляции с ответами DNS.

Успешная подмена пакетов продемонстрирована для туннелей, создаваемых при помощи OpenVPN, WireGuard и IKEv2/IPSec.Tor проблеме не подвержен, так как использует SOCKS для проброса трафика и привязку к loopback-интерфейсу. Для IPv4 атака возможна в случае перевода rp_filter в режим "Loose" (sysctl net.ipv4.conf.all.rp_filter = 2). Изначально в большинстве систем применялся режим "Strict", но начиная с systemd 240, выпущенного в декабре прошлого года, режим работы по умолчанию был заменён на "Loose" и данное изменение отразилось в настройках по умолчанию многих дистрибутивов Linux.

Механизм rp_filter применяется для дополнительной проверки путей прохождения пакетов для предотвращения спуфинга адреса источника. При установке в значение 0 проверка адреса источника не производится и любой пакет может без ограничений перенаправляться между сетевыми интерфейсами. Режим 1 "Strict" включает проверку каждого приходящего извне пакета на соответствие таблице маршрутизации, и если сетевой интерфейс, через который был получен пакет, не связан с оптимальным маршрутом доставки ответа, то пакет отбрасывается. Режим 2 "Loose" смягчает проверку, чтобы допустить работу при применении балансировщиков нагрузки или асимметричной маршрутизации, при которой маршрут ответа может проходить не через тот сетевой интерфейс, через который поступил входящий пакет.

В режиме "Loose" входящий пакет проверяется на соответствие таблице маршрутизации, но считается допустимым, если адрес источника достижим через любой имеющийся сетевой интерфейс. Предложенная атака строится на том, что атакующий может отправить пакет с подменённым адресом источника, соответствующим интерфейсу VPN, и несмотря на то, что данный пакет поступит в систему через внешний сетевой интерфейс, а не через VPN, в режиме rp_filter "Loose" такой пакет не будет отброшен.

Для совершения атаки злоумышленник должен контролировать шлюз, через который пользователь выходит в сеть (например, через организацию MITM, при подключении жертвы к контролируемой атакующим точке беспроводного доступа или через взлом маршрутизатора). Контролируя шлюз, через который подключён к сети пользователь, атакующий может отправлять фиктивные пакеты, которые будут восприниматься в контексте сетевого интерфейса VPN, но ответы будут направляться через туннель.

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

Для определения IP виртуального сетевого интерфейса VPN используется отправка на систему жертвы SYN-ACK пакетов, последовательно перебирая весь диапазон виртуальных адресов (в первую очередь перебираются адреса, используемые в VPN по умолчанию, например в OpenVPN используется подсеть 10.8.0.0/24). О существовании адреса можно судить на основе поступления ответа с флагом RST.

Аналогичным образом определяется наличие соединения с определённым сайтом и номер порта на стороне клиента - перебирая номера портов в сторону пользователя отправляется SYN-пакет, в качестве адреса источника, в котором подставлен IP сайта, а адреса назначения виртуальный IP VPN. Серверный порт можно предугадать (80 для HTTP), а номер порта на стороне клиента можно вычислить перебором, анализируя для разных номеров изменение интенсивности ACK-ответов в сочетании с отсутствием пакета с флагом RST.

На данном этапе атакующий знает все четыре элемента соединения (адреса/порт IP источника и адрес/порт IP назначения), но для того, чтобы сгенерировать фиктивный пакет, который воспримет система жертвы, атакующий должен определить номера последовательности и подтверждения (seq и ack) TCP-соединения. Для определения данных параметров атакующий непрерывно отправляет поддельные RST-пакеты, перебирая разные номера последовательности, до тех пор, пока не зафиксирует ответный ACK-пакет, поступление которого указывает, что номер попадает в окно TCP.

Далее атакующий уточняет правильность определения отправкой пакетов с тем же номером и наблюдая за поступлением ACK-ответов, после чего подбирает точный номер текущей последовательности. Задача усложнена тем, что ответы отправляются внутри шифрованного туннеля и анализировать их наличие в перехватываемом потоке трафика можно лишь косвенными методами. Факт отправки адресованного VPN-серверу ACK-пакета клиентом определяется на основе размера и задержки шифрованных ответов, коррелирующих с отправкой поддельных пакетов. Например, для OpenVPN шифрованный пакет с размером 79 позволяет точно судить, что внутри содержится ACK-подтверждение.

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


  iptables -t raw -I PREROUTING ! -i wg0 -d 10.182.12.8 -m addrtype ! --src-type LOCAL -j DROP

или для nftables

  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'


Для защиты при использовании туннелей с адресами IPv4 достаточно перевести rp_filter в режим "Strict" ("sysctl net.ipv4.conf.all.rp_filter = 1"). Со стороны VPN метод определения номера последовательности может быть блокирован путём добавления к зашифрованным пакетам добавочного заполнения, делающего размер всех пакетов одинаковым.

  1. Главная ссылка к новости (https://www.openwall.com/lists...)
  2. OpenNews: Уязвимости в TCP-стеках Linux и FreeBSD, приводящие к удалённому отказу в обслуживании
  3. OpenNews: Уязвимость, позволяющая вклиниться в стороннее TCP-соединение
  4. OpenNews: Уязвимость в TCP-стеке FreeBSD, позволяющая обрывать чужие TCP-соединения
  5. OpenNews: Текущее состояние генераторов "TCP Initial Sequence Numbers" в различных ОС.
  6. OpenNews: 59.7% маршрутизаторов в домашних сетях имеют проблемы с безопасностью
Лицензия: CC-BY
Источник: ~Artem S. Tashkinov
Тип: Интересно / Проблемы безопасности
Ключевые слова: vpn, tcp, rp_filter
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (177) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 13:49, 06/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +24 +/
    /*

    Для IPv4 атака возможна в случае перевода rp_filter в режим "Loose" (sysctl net.ipv4.conf.all.rp_filter = 2). Изначально в большинстве систем применялся режим "Strict", но начиная с systemd 240, выпущенного в декабре прошлого года, режим работы по умолчанию был заменён на "Loose" и данное изменение отразилось в настройках по умолчанию многих дистрибутивов Linux.

    */

    cчитaeм этo шикapнo

     
     
  • 2.3, A.Stahl (ok), 13:55, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    И в этом тоже systemd виноват?
     
     
  • 3.7, Аноним (7), 14:04, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • –5 +/
    тут налицо вина сисдамина!
     
     
  • 4.9, Аноним (9), 14:05, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да, можно и тае сказать. А вот не надо было идти на поводу.
     
  • 3.8, Аноним (9), 14:04, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +6 +/
    А разве нет? Почитайте текст в оригинале. Таки да.
     
  • 3.13, Поцтеринг (?), 14:08, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +23 +/
    notabug, closed!
     
  • 3.29, Аноним (29), 14:47, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Угу, ожидаемое следствие когда решения о настройках по умолчанию принимают дилетанты (то есть авторы systemd).
     
     
  • 4.37, A.Stahl (ok), 14:57, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +9 +/
    Ну так где были не дилетанты? Вы же, не дилетанты, знали что вот-вот в режиме Loose будет обнаружена уязвимость. Знали ведь, да? А почему молчали?

     
     
  • 5.39, Аноним (29), 15:02, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Потому что я не нанимался тестировщиком systemd
     
  • 5.48, Аноним (48), 15:24, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    По умолчанию должен быть сторогий режим. Админ на свой стах и риск может понижать его.
     
     
  • 6.144, Андрей (??), 04:09, 07/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И ведь действительно, в GRUB же дистрибутивы не приписывают по-умолчанию отключение тормозилок для интела (ну и амд):
    GRUB_CMDLINE_LINUX_DEFAULT="quiet"

    Уверен сам - вот и дописывай сам на свой страх и риск:
    GRUB_CMDLINE_LINUX_DEFAULT="quiet mitigations=off"

     
  • 5.94, Anonymoustus (ok), 18:41, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Не-дилетанты используют Икспишечку. ;)
     
     
  • 6.163, Аноним (-), 09:49, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Windows XP has implemented the weak host model [RFC1122] on IPv4
     
     
  • 7.165, Anonymoustus (ok), 18:22, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >  Windows XP has implemented the weak host model [RFC1122] on IPv4

    И?

     
  • 6.182, Аноним (-), 05:15, 11/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Не-дилетанты используют Икспишечку. ;)

    Может еще и IE6? А то у меня как раз в бэкапах эксплойт для активиксов нашелся.

     
     
  • 7.184, Anonymoustus (ok), 07:30, 11/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> Не-дилетанты используют Икспишечку. ;)
    > Может еще и IE6? А то у меня как раз в бэкапах
    > эксплойт для активиксов нашелся.

    Давай. Я его запущу и покажу результат.

     
  • 5.106, anonymous (??), 20:53, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    ХЗ, лично мне казалось очевидным, что любой режим, кроме strict, это по умолчанию уязвимая к таким атакам система. И даже мысли не было, что это необходимо кому-то разжёвывать.
     
     
  • 6.114, annomaus (?), 22:27, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    И по этому режим по умолчанию сначала был strict. Но потом его сменили на loose, и сменили условно у всех через обновления, другими словами удалённо ослабили защиту. И год никто не знал, что это уязвимо... Как бы никто не знал, это должно выглядеть так, что ”никто не знал..","обнаружили...", "оказывается..." "Нас поосто год не было.. Мы разрабатываем это.. но мы не знаем"
     
     
  • 7.141, Аноним (141), 02:58, 07/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И чем же, спрашивается, это лучше десяточки от Майкрософта?
    Такое же отношение в плане безопасности и принудительных обновлений...
     
  • 3.49, Аноним (49), 15:25, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >  Значение sysctl "net.ipv4.conf.all.rp_filter" теперь по умолчанию выставляется в значение 2 (устанавливается режим Loose вместо Strict), что более приемлемо для хостов с несколькими сетевыми линками, маршрутизируемыми через одну сеть (например, когда клиент одновременно подключен через Wi-Fi и Ethernet);

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

     
  • 3.93, Anonymoustus (ok), 18:40, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Уточним: в этом виноваты создатели системды.
     
  • 3.169, КО (?), 10:01, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, авторы его концепции - что пироги и сапоги может строгать один комбайнер.
     
  • 2.110, dfhdh (?), 21:13, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Систамм да стал использовать балансировку нагрузки по умолчанию или что? Есть же какой-то смысл в этом?
     
  • 2.112, Rootlexx (?), 21:42, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А ничего, что в системах, не использующих systemd, rp_filter вообще 0, т.е. выключен? См. ниже в исходном сообщении об уязвимости:

    [code]**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)
    [/code]

     
     
  • 3.129, Аноним (129), 01:17, 07/12/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    И как это оправдывает авторов systemd?
     
     
  • 4.132, Rootlexx (?), 01:32, 07/12/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А при чём здесь вообще systemd? Уязвимость в systemd? - нет, не в systemd. Значение rp_filter == 2 некорректно? - нет, корректно. В системах без systemd уязвимости нет? - есть. Так в чём в данном случае вина systemd?

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

     
     
  • 5.136, пох. (?), 02:09, 07/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > А при чём здесь вообще systemd? Уязвимость в systemd? - нет, не в systemd.

    если я неткатом проброшу 23й порт напрямую в рутовый шел - это уязвимость в netcat, шелле или таки руках того кто создал такую конструкцию?

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

    Конфигурация ядра по умолчанию была безопасна. Любитель "как в винде" в очередной раз залез руками куда не надо. Причем бы тут вообще, действительно, его рукожопие, виновато ядро!

     
     
  • 6.137, Rootlexx (?), 02:18, 07/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Конфигурация ядра по умолчанию была безопасна.

    В дистрибутивах, не использующих systemd, используется как раз конфигурация ядра по умолчанию: rp_filter == 0. При этом они тоже подвержены данной уязвимости, что указано в оригинальном сообщении. Вопрос: каким образом уязвимая конфигурация по умолчанию превратилась у вас в безопасную?

     
     
  • 7.139, пох. (?), 02:33, 07/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > В дистрибутивах, не использующих systemd, используется как раз конфигурация ядра по умолчанию:

    grep rp_filter /etc/sysctl.conf
    net.ipv4.conf.all.rp_filter = 1
    таким, примерно. Это дистрибутивный конфиг.
    Нормального дистрибутива, конечно, а не слаквари.

     
     
  • 8.140, Rootlexx (?), 02:39, 07/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Сначала заявили про безопасную конфигурацию ядра по умолчанию, а теперь вдруг ... текст свёрнут, показать
     
  • 8.147, Anonymoustus (ok), 08:24, 07/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Оговорка нужная Чтоб вы понимали, анонимы, почему я говорю, что пох знаёт вс... текст свёрнут, показать
     
     
  • 9.166, Darth Revan (ok), 19:30, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    openSUSE Почему-то systemd не помешал мэйнтейнеру поменять значение на Strict ... текст свёрнут, показать
     
     
  • 10.167, Anonymoustus (ok), 20:11, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Системда помешала SUSE жить и развиваться Конвульсии вызывают сожаления и взыва... текст свёрнут, показать
     
     
  • 11.177, Аноним (177), 15:53, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Пруфы буду про конвульсии А пока я вижу, что в Сусе пакеты новее, чем в Дебиане... текст свёрнут, показать
     
     
  • 12.178, Anonymoustus (ok), 17:06, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    ERROR Peer certificate cannot be autentificated with known CA certificates 60... текст свёрнут, показать
     
     
  • 13.179, Anonymoustus (ok), 17:11, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    ЗЫ These products have reached their end of general support and thus do not prov... текст свёрнут, показать
     
  • 5.170, КО (?), 10:07, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Значение rp_filter == 2 некорректно?

    Для систем на которых поднят vpn некорректно, причем systemD в курсе подняты они или нет. Очередной пример того что его лабают и нахваливают те, кто в нем не разбирается.

     
     
  • 6.183, Rootlexx (?), 06:39, 11/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Для систем на которых поднят vpn некорректно

    Аргументируйте, почему rp_filter == 0 корректно, а более строгое rp_filter == 2 - вдруг некорректно. Или же придётся, кинув камень в systemd, кинуть гораздо больший камень в разработчиков ядра.

     
  • 2.150, mikhailnov (ok), 11:20, 07/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    https://github.com/systemd/systemd/commit/230450d4e4f - описание, зачем была сделана права с 2 на 1, читали? Я понял, что чтобы VPN-соединение продолжило работать, когда с Wi-Fi переключились на кабель, например. Сомнительный юзкейс.
     
     
  • 3.154, Аноним (154), 12:54, 07/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > когда с Wi-Fi переключились на кабель, например. Сомнительный юзкейс.

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

     

     ....большая нить свёрнута, показать (39)

  • 1.2, Адекват (ok), 13:50, 06/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    А как они получают ключ, длинной, например, 2048 бит ?, ведь openvpn по сути это udp(например) инкапсулированный в ip.
    ip доставляется через сеть интернет, демультиплексирует udp, а вот его содержимое уже шифровано, и расшифрованно может быть только при помощи ключа, ну после расшифровки мы опять получаем ip, но уже виртуальный, вида 10.8.0.1, а в нем инкапсулированное tcp/udp/icmp.
    Причем ключ никуда не передается, он серкретный, просто им на месте данные шифруются, а на удаленной стороне расшифровываются.
     
     
  • 2.4, Аноним (4), 13:56, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +10 +/
    В том-то и дело, что ни ключ, ни логин-пароль не нужны. Пакет прилетает из внешнего интерфейса, а ядро воспринимает его как пакет из VPN-интерфейса.
     
     
  • 3.14, Аноним (14), 14:09, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Но тогда причем тут ВПН, если точно так же можно подделать ТСП и без ВПНа ? (но по факту надо подобрать 2 пары ip/порт и номера seq, все это и так известно 100500 лет как, но не очень просто реализуется на сколько то нагруженных концах соединения)
     
     
  • 4.20, пох. (?), 14:22, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    vpn тут притом, что траффику из vpn'а обычно доверяют (речь, если что, Васян, не о твоей порнухе с малолетками, а о корпоративных vpn, наивно полагаемых многими - надежным средством связи через ненадежные каналы)

     
     
  • 5.30, Аноним (29), 14:49, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Почему «наивно»?
     
  • 3.16, Адекват (ok), 14:12, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    то есть если vpn основан на udp а не на tcp - данный метод не сработает ?
    Вообще для атаки нужно, чтобы под контролем был роутер, роутер подключенный к компу жертвы - вопрос при чему тут vpn вообще ?
     
     
  • 4.24, пох. (?), 14:25, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    сработает. Подделать можно - только udp, тот что внутри vpn - для tcp слишком много надо знать, и ответный пакет все равно не получишь.

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

    (что на них никогда и низачто не должно быть отключенного rp-filter - неважно, поцтеринг уже позаботился о тех из них, кто по дурости использовал наколеночное линукс-решение вместо железки.)

     
  • 2.171, КО (?), 10:12, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Они пишут сразу в декодированный канал, что там н6а уровне шифрования им фиолетово.
     

  • 1.5, Аноним (9), 14:00, 06/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    насколько понимаю, на *BSD со включенным в pf antispoof - работать не будет, а ведь там, где есть pf - обычно есть и antispoof из файла-примера по умолчанию...
     
  • 1.6, Аноним (6), 14:00, 06/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Не увидел бага. Это особенность.
    Rp filter отключается только на маршрутизаторах с асинхронным трафиком. Отключать  rp filter на оконечных устройствах tcp сессий - как бы говорит об уровне компетенции дистростроителей.
     
     
  • 2.10, Аноним (9), 14:06, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    полагаю, стильномодномолодёжные девляпсы не поймут.
     
  • 2.12, Аноним (12), 14:07, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    у нормальных людей это брандмауером прикрывается на этапе проектирования. а те кто доверяет шлюзу провайдера и принимает с него даже для внутреенних ип - ссзб
     
     
  • 3.87, ll (??), 18:03, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    нет идеальных людей... не одно, так другое...

    кто-то доверяет провайдерским шлюзам, а кто-то проприетарным биосам/уефи, не заморачиваясь прошивкой коребута...

     
     
  • 4.91, Аноним (12), 18:38, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    идеальных людей нет. но есть (пока еще) квалифицированные специалисты.
     
     
  • 5.135, пох. (?), 02:00, 07/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    нету. В смысле, в IT - уже нету. Кинолога одного знаю.
     
  • 2.23, Аноним (23), 14:23, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +17 +/
    >Отключать  rp filter на оконечных устройствах tcp сессий - как бы говорит об уровне компетенции дистростроителей.

    Это дефолтная фишка systemd -- поднаcрать там где не ждали.

     
     
  • 3.32, Аноним (29), 14:51, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ох, как я с Вами согласен!
     
  • 3.36, Andrey Mitrofanov_N0 (??), 14:55, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >>Отключать  rp filter на оконечных устройствах tcp сессий - как бы говорит об уровне компетенции дистростроителей.
    > Это дефолтная фишка systemd -- поднаcрать там где не ждали.

    Теперь даже до

    "FreeBSD, OpenBSD, [...] macOS, iOS и другие Unix-подобные системы"

    долетает.  "щикарно", да...

     
     
  • 4.51, nuclight (??), 15:39, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Для этого, а точнее не (только) этого, а и много чего еще (например не давать своим юзерам быть DDoS'ерами), много лет как существует ipfw verrevpath.
     
     
  • 5.78, Аноним (9), 17:33, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    и - для любителей last match, хитрых policy NAT'ов и гигантских таблиц - antispoof quick в pf.conf
     
     
  • 6.97, Аноним (97), 19:29, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > и - для любителей last match, хитрых policy NAT'ов и гигантских таблиц
    > - antispoof quick в pf.conf

    # ipfw show | grep anti
    00010      14        882 deny ip from any to any not antispoof in

     

  • 1.11, пох. (?), 14:07, 06/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    что у вас за устаревшая немодная вонючая портянка в конце текста и что она вообще означает? Мы понимаем только синтаксис nft!

    (К сожалению, прекрасная утилита iptables-translate выдала только какую-то х-ню при попытке интерпретировать вашу портянку.)

     
     
  • 2.18, dimqua (ok), 14:17, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Значит она пока не такая прекрасная, как хотелось бы.
     
     
  • 3.40, пох. (?), 15:02, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Значит она пока не такая прекрасная, как хотелось бы.

    в соседней новости с вами не согласны ;-)

    (скормил, чисто поржать. Результат, в общем, неудивительный.)

     
  • 2.53, Nadanon (?), 15:49, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > что у вас за устаревшая немодная вонючая портянка в конце текста и что она вообще означает?

    О, ДеВоПсЫ подтянулись.

     
     
  • 3.56, пох. (?), 16:04, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >> что у вас за устаревшая немодная вонючая портянка в конце текста и что она вообще означает?
    > О, ДеВоПсЫ подтянулись.

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

     
     
  • 4.172, привет (ok), 11:34, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    У правильного девопа вообще нет фаервола
    потому как это не задача девопса вообще,
    его задача показать красивый график, и,
    чтоб все вроде как работало. Да и мало вероятно
    что девопс вообще знает что это - вы про монги и тп
    открытые без авторизации не слышали что ли?
     
     
  • 5.173, пох. (?), 11:43, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    дык, у самого монга такая же. Если ее закрыть - она, внезапно, и работать не будет.

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

    Она тебе еще и тормозов добавит туда, где их как раз быть не должно.

    Так что - улыбаемся и машем, парни. В конце-концов, всегда можно прикинуться ту...м девляпсом, который просто не ведает что творит. Сказали поставь монгу -  поставил монгу. А поскольку она не работала - sudo firewall-cmd --permanent --add-port=27017/tcp ; sudo firewall-cmd --reload - понятия не имею, что это такое, но на stackoverflow так было написано!

     
     
  • 6.175, привет (ok), 12:51, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    вот это дельная вещь - допишу в ТЗ коллегам
    а то чот у них не запускается монга-то
    Спасибо
     
  • 3.153, Аноним (154), 12:45, 07/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > ДеВоПсЫ

    ДевоПсы! Сначала РедхатОвцы а потом и ДебианОвцы.

     
  • 2.65, Darth Revan (ok), 16:36, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > К сожалению, прекрасная утилита 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'

    Всё, выглядит вполне прилично.

     
     
  • 3.131, Аноним (129), 01:23, 07/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Всё, выглядит вполне прилично

    Выгляди отвратительно, три строки вместо одной, постоянное дублирование слов ip ip raw raw prerouting prerouting hook prerouting.

    Ужас.

     
     
  • 4.143, Darth Revan (ok), 03:45, 07/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Таблицы и цепи сами собой не возникают, как на 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 файл".

     

  • 1.15, Аноним (15), 14:11, 06/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    # cat /proc/sys/net/ipv4/conf/all/rp_filter
    0

    Проклятый системдос! И до openwrt добрался!

     
     
  • 2.34, Аноним (29), 14:53, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    openwrt это маршрутизатор с поддержкой ассимитричного трафика
     
     
  • 3.41, пох. (?), 15:03, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > openwrt это маршрутизатор с поддержкой ассимитричного трафика

    а ведь некоторые, не будем показывать пальцем, тащат на него openvpn!

     
  • 2.45, Аноним (45), 15:06, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Системдос выставляет значение 2.
     
     
  • 3.50, Аноним (15), 15:35, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    2 — это там, где он установлен.
     
  • 2.64, Аноним (64), 16:30, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    а меня 1
     
  • 2.127, хотел спросить (?), 00:30, 07/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    CentOS 7
    cat /proc/sys/net/ipv4/conf/all/rp_filter
    1

    Fedora 30
    cat /proc/sys/net/ipv4/conf/all/rp_filter
    2

    пойду поменяю на Fedora

     

  • 1.17, Аноним (12), 14:13, 06/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    я только не понял, с rp_filter=0 оно работает или нет?
     
     
  • 2.19, Аноним (-), 14:20, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А самому попробовать первую стадию (определение локального адреса VPN) ну вообще что-ли никак?
     
  • 2.21, Аноним (-), 14:22, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    насколько понял, если вы сидите из мухосранска где только ipv4 - настройки rp_filter достаточно. Если есть возможность подключиться через ipv6 - нужно подкручивать iptables
     
     
  • 3.142, хотел спросить (?), 03:28, 07/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    а если ipv6 недоступен внутри тунеля?
    если у меня в openVPN только ipv4?
     
  • 2.66, Аноним (64), 16:37, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    походу тебя поимеют
     

  • 1.25, Нанобот (ok), 14:28, 06/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    Слишком надумано
    Я правильно понимаю, что включение strict приведёт к проблемам с доступом, например нельзя будет пропинговать внешний адрес роутера из внутренней сети?
     
     
  • 2.28, Аноним (-), 14:35, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    включение strict будет проверять, что отправитель и адресат совпадают, так сказать. На этом все
     
     
  • 3.31, Аноним (-), 14:50, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    *адресат и получатель же
     
  • 2.43, пох. (?), 15:04, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Слишком надумано
    > Я правильно понимаю, что включение strict приведёт к проблемам с доступом, например
    > нельзя будет пропинговать внешний адрес роутера из внутренней сети?

    нет, неправильно.
    Проверяется _reverse_path.

     

  • 1.26, Нуб (?), 14:32, 06/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    ребята, объясните - правильные параметры выставляются через
    sudo sysctl -w "net.ipv4.conf.all.rp_filter=1"
    да?
     
     
  • 2.33, Аноним (33), 14:51, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >/etc/sysctl.conf

    147-# 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


    если я правильно помню заметку фильтрация могла быть включена отдельно в файрволе

     
     
  • 3.42, Аноним (-), 15:03, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >etc/sysctl.conf

    на манжаре вообще нет этого файла

     
     
  • 4.44, Аноним (33), 15:05, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Его надо создать. Ну или

           /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.conf

    man sysctl.conf

     
     
  • 5.92, Аноним (-), 18:39, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    /etc/sysctl.d/100-manjaro.conf имеется. С единственной записью:
    vm.swappiness = 1
    Дописать после этого?
     
     
  • 6.134, Аноним (33), 01:44, 07/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Какие кошмарные дефолты, впрочем, в рачике всё нужно настраивать самому. Можно сделать /etc/sysctl.d/999-custom.conf и записать туда, в том числе vm.swappiness = 90.
     

  • 1.27, Аноним (-), 14:33, 06/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +9 +/
    **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)

     
     
  • 2.35, Нанобот (ok), 14:54, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Devuan опасносте!😱
    А в коментариях выше местные иксперды уже пришли к выводу, что виноват systemd
     
     
  • 3.38, Аноним (29), 14:58, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    А о чём вы спорите? Там где systemd — это решение принимал systemd, это же у них в release notes написано. Странно было бы считать их не виновными.
     
  • 2.70, Olololo (?), 16:56, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +9 +/
    OpenBSD - Only two remote holes in the default install, in a heck of a long time!
     
     
  • 3.79, ll (??), 17:35, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > Only two remote holes in the default install, in a heck of a long time!

    бгг.. фраза звучит довольно фальшиво (уже как несколько лет), но фанатики хавают и это главное...

     
     
  • 4.88, Аноним (9), 18:07, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Вы знаете, а я почему-то полагал, что люди её применяют - после тщательного анализа всех "за" и "против", конечно - в качестве, например, маршрутизатора либо балансера. Выходит, я ошибался, и всё дело в банальном фанатизме?..
     
     
  • 5.100, пох. (?), 19:42, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ну вон перечитай жизенный путь одного местного, гхм нефанатика, изложенный ча... большой текст свёрнут, показать
     
     
  • 6.103, Olololo (?), 20:30, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >что-то когда-то понаулучшали, но это было давно, и никакой особой пользы не принесло никому.

    Напомнить, как после обнародования уязвимости Spectre в процессорах только у OpenBSD проблема не выявлялась? Все остальные OS глубоко соснули. Это называется не принесло пользы?

    >Первый и последний раз применение openbsd по делу я видел в 2007м году

    Что же сейчас модно применять у благородных мусье?

     
     
  • 7.111, Anonymoustus (ok), 21:13, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Что же сейчас модно применять у благородных мусье?

    Десяточку, вестимо.

     
  • 7.115, пох. (?), 22:44, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    лолшта spectre не имеет отношения к героической поебде над гипертредингом, с ко... большой текст свёрнут, показать
     
     
  • 8.117, Olololo (?), 22:58, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Бред не неси Причём тут Meltdown Я где-то про него писал Может ещё какие нибу... текст свёрнут, показать
     
     
  • 9.123, пох. (?), 23:41, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    бред нес твой божок Тео, перемешав две проблемы в своих широковещательных заявле... большой текст свёрнут, показать
     
     
  • 10.124, Olololo (?), 23:49, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Что ЧТО В виртуальных машинах тоже патчи на компилятор помогут В интерпрета... текст свёрнут, показать
     
     
  • 11.138, пох. (?), 02:27, 07/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    да В смысле, наоборот - кроме них ничего не поможет Причем понадобится собират... большой текст свёрнут, показать
     
  • 10.164, пох. (?), 17:53, 08/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    да, кому поржать над пастушком с заевшей пластинкой Волки - гугль притащил из... текст свёрнут, показать
     

     ....большая нить свёрнута, показать (14)

  • 1.46, Аноним (46), 15:10, 06/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Например, для OpenVPN шифрованный пакет с размером 79 позволяет точно судить, что внутри содержится ACK-подтверждение.

    Ну блин, padding уже везде должен быть жеж поидее

     
  • 1.47, Ilya Indigo (ok), 15:24, 06/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Даже ничего изменять не пришлось code net ipv4 conf all accept_redirects 0 ... большой текст свёрнут, показать
     
     
  • 2.55, Аноним (55), 15:59, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Надеюсь ты сам понимаешь что тут столько настроек чтобы сам ты тут ничего поменять не смог. И то что ты просишь некоего Анонимуса помочь показательно.
     
     
  • 3.57, пох. (?), 16:06, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Надеюсь ты сам понимаешь что тут столько настроек чтобы сам ты тут
    > ничего поменять не смог. И то что ты просишь некоего Анонимуса

    он похоже не понимает, что эти настройки означают и как работают - судя по мешанине с .default .all и per-interface.

    > помочь показательно.

    Б-г поможет!


     
     
  • 4.62, Аноним (55), 16:18, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    На дефолтные из убунты не похоже видимо он их сам правил.
     
     
  • 5.116, пох. (?), 22:45, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    на копипасту из вопросов со stackoverflow похоже - до ответов, видимо, опять недочитано.
     
  • 3.58, Ilya Indigo (ok), 16:11, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Надеюсь ты сам понимаешь что тут столько настроек чтобы сам ты тут
    > ничего поменять не смог. И то что ты просишь некоего Анонимуса
    > помочь показательно.

    Я понимаю для чего они изменяются, но не понимаю до конца все последствия и накладные расходы связанные с ними.

     
     
  • 4.59, Аноним (55), 16:13, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Хорошо что ты сам смог это более четко сформулировать.
     
     
  • 5.63, Ilya Indigo (ok), 16:25, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Да я это и не говорил никогда что разбираюсь в параметрах настройки ядра и в фильтрации пакетов.
    От того что Вы притворяетесь всезнающим, умнее Вы не становитесь.
     
  • 2.68, Fyjy (?), 16:49, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ох, мать-перемать, вот это простыня. Это ты на своем десктопе/лэптопе такое фигачишь? А зачем? Про просьбу пояснить каждое значение я уж вообще молчу.
     
     
  • 3.82, Ilya Indigo (ok), 17:43, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Ох, мать-перемать, вот это простыня. Это ты на своем десктопе/лэптопе такое фигачишь?
    > А зачем? Про просьбу пояснить каждое значение я уж вообще молчу.

    Вообще-то это веб-сервер (nginx/php/redis), настроенный на высокую нагрузку.
    На десктопе я тоже это использую, у меня мой десктоп дев-сервер и я хочу чтобы у него конфиг был максимально приближённый к проду, и в крайнем случае мог подстраховать его.

    Настраивалось для защиты от DDOS-а и способность обрабатывать много соединений.

    ЕМНИП
    sysctl net.ipv4.conf.all.rp_filter = 1
    net.core.somaxconn = 65535
    И отключение больших прозрачных страниц в параметрах загрузки требовал redis.

     
     
  • 4.118, пох. (?), 22:59, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А это ничего, что его требования - перпендикулярны большим нагрузкам и вообще ... большой текст свёрнут, показать
     
     
  • 5.125, Ilya Indigo (ok), 23:52, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Вы можете обосновать своё заявление Я читал про них в то время, уже подзабыл чт... большой текст свёрнут, показать
     
     
  • 6.128, пох. (?), 00:39, 07/12/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    лень Можно просто включить обратно huge pages и убедиться, что мир не рухнет, и... большой текст свёрнут, показать
     
     
  • 7.130, Ilya Indigo (ok), 01:21, 07/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Я месяц назад перешёл на nginx php-fpm апач со своим htaccess уже в прошлом Под... большой текст свёрнут, показать
     
     
  • 8.174, пох. (?), 11:59, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    у тебя основные задержки - на установление соединения с клиентом и рестарт пхп-и... текст свёрнут, показать
     
  • 2.71, Olololo (?), 16:58, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Добавь вот это

    [code]
    vm.swappiness=0
    vm.dirty_ratio=60
    vm.dirty_background_ratio=40
    vm.dirty_writeback_centisecs=3000
    vm.dirty_expire_centisecs=5000

    net.ipv6.conf.all.disable_ipv6=1
    net.ipv6.conf.default.disable_ipv6=1
    net.ipv6.conf.lo.disable_ipv6=1
    [/code]

     
     
  • 3.73, Fyjy (?), 17:05, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > 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

     
     
  • 4.74, Olololo (?), 17:11, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Нет IPv6, а значит и нет дырок в IPv6 и дырок эксплуатируемых с помощью IPv6. Это называется мудрость.
     
     
  • 5.75, Fyjy (?), 17:15, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Что такое «дырки в IPv6»?
    А так отруби тогда вообще сетевой стек, что уж мучиться
    Блинский ёж, у меня ВСЯ работа с серверами идет по IPv6, вот просто вся, а ты тут даешь людям советы его отрубать. Ты откуда сбежал? Из 2000 года?
     
     
  • 6.76, Olololo (?), 17:20, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    IPv6 слишком молод, чтобы его использовать. Ещё даже в IPv4 не все дырки отловили, лет через 25 можно будет присматриваться к IPv6, но не раньше.
    Живу на IPv4 и горя не знаю.
     
  • 6.156, Michael Shigorin (ok), 13:52, 07/12/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Блинский ёж, у меня ВСЯ работа с серверами идет по IPv6,
    > вот просто вся, а ты тут даешь людям советы его отрубать.

    "Сижу на героине весь, просто весь, а ты тут предлагаешь дилеров отстреливать" (логика та же)

     
     
  • 7.159, Fyjy (?), 17:49, 07/12/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Миша, мы все знаем, что логика не твоя сильная сторона, а мозг у тебя отсутствует. IPv6 — стандарт в индустрии уже, то что в твоем отделе ФСБ об этом не знают ничего не значит, они и о существовании интернета узнали только на 10ый год правления ботоксного карлика.
     
     
  • 8.161, Olololo (?), 19:37, 07/12/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    20 год не хочешь Пу сидит со второй половины 1999 года, сидит уже больше чем Бр... текст свёрнут, показать
     
     
  • 9.162, Fyjy (?), 22:45, 07/12/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А об интернете они узнали 10 лет назад, как раз тогда начали первые законы о цен... текст свёрнут, показать
     
  • 4.126, пох. (?), 00:01, 07/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Вот только что был, но ты добавил фигню по совету анона с опеннета и все отвалилось

    причем одного раза выстрелить самому себе из ружья в задницу показалось мало, сделал контрольный, и еще прикладом добил. Какое нелепое самоубийство!

     
  • 3.85, Ilya Indigo (ok), 17:56, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Добавь вот это
    > net.ipv6.conf.all.disable_ipv6=1
    > net.ipv6.conf.default.disable_ipv6=1
    > net.ipv6.conf.lo.disable_ipv6=1  

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

     
     
  • 4.86, Olololo (?), 18:01, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Выруби логи, делов-то.
     
  • 4.90, gogo (?), 18:37, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Как раз наоборот. Именно это рекомендуемый, например, красношапкой способ отключния.
    Ибо есть приложениия, точно postfix, которыйе неистово верят в существование ipv6 всегда. И очень плачут, когда ядро его не поддерживает.
     
     
  • 5.101, Аноним (101), 19:52, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Про inet_protocols=ipv4 не слышали?
     
     
  • 6.119, пох. (?), 23:01, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    тебе же сказали - выключи логи! Они ВСЕ проблемы так решают.


     
     
  • 7.148, Anonymoustus (ok), 08:57, 07/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > тебе же сказали - выключи логи! Они ВСЕ проблемы так решают.

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

     

     ....большая нить свёрнута, показать (30)

  • 1.52, AnonPlus (?), 15:46, 06/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Отличная иллюстрация того, зачем надо использовать HTTPS.

    Сначала был KRACK, который позволял прослушивать трафик беспроводной сети Wi-Fi без знания пароля. Теперь можно влезть в VPN-туннель.

    Используйте HTTPS, пригодится в таких вот случаях, когда предыдущий уровень защиты облажался.

     
     
  • 2.95, Anonymoustus (ok), 18:47, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да-да, особенно умиляет HTTPS _вместо_ FTP.
     
     
  • 3.152, InuYasha (?), 11:39, 07/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    кто-то ещё пользуется FTP? :D
     

  • 1.54, Аноним (55), 15:55, 06/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    И это только один системдосовский нотэбаг.
     
  • 1.61, sage (??), 16:18, 06/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Я писал о похожей атаке в 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 не требуется.

     
     
  • 2.72, Olololo (?), 17:00, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Так вот мне засирал порты в 2015 году.
     
     
  • 3.99, anonymous (??), 19:39, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Так вот кто тебе в порты наcpaл... и совсем и не абама...
     
  • 2.105, Аноним (-), 20:53, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Это у тебя там Рика-тяма на аватарке или просто похожа?
     
  • 2.120, пох. (?), 23:07, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Важное отличие от описанной атаки в том

    что тебе надо откуда-то узнать ip-адрес. А если у тебя при подключенном vpn и перенаправленном в него default gateway утекают реальные адреса - через сцайп, или чере моднявый webrtc - то поздно уже пить боржом.

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

     

  • 1.67, Fyjy (?), 16:48, 06/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    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: bionic

    net.ipv4.conf.all.rp_filter не менял, все в дефолте. То есть в LTS'е проблемы нет, а те кто сидит на тестовых ветках делают это добровольно и осознают что делают(а если не осознают, то сами виноваты)

     
     
  • 2.69, Аноним (64), 16:50, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    +
     
  • 2.121, пох. (?), 23:09, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > То есть в LTS'е проблемы нет

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

     
     
  • 3.160, Fyjy (?), 17:50, 07/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Сегодня обновления ставил. Дальше фантазировать будешь?
     

  • 1.84, Аноним (46), 17:53, 06/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Блин, iptables и nftables, конечно, мощные инструменты. Но какой же вырвиглазный синтактсис. Сравнить, хотя бы, с pf
     
  • 1.89, Аноним (89), 18:13, 06/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    а в FreeBSD что править и патчить?
     
     
  • 2.96, xm (ok), 19:03, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    В ipfw - deny ip from any to any not verrevpath in
     

  • 1.98, Аноним (98), 19:35, 06/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Я тут недавно обнаружил, что через NAT-сервер и так утекают локальные адреса. Тупо некоторые FIN и RST -пакеты не натятся и улетают как есть. Для FIN-пакетов я подобрал параметры в sysctl, которые это фиксят, а вот RST-пакеты всё-равно не все натятся - по-моему это баг ядра.

    Поснифайте внешний интерфейс на своём NAT, у кого есть такая возможность.

     
     
  • 2.122, пох. (?), 23:20, 06/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    на бордере - _любом_ бордере, а не только натящем, является хорошей традицией не "снифать внешний интерфейс", а иметь либо маршруты для rfc1918 сетей в blackhole или иной местный аналог /dev/null, либо правило drop в пакетном фильтре.

    Это не баг ядра, это баг твоих настроек скорее всего. Отправлять эти rst дальше null не имеет никакого смысла.

     
  • 2.149, Нанобот (ok), 10:45, 07/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это давно известная багофича. В iptables можно фильтровать как-то вроде "-m conntrack --ctstate INVALID -j DROP"
     

  • 1.102, Анонимчик (?), 20:30, 06/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Так это для впн...)) можно и на ноль сидеть, Оперой не пользуюсь и другими впнками тоже.
     
  • 1.104, fedora (?), 20:52, 06/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    #cat /proc/sys/net/ipv4/conf/all/rp_filter
    1
     
  • 1.108, Онаним (?), 20:59, 06/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Для проведения атаки необходимо узнать назначенный VPN-сервером IP-адрес сетевого интерфейса туннеля, а также определить, что в данный момент через туннель активно соединение к определённому хосту.

    Ну и root-доступ бы ещё неплохо.

     
  • 1.113, Аноним (113), 21:56, 06/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А какого хрена вообще какие-то режимы влияют на изоляцию VPN-туннелей? Какого хрена вообще для этого используется rp_filter?
     
     
  • 2.133, Аноним (129), 01:33, 07/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Потому что vpn туннель реализован в виде виртуального сетевого интерфейса
     

  • 1.145, Аноним (145), 04:27, 07/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    кто полагается на IP-адреса в вопросах безопасности VPN тот сам себе злобный буратино
     
     
  • 2.146, Аноним (145), 04:30, 07/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    на Archlinux всё в порядке
     
     
  • 3.151, Аноним (151), 11:39, 07/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >на Archlinux всё в systemD.

    Этим всё сказано.

     

  • 1.155, Michael Shigorin (ok), 13:40, 07/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > но начиная с systemd 240, выпущенного в декабре прошлого года,
    > режим работы по умолчанию был заменён на "Loose"

    Понятно, что все высказались; кто-нить уже git grep, git blame и git show насчёт хоть каких-то аргУментов?

     
     
  • 2.168, Andrey Mitrofanov_N0 (??), 09:01, 09/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> но начиная с 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/230450d4e4f1f5fc9fa4295ed9185eea5b6e

    lkundrak authored and poettering committed on 28 Nov 2018

    https://fedoraproject.org/wiki/User:Lkundrak

    LP и S-D в едином порыве с F-d и NM....
        [I]...встречаются роковые мгновения, когда он беспощадно рвет со своим прошлым...[/I]
    ....рвут прошлое rp_filter-а.

     

  • 1.158, Аноним (-), 15:10, 07/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > включение которого в режим "Strict" нейтрализует данную проблему.

    Где там чего менять?

     
  • 1.176, Ivan_83 (ok), 13:30, 09/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Сразу видно уровень местных экспертов - все побежали включать.

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

    Уровень авторов антиспуфинга в линухе тоже зашкаливает - антиспуфить мультикаст из 224/4 - это надо быть особо одарённым.

    И ровно по той же причине в опенврт эта херня отключена.

     
  • 1.180, mumu (ok), 02:22, 10/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Первым делом при настройке любого маршрутизатора запрещаю приём пакетов на интерфейс не из его сети. Это прям базовая вещь. Но да, девопсяры обычно не в курсе.
     
  • 1.181, Аноним (181), 01:14, 11/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ecли у меня UDP с TLS на pfsense, мне стоит беспокоится по поводу сабжа?
     
  • 1.185, Аноним (185), 12:04, 15/12/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Опубликована техника атаки (CVE-2019-14899), позволяющая подменить, изменить или подставить пакеты в TCP-соединения, пробрасываемые через VPN-туннели.

    Примерно ~15 лет назад данная техника атаки на шифрованные тунели была разработана и опубликована мною лично на одном украинском форуме.

    И другой человек, с этого украинского форума, предложил патч для выравнивания всех пакетов тунеля до MTU.

    Там же предлагали защиту с помощью сетевого экрана.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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