1. Для блокировка используем

[msa]

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

Ну и уже на нём весь трафик по 80 порту проходит через софтину, остальной - прозрачно роутится

А можно пример конфигов bgpd, чтобы заворачивать некошерные ip на фильтр? В идеале вместе со скриптом, который заливает список ip на этот bgpd. Можно в ПМ

[roysbike]

Я использую setfib на freebsd.

 

172.30.0.3 шлюз где запущен фильтр url

172.30.0.0/16 , клиентская сеть

#${fwcmd}
setfib 1 route delete default 
setfib 1 route add default 172.30.0.3
${fwcmd} add setfib 1 ip from 172.30.0.0/16 to 'table(3)'

 

в таблице 3 , 1к не кошерных ip

Изменено 17 апреля, 2014 пользователем roysbike

[YuryD]

Я использую setfib на freebsd.

 

172.30.0.3 шлюз где запущен фильтр url

172.30.0.0/16 , клиентская сеть

#${fwcmd}
setfib 1 route delete default 
setfib 1 route add default 172.30.0.3
${fwcmd} add setfib 1 ip from 172.30.0.0/16 to 'table(3)'

 

в таблице 3 , 1к не кошерных ip

 

setfib 1 - не ошибка ? вроде fib 1 это основная таблица ? Хотя поправляюсь, всё нормально. Давно setfib не баловался.

И кстати и setfib гораздо меньше грузит проц чем ipfw fwd

[^rage^]

я очень надеюсь, что кто-нибудь чистый ipv6-only хост с запрещенным контентом и доступом к нему через teredo/6to4.

[metalsoft]

[metalsoft@metalsoft build]$ make

Scanning dependencies of target nfq_filter

[ 25%] Building CXX object CMakeFiles/nfq_filter.dir/nfq.cpp.o

[ 50%] Building CXX object CMakeFiles/nfq_filter.dir/config.cpp.o

[ 75%] Building CXX object CMakeFiles/nfq_filter.dir/sender.cpp.o

[100%] Building CXX object CMakeFiles/nfq_filter.dir/parser.cpp.o

Linking CXX executable nfq_filter

CMakeFiles/nfq_filter.dir/nfq.cpp.o: In function `netlink_loop(unsigned short)':

nfq.cpp:(.text+0x1545): undefined reference to `nfq_open()'

nfq.cpp:(.text+0x1582): undefined reference to `nfq_unbind_pf(nfq_handle*, unsigned short)'

nfq.cpp:(.text+0x15b7): undefined reference to `nfq_bind_pf(nfq_handle*, unsigned short)'

nfq.cpp:(.text+0x1616): undefined reference to `nfq_create_queue(nfq_handle*, unsigned short, int (*)(nfq_q_handle*, nfgenmsg*, nfq_data*, void*), void*)'

nfq.cpp:(.text+0x165b): undefined reference to `nfq_set_mode(nfq_q_handle*, unsigned char, unsigned int)'

nfq.cpp:(.text+0x1688): undefined reference to `nfq_nfnlh(nfq_handle*)'

nfq.cpp:(.text+0x16c6): undefined reference to `nfq_handle_packet(nfq_handle*, char*, int)'

nfq.cpp:(.text+0x173b): undefined reference to `nfq_destroy_queue(nfq_q_handle*)'

nfq.cpp:(.text+0x1749): undefined reference to `nfq_close(nfq_handle*)'

CMakeFiles/nfq_filter.dir/nfq.cpp.o: In function `nfqueue_cb(nfq_q_handle*, nfgenmsg*, nfq_data*, void*)':

nfq.cpp:(.text+0x1868): undefined reference to `nfq_get_msg_packet_hdr(nfq_data*)'

nfq.cpp:(.text+0x18e6): undefined reference to `nfq_get_payload(nfq_data*, char**)'

nfq.cpp:(.text+0x1904): undefined reference to `nfq_get_payload(nfq_data*, char**)'

nfq.cpp:(.text+0x19bd): undefined reference to `nfq_set_verdict(nfq_q_handle*, unsigned int, unsigned int, unsigned int, unsigned char*)'

nfq.cpp:(.text+0x1da1): undefined reference to `nfq_set_verdict(nfq_q_handle*, unsigned int, unsigned int, unsigned int, unsigned char*)'

nfq.cpp:(.text+0x20e0): undefined reference to `nfq_set_verdict(nfq_q_handle*, unsigned int, unsigned int, unsigned int, unsigned char*)'

nfq.cpp:(.text+0x239e): undefined reference to `nfq_set_verdict(nfq_q_handle*, unsigned int, unsigned int, unsigned int, unsigned char*)'

nfq.cpp:(.text+0x2620): undefined reference to `nfq_set_verdict(nfq_q_handle*, unsigned int, unsigned int, unsigned int, unsigned char*)'

collect2: ld returned 1 exit status

make[2]: *** [nfq_filter] Ошибка 1

make[1]: *** [CMakeFiles/nfq_filter.dir/all] Ошибка 2

make: *** [all] Ошибка 2

[metalsoft@metalsoft build]$

[Wingman]

пакет libnetfilter_queue в системе присутствует?

[metalsoft]

Да:

[metalsoft@metalsoft ~]$ rpm -qa| grep libnetfilter_queue
libnetfilter_queue-devel-0.0.15-alt1.1
libnetfilter_queue-0.0.15-alt1.1
[metalsoft@metalsoft ~]$

[metalsoft]

Мда... Провел dist-upgrade, все собралось :) Спасибо за участие! Будем пробовать.

[Evolution23]

пакет libnetfilter_queue в системе присутствует?

Объясните дураку, пожалуйста.

Система debian 7. Собрал nfq_filter по инструкции.

Он даже запускается, но такое ощущение, что не читает файл cfg, который я ему подсовываю.

 

nfq_filter -c /etc/nfq/nfq_filter.cfg
12.06.2014 03:39:09:
--------------------------
Starting program.

Queue:          0
Log file:       /tmp/nfq_filter.log
Debug:          1

URLs and Domains files reading done.
Thread: sniffing packet...started.
Thread: write log file...started
Thread: read config files...started
NFQ: Binding to queue '0'

При том, что в файле /etc/nfq/nfq_filter.cfg лежит следующее

queue = 1
logfile = /tmp/nfq_filter.log
pidfile = /tmp/nfq_filter.pid

# 1: print out filtered packets info (from, to)
# 2: print out full filtered packets: from/to and content
# 3: print out all packets info (from, to)
# 4: print out full info of all captured packets: from/to + content
debug = 4


# Single ip-address requests debugging
#debug_from_ip = 10.10.10.10
#debug_ip_file = /tmp/nfq_ip.log

domainlist = /etc/nfq/domains
urllist = /etc/nfq/urls

redirect_url = http://ya.ru

Таким образом, даже если файл конфигурации подхватывается, то данные из него, судя по всему, не используются (как минимум, значение queue=1 и debug=4 точно нет).

 

Отсюда вопрос, что я делаю не так?

[Wingman]

Evolution23, если честно, хз :)

Собрал из гита на debian 7, всё подхватывается:

 

# ./nfq_filter -c /etc/nfq/nfq_filter.cfg
12.06.2014 19:49:15:
--------------------------
Starting program.

Queue:          1
Log file:       /tmp/nfq_filter.log
Debug:          4

URLs and Domains files reading done.
Thread: sniffing packet...started.
Thread: write log file...started
Thread: read config files...started
NFQ: Binding to queue '1'

Как вариант, можете на некоторое время дать мне доступ к серверу, я посмотрю; а так - особо предположений нет

 

---

 

Всем, кто использует: замечена проблема - через несколько часов работы в софтину как будто перестаёт поступать трафик из iptables. Работает, пишет логи, но входящих пакетов - нет.

Уже голову сломал, дебажил и так и сяк - причины не нашёл.

 

Ни у кого такого не наблюдается при длительной работе софтины? Если нет - возможно, это какой-то баг libnetfilter_queue на моей генте.

 

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

[metalsoft]

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

[metalsoft]

Наблюдаю непонятки...

Чтоб на основном шлюзе ничего не трогать, подключил к нему сбоку отдельной сетевухой отдельный серв, на котором запускаю nfq_filter. Зеркалирую трафик со шлюза на nfq-серв таким образом:

iptables -t mangle -A PREROUTING -s x.x.x.x/32 -i eth0 -p tcp --dport 80 -j TEE --gateway 192.168.0.2

Все выглядит нормальным, пакеты на nfq ходят, запрещенные страницы блокируются. В течение нескольких дней все отлично. Но стоит только вместо одного ip сделать зеркалирование _всего_ трафика:

iptables -t mangle -A PREROUTING -s a.a.a.0/22 -i eth0 -p tcp --dport 80 -j TEE --gateway 192.168.0.2
iptables -t mangle -A PREROUTING -s a.a.a.0/22 -i eth2 -p tcp --dport 80 -j TEE --gateway 192.168.0.2
iptables -t mangle -A PREROUTING -s a.a.a.0/22 -i eth5 -p tcp --dport 80 -j TEE --gateway 192.168.0.2

iptables -t mangle -A PREROUTING -s b.b.b.0/22 -i eth0 -p tcp --dport 80 -j TEE --gateway 192.168.0.2
iptables -t mangle -A PREROUTING -s b.b.b.0/22 -i eth2 -p tcp --dport 80 -j TEE --gateway 192.168.0.2
iptables -t mangle -A PREROUTING -s b.b.b.0/22 -i eth5 -p tcp --dport 80 -j TEE --gateway 192.168.0.2

iptables -t mangle -A PREROUTING -s c.c.c.0/21 -i eth0 -p tcp --dport 80 -j TEE --gateway 192.168.0.2
iptables -t mangle -A PREROUTING -s c.c.c.0/21 -i eth2 -p tcp --dport 80 -j TEE --gateway 192.168.0.2
iptables -t mangle -A PREROUTING -s c.c.c.0/21 -i eth5 -p tcp --dport 80 -j TEE --gateway 192.168.0.2

iptables -t mangle -A PREROUTING -s d.d.d.0/22 -i eth0 -p tcp --dport 80 -j TEE --gateway 192.168.0.2
iptables -t mangle -A PREROUTING -s d.d.d.0/22 -i eth2 -p tcp --dport 80 -j TEE --gateway 192.168.0.2
iptables -t mangle -A PREROUTING -s d.d.d.0/22 -i eth5 -p tcp --dport 80 -j TEE --gateway 192.168.0.2

через несколько минут получаю на сервере с nfq глухой зависон. Только reset. После загрузки - в логах все чисто, нигде никакого намека, что была проблема. Трафик получается небольшой, порядка 20-30 МБит. Если зеркалировать не все сети (уменьшить трафик), работает дольше.

Ломаю голову, как диагностировать проблему...

Изменено 20 июня, 2014 пользователем metalsoft

[Wingman]

А если нагрузку увеличивать постепенно, добавляя по одной сетке? Софтина начинает постепенно отжирать процессор, или всё так же резко с какого-то момента виснет?

А если запустить, например, 4 копии софтины, повесив их на разные очереди, и трафик с разных сетей направить (-j NFQUEUE --queue-num X) на разные инстансы софтины?

[metalsoft]

Резко висло.Вобщем, проблема решилась обновлением ядра. Видать, проблема была в nfq.

[metalsoft]

Ни у кого такого не наблюдается при длительной работе софтины?

Да, проблема наблюдается.

Запускаю в nfq один конкретный ip:

/sbin/iptables -t mangle -A PREROUTING -s a.b.c.d/32 -p tcp -m tcp --dport 80 -j NFQUEUE --queue-num 0 --queue-bypass

Фильтр нормально работает минут 10. После чего фильтровать перестает, как будто до него пакеты не доходят (или до него доходят, но он их не обрабатывает, или еще что).

Запускаю в nfq одну подсеть /22 - работает буквально пару минут, потом опять такая же картина. Несколько раз пробовал - явно налицо зависимость от потока пакетов.

Запускаю опять подсеть /22, включаю дебаг по ip - тоже через пару минут фильтровать перестает, вывод в ip_log прекращается, хотя в nfq_filter.log вывод идет как ни в чем не бывало.

 

Хорошая идея, хороший фильтр, вот только до ума бы довести...

[pavel.odintsov]

А чисто open source решений задачи ниужели до сих пор не существует? Ведь это поидее довольно простенький L7 proxy.

 

Я себе вижу схему так:

1) Если нужно какой-то узел фильтровать по URL и на одном IP куча хостов, то весь IP заворачивается на отдельный хост, где и фильтруется

2) Сама фильтрация поидее красиво должна обработать через аппаратные правила 82599 - просто забрасываем часть трафика в юзерспейс и если он некошерный, отбрасываем его.

 

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

[Ivan_83]

Опенсорса нет - потому что:

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

2. Это сложно и на коленке за вечер не сделаешь.

 

Проблема далеко не в железе сетевух. И аппаратные фильтры тут далеко не то на что нужно смотреть.

Проблема тут в том, что нужно прозрачно вклиниваться в HTTP, это означает что нужно IP + TCP + HTTP разбирать.

Всё потому что нужно получить полный GET запрос из, вероятно, кучи ip/tcp ошмётков, выделить от туда host и url и прогнать их по большой базе.

В случае если этот урл + хост в базе есть то нужно отдать юзеру редирект, те перехватить ip+tcp и сэмулировать дальше самому, не забыв оборвать/отбросив ответ от оригинального дст хоста.

 

Помимо фрагментации и перепосылок в ip и tcp ещё есть keep-alive в http, те GET ++ нужно искать постоянно во всём передаваемом потоке.

 

Это если всё по правильному делать.

Причём тут какие то аппаратные фильтры в каких то там сетевухах - не очень понятно.

[pavel.odintsov]

Этическая сторона, безусловно, есть. Но так или иначе блокируется в основном откровенный треш. Да, он в 100% случаев абсолютно безвреден и не требует вмешательства с точки зрения здравого смысла. Но конторы-паразиты будут на этом рынке итак. А открытое решение по крайне мере лишит их возможности паразитировать на гхм этой падальщине.

 

А фильтры сетевой при том, что ими можно извлечь поток конкретного клиента и завернуть его в user space. А там уже силами того же PF_RING провести дефаргаментацию и подменить чужие пакеты на свои. Безусловно, с вклиниванием в tcp сессию будет сложно, но вполне реализуемо.

[Ivan_83]

Этическая сторона, безусловно, есть. Но так или иначе блокируется в основном откровенный треш. Да, он в 100% случаев абсолютно безвреден и не требует вмешательства с точки зрения здравого смысла. Но конторы-паразиты будут на этом рынке итак. А открытое решение по крайне мере лишит их возможности паразитировать на гхм этой падальщине.

Каждый должен лично решать что ему смотреть/читать а что нет. Автоматом можно только спам и эксплоиты резать.

Кроме СКАТ никого и нет кто себя позиционирует именно по этой теме.

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

 

А фильтры сетевой при том, что ими можно извлечь поток конкретного клиента и завернуть его в user space. А там уже силами того же PF_RING провести дефаргаментацию и подменить чужие пакеты на свои. Безусловно, с вклиниванием в tcp сессию будет сложно, но вполне реализуемо.

Трафик и так пойдёт через ядро ОС, она ведь его роутит.

[pavel.odintsov]

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

[Diamont]

У нас провайдер по ходу выстроил приоритет. Всякие торрент сайты блочит по днс: помогает указать 8.8.8.8 в качестве альтернативного днс.

А вот таким сайтам, как кавказцентр это не помогает. Там наверняка блок по ip.

[rvr.online]

Evolution23, если честно, хз :)

 

У меня не читались queue и debug, пока в config.cpp после строк "param = _val;" не поставил "return true;".

[Wingman]

rvr.online, угу, спасибо, был такой баг

[ichthyandr]

вопрос в тему - у кого какой DPI

[roysbike]

sce8000. Но заглядываюсь на СКАТ