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

Большинство компаний, которые подключены к интернету, имеют свой собственный почтовый сервер, который принимает почту от других таких же почтовых серверов. Этот сервер должен быть доступен для подключения из любой точки интернета, поскольку невозможно предсказать, кто пришлёт следующее письмо, которое, как известно, принимается через прямое подключение к серверу компании по протоколу SMTP (Simple Mail Transport Protocol). Получается, что, с одной стороны, необходимо обеспечить безопасность почтового сервера, т.е. максимально ограничить несанкционированные подключения, с другой, нужно сделать его максимально доступным из интернета. Серверы, которые должны принимать соединения без проведения аутентификации, принято называть "публичными", т.е. доступными для любого пользователя глобальной Сети. Подход к построению систем, включающих в себя публичные серверы, должен быть иным, нежели подход к построению систем на базе внутренних серверов. Диктуется это специфическими рисками, которые возникают из-за публичной доступности сервера.

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

Как правило, начинающие администраторы устанавливают всего один почтовый сервер, который доступен из интернета и хранит почтовые ящики внутренних пользователей. Такая схема является самой дешёвой, но и самой уязвимой из возможных. Угроза заключается в том, что если хакеру удастся взломать почтовый сервер, то он не только получит полный доступ к хранящейся на нём почте, но и прямой доступ к локальной сети, в которой может присутствовать масса уязвимостей, созданных самими пользователями либо недосмотром администратора. Ведь внутренняя сеть кажется такой безопасной, что, порой, даже опытные администраторы закрывают глаза на некоторые недоработки в безопасности внутренней сети. Самая распространённая рукотворная уязвимость в сетях, построенных на технологиях от Microsoft, - это сетевые папки со слишком широко заданными правами доступа. Как правило, неопытные пользователи создают такие папки на своём компьютере с правами полного доступа "для всех". В таких сетевых папках хакер может не только получить доступ ко внутренним документам компании, но и уничтожить их, что в определённых случаях является огромной потерей. И это всего лишь одна из потенциальных серьёзных уязвимостей в локальной сети, которую сложно проконтролировать.

Если же ваша внутренняя сеть построена на концентраторах (хабах, hub), а не на коммутаторах (свитчах, switch), то она являет собой одну большую уязвимость. Если хакер в такой сети получит контроль хотя бы над одним из компьютеров, то он получит полный доступ ко всей информации, циркулирующей в вашей сети. Кража паролей - это самое безобидное из того, что позволяет делать сеть, построенная на концентраторах.

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

Для разделения внутренней и публичной сетей есть проверенное решение, которое широко используют профессионалы в области сетевой безопасности - это Демилитаризованная Зона (DMZ - Demilitarized Zone). Суть этого решения заключается в таком сетевом расположении публичных серверов, чтобы оно не допускало бесконтрольного установления соединений в локальную сеть с любого из этих серверов. Даже в том случае, если хакер сможет захватить контроль над одним из них, например, использовав новую уязвимость в ПО, то он не сможет получить бесконтрольный доступ во внутреннюю сеть. Суть такого решения заключается в почти полной изоляции публичных серверов от локальной сети, но лишь для соединений, исходящих с этих серверов, поскольку эти соединения могут быть инициированы хакером, захватившим контроль. Однако, сами серверы должны оставаться доступны для соединений, инициированных как из интернета, так и из локальной сети.

Другая опасность, которую могут представлять публичные серверы для локальной сети, - это возможность их использования как плацдарма для атак типа DOS (Denial Of Service - "Отказ в обслуживании"). В этом случае проблема заключается в том, что пропускная способность соединения между публичными серверами компании и локальной сетью в сотни раз выше пропускной способности канала в интернет, что предоставляет очень широкий канал для потока вредоносных DOS-пакетов. Другими словами, попав на ваш публичный сервер, хакер может "завалить" ваши внутренние серверы таким количеством вредоносных пакетов, от которого они выйдут из строя, как минимум, на определённое время.

DMZ - это превентивная мера против хакеров, которая не позволит им получить бесконтрольный доступ к локальной сети, взломав один из публичных серверов.

На практике DMZ выполняется как отдельная IP-подсеть с публичными адресами, вынесенная в отдельный сегмент сети (см. рис.), который физически либо с помощью технологии VLAN (Virtual Local Area Network) отделён от локальной сети предприятия.

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

Сам маршрутизатор стоит рассматривать как один из публичных серверов и распространять на него аналогичную политику безопасности как и на публичные серверы. И нужно помнить, что в случае взлома маршрутизатора никакая политика DMZ не поможет - хакер получит доступ в вашу внутреннюю сеть. Так что особое внимание при построении публичной сети стоит уделить безопасности маршрутизатора.

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

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

"Обесценить" информацию на серверах в DMZ - задача не тривиальная и в значительной степени зависит от типа сервера. Как правило, требуется индивидуальное решение по каждому такому публичному серверу. Однако есть несколько общих рекомендаций по почтовым и web-серверам - так, для почтовых серверов нужно применять, как минимум, двухсерверную модель обслуживания, а для web-серверов вести постоянный мониторинг состояния информации для своевременного обнаружения и устранения последствий взлома. Как аксиому, можно принять и то, что на серверах в DMZ не должно быть никаких баз данных, содержащих ценные сведения, как то: базы данных по пользователям или по клиентам компании. Не стоит размещать на публичных серверах и почтовые ящики пользователей - зачастую внутренняя переписка - это самая ценная информация, которая есть в компании, потерять её равносильно пожару в центральном офисе.

Если для функционирования web-сервера требуется база данных, то стоит разделить web-сервис на два сервера - на первом, публичном, который будет располагаться в DMZ, будет работать HTTP-сервер, на втором, внутреннем, находящемся в локальной сети, будет располагаться база данных. При этом доступ с публичного HTTP-сервера на сервер с базой данных должен быть ограничен одним единственным портом, по которому будет производиться подключение к базе данных. Вся остальная локальная сеть при этом будет недоступна с публичного HTTP-сервера.

Аналогичное решение применяется и для почты - публичный сервер принимает почту и передаёт её на внутренний почтовый сервер. Любые другие попытки соединения во внутреннюю сеть будут пересечены. В качестве дополнительной задачи на публичный почтовый сервер можно возложить сканирование почты на предмет присутствия вирусов и опасных вложений.

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

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

В заключение хочется отметить, что правильно построенная сеть не отменяет необходимости периодического аудита безопасности и установки заплаток на выявленные уязвимости в сетевом ПО.

© 2002 Алексей ГРЕЧАНИНОВ