[kid79]

Добрый день, нужна помощь с iptables+ipset есть 3 листа allow_ip (список ip кому разрешен выход), balance (список ip абонентов с отрицельным балансом или заблокированных) и paysystem (список ip доступных при блокировке )

Для абонентов заблокированных или с отрицательным балансом должны быть доступны только ip адреса указанные в списке paysystem. Абоненты за натом.

# Generated by iptables-save v1.4.21 on Mon Feb 27 11:58:36 2017

*mangle

:PREROUTING ACCEPT [1892480404:1947463774622]

:INPUT ACCEPT [27232317:1873540746]

:FORWARD ACCEPT [1865202794:1945586577869]

:OUTPUT ACCEPT [213524:31329599]

:POSTROUTING ACCEPT [1864682462:1945556853785]

COMMIT

# Completed on Mon Feb 27 11:58:36 2017

# Generated by iptables-save v1.4.21 on Mon Feb 27 11:58:36 2017

*nat

:PREROUTING ACCEPT [1157334:81677883]

:INPUT ACCEPT [3722:242087]

:OUTPUT ACCEPT [26:1558]

:POSTROUTING ACCEPT [26:1558]

-A PREROUTING -p tcp -m set --match-set balance src,dst -m set ! --match-set paysystem dst,src -m multiport --dports 80,443 -j DNAT --to-destination xxx.xxx.xxx.xxx (web сервер с страницей блокировки)

-A POSTROUTING -m set --match-set allow_ip src -j SNAT --to-source xxx.xxx.xxx.xxx (внешний ip адрес)

COMMIT

# Completed on Mon Feb 27 11:58:36 2017

# Generated by iptables-save v1.4.21 on Mon Feb 27 11:58:36 2017

*filter

:INPUT DROP [1317033:80780178]

:FORWARD DROP [23035:1987734]

:OUTPUT ACCEPT [28943:2169331]

-A INPUT -i lo -j ACCEPT

-A INPUT -i bond1 -j ACCEPT

-A INPUT -i bond0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

-A INPUT -i eth3 -j ACCEPT

-A FORWARD -i bond1 -o bond0 -m set --match-set allow_ip src -j ACCEPT

-A FORWARD -i bond0 -o bond1 -m set --match-set allow_ip dst -j ACCEPT

COMMIT

# Completed on Mon Feb 27 11:58:36 2017

т.е сейчас абоненты из списка allow_ip натятся, все остальное режется. Блокированные абоненты должны отправляться на веб сервер со страницей блокировки , счеткики iptables увеличиваются а вот с FORWARD-ом у меня затык какой то выходит.

[kid79]

потрите пожалуйста тему. разобрался.

[arhead]

разобрался.

Что именно сделали? На стенде работает, на боевой ipset поставил но увы ни в какую не хочет работать. ОС Debian 8 ядро ванильное 3.18. Может что еще надо дополнительно установить?

 

На стедне есть два листа sber Где сети сбера, биллинга, компании и balance где апишники заблокированных.

 

iptables -t nat -A PREROUTING -p tcp -m set --match-set balance src -m set ! --match-set sber dst,src -j DNAT --to-destination 194.XX.XXX.XX:8080

iptables -t nat -A POSTROUTING -p tcp -m set --match-set balance src -o bond2.128 -m multiport --dports 8080,80 -j SNAT --to-source 194.X.XXX.XXY

 

Вот думаю из-за чего тут получается доступ на боевом нет.

Edited July 4, 2017 by arhead

[Asatiany]

Приветствую!

UP'ну тему.

Используя ipset, как правильно построить правила SNAT?

Поясню.

Имеем:

ipset "BLOCK" - для заблокированных пользователей;

ipset "FREE" - разрешенные ресурсы;

1.1.1.1 - страница блокировки на другом сервере;

ppp+ - интерфейсы пользователей.

Пока блокировка отсутствует, пользователь пользуется всеми благами Интернета. Если принудительно блокируем, то

Quote

iptables -t nat -A PREROUTING -i ppp+ -m set --match-set BLOCK src -m set ! --match-set FREE dst -m tcp -p tcp --dport 80 -j DNAT --to-destination 1.1.1.1

великолепно DNAT'ит только НОВЫЕ страницы браузера, если там уже были открыты какие-либо ресурсы, то ими спокойно пользуешься. Политикой DROP в цепочке mangle FORWARD можно убить их, но как-то не комильфо видеть "Страница недоступна" без пояснения. Понимаю, что спасет действие SNAT. Но как, если --to-source там  - конкретный IP-адрес, а не список ipset?

