Достаточно интересная задача поступила мне в обработку в начале текущего года. Суть ее заключалась в том, чтобы весь Интернет-трафик организации завернуть на прокси-сервер вместо прямых обращений к маршрутизатору, имеющему прямой доступ в Интернет. Вернее, нет: моей задачей было в рамках ужесточения политики охраны конфиденциальных данных обеспечить ограничение доступа через сеть Интернет на запрещенные ресурсы и полное журналирование действий персонала в Интернете, за прокси уже додумал я. Чем задача интересна? Хотя бы тем, что внутри сети организации живет все, что угодно: от Microsoft Windows 98 до FreeBSD. Что конкретно было сделано, как сконфигурировано и с какими ошибками сталкивался на этапе реализации — не помню. Дело было уже почти год тому назад и более доступа к своему детищу я не имею, тем не менее, я хочу записать теоретическую часть, дабы хоть она осталась если не мне, то кому-нибудь другому на будущее. Именно поэтому в данной заметке вы не найдете конкретных решений с примерами, но найдете идеи по модификации и исправления к тому, что было реализовано по инструкциям, но не подошло.

Итак, имеем: прокси-сервер на Debian Jessie (не знаю, почему Debian; сегодня бы поставил Gentoo), внутреннюю сеть и полсотни различных машин работников. Изначально машины настроены так, что их шлюз по умолчанию — 192.168.0.200 (например). Это маршрутизатор, но нам так не подходит. В то же время, сильно дискредитированы были бы все меры, если бы я прошел по всем компьютерам и перед носом у работников менял бы шлюзы, поэтому маршрутизатор переезжает на 192.168.0.137, а на его прежнем адресе встает прокси-сервер.

Что нам нужно? Начнем с ограничения доступа. Список ничем не примечателен: социальные сети, сайты знакомств, развлекательные порталы, онлайн-видео (мера по экономии трафика, так как канал не сильно широк и при просмотре видео у одного другие могут остаться даже без электронной почты), эротика и порнография. Списков, благо, в Интернете навалом, так что тут проблем не будет. Как делается фильтрация по доменам в Squid рассказывать не буду — это все есть в Интернете и в 1001 раз я лучше не напишу. Скажу, однако, сразу, что меры эти с тех времен, как были опубликованы своими авторами в Интернете, немножко устарели. Нынче соединение со «В контакте» происходит по HTTPS, а для нас это значит, что доменное имя наш Squid никогда в жизни не определит и ему не останется ничего, кроме как пропустить соединение независимо от того, блокируем мы этот домен или нет.

В принципе, у Squid есть встроенное средство борьбы с шифрованием — вскрытие HTTPS-запросов, по этому пути я и пошел. Суть такова: пользователь обращается через прокси к HTTPS-ресурсу, прокси делает так, как будто запрос идет напрямую от прокси, после чего расшифрованную страницу снова шифрует, но уже со своим сертификатом. Пользователь видит страницу так, как будто бы она зашифрована как положено, если только не кликнет по подробностям сертификата, где увидит уже не то, что нужно. Но есть одно но: доверенный сертификат на любой домен вы не получите, даже на бесплатных сервисах, в противном же случае браузер пользователя будет вылетать с красными сообщениями о подмене сертификата. Выход есть: копируем сертификат прокси-сервера и ставим его в браузеры пользователей как доверенный. В Linux он становится доверенным сразу же, в Windows же логики работы с сертификатами я так и не понял. Есть одновременно с выходом и проблема: Squid'у пофиг на степень доверия тому сертификату, который мы подменяем. Таким образом, пользователь может зайти на сайт sberbank-onlayin.spb.ru, подписанный самодельным сертификатом, который через прокси удивительным способом превратится в доверенный. Очень серьезная дыра в безопасности, между прочим.

Какими бы там ни были дыры, решающим стало обрушение всех Интернет-банков, из-за чего бухгалтерия кратковременно потеряла контроль над расчетными счетами. В моем случае все было решено отключением HTTPS-проксирования для всех, однако же оптимальный способ при этом — создать список сетей CIDR, в которых размещаются блокированные ресурсы (у популярных социальных сетей это целые диапазоны, у более мелких сайтов можно ограничится только одним адресом). HTTPS-запросы далее вскрывать только в том случае, если сервер назначения находится в списке заблокированных (IP, в отличие от домена, видно даже через HTTPS).

А только ли социальные сети и порнография составляют проблему? Нет. Есть еще файлообменные сети (Torrent ложит на лопатки всю сеть, проверено), мессенджеры и прочее прикладное ПО, работающее за пределами Интернет-браузера. Torrent и некоторые мессенджеры блокируются путем запрета проксирования (IPv4-Forwarding) на конкретных портах или их диапазонах. Порно-вариант: блокировка всего, кроме 80, 443 и 2525. В конечном итоге мы сделали именно так, однако можно было немного поизвращаться и добиться намного более гибкой системы контроля доступа, но и более ресурсоемкой (но поскольку наш сервер занимался только проксированием, то чрезмерной нагрузки на него не наблюдалось). Сложнее всего блокируется Skype, но и там есть свои варианты, которых в сети есть.

