2.4 Компоненты брандмауэра

Основными компонентами брандмауэра являются:

• политика сетевого доступа
• механизмы усиленной аутентификации
• фильтрация пакетов
• прикладные шлюзы

Следующие разделы описывают более детально каждую из этих компонент.

2.4.1 Политика сетевого доступа

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

Политика доступа к сервисам

Политика доступа к сервисам должна фокусироваться на проблемах использования Интернета, описанных выше, и, судя по всему, на всем доступе к сети извне( то есть политика доступа по модемам, соединений SLIP и PPP). Эта политика должна быть уточнением общей политики организации в отношении защиты информационных ресурсов в организации. Чтобы брандмауэр успешно защищал их, политика доступа к сервисам должна быть реалистичной и согласовываться с заинтересованными лицами перед установкой брандмауэра. Реалистическая политика - это такая политика, в которой найден баланс между защитой сети от известных рисков, но в то же время обеспечен доступ пользователей к сетевым ресурсам. Если система брандмауэра запрещает или ограничивает использование некоторых сервисов, то в политике должна быть явно описана строгость, с которой это делается, чтобы предотвратить изменение параметров средств управления доступом сиюминутным образом. Только поддерживаемая руководством реалистическая политика может обеспечить это.

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

Политика проекта брандмауэра

Она специфична для конкретного брандмауэра. Она определяет правила, используемые для реализации политики доступа к сервисам. Нельзя разрабатывать эту политику, не понимая такие вопросы, как возможности и ограничения брандмауэра, и угрозы и узявимые места, связанные с TCP/IP. Как правило, реализуется одна из двух базовых политик проекта:

1. разрешить доступ для сервиса, если он явно не запрещен
2. запретить доступ для сервиса, если он явно не разрешен

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

Первая политика менее желательна, так как она предоставляет больше способов обойти брандмауэр, например, пользователи могут получить доступ к новым сервисам, не запрещаемым политикой( или даже не указанных в политике), или запустить запрещенные сервисы на нестандартных портах TCP/UDP, которые не запрещены политикой. Определенные сервисы, такие как X Windows , FTP, ARCHIE и RPC, сложно фильтровать [Chap92],[Ches94], и для них лучше подходит брандмауэр, реализующий первую политику. Вторая политика строже и безопаснее, но ее тяжелее реализовать и она может повлиять на работу пользователей в том отношении, что ряд сервисов, такие, как описанные выше, могут оказаться блокированными или использование их будет ограничено.

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

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

2.4.2 Усиленная аутентификация

Разделы 1.3, 1.3.1 и 1.3.2 описывали инциденты в Интернете, произошедшие отчасти из-за уязвимости традиционных паролей. Уже много лет пользователям рекомендуется выбирать такие пароли, которые было бы тяжело угадать и не сообщать их никому. Тем не менее, даже если пользователь следует этому совету( а многие и этого не делают), то тот факт, что злоумышленники могут наблюдать за каналами в Интернете и перехватывать передающиеся в них пароли, делает традиционные пароли устаревшими.

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

Ряд наиболее популярных устройств усиленной аутентификации, используемых сегодня, называются системами с одноразовыми паролями. Смарт-карта, например, генерирует ответ, который хост использует вместо традиционного пароля. Так как смарт-карта работает совместно с программой или оборудованием на хосте, генерируемые ответы уникальны для каждого установления сеанса. Результатом является одноразовый пароль, который, если перехватывается, не может быть использован злоумышленником для установления сеанса с хостом под видом пользователя. [NIST94a] и [NIST91a] более детально описывают устройства усиленной аутентификации и средства защиты на их основе.

Рисунок 2.2 Использование усиленной аутентификации в брандмауэре для предварительной аутентификации трафика TELNET, FTP

Так как брандмауэры могут централизовать управление доступом в сети, они являются логичным местом для установки программ или устройств усиленной аутентификации. Хотя меры усиленной аутентификации могут использоваться на каждом хосте, более практичным является их размещение на брандмауэре. Рисунок 2.2 показывает, что в сети без брандмауэра, использующего меры усиленной аутентификации, неаутентифицированный траффик таких приложений как TELNET или FTP, может напрямую проходить к системам в сети. Если хосты не используют мер усиленной аутентификации, злоумышленник может попытаться взломать пароли или перехватывать сетевой трафик с целью найти в нем сеансы, в ходе которых передаются пароли. Рисунок 2.2 также показывает сеть с брандмауэром, использующим усиленную аутентификацию, при которой сеансы TELNET или FTP, устанавливаемые со стороны Интернета с системами сети, должны проходить проверку с помощью усиленной аутентификации перед началом работы. Сами системы сети могут продолжать требовать статические пароли перед доступом к себе, но эти пароли нельзя будет использовать, даже если их перехватить, так как меры усиленной аутентификации и другие компоненты брандмауэра не позволят злоумышленнику проникнуть или обойти брандмауэр.

Части 2.4.4 и 3 содержат дополнительную информацию об использовании мер усиленной аутентификации с брандмауэрами. Смотри [NIST94b] для получения более подробной информации об использовании мер усиленной аутентификации на хостах.

2.4.3 Фильтрация пакетов

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

• IP-адрес отправителя
• IP-адрес получателя
• TCP/UDP-порт отправителя
• TCP/UDP-порт получателя

Не все фильтрующие маршрутизаторы сейчас фильтруют по TCP/UDP-порту отправителя, но многие производители начали включать такую возможность. Некоторые маршрутизаторы проверяют, с какого сетевого интерфейса маршрутизатора пришел пакет, и затем используют эту информацию как дополнительный критерий фильтрации. Некоторые версии Unix имеют возможность фильтрации пакетов, но далеко не все.

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

Добавление фильтрации по портам TCP и UDP к фильтрации по IP-адресам дает большую гибкость. Напомним главу 1, в которой говорилось, что сервера, такие как демон TELNET, связаны обычно с конкретными портами, такими как порт 23 для TELNET. Если брандмауэр может блокировать соединения TCP или UDP к или от определенных портов, то можно реализовать политику, при которой определенные виды соединений могут быть осуществлены только с конкретными хостами, но не с другими. Например, организация может захотеть блокировать все входящие соединения для всех хостов, кроме нескольких систем, входящих в состав брандмауэра. Для этих систем могут быть разрешены только определенные сервисы, такие как SMTP для одной системы, и TELNET или FTP для другой. При фильтрации по портам TCP и UDP эта политика может быть легко реализована маршрутизатором с фильтрацией пакетов или хостом с возможностью фильтрации пакетов.

Рисунок 2.3 Пример фильтрации пакетов для TELNET и SMTP

Для примера рассмотрим политику, в которой разрешаются только определенные соединения с сетью с адресом 123.4.*.* Соединения TELNET разрешаются только с одним хостом, 123.4.5.6, который может быть прикладным TELNET-шлюзом сети, а SMTP-соединения разрешаются только с двумя хостами, 123.4.5.7 и 123.4.5.8, которые могут быть двумя почтовыми шлюзами сети. NNTP(Network News Transfer Protocol) разрешается только от взаимодействующего с сетью сервера новостей, 129.6.48.254, и только с NNTP-сервером сети, 123.4.5.9, а протокол NTP(сетевого времени) разрешен для всех хостов. Все другие сервисы и пакеты блокируются. Пример набора правил приведен ниже:

Тип	Адрес отправителя	Адрес получателя	Порт источника	Порт получателя	Действие
tcp	*	123.4.5.6	>1023	23	разрешить
tcp	*	123.4.5.7	>1023	25	разрешить
tcp	*	123.4.5.8	>1023	25	разрешить
tcp	129.6.48.254	123.4.5.9	>1023	119	разрешить
udp	*	123.4.*.*	>1023	123	разрешить
*	*	*	*	*	запретить

Первое правило позволяет пропускать пакеты TCP из Интернета от любого источника, имеющие порт отправителя больше чем 1023, к адресу 123.4.5.6, если соединение устанавливается с портом 23. Порт 23 - это порт, связанный с сервером TELNETa, а все клиенты TELNETа должны использовать непривилегированные порты больше, чем 1024. Второе и третье правило работают аналогично, кроме того, что разрешаются адреса назначения 123.4.5.7 и 123.4.5.8 и порт 25 - SMTP. Четвертое правило пропускает пакеты к NNTP-серверу сети, но только от адреса 129.6.48.254 к адресу 123.4.5.9 с портом назначения 119( 129.6.48.254 - единственный NNTP-сервер, от которого сеть получает новости, поэтому доступ к сети в отношении NNTP ограничен только этой системой). Пятое правило разрешает траффик NTP, который использует UDP, а не TCP, от любого источника к любой системе в сети. Наконец, шестое правило блокирует все остальные пакеты - если этого правила не было бы, маршрутизатор мог блокировать, а мог и не блокировать другие тиы пакетов. Это очень простой пример фильтрации пакетов. Настоящие правила позволяют осуществить более сложную фильтрацию и являются более гибкими.

Какие протоколы фильтровать

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

• Tftp, порт 69, упрощенный FTP, используемый для загрузки ОС на бездисковых рабочих станциях, терминальных серверах и маршрутизаторах, может также быть использован для чтения любого файла в системе при его неправильной установке.
• X Windows, Open Windows , порты 6000+, порт 2000, может использоваться для перехвата изображения окон X-окон, а также вводимых символов.
• RPC , порт 111, службы вызова удаленных процедур, включая NIS и NFS, которые могут использоваться для кражи системной информации, включая пароли, а также чтения и записи файлов
• rlogin, rsh, rexec, порты 513, 514, 512, службы, которые могут при их неправильной конфигурации привести к неавторизованному доступу в систему

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

• TELNET, порт 23, часто разрешается только для отдельных систем
• FTP, порты 20 и 21, аналогично TELNET его использование разрешено только для отдельных систем
• SMTP, порт 25, часто разрешается только для центрального почтового сервера
• RIP, порт 520, протокол передачи информации о маршрутизации пакетов, может быть фальсифицирован для перенаправления пакетов
• DNS, порт 53
• UUCP, порт 540, UNIX-to-UNIX CoPy, при неправильной конфигурации может быть использован для получения неавторизованного доступа
• NNTP, порт 119, протокол передачи сетевых новостей, для доступа и чтения сетевых новостей
• Gopher, http, порты 70 и 80,

Проблемы с маршрутизаторами с фильтрацией пакетов

Маршрутизаторы с фильтрацией пакетов имеют ряд недостатков, описанных в [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], в котором дано более детально описание фильтрации пакетов и связанных с ней проблем. Хотя фильтрация пакетов очень важна, нужно знать существующие проблемы и пути их решения.

2.4.4 Прикладные шлюзы

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

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

• сначала пользователь устанавливает telnet-соединение с прикладным шлюзом и вводит имя внутреннего хоста
• шлюз проверяет IP-адрес пользователя и разрешает или запрещает соединение в соответствии с тем или иным критерием доступа
• может понадобиться аутентификация пользователя(возможно с помощью одноразовых паролей)
• прокси-сервер создает telnet-соединение между шлюзом и внутренним хостом
• прокси-сервер передает данные между этими двумя соединениями
• прикладной шлюз протоколирует соединение

Рисунок 2.4 Виртуальные соединения, реализуемые с помощью прикладного шлюза и прокси-средств

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

Другим преимуществом использования прокси-служб является то, что может быть осуществлена фильтрация протоколов. Например, некоторые брандмауэры, могут фильтровать ftp-соединения и запрещать использование команды FTP put, что было бы полезно для получения гарантий того, что пользователи не могут, например, писать на анонимный FTP-сервер.

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

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

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

Помимо TELNET, обычно прикладные шлюзы используются для FTP и электронной почты, а также X Windows и ряда других служб. Некоторые прикладные шлюзы FTP имеют возможности блокирования команд get и put для некоторых хостов. Например, внешний пользователь, установивший FTP-сеанс(через прикладной шлюз FTP) с внутренней системой, такой, как анонимный FTP-сервер, может попытаться скопировать файлы на сервер. Прикладной шлюз может фильтровать FTP-протокол и блокировать все команды put для анонимного FTP-сервера; это позволит гарантировать, что никто не сможет загрузить на сервер чего-либо, и даст большие гарантии, чем простая уверенность в том, что права доступа к файлам на анонимном FTP-сервере установлены корректно( некоторые организации ввели политики, в которых запрещаются команды get и put для определенных директорий; наличие брандмауэра, фильтрующего FTP-команды, было бы особенно полезно в этой ситуации. Некоторые места запретили команды get для внешних хостов, чтобы пользователи не могли считать информацию или программы с внешних хостов. В других же сетях запрещена команда put для внешних хостов, чтобы пользователи не могли сохранить локальную информацию на внешних FTP-серверах. Но типовым является вариант. Когда запрещаются входящие команды put, чтобы внешние пользователи не могли писать на FTP-сервера в сети)

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

Шлюзы транспортного уровня

[Ches94] описывает другую компоненту брандмауэра, которую другие авторы иногда включают в категорию прикладных шлюзов. Шлюз транспортного уровня пропускает через себя TCP-соединения, но не делает никакой фильтрации протокола. Например, описанный выше пример прикладного шлюза TELNET может служить примером шлюза транспортного уровня, так как после установления соединения между источником и назначением брандмауэр просто передает поток данных между этими двумя системами. Другим примером шлюза транспортного уровня может быть шлюз для NNTP, в котором NNTP-сервер соединяется с брандмауэром, а затем - с внутренней системой через брандмауэр. Здесь брандмауэр просто передает поток данных.