[taf_321]

*nat
-A PREROUTING -i ppp+ -p tcp -m tcp --dport 80 -m set --match-set station4 src -j ACCEPT
-A PREROUTING -i ppp+ -p tcp -m tcp --dport 80 -m set --match-set mandatory4 dst -j ACCEPT
-A PREROUTING -i ppp+ -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.0.0.2

Первое правило - пропускаем всех клиентов, адрес которых внесены в station4.

Второе прапвило - пропускаем всех на ресурсы, адреса которых прописаны в mandatory4.

Третье правило - заворачиваем всех, кто не попался на первом и втором правилах на сайт-заглушку по адресу 10.0.0.2

[Asatiany]

On 22.09.2018 at 3:30 PM, taf_321 said:

*nat
-A PREROUTING -i ppp+ -p tcp -m tcp --dport 80 -m set --match-set station4 src -j ACCEPT
-A PREROUTING -i ppp+ -p tcp -m tcp --dport 80 -m set --match-set mandatory4 dst -j ACCEPT
-A PREROUTING -i ppp+ -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.0.0.2

Первое правило - пропускаем всех клиентов, адрес которых внесены в station4.

Второе прапвило - пропускаем всех на ресурсы, адреса которых прописаны в mandatory4.

Третье правило - заворачиваем всех, кто не попался на первом и втором правилах на сайт-заглушку по адресу 10.0.0.2

Логика более-менее понятна, но сложна, ибо

 

On 21.09.2018 at 12:02 PM, Asatiany said:

  Quote

iptables -t nat -A PREROUTING -i ppp+ -m set --match-set BLOCK src -m set ! --match-set FREE dst -m tcp -p tcp --dport 80 -j DNAT --to-destination 1.1.1.1

оперирует уже ФИЛЬТРОВАННЫМИ адресами, без указания глобальных. В DNAT попадает только первый пакет (новый ресурс). Уже с установленными соединениями оно не работает. Тут, прям, REDIRECT напрашивается, но "заглушка" на другой машине... К тому же, есть нюансы с HTTPS (порт 443): ругается на сертификаты и защищенность. Вот, вот, как бы SNAT'ить правильно?

[taf_321]

В 24.09.2018 в 15:55, Asatiany сказал:

Логика более-менее понятна, но сложна, ибо

В вашем однострочнике пакет будет обязательно дважды проходить проверку в сете, без нужды нагружая hash_net4_test. В моем случае первой строкой 99.99% трафика проверяется в одном сете. Во втором сете проверяются оставшиеся сотые доли. Логику "в xNAT попадает первый пакет, поэтому в правилах городим всякую развесистую многоэтажную херню"  лучше сразу отбросить, ибо светит в совсем недалеком будущем вполне реальными проблемами.

 

Пытаться заворачивать https без подсаживания клиенту в CA-хранилище своего корневого серта - пустое занятие. Обсасывалось тут не раз.

 

И какие могут быть проблемы с SNAT?

[Asatiany]

1 hour ago, taf_321 said:

Логику ...  лучше сразу отбросить, ибо светит в совсем недалеком будущем вполне реальными проблемами

Поясните, пожалуйста, какими? Как говориться: "Предупрежден - значит вооружен".

1 hour ago, taf_321 said:

И какие могут быть проблемы с SNAT?

Уже говорил, что

On 21.09.2018 at 12:02 PM, Asatiany said:

если там уже были открыты какие-либо ресурсы, то ими спокойно пользуешься. Политикой DROP в цепочке mangle FORWARD можно убить их, но как-то не комильфо видеть "Страница недоступна" без пояснения. Понимаю, что спасет действие SNAT. Но как, если --to-source там  - конкретный IP-адрес, а не список ipset?

, то есть как мне "зарулить" все уже установленные соединения на страницу-пояснение при блокировке? Сервер - NAS, сетей три - абонентская (local - под туннели), ospf и туннели пользователей (PPTP). Вот и не пойму, КАК именно и КУДА именно src'ить... 

Edited September 26, 2018 by Asatiany

[taf_321]

8 часов назад, Asatiany сказал:

Поясните, пожалуйста, какими? Как говориться: "Предупрежден - значит вооружен".

 

Просто рассчитывайте пути обработки пакета так, чтобы свести их шаги к минимуму для максимального числа пакетов. Ваш однострочник красив и элегантен, но, как я говорил, пакет в нем проходит проверку в двух сетах. И все ради того, чтобы убедиться, что 99.999% пакетов не подходят ни для одного ни для другого условия и пакет пойдет обрабатываться дальше по цепочке. В моем примере как раз эти 99.999% пакетов будут прогнаны в одном сете и полетят по своим делам. Экономия ресурсов в наличии.

 