Казалось бы, нирвана близко. Ан, нет. Хитренькие барышни через системного администратора за какие-то там небольшие услуги выведали адрес шлюза и изменили настройки своих сетевых адаптеров. Нонсенс тут не в том, что системный администратор находится в оппозиции к своей сети, а в том, что любой секретарь сидит за учетной записью администратора машины и может изменить в настройках что угодно. Такого быть не должно и пользователи должны находится на учетных записях пользователей. Вообще, пользуясь Linux-системами, можно даже ограничить список программного обеспечения, запускаемого пользователем, однако это не наш случай, ибо большинство работников впадает в транс, услышав слова «UNIX» и «ограничения». Есть способ проще: просто запрещаем на маршрутизаторе подключение откуда угодно, кроме MAC-адреса прокси-сервера (и, быть может, сетевой карты на компьютере человека, который занимается управлением этим всем хозяйством). Теперь можно менять настройки на что угодно, маршрутизатор просто сбросит соединение.

Позже появились дополнительные надстройки. Вместо обыкновенного обрыва соединения на запрещенном сайте появилась необходимость отображать сообщение о блокировке, а для некоторых работников возникла потребность в доступе к электронной почте без доступа к чему-либо еще в сети Интернет. Последнее решилось установкой nginx, а на нем — squirrelMail; первое же решилось размещением другой копии nignx на другом порту и перенаправлением посетителей запрещенных сайтов на тот порт (то есть, vk.com:8080 распознавалось как обращение к 192.168.0.200:8080 с Host=vk.com). В офисе на несколько недель воцарилась тишина и блаженство: все работало и не нуждалось в каких-либо модификациях. Я уже было упокоился, да рано. Появились сообщения о том, что некоторые сотрудники вместо работы и подготовки к проверке гоняют статусы в социальных сетях со скоростью лазерного принтера. Ясное дело, при опросе выяснилось, что у всех есть смартфоны с безлимитным Интернетом, только я в такое не верю, ибо некоторые даже позвонить никуда не могли с месяц назад по их же жалобам из-за невыгодных тарифов. Сейчас же посыпалась манна небесная?

Пока я гадал и разыскивал дыры сначала в своих настройках, а потом в исходном коде программного обеспечения, из которого я собирал deb-пакеты перед установкой, возникла новая проблема: одному из работников потребовалось открыть исходящий порт для какой-то там ужасно кривой программы от налоговой инспекции (такой себе платный LibreOffice Calc, который вместо сохранения отправляет документ по электронной почте в налоговую, только не на стандартный порт, а на какую-то ахинею). Набираю я iptables -L, дабы убедиться в том, что сейчас этот порт закрыт именно на прокси-сервере, а не на маршрутизаторе, и что я вижу? Входящий порт 80 прокси сервера перенаправляет абсолютно всех на порт прокси. Всех, кроме одного внутреннего IP-адреса, для которого по какой-то милости происходит прямой IPv4-Forwarding. Как результат, ни вскрытие HTTPS, ни черный список IP-адресов, ни список доменов не работают, так как запрос с компьютера сотрудника просто не доходит до Squid'а, а направляется дальше по сетевой иерархии. Говорю вам точно — главная дыра любой закрытой сети — не прокси, не вирусы и не секретарша, главная дыра закрытой сети — администратор с правами root над этой сетью. Никакие законы о конфиденциальных данных не остановят человека, перед носом у которого нарисовалась сиюминутная выгода, выгода, для получения которой ничего не нужно делать.

Кстати, прокси-сервер также помогает и вирусы контролировать. К примеру, во время работы над этой сетью выяснилось, что некоторые вирусы посылают запросы в командный центр на порт 80/443, а не на какой-то нестандартный, так как все они были бы неминуемо заблокированы. После сбора статистики выяснилось, что ботнет имеет несколько командных центров, блокировка которых на уровне прокси привела к тому, что вирус спокойно позволил себя удалить.

Интересные, конечно, эти все вещи. Только вот очень уж много они отнимают энергии. На все вышеописанное, например, у меня ушло две недели. Это с учетом первичного сбора информации, подготовки hardware и, собственно, реализации. Сюда я не считаю исправления после запуска — сервер во время всех этих манипуляций останавливался не более, чем на полчаса, соответственно, не снимаясь со своего места в стойке и не переезжая в мой офис (первоначальную же настройку и установку я не потянул на территории клиента — сервер таки жил у меня, ибо нуждался в качественном тестировании, которое на месте было невозможно обеспечить, а кроме этого я уже изрядно поднадоел некоторым сотрудникам, которые смотрели на меня, как на исчадие ада, в особенности после того, как перестали работать любимые «контактики» и «ФСБуки».