Безопасность на сетевом уровне

Proxy-сервисы

Здесь выбор, по большому счёту, невелик, и его приходится делать между Squid, Oops и модулем для сервера Apache. Если всё же останавливаться на специализированных для выполнения функций прокси-сервера программах, то остаётся выбирать между Squid и Oops.

Squid-сервер, несомненно, весьма мощный, с большим количеством возможностей, однако по параметрам безопасности выгоднее смотрится сервер Oops. Этот сервер уже давно не имел проблем безопасности (поскольку написан, как все описываемые здесь программы, с учётом требований безопасности), да и по потреблению системных ресурсов он выигрывает у Squid без уменьшения возможностей и качества работы.

Кроме того что на сервере установлено специальным образом «пропатченное» ядро, безопасные сетевые сервисы, не помешает ещё озаботиться и безопасностью на уровне самого протокола TCP/IP, для чего обратимся к файрволу, стандартно идущему с системой (ниже будут даны правила ipchains, для ветки ядер 2.2.x).

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

Хорошим началом можно считать правило, запрещающее все входящие пакеты; впоследствии уже разрешается только то, что необходимо:

ipchains -P input DENY

ipchains -O output REJECT

ipchains -P forward REJECT

Далее даётся разрешение на свободный трафик по «кольцевому» интерфейсу lo0 и идёт серия запрещающих (точнее фильтрующих) правил для внутренней сети – запрет явно фальсифицированных пакетов (например, пакеты, пришедшие с внешнего интерфейса, но имеющие в качестве исходного адреса внутренний), и серия для протокола ICMP. По большому счёту, все пакеты этого протокола можно запретить, но при грамотной фильтрации можно оставить пакеты третьего, четвёртого, восьмого, одиннадцатого и двенадцатого типов, которые будут полезны для диагностирования ошибок.

Дальше идёт последовательное расписывание правил для каждого сервиса, что в общем случае будет выглядеть так (дан вариант для HTTP- сервиса, другие сервисы, например DNS, могут иметь более сложную структуру):

#client

ipchains -A output -i

$EXTERNAL_INTERFACE -p tcp -s $IPADDR

$UNPRIVPORTS -d

$ANYWHERE 80 -j ACCEPT

ipchains -A input -i

$EXTERNAL_INTERFACE -p tcp ! -y -s

$ANYWHERE 80 -d $IPADDR

$UNPRIVPORTS -j ACCEPT

#server

ipchains -A input -i

$EXTERNAL_INTERFACE -p tcp -s $ANYWHERE

$UNPRIVPORTS -d

$IPADDR 80 -j ACCEPT

ipchains -A output -i

$EXTERNAL_INTERFACE -p tcp ! -y -s $IPADDR

80 -d $ANYWHERE

$UNPRIVPORTS -j ACCEPT

где $EXTERNAL_INTERFACE — название интерфейса, обращённого к внешней сети,

$IPADDR — адрес сервера,

$ANYWHERE — любой возможный адрес сети,

$UNPRIVPORTS — номера непривилегированных портов (с 1024 по 65535).

Обычно также разрешается неограниченный трафик внутри локальной сети и входящие запросы от провайдера.

Итого

С помощью всех вышеописанных шагов сетевая часть сервера была сделана более безопасной, однако же остаётся ещё много проблем: во-первых, постоянное отслеживание событий безопасности; а во-вторых, локальная безопасность, ведь у пользователя, имеющего регистрацию в системе, есть под рукой гораздо большее количество программ, чем только те, что были оставлены администратором для сетевого пользования, а потому и больше шансов на компрометацию системы. Часть проблем локального характера снимается вышеуказанными патчами на ядро, ещё часть проблем можно снять, удалив всё ненужное с сервера (например, первыми кандидатами можно назвать всевозможные игры). Всё остальное нужно только регулярно отслеживать, проверяя журналы регистрации (модифицированное таким образом ядро и грамотно настроенные программы будут оставлять много интересных записей в журналах).

Александр Потёмкин