8 часов назад, Asatiany сказал:

, то есть как мне "зарулить" все уже установленные соединения на страницу-пояснение при блокировке? Сервер - NAS, сетей три - абонентская (local - под туннели), ospf и туннели пользователей (PPTP). Вот и не пойму, КАК именно и КУДА именно src'ить... 

 

Все завернуть не выйдет, как выше написал, с HTTPS будет облом. HTTP завернется без проблем при очередном GET/POST запросе. Чтобы можно было перекрыть кислород смотрящих http-стрим или у кого получилось в http/2, для этого надо обязательно продублировать разрешительно-запретительные правила в *filter или *raw таблицах. При реконнекте он получит заглушку. В *mangle кроме изменения полей заголовков пакетов больше ничего делать не рекомендуется.

[Asatiany]

On 26.09.2018 at 9:16 PM, taf_321 said:

Экономия ресурсов в наличии

Убедили, спасибо!

 

On 26.09.2018 at 9:16 PM, taf_321 said:

с HTTPS будет облом

Как же с ним быть? Да и вообще - почему? Создание защищенного подключения (грубо говоря обмен сертификатами) ведь происходит ПОСЛЕ создания подключения (обмена начальными пакетами-запросами). Неужели на этом этапе нельзя применить ограничения, которые дает firewall? 

[alibek]

3 минуты назад, Asatiany сказал:

Как же с ним быть?

Никак.

3 минуты назад, Asatiany сказал:

Да и вообще - почему?

Потому что перенаправление — это подмена ответа сервера (кодом 302 на новый адрес или просто подмена ответа).

HTTPS для того и предназначен, чтобы нельзя было подменить ответы.

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

[Asatiany]

1 hour ago, alibek said:

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

Возможно ли сбросить через firewall такое защищенное (уже установленное) соединение, чтобы процедура его установления прошла заново? Ведь пакеты попадают под DNAT, но браузер будет ругаться на сертификат, а если "Все-равно загрузить" - то выскочит "заглушка"... Как организовать? 

[Asatiany]

И, получается, что с HTTPS бороться можно только действующим доменом и официальным сертификатом? Придется ковыряться с DNS?

[alibek]

24 минуты назад, Asatiany сказал:

Возможно ли сбросить через firewall такое защищенное (уже установленное) соединение

Сбросить можно.

24 минуты назад, Asatiany сказал:

чтобы процедура его установления прошла заново

Не будет.

24 минуты назад, Asatiany сказал:

Как организовать?

Никак. Забыть про это.

7 минут назад, Asatiany сказал:

И, получается, что с HTTPS бороться можно только действующим доменом и официальным сертификатом?

Посмотрите в сертификате сайта, кто его выпустил.

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

8 минут назад, Asatiany сказал:

Придется ковыряться с DNS?

DNS не поможет.

Или MITM (с малыми шансами на успех), или забыть про описанные глупости.

[LostSoul]

В 28.09.2018 в 12:10, alibek сказал:

Посмотрите в сертификате сайта, кто его выпустил.

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

это теперь вроде тоже не помогает, так как адепты корпорации бобра ведут реестр всех выпущенных сертификатов

 

[alibek]

Не всех сертификатов, а всех CA. А CA будет настоящий, нужно его только уговорить.

[st_re]

Да нет, как раз всех сертификатов... всех многих миллионов сертификатов. Причем ЦА сам их должен (дату уже не помню, кажется с марта именно должен, ранее было по желанию ЦА, но в 16 году уже многие сливали) слить перед подписанием. и ссылку вписать в выдаваемый сертификат. И свежие хромы сертификат без такой записи не примут...   (сам не проверял, т.к. поддельного сертификата взять негде, а для приватных ЦА пока не требуется).. туда же попадают ранее неучтенные сертификаты когда они попадают в поле зрения кравлеров (ну гугл, например)

 

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

 

http://www.certificate-transparency.org/

[disappointed]

В 28.09.2018 в 14:01, Asatiany сказал:

И, получается, что с HTTPS бороться можно только действующим доменом и официальным сертификатом? Придется ковыряться с DNS?

Зачем в 2018 пытаться что-то вывести в браузер? У большей части пользователей

гаджеты с приложениями которые общаются с своими серверами всякими json-ами,

уже этого достаточно чтобы оставить эту идею.