Перейти к содержимому
Калькуляторы
Блокировка веб ресурса  

518 пользователей проголосовало

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



Блокировка сайтов провайдерами маневры с DNS

Кому нужен был рабочий рецепт с ipset:

 

Есть ли в открытом виде вариант с использованием ipsеt вместо bgpd?

 

Вот мой вариант работы через ipset:

На бордере есть четыре списка ipset - dropnets, dropnetsrunning, tofilternets, tofilternetsrunning

 

Для блокирования запрещенных ip работает такое правило:

iptables -A FORWARD -m set --match-set dropnetsrunning dst -j DROP

 

Для перенаправления трафика на сторонний сервер с nfqfilter используется Policy-Routing:

iptables -t mangle -A PREROUTING ! -s 1.2.3.4/32 -m set --match-set tofilternetsrunning dst -j MARK --set-mark 3
ip route add default via 10.10.10.10 table 3
ip rule add fwmark 3 table 3

 

На сервере с nfqfilter трафик nat-ится, 1.2.3.4 - это внешний интерфейс, 10.10.10.10 - внутренний интерфейс.

 

Для обновления списков ipset взял за основу скрипт от max1976, выбросил лишнее, и вот что получилось:

 

#!/usr/bin/perl

use strict;
use warnings;
use utf8;
use Config::Simple;
use DBI;
use File::Basename;
use Log::Log4perl;
use Net::IP qw(:PROC);
use Net::CIDR::Lite;

binmode(STDOUT,':utf8');
binmode(STDERR,':utf8');

my $dir = File::Basename::dirname($0);

my $Config = {};
Config::Simple->import_from($dir.'/zapret-ipset.conf', $Config) or die "Can't open ".$dir."/zapret-ipset.conf for reading!\n";
Log::Log4perl::init( $dir.'/zapret-ipset-log.conf' );

my $logger=Log::Log4perl->get_logger();

my $db_host = $Config->{'DB.host'} || die "DB.host not defined.";
my $db_user = $Config->{'DB.user'} || die "DB.user not defined.";
my $db_pass = $Config->{'DB.password'} || die "DB.password not defined.";
my $db_name = $Config->{'DB.name'} || die "DB.name not defined.";

###my @resolvers = $Config->{'NS.resolvers'} || ();

my $dbh = DBI->connect("DBI:mysql:database=".$db_name.";host=".$db_host,$db_user,$db_pass,{mysql_enable_utf8 => 1}) or die DBI->errstr;
$dbh->do("set names utf8");

my $only_ip=0;
my $total_entry=0;
my %ip_s;
my %ip6_s;
my %ip_s_null;
my %ip6_s_null;
my %already_out;

my $ip_cidr=new Net::CIDR::Lite;
my $ip_cidr_null=new Net::CIDR::Lite;
my $ip6_cidr=new Net::CIDR::Lite;
my $ip6_cidr_null=new Net::CIDR::Lite;

my @ip_list;
my @ip6_list;
my @ip_list_null;
my @ip6_list_null;

# Выборка IP из таблицы zap2_ips
my $sth = $dbh->prepare("SELECT ip FROM zap2_ips UNION SELECT ip FROM zap2_only_ips");
$sth->execute;
while (my $ips = $sth->fetchrow_hashref())
{
my $ip=get_ip($ips->{ip});
next if($ip eq "0.0.0.0" || $ip eq "0000:0000:0000:0000:0000:0000:0000:0000");
my $ip_version=ip_get_version($ip);
if($ip_version == 4)
{
	$ip_cidr->add_any($ip);
} elsif ($ip_version == 6)
{
	$ip6_cidr->add_any($ip);
}
}
$sth->finish();
# Конец выборки IP из таблицы zap2_ips

