CC BY
89
ТЕХНИЧЕСКИЕ НАУКИ TECHNICAL SCIENCES
УДК 004.45
ББК 32.973.202-018.2
К 38
Киздермишов Асхад Асланчериевич
Кандидат физико-математических наук, доцент кафедры автоматизированных систем обработки информации и управления инженерно-физического факультета Адыгейского государственного университета, Майкоп, e-mail: Askhad_75@rambler.ru Киздермишова Сулиет Халидовна
Кандидат социологических наук, доцент, доцент кафедры экологии и защиты окружающей среды экологического факультета Майкопского государственного технологического университета, Майкоп, email: Suliet@rambler.ru
Установка и настройка редиректора для Squid (ssl-bump)
(Рецензирована)
Аннотация. Рассмотрены вопросы, связанные с вводом в эксплуатацию специального режима Squid (ssl-bump), даны рекомендации для администраторов ИТ с низким уровнем подготовки по установке и настройке редиректора SquidGuard для случая настройки пакета Squid со специальным режимом ssl-bump на Ubuntu.
Ключевые слова: Linux, Ubuntu, HTTPS, Squid, SquidGuard, прокси-сервер, фильтрация трафика, анализ трафика.
Kizdermishov Askhad Aslancherievich
Candidate of Physics and Mathematics, Associate Professor of the Department of Automated Systems of Processing Information and Control at Engineering-Physics Faculty, Adyghe State University, Maikop, ph. (8772) 593911, e-mail: Askhad_75@rambler.ru Kizdermishova Suliet Khalidovna
Candidate of Sociology, Associate Professor, Associate Professor of Department of Ecology and Environmental Protection of Environmental Faculty, Maikop StateUniversity of Technology, Maikop, e-mail: Suliet@rambler.ru
Installing and configuring the redirector for Squid (ssl-bump)
Abstract. The paper deals with the issues associated with the commissioning of a special regime Squid (ssl-bump) and gives recommendations for IT administrators with low level ofpreparation for installing and configuring the SquidGuard redirector for the case ofpackage configuration of Squid with special ssl-bump on Ubuntu.
Keywords: Linux, Ubuntu, HTTPS, Squid, SquidGuard, proxy server, traffic filtering, traffic analysis.
Как известно, распространяемые злоумышленниками через Интернет вредоносные программы способны нанести серьезный ущерб владельцам информационных ресурсов. Неприятные последствия могут наступить и для пользователей Интернета, случайно или неосознанно загрузивших на свой компьютер вредоносный код с сайта, электронной почты или из любого другого источника в сети Интернет [1, 2]. Этими обстоятельствами обусловлено повышенное внимание к вопросам защиты Интернет-шлюзов как от внешних угроз, так и от инсайдеров. Отдельное место в проблеме защиты Интернет-шлюзов занимают средства фильтрации и обработки адресов запросов от клиентов к серверам, так как эти средства предотвращают доступ пользователей Интернета к известным ресурсам (сайтам, страницам, серверам и т.п.), содержащим опасный код или нежелательную (запрещенную) информацию, а также способны осуществлять контентный анализ запросов пользователей Интернета и по его результатам предотвращать целый ряд угроз информационной безопасности.
В настоящее время наиболее эффективными средствами защиты от так называемых Интернет-угроз являются системы обнаружения и предотвращения вторжений Intrusion detection system/Intrusion prevention system (IPS/IDS) и Data Leak Prevention (DLP) системы [3]. Однако, ввиду дороговизны и сложности в настройке и эксплуатации, применение таких систем име-
ет смысл только в автоматизированных информационных системах (АИС) и корпоративных сетях передачи данных крупных компаний, либо государственных учреждений, в которых обрабатывается информация, сопоставимая по стоимости с IPS/IDS и DLP системами, и при условии наличия штатного подразделения по защите информации, способного осуществить ввод в эксплуатацию и эффективное применение таких сложных систем. Поэтому актуальной задачей является поиск технических решений для обеспечения безопасного доступа в Интернет из локальных вычислительных сетей (ЛВС) офисов небольших негосударственных компаний. Очевидно, что такое решение в отличие от IPS/IDS и DLP систем должно быть простым и дешевым, то есть отвечать следующим требованиям:
- разворачиваться на базе относительно недорогой аппаратной платформы;
- использовать только бесплатное (Freeware) системное и прикладное программное обеспечение;
- применяемое программное обеспечение должно быть простым в настройке и эксплуатации в такой мере, чтобы квалификации администратора ИТ с низким уровнем подготовки было достаточно для установки и настройки этого программного обеспечения [4].
Отметим, что для небольших компаний свойственно отсутствие в штате специалистов по защите информации или информационным технологиям (ИТ) с уровнем подготовки, который можно было бы охарактеризовать как высокий.
В рамках поставленной задачи рассмотрим процесс установки и настройки для совместной работы прокси-сервера и редиректора. В нашей предыдущей статье [5] уже рассмотрен процесс установки и настройки программного пакета Squid (далее Squid) со специальным режимом ssl-bump, поэтому далее будем исходить из того, что у нас есть прокси-сервер c возможностью контроля HTTPS трафика. Как показано в работе [5], администратор ИТ с низким уровнем подготовки способен установить и настроить этот прокси-сервер на базе недорогой аппаратной платформы и бесплатной операционной системы Ubuntu (семейство Linux). После настройки работы Squid перед администратором ИТ встанет новая проблема - настройка фильтрации и обработки адресов запросов от клиентов к серверам. Проблема может быть решена штатными средствами Squid с помощью списков контроля доступа Access Control List (ACL), но для работы с ними требуется довольно большой опыт. Кроме того, администратору ИТ придется самостоятельно составлять списки контроля доступа по результатам анализа содержимого наиболее посещаемых сайтов. Учитывая низкую квалификацию администратора ИТ и количество сайтов в Интернете, такое решение проблемы фильтрации сайтов не представляется эффективным. Отметить, что фильтрация сайтов штатными средствами Squid сопровождается еще и техническими сложностями, например, «притормаживание» открытия страниц на клиентских рабочих станциях, связанное с тем, что Squid хранит списки запрещенных сайтов в виде текстовых файлов, чтение которых может занимать довольно продолжительное время и увеличивать используемую оперативную память. Таким образом, для эффективного решения задачи необходимо использовать внешнюю программу (модуль прокси-сервера), отвечающую за фильтрацию и обработку адресов запросов от клиентов к серверам, так называемый редиректор. Суть работы редиректора состоит в том, что он перенаправляет пользователей, инициировавших запрос на доступ к запрещенным сайтам (страницам), на локальную страницу, содержащую информацию о причине запрета доступа.
Для выбора редиректора определим критерии, которым он должен соответствовать:
- редиректор должен быть протестирован на совместимость со Squid (ссылка на редиректор должна быть на официальном сайте разработчика Squid);
- редиректор должен хранить настройки фильтров не в текстовых файлах, а в базе данных, созданной средствами вспомогательного программного обеспечения;
- редиректор должен фильтровать трафик по сайтам, доменным именам и регулярным выражениям (контентный анализ);
- редиректор должен иметь функционал, позволяющий настраивать политику доступа в зависимости от идентификатора пользователя, группы пользователей, времени дня, текущей даты, дня недели, а также возможность гибкой настройки протоколирования всех запросов и
фактов запрета;
- должны регулярно выходить обновления и исправления редиректора, которые можно свободно скачать с сайта разработчика;
- списки запрещенных сайтов, применяемых редиректором, должны регулярно обновляться и быть доступными для свободного скачивания с сайта разработчика;
- редиректор и его вспомогательное программное обеспечение должны распространяться бесплатно (Freeware).
Указанным выше критериям соответствует редиректор SquidGuard. В Интернете можно найти много статей с рекомендациями по установке SquidGuard, но мы рекомендуем пользоваться теми инструкциями по установке и настройке редиректора, которые опубликованы на официальном сайте разработчика [6]. Эти инструкции на английском языке [6] и, на наш взгляд, они вполне доступны для понимания, не содержат лишней информации, связанной с настройками другого программного обеспечения. Тем не менее, как и в случае установки и настройки специального режима ssl-bump [5], комментарии к статьям и многочисленные посты на форумах показывают, что не все администраторы способны самостоятельно установить SquidGuard, пользуясь только инструкцией разработчика. Мы не подвергаем сомнению квалификацию и результаты авторов, на наш взгляд, ошибки связаны с тем, что для администратора ИТ с низким уровнем подготовки требуется более полное и детальное описание действий. Поэтому рассмотрим процесс установки и настройки по инструкциям, опубликованным на официальном сайте разработчика [6], с подробным описанием на русском языке всех этапов, в том числе вызывающих сложности у администраторов ИТ.
Инструкция по установке [6]
1. Распаковать исходный код.
Здесь мы отклонимся от инструкции и опишем несколько действий, которые необходимо выполнить до распаковки исходного кода SquidGuard.
Установим необходимые для работы SquidGuard пакеты:
1# apt-get install -y bison gcc flex
Создадим каталог для работы с исходными кодами:
2#cd /home/proxy/makes/
Скачаем и распакуем архив с исходным кодом вспомогательной СУБД BerkeleyDB:
3#cd/home/proxy/makes/&& wget http://download.oracle.eom/berkeley-db/db-4.6.21.NC.zip && unzip db-4.6.21.NC.zip
(&& - знак последовательного выполнения команд при условии, что предыдущая команда завершилась корректно.)
Скомпилируем и установим СУБД BerkeleyDB:
4#/home/proxy/mk/db-4.6.21.NC/build_unix/dist/configure —
prefix=/usr/local/BerkeleyDB.4.6 --enable-compat185 --enable-cxx && make && make install
Скопируем библиотеки в каталоги по умолчанию:
5#cp /usr/local/BerkeleyDB.4.6/lib/* /usr/lib && cp /usr/local/BerkeleyDB.4.6/lib/* /usr/lib32 && cd /usr && cp /usr/local/BerkeleyDB. 4.6/lib/* /usr/lib64 &&/cp /usr/local/BerkeleyDB.4.6/include/* /usr/include
Скачаем исходный код SquidGuard. Здесь мы заменили указанную в инструкции версию 1.2 на последнюю стабильную на момент написания статьи версию 1.4:
6#cd /home/proxy/mk/ && wget http://www.squidguard.org/Downloads/squidGuard-1.4.tar.gz
Теперь пришло время вернуться к тексту инструкции и распаковать исходный код SquidGuard:
7#tar xvzf squidGuard-1.4.tar.gz
2. Компиляция:
8#cd/home/proxy/mk/squidGuard-1.4 && ./configure --with-squiduser=proxy
Этот пункт инструкции не сопровождается никакими комментариями. Однако, на наш взгляд, параметр конфигурации --with-squiduser=proxy требует пояснений. Здесь под «proxy» имеется в виду имя учетной записи пользователя, от имени которого запущен процесс Squid. Для того чтобы узнать, от имени какого пользователя запущен процесс Squid, необходимо выполнить команду:
9#ps-aux
Если имя пользователя не «proxy», то необходимо внести соответствующие изменения в параметр конфигурации и повторить команду 8.
3. Установка.
10#make && make install
Здесь добавлена команда «make».
4. Установка черных списков.
К этому пункту в инструкции есть комментарий: «Скопируйте черные списки в желаемый каталог черного списка (по умолчанию: / usr / local / squidGuard / db) и распакуйте их. В приведенной ниже команде мы предполагаем, что используется местоположение по умолчанию. Убедитесь, что у вас есть соответствующие права на запись в этот каталог».
Для того чтобы в будущем не возникли проблемы, связанные с определением путей, каталоги по умолчанию лучше не менять. Изменим команды:
11#cd /usr/local/squidGuard/db
12#wget http://www.shallalist.de/Downloads/shallalist.tar.gz && gzip -d shallalist.tar.gz && tar xfv shallalist.tar
Здесь мы заменили MESD blacklists, применяемый по умолчанию, на более полный Shalla's Blacklists.
Shalla's Blacklists - это набор списков URL, сгруппированных по нескольким категориям, предназначенным для использования с фильтрами URL, такими, как SquidGuard Blacklists Shalla, бесплатный для некоммерческого использования, и на дату написания статьи количество записей в нем составляет порядка 1,7 миллиона. Этот «черный список» не рекомендуется по умолчанию, так как SquidGuard может работать и без установки СУБД BerkeleyDB, и в этом случае обработка такого большого фильтра в виде текстовых файлов «подвесит» прокси-сервер.
На этом инструкция по инсталляции заканчивается.
Перейдем к инструкции по настройке. Инструкция по настройке требует дополнительных пояснений только по п. 4 «Инициализация черного списка» раздела «Базовая конфигурация». Судя по обсуждениям на форумах, именно на этом этапе большинство администраторов сталкиваются с «неразрешимой проблемой» - «редиректор не редиректит». Как правило, администраторы ИТ с низким уровнем подготовки тратят много времени на поиск решения проблемы, иногда его не находят и отказываются от идеи установить редиректор. Изложим суть этого пункта на русском языке и поясним текст содержащихся в нем комментариев:
4. Инициализация черных списков.
До применения редиректора необходимо инициализировать черные списки, то есть перевести их из текстовых файлов в файлы БД. Использование формата db ускорит проверку и блокировку.
Инициализация выполняется следующей командой:
13#squidGuard -C all
14#chown -R <squiduser> /usr/local/squidGuard/db/*
Вторая команда гарантирует, что ваш Squid сможет получить доступ к черным спискам. В качестве <squiduser> укажите имя учетной записи пользователя, от имени которой запущен процесс Squid.
Инициализация может занять время от нескольких секунд до нескольких минут в зависимости от размера черных списков и мощности вашего компьютера. В случае если инициализация завершилась успешно, на экран будет выведено содержимое лог-файла (cache.log) примерно такого содержания:
2018-01-13 1 6:21:52 [9394]squidGuard 1.4 started (1515849712.954)
2018-01-13 1 6:21:52 [9394] db update done
2018-01-13 1 6:21:52 [9394] squidGuard stopped (1515849712.970)
В случае корректного завершения процесса инициализации в каталогах, содержащих файлы domains и urls, должны быть созданы дополнительные файлы domains.db и urls.db. Эти новые файлы не должны быть пустыми! Инициализируются только те черные списки, которые применили в правилах, указанных в конфигурационном файле squidGuard.conf.
Комментарий, приведенный после команды 14, означает, что права на файлы domains.db и urls.db есть только у пользователя, под учетной записью которого произведена инициализация базы данных. В идеале нужно инициализировать базу данных, используя учетную запись пользователя, от имени которого стартует Squid, которую, как отмечалось выше, можно уточнить, выполнив команду 9. В любом случае присвоение командой 14 нужному пользователю прав на файлы domains.db и urls.db гарантирует отсутствие ошибок доступа к файлам, в результате которых SquidGuard не выполняет функции редиректора.
Еще большую гарантию корректности работы даст замена команды 13 на команду:
15#squidGuard -d -u <squiduser> $(which squidGuard) -C all
Встроенная команда "which squidGuard" исключит вероятность опечатки в пути к исполняемому файлу, а ключи "-d" и "-u" позволят присвоить нужные права на файлы domains.db и urls.db еще на этапе инициализации базы данных.
На этом конфигурирование squidGuard завершено.
Далее нужно изменить конфигурацию Squid таким образом, чтобы редиректор вызывался после завершения ss-bump. Для этого необходимо вставить четыре строки, которые приведены ниже, в конфигурационный файл squid.conf после строки ssl_bump none all:
1) url_rewrite_host_header off - рекомендуем запретить переписывать заголовок Host;
2) url_rewrite_bypass off - рекомендуем отключить для того, чтобы все запросы шли через редиректор, только в этом случае пользователи гарантированно не получат доступ к запрещенным сайтам, кроме того, кэширование на Squid (ssl-bump) отключено;
3) url_rewrite_program /usr/local/bin/squidGuard - путь к редиректору;
4) url_rewrite_children 10 - рекомендуем устанавливать равным количеству пользователей, одновременно работающих в Интернете; если установите их меньше, то Squid будет работать медленно, ожидая освобождения для обработки накопившихся соединений, и наоборот, если запустите слишком много, они будут потреблять значительные системные ресурсы.
Если после перезапуска Squid в cache.log нет ошибок, установка и настройка редиректора для Squid (ssl-bump) завершена. Далее необходимо настроить локальный веб-сервер (Apache HTTP-сервер) с поддержкой протокола HTTPS, так как в случае Squid (ssl-bump) будет осуществляться редирект запросов к HTTPS ресурсам, а также создать локальные страницы, содержащие информацию о причинах запрета доступа. Следует отметить, что из-за особенностей работы Squid со специальным режимом ssl-bump невозможно без существенной доработки использовать типовые страницы, включенные в состав дистрибутива SquidGuard. По завершению последних действий можно вводить прокси-сервер в эксплуатацию.
Таким образом, следуя нашим рекомендациям, можно получить максимально эффективное решение поставленной в статье задачи. Окончательное решение строится на базе недорогой аппаратной платформы и бесплатной операционной системы Ubuntu (семейство Linux), а также бесплатного программного обеспечения пакетов Squid и
SquidGuard, позволяющих контролировать содержимое как HTTP, так HTTPS трафика. Полный контроль HTTPS трафика достигается совместным использованием редиректора SquidGuard, который существенно расширяет возможности настройки фильтрации, в частности, он позволяет проводить фильтрацию по регулярным выражениям, и пакета Squid, настроенного на работу со специальным режимом ssl-bump, что позволяет «просматривать» HTTPS трафик, закрытый при стандартных настройках. Кроме того, SquidGuard используют средства СУБД BerkeleyDB, что обеспечивает более быструю фильтрацию, чем штатные средства Squid.
Эффективность решения может быть усилена установкой анализатора лог-файлов и антивирусного программного обеспечения. В качестве анализатора лог-файлов и антивирусного программного обеспечения рекомендуем использовать SARG (Squid Analysis Report Generator) и Clam AntiVirus. Следует отметить очевидные достоинства и даже преимущества этого решения перед большинством коммерческих прокси-серверов, которые, например, не имеют функционала, позволяющего проводить фильтрацию HTTPS трафика по регулярным выражениям.
Выбор, установка и настройка анализатора лог-файлов и антивирусного программного обеспечения представляют отдельную тему для изучения.
Примечания:
1. Киздермишов А. А. Защита персональных данных при их обработке посредством информационно-телекоммуникационной сети «Интернет» // Вестник Адыгейского государственного университета. Сер. Естественно-математические и технические науки. 2015. № 4 (171). С. 139-143. URL: http://vestnik.adygnet.ru
2. Киздермишов А.А. Вирус-вымогатель WANNA-CRY и те, кого он не атаковал // Информационные системы и технологии в моделировании и управлении: материалы Всерос. науч.-практ. конф. / отв. ред. Н.Н. Олейников. 2017. С. 241-245.
3. Киздермишов А.А., Киздермишова С.Х. К вопросу о вводе в эксплуатацию DLP-систем // Вестник Адыгейского государственного университета. Сер. Естественно-математические и технические науки. 2017. Вып. 3. С 128-133. URL: http://vestnik.adygnet.ru
4. Киздермишов А.А. Снижение риска возникновения предпосылок угроз информационной безопасности, связанных с ошибочными действиями и неверно принятыми решениями специалистов, ответственных за защиту информации // Вестник Майкопского государственного технологического университета. 2009. № 3. С. 111-115.
5. Киздермишов А.А., Киздермишова С.Х. Установка и настройка специального режима Squid (ssl-bump) на Ubuntu 12.04 TLS // Вестник Адыгейского государственного университета. Сер. Естественно-математические и технические науки. 2017. № 4 (211). С. 154-159. URL: http://vestnik.adygnet.ru
6. Официальный сайт разработчика SquidGuard. [Электронный ресурс]. URL: http://www.SquidGuard.org
References:
1. Kizdermishov A.A. Protection of personal information at its processing by means of the Internet telecommunication network // The Bulletin of the Adyghe State University. Ser. Natural-Mathematical and Technical Sciences. 2015. Iss. 4 (171). P. 139-143. URL: http://vestnik.adygnet.ru
2. Kizdermishov A.A. The virus-extortionist WANNA-CRY and those whom he did not attack // Information systems and technologies in modeling and management: materials of the Russian scientific-practical conference / ed.-in-chief N.N. Oleynikov. 2017. P. 241-245.
3. Kizdermishov AA, Kizdermishova S.Kh. On the issue of the commissioning of DLP-systems // The Bulletin of the Adyghe State University. Ser. Natural-Mathematical and Technical Sciences. 2017. Iss. 3. P. 128-133. URL: http://vestnik.adygnet.ru
4. Kizdermishov A.A. Reducing the risk of the emergence of prerequisites for information security threats related to erroneous actions and incorrectly accepted decisions of specialists responsible for protecting information // The Bulletin of the Maikop State Technological University. 2009. № 3. P. 111-115.
5. Kizdermishov AA, Kizdermishova S.Kh. Installing and configuring a special Squid mode (ssl-bump) on Ubuntu 12.04 TLS // The Bulletin of the Adyghe State University. Ser. Natural-Mathematical and Technical Sciences. 2017. Iss. 4. P. 154-159. URL: http://vestnik.adygnet.ru
6. Official website of the SquidGuard developer. [Electronic resource]. URL: http://www. SquidGuard.org
