iptables string, можно ли пофиксить ложные срабатывания?

Ну там же есть опции ″--from″ и ″--to″, а с помощью ″-m length″ можно пакеты кидать в разные цепочки, где будут разные правила ″-m string″. Ну ещё можно попытаться прекрутить ″KPCRE″ и писать регулярные выражения для string.

Не хочешь специализированную тулзу для этого использовать?

string для поиска в dns запросах/ответах ? Они же на половину бинарные, да еще и со «сжатием».

Нужен декодер чтобы получить строку имени в читаемом виде.

Пример ложного страбатывания можно привести?

пример правила для google.com: DEPARTMENT_IP=192.168.1.192/26

iptables -t nat -A PREROUTING -i ens18 -p udp --dport 53 -s «$DEPARTMENT_IP» -d 192.168.1.4 \ -m string --algo bm --from 0x0020\ --hex-string «|676f6f676c6503636f6d|» \ -j DNAT --to-destination 10.10.2.1:53

и сверху маскарад.

Может чего не правильно?

Пример пакета:

0x0000: 4500 0038 861c 0000 4011 6484 c0a8 07c0 E..8....@.d..... 0x0010: c0a8 0704 e504 0035 0024 ebf2 8aab 0100 .......5.$...... 0x0020: 0001 0000 0000 0000 0667 6f6f 676c 6503 .........google. 0x0030: 636f 6d00 0001 0001 com.....

Пример чего именно вам нужен? Пакета? Попытаюсь объяснить, как именно происходят ложные срабатывания, например: все запросы попадают на DNS-fakeroot 192.168.1.4 и только избранные (например, google.com) DNAT'ятся на внешний dns, так вот иногда nslookup, dig да и просто браузер получает ip заглушки, при этом сам пакет отличается только в заголовках, та часть где находится доменное имя неизменна, по логам iptables тоже ничего внятного нету, пробовал дропать фрагментированные пакеты - тщетно. А самое интересное, что такие срабатывания случаются для любых доменных имен, например есть написать цикл, который будет все время спрашивать ip для ya.ru то рано или поздно он вернет реальный ip для ya.ru, а не адрем заглушки. Еще почитал про u32, сегодня опробую.

хм, а ты уверен, что это не срабатывает string ?

Клиенты могут использовать tcp, а не udp.

dns не различает регистр букв, а string различает.

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

Ищи проблему и она не в string.

У беспроводного клиента есть dns-кеш. Если данные есть в кеше, то он не просит тебя, а сразу пройдет на сайт.

Возможно они получают данные другим путем...

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

если строка находится в пакете не там, где ее ожидали - это не ложное страбатывание.

Ложное срабатывание - это обнаружение строки там, где ее нет.

Тему лучше исправить на «iptables string пропускает/не видит строку»

dns-кеш тут не причем.

как делаю проверку:

на клиенте:

while read line
 do 
  nslookup ya.ua  | grep Address |  grep -v "192.168.1.4"; 
done<<<$(seq 1 500)

а это tcpdump на стороне dns-сервера, в котором видно 3 ложных срабатывания. https://pastebin.com/CxMGXWvv

как еще можно узнать где он спотыкается?

какую например?

все запросы попадают на DNS-fakeroot 192.168.1.4 и только избранные (например, google.com) DNAT'ятся на внешний dns

как насчёт идеи создать на «DNS-fakeroot» google.com и слать на рекурисвный днс?

google.com это лишь пример, доменов там около тысячи, как я понимаю для каждого из них придется создавать зону с рекурсивным запросом.

с --from и --to понятно, а зачем использовать -m length? захватывать пакеты определенной длинны? Но ведь запрос для каждого домена имеет разную длину, или я не так понял?

В цепочку NAT попадают не все пакеты, а только первый пакет в каждом направлении. В твоем случае это может стать проблемой. Это не сложно проверить, если сделать 2 одинковых правила со string одно в filter, а другое в nat. Сбросить счетчики и запустить тест. Если счетчики различаются, значит есть такая проблема.

Есть способ посмотреть что происходит с пакетом - это "-j TRACE"

Проблема в том, что он много пишет в логи.

Я бы добавил правило типа "-p udp --dport 53 -s 192.168.1.192 -j TRACE"

Запустил тест (и tcpdump) и после этого удалил правило.

Дальше придется парсить логи.

Для «проскочивших» пакетов цепочка правил будет отличаться.

Ок спасибо, попробую.

Например, dnsdist. Или мой dnsbalancer.

Не нужно, не используте length, ваше дело. Просто исходно вы не уточнили, что подразумевается под «в какой именно части пакета», может вам нужно было что-то наподобие ″во второй трети пакета″.