Что является безопасным выбором для веб-сервера на Java в Интернете? - PullRequest
7 голосов
/ 18 марта 2011

Мне нужно внедрить сервер, который общедоступен из Интернета. У сервера очень простая миссия:

  • Прием POST форм от пользователей через HTTPS (фактическая HTML-форма находится на другом сайте)
  • Переписать форму сообщения как JSON
  • Отправить его на внутренний сервер через отдельное соединение HTTPS, с отказоустойчивостью нескольких серверов
  • Ожидание ответа в JSON, содержащего либо успех, либо причину ошибки
  • Возвращает перенаправление «303» из URI успеха или URI отказа, указав причину ошибки в качестве параметра запроса

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

Однако реальная проблема заключается в том, что безопасность абсолютно важна для сервера - сервер участвует в платежных транзакциях с достаточно большим объемом, чтобы сделать его желательной целью для взлома. Сервер находится за IPS, но в остальном он напрямую подключен к Интернету и будет прерывать HTTPS-соединения напрямую от браузеров конечного пользователя без каких-либо промежуточных обратных прокси-серверов или SSL-ускорителей или чего-либо подобного.

Итак, мой вопрос: какой веб-сервер Java был бы самым безопасным выбором для такой цели?

Или, в качестве альтернативы, если вы действительно думаете, что такие запросы должны приниматься не непосредственно Java, а lighttpd или чем-то еще, вы можете предложить что-то еще. Но только если он может выполнить требования, указанные выше.


Действительно хороший ответ затронет следующие вопросы:

  • Соответствующая безопасность OpenSSL против криптографии Java против альтернатив (у всех были уязвимости)
  • Соответствующая безопасность функций Java VM (например, недавняя уязвимость при разборе XML)
  • Соответствующая безопасность парсинга HTTP-заголовка веб-сервера (кажется, что почти у всех были уязвимости)
  • Соответствующая безопасность необязательного сжатия (у zlib были уязвимости, а у mod_deflate помимо этого были отдельные уязвимости)

Ответы [ 3 ]

6 голосов
/ 20 марта 2011

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

Я бы предложил Tomcat и следовал инструкциям Улучшение безопасности Apache Tomcat . Преимущество Tomcat в том, что он является общедоступным и открытым исходным кодом, поэтому он привлекает много внимания и быстрых исправлений. Многие атаки направлены на вещи, которые вам даже не нужны, поэтому отключите все, что можете. Настройте ваш web.xml так, чтобы он принимал только те URL-адреса, которые вы ожидаете, и выдает ошибку для всего остального.

Не похоже, что вам нужен Apache HTTPD перед веб-контейнером. Вероятно, тогда лучше уменьшить количество векторов атак и сделать так, чтобы веб-запросы направлялись прямо в веб-контейнер. Невозможно узнать, какие из HTTPD или Java будут иметь больше уязвимостей для SSL и gzip. Тем не менее, если вы используете только Java, вы, по крайней мере, не открыты для остальной части того, что может быть найдено для HTTPD, по сравнению с ограниченным набором проблем собственной реализации для Java.

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

1 голос
/ 21 марта 2011

Если вам нужно что-то простое и универсальное, я бы попробовал Grizzly - меньше кода, меньше ошибок. У него есть некоторый класс SSLConfig для настройки HTTPS, хотя я не использовал его.

0 голосов
/ 18 марта 2011

Большинство серверов способны на это.Tomcat - очевидный выбор.Tomcat за Apache также распространен.Если использовать JavaEE - любой сервер приложений будет работать.

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