Требуется ли вам глубокая проверка пакетов на брандмауэре, предназначенном только для сервера?[закрыто]

Question

У меня есть сервер за брандмауэром.Он запускает веб-приложение (сервлеты Java под Apache Tomcat) и отвечает только на порт 443 (HTTPS).На обслуживаемых страницах нет кода сценария — формы используют HTTP POST для получения формы, обработки данных (с соответствующей фильтрацией ввода), а затем вывода страницы результатов HTTP.

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

Я не убежден, но у меня нет опыта в области безопасности, чтобы быть уверенным.Брандмауэр будет располагаться между «миром» и моим сервером и использовать «переадресацию портов», чтобы разрешить доступ к серверу только портам 443 и 22 (для обслуживания).

Итак, действительно ли мне нужна эта глубокая проверка пакетов или нет?

Answer 1

Учитывая, что единственными интересующими вас протоколами (ssh и https) являются " согласование шифрования при подключении " мало что стандартный брандмауэр сможет проверить после этого. После установления сеанса SSL / SSH брандмауэр будет видеть только зашифрованные пакеты. Спросите своего поставщика, что их продукт рассматривает в этом контексте.

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

Также вы можете спросить, от каких уязвимостей / рисков защищает система проверки. Например: высматривает ли SQL-инъекцию? Это предназначено для определенной платформы? (Если ваш веб-сервер работает, например, на процессоре SPARC, то нет смысла проверять URL-адреса для шелл-кода x86).

Answer 2

Мне, как специалисту по сетевой безопасности, это кажется излишним.

Ответ Мартина Карпентера на 100% попадает в цель.Каждый раз, когда вы задумываетесь о безопасности, вам необходимо понимать

• То, что вы обеспечиваете,
• Что вы обеспечиваете? против,
• Вероятность нападения и
• Ваш риск в случае успеха атаки.

В вашем приложении, которое допускает только зашифрованную и аутентифицированную связь только на двух портах, я вижу лишь несколько уязвимостей:

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

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

Answer 3

Обновление по нескольким направлениям ...

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

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

Основным назначением брандмауэра в моем сетевом сценарии является "привратник". То есть я хочу, чтобы брандмауэр не давал всему трафику, КРОМЕ http, https и некоторому ssh, выходить за пределы порта WAN. Поскольку внутри брандмауэра нет пользователей, любой трафик, генерируемый изнутри, поступает из моего приложения и может быть разрешен.

Дальнейшие переговоры с одним поставщиком показали, что им больше не нужна глубокая проверка пакетов - другой сотрудник просто пытался «продать» я на рассматриваемой единице. Я также узнал, что их оборудование на самом деле не будет делать все, что я хочу, не тратя кучу денег.

Сейчас я серьезно изучаю использование OpenBSD и брандмауэра PF, чтобы делать то, что я делаю, экономически эффективным способом.