Решение о том, какие протоколы или группы портов фильтровать, зависит от политики сетевого доступа, то есть от того, какие системы должны иметь доступ к Интернету и какие типы доступа разрешены. Описанные ниже сервисы потенциально уязвимы к атакам и обычно блокируются на брандмауэре при входе в сеть или выходе из нее[Chap92],[Garf92].
Ряд других средств также обычно фильтруется или их использование разрешается только для тех систем, которым они на самом деле нужны. В это список входят:
Хотя некоторые из этих служб, такие как TELNET и FTP, являются опасными по своей сути, полное блокирование доступа к другим может оказаться неприемлемым для многих организаций. Тем не менее, не все системы требуют доступа ко всем службам. Например, разрешение доступа по TELNET и FTP из Интернета только к тем системам, которым нужен этот вид доступа, может улучшить безопасность, не причиняя неудобства пользователям. Такие службы, как NNTP, на первый взгляд не представляют особой опасности, но разрешение этих служб только для тех систем, которым они нужны, поможет создать более упорядоченную сетевую среду и уменьшит вероятность их использования атакующими из-за еще неизвестных уязвимых мест.
Маршрутизаторы с фильтрацией пакетов имеют ряд недостатков, описанных в [Chap92]. Правила фильтрации пакетов сложно формулируются и обычно нет средств для тестирования их корректности( кроме как ручное тестирование). У некоторых маршрутизаторов нет средств протоколирования, поэтому если правила фильтрации пакетов все-таки позволят опасным пакетам пройти маршрутизатора, такие пакеты не смогут быть выявлены до обнаружения проникновения.
Часто требуется сделать исключения из правил, чтобы разрешить определенные виды доступа, которые обычно блокируются. Но исключения из правил фильтрации иногда могут сделать правила фильтрации такими сложными, что они станут неконтролируемыми. Например, достаточно просто написать правило для блокирования всех входящих соединений к порту 23( серверу TELNETa). Если же делаются исключения, то есть если с некоторыми системами сети разрешается иметь прямые соединения по TELNET, то должно быть добавлено правило для каждой такой системы. Иногда добавление определенных правил может усложнить всю схему фильтрации. Как было уже сказано, тестирование сложного набора правил на их корректность может оказаться очень трудным.
Некоторые маршрутизаторы с фильтрацией пакетов не фильтруют по порту TCP/UDP отправителя, что может сделать набор правил фильтрации очень сложным и создать "дыры" в схеме фильтрации. [Chap92] описывает подобные проблемы с сетями, в которых были разрешены входящие и исходящие SMTP-соединения . Согласно пункту 1.2.5, TCP-соединения имеют порт отправителя и порт получателя. Если система инициирует SMTP-соединение с сервером, портом источника будет случайно выбранный порт с номером больше 1024, а портом получателя будет будет порт с номером 25, порт, который слушает сервер SMTP. Сервер будет возвращать пакеты с номером порта отправителя 25, и номером порта получателя, равным случайно выбранному клиентом номеру порта. Если в сети разрешены входящие и исходящие SMTP-соединения, то маршрутизатор должен разрешать соединения с портами отправителя и получателя, большими 1023, в обоих направлениях. Если маршрутизатор может фильтровать по порту отправителя, он может блокировать все пакеты, входящие в сеть организации, у которых порт получателя больше 1023, а порт отправителя не равен 25. Если он не может фильтровать пакеты по порту отправителя, маршрутизатор должен разрешить соединения, которые используют порты отправителя и получателя больше 1024. Пользователи иногда могут специально запустить сервера на портах, больших 1023, и обходить таким образом политику фильтрации( то есть обычно сервер telnet в системе слушает порт 23, но может быть сконфигурирован так, что будет слушать вместо этого порт 9876; и пользователи в Интернете смогут организовать telnet-сеанс с этим сервером даже, если маршрутизатор блокирует соединения с портом назначения 23).
Другой проблемой является то, что ряд служб RPC очень трудно заблокировать из-за того, что сервера для этих служб слушают порты, случайно выбираемые в процессе загрузки системы. Служба, известная под названием portmapper отображает первоначальные вызовы служб RPC в назначенные им номера служб, но ее эквивалента не существует для маршрутизатора с фильтрацией пакетов. Так как маршрутизатору нельзя сообщить, с каким портом работает служба, нельзя полностью заблокировать эти службы, разве что заблокировать полностью все пакеты UDP( RPC-службы в-основном используют UDP). Блокирование всех пакетов UDP приведет к блокированию ряда других полезных служб, таких как DNS. Поэтому блокирование RPC приводит к дилемме.
Маршрутизаторы с фильтрацией пакетов с более чем двумя интерфейсами иногда не имеют возможностей по фильтрации пакетов в зависимости от того, с какого интерфейса приняты пакеты, и куда должны быть направлены. Фильтрация входящих и исходящих пакетов упрощает правила фильтрации пакетов и позволяет маршрутизатору легко определить, какой IP-адрес настоящий, а какой - фальшивый. Маршрутизаторы без такой возможности затрудняют реализацию стратегий фильтрации.
Кроме того, маршрутизаторы с фильтрацией пакетов могут реализовывать обе концептуальные стратегии, описанные в пункте 2.4.1. Набор правил, который менее гибок, то есть не фильтрует по порту отправителя или по типу интерфейса( входящий или выходящий), уменьшает возможности маршрутизатора по претворению в жизнь второй и более сильной политики, при которой запрещаются все сервисы, кроме тех, что явно разрешены. Например, проблематичные службы, такие, как те, которые базируются на RPC, становится еще труднее фильтровать с менее гибким набором правил; отсутствие фильтрации по порту отправителя заставляет разрешать соединения с портами, большими 1023. При менее гибком наборе правил маршрутизатор имеет меньше возможностей по реализации сильной политики, и поэтому обычно используют первую политику - разрешать все средства, кроме тех, что явно запрещены.
Читателям рекомендуется прочитать [Chap92], в котором дано более детально описание фильтрации пакетов и связанных с ней проблем. Хотя фильтрация пакетов очень важна, нужно знать существующие проблемы и пути их решения.
Чтобы защититься от ряд уязвимых мест, связанных с маршрутизаторами с фильтрацией пакетов, в брандмауэрах нужно использовать прикладные программы для перенаправления и фильтрации соединений с такими службами, как TELNET и FTP. Такое приложение называется прокси-службой, а хост, на котором работает прокси-служба - прикладным шлюзом. Прикладные шлюзы и маршрутизаторы с фильтрацией пакетов могут быть объединены для достижения более высокой безопасности и гибкости, чем была бы достигнута, если бы они использовались отдельно.
Например, рассмотрим сеть, в которой блокируются входящие соединения TELNET и FTP с помощью маршрутизатора с фильтрацией пакетов. Этот маршрутизатор позволяет пропускать пакеты TELNET или FTP только к одной машине, прикладному шлюзу TELNET/FTP. Пользователь, который хочет соединиться снаружи с системой в сети, должен сначала соединиться с прикладным шлюзом, а затем уж с нужным хостом :