Иллюстрированный самоучитель по разработке безопасности

Подход к Internet

Разрешенные вспомогательные процедуры

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

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

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

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

Таблица 6.1. Вспомогательные системы, рассматриваемые при разработке правил.

Разработка правил такого типа сводится к тому, что вам необходимо понять вспомогательные процедуры и их воздействие на процессы, прежде чем начинать разбираться, в каком виде они должны быть отражены в правилах. Например, появляется искушение ограничить доступ к процедурам протокола пользовательских дейтаграмм (UDP – User Datagram Protocol) в сети. Многие организации это делают, поскольку UDP является протоколом, не требующим установления соединения, который сложно контролировать и тем более управлять им. Однако, если сервер, обслуживающий службы именования доменов, размещен после брандмауэра, то нужно подкорректировать правила так, чтобы был разрешен доступ пользователям Internet к порту 53 UDP для распознавания адресов имен доменов вашей организации. Формулировка правила может выглядеть следующим образом.

Шлюз Internet должен предотвращать пропуск UDP-пакетов из Internet в сеть организации ЗА ИСКЛЮЧЕНИЕМ UDP-пакетов, запрашивающих общедоступные службы именования доменов, доступных на порте 53.

Отметим, что такая формулировка правил предназначена для "входящих" процедур, поскольку в ней сказано "из Internet в сеть организации". Она не накладывает ограничений на исходящие процедуры. Как правило, в организации стараются не обращать внимание на то, каким образом их пользователи получают доступ к исходящим процедурам. Однако, при такой формулировке правил ответы внешних UDP-систем, направленные пользователям организации, будут блокироваться. Это не всегда плохо, но если работа организации с клиентами зависит от таких служб, как сетевая файловая система (NFS – Network File System), или других служб, обслуживающих сетевые имена, то придется откорректировать правила, чтобы обеспечить работу этих служб.

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

Другая проблематичная область политики заключается в разработке правил использования протокола управления сообщениями в сети Internet (ICMP – Internet Control Message Protocol). ICMP используется для передачи сообщений об ошибках между компонентами сети. ICMP передается на уровне IP и используется только между компонентами сети. Можно зафиксировать работу ICMP с помощью программ типа ping и traceroute (или tracert). Однако, эти сообщения об ошибках можно использовать для составления карты сети, определения того, работает ли система и доступна ли она из сети, а также они могут представлять и другие интересные сведения для потенциального взломщика (см. "ICMP-вторжения").

Проблема, связанная с использованием ICMP, заключается в том, что после того, как вы узнали о проблеме, появляется желание написать правило блокирования ICMP на брандмауэре. При осуществлении данного желания теряется возможность получения ICMP-сообщений host unreachable (недоступный хост) и need to frag (необходимо разбиение). Для управления исходящим трафиком организации необходимо иметь возможность получать эти сообщения. Ввиду сложности таких решений рекомендуется не включать эти вопросы в документы, определяющие политику. Однако, если есть желание упомянуть об этом, то можно составить следующую формулировку.

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