Должен ли брандмауэр веб-сервера блокировать исходящий HTTP-трафик через порт 80? - PullRequest
5 голосов
/ 03 апреля 2009

Я понимаю необходимость помещения веб-сервера в демилитаризованную зону и блокирования входящего трафика на все порты, кроме 80 и 443. Я также понимаю, почему, вероятно, следует также блокировать большую часть исходящего трафика в случае взлома сервера.

Но нужно ли блокировать исходящий HTTP-трафик через порт 80? Если так, то почему? Многие веб-приложения в наши дни полагаются на отправку / извлечение данных из внешних веб-сервисов и API-интерфейсов, поэтому блокирование исходящего трафика через порт 80 предотвратит эту возможность. Существует ли проблема безопасности, которая является достаточно обоснованной, чтобы это оправдать?

Ответы [ 7 ]

7 голосов
/ 03 апреля 2009

Единственная причина, по которой я могу придумать, заключается в том, что если ваша машина каким-то образом скомпрометирована удаленно, то она не сможет DDoS для другого веб-сайта на порту 80. Хотя я обычно не делаю это.

0 голосов
/ 21 июня 2017

Если машина скомпрометирована и разрешен исходящий трафик через порт 80, злоумышленникам будет легче отправлять собранные данные себе. Разрешение исходящего трафика означает, что вы можете инициировать соединение со своей машины с внешним миром. Лучшим подходом будет разрешить исходящий трафик только на определенные веб-сайты / адреса, которым вы доверяете (например, Microsoft Windows Update, Google reCAPTCHA), а не на любой пункт назначения в мире.

0 голосов
/ 01 июня 2016

Во-первых, я согласен с @vartec в вопросе регулирования «Скорее блокировать, регулировать. Использовать iptables -m limit» как минимум как часть решения.

Однако я могу предложить другую причину, чтобы не блокировать исходящий порт 80 постоянно. Если у вас включены автоматические обновления безопасности, сервер не может обратиться к PPA через порт 80 для запуска обновления безопасности. Таким образом, если у вас установлены автоматические обновления безопасности, они не будут запускаться. В Ubuntu обновления для автоматической безопасности включены в 14.04 LTS с:

 sudo apt-get install unattended-upgrades update-notifier-common && \
 sudo dpkg-reconfigure -plow unattended-upgrades
 (then select "YES")

Более изящными решениями были бы доступные сценарии, открывающие порт автоматически, возможно также изменяющие правило группы безопасности AWS через CLI в дополнение к iptables, если вы находитесь в AWS. Я предпочитаю временно изменять свои исходящие правила через интерфейс командной строки AWS, инициированный стелс-боксом. Это вынуждает регистрировать обновление в моих журналах AWS S3, но никогда не отображается в журналах на самом сервере. Кроме того, сервер, который инициирует обновление, даже не должен находиться в ACL частной подсети.

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

Надеюсь, это поможет. Если нет, ответьте и предоставьте больше примеров кода, чтобы быть более конкретными и точными. #staysafe!

0 голосов
/ 03 апреля 2009

В зависимости от версии SQL у вас могут быть проблемы с истечением времени проверки подлинности сертификата с SQL Server 2005.

0 голосов
/ 03 апреля 2009

У меня есть несколько веб-приложений, которые вызывают внешние веб-службы, поэтому я бы сказал, что блокировать выходной HTTP-трафик - плохая идея. Если вы беспокоитесь о безопасности, вы можете заблокировать ее и разрешить только определенные пункты назначения.

0 голосов
/ 03 апреля 2009

Вместо того, чтобы блокировать это, дросселировать это. Используйте iptables -m limit.

0 голосов
/ 03 апреля 2009

что вы подразумеваете под блокировкой исходящего трафика через порт 80.

У вас есть две возможности. Gernerate Dynamic Rules, которые разрешают связь от клиента к вашему веб-серверу для этого сеанса. Поиск правил межсетевого экрана с отслеживанием состояния.

Или вы обычно разрешаете установленным Соединениям взаимодействовать друг с другом.

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

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

Ваш веб-сервер обычно выбирает порт> 1024 и использует его для своего запроса для получения API с удаленного Сервера.

Таким образом, блокировка всего трафика через порт 80 (в качестве порта, к которому вы подключаетесь) не помешает вашему Серверу отправлять какие-либо запросы на apis и тому подобное. потому что он не использует порт 80, когда он действует как клиент.

...