Остается ли возможность логировать трансляции NAT модулем ipt_NETFLOW через natevents при описанном режиме работы NAT с flowtables в nftables?

Добрый день! Спасибо большое за статью. Хотел уточнить пару вопросов от коллег :)

1. А есть ли параллельно графикам загрузки процессоров график с количеством rx_dropped?
2. Какая сетевая карта использовалась?

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

Это именно галопом по Европам, потому что в час доклада невозможно всунуть много разных случаев. Напишите в личку, если нужно что-то более конкретное.

Пока нет. Я хочу для начала узреть, как я его дал — оно же должно быть в письменном виде, вот и посмеемся. Отменить согласие, конечно же, всегда успею :)

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

Спасибо. Исправил.

Я бы для начала разделял два понятия: «согласие» на обработку, то есть вообще мое согласие, что образцы меня (голоса, внешнего вида, ткани моего тела) могут быть собраны кем-то, и дальше, уже конкретные собранные образцы.

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

Нарисую простой сценарий. Абонент заходит на не очень хороший сайт, который согласен за денежку вставить в код любой внешний url, который позволит идентифицировать IPv6-абонента.

Обратный скан будет произведен сразу же, без особых задержек, если с той стороны абонент интересен. А поскольку нынче не Edge на дворе, то скан будет быстрый, сочный, вкусный, со всеми пирогами.

Попробуйте такое с NAT.

Про это было много копий поломано. Вы вряд ли будете выдавать сложный адрес из середины диапазона, если будете выдавать его вручную, это раз. Различные протоколы могут «случайно» раскрыть Ваш адрес, это два. Перехват трафика с целью выявления адресов тоже никто не отменял, пусть это и достаточно сложный путь, это три.

В Хакере про это писали.

Блокировать или не блокировать входящий трафик на 13х порты — это пока открытый вопрос.

Сейчас уже не нужно. А вот во времена MSBlast было еще как нужно, поверьте.

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

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

Эм, относительно.

1. Да, я считаю патернализм оправданным, поскольку сами пользователи этого не делают (см. первую часть статьи). Делать это некому, кроме оператора.

2. Я, к сожалению, видел мало вменяемых реализаций statefull firewall, вернее, те, что видел, мне не оч. нравились.

Да, IoT — это плохо, но решать его надо на уровне IoT'а. Например, обязательным отзывом уязвимых моделей за счёт производителя. Либо OTT updates, либо оплачиваешь отзыв.

А вот это уже неисправимый идеализм. На практике, когда производитель уже продал устройство (особенно если это стартап, с настроением «пропели, а там хоть не рассветай») требовать от него отзыва наивно. Он просто не будет этого делать.

Ну а про обновления — старая песня. Через какое-то время производитель объявляет EOL, и говорит, что больше вот этот девайс не поддерживает, дальше догадаетесь.

Эм, я сразу пишу, что говорю от лица своего провайдера. Не более того.

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

Я общаюсь с другими операторами, везде наблюдаю плюс/минус похожую картину.

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

Я допускаю, что к массовому приходу IPv6 операторы научатся это делать без NAT, но ощутимо в этом сомневаюсь.

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

Когда устройств станет больше, а latency начнет иметь все большее значение, локальные соединения станут более приемлемым механизмом. И рано или поздно мы получим открытые порты и белый IPv6.

Вы с пользовательской стороны имеете ввиду или с операторской?

С пользовательской — это роутер, его не надо настраивать, по дефолту настроен.

См. чуть ниже, промахнулся :(

Вы говорите о stateless-файрволле, или о чем? Вы хотите дать возможность разрешать входящие соединения с определенных IP-адресов, а для всех остальных отключать эту возможность? Считаю, что это уже не провайдерское дело.

Я с Вами совершенно согласен. Только проблема в том, что это не дело пользователя. Ему плевать.

Смотрите, главный вопрос будет «Где ее втыкать, эту блокировку?». Если кратко о проблеме, то на магистральном уровне ее втыкать дорого, а на уровне свича в подъезде хлопотно и/или не всегда возможно.