Вам нужна глубокая проверка пакетов на серверном брандмауэре?

Question

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

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

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

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

Answer 1

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

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

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

Answer 2

Как профессионал в области сетевой безопасности, это звучит как излишество для меня.

Ответ Мартина Карпентера на цель 100%. В любое время вы рассматриваете безопасность, вы должны понимать

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

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

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

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

Answer 3

Обновление на нескольких фронтах ...

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

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

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

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

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