Linux глазами хакера

Флёнов Михаил Евгеньевич

9.5.1. Безопасность сервиса

Когда я впервые знакомился с документацией на squid, то мне очень понравились следующие два параметра:

cache_effective_user

и

cache_effective_group

. Если squid запущен от имени администратора root, то идентификаторы пользователя и группы будут заменены на указанные в этих параметрах. По умолчанию установлено значение идентификатора squid для пользователя и для группы:

cache_effective_user squid

cache_effective_group squid

Таким образом, squid не будет работать с правами root,

и при попытке сделать это сервис сам понизит свои права до squid. Не стоит вмешиваться. Сервису squid не имеет смысла давать большего, потому что ему достаточно прав только на директорию с кэшем.

9.5.2. Ускорение сайта

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

□ 

httpd_accel_host адрес

— адрес реального сервера;

□ 

httpd_accel_port порт

— порт Web-сервера. Чаще всего это порт по умолчанию (он равен 80), если не указан другой;

□ 

httpd_accel_uses_host_header параметр

— HTTP-заголовок включает в себя поле Host, не проверяемое сервером squid, и это может оказаться большой дырой в безопасности. Разработчики рекомендуют отключать эту директиву, указав в качестве параметра значение

off

. Включать ее необходимо, если squid работает в прозрачном режиме;

□ 

httpd_accel_with_proxy параметр

— флаг использования кэширования страницы для дополнительного повышения скорости (

on

/

off

).

9.5.3. Маленький секрет User Agent

Многие статистические системы не учитывают или не пускают к себе пользователей, запросы которых содержат пустое значение в поле User Agent. Именно так определяется, что вы работаете через proxy.

Опять случай из собственной практики. Я снова вспоминаю фирму, где мне пришлось работать 4 года, и защита была организована по IP-адресу. Мой отдел занимался автоматизацией производства, и в нем работали электронщики, а я был единственный программист и администратор в одном лице. Доступ в Интернет был разрешен только мне, начальнику отдела и его заместителю. Через несколько часов доступ имели все сотрудники отдела. Как это произошло? Решение очень простое — я поставил на свой компьютер прокси-сервер, к которому могли подключаться без аутентификации мои сослуживцы, а он уже переправлял эти запросы корпоративному proxy. Так как все запросы шли от меня, то главный proxy ничего не заметил.

На первый взгляд решение идеальное, но тут есть один изъян. Да, это поле User Agent, которое становится пустым при прохождении пакетов через мой squid-сервис. Но поле можно задать вручную в конфигурационном файле. Для этого существует директива

fake_user_agent

. Например, следующая строка может эмулировать запросы, как будто они идут от браузера Netscape:

fake_user_agent Netscape/1.0 (CP/M; 8-bit)

9.5.4. Защита сети

Сервис squid может быть как средством защиты сети, так и орудием проникновения хакера в сеть. Чтобы внешние пользователи не могли задействовать прокси-сервер для

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

tcp_incoming_address внутренний_адрес

tcp_outgoing_address внешний_адрес

udp_incoming_address внутренний_адрес

udp_outgoing_address внешний_адрес

В данном случае

внутренний_адрес

— это адрес компьютера с установленным squid, сетевое соединение которого направлено на вашу локальную сеть, а

внешний_адрес

— это адрес сетевого соединения, направленного в Интернет. Если неправильно указать адреса, то хакер сможет подключаться к компьютерам локальной сети, находясь за ее пределами. Вот пример ошибочного конфигурирования squid-сервиса:

tcp_incoming_address внешний_адрес

tcp_outgoing_address внутренний_адрес

udp_incoming_address внешний_адрес

udp_outgoing_address внутренний_адрес

9.5.5. Борьба с баннерами и всплывающими окнами

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

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

Но есть графика, которая надоедает, раздражает и не несет полезной информации, а главное, от нее можно избавиться. Я говорю про баннеры. Давайте рассмотрим, как их можно отключить еще на уровне прокси-сервера. Для этого сначала добавим в файл squid.conf следующие правила:

acl banners_regex url_regex "/usr/etc/banners_regex"

acl banners_path_regex urlpath_regex "/usr/etc/banners_j?ath_regex"

acl banners_exclusion url_regex "/usr/etc/banners_exclusion"

Первая строка создает ACL-список с именем

banners_regex

типа

url_regex

, который позволяет сравнивать полный URL-адрес. В последнем параметре определен файл /usr/etc/banners_regex, в котором будут указываться нужные адреса. Нас интересуют URL баннерных систем, и вы можете поместить их в этот файл.

Вторая строка создает ACL-список с именем

banners_path_regex

типа

urlpath_regex

. В последнем параметре снова указан файл /usr/etc/banners_path_regex, в котором вы должны описывать пути URL, которые впоследствии мы запретим.

Третья строка схожа с первой, но имеет имя

banners_exclusion

и связана с файлом /usr/etc/banners_exclusion. В первых двух файлах вы должны описывать пути или шаблоны, по которым потом будут обрезаться баннеры. Но бывают случаи, когда можно промахнуться и отсечь вполне полезную информацию. Если найден ошибочный путь, то его можно записать в этот файл, и баннер будет загружен.