Актуальность блокировки посещений запрещенных ресурсов затрагивает любого админа, которому могут официально предъявить невыполнение закона или распоряжения соответствующих органов.
Зачем изобретать велосипед тогда, когда есть специализированные программы и дистрибутивы для наших задач, например: Zeroshell, pfSense, ClearOS.
Еще один вопрос оказался у начальства: А есть ли у используемого продукта сертификат безопасности нашего государства?
У нас был опыт по работе с перечисленными дистрибутивами:
- Zeroshell — разработчики даже подарили на 2 года лицензию, но оказалось что интересующий дистрибутив нелогично для нас выполнял критическую для нас функцию;
- pfSense — уважение и почет, одновременно скучно, привыкание к командной строке файрвола FreeBSD и не достаточно удобно для нас (думаю дело привычки, но это оказалось не «тем путем»);
- ClearOS — на нашем железе оказалось очень медленно, до серьезного тестирования не смогли дойти, вот и зачем такие тяжелые интерфейсы?
- Ideco SELECTA. Про продукт «Айдеко» отдельный разговор, интересный продукт, но по политическим соображениям не для нас, а еще хочется «укусить» их по поводу лицензии на тот же линукс, Roundcube и т.п. С чего они взяли, что «напилив» интерфейс в Python и отобрав права суперпользователя они могут продавать законченный продукт составленный из разработанных и доработанных модулей интернет сообщества распространяемых по GPL&etc.
Понимаю, что сейчас в мою сторону посыпятся негативные возгласы с требованиями детально обосновать свои субъективные ощущения, но хочу сказать что этот узел сети также является балансировщиком трафика на 4 внешних канала к сети Интернет, причем у каждого канала есть свои особенности. Еще краеугольным камнем стала необходимость работать одному из нескольких сетевых интерфейсов в разных адресных пространствах, и я готов признать, что применять везде где надо и не надо VLANы я не готов. В пользовании есть устройства типа TP-Link TL-R480T+ — ведут себя не идеально, в общем со своими нюансами. Эту часть на Linux получилось вменяемо настроить благодаря оф.сайту Ubuntu . Причем каждый из каналов может «упасть» в любой момент, как и подняться. Если интересует скрипт, который работает на данный момент (а это стоит отдельной публикации) — пишите в комментариях.
Рассматриваемое решение не претендует на уникальность, но хочется задать вопрос: «А зачем на предприятии приспосабливаться под сторонние сомнительные продукты с серьезными аппаратными требованиями когда можно рассмотреть альтернативный вариант?».
Если в РФ есть список Роскомнадзора, в Украине — приложение к Решению Совета НацБезопасности (напр. ), то на местах руководители тоже не спят. Например, нам был передан список запрещенных сайтов, по мнению руководства ухудшающих производительность труда на рабочем месте.
Общаясь с коллегами на других предприятиях, на которых по умолчанию запрещены все сайты и только по запросу с разрешения начальника можно получить доступ к конкретному сайту, уважительно улыбнувшись, подумав и «покурив над проблемой» пришло понимание того, что жизнь все-таки хороша и мы начали свой поиск.
Имея возможность не только аналитически посмотреть, что пишут в «книгах домохозяек» про фильтрацию трафика, но и посмотреть что происходит на каналах разным провайдеров мы подметили следующие рецепты (любые скрины немного обрезаны, прошу понять просить):
Провайдер 1
— не заморачивается и навязывает собственные ДНС сервера и прозрачный прокси-сервер. Ну что?.. зато у нас есть доступ туда куда надо (если нам это надо :))
Провайдер 2
— считает что его верхний провайдер должен об этом думать, техподдержка верхнего провайдера даже призналась почему я не могу открыть необходимый мне не запрещенный сайт. Я думаю что картинка вас развеселит 🙂
Как оказалось, они имена запрещенных сайтов переводят в айпи адреса и блокируют именно IP (не беспокоит их то, что на этом IP адресе может размещаться и 20 сайтов).
Провайдер 3
— пропускает трафик туда, но обратно по маршруту его не пускает.
Провайдер 4
— запрещает все манипуляции с пакетами в указанном направлении.
А что делать с ВПН (браузеру Opera уважение) и плагинами для браузеров? Играясь по-началу с узловым Mikrotik у нас даже появился ресурсоемкий рецепт на L7, от которого в последствии пришлось отказаться (запрещенных названий может быть и побольше, печально становится когда кроме своих прямых обязанностей по маршрутам, на 3х десятках выражений загрузка процессора PPC460GT уходит в 100%).
.
Что стало понятно:
ДНС на 127.0.0.1 абсолютно не панацея, современные версии браузеров таки позволяют обходить подобные траблы. Ограничить всех пользователей урезанными правами нельзя, и нельзя забывать об огромном количестве альтернативных ДНС. Интернет не статичен, и кроме новых ДНС адресов, запрещенные сайты покупают новые адреса, изменяют домены верхнего уровня, могут добавить/удалить символ в своем адресе. Но все же имеет право жить что-то типа:
ip route add blackhole 1.2.3.4Вполне действенным было бы получение списка IP адресов из списка запрещенных сайтов, но по указанным выше соображениям мы перешли к соображениям о Iptables. Существовал уже живой балансировщик на CentOS Linux release 7.5.1804.
Интернет у пользователя должен быть быстрым, а Браузер не должен ждать полминуты, заключая что данная страница не доступна. После долгих поисков мы пришли к такой модели:
Файл 1 -> /script/denied_host, список запрещенных названий:
test.test
blablabla.bubu
torrent
pornoФайл 2 -> /script/denied_range, список запрещенных адресных пространств и адресов:
192.168.111.0/24
241.242.0.0/16Файл-скрипт 3 -> ipt.sh, выполняющий работу с ipables:
# считываем полезную информацию из перечней файлов
HOSTS=`cat /script/denied_host | grep -v '^#'`
RANGE=`cat /script/denied_range | grep -v '^#'`
echo "Stopping firewall and allowing everyone..."
# сбрасываем все настройки iptables, разрешая то что не запрещено
sudo iptables -F
sudo iptables -X
sudo iptables -t nat -F
sudo iptables -t nat -X
sudo iptables -t mangle -F
sudo iptables -t mangle -X
sudo iptables -P INPUT ACCEPT
sudo iptables -P FORWARD ACCEPT
sudo iptables -P OUTPUT ACCEPT
#решаем обновить информацию о маршрутах (особенность нашей архитектуры)
sudo sh rout.sh
# циклически обрабатывая каждую строку файла применяем правило блокировки строки
for i in $HOSTS; do
sudo iptables -I FORWARD -m string --string $i --algo bm --from 1 --to 600 -p tcp -j REJECT --reject-with tcp-reset;
sudo iptables -I FORWARD -m string --string $i --algo bm --from 1 --to 600 -p udp -j DROP;
done
# циклически обрабатывая каждую строку файла применяем правило блокировки адреса
for i in $RANGE; do
sudo iptables -I FORWARD -p UDP -d $i -j DROP;
sudo iptables -I FORWARD -p TCP -d $i -j REJECT --reject-with tcp-reset;
done
Применение sudo обусловлено тем, что у нас есть небольшой хак для управления через WEB интерфейс, но как показал опыт использования такой модели сроком более года, то WEB не так уж и нужен. После внедрения было желание перечень сайтов завести в БД и т.п. Количество заблокированных хостов более 250 + десяток адресных пространств. Действительно есть проблема при переходе на сайт по https соединению, как и системного администратора у меня есть претензии к браузерам :), но это частные случаи, большинство срабатываний к отсутствию доступа к ресурсу всё таки на нашей стороне, так же успешно блокируем Opera VPN, плагины типа friGate и телеметрию от Майкрософт.
Источник: habr.com