Перенаправление портов

Пример из жизни. Пакетные фильтры, порты и проблемы

Основные пакетные фильтры разрешают или запрещают сетевой трафик, основываясь на IP-адресах и номерах портов. ipchains системы Linux и маршрутизаторы Cisco (минус "установленные" возможности) являются хорошими примерами устройств фильтрации пакетов. Они исследуют только четыре части TCP/IP-пакета.

• IP-адрес отправителя.
• Порт отправителя.
• IP-адрес получателя.
• Порт получателя.

Вы можете создать строгие правила, основанные на этих комбинациях. Например, так как Web-сервер должен получать трафик только через порты 80 и 443, администратор создает правила ipchains для исследования трафика, прибывающего из интернета, и разрешения проходить только такому трафику, который идет к TCP-портам получателя с номерами 80 и 443. При этом, например, доступ к порту получателя с номером 22 (протокол Secure Shell), будет блокирован. Обратите внимание на следующее различие. Если администратор откроет только TCP-порты 80 и 443, возникнет потенциальная проблема: что случится, когда прибывает пакет с порта отправителя с номером 80? Пакет проходит через брандмауэр в зависимости от порядка правил ipchains. Далее, что произойдет, если этот пакет имеет порт отправителя 80 и порт получателя 22? Произойдет неправомочный доступ к командной строке протокола Secure Shell!

Проблемы порта отправителя неожиданно возникают в нескольких службах. Начнем с упоминания службы FTP, которая, вероятно, является наиболее печально известной службой. Подключение FTP начинается прекрасно. Клиент подключается к серверу через порт 21. Затем возникают сложности. Если клиент начинает загружать файл, сервер инициирует передачу данных клиенту через порт 20. Тип пакета, который создает подключение, называется SYN-пакетом (в соответствии с типом флага, который содержит пакет). При передаче данных по FTP, сервер посылает SYN-пакет, и клиент поддерживает подключение. Пакетные фильтры исследуют SYN-пакеты, чтобы применить к ним свои правила. Следовательно, пакетный фильтр может запутаться в том, какая система запустила FTP-подключение, потому что трафик порождается во внутренней сети, а не в интернете. Во многих случаях, администраторы разрешают трафику с порта 20 входить в сеть, но забывают ограничить трафик, входящий на FTP-сервер.

Другими проблематичными службами являются также служба доменных имен DNS (Domain Name System), протокол SMTP (Server Message Transfer Protocol) и протоколы IPsec (Internet Protocol Security) и Kerberos. Службы DNS выполняются через TCP- и UDP-порт 53. Для разрешения имен доменов необходим только UDP-порт (хотя порт TCP иногда используется для поиска в больших пространствах имен). Однако если существует путаница в том, какие хосты требуют разрешения имен, внутренние или хосты интернета, TCP-порт 53 может оказаться открытым для всего мира.

Все пользуются серверами электронной почты и SMTP для уверенности в получении электронной почты. Сервер SMTP использует для получения электронной почты TCP-порт получателя 25, но вполне возможно, что правила брандмауэра по ошибке откроют порт 25 (для отправителя или получателя). Kerberos ни в коем случае не является новым протоколом, его использование возродилось в результате включения его в Windows 2000 подобно Франкенштейну. Теперь системные администраторы Windows могут устанавливать более безопасную зашифрованную связь, используя TCP-порт 88 и протокол IPsec. Порт 88 также подвергается путанице в определении отправителя/получателя.

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

C:\>fpipe -l 3389 -r 3389 -s 20 192.168.0.116

К сожалению, утилита datapipe не поддерживает опцию для изменения порта отправителя, но, по крайней мере, вы имеете исходный код утилиты!

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

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

• Защита хоста. Очевидно, что если взломщик не может получить доступ к командной строке в системе, инструмент перенаправления порта не может использоваться для обхода списков управления доступом. Часть мантры, повторяемой любым системным администратором, должна быть следующей: "ставь заплаты, конфигурируй, проверяй".
• Фильтры доступа. Сильный брандмауэр или список управления доступом маршрутизатора должен начинаться с правила "все запрещено". Затем добавляются порты и службы по мере того, как они требуются для деловых целей. Кроме того, порты не должны открываться с доступом типа "карт-бланш". Порты 80 и 443 должны открываться только для Web-серверов, порт 25 нужно открывать только для серверов электронной почты.
• Выходные фильтры. Открытые серверы типа Web-серверов, всегда получают трафик. То есть Web-сервер не предугадывает, что вы хотите соединиться с ним, и переслать его домашнюю страницу на свой броузер; вы должны обратиться к нему. Из этого, естественно, следует, что Web-сервер никогда не должен устанавливать подключение, выходящее во внешнюю сеть (в интернет). Он должен получать трафик через порт 80, но сетевое устройство должно блокировать любые попытки подключения с Web-сервера на любой хост интернета.

Вы должны также избегать неправильных взаимных правил. Если ваша сеть использует Ipsec-туннелирование по порту TCP 88, вы должны гарантировать, что правила подключений имеют смысл. Например, неверное правило может выглядеть так (в псевдокоде):

allow (src ip ANY) and (tcp port 88)

Это правило позволяет любому пакету с IP-адресом, имеющим порт отправителя или порт получателя с номером 88, входить в сеть. Таким образом, этот набор правил разрешил бы пакету, имеющему порт отправителя 88 и порт получателя 139 (например) пересекать сеть. Корректное правило должно разрешать трафик к Ipsec-порту:

allow (src ip ANY) and (dst tcp port 88)

Помните, что данный тип проблемы также часто обнаруживается в службах FTP, SMTP и DNS.