boco

омг =) правило нужно ставить туда, где трафик, который вы хотите собрать, еще есть. например, самым первым в цепочке FORWARD. кусок кода, который я привел был просто намеком на то, что вы забыли добавить правило в фаервол. это, кстати, написано в документации на модуль 4. Example of directing all IPv4 traffic into the module: # iptables -I FORWARD -j NETFLOW # iptables -I INPUT -j NETFLOW # iptables -I OUTPUT -j NETFLOW Note: It is preferable (because easier to understand) to _insert_ NETFLOW target at the top of the chain, otherwise not all traffic may reach NETFLOW if your iptables configuration is complicated and some other rule inadvertently consume the traffic (dropping or acepting before NETFLOW is reached). It's always good to test your configuration. Use iptables -L -nvx to check pkts/bytes counters on the rules.

собирать ее? iptables -A FORWARD -j NETFLOW

плюс можно но лучше unbound и его "max-udp-size"

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

не нужно, его же оператор услужливо предоставляет =)

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

а если закавычить одинарными кавычками весь урл? и заодно запустить с отдельным конфигом, в котором только этот урл.

пробел в пароле. или какой-то другой символ, который превращает урл в огрызок вида "rtsp://cyberlive:passwo", где "passwo" естественно каким-нибудь atoi() преобразуется в "0"

cache-max-ttl, cache-max-negative-ttl

раз: https://www.sysnative.com/forums/networking-tutorials/10398-how-enable-use-rip-listener-routing-computer.html два: http://sourcedaddy.com/windows-7/managing-rip.html

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

без понятия. нашим сотрудникам этот продукт на какой-то тусовке разрекламировали.

https://rdp.ru/products/service-gateway-engine/qoe/

я просто оставлю это здесь:

а в чем суть вопроса? если нашему нс всегда отдаются заблоченные ипы, то клиенту отдастся пустой ответ. если бы фильтра ответов не было, клиенту улетели бы заблоченные ипы и он все равно не смог бы туда попасть (т.к. заблочены), только после tcp timeout. можно немного изменить схему: поставить перед анбаундом бинд с опцией forward first. тогда если бинд получит от анбаунда пустой ответ, он сам слазит в днс за ответом и отдаст клиенту все полученные записи. то есть, схема будет работать так: клиенту улетают отфильтрованные ип-адреса, если среди них есть незаблокированные и все ип-адреса, если среди них только заблокированные.