Заблокировать внешнюю сеть по src признаку

misant

Коллеги. Картина следующая:

pfSense 2.2.3, LAN, WAN, IPSec. Из пакетов squid (ipcad + lightsquid), ntopng.

Сделал правило, сначала на LAN, потом floating. В правиле два alias, в source указаны локальные хосты, которые не надо пускать, в destination указан alias c адресами куда не надо пускать. Правило работает для всего трафика, кроме чистого http.

Я так понимаю, что squid его перехватывает и форвардит от своего имени (меняется source), потому пакет не попадает в условия правила.
Если бы нужно было блокировать для всех, думаю, что все бы работало и в таком виде (оставляем в правиле только destination).

Сбивает с толку, что если смотреть packet capture, то там для пакетов по 80 порту ничего не подменяется.

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

misant

Детали согласно правилам.

1. См. первый пост, изложил вроде доступно.
2. Схема проста, понятна из первого поста.
3. Скрины прилагаю:

1. Правила, стоит галка "писать в лог"
2. В логах есть попадания, но только по 443 порту.
3. Всплывающее, попадание именно по этому правилу.

В lightsquid и при анализе ntopng вижу, что люди все-таки ходят на указанные адреса (которые входят в алиас правила)

drop_rule.png_thumb

drop_match.png_thumb

drop.png_thumb

NegoroX

у меня pfsense 215
разрешаю 01vk алиас - несколько ip адресов сети кому "можно" в ВК

allov IPv4 * 01vk * 87.240.128.0/18 * * none

и следующее правило закрываю всем
deny IPv4 * 01vk * 87.240.128.0/18 * * none

для "ок" 217.20.144.0/20 много, иначе пролезут.
(правила на ЛАН - но можно как и у тебя на флоате.

misant

@NegoroX:

разрешаю 01vk алиас - несколько ip адресов сети кому "можно" в ВК

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

К тому же хочется разобраться, как это так получается, что пакет сначала попадает в сквид, если обращение идет по 80 порту. Правило прекрасно работает для все остальных запросов.

misant

Ответов не много, но продолжаю разбираться.

Если выполнить в cli "pfctl -sn", то можно увидеть все правила трансляции, даже те, что не видно в gui:

no nat proto carp all
nat-anchor "natearly/" all
nat-anchor "natrules/" all
no rdr proto carp all
rdr-anchor "relayd/" all
rdr-anchor "tftp-proxy/" all
rdr on xl0 inet proto tcp from any to ! (xl0) port = http -> 127.0.0.1 port 3128
rdr-anchor "miniupnpd" all

Выделена строка, которая как раз исключает моих жертв из запрещающего правила. Стало понятно почему запросы от них по 80 порту не попадают в запрет. Теперь нужно придумать как красиво это обойти.

misant

Сделал так:

rdr on xl0 proto tcp from <disable_soc>to <vkontakte_nets>port = http -> <vkontakte_nets>port 444 round-robin
rdr on xl0 proto tcp from <disable_soc>to <odnoklassniki_nets>port = http -> <odnoklassniki_nets>port 444 round-robin
rdr on xl0 inet proto tcp from any to ! (xl0) port = http -> 127.0.0.1 port 3128

Теперь сижу в засаде, жду когда полезут, запросы должны попасть в первоначальное правило, в логе должно быть обращение по 444 порту.</odnoklassniki_nets></odnoklassniki_nets></disable_soc></vkontakte_nets></vkontakte_nets></disable_soc>

misant

Да, всё работает. Тема закрыта.
Если кто сюда попадет поиском, буду нюансы постить, вдруг пригодится.

misant

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

Формулировка для поисковиков: Как заблокировать Вконтакте и Одноклассники pfSense?
Формулировка задачи от бизнеса: Нужно закрыть доступ к Вконтакте и Одноклассники для нескольких ПК.

Решение.

1. Создание алиасов. В Disable_soc вносим хосты, которым нужно запретить. Vkontakte_nets и Odnoklassniki_nets соответственно хосты\подсети блокируемых ресурсов. Удобный инструмент против таких монстров: http://bgp.he.net/search?search%5Bsearch%5D=odnoklassniki&commit=Search

2. Создаем правило для файрволла. См. картинку 1.

3. Создаем правило для ната. См. картинку 2. Т.к. у меня прокси в прозрачном режиме, то запросы на 80 порт перехватывает squid и шлет уже от своего имени, поэтому правило не блокирует такие запросы (только https, т.к. они идет на 443 порт). Редирект можно сделать и на корпоративный сервер, у меня так сделано, чтобы попадало в лог правила из пункта 2.

4. Профит!

ЗЫ: Блокировать https трафик средствами одного сквида сейчас не удалось (в прозрачном режиме), хотя потенциально возможно, если настроить что-то из Dansquard, Squid3 + man in the middle. Возможно когда починят Layer7, можно будет закрыть регулярными выражениями и кастомными фильтрами L7

02_rules_firewall.png_thumb
![01_port forward.png](/public/imported_attachments/1/01_port forward.png)
![01_port forward.png_thumb](/public/imported_attachments/1/01_port forward.png_thumb)

Scodezan

Думаю, можно обойтись без первого скрина, если во втором не указывать dest port.

misant

@Scodezan:

Думаю, можно обойтись без первого скрина, если во втором не указывать dest port.

Да, это мысль правильная. Можно логировать нат попадания в правило?

Scodezan

Поставьте соответствующую галочку в связанном правиле fw.

misant

Может быть есть успешный опыт фильтрации https трафика?
Какое оптимальное решение? Можно ли обойтись squid2 или обязательно третий нужен? Видел мануалы с разными вариантами, за 5 минут не вышло, возможно будет позже время поразбираться, но если кто-то поделится опытом, буду признателен.

werter

2 misant
Исп-те reject вместо block в Ваших правилах по соцсетям. Иначе при откр страниц со ссылками на соцсети будут дикие "тормоза".
И это не панацея. Про анонимайзеры слыхали ?
Рекомендую squid + squidguard + http://blog.bigbytenetworks.com/2014/09/pfsense-squid-squidguard-configuration/ + https-фильтрация.
Прийдется сертификаты пользователям "доверять" для серфинга, но это дело поправимое.

P.s. Зачем Вы Port forwarding вообще трогаете? Что это за перенаправление с 80-го на 444-ый причем на теже адреса ? Оно вообще работает ?
Если нужна прозрачная фильтрация - исп. squid со вкл. опцией transparent (описал выше)

misant

Про reject дельный совет, спасибо.
Про анонимайзеры конечно знаю, но т.к. ведется журнал посещений, то тут уже сотрудник не сможет сказать что случайно нажал на иконку соц сети на нормальном сайте. Использование анонимайзеров это умышленный обход запрета при использовании корпоративных ресурсов, это уже административно должно решаться.

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

PS: Порт форвардинг нужен, в моих сообщениях сначала темы описывается зачем. Да, оно работает. Редирект можно делать куда угодно, мне так было нужно, чтобы в лог попадало по тому же правилу, что и запросы на 443 порт. Сквид работает как прозрачный прокси.

werter

Squid2 там хватит или третий обязательно?

Squid3

misant

@werter:

Squid3

Да, спасибо. Удалось добиться нормальной работы squid3 + squidguard для фильтрации https. Сходу не получилось - генерились сертификаты для ip адресов вместо доменных имен. В IE хоть как-то работало, в Chrome вообще никак, несмотря на добавленный в доверенный корневой сертификат.

Спасла строчка "ssl_bump server-first all" в секции Custom ACLS (After_Auth) настроек squid3.

Тестирую, пока проблем не всплыло.