# Выборка IP из таблицы zap2_only_ips
$sth = $dbh->prepare("SELECT ip FROM zap2_only_ips");
$sth->execute;
while (my $ips = $sth->fetchrow_hashref())
{
my $ip=get_ip($ips->{ip});
next if($ip eq "0.0.0.0" || $ip eq "0000:0000:0000:0000:0000:0000:0000:0000");
my $ip_version=ip_get_version($ip);
if($ip_version == 4)
{
	$ip_cidr_null->add_any($ip);
} elsif ($ip_version == 6)
{
	$ip6_cidr_null->add_any($ip);
}
}
$sth->finish();
# Конец выборки IP из таблицы zap2_only_ips

@ip_list=$ip_cidr->list();
%ip_s = map { $_ => 1 } @ip_list;
@ip6_list=$ip6_cidr->list();
%ip6_s = map { $_ => 1 } @ip6_list;
@ip_list_null=$ip_cidr_null->list();
%ip_s_null = map { $_ => 1 } @ip_list_null;
@ip6_list_null=$ip6_cidr_null->list();
%ip6_s_null = map { $_ => 1 } @ip6_list_null;

$logger->debug("ipset flush tofilternets");
system("ipset", "flush", "tofilternets");
foreach my $ip (@ip_list)
{
system("ipset", "add", "tofilternets", $ip);
}
$logger->debug("ipset swap tofilternets");
system("ipset", "swap", "tofilternets", "tofilternetsrunning");

$logger->debug("ipset flush dropnets");
system("ipset", "flush", "dropnets");
foreach my $ip (@ip_list_null)
{
system("ipset", "add", "dropnets", $ip);
}
$logger->debug("ipset swap dropnets");
system("ipset", "swap", "dropnets", "dropnetsrunning");

$dbh->disconnect();

sub get_ip
{
my $ip_address=shift;
my $d_size=length($ip_address);
my $result;
if($d_size == 4)
{
	$result=ip_bintoip(unpack("B*",$ip_address),4);
} else {
	$result=ip_bintoip(unpack("B*",$ip_address),6);
}
return $result;
}

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Нормализация выключена иначе пропускает и с запятыми и с апострофами и скобками.

 

Нормализация переводит uri в соответствии с rfc, что позволяет решить все проблемы, вами описанные. Мой скрипт так же сохраняет uri в нормализованном виде.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Кому нужен был рабочий рецепт с ipset:

....

Вот мой вариант работы через ipset:

На бордере есть четыре списка ipset - dropnets, dropnetsrunning, tofilternets, tofilternetsrunning

 

Для блокирования запрещенных ip работает такое правило:

iptables -A FORWARD -m set --match-set dropnetsrunning dst -j DROP

....

А разве не

iptables -A INPUT -m set --match-set dropnetsrunning dst -j DROP

?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Нормализация переводит uri в соответствии с rfc, что позволяет решить все проблемы, вами описанные. Мой скрипт так же сохраняет uri в нормализованном виде.

Максим, сейчас ситуация такая: С выключенной нормализацией с опцией remove_dot=false, и с патченным скриптом extfilter_maker.pl что бы двойные слэши заменялись на одинарные, только в конце. Я получаю по собственной программе тестирование 0 пропусков.

Тестирование ведется строкой вида

wget --timeout=3 --no-check-certificate -t 1 "$url" -P /root/ZAPRET/html -a /root/ZAPRET/wlog ;

Обо всех пропусках что я писал выше, проверял их так же через браузеры opera и chrome, они совпадали с wget.

Вот здесь выложил полный лог https://yadi.sk/d/hhP1hT-g3KyG88

get_url - скрипт проверки

wlog - лог wget

папка html - что скачалось по запросу, все что 938байт это заглушка, там правда есть один пропуск, но я посмотрел ссылки нет в фильтре, так что не считаем

url-abuse.txt.orig - ссылки по которым проводилась проверка

missed.sh - выбирает из wlog то что пролетело

 

Или же агент-ревизор сам предварительно обрабатывает ссылки, и уже на ревизоре я получу пропуски?

 

ПС Перечитал свой пост http://forum.nag.ru/forum/index.php?showtopic=79886&view=findpost&p=1419451 Я вообще не использую Максовский софт, в том числе и по предубеждениям. Сорри только сейчас прочитал какую чушь написал. Я прочитал как "Майкрософовский" :))), конечно все через софт Максима делаю.

Изменено пользователем big-town

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Или же агент-ревизор сам предварительно обрабатывает ссылки, и уже на ревизоре я получу пропуски?

Кроме ревизора, может быть и обычная проверка. Вобьют адрес в браузер, страница откроется.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Обо всех пропусках что я писал выше, проверял их так же через браузеры opera и chrome, они совпадали с wget.

 

Не могу подтвердить пропуски никакими браузерами/curl/wget. При отключенной нормализации пропуски возможны. Может у вас на фильтр не попадает ipv6 трафик?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Не могу подтвердить пропуски никакими браузерами/curl/wget. При отключенной нормализации пропуски возможны. Может у вас на фильтр не попадает ipv6 трафик?

Максим ipv6 отключен в кернеле, его не используем, так исторически сложилось.

К примеру ссылка вида ynet.co.il/articles/0,7340,L-4715257,00.html скачивалась при включенной нормализации, как только выставил в false, перестала скачиваться. Если с нормализацией обрезал в urls до ynet.co.il/articles/0 то благополучно фильтровалось.

 

Ну вот даже видео сделал:

https://youtu.be/U2oMKD08eI0

Изменено пользователем big-town

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Никак не пойму логику работы "Ревизора".

Заказал сегодня отчет, смотрю - пропуск:

http://mirror600.graniru.info/, 146.20.53.171

Время включения записи в реестр (UTC) 10 Май, 2016 06:44:09

(к слову говоря, указанный сайт - это не пропуск, показывается моя заглушка).

 

Поднимаю вчерашний отчет о пропусках - там такого сайта нет.

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

Логики не вижу никакой.

 

Как объяснить такое поведение системы контроля? Я не понимаю. :(

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

К примеру ссылка вида ynet.co.il/articles/0,7340,L-4715257,00.html скачивалась при включенной нормализации, как только выставил в false, перестала скачиваться. Если с нормализацией обрезал в urls до ynet.co.il/articles/0 то благополучно фильтровалось.

 

Чудес не бывает на одном и том же коде. Какая версия poco используется?

 

Никак не пойму логику работы "Ревизора".

Заказал сегодня отчет, смотрю - пропуск:

http://mirror600.graniru.info/, 146.20.53.171

Время включения записи в реестр (UTC) 10 Май, 2016 06:44:09

(к слову говоря, указанный сайт - это не пропуск, показывается моя заглушка).

 

Поднимаю вчерашний отчет о пропусках - там такого сайта нет.

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

Логики не вижу никакой.

 

Как объяснить такое поведение системы контроля? Я не понимаю. :(

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Чудес не бывает на одном и том же коде. Какая версия poco используется?

Полностью согласен, я тоже в чудеса не верю :). poco-1.7.8p3 скачивал вот по этой ссылке

Макс, напомню у меня ОС Linux extfilter 4.8.0-58-lowlatency #63~16.04.1-Ubuntu SMP PREEMPT Mon Jun 26 19:54:15 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux не CentOS

 

В принципе есть винт свободный, за выходные могу попробовать собрать все на CentOS-е и протестировать, самому интересно, почему такие расхождения.

Изменено пользователем big-town

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А никто работу с белыми списками не пилил?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

poco-1.7.8p3 скачивал

 

Попробуйте собрать с poco 1.6.1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

К примеру ссылка вида ynet.co.il/articles/0,7340,L-4715257,00.html скачивалась при включенной нормализации, как только выставил в false, перестала скачиваться. Если с нормализацией обрезал в urls до ynet.co.il/articles/0 то благополучно фильтровалось.

 

Чудес не бывает на одном и том же коде. Какая версия poco используется?

 

Никак не пойму логику работы "Ревизора".

Заказал сегодня отчет, смотрю - пропуск:

http://mirror600.graniru.info/, 146.20.53.171

Время включения записи в реестр (UTC) 10 Май, 2016 06:44:09

(к слову говоря, указанный сайт - это не пропуск, показывается моя заглушка).

 

Поднимаю вчерашний отчет о пропусках - там такого сайта нет.

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

Логики не вижу никакой.

 

Как объяснить такое поведение системы контроля? Я не понимаю. :(

 

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

У меня не к вам вопрос, система блокировки у меня не ваша, другая. Это просто вопрос по логике работы "Ревизора". А ее я что-то не улавливаю - см.выше.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Попробуйте собрать с poco 1.6.1

Сегодня попробую воспроизвести все на CentOS-е, если успею, с poco-1.7. Я вспомнил что недавно мы обгрейдили UTM5-ку, и обновили до ubuntu 14LTS. Так вот после этого в latin1 перестал работать регистронезависимый поиск. Походу все же внесли какие то изменения в функции работы со строками.

 

Максим еще вопрос как делается сравнение строк в url? Есть ли возможность использовать регулярки? В urls я посмотрел, ссылки с кириллицей дублируются точками.

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

 

Насколько смог разобрать

Poco::URI - как раз и отвечает за нормализацию, а при помощи AhoCorasickPlus идет сравнение?

 

ПС

Попробуйте

Максим, не надо меня на "вы".

Изменено пользователем big-town

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сегодня завел все на CentOS-е, с poco-1.7.8, результат абсолютно такой же как и на ubuntu-server. Так что OS тут не причем, вечером попробую скомпилить 1.6.1.

 

Немножко поковырял либу, если использовать нормализацию, то надо приводить URL к виду

 

http://ynet.co.il/articles/0%2C7340%2CL-4715257%2C00.html

а она попадает в urls в таком виде

ynet.co.il/articles/0,7340,L-4715257,00.html

.

Причем нормализация убирает только двойные слэши. Точки как написано в документации почему то нет.

 

Маленький эксперимент

 

 

#include <Poco/URI.h>
#include <iostream>
using namespace std;

int main(){
   string uri = "http://ynet.co.il.//articles//0,7340,L-4715257,00.html";
   Poco::URI uri1(uri);
   cout << uri1.toString() << endl;
   uri1.normalize();
   cout << uri1.toString() << endl;
   //uri1.~URI();
return 0;
}

http://ynet.co.il.//articles//0%2C7340%2CL-4715257%2C00.html
http://ynet.co.il./articles/0%2C7340%2CL-4715257%2C00.html

 

 

 

Кстати, Максим а ссылки в urls, разве не должны быть приведены к rfc? Почему туда попадают строки вида 0,7340,L-4715257,00.html? Может быть вообще проблемма не poco, а в скрипте?

 

Если в urls добавить ссылку вида

ynet.co.il/articles/0%2C7340%2CL-4715257%2C00.html

, то со включенной нормализацией она блокируется.

Изменено пользователем big-town

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сегодня завел все на CentOS-е, с poco-1.7.8, результат абсолютно такой же как и на ubuntu-server. Так что OS тут не причем, вечером попробую скомпилить 1.6.1.

 

Немножко поковырял либу, если использовать нормализацию, то надо приводить URL к виду

 

http://ynet.co.il/articles/0%2C7340%2CL-4715257%2C00.html

а она попадает в urls в таком виде

ynet.co.il/articles/0,7340,L-4715257,00.html

.

Причем нормализация убирает только двойные слэши. Точки как написано в документации почему то нет.

 

Маленький эксперимент

 

 

#include <Poco/URI.h>
#include <iostream>
using namespace std;

int main(){
   string uri = "http://ynet.co.il.//articles//0,7340,L-4715257,00.html";
   Poco::URI uri1(uri);
   cout << uri1.toString() << endl;
   uri1.normalize();
   cout << uri1.toString() << endl;
   //uri1.~URI();
return 0;
}

http://ynet.co.il.//articles//0%2C7340%2CL-4715257%2C00.html
http://ynet.co.il./articles/0%2C7340%2CL-4715257%2C00.html

 

 

 

Кстати, Максим а ссылки в urls, разве не должны быть приведены к rfc? Почему туда попадают строки вида 0,7340,L-4715257,00.html? Может быть вообще проблемма не poco, а в скрипте?

 

Если в urls добавить ссылку вида

ynet.co.il/articles/0%2C7340%2CL-4715257%2C00.html

, то со включенной нормализацией она блокируется.

У меня обе ссылки блокируются. Ничего не менял. CentOS7 3.10.0-514.16.1.el7.x86_64, poco-util 1.6.1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сегодня завел все на CentOS-е, с poco-1.7.8, результат абсолютно такой же как и на ubuntu-server. Так что OS тут не причем, вечером попробую скомпилить 1.6.1.

 

Немножко поковырял либу, если использовать нормализацию, то надо приводить URL к виду

 

http://ynet.co.il/articles/0%2C7340%2CL-4715257%2C00.html

а она попадает в urls в таком виде

ynet.co.il/articles/0,7340,L-4715257,00.html

.

Причем нормализация убирает только двойные слэши. Точки как написано в документации почему то нет.

 

Маленький эксперимент

 

 

#include <Poco/URI.h>
#include <iostream>
using namespace std;

int main(){
   string uri = "http://ynet.co.il.//articles//0,7340,L-4715257,00.html";
   Poco::URI uri1(uri);
   cout << uri1.toString() << endl;
   uri1.normalize();
   cout << uri1.toString() << endl;
   //uri1.~URI();
return 0;
}

http://ynet.co.il.//articles//0%2C7340%2CL-4715257%2C00.html
http://ynet.co.il./articles/0%2C7340%2CL-4715257%2C00.html

 

 

 

Кстати, Максим а ссылки в urls, разве не должны быть приведены к rfc? Почему туда попадают строки вида 0,7340,L-4715257,00.html? Может быть вообще проблемма не poco, а в скрипте?

 

Если в urls добавить ссылку вида

ynet.co.il/articles/0%2C7340%2CL-4715257%2C00.html

, то со включенной нормализацией она блокируется.

 

5 месяцев назад в poco было добавлено экранирование резервных символов и из-за этого наблюдается проблема. Текущая версия скрипта добавляет url в нужном виде под предыдущую версию poco::uri.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Максим, я правильно понимаю, что на последней версии (0.80) есть пропуски при проверке ревизором?

 

Я почему спрашиваю. У нас стояло несколько блокировщиков одновременно с extfilter. Отчеты были нулевые. Что не блокировал один, блокировал другой. На той неделе решили отказаться от всех других вариантов и оставить только один extfilter, хотя бы на тест.

Так вот за день набежало около 30 пропусков по отчетам ревизора. Причем проверяешь вручную - все блокирует. Ну и в отчетах в разное время разные адреса.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Макс пропустил urls через Poco/URI-нормализацию, предварительно удалил точки в конце домена и ссылки, так же удалил % в конце. На % библиотека генерит исключение.

Прогнал тест, пропуска нуль. На poco 1.7.8 Со включенной нормализацией. remove_dot=true

Код фильтра:

 

 

#include <Poco/URI.h>
#include "Poco/Exception.h"
#include <iostream>
#include <fstream>
using namespace std;


string remove_dot(string uri){
       string host="";
       string path="";

   if( ! uri.empty()){
       int last_char_uri=uri.length()-1;
       if( uri[last_char_uri]=='.' || uri[last_char_uri]=='%' ){
           uri.erase(last_char_uri,1);
       }
       Poco::URI uri1("http://"+uri);
       uri1.normalize();
       host=uri1.getAuthority();
       path=uri1.getPathAndQuery();

       int last_char_host=host.length()-1;
       if(!host.empty()  && host[last_char_host]=='.'){
           host.erase(last_char_host,1);
       }
   }

return host+path;
}

int main(){
   string line;
   int i=0;
   ifstream urls_in ("/usr/local/etc/extfilter/urls.orig");
   ofstream urls_out ("/usr/local/etc/extfilter/urls.normalize");
   if (urls_in.is_open()){
       while ( getline (urls_in,line) ){
           try
             {
                   urls_out << remove_dot(line) << endl;
                   i++;
               } catch( Poco::URISyntaxException& exc ) { cout << line << exc.displayText() << endl; }
       }
       urls_in.close();
       urls_out.close();
   } else cout << "Unable to open file";
   cout << "Count lines " << i << endl;
return 0;
}

 

 

Может все же оставить poco в покое и доработать сам скрипт? Или же при загрузке urls прогонять их через подобный фильтр.

Изменено пользователем big-town

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Уважаемые подскажите.

Что нам выбрать extfilter или Suricata.

 

Сейчас используем nfqfilter.

nfqfilter перестал устраивать потому что нет сборки фрагментов.

У нас своя система получения реестра, парсинга и подготовки конфига для nfqfilter.

Переписать её для генерации конфигов для Suricata проблем не составляет.

 

Преимущества Suricata видим в поддержке режимов установки в разрыв и работу как NFQUEUE так DPDK, наличие сборки пакетов.

 

Подскажите, почему мне следует выбрать решение на базе extfilter?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Уважаемые подскажите.

Что нам выбрать extfilter или Suricata.

 

Сейчас используем nfqfilter.

nfqfilter перестал устраивать потому что нет сборки фрагментов.

У нас своя система получения реестра, парсинга и подготовки конфига для nfqfilter.

Переписать её для генерации конфигов для Suricata проблем не составляет.

 

Преимущества Suricata видим в поддержке режимов установки в разрыв и работу как NFQUEUE так DPDK, наличие сборки пакетов.

 

Подскажите, почему мне следует выбрать решение на базе extfilter?

Где вы там поддержку DPDK увидели?

Suricata работает хорошо но не умеет заглушку слать...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Уважаемые подскажите.

Что нам выбрать extfilter или Suricata.

 

Сейчас используем nfqfilter.

nfqfilter перестал устраивать потому что нет сборки фрагментов.

У нас своя система получения реестра, парсинга и подготовки конфига для nfqfilter.

Переписать её для генерации конфигов для Suricata проблем не составляет.

 

Преимущества Suricata видим в поддержке режимов установки в разрыв и работу как NFQUEUE так DPDK, наличие сборки пакетов.

 

Подскажите, почему мне следует выбрать решение на базе extfilter?

Где вы там поддержку DPDK увидели?

Suricata работает хорошо но не умеет заглушку слать...

 

Есть соответствующие патчи.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Уважаемые подскажите.

Что нам выбрать extfilter или Suricata.

 

Сейчас используем nfqfilter.

nfqfilter перестал устраивать потому что нет сборки фрагментов.

У нас своя система получения реестра, парсинга и подготовки конфига для nfqfilter.

Переписать её для генерации конфигов для Suricata проблем не составляет.

 

Преимущества Suricata видим в поддержке режимов установки в разрыв и работу как NFQUEUE так DPDK, наличие сборки пакетов.

 

Подскажите, почему мне следует выбрать решение на базе extfilter?

Где вы там поддержку DPDK увидели?

Suricata работает хорошо но не умеет заглушку слать...

 

Есть соответствующие патчи.

Можно ссылку на DPDK патч

и заглушку?

 

AF_PACKET и RST работает отлично

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Можно ссылку на DPDK патч

и заглушку?

 

AF_PACKET и RST работает отлично

 

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

поэтому буду рад если поправите.

 

Заглушка

https://www.linux.org.ru/forum/admin/12008608#comment-12211597

 

DPDK Suricata гуглиться:

Snort/Suricata DAQ module with DPDK https://github.com/redBorder/daq

Integrate dpdk PMD to suricata read method under worker mode https://github.com/vipinpv85/DPDK_Suricata_3.0

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас