overty

Отбой, сам виноват, нулится резервным роутером, по префиксам короче /32. НЕ попадает трафик во внешний канал, соответственно до ExtFilter SYN пакеты не доходят. А /32 и все префиксы отправляю по BGP на основной бородер. ExtFilter стоит между ними.

dpdk-stable-17.05.2

Не блокируется, еще раз проверил. Если убрать null route на бордере, то RST мне присылает вышестоящий оператор. curl -v 34.248.222.69 * About to connect() to 34.248.222.69 port 80 (#0) * Trying 34.248.222.69... 10:23:46.958190 IP 91.109.200.254.35124 > 34.248.222.69.80: Flags , seq 3512681898, win 29200, options [mss 1460,sackOK,TS val 435778989 ecr 0,nop,wscale 7], length 0 10:23:47.960700 IP 91.109.200.254.35124 > 34.248.222.69.80: Flags , seq 3512681898, win 29200, options [mss 1460,sackOK,TS val 435779992 ecr 0,nop,wscale 7], length 0 10:23:49.966837 IP 91.109.200.254.35124 > 34.248.222.69.80: Flags , seq 3512681898, win 29200, options [mss 1460,sackOK,TS val 435781998 ecr 0,nop,wscale 7], length 0 Работаю два ExtFilter на двух разных физических машинах в режиме зеркала и не один не присылает RST, если префикс короче /32 Ошибок в логах нет.

34.248.222.68 Не блокируется. Запись вида - 34.248.222.68/31, 6/0xfe Проверил другие /31 и /29, тоже нет RST. /32 - RST приходит Настройки: # Выгружать ip для полной блокировки в режиме моста ips_to_hosts = true # Выгружать сети для полной блокировки в режиме моста nets_to_hosts = true

Если что то, в centos 7.5 DPDK не собирается. http://dpdk.org/dev/patchwork/patch/35566/

А только у меня всю неделю - "Мониторинг в указанную дату не проводился"? Хочу понять сам сломал или со стороны ревизора проблема. Сам агент в ЛК показывается как "Активен. В сети".

У меня nfqfilter в режиме зеркала работает с марта. Никаких проблем с этим нет. Снимаю исходящий трафик с 10Г SPAN порта коммутатора CISCO. Сетевка в мосте с вызовом iptables для попадания в nfqueue. Нагрузка порта 3Гбит/сек.

Временно добавил строки $url11 =~ s/\/$//; $url2 =~ s/\/$//; в nfqfilter_config для удаление последнего слеша "/". URL с окончанием /. у меня заблокировались.

У вас блочится потому что браузер, скорее всего убирает точку в конце URL. Проблема только с URL оканчивающими на '/.' Например через curl (curl -v expirience.ru/kak-sdelat-kastet/.) пролетает свободно при match_url_exactly = false, хотя должно блокировать. GET /kak-sdelat-kastet/. HTTP/1.1 > User-Agent: curl/7.29.0 > Host: expirience.ru > Accept: */* > < HTTP/1.1 200 OK < Server: nginx/1.2.1 < Date: Wed, 24 Aug 2016 12:38:40 GMT < Content-Type: text/html;charset=UTF-8 ... ... Пролетает так же curl -v expirience.ru/kak-sdelat-kastet > GET /kak-sdelat-kastet HTTP/1.1 > User-Agent: curl/7.29.0 > Host: expirience.ru > Accept: */* > < HTTP/1.1 200 OK < Server: nginx/1.2.1 < Date: Wed, 24 Aug 2016 12:43:58 GMT < Content-Type: text/html;charset=UTF-8 ... ... А вот curl -v expirience.ru/kak-sdelat-kastet/ - блокируется, но параметр url_additional_info=url как-то не правильно работает в последней версии. > GET /kak-sdelat-kastet/ HTTP/1.1 > User-Agent: curl/7.29.0 > Host: expirience.ru > Accept: */* > < HTTP/1.1 302 Moved Temporarily < Location: hXXp://www.example.com/block.html?url=http://expirience.ru/kak-sdelat-kastet/http://expirience.ru/kak-sdelat-kastet/ < Connection: close url повторяется два раза. С доменами такой проблемы не наблюдаю.

Так же исправлено в конфигураторе. Не помогает, так же ссылки пролетают и не перенаправляются на страницу блокировки. Например: kazino-klub-vulcan.com/azartnye-igry/. mixslots.com/. curl -v expirience.ru/kak-sdelat-kastet/. тоже пролетает. Мне кажется что неправильно интерпретируется точка в конце url. Если добавить несколько точек, то видно что url в nfqfilter искажается. curl -v kazino-klub-vulcan.com/azartnye-igry/.... Редирект становится вида - Location: hXXp://www.example.com/block.html?url=http://kazino-klub-vulcan.com/azartnye-igry/....http://kazino-klub-vulcan.com/azartnye-igry/....

Подтверждаю, пролетают. У меня пролетает, например, домен "www.dawlah.ga.". И ссылки mixslots.com/. , kazino-klub-vulcan.com/azartnye-igry/. - все ссылки с окончанием "/."

Поддерживаю, на последнем коммите повышенное использование ЦПУ и иногда некоторые ссылки у меня "прорываются". Пришлось все-таки откатиться на 94c56b761655c13b8c77f7e5fe7d4ad533a503a5 из-за повышенного использования ЦПУ и "пролета" некоторых ссылок. Ответ HTTP прилетает быстрее чем генерируется редирект. Нагрузка упала с 30-50% ЦПУ до 5-10. Было: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 31154 root 20 0 538828 132640 2672 S 37,5 0,1 82:28.44 nfqfilter 31162 root 20 0 538828 126792 2668 S 33,0 0,1 56:34.71 nfqfilter 31158 root 20 0 538828 124588 2668 S 31,5 0,1 33:51.72 nfqfilter 31210 root 20 0 538828 126684 2672 S 28,0 0,1 48:27.23 nfqfilter 31236 root 20 0 538828 126736 2668 S 24,5 0,1 56:58.80 nfqfilter 31286 root 20 0 538828 126744 2668 S 24,0 0,1 57:57.07 nfqfilter Стало: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 29183 root 20 0 538572 126364 2428 S 6,3 0,1 0:09.55 nfqfilter 29353 root 20 0 538572 126544 2584 S 4,0 0,1 0:08.51 nfqfilter 29175 root 20 0 538572 124332 2432 S 3,6 0,1 0:06.97 nfqfilter 29167 root 20 0 538572 126324 2400 S 3,3 0,1 0:08.40 nfqfilter 29297 root 20 0 538572 128428 2428 S 3,3 0,1 0:07.22 nfqfilter 29277 root 20 0 538572 126304 2400 S 3,0 0,1 0:05.63 nfqfilter block_undetected_ssl = true в обоих случаях. max1976 планируется ли поддержка спуфинга DNS ответов при резолвинге запрещенных доменов?

Поддерживаю, на последнем коммите повышенное использование ЦПУ и иногда некоторые ссылки у меня "прорываются".

Пока вбил костыль sed -i '/\//! {s/.*/&\//}' ./urls Перед запуском nfqfilter ищу строки без "/" и добавляю слэш. Вроде запускается. А вот что у меня не так с protos не пойму? --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0} --- rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0 tgkill(9022, 9022, SIGABRT) = 0 --- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=9022, si_uid=0} --- +++ killed by SIGABRT +++ Аварийный останов

А по строке tcp:16869@SSL в файле protos ни у кого проблемы нет?

У Вас может в вопросах, у меня точно в слешах, проверял добавляя их. Начинает запускаться и падает по сигналу SIGABRT из-за строки tcp:16869@SSL в файле protos.

Тоже "рухнул" сегодня Fatal Application - Bad url format in line 26662 in file /urls betcity.??? betcity.中文网 Здесь мне кажется просто не хватает слешей на конце. Падает еще из-за строки tcp:16869@SSL в файле protos --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0} --- rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0 tgkill(23627, 23627, SIGABRT) = 0 --- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=23627, si_uid=0} --- +++ killed by SIGABRT +++ Аварийный останов

Используется больше одной nf очереди? Да, собирался использовать несколько очередей. Перед перезапуском основной инстанции nfqfilter запускается другая, с другим номером очереди, трафик временно передаю в другую очередь, пока не перезагрузится основная.

У меня на последней версии nfqfilter система полностью зависает если указываю количество потоков больше одного. Ядро 3.10.0-327.10.1.el7.x86_64 Кто-нибудь ловит такой же глюк?

+1 url есть в выгрузке, не блокируется konan-vesti.blogspot.ru находится на IP 173.194.219.132 Если посмотреть в исходники ndpi src/lib/ndpi_content_match.c.inc, то видно это /* Google 173.194.0.0/16 64.233.160.0/19 */ { 0xADC20000 /* 173.194.0.0 */, 16, NDPI_SERVICE_GOOGLE }, { 0x40E91600 /* 64.233.160.0 */, 19, NDPI_SERVICE_GOOGLE }, Соответсвенно NDPI определяет этот ресурс как NDPI_SERVICE_GOOGLE. Я у себя полностью вычистил файл src/lib/ndpi_content_match.c.inc стало меньше проблем с блокировкой. Если нужно то вот мое содержимое этого файла /* * ndpi_content_match.c * * Copyright (C) 2011-15 - ntop.org * * nDPI is free software: you can redistribute it and/or modify * it under the terms of the GNU Lesser General Public License as published by * the Free Software Foundation, either version 3 of the License, or * (at your option) any later version. * * nDPI is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU Lesser General Public License for more details. * * You should have received a copy of the GNU Lesser General Public License * along with nDPI. If not, see <http://www.gnu.org/licenses/>. * */ typedef struct { char *string_to_match, *proto_name; int protocol_id; ndpi_protocol_breed_t protocol_breed; } ndpi_protocol_match; typedef struct { u_int32_t network; u_int8_t cidr; u_int8_t value; } ndpi_network; /* ****************************************************** */ static ndpi_network host_protocol_list[] = { { 0x0, 0, 0 } }; /* ****************************************************** */ /* Host-based match HTTP: Server: field HTTPS: Server certificate name */ ndpi_protocol_match host_match[] = { { NULL, 0 } }; /* Mime-type content match match */ ndpi_protocol_match content_match[] = { { NULL, 0 } }; /* ****************************************************** */ static const char *ndpi_en_bigrams[] = { "aa", "ba", "ca", "da", "ea", "fa", "ga", "ha", "ia", "ja", "ka", "la", "ma", "na", "oa", "pa", "qa", "ra", "sa", "ta", "ua", "va", "wa", "xa", "ya", "za", "ab", "bb", "db", "eb", "fb", "gb", "hb", "ib", "kb", "lb", "mb", "nb", "ob", "pb", "rb", "sb", "tb", "ub", "wb", "yb", "ac", "bc", "cc", "dc", "ec", "fc", "gc", "hc", "ic", "kc", "lc", "mc", "nc", "oc", "pc", "rc", "sc", "tc", "uc", "wc", "xc", "yc", "ad", "bd", "cd", "dd", "ed", "fd", "gd", "hd", "id", "kd", "ld", "md", "nd", "od", "pd", "rd", "sd", "td", "ud", "wd", "xd", "yd", "zd", "ae", "be", "ce", "de", "ee", "fe", "ge", "he", "ie", "je", "ke", "le", "me", "ne", "oe", "pe", "re", "se", "te", "ue", "ve", "we", "xe", "ye", "ze", "af", "bf", "df", "ef", "ff", "gf", "hf", "if", "kf", "lf", "mf", "nf", "of", "pf", "rf", "sf", "tf", "uf", "wf", "xf", "yf", "zf", "ag", "bg", "dg", "eg", "fg", "gg", "hg", "ig", "kg", "lg", "ng", "og", "pg", "rg", "sg", "tg", "ug", "wg", "yg", "ah", "bh", "ch", "dh", "eh", "fh", "gh", "hh", "ih", "kh", "lh", "mh", "nh", "oh", "ph", "rh", "sh", "th", "uh", "wh", "xh", "yh", "ai", "bi", "ci", "di", "ei", "fi", "gi", "hi", "ii", "ji", "ki", "li", "mi", "ni", "oi", "pi", "qi", "ri", "si", "ti", "ui", "vi", "wi", "xi", "yi", "zi", "aj", "bj", "dj", "ej", "fj", "gj", "hj", "ij", "jj", "kj", "lj", "nj", "oj", "pj", "rj", "sj", "tj", "uj", "wj", "yj", "ak", "ck", "dk", "ek", "gk", "ik", "kk", "lk", "mk", "nk", "ok", "pk", "rk", "sk", "tk", "uk", "wk", "yk", "zk", "al", "bl", "cl", "dl", "el", "fl", "gl", "hl", "il", "kl", "ll", "ml", "nl", "ol", "pl", "rl", "sl", "tl", "ul", "vl", "wl", "xl", "yl", "zl", "am", "bm", "cm", "dm", "em", "fm", "gm", "hm", "im", "km", "lm", "mm", "nm", "om", "pm", "rm", "sm", "tm", "um", "wm", "xm", "ym", "zm", "an", "bn", "cn", "dn", "en", "fn", "gn", "hn", "in", "kn", "ln", "mn", "nn", "on", "pn", "rn", "sn", "tn", "un", "wn", "xn", "yn", "ao", "bo", "co", "do", "eo", "fo", "go", "ho", "io", "jo", "ko", "lo", "mo", "no", "oo", "po", "ro", "so", "to", "uo", "vo", "wo", "xo", "yo", "zo", "ap", "bp", "dp", "ep", "fp", "gp", "hp", "ip", "kp", "lp", "mp", "np", "op", "pp", "rp", "sp", "tp", "up", "wp", "xp", "yp", "zp", "aq", "cq", "dq", "eq", "hq", "iq", "nq", "oq", "qq", "rq", "sq", "uq", "xq", "ar", "br", "cr", "dr", "er", "fr", "gr", "hr", "ir", "kr", "lr", "mr", "nr", "or", "pr", "rr", "sr", "tr", "ur", "vr", "wr", "xr", "yr", "as", "bs", "cs", "ds", "es", "fs", "gs", "hs", "is", "ks", "ls", "ms", "ns", "os", "ps", "rs", "ss", "ts", "us", "vs", "ws", "xs", "ys", "at", "bt", "ct", "dt", "et", "ft", "gt", "ht", "it", "kt", "lt", "mt", "nt", "ot", "pt", "rt", "st", "tt", "ut", "wt", "xt", "yt", "zt", "au", "bu", "cu", "du", "eu", "fu", "gu", "hu", "iu", "ju", "ku", "lu", "mu", "nu", "ou", "pu", "qu", "ru", "su", "tu", "uu", "vu", "wu", "xu", "yu", "zu", "av", "bv", "dv", "ev", "iv", "lv", "mv", "nv", "ov", "rv", "sv", "tv", "uv", "vv", "zv", "aw", "bw", "dw", "ew", "fw", "gw", "hw", "iw", "kw", "lw", "mw", "nw", "ow", "pw", "rw", "sw", "tw", "uw", "ww", "xw", "yw", "zw", "ax", "ex", "ix", "nx", "ox", "rx", "ux", "xx", "yx", "ay", "by", "cy", "dy", "ey", "fy", "gy", "hy", "ky", "ly", "my", "ny", "oy", "py", "ry", "sy", "ty", "uy", "vy", "wy", "xy", "yy", "zy", "az", "bz", "cz", "dz", "ez", "gz", "iz", "lz", "nz", "oz", "pz", "rz", "tz", "uz", "zz", NULL }; static const char *ndpi_en_impossible_bigrams[] = { "bk", "bq", "bx", "cb", "cf", "cg", "cj", "cp", "cv", "cw", "cx", "dx", "fk", "fq", "fv", "fx", "ee", "fz", "gq", "gv", "gx", "hh", "hk", "hv", "hx", "hz", "iy", "jb", "jc", "jd", "jf", "jg", "jh", "jk", "jl", "jm", "jn", "jp", "jq", "jr", "js", "jt", "jv", "jw", "jx", "jy", "jz", "kg", "kq", "kv", "kx", "kz", "lq", "lx", "mg", "mj", "mq", "mx", "mz", "pq", "pv", "px", "qb", "qc", "qd", "qe", "qf", "ii", "qg", "qh", "qj", "qk", "ql", "qm", "qn", "qo", "qp", "qr", "qs", "qt", "qv", "qw", "qx", "qy", "uu", "qz", "sx", "sz", "tq", "tx", "vb", "vc", "vd", "vf", "vg", "vh", "vj", "vk", "vm", "vn", "vp", "bw", "vq", "vt", "vw", "vx", "vz", "wq", "wv", "wx", "wz", "xb", "xg", "xj", "xk", "xv", "xz", "xw", "yd", "yp", "yj", "yq", "yv", "yz", "yw", "zb", "zc", "zg", "zh", "zj", "zn", "zq", "zr", "zs", "zx", "wh", "wk", "wb", "zk", "kp", "zk", "xy", NULL };

Конечно не блокируется, т.к. символы в нижнем регистре, а в url попадают в верхнем. Мне кажется что это не правильно. Даже подставив в URL один тот же самый символ в другом регистре, то ссылка разблокируется. Есть серверы регистронезависимые. Что касается URL кода или не ASCII символов, то их тоже желательно приводит к нижнему регистру при проверке в nfqfilter. А жесткое сравнение в нижнем регистре по URL кодам невозможно организовать в дополнение к существующему сравнению? К примеру, сначала переводить url из запроса браузера в нижний регистр, потому делать URL-Encode и сравнивать по URL-кодам из файла urls. ASCII будет в нижнем регистре и не переведется, а остальное станет URL кодом. В файле urls так же записать не-ASCII символы в нижнем регистре в URL-код в трех известных нам кодировках (UTF-8, Windows-1251 и KOI8-R). Или так не получиться и я не прав?

У кого-нибудь https://1xbet.在线/ блокируется? В ssl_host он указан как 1xbet.xn--3ds443g. Еще http://intpharm.ru/%d1%82%d1%80%d0%b0%d0%bc%d0%b0%d0%b4%d0%be%d0%bb/ не блокируется, хотя также присутсвует в urls. И Проблема с http://mp3vega.com/?string=%D1%D3%CA%C0+%D7%D3%D0%CA%C8+%C5%C1%C0%CD%DB%C9… Тут запись в реестре имеет вид http://mp3vega.com/?string=%D1%D3%CA%C0+%D7%D3%D0%CA%C8+%C5%C1%C0%CD%DB%C9<85> (Символ … в конце) А в urls mp3vega.com/?string=%D1%D3%CA%C0+%D7%D3%D0%CA%C8+%C5%C1%C0%CD%DB%C9%E2%80%A6 Судя по программе проверки <85> имеется ввиду символ "троеточие", но блокирует не во всех браузерах. У себя отбросил полностью в скрипте make_files.pl "%E2%80%A6" - URL заблокировалась.

max1976 спасибо. Банит теперь. curl -v https://www.noxwin.com * About to connect() to www.noxwin.com port 443 (#0) * Trying 109.205.94.28... * Connected to www.noxwin.com (109.205.94.28) port 443 (#0) * Initializing NSS with certpath: sql:/etc/pki/nssdb * CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none * NSS error -5961 (PR_CONNECT_RESET_ERROR) * TCP connection reset by peer * Closing connection 0 curl: (35) TCP connection reset by peer

nDPI детектит пакеты к данному хосту как Tor. т.е. не исправить?

А что говорит host kasparov.ru Вот: system@ne-vlezay80:~$ host kasparov.ru kasparov.ru has address 216.92.111.41 kasparov.ru mail is handled by 50 mail1.g1.pair.com. как он это делает? странно Хотя, если блокировщик на perl: можно сваливать весь трафик через libpcap в файл, там его склеивать и анализировать. А потом отправлять RST. Единственный минус: может навернуться жёсткий диск или SSD. Кстати, так может COPM получиться Не вариант, быстрее ответ от веб сервера придет с такой логикой чем RSP пакет. И libpcap теряет пакеты, perl возможно ляжет, это все таки не C++. nfqfilter только дорабатывать, если получиться сложить payload нескольких пакетов и далее обработать, но тут слово за max1976. Судя по коду это еще должен и ndpi поддерживать. И очень хотелось бы видеть поддержку DNS спуфинга тоже. На счёт сложения payload: тут по любому придётся в файл писать, а потом уже этот файл анализировать. На счёт ответа от сервера: в nfqueue пожно "придержать" пакет пока он небудет проинспектирован. Размещять этот файл лучше в /dev/ram0 Я max1976 спрашивал. Вот что он мне в ЛС прислал: Интересно, какая будет производительность вашей сети, если пакеты будут придерживать. К вашем сведению nfqueue работает per-flow, а не per-packet. Даже при queue-balance одно подключение попадает в одну и туже очередь. Задержали вы первый пакет, как второй смотреть будете, без вердикта первого? Запись в файл с использованием pcap для меня вообще не вариант.