Укрепление безопасности WebSphere Application Server V7: Часть 1. Общий обзор и подходы к укреплению безопасности

Безопасность не сводится к размещению на границе сети нескольких межсетевых экранов для защиты от внешних угроз. Безопасность представляет собой набор трудных и сложных мероприятий и процедур, предназначенных для упрочнения системы до необходимого уровня. В данной статье рассматриваются многие общие аспекты безопасности, в том числе архитектура безопасности продукта IBM® WebSphere® Application Server, и описывается укрепление среды IBM® WebSphere® Application Server. Данная статья представляет собой переработанный вариант более ранней статьи,который был существенно обновлен для продукта WebSphere Application Server версий V6.1/V7 и скорректирован с целью концентрации исключительно на вопросах укрепления безопасности. Это первая статья в серии из двух статей. Данный материал был опубликован в онлайновом издании IBM WebSphere Developer Technical Journal. Из журнала IBM WebSphere Developer Technical Journal.

Кейз Ботзум, ведущий технический специалист, EMC

Кейз Ботзум (Keys Botzum) – ведущий технический специалист подразделения IBM Software Services for WebSphere. Кейз Ботзум более 10 лет работает в области проектирования крупномасштабных распределенных систем и дополнительно специализируется в области безопасности. Он имеет большой опыт работы с различными распределенными технологиями, включая Sun RPC, DCE, CORBA, AFS и DFS. В последнее время К. Ботзум сосредоточил свои усилия на J2EE и сопутствующих технологиях. К. Ботзум является обладателем ученой степени магистра в области вычислительной техники, полученной в Стэнфордском университете, и степени бакалавра по прикладной математике/вычислительной технике, полученной в Университете Карнеги Меллона. К. Ботзум опубликовал множество статей по продуктам WebSphere и по безопасности платформы WebSphere. С другими статьями и презентациями К. Ботзума можно ознакомиться по адресу http://www.keysbotzum.com, а также в разделе Материалы по платформе WebSphere на ресурсе IBM developerWorks. К. Ботзум является одним из авторов книги Развертывание и углубленное конфигурирование продуктов IBM WebSphere.



17.12.2012

Введение

Безопасность продукта IBM WebSphere Application Server продолжает совершенствоваться с каждым его выпуском. Помимо добавления новых функций в каждой версии, мы также стремимся улучшить безопасность продукта, обеспечиваемую по умолчанию. Совершенствуя настройки по умолчанию, мы продолжаем улучшать соблюдение важнейшего принципа защиты, согласно которому продукт должен быть безопасен по умолчанию. Предыдущий вариант данной статьи ориентировался на версию WebSphere Application Server V6 и на необходимые шаги по укреплению безопасности этой версии. В последующих выпусках продукта WebSphere Application Server количество этих шагов было значительно сокращено и, что еще важнее, оставшиеся шаги в большинстве своем стали менее критичными. Таким образом, пришло время обновить эту статью в соответствии с наиболее актуальной информацией.

Эта обновленная статья начинается с краткого обсуждения важности безопасности и трудностей упрочнения систем. Затем описывается, как укрепить среду WebSphere Application Server с целью нейтрализации различных уязвимостей в системе безопасности. Для того чтобы можно было сосредоточить внимание преимущественно на укреплении, часть информации представлена на высоком уровне, без углубления в детали. Везде, где это оказалось возможным, предоставлены ссылки на соответствующие ресурсы, позволяющие читателю глубже исследовать связанные темы.

Хотя информация данной статьи основана на версии IBM WebSphere Application Server V7, большинство рассматриваемых в ней вопросов одинаково применимо к версии V6.1. Если та или иная проблема уникальна для определенной версии, этот момент отмечается в статье соответствующим образом. Если вы пользуетесь более ранней версией продукта WebSphere Application Server, обратитесь к предшествующему варианту данной статьи, поскольку между версиями имеются существенные различия.


Зачем нужна безопасность?

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

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

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

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

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

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

Учитывайте не только внешние, но и внутренние угрозы

Безопасность не следует рассматривать как простые ворота, которые не пускают внутрь «посторонних». Это слишком упрощенное представление. Сегодня многие организации направляют свои усилия в области безопасности исключительно на людей за своими границами, ошибочно полагая, что опасность исходит лишь от посторонних лиц. Такое представление не соответствует действительности. У любой большой корпорации существуют, без преувеличения, тысячи людей, многие из которых не являются ее сотрудниками, но обладают доступом к ее внутренней сети. Все эти люди являются потенциальными злоумышленниками, а поскольку они находятся «внутри», то располагают отличными возможностями для доступа к сети. Во многих случаях для получения доступа к корпоративной сети достаточно, чтобы ноутбук был физически подключен к этой сети. Согласно результатам нескольких исследований, примерно половина всех взломов совершена непосредственно самими сотрудниками/контрагентами организации или с их участием.

Даже если вы считаете каждого пользователя в своей сети заслуживающим доверия, все равно нельзя исключать вероятность ошибки. С учетом таких факторов, как широкое распространение почтовых вирусов, легко достигающих адресатов электронной почты; наличие атакующих программ на основе JavaScript™; злонамеренные программы, которые попадают на ваши компьютеры посредством неучтенных USB-накопителей и компакт-дисков, а затем нападают изнутри корпоративной сети компании, было бы опрометчиво предполагать, что вашей внутренней сети можно доверять – это далеко не так.

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

Ограничения и действительность

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

  1. Проанализируйте различные цели атак.
  2. Рассмотрите риск атаки для каждой потенциальной цели.
  3. Определите возможность ущерба от успешной атаки на каждую уязвимость.
  4. Оцените стоимость предотвращения каждой атаки.

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

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

В конечном итоге определение требуемого уровня безопасности – это бизнес-решение, а не техническое решение. Тем не менее в качестве технических специалистов мы должны помочь всем заинтересованным сторонам в осознании ценности и важности безопасности. Необходимо заметить, что за исключением защиты от атак на внутренние приложения бóльшая часть предлагаемых в данной статье шагов по укреплению безопасности сопровождается довольно низкими затратами. В основном организации вполне могут позволить себе реализацию большинства из них. В данной статье не описываются более сложные (и более дорогие) подходы к обеспечению безопасности – более строгая аутентификация, аудит, обнаружение вторжений и т.д. – которые далеко выходят за нативные возможности продукта WebSphere Application Server.

Безопасность – это обширная тема, поэтому невозможно полностью охватить все аспекты безопасности в одной статье. Данная информация не предназначена для использования в качестве введения в безопасность или руководства по защите систем. Статья представляет собой высокоуровневый обзор («контрольный перечень») подлежащих рассмотрению базовых технических проблем, имеющих непосредственное отношение к безопасности продукта WebSphere Application Server. Информация, представленная в данной статье, должна использоваться в рамках более масштабных усилий по созданию безопасного предприятия.

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

Социальная инженерия

Поскольку эта статья имеет технический характер, основное внимание в ней уделяется техническим решениям по обеспечению безопасности систем и, в частности, обеспечению безопасности продукта WebSphere Application Server. Тем не менее необходимо помнить, что во многих случаях скомпрометировать системы легче с помощью технологий социальной инженерии. Другими словами, атакующие способны получить доступ к системам и к информации, к которой они не должны иметь доступа, посредством обмана людей, работающих на определенную организацию. Одно релевантное заключение, которое можно вывести из изучения атак на основе социальной инженерии, состоит в том, что при использовании социальной инженерии атакующие могут находиться внутри вашей сети. Это заключение снова подчеркивает изложенный выше тезис о том, что концентрация усилий в области безопасности исключительно на недопущении злоумышленников в свою сеть – это явно недостаточная мера. Таким образом, в данной статье проблемы безопасности рассматриваются на нескольких уровнях. Каждый уровень пытается противодействовать различным типам атак и выстраивает дополнительные барьеры перед атакующими.

Общее представление системы: детали имеют значение

Прежде чем углубляться в конкретные пошаговые рекомендации, коротко рассмотрим фундаментальные методики создания безопасных систем. Фундаментальное представление состоит в том, чтобы посмотреть на границу каждой системы или на каждую точку совместного использования, а затем проанализировать, какие акторы имеют доступ к этим границам или к этим совместно используемым компонентам. Другими словами, при условии, что эта граница существует (с учетом разумной степени доверия в пределах подсистемы), что сможет сделать злоумышленник для нарушения этой границы? Или при условии, что какой-либо компонент находится в совместном использовании, что сможет сделать злоумышленник для ненадлежащего совместного использования?

Большинство границ вполне очевидны: это сетевые соединения, коммуникации между процессами, файловые системы, интерфейсы операционных систем и т.д., однако некоторые границы являются менее различимыми. Например, если какое-либо одно приложение использует J2C-ресурсы в среде WebSphere Application Server, необходимо рассмотреть возможность того, что некоторое другое приложение попытается получить доступ к этим же ресурсам. Это происходит в связи с существованием системной границы между первым приложением и WebSphere Application Server, а также между вторым приложением и WebSphere Application Server. Вполне возможно, что оба приложения смогут получить доступ к этому общему ресурсу (и, действительно, это вполне возможно). Это пример возможного ненадлежащего совместного использования.

Способ предотвращения этих различных форм атак состоит в применении нескольких хорошо известных методик. Для сетевых атак нижнего уровня применяются такие методики, как шифрование и сетевая фильтрация. По существу, вы лишаете злоумышленников возможности видеть «вещи», которые им не следует видеть (или получать к ним доступ). Для защиты ресурсов операционной системы от злоупотребления используются соответствующие механизмы этой операционной системы. Например, нежелательно, чтобы обычный код пользовательского уровня был способен получить доступ к системной шине и непосредственно читать внутренние сообщения. Также можно использовать то обстоятельство, что самые современные операционные системы обладают довольно мощными средствами для защиты системных API-интерфейсов (см. врезку). На высоком уровне применяется строгая аутентификация и авторизация. Каждый API-интерфейс, каждый метод и каждый ресурс потенциально нуждается в той или иной форме авторизации. Другими словами, доступ к перечисленным выше артефактам должен быть ограничен на основе реальных потребностей. И, конечно, авторизация сама по себе имеет малую ценность без надежной аутентификации. Аутентификация обеспечивает надежное определение «личности» вызывающей стороны. Термин надежное используется не случайно, поскольку аутентификация, которую можно легко подделать, имеет незначительную ценность.

В случае невозможности адекватного уровня аутентификации и авторизации следует прибегнуть к разумному проектированию и к применению соответствующих процедур для предотвращения потенциальных проблем. Например, вот каким образом осуществляется защита J2C-ресурсов. Продукт WebSphere Application Server не предусматривает авторизации доступа к J2C-ресурсам, поэтому вместо этого применяются другие методики для ограничения (на основе конфигурации) возможностей приложений по ненадлежащему обращению к J2C-ресурсам.

Несложно представить, что исследование всех границ системы и всех совместно используемых компонентов – весьма трудная задача. Кроме того, обеспечение защиты системы может привести нас к глубоким размышлениям о сложности. Возможно, самая неприятная правда о безопасности состоит в том, что создание безопасной системы входит в противоречие с абстракцией. Один из базовых принципов хорошей абстракции – сокрытие проблем от высокоуровневых компонентов. Это весьма желательный и хороший результат. К сожалению, злоумышленники не отличаются добротой. Они не заботятся о наших абстракциях или о наших хороших проектах. Их цель состоит в том, чтобы сломать ваши системы любым доступным им способом и попутно отыскать бреши в вашем проекте. Поэтому для подтверждения безопасности системы вы должны продумать ее на каждом уровне абстракции: и на самом высоком архитектурном уровне, и на уровне мельчайших деталей. На сегодняшний день существует несколько инструментов для сканирования приложений, способных оказать содействие при просмотре программного кода (таких как IBM Rational® AppScan®), однако даже при использовании сканирующего инструмента по-прежнему сохраняет свою значимость просмотр каждой строки кода и каждого проектировочного решения в «ручном режиме» с целью предотвращения атак на приложения. Необходимо тщательно просматривать все, что возможно.

Малейшая ошибка способна скомпрометировать целостность всей системы. Этот тезис лучше всего иллюстрируется техникой взятия злоумышленником под свой контроль системы на базе C/C++ с помощью технологий переполнения буфера. По существу, злоумышленник присылает строку, которая является слишком длинной для существующего буфера. Затем эта дополнительная информация накладывается на часть исполняющейся программы и заставляет runtime-среду исполнять инструкции, которые ей не следует исполнять. Приложив определенные усилия, злоумышленник может заставить программу делать практически все, что угодно. Архитектору безопасности даже для выявления этой атаки необходимо глубокое понимание того, как среда исполнения C/C++ управляет памятью и как исполняет работающие программы. Кроме того, для нахождения этой конкретной бреши архитектору необходимо просмотреть каждую строку кода – при условии, что он осознал, что эта брешь существует. Сегодня мы многое знаем об атаках, но тем не менее эти атаки продолжают достигать успеха, поскольку отдельные программисты принимают очень небольшие, но очень плохие решения, которые компрометируют всю систему. К счастью, атака описанного выше типа нереализуема в среде Java™, однако не стоит полагать, что в этой среде невозможны другие маленькие ошибки, способные привести к компрометации.

Относитесь к безопасности серьезно, она заслуживает того.


Обзор укрепления безопасности

Спецификация Java EE в сочетании с продуктом WebSphere Application Server образует прочную инфраструктуру для реализации безопасных систем. К сожалению, многие люди не знают обо всех проблемах, окружающих создание безопасной системы на базе продукта WebSphere Application Server. Поскольку существует множество степеней свободы и множество различных источников соответствующей информации, некоторые пользователи склонны не обращать внимания на проблемы безопасности и развертывают недостаточно безопасные системы. Для решения этой проблемы в данном разделе обобщаются ключевые, наиболее важные вопросы.

Укрепление безопасности – это акт конфигурирования продукта WebSphere Application Server, разработки приложений и конфигурирования некоторых других релевантных компонентов таким способом, который обеспечивал бы максимальный уровень безопасности – с целью фактического предотвращения, блокировки или ослабления различных форм атаки. Для эффективного решения этой задачи необходимо рассмотреть возможные формы атак. Существуют четыре основных подхода к проведению атаки на сервер приложений (классы атак).

  • Сетевые атаки. Эти атаки используют низкоуровневый доступ к сетевым пакетам и стремятся нанести вред системе посредством изменения сетевого трафика или извлечения информации из этих пакетов.
  • Атаки на машину. В этом случае злоумышленник имеет доступ к машине, на которой исполняется WebSphere Application Server. Цель защиты состоит в ограничении возможностей злоумышленника для повреждения конфигурации или для доступа к информации, которую ему не следует видеть.
  • Внешние атаки на приложение. В этом сценарии злоумышленник использует протоколы уровня приложений (HTTP, IIOP, JMX, Web-сервисы и т.д.) для получения доступа к приложению (посредством Web-браузера или клиента какого-либо другого типа) и использует этот доступ для нарушения нормального порядка использования этого приложения с целью выполнения ненадлежащих операций. Необходимо понимать, что такая атака выполняется с использованием хорошо описанных API-интерфейсов и протоколов. Злоумышленник не обязательно находится за пределами компании; он просто выполняет определенный программный код, находясь с внешней стороны от атакуемого приложения. Атаки данного типа являются самыми опасными, поскольку обычно они предъявляют минимальные требования к навыкам злоумышленника и могут быть проведены на большом расстоянии (при наличии доступного IP-соединения).
  • Внутренние атаки на приложение (также известные как изоляция приложения). В этом случае речь идет о так называемом несанкционированном («фальшивом») приложении. В этом сценарии несколько приложений совместно используют одну инфраструктуру WebSphere Application Server, и вы не доверяете полностью ни одному из этих приложений.

Для связывания методик защиты с перечисленными выше классами атак вместе с каждой методикой будет приведен следующий четырехпозиционный ключ для представления уязвимостей:

Vulnerability indicators
  • N - сетевая атака.
  • M – атака на машину.
  • E – внешняя атака на приложение.
  • I – внутренняя атака на приложение.

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

Следует отметить, что в данной статье не рассматривается еще одна форма технической атаки, а именно атака типа «отказ от обслуживания» (DoS – denial of service). Хотя эта тема очень важна, DoS-атаки находятся за пределами данной статьи. Для предотвращения DoS-атак требуются совсем другие методики, для применения которых недостаточно возможностей сервера приложений. Для защиты от DoS-атак применяются такие средства, как мониторы сетевого трафика, ограничители пропускной способности, инструменты для обнаружения вторжений и т.д.

Подход к укреплению безопасности

Опишем некоторые известные шаги, которые следует предпринять для защиты инфраструктуры WebSphere Application Server и приложений от атак четырех перечисленных выше классов (термин «известные» используется в том смысле, что вполне возможно существование других уязвимостей, которые пока еще не были выявлены). Было бы идеально, если бы мы могли организовать информацию в четыре группы – по одной для каждого класса атак. К сожалению, атаки не могут быть аккуратно поделены по перечисленным выше классифицирующим признакам. Несколько различных методик защиты помогают противодействовать нескольким классам атак, а одна единственная атака иногда может задействовать несколько форм вторжения для достижения конечной цели. В качестве примера рассмотрим простейший случай. Злоумышленник применяет анализатор сети (сниффер) для получения паролей, которые затем используются для выполнения атаки на уровне приложений. В отличие от атак методики укрепления в общем случае организованы в логическую структуру, базирующуюся на выполняемых действиях или на роли человека, имеющего отношение к этим проблемам.

  • Инфраструктура. Возможные действия по конфигурированию инфраструктуры WebSphere Application Server для достижения максимального уровня безопасности. Как правило, эти действия выполняются однократно, на этапе построения инфраструктуры, силами только системных администраторов.
  • Конфигурирование приложений. Возможные действия разработчиков приложений и администраторов, результаты которых можно увидеть в процессе развертывания. По существу, речь идет о решениях по проектированию и реализации приложений, которые видимы администратору WebSphere Application Server и поддаются верификации (возможно, с некоторыми трудностями) в рамках процесса развертывания. В этом разделе будет описано большое число методик. Это в очередной раз подтверждает тезис о том, что безопасность не является неким «специализированным» мероприятием – это ответственность каждого лица, участвующего в проектировании, разработке и развертывании приложений.
  • Проектирование и реализация приложений. Возможные действия разработчиков и проектировщиков на этапе разработки, которые имеют критическое значение для безопасности, но могут оказывать незначительное влияние на процесс развертывания.
  • Изоляция приложений. Эта тема рассматривается отдельно вследствие сложности затрагиваемых проблем.

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

  • Атаки на машину менее вероятны, чем сетевые атаки, поскольку доступ к «производственной» машине обычно ограничивается. Если в вашей среде такие ограничения не применяются, эти угрозы становятся весьма вероятными. Для противодействия этим угрозам в первую очередь необходимо ограничить доступ к этим машинам.
  • Самыми серьезными являются атаки, которые могут быть выполнены дистанционно с использованием только IP-соединения. Для противодействия этим атакам необходимо применять аутентификацию для всех коммуникаций.
  • Для защиты трафика следует применять шифрование. При этом следует помнить, что шифрование внутреннего трафика WebSphere Application Server менее важно, чем шифрование трафика, перемещающегося за пределами WebSphere Application Server, поскольку в масштабе всей сети может существовать большое число точек, где злоумышленник способен просматривать трафик.

Обзор SSL/TLS

Технология SSL/TLS (далее будет использоваться обозначение SSL) – это ключевой компонент архитектуры безопасности WebSphere Application Server, который широко применяется для защиты коммуникаций, в частности, для защиты трафика по протоколам HTTP, IIOP, LDAP и SOAP. SSL требует использования пар ключей (открытый/секретный). В случае продукта WebSphere Application Server эти ключи хранятся в так называемых хранилищах ключей (key store). Вследствие важности SSL в защите инфраструктуры сначала рассмотрим некоторые основные аспекты SSL, имеющие непосредственное отношение к WebSphere Application Server (это рассмотрение намеренно сделано весьма поверхностным; описываются только те основные пункты, которые необходимы для надлежащего конфигурирования SSL).

Криптография с открытым ключом базируется на паре ключей (открытый/секретный). Эти два ключа связаны криптографическим образом. Важным моментом является асимметричность ключей – информация, зашифрованная с помощью одного ключа, может быть расшифрована с использованием другого ключа. Секретный ключ, как следует из его названия, является секретным. Это означает, что вы всегда должны защищать этот секретный ключ. Если какое-либо другое лицо когда-либо получит доступ к секретному ключу, оно сможет затем использовать его в качестве «подтверждения» своих идентификационных данных и действовать от вашего имени. Секретный ключ напоминает пароль, только более защищенный и более трудный для изменения. Обладание секретным ключом является доказательством корректности идентификационных данных. Открытый ключ – это часть пары ключей, которую можно использоваться совместно с другими сторонами.

Если бы существовал безопасный способ для распределения открытых ключей между доверенными сторонами, этого было бы вполне достаточно. Однако криптография с открытым ключом делает еще один шаг и вводит концепцию так называемых подписанных открытых ключей. Подписанный открытый ключ имеет цифровую подпись (подобную подписи человека), которая декларирует, что подписавшая сторона ручается за данный открытый ключ. Подписавшая сторона гарантирует, что сторона, обладающая секретным ключом, соответствующим подписанному открытому ключу, является стороной, идентифицированной данным ключом. Эти подписанные открытые ключи называются сертификатами. Известные подписывающие стороны называются центрами сертификации (Certificate Authority, CA). Кроме того, существует возможность самостоятельного подписывания открытых ключей. Такие ключи называются самоподписанными сертификатами. Эти самоподписанные сертификаты не менее безопасны, чем сертификаты, подписанные центрами сертификации. Однако с точки зрения управления их использование создает некоторые дополнительные трудности, как будет показано ниже.

На рисунке 1 показан базовый процесс создания сертификата с помощью центра сертификации и распределения этого сертификата с целью выполнения аутентификации сервера с помощью SSL. В этой ситуации сервер обладает сертификатом, который он использует для идентификации себя перед клиентом. Клиент не имеет сертификата и поэтому является анонимным для SSL.

Рисунок 1. Аутентификация сервера с использованием SSL: создание и распределение сертификата
Figure 1. Server SSL authentication: certificate creation and distribution

При рассмотрении данного рисунка обратите внимание, что клиент должен обладать сертификатом, подписывающим открытый ключ, генерированный сервером. Это решающая часть доверительных отношений. Поскольку клиент доверяет любому имеющемуся у него «подписывающему» сертификату (в данном случае это сертификат от центра сертификации), он доверяет и сертификатам, подписанным данным центром сертификации (CA-сертификатам). При необходимости использования самоподписанных сертификатов вам пришлось бы в ручном режиме доставлять соответствующий самоподписанный сертификат каждому клиенту вместо использования известного CA-сертификата, который, скорее всего, уже встроен в клиента. Это не снижает уровень безопасности, однако при наличии большого числа клиентов существенно затрудняется управление распределением всех подписывающих сертификатов (по одному на каждый сервер) всем клиентам. Гораздо легче было бы распределить только один CA-сертификат, подписывающий множество ключей.

Это преимущественно относится к аутентификации сервера с использованием SSL. После начального установления канала связи (handshake – «рукопожатие») SSL с целью защиты этого канала фактически переключается на шифрование с помощью секретного ключа, используя для этого ключ, созданный в процессе рукопожатия. Более подробное рассмотрение этой темы выходит за рамки данной статьи.

При аутентификации клиента перед сервером имеет место подобный процесс, хотя роли участников полностью меняются. Для аутентификации клиента перед сервером (этот процесс часто называется аутентификацией клиента по сертификату; в сочетании с аутентификацией сервера перед клиентом этот процесс называется «двусторонним SSL») этот клиент должен обладать секретным ключом и соответствующим сертификатом, а сервер должен обладать соответствующим подписывающим сертификатом или копией сертификата клиента. Вот и все, что действительно необходимо знать по этому вопросу. Обратите внимание на следующее обстоятельство: аутентификация по SSL-сертификату ограничивается определением валидности сертификата и не занимается валидностью того, кого представляет этот сертификат. Это ответственность последующих этапов обработки (после применения SSL). Это обстоятельство имеет существенные последствия, о которых вы вскоре узнаете.

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

Ограничение доступа с использованием только SSL

Как указывалось выше, после валидации сертификата средствами SSL процесс аутентификации является завершенным с точки зрения SSL. В идеальном случае было бы желательно, чтобы теперь какой-либо другой компонент проверил идентифицирующую информацию этого сертификата, а затем использовал эту информацию для принятия решения об авторизации. Примеры таких решений об авторизации: клиент принимает решение о том, можно ли доверять данному серверу (Web-браузеры делают это посредством проверки имени в сертификате на совпадение с именем хоста Web-сервера); сервер извлекает имя пользователя, а затем использует его для создания учетных данных в интересах будущих решений об авторизации (именно это делает продукт WebSphere Application Server, когда пользователь пытается осуществить аутентификацию). К сожалению, не все системы обладают такими возможностями. В этом случае можно воспользоваться популярной SSL-уловкой под названием «ограничение валидных сертификатов».

В предыдущем сценарии с аутентификацией клиента этот клиент предоставляет сертификат, а сервер осуществляет валидацию этого сертификата на соответствие перечню сторон, подписывающих доверенные сертификаты. После успешного прохождения этой валидации SSL-рукопожатие считается завершенным. При необходимости ограничить перечень подписывающих сторон, которым следует доверять на определенном сервере, вы даже можете ограничить перечень сторон, способных выполнить такое SSL-рукопожатие. Крайним случаем являются самоподписанные сертификаты. Они позволяют создать ситуацию, в которой будет иметься лишь одна подписывающая сторона: самоподписанный сертификат. Это означает, что на стороне клиента имеется лишь один валидный секретный ключ, который может быть использован для подключения к данной конечной точке SSL: секретный ключ, который вы генерировали при первоначальном создании самоподписанного сертификата. Подобным образом вы можете легко ограничить перечень сторон, способных подключаться к системе по SSL, даже если компоненты серверной стороны не поддерживают авторизацию. Этот прием можно рассматривать как создание доверенного защищенного туннеля на сетевом уровне. Если вы сконфигурируете все надлежащим образом, то даже подключаться с помощью этого транспорта смогут лишь специальные доверенные клиенты. Это весьма полезно в некоторых ситуациях с продуктом WebSphere Application Server, которые будут рассмотрены позднее.

Управление SSL

Как указывалось выше, продукт WebSphere Application Server управляет ключами в файлах хранилищ ключей. Существуют два типа ключевых файлов: хранилища ключей (key store) и хранилища доверенных сертификатов (trust store). Хранилище доверенных сертификатов – это хранилище ключей, которое, согласно установленным соглашениям, содержит только сертификаты от доверенных подписывающих сторон. Таким образом, CA-сертификаты и другие подписывающие сертификаты следует помещать в хранилище доверенных сертификатов, а секретную информацию (личные сертификаты с секретными ключами) следует помещать в хранилище ключей.

К сожалению, в этой простой системе есть одна ловушка. Бóльшая часть среды WebSphere Application Server использует формат PKCS12 (SSL-конфигурации продукта WebSphere Application Server фактически поддерживают три современных формата ключей для баз данных: JKS, JCEKS и PKCS12). Продукт IBM HTTP Server и подключаемый модуль Web-сервера продукта WebSphere Application Server используют более старый формат ключей, известный как формат KDB (более корректное название – формат CMS). Эти два формата подобны по функциональности, но несовместимы. Поэтому следует соблюдать максимальную осторожность, чтобы не использовать эти форматы одновременно.

SSL-конфигурации продукта WebSphere Application Server

Версия WebSphere Application Server V6.1 предоставляет надежную инфраструктуру для управления сертификатами и SSL. При последующем изложении материала данной статьи предполагается, что читатель знаком с этой информацией.


Укрепление безопасности продукта WebSphere Application Server

Версия WebSphere Application Server V6.1 и последующие версии проектировались по принципу защиты, согласно которому продукт должен быть безопасен по умолчанию. Цель (хотя и не полностью достигнутая) состояла в выпуске продукта, который в наиболее распространенных конфигурациях и в более простых средах мог быть сконфигурирован с разумным уровнем безопасности при настройках по умолчанию. Не вызывает сомнения, что более сложные среды могут столкнуться с уникальными проблемами, которые просто невозможно предвидеть. Тем не менее для более простых сред задача состояла в том, чтобы в результате установки и конфигурирования по умолчанию получалась бы система с разумным уровнем безопасности, а не абсолютно безопасная система, поскольку это в принципе невозможно. При этом мы не устраняли каждую уязвимость, поскольку многие из них являются незначительными, и их закрытие по умолчанию значительно усложнило бы разработку приложений, управление приложениями и обеспечение совместимости приложений. Но в тех ситуациях, когда уязвимость могла быть разумно устранена таким способом, с которым согласилось бы большинство клиентов, мы поступали именно так.

Профилактические меры, основанные на инфраструктуре

При защите инфраструктуры сначала необходимо понять, какие компоненты подлежат защите. Как и при любом анализе уязвимости, начните с идентификации компонентов и их внешних коммуникационных маршрутов (такой анализ не выявляет внутренних уязвимостей в приложениях, но действительно раскрывает большинство других уязвимостей). При этом полезно рассмотреть стандартную топологию WebSphere Application Server, включая все сетевые соединения и протоколы (рисунок 2). Поскольку речь идет о безопасности, необходимо узнать обо всех этих связях и сосредоточиться на их защите. Эти соединения представляют собой наиболее «крупнозернистое» представление границ системы, которые упоминались выше.

Рисунок 2. Картина сетевых соединений
Figure 2. Network link picture

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

  • H - HTTP-трафик
    • Использование: от браузера к Web-серверу, от Web-сервера к серверу приложения, от консоли администратора к Web-клиенту.
    • Дружествен к межсетевым экранам.
  • W - внутренние коммуникации WebSphere Application Server.
    • Использование: трафик административных клиентов и внутренний административный трафик сервера WebSphere Application Server. Внутренние коммуникации WebSphere Application Server используют один из следующих протоколов:
      • RMI/IIOP или SOAP/HTTP: протокол административного клиента, поддерживает конфигурирование;
      • сервис передачи файлов (между dmgr и агентом node agent), использует протокол HTTP(S);
      • механизм DCS (Distributed Consistency Service), использует проприетарный протокол. Применяется для репликации память-память, для EJB-сессий с запоминанием состояния, для dynacache и менеджера обеспечения высокой готовности.
    • Протокол SOAP/HTTP дружествен к межсетевым экранам. Протокол DCS может быть дружественным к межсетевым экранам.
  • I - Коммуникация RMI/IIOP.
    • Использование: EJB-клиенты (автономный и Web-контейнер).
    • В общем случае – враждебен к межсетевым экранам как следствие динамического распределения портов и наличия встроенных IP-адресов (что может вызвать конфликты с межсетевыми экранами, выполняющими функции Network Address Translation).
  • M - протокол обмена сообщениями SIB.
    • Использование: JMS-клиент для механизма обмена сообщениями.
    • Протокол: проприетарный.
    • Дружествен к межсетевым экранам, поскольку способен зафиксировать используемые порты. Враждебен к межсетевым экранам, выполняющим функции Network Address Translation (NAT).
  • MQ – протокол WebSphere MQ.
    • Использование: MQ-клиенты (истинные клиенты и серверы приложений).
    • Протокол: проприетарный
    • Совместим с межсетевыми экранами (существует набор портов, доступных для использования). Воспользуйтесь пакетом поддержки продукта WebSphere MQ под номером MA86.
  • L – LDAP-коммуникации.
    • Использование: верификация информации пользователя WebSphere Application Server в реестре.
    • Протокол: TCP-поток, отформатированный согласно документу LDAP RFC.
    • Дружествен к межсетевым экранам.
  • J – JDBC-коммуникации с базой данных посредством JDBC-драйверов от поставщиков.
    • Использование: JDBC-доступ к приложению и к сессии WebSphere Application Server с базой данных.
    • Протокол: проприетарный сетевой протокол для каждой базы данных.
    • Совместимость с межсетевыми экранами зависит от конкретной базы данных (в общем случае, дружествен к межсетевым экранам).
  • S - SOAP
    • Использование: SOAP-клиенты.
    • Протокол: в общем случае – SOAP/HTTP.
    • Дружествен к межсетевым экранам при использовании SOAP/HTTP.

Как показано на рисунке 2, типичная конфигурация WebSphere Application Server имеет несколько сетевых соединений. Чтобы остановить злоумышленников, необходимо в максимально возможной степени защитить трафик в каждом из этих соединений. В остальной части данного раздела описываются необходимые шаги для защиты инфраструктуры, описанной выше. Следующий список составлен в порядке приоритетности. Детальная информация по каждому пункту представлена ниже. В начале списка находятся самые важные пункты (фактически, критически важные). По мере продвижения по этому списку пункты будут становиться менее важными. Каждая организация должна решить для себя, насколько далеко она желала бы продвинуться по этому списку.

  1. Поместите Web-сервер в зону DMZ без продукта WebSphere Application Server.
  2. Отделите свою производственную сеть от интранет-сети.
  3. Используйте протокол HTTPS при работе в браузере.
  4. Сконфигурируйте безопасную передачу файлов.
  5. Поддерживайте актуальное состояние с помощью обновлений и исправлений.
  6. Активируйте безопасность приложений.
  7. Ограничьте доступ к обмену сообщениями на основе WebSphere MQ.
  8. Защитите трафик внутреннего механизма обмена сообщениями.
  9. Укрепите безопасность Web-сервера и хоста.
  10. Удалите JRE-файлы, оставленные инсталляторами подключаемых модулей и Web-сервером.
  11. Укрепите безопасность прокси-сервера.
  12. Тщательно конфигурируйте и используйте модули-посредники типа Trust Association Interceptor (TAI).
  13. Осторожно используйте аутентификацию по сертификату.
  14. Организуйте аутентификацию HTTP-соединений от Web-сервера к WebSphere Application Server.
  15. Не исполняйте примеры в производственной среде.
  16. Выберите для процесса соответствующие идентификационные данные.
  17. Защитите конфигурационные файлы и секретные ключи.
  18. Шифруйте соединения от WebSphere Application Server к серверу LDAP.
  19. Гарантируйте прохождение cookie-файлов LTPA только по протоколу HTTPS.
  20. Гарантируйте периодическое изменение ключей шифрования LTPA.
  21. Не задавайте паролей в командной строке.
  22. Создайте отдельные идентификаторы административных пользователей.
  23. Пользуйтесь разными административными ролями.
  24. Рассмотрите необходимость шифрования канала от Web-сервера к Web-контейнеру.
  25. Используйте только новый формат cookie-файлов LTPA.
  26. Шифруйте каналы обмена сообщениями WebSphere MQ.
  27. Шифруйте транспортный канал DCS (distribution and consistency services).
  28. Защитите сетевое соединение сервера приложений с базой данных.
  29. Защитите конфиденциальные cookie-файлы с помощью опции HTTP Only.
  30. Научите пользователей правильно понимать предупреждения сертификатов.
  31. Тщательно ограничивайте число доверенных подписывающих сторон.
  32. Ограничьтесь только прочными шифрами.
  33. Обеспечьте принудительное использование транспорта CSIv2 over SSL.
  34. Рассмотрите необходимость фильтрации портов.
  35. Отключите неиспользуемые порты.
  36. Рассмотрите необходимость деактивации кэширования пароля.
  37. Рассмотрите необходимость активации совместимости со стандартами FIPS.

1. Поместите Web-сервер в зону DMZ без продукта WebSphere Application Server Server

Vulnerable from: Network, Machine, External

Существуют три фундаментальных принципа DMZ (см. врезку), которые подлежат рассмотрению в рамках данной статьи.

  • Входящий сетевой трафик, поступающий извне, должен быть терминирован в зоне DMZ. Применение одного лишь прозрачного для сети механизма выравнивания нагрузки, такого как Network Dispatcher, не обеспечивает соблюдение этого требования.
  • Необходимо ограничивать ассортимент типов трафика и число открытых портов от зоны DMZ в интранет-сеть.
  • Компоненты, исполняющиеся в зоне DMZ, должны обладать усиленной защитой и соответствовать принципу минимальной функциональности и сложности.

Таким образом, обычно в зоне DMZ следует размещать Web-сервер, а серверы приложений WebSphere Application Server следует размещать за внутренним межсетевым экраном. Это идеальный вариант, поскольку машина Web-сервера может в этом случае иметь очень простую конфигурацию и требовать очень небольшого объема программного обеспечения. Кроме того, в зоне DMZ эта машина служит точкой, в которой терминируются входящие запросы. И, наконец, единственный порт, который должен быть открыт на внутреннем межсетевом экране, это порт HTTP(S) для целевых серверов приложений. Эти шаги делают зону DMZ весьма неблагоприятным местом для атакующего. Кроме того, при желании в зону DMZ можно поместить защищенный прокси-сервер вместо Web-сервера или в дополнение к нему.

Если вы разместите WebSphere Application Server на машине, находящейся в зоне DMZ, то вам придется устанавливать на этой машине гораздо больше программного обеспечения, а также открывать значительно больше портов на внутреннем межсетевом экране, чтобы продукт WebSphere Application Server смог получить доступ к производственной сети. Это в значительной степени подрывает потенциальную ценность концепции DMZ.

Вы можете поместить в зону DMZ не Web-сервер, а что-либо другое. Разумный вариант – поместить в зону DMZ защищенный прокси-сервер, например, IBM Tivoli® AAccess Manager WebSEAL, защищенный прокси-сервер WebSphere Application Server или защищенное устройство типа IBM WebSphere DataPower®. Залог успеха – в зоне DMZ не должно находиться сложных серверов приложений, а все размещаемые в ней компоненты должны быть хорошо защищены и выполнять функции терминации входящих соединений.

2. Отделите свою производственную сеть от интранет-сети

Vulnerable from: Network, External

Сегодня большинство организаций осознает ценность зоны DMZ, которая отделяет посетителей Интернета от корпоративной интранет-сети. Тем не менее слишком многие организации не в состоянии понять, что множество злоумышленников уже находится у них внутри. Как говорилось ранее, необходимо защищаться не только от внешних, но и от внутренних угроз. Точно так же, как вы защищаетесь от большого и ненадежного Интернета, вы должны защитить свои производственные системы от большой и ненадежной интранет-сети.

Отделите свои производственные сети от внутренней сети с помощью межсетевых экранов. По всей вероятности, эти межсетевые экраны будут работать в более «либеральном» режиме, чем межсетевые экраны, обращенные в Интернет, тем не менее они смогут блокировать многочисленные разновидности атак. После применения этого и предыдущего шагов построение топологии межсетевого экрана будет завершено, как показано на рисунке 3 (дополнительная информация о назначении портов межсетевого экрана WebSphere Application Server содержится в статье Назначение портов межсетевого экрана в WebSphere Application Server.)

Обратите внимание, что компонент wsadmin на рисунке помещен на границе межсетевого экрана. Это сделано для того, чтобы продемонстрировать следующее обстоятельство. Предпочтительным местом для исполнения компонента wsadmin является производственная сеть (внутри защищенной зоны), тем не менее доступ к wsadmin может быть ограничен выбранными адресами, соответствующими компьютерам администраторов, и достаточно легко осуществляться через межсетевой экран. EJB-клиенты на рисунке 3 также показаны на границе, поскольку они могут находиться с любой стороны от межсетевого экрана.

Рисунок 3. Рекомендуемая конфигурация межсетевых экранов
Figure 3. Recommended firewall configuration

На данном рисунке показан единственный межсетевой экран и неполная зона DMZ, обращенная к интранет-сети, поскольку это наиболее распространенная топология. Тем не менее мы все чаще видим полные зоны DMZ (с Web-сервером во внутренней зоне DMZ), защищающие производственные сети от непроизводственных интранет-сетей. Вне всякого сомнения, это весьма разумный подход.

3. Используйте протокол HTTPS при работе в браузере

Vulnerable from: Network

Если на вашем сайте применяется какая-либо аутентификация или выполняются какие-либо действия, подлежащие защите, используйте протокол HTTPS при коммуникациях от браузера до Web-сервера. Если протокол HTTPS не используется, то такая информация, как пароли, действия пользователей, cookie-файлы сессии WebSphere Application Server, cookie-файлы безопасности (LTPA-маркеры, см. врезку) может быть видна злоумышленникам, поскольку трафик перемещается по внешней сети.

При использовании приложений, которые разрешают прохождение HTTP-трафика до проведения аутентификации, обращайте на cookie-файлы самое пристальное внимание. Если какой-либо cookie-файл (например, JSESSIONID) задействован до начала использования HTTPS, этот cookie-файл является источником потенциального риска после начала использования HTTPS, поскольку он мог быть изменен или захвачен злоумышленником. Вот почему у продукта WebSphere Application Server имеются отдельные cookie-файлы для аутентифицированных пользователей. Существует еще более утонченный метод атаки, позволяющий злоумышленнику модифицировать любую страницу, возвращаемую по HTTP – даже URL-адрес, встроенный в эту страницу. В этом случае пользователь может нажать на «безопасную» URL-ссылку на вашей странице, после чего он в действительности будет перенаправлен на сайт злоумышленника.

4. Сконфигурируйте безопасную передачу файлов

Vulnerable from: External

(В версии V7 осуществляется по умолчанию)

Компонент Deployment Manager (менеджер развертывания) присылает обновления конфигурации агентам узлов с помощью протокола FTP. В V6.1 и ниже этот протокол по умолчанию является неаутентифицируемым. Точнее говоря, агенты узла извлекают из менеджера развертывания административные обновления конфигурации с помощью неаутентифицируемого сервиса передачи файлов. Таким образом, любой внешний клиент потенциально способен подключиться к менеджеру развертывания и загрузить на него любые файлы. Подобная загрузка множества файлов большого размера способна привести к исчерпанию дискового пространства у операционной системы и, соответственно, к полному краху. Кроме того, теоретически существует возможность для загрузки файлов, которые затем будут реплицироваться от менеджера развертывания к узлам. Однако, с учетом кратковременной и переходной природы таких файлов, эта возможность является менее вероятной.

Чтобы гарантировать, что менеджер развертывания будет отвечать на запросы о передаче файлов только от доверенных серверов в ячейке, необходимо установить приложение filetransferSecured и заменить им существующее небезопасное приложение. В нормальных условиях это приложение невидимо, поскольку является системным, что не мешает ему успешно выполнять свои функции. IBM предоставляет соответствующий скрипт, описанный на ресурсе Информационный центр по продукту WebSphere Application Server.В листинге 1 показаны шаги для установки приложения filetransferSecured (это пример для Windows®, вариант для UNIX® практически ничем не отличается). В листинге 1 предполагается, что вы используете редакцию WebSphere Application Server Network Deployment; если вы используете базовую редакцию продукта WebSphere Application Server, сервер будет иметь имя server1, а не dmgr.

Листинг 1. Установка приложения filetransferSecured
cd <profilehome>\bin
wsadmin.bat -user <wasadminuser> -password <waspassword>
wsadmin>source ../../../bin/redeployFileTransfer.jacl
wsadmin>fileTransferAuthenticationOn <your cell name> <dmgr node name> dmgr 
wsadmin>$AdminConfig save

Если вы забыли значения параметров cell name (имя ячейки) и node name (имя узла), вы сможете найти их в каталоге config для соответствующего профиля. Помните, что node – это узел менеджера развертывания (deployment manager), поэтому искомое имя скорее всего заканчивается на "CellManager".

5. Поддерживайте актуальное состояние с помощью обновлений и исправлений

Vulnerable from: Network, Machine, External, Internal

Как и в любых других сложных продуктах, корпорация IBM время от времени находит и устраняет ошибки безопасности в WebSphere Application Server, в IBM HTTP Server и других продуктах. Крайне важно, чтобы вы своевременно устанавливали эти исправления. Рекомендуется подписаться на бюллетени службы поддержки по используемым продуктам, а в случае продукта WebSphere Application Server отслеживать сайт с бюллетенями безопасности для своей версии. Часто эти бюллетени содержат уведомления о недавно обнаруженных ошибках безопасности и о соответствующих исправлениях. Вы можете быть уверены в том, что потенциальные злоумышленники быстро узнают о брешах в системе безопасности. Чем быстрее вы будете действовать, тем лучше.

Более общая информация по безопасности продукта WebSphere Application Server, включая рекомендации по укреплению инфраструктуры WebSphere Application Server, доступна на странице WebSphere Application Server security.

6. Активируйте безопасность приложений

Vulnerable from: Network, External

По умолчанию продукт WebSphere Application Server обеспечивает административный уровень безопасности. Таким образом, для большей части инфраструктуры по умолчанию предусматривается разумный уровень аутентификации, авторизации и шифрования административного трафика. Если активирован административный уровень безопасности, то внутренние соединения продукта WebSphere Application Server между менеджером развертывания и серверами приложений, а также трафик от административных клиентов (Web-клиентов и клиентов на основе командной строки) к менеджеру развертывания подвергаются шифрованию и аутентификации (см. рисунок 3). Помимо прочего, это означает, что администраторам придется проходить аутентификацию при работе с административными инструментами. Имеются некоторые исключения, которые будут рассмотрены позже.

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

Для активации безопасности приложений перейдите к панели глобальной безопасности (рисунок 4) и выберите опцию Enable application security (как будет показано позднее, в активации безопасности Java 2 нет необходимости).

Рисунок 4. Активация безопасности приложений
Figure 4. Application security

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

7. Ограничьте доступ к обмену сообщениями на основе WebSphere MQ

Vulnerable from: External

При использовании продукта WebSphere MQ в качестве поставщика сервисов обмена сообщениями необходимо реализовать авторизацию очереди посредством применения других средств. По умолчанию продукт WebSphere MQ в режиме клиент-сервер не осуществляет никакой аутентификации пользователей (в режиме bindings применяется внутримашинная аутентификация между процессами). И действительно, при указании идентификатора/пароля пользователя при подключении к продукту WebSphere MQ он просто игнорирует эти значения.

Данная статья концентрируется на безопасности продукта WebSphere Application Server, поэтому текущий раздел касается исключительно защиты соединения от сервера приложений к продукту WebSphere MQ. Эта защита не делает безопасным сам продукт WebSphere MQ. Для надлежащей защиты продукта WebSphere MQ требуются значительные дополнительные усилия.

Одна из возможностей для решения этой проблемы состоит в реализации собственного подключаемого модуля аутентификации на стороне сервера WebSphere MQ, который будет осуществлять валидацию идентификатора/пароля пользователя, посылаемых продуктом WebSphere Application Server. Еще один и, вероятно, более простой способ состоит в том, чтобы сконфигурировать WebSphere MQ для использования SSL при аутентификации клиента, а затем гарантировать, что только сервер WebSphere Application Server будет обладать соответствующими сертификатами для подключения к продукту WebSphere MQ. (Прочитайте статью Защита соединений между WebSphere Application Server и WebSphere MQ для получения дополнительной информации по данной теме; эта статья немного устарела, однако изложенные в ней принципы и методики применимы и к более новым версиям обоих продуктов. При чтении статьи не забывайте об изменениях, реализованных в современных версиях указанных продуктов.)

8. Защитите трафик внутреннего механизма обмена сообщениями

Vulnerable from: External

(В версии V7 осуществляется по умолчанию).

До версии V7 шина SIBus по умолчанию обеспечивала аутентификацию и авторизацию клиентов, но не требовала, чтобы механизмы обмена сообщениями осуществляли аутентификацию друг друга. Это создавало брешь в системе безопасности, поскольку злоумышленник мог представить себя в качестве механизма обмена сообщениями и скомпрометировать трафик шины. Аутентификация между механизмами (и неявная авторизация) легко конфигурируется на панели безопасности шины (рисунок 5) посредством выбора аутентификационного псевдонима (Inter-engine authentication alias).

Рисунок 5. Аутентификация механизма обмена сообщениями
Figure 5. Messaging engine authentication

9. Укрепите безопасность Web-сервера и хоста

Vulnerable from: External

Если вы следуете рекомендациям по стандартной топологии, изложенным выше (см. шаг 1), ваш Web-сервер работает в зоне DMZ. Поскольку зона DMZ представляет собой переднюю линию защиты от потенциальных злоумышленников, необходимо предпринять специальные меры для укрепления этого сервера.

В данной статье не обсуждаются специфические особенности укрепления безопасности Web-сервера, тем не менее вам следует специально рассмотреть такие моменты, как укрепление безопасности операционной системы, ограничение числа загружаемых модулей Web-сервера, а также иные шаги по конфигурированию Web-сервера (Дополнительную информацию можно получить на ресурсе по повышению безопасности Apache и в книге Building Secure Servers with LINUX).

При укреплении Web-сервера необходимо рассмотреть один специфический аспект продукта WebSphere Application Server. Административная инфраструктура WebSphere Application Server способна управлять Web-серверами. Это выглядит привлекательно с точки зрения простоты использования, однако создает серьезные проблемы безопасности. Имеются два способа для управления Web-сервером.

  • Способ с использованием управляемого узла требует размещения агента узла на машине Web-сервера (который, как правило, находится в зоне DMZ). Этот агент должен являться частью ячейки WebSphere Application Server. Это совершенно недопустимо с точки зрения безопасности, поэтому данный способ не должен применяться кроме тех редких случаев, когда нет никакой необходимости в зоне DMZ. Это недопустимо по двум причинам:
    • во-первых, агент узла является полнофункциональным членом ячейки и, таким образом, имеет полные административные полномочия. Если он будет скомпрометирован в зоне DMZ, то вся ячейка будет скомпрометирована;
    • во-вторых, WebSphere Application Server – это большой и мощный продукт, укрепление безопасности которого сопровождается определенными трудностями, как показано в данной статье. Подобные продукты не должны принадлежать к зоне DMZ.
  • Второй способ требует использования продукта IBM HTTP Server и конфигурирования HTTP-сервера администратора. В этом сценарии менеджер развертывания будет посылать административные запросы в HTTP-сервер администратора, исполняющийся на хосте Web-сервера. Хотя этот способ лучше, чем рассмотренный выше, многие специалисты полагают, что он является слишком рискованным и предпочитают не иметь никаких административных функций в зоне DMZ.

10. Удалите JRE-файлы, оставленные инсталляторами подключаемых модулей и Web-сервером

Vulnerable from: Machine

При установке продукта IBM HTTP Server его инсталлятор оставляет после себя JRE-файл. Удалите этот JRE-файл, поскольку он предлагает функции, которые в нормальных условиях не нужны Web-серверу или подключаемому модулю. Имейте в виду, что это сделает невозможным исполнение на этом Web-сервере некоторых инструментов, таких как iKeyman. Это малозначительная проблема, поскольку исполнение таких инструментов в зоне DMZ в любом случае является весьма проблематичным.

При установке подключаемого модуля HTTP Server продукта WebSphere Application Server с помощью инсталлятора IBM этот инсталлятор также оставляет после себя JRE-файл. Как и в предыдущем случае, эти следы установки необходимо удалить .

Если вы решите удалить эти JRE-файлы, следует сделать их резервную копию на случай будущего использования. Так, с этой целью можно архивировать JRE-файл в формате zip или tar, а впоследствии извлечь его из архива, если он, например, потребуется для обновления инсталлятора WebSphere Application Server с целью установки исправлений. После завершения процесса установки этот JRE-файл можно будет снова заархивировать, а затем удалить исходный файл.

11. Укрепите безопасность прокси-сервера

Vulnerable from: External

Если вы хотите использовать защищенный прокси-сервер в зоне DMZ вместо Web-сервера (или в дополнение к нему), то предыдущий совет применим и к прокси-серверу, хотя укрепление прокси-сервера имеет определенную специфику, которая выходит за рамки данной статьи.

Один важный момент относительно WebSphere DataPower. Как правило, прокси-серверы Web-безопасности не подходят для представительства трафика Web-сервисов, поскольку они не способны блокировать угрозы тех типов, которые возможны при передаче XML-контента. Для защиты Web-сервисов (или любого протокола на базе XML) используйте межсетевой экран с поддержкой XML, такой как WebSphere DataPower.

12. Тщательно конфигурируйте и используйте модули-посредники типа Trust Association Interceptor (TAI)

Vulnerable from: External

TAI-модули часто используются для того, чтобы реализовать в среде WebSphere Application Server функцию распознавания существующей аутентификационной информацию от прокси-сервера типа Web SSO, например, от Tivoli Access Manager WebSEAL. В общем случае все это замечательно. Тем не менее следует соблюдать осторожность при разработке, выборе и конфигурировании TAI-модулей. Применение TAI-модуля расширяет доверительную область. Теперь продукт WebSphere Application Server доверяет TAI-модулю и всему, чему доверяет этот TAI-модуль. Если TAI-модуль разработан или сконфигурирован ненадлежащим образом, он может полностью скомпрометировать безопасность среды WebSphere Application Server. При разработке специального TAI-модуля необходимо гарантировать, что этот TAI-модуль осуществляет тщательную валидацию параметров, передаваемых в запросе, и что эта валидация осуществляется безопасным способом. Мне встречались TAI-модули, которые делали такие глупые вещи, как беспрепятственное принятие имени пользователя в HTTP-заголовке. Это бесполезно до тех пор, пока не гарантирована пересылка всего трафика, получаемого от WebSphere Application Server, через соответствующий аутентификационный прокси-сервер (например, посредством описанных выше методик) и того, что этот аутентификационный прокси-сервер всегда отвергает установленный клиентом HTTP-заголовок, поскольку HTTP-заголовки могут быть подделаны злоумышленником.

  • Конфигурирование модуля WebSEAL TAI

    Чтобы подчеркнуть всю важность тщательного конфигурирования, в данной статье специально рассматривается унаследованный TAI-модуль от IBM под названием WebSEAL TAI, однако любой TAI-модуль требует максимальной осторожности при проектировании и конфигурировании с целью обеспечения безопасности. Надлежащее конфигурирование доверительных отношений между продуктами WebSphere Application Server и Tivoli Access Manager WebSEAL имеет критическое значение для создания безопасной конфигурации. С целью создания этой безопасной конфигурации необходимо выполнить соответствующие шаги и в WebSphere Application Server, и в WebSEAL. В среде WebSphere Application Server надлежащим образом должны быть настроены конфигурация Web-контейнера и конфигурация модуля WebSEAL TAI.

    Доверительные отношения между этими двумя продуктами имеют критическое значение, поскольку модуль WebSEAL TAI в среде WebSphere Application Server принимает утверждения идентификационных данных от сервера WebSEAL. Если этот канал будет скомпрометирован, злоумышленник сможет декларировать любую идентификационную информацию и тем самым полностью подорвать безопасность инфраструктуры. Доверительные отношения между WebSphere Application Server и WebSEAL могут быть установлены посредством одного из двух механизмов: взаимная SSL-аутентификация (mutualSSL) и аутентификация на основе паролей. Любой из этих механизмов подходит для использования в защищенной среде. Тем не менее каждый из них должен быть сконфигурирован надлежащим образом, поскольку в противном случае возможны серьезные бреши в системе безопасности. В любом случае WebSEAL посылает идентификатор конечного пользователя как заголовок iv-user в HTTP-запросе. Различие между этими двумя конфигурациями состоит в том, каким образом WebSEAL аутентифицирует себя перед сервером приложений.

  • Конфигурирование аутентификации WebSEAL на основе пароля

    При использовании аутентификации по паролю WebSEAL посылает свои идентификатор/пароль пользователя как базовый аутентификационный заголовок в HTTP-запросе (идентификатор пользователя user ID находится в заголовке iv-user). Аутентификация на основе пароля конфигурируется в двух местах. Во-первых, сервер WebSEAL должен быть сконфигурирован на отсылку своих идентификатора/пароля пользователя серверам приложений для настройки соединения. Вне всякого сомнения, этот пароль должен быть надежно защищен. При получении этого пароля модуль WebSEAL TAI осуществит валидацию этого пароля на соответствие реестру.

    Имеется, однако, один тонкий момент, который часто упускается из виду. Если свойство LoginId не настроено в свойствах модуля WebSEAL TAI, то этот TAI-модуль будет осуществлять верификацию комбинации идентификатор/пароль пользователя, присланную от WebSEAL, и доверять ей, если она будет представлять собой любое валидное сочетание идентификатора и пароля пользователя. Это небезопасная конфигурация, поскольку в этом случае любое лицо, знающее какую-либо валидную комбинацию «идентификатор/пароль пользователя», сможет подключиться к WebSphere Application Server и выступать от имени любого пользователя. Если свойство LoginId будет специфицировано, то модуль WebSEAL TAI игнорирует входящий идентификатор пользователя в базовом заголовке аутентификации и осуществляет верификацию комбинации «идентификатор LoginId/пароль WebSEAL». В этом случае существует лишь один (хорошо охраняемый) валидный пароль, который может быть прислан от WebSEAL. Конечно, следует сконфигурировать SSL-соединение от WebSEAL до сервера приложений, чтобы гарантировать, что секретный пароль не пересылается в виде открытого (незашифрованного) текста.

  • Конфигурирование mutualSSL для WebSEAL

    Механизм mutualSSL конфигурируется посредством трех раздельных и критически важных шагов.

    1. Сервер WebSEAL должен быть сконфигурирован на использование SSL при коммуницировании с WebSphere Application Server, при этом SSL-конфигурация должна включать сертификат клиента, известный только Web-контейнеру сервера приложений.
    2. Web-контейнер сервера приложений должен быть сконфигурирован на выполнение аутентификации клиента по сертификату, а его хранилище доверительных сертификатов должно быть изменено таким образом, чтобы включать только сертификат клиента, используемый сервером WebSEAL. Этот шаг крайне важен, поскольку таким образом вы гарантируете, что запросы к Web-контейнеру сервера приложений поступают только от WebSEAL, а не от некоторого злоумышленника (простого использования взаимной SSL-аутентификации недостаточно). Вы также должны удалить из Web-контейнера соединения, не использующие HTTPS. Это гарантирует, что при контакте с сервером будут использоваться только взаимно аутентифицированные SSL-соединения.
    3. Свойства модуля WebSEAL TAI должны быть сконфигурированы с параметром mutualSSL=true. Однако следует понимать, что этот последний шаг просто указывает этому TAI-модулю, что он должен считать данное соединение безопасным и что он использует взаимно аутентифицированное SSL-соединение. Если любой из двух предыдущих шагов не будет сконфигурирован абсолютно корректно, ваша среда станет небезопасной.

    Таким образом, решение о применении mutualSSL должно приниматься с большой осторожностью. Любые конфигурационные ошибки породят среду, в которой любой пользователь может быть имитирован злоумышленником.

    При добавлении Web-сервера ситуация становится еще более сложной. В этом случае необходимо тщательно сконфигурировать mutualSSL-аутентификацию между сервером WebSEAL и Web-сервером, а также между подключаемым модулем Web-сервера и Web-контейнером продукта WebSphere Application Server.

Несколько модулей WebSEAL TAI

В настоящее время существуют три различных TAI-модуля, которые могут применяться для поддержки единого входа (single sign-on, SSO) между WebSEAL и WebSphere Application Server.

  • Унаследованный модуль WebSEAL TAI (WebSealTrustAssociationInterceptor) поставляется вместе с продуктом WebSphere Application Server. Избегайте этого TAI-модуля, поскольку его использование в версии V7 категорически не рекомендуется. Кроме того, конфигурация этого модуля может быть небезопасной, как указывалось выше.
  • Tivoli Access Manager Interceptor Plus TAI (TAMTrustAssociationInterceptorPlus) поставляется вместе с продуктом WebSphere Application Server. Этот TAI-модуль является предпочтительным, поскольку он устраняет уязвимость в системе безопасности, характерную для предшествующего TAI-модуля. Однако у этого модуля есть некоторые функциональные отличия от унаследованного TAI-модуля (в том числе обязательное конфигурирование TAM-клиента), вследствие чего некоторые пользователи предпочитают не применять этот модуль.
  • Enhanced Tivoli Access Manager TAI (TAMETai) может быть загружен с сайта IBM. Этот TAI-модуль укреплен надлежащим образом, как и TAI-модуль TAMPlus, но при этом поддерживает важные дополнительные функции, в том числе возможность исполнения без клиента Tivoli Access Manager (точно так же, как унаследованный модуль WebSEAL TAI).

В общем случае, следует выбирать для использования второй или третий TAI-модуль (согласно имеющимся потребностям).

13. Осторожно используйте аутентификацию по сертификату

Vulnerable from: External

Аутентификация по сертификату сопровождается двумя весьма специфическими рисками.

  • Аннулирование. Сертификаты могут быть скомпрометированы, что может породить решения по их аннулированию.

    Сертификаты обеспечивают устойчивую форму аутентификации, и их применение весьма желательно с точки зрения безопасности. Однако необходимо учитывать проблему их аннулирования. Поскольку секретный ключ контролируется пользователем, всегда существует риск его компрометации. По указанной причине все центры сертификации предусматривают возможность аннулирования сертификата; как правило, в этом случае центр сертификации заявляет, что определенному сертификату больше нельзя доверять. Чтобы аннулирование сертификата работало надлежащим образом, получатель сертификата должен проверить его на валидность. Многие люди пропускают этот этап. Без надлежащей поддержки аннулирования сертификатов их использование для аутентификации – это просто авантюра. На данный момент существует множество применяемых методик (которые не будут рассматриваться здесь подробно); говоря кратко, можно выбирать из следующих вариантов:

    • Online Certificate Status Protocol (OCSP).
    • Certificate Revocation List (список аннулированных сертификатов), который можно найти по встроенной в сертификат информации о единственной конечной точке (end point) или о точке распределения (distribution point);
    • Self Signed Certificates (самоподписанные сертификаты). Если вам достаточно небольшого количества сертификатов, вы можете выпускать так называемые «самоподписанные» сертификаты. В этом случае для аннулирования достаточно удалить соответствующую подписывающую сторону.

    Продукт WebSphere Application Server поддерживает все перечисленные выше методики, однако все они нуждаются в конфигурировании. Убедитесь в том, что вы выполнили все надлежащие шаги.

  • Риск достоверности Web-аутентификации. Механизм, используемый для валидации сертификатов, должен иметь защищенную конфигурацию; по умолчанию он не предназначен для Web-трафика.

    Когда аутентификация по сертификатам используется для Web-аутентификации, может возникнуть очень тонкая проблема доверия. Когда Web-клиент аутентифицируется на Web-сервере, этот Web-сервер осуществляет валидацию его сертификата. После этого подключаемый модуль Web-сервера продукта WebSphere Application Server перенаправляет информацию этого сертификата от Web-сервера к серверу приложений. Эта информация перенаправляется таким образом, чтобы Web-контейнер смог преобразовать данный сертификат в идентификационные сведения Java EE. Проблема состоит в том, что данная информация – это всего лишь описание сертификата (т.е. информация, доступная в открытом сертификате). Если злоумышленник сможет подключиться непосредственно к Web-контейнеру и обойти Web-сервер, система станет уязвимой для компрометации, поскольку злоумышленник способен подделать информацию сертификата и обмануть среду исполнения, а затем представиться любым лицом. Другими словами, если для аутентификации используются сертификаты (аутентификация на базе Java EE или на базе специализированного приложения, непосредственно исследующего сертификат), необходимо заблокировать эту уязвимость.

    Необходимо рассмотреть следующие два случая. Если вы хотите использовать сертификаты для аутентификации на Web-сервере, а затем сделать эти сертификаты доступными Web-контейнеру для аутентификации, вам потребуется аутентифицировать соединение от Web-сервера к Web-контейнеру (см. следующий раздел). Если вы хотите использовать сертификаты для аутентификации непосредственно на Web-контейнере (т.е. в вашем сценарии Web-сервер отсутствует), вам потребуется сконфигурировать Web-контейнер таким образом, чтобы он игнорировал информацию сертификата в HTTP-заголовках (в этом сценарии такая информация всегда была бы фальсифицирована). С этой целью необходимо для каждого сервера приложений сконфигурировать специальное свойство Web-контейнера с именем trusted и присвоить этому свойству значение «false» (ложь), как показано на рисунке 6.

    Рисунок 6. Настройка Web-контейнера на игнорирование заголовков сертификатов от клиента
    Figure 6. Setting Web container to ignore certificate headers from client

Если вы хотите поддержать аутентификацию по сертификатам на Web-сервере и на Web-контейнере, вам потребуется специализированный код, поскольку ни одно из упомянутых выше решений не является достаточным; оба этих решения уязвимы для атак со стороны другого соединения. Вместо них нужно разработать специализированный код TAI-модуля или приложения для использования определенных функций IBM, посредством которых исполняющийся в Web-контейнере код анализирует информацию сертификата, доступную через API-интерфейсы Java EE и определяет, получена ли эта информация от стороны, непосредственно подключенной к Web-контейнеру (в этом случае она заслуживает доверия), или эта информация извлечена из HTTP-заголовков (в этом случае она не является безусловно заслуживающей доверия). В последнем случае специализированный код может непосредственно просмотреть информацию сертификата, представленную контейнеру в рамках SSL-рукопожатия и проверить, заслуживает ли доверия сторона, сформировавшая HTTP-заголовки. Например, специализированный код может исследовать сертификаты SSL-клиента (доступные посредством команды request property com.ibm.websphere.ssl.direct_connection_peer_certificates) на предмет наличия у контейнера прямого соединения от подключаемого модуля WebSphere Application Server. При наличии такого соединения этот код может согласиться принять информацию сертификата, декларируемую в HTTP-заголовках. Эта функция, добавленная в версии 7.0.0.7, описана на следующем ресурсе: Информационный центр по продукту WebSphere Application Server.

14. Организуйте аутентификацию HTTP-соединений от Web-сервера к WebSphere Application Server

Vulnerable from: Network, External

Подключаемый модуль Web-сервера продукта WebSphere Application Server перенаправляет запросы от Web-сервера к целевому серверу приложений. По умолчанию, если трафик к Web-серверу передается по протоколу HTTPS, то упомянутый выше подключаемый модуль будет автоматически использовать HTTPS при перенаправлении запроса серверу приложений с целью защиты его конфиденциальности.

Теперь вы можете достаточно легко сконфигурировать серверы приложений (каждый из которых имеет небольшой встроенный модуль HTTP listener) на принятие запросов только от известных Web-серверов. Эта мера предотвратит разнообразные скрытые атаки, которые обходят любые средства защиты перед Web-сервером или в самом Web-сервере, и создаст доверенные сетевые маршруты. Подобная ситуации может показаться маловероятной, однако в действительности она вполне возможна. Вот некоторые примеры, не претендующие на полноту охвата.

  • У вас есть аутентификационный прокси-сервер, который осуществляет только пересылку идентификатора пользователя как HTTP-заголовок без какой-либо аутентификационной информации. Злоумышленник, способный получить доступ непосредственно к Web-контейнеру, сможет имитировать любое лицо, просто предоставив этот же заголовок (продукт IBM Tivoli Access Manager WebSEAL не имеет такой уязвимости).
  • У вас есть прокси-сервер, который выполняет важные авторизационные функции с целью ограничения (на достаточно грубом уровне) круга лиц, способных получить доступ к определенным приложениям.
  • У вас есть прокси-сервер, который выполняет ответственные функции аудита, и вы хотите, чтобы его невозможно было обойти.
  • Вы используете аутентификацию клиента по сертификатам для Web-сервера, как было описано в предыдущем разделе.

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

  1. Создайте хранилище ключей и хранилище доверенных сертификатов для Web-контейнера, а также хранилище ключей для подключаемого модуля Web-сервера.
  2. Удалите из всех хранилищ ключей (включая хранилище доверенных сертификатов) все существующие подписывающие сертификаты. Начиная с этого момента никакое хранилище ключей не может быть использовано для валидации каких-либо сертификатов. Это сделано намеренно.
  3. Создайте самоподписанный сертификат в двух хранилищах ключей и экспортируйте только этот сертификат (а не секретный ключ). Не забывайте отслеживать истечение сроков действия ваших сертификатов. После истечения срока действия сертификата подключаемого модуля этот модуль больше не сможет связаться с Web-контейнером! Импортируйте сертификат, экспортированный из хранилища ключей Web-контейнера, в хранилище ключей подключаемого модуля. Импортируйте сертификат подключаемого модуля в хранилище доверенных сертификатов Web-контейнера. Теперь каждая сторона содержит лишь один подписывающий сертификат. Другими словами, каждая сторона может быть использована для верификации ровно одного сертификата – самоподписанного сертификата, созданного для другой стороны.
  4. Установите недавно созданные хранилища ключей в Web-контейнер и в подключаемый модуль Web-сервера.

15. Не исполняйте примеры в производственной среде

Vulnerable from: External

Продукт WebSphere Application Server поставляется с несколькими превосходными примерами для демонстрации его различных функций. Эти примеры не предназначены для использования в производственной среде. Не исполняйте примеры в этой среде, поскольку они создают существенные риски безопасности. В частности, snoop-сервлеты showCfg могут предоставить внешней стороне огромный объем информации о вашей системе. Эта информация относится именно к тому типу, который вы не хотели бы предоставлять потенциальному злоумышленнику. Эта проблема легко решается – достаточно не запускать пакет server1 (который содержит примеры) в производственной среде или не устанавливать примеры на этапе создания профиля. Если вы используете базовую версию WebSphere Application Server, вам необходимо удалить примеры из server1.

16. Выберите для процесса соответствующие идентификационные данные

Vulnerable from: Machine

Процессы WebSphere Application Server исполняются под управлением операционной системы и, соответственно, должны обладать теми или иными идентификационными данными (учетной записью операционной системы). С точки зрения учетных записей операционной системы существуют три способа исполнения процессов WebSphere Application Server:

  • все процессы исполняются с учетной записью root;
  • все процессы исполняются с единственной учетной записью пользователя, например, was;
  • агенты узлов исполняются с учетной записью root, а отдельные серверы исполняются с собственными учетными записями.

Корпорация IBM тестирует и полностью поддерживает первые два подхода. Третий подход может показаться привлекательным, поскольку он позволяет воспользоваться разрешениями операционной системы. Тем не менее на практике этот подход не очень эффективен по следующим причинам:

  • высокая сложность конфигурирования и отсутствие документированных процедур. Многие процессы WebSphere Application Server нуждаются в доступе по чтению к многочисленным файлам, а также в доступе по записи к журналам и к каталогам транзакций;
  • при исполнении агента узла как root вы фактически предоставляете администратору WebSphere Application Server (а также любым приложениям, исполняющимся в среде WebSphere Application Server) полномочия root;
  • основная ценность этого подхода состоит в контроле доступа к файловой системе приложениями. Эта же цель может быть достигнута с использованием разрешений Java 2;.
  • этот подход создает ложное впечатление, что приложения изолированы друг от друга. Это не так. Внутренняя модель безопасности WebSphere Application Server основана на безопасности Java EE и Java 2, поэтому на нее не влияют разрешения операционной системы. Таким образом, если вы выбрали этот подход для защиты себя от «фальшивых» приложений, он вводит вас в заблуждение.

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

17. Защитите конфигурационные файлы и секретные ключи

Vulnerable from: Network, Machine

Вам следует ограничить доступ файловой системы к файлам WebSphere Application Server с помощью файловых разрешений операционной системы. Как и любая другая сложная система, продукт WebSphere Application Server использует и обслуживает огромный объем конфиденциальной информации. В общем случае к большей части информации WebSphere Application Server почти никто не должен иметь доступа по чтению или по записи (см. врезку). В частности, конфигурационные файлы WebSphere Application Server (<root>/config) содержат информацию о конфигурации, а также пароли.

Кроме того, избегайте случайного совместного использования ключей. Например, не используйте одни и те же ключи в производственной среде и в какой-либо другой среде. Множество людей будет иметь доступ к машинам разработки и тестирования, а также к их секретным ключам. Тщательно охраняйте производственные ключи.

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

18. Шифруйте соединения от WebSphere Application Server к серверу LDAP

Vulnerable from: Network

При использовании реестра LDAP продукт WebSphere Application Server верифицирует пароль пользователя с помощью стандартной функции ldap_bind. Для этого требуется, чтобы WebSphere Application Server пересылал этот пароль пользователя в сервер LDAP. Если этот запрос не будет зашифрован, то хакер сможет использовать анализатор сети для кражи паролей пользователей, осуществляющих аутентификацию (включая пароли администраторов!). Большинство каталогов LDAP поддерживает технологию LDAP over SSL, и продукт WebSphere Application Server может быть сконфигурирован для ее использования. В панели пользователей LDAP (рисунок 7) проверьте активацию опции «SSL enabled», а затем настройте SSL-конфигурацию, подходящую для вашего каталога LDAP. Скорее всего, вам придется поместить подписывающийся ключ для сертификата LDAP-сервера в хранилище доверенных сертификатов. Наилучшее решение – создать новую SSL-конфигурацию только для LDAP во избежание проблем с существующим порядком использования технологии SSL.

Рисунок 7. Активация SSL для LDAP
Figure 7. Enable LDAP SSL

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

19. Гарантируйте прохождение cookie-файлов LTPA только по протоколу HTTPS

Vulnerable from: Network

Web-приложения используют cookie-файлы для отслеживания пользователей, генерирующих запросы. Хотя эти cookie-файлы, как правило, не являются конфиденциальными сами по себе, они подключают пользователя к его существующему состоянию на серверной системе. Если злоумышленник захватит один из ваших cookie-файлы, он потенциально сможет использовать этот cookie-файл, чтобы действовать от вашего имени. Поскольку сетевой трафик часто проходит по ненадежным сетям (вспомните свою любимую точку доступа WiFi), в которых захват пакетов не вызывает никаких затруднений, важный сетевой трафик должен быть зашифрован с помощью SSL. Это относится и к важным cookie-файлам. Очевидно, что если SSL используется для всех запросов, то все cookie-файлы будут защищены. Тем не менее многие приложения (возможно, случайно) осуществляют некоторые запросы по протоколу HTTP без SSL, чем подвергают cookie-файлы потенциальной опасности. К счастью, спецификация HTTP позволяет приказать браузеру посылать cookie-файлы только по SSL.

В случае WebSphere Application Server самый важный cookie-файл – это cookie-файл LTPA, поэтому конфигурация должна разрешать его пересылку в режиме «только по SSL» (рисунок 8).

Рисунок 8. Разрешение пересылки cookie-файлов LTPA только по SSL
Figure 8. Limit LTPA cookies to SSL only

Вы можете аналогичным образом ограничить возможности пересылки cookie-файла HTTP-сессии (по умолчанию – JSESSION). Для этого необходимо активировать опцию SSL only (только по SSL) в панели управления сессией.

Предостережение. Флаг Requires SSL (см. рисунок 8) не работает в продукте WebSphere Application Server версии V7 до установки служебного пакета под номером APAR PM00610. Не забудьте установить этот пакет.

20. Гарантируйте периодическое изменение ключей шифрования LTPA

Vulnerable from: Network

WebSphere Application Server шифрует различные маркеры пользователей (включая cookie-файл LTPA) с помощью так называемых ключей шифрования LTPA. Как и любые другие криптографические ключи, они должны периодически меняться. В зависимости от версии и уровня исправлений используемого продукта WebSphere Application Server автоматическая генерация ключей может быть по умолчанию включена или выключена; в современных версиях эта опция, скорее всего, по умолчанию выключена.

Вам следует гарантировать периодическое изменение своих ключей LTPA. С этой целью вы можете активировать автоматическую замену LTPA-ключей, как показано на рисунке 9, или повторно генерировать ключи в ручном режиме, как показано на рисунке 10. Вне зависимости от выбранного вами подхода убедитесь в успешном решении проблемы появления несовместимых LTPA-ключей:

  • во-первых, если некоторые узлы в вашей ячейке не были задействованы на протяжении длительных промежутков времени (превышающих срок жизнь ключа примерно вдвое), эти узлы могут потерять способность к коммуницированию;
  • во-вторых, если вы пользуетесь своими ключами LTPA совместно с какой-либо другой стороной (например, с другой ячейкой или с продуктом WebSphere DataPower), то при изменении этих ключей вам придется обновить их везде – как правило, для этого необходима остановка системы.
Рисунок 9. Активация автоматического обновления LTPA-ключей
Figure 9. Enabling automatic LTPA key updates
Рисунок 10. Ручная генерация новых LTPA-ключей
Figure 10. Manually generating new LTPA keys

21. Не задавайте паролей в командной строке

Vulnerable from: Machine

После активирования безопасности административные инструменты WebSphere Application Server будут требовать от вас аутентификации для начала своего функционирования. На первый взгляд, очевидный способ сделать это – указать идентификатор и пароль пользователя в командной строке в качестве параметров для инструментов. Не делайте этого. Это откроет ваш административный пароль любому лицу, заглядывающему через ваше плечо. Кроме того, во многих операционных системах любое лицо, способное увидеть список процессов, сможет увидеть аргументы в командной строке. Вместо этого вы должны гарантировать, что административные инструменты будут предлагать пользователю ввести идентификатор и пароль. В версии WebSphere Application Server V6.0.2 все административные инструменты автоматически предлагают пользователю ввести идентификатор и пароль, если эта информация не была предоставлена в командной строке. Никакие дальнейшие действия не требуются.

При использовании более ранней версии WebSphere Application Server вы можете заставить инструменты действовать указанным образом, для чего специфицировать использование механизма RMI (по умолчанию используется SOAP). Механизм RMI будет по мере необходимости выводить приглашения пользователю. Для этого достаточно ввести следующую спецификацию:

–conntype RMI –port <bootstrap port>

Пример запуска wsadmin с параметрами для подключения к менеджеру развертывания, прослушивающему порт по умолчанию:

wsadmin.sh –connectype RMI –port 9809

Вас раздражает, когда инструменты командной строки в графическом виде генерируют подсказки для ввода идентификатора и пароля пользователя? Вы можете видоизменить это поведение и заставить эти инструменты пользоваться простой текстовой подсказкой. С этой целью измените значение параметра loginSource с prompt на stdin, для чего отредактируйте соответствующий конфигурационный файл. По умолчанию административные инструменты используют SOAP, поэтому необходимо редактировать файл soap.client.props. Если вы используете RMI, то, соответственно, отредактируете файл sas.client.props. Найдите в соответствующем файле свойство loginSource и измените его значение на stdin.

22. Создайте отдельные идентификаторы административных пользователей

Vulnerable from: External

При конфигурировании безопасности для версии WebSphere Application Server V6.1 и старше сначала конфигурируется один идентификатор главного администратора (см. врезку). Этот идентификатор фактически является эквивалентом root в WebSphere Application Server и позволяет выполнять любую административную деятельность (включая все административные роли, упомянутые в следующем разделе). Вследствие важности этого идентификатора не рекомендуется широкомасштабное совместное использование пароля. В идеальном случае этот идентификатор никогда не должен использоваться после завершения начального конфигурирования.

Как и большинство систем, WebSphere Application Server разрешает нескольким специалистам действовать в качестве администраторов. В административном приложении перейдите к разделу консоли системного администрирования под названием Users (Пользователи) или Groups (Группы) для указания дополнительных пользователей или групп, которым следует предоставить административные полномочия. После этого каждый специалист сможет аутентифицировать себя при администрировании WebSphere Application Server. В версии WebSphere Application Server V5.0.2 все административные действия, приводящие к изменению конфигурации WebSphere Application Server, контролируются менеджером развертывания, включая идентификационные данные специалиста, который внес данное изменение. В версии V7 введена новая инфраструктура аудита, способная предоставлять еще больше детальной информации по действиям администраторов. Очевидно, эти аудиторские записи более полезны, если каждый администратор имеет отдельную учетную запись.

Подход с предоставлением отдельным администраторам персонального административного доступа может быть особенно полезен в среде, в которой администраторы централизованно управляют несколькими ячейками WebSphere Application Server. Вы можете сконфигурировать все эти ячейки на совместное использование общего реестра, благодаря чему администраторы смогут использовать одинаковые идентификаторы/пароли для управления всеми ячейками, при этом у каждой ячейки будет иметься собственная локальная учетная запись root с идентификатором/паролем.

23. Пользуйтесь разными административными ролями

Vulnerable from: External

В зависимости от версии WebSphere Application Server поддерживает различные административные роли: Administrator, Operator, Monitor, Configurator, AdminSecurityManager, iscadmins, Deployer, Auditor. Эти роли позволяют предоставить специалистам (и автоматическим системам) доступ, соответствующий их уровню потребностей. Настоятельно рекомендуется использовать роли в любой ситуации, когда это возможно. Использование менее влиятельных ролей Monitor и Operator позволяет ограничить перечень действий, которые сможет предпринять администратор. Например, вы можете позволить младшим администраторам только запускать и останавливать серверы, а ночным операторам – только наблюдать за системой (Monitor). Предоставление специалистам лишь необходимых им разрешений существенно ограничивает риск нанесения ущерба доверенными людьми.

Полная документация по ролям и их полномочиям доступна в Информационном центре по продукту WebSphere Application Server. Тем не менее рекомендую обратить особое внимание на следующие три интересные роли.

  • Monitor: Предоставляя пользователю (или системе) этот уровень доступа, вы позволяете ему осуществлять лишь мониторинг состояния системы; это состояние не может быть изменено, конфигурация системы также не может быть изменена. Например, вы разрабатываете скрипты мониторинга, проверяющие работоспособность системы, и должны организовать локальное хранение идентификатора/пароля пользователя вместе с этим скриптом. В этом случае используйте идентификатор с ролью Monitor. Даже если этот идентификатор будет скомпрометирован, это не приведет к серьезному ущербу.
  • AdminSecurityManager: (добавлена в версии V6.1). Пользователи с этой ролью способны предоставлять административные роли другим пользователям. Сама роль Administrator (администратор) не имеет таких полномочий. Теперь вы можете предоставлять специалистам различные полномочия (даже полномочия Administrator) и быть уверенными в том, что они не смогут предоставить такие же полномочия другим лицам.
  • Auditor: (добавлена в версии V7). Пользователи с этой ролью имеют полномочия только на конфигурирование системы аудита. Администраторы, напротив, могут конфигурировать все, кроме системы аудита. Это обеспечивает четкое разделение обязанностей. Администратор способен изменить конфигурацию, но не может «замести» следы своей деятельности, поскольку не имеет полномочий на отключение функций аудита.

24. Рассмотрите необходимость шифрования канала от Web-сервера к Web-контейнеру

Vulnerable from: Network

Даже если вы решили не осуществлять аутентификацию соединения Web-сервера с Web-контейнером, вы можете рассмотреть возможность шифрования этого соединения. Подключаемый модуль Web-сервера передает информацию от Web-сервера к Web-контейнеру по HTTP. Если какой-либо запрос поступил на Web-сервер с помощью HTTPS, то подключаемый модуль по умолчанию отправит этот запрос дальше также с помощью HTTPS. Если запрос поступил на Web-сервер с помощью HTTP, то подключаемый модуль будет по умолчанию использовать HTTP. Такие настройки по умолчанию подходят для большинства сред. Существует, однако, одно исключение.

В некоторых средах определенная конфиденциальная информация добавляется к запросу уже после того, как он поступил в сеть. Например, некоторые аутентификационные прокси-серверы (такие как WebSEAL) дополнительно вставляют в запрос информацию о пароле. Специализированный код в Web-сервере может делать нечто подобное. В этом случае следует предпринять дополнительные шаги для защиты трафика от Web-сервера к Web-контейнеру. Для принудительного использования HTTPS для всего трафика от подключаемого модуля достаточно отключить HTTP-транспорт от Web-контейнера на каждом сервере приложений, а затем повторно генерировать и развернуть подключаемый модуль (рисунок 11). Теперь подключаемый модуль способен использовать только HTTPS и, соответственно, будет использовать его для всего трафика – вне зависимости от того, каким образом этот трафик поступил в Web-контейнер.

Рисунок 11. Гарантированное применение только HTTPS
Figure 11. Ensuring HTTPS only

25. Используйте только новый формат cookie-файлов LTPA

Vulnerable from: Network, External

(В версии V7 осуществляется по умолчанию).

В версии WebSphere Application Server V5.1.1 введен новый формат cookie-файлы LTPA (LTPAToken2) для поддержки опции subject propagation. При этом также были устранены некоторые теоретические «слабости» старого формата. Следует понимать, что эти «слабости» являются именно «теоретическими», поскольку отсутствует информация о каких-либо связанных с ними случаях компрометации. Тем не менее если у вас нет необходимости по каким-либо причинам использовать предшествующий формат, то желательно использовать новый, более прочный формат.

Новый LTPA-маркер использует следующие методики сильного шифрования:

  • Random salt.
  • сильные AES-шифры;
  • подписывание данных;
  • шифрование данных.

Сведения для любознательных: для подписания используется пара 1024-разрядных RSA-ключей, а для шифрования – секретный 128-разрядный ключ (AES). Для шифрования используется шифр AES/CBC/PKCS5Padding.

По умолчанию старый и новый форматы cookie-файлов поддерживаются одновременно (до версии V7). Эта мера призвана гарантировать совместимость с предшествующими версиями продуктов WebSphere Application Server, IBM Lotus® Domino® (до версии V8) и Tivoli Access Manager WebSEAL (до версии V6) при создании cookie-файлов LTPA. Если вы не нуждаетесь в этой совместимости, следует ее отключить. Для этого перейдите к панели Security > Authentication Mechanisms > LTPA > SSO configuration и снимите флажок в контрольном окошке Interoperability Mode (рисунок 12).

Рисунок 12. Настройка SSO с помощью флажка Interoperability Mode
Figure 12. SSO interoperability mode setting

Предупреждение. В версиях ниже V7 невозможно одновременно отключить опцию Interoperability Mode и опцию Web inbound security attribute propagation (известную также под названием subject propagation). В случае отключения обеих опций аутентификация потерпит неудачу.

26. Шифруйте каналы обмена сообщениями WebSphere MQ

Vulnerable from: Network

Если для обмена сообщениями вы используете WebSphere MQ, а не поставщика услуг по умолчанию, вы, несомненно, должны использовать SSL для WebSphere MQ. Для получения дополнительной информации по этой теме обратитесь к разделу Ресурсы. SSL-конфигурация клиента WebSphere MQ в среде WebSphere Application Server V7 – это первоклассная конструкция, которая может быть построена с помощью консоли администратора, как и любая другая SSL-конфигурация.

27. Шифруйте транспортный канал DCS (distribution and consistency services)

Vulnerable from: Network

Базовые группы (Core group) опираются на механизм DCS, который в качестве транспорта использует RMM-систему (reliable multicast message). RMM может использовать одну из нескольких транспортных технологий для проводных сетей. В зависимости от особенностей среды по DCS может передаваться конфиденциальная информация. Например, данные в DynaCache и в кэш security subject cache передаются с использованием механизма DCS. Чтобы гарантировать защиту этого механизма, для каждой группы Core group выберите для параметра Transport type значение CHANNEL_FRAMEWORK, а для параметра Channel chain name – значение DCS-Secure (рисунок 13).

Рисунок 13. Конфигурирование DCS для использования защищенного соединения
Figure 13. Configuring DCS to use a protected link

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

После этого все сервисы, базирующиеся на механизме DCS, будут использовать зашифрованный и аутентифицированный транспорт. К числу этих сервисов относятся: DynaCache, репликация сессии типа memory-to-memory, группы типа Core group, кэширование Web-сервисов, персистентность компонентов типа stateful session bean и т.д.

28. Защитите сетевое соединение сервера приложений с базой данных

Vulnerable from: Network

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

Ознакомьтесь с примером для IBM DB2.

29. Защитите конфиденциальные cookie-файлы с помощью опции HTTP Only

Vulnerable from: External

Если хакер сможет нарушить работу Web-приложения посредством внедрения злонамеренного кода JavaScript в браузер (так называемый «межсайтовый скриптинг»), то после этого он сможет выполнить любое количество злонамеренных действий, а приложение, по существу, будет скомпрометировано. Одним из многих враждебных действий, которые могут выполнять злоумышленники, является кража конфиденциальных cookie-файлов, таких как LTPA-cookie. Новые Web-браузеры поддерживают концепцию под названием Cookie-файлы с флагом HTTP Only.

Продукт WebSphere Application Server позволяет гарантированно промаркировать все cookie-файлы типа LTPA как HTTP Only. Для этого необходимо присвоить значение true (истина) следующему специальному свойству безопасности: com.ibm.ws.security.addHttpOnlyAttributeToCookies. (Эта опция была добавлена сравнительно недавно – посредством установки пакета APAR PK82764 (V6.0 или V6.1) или PM03760 (V7)).

В настоящее время это свойство защищает только файлы LTPA-cookie с флагом HTTP Only. Для написанного надлежащим образом приложения, которое использует безопасность Java EE и активирует безопасность сессии (описывается ниже), этого должно быть достаточно.

Будущий пакет APAR (PK98436) позволит устанавливать флаг HTTP Only для любых cookie-файлов. Когда эта новая функция станет доступной, используйте ее вместо устаревших функций, поскольку она является более гибкой и более полной. После установки пакета APAR контроль cookie-файлов с целью их защиты будет осуществляться следующим свойством Web-контейнера: com.ibm.ws.webcontainer.httpOnlyCookies. Это свойство представляет собой разделенный запятыми список cookie-файлов, подлежащих защите (символ * обозначает все cookie-файлы).

Предупреждение. Может сложиться впечатление, что пакет APAR решает проблему межсайтового скриптинга, однако это не так. Если хакер способен выполнить в вашем браузере произвольный код, то он может нанести гораздо более серьезный ущерб, чем простая кража ваших cookie-файлов. В действительности злоумышленник сможет видеть все, что отображается на экране браузера и регистрировать каждое нажатие клавиши – а это гораздо более серьезная угроза, чем кража cookie-файлов.

30. Научите пользователей правильно понимать предупреждения сертификатов

Vulnerable from: Network

При использовании SSL в коммуникационных целях важнейшим элементом безопасного обмена информацией является валидация сертификата сервера с помощью хранилища доверенных сертификатов клиента. Если сервер представил сертификат, который не заслуживает доверия, поскольку подписавшая его сторона не указана в упомянутом выше хранилище доверительных сертификатов, большинство клиентов (Web-браузеры, SSH, wsadmin и т.д.) обращаются к пользователю и предлагают ему решить, что делать дальше. Как правило, эти клиенты предупреждают пользователя о неизвестном сертификате, представляют «отпечаток пальца» (как правило, SHA) этого сертификата и спрашивают, следует ли доверять этому сертификату? К сожалению, большинство пользователей бездумно нажимает на кнопку Да. Это очень плохое решение. Если вы поступите таким образом, вы не будете иметь представления о том, с каким сервером общаетесь. А при работе с административными клиентами WebSphere Application Server вы в подобной ситуации даже сможете отослать неизвестной стороне идентификатор/пароль своего административного пользователя!

Вместо этого администраторы (а в идеальном случае – и конечные пользователи) должны исследовать информацию отпечатка пальца и определить, является ли он корректным. Административные инструменты позволяют увидеть отпечаток пальца сертификата. Выберите в консоли администратора опцию Personal certificates. Отпечаток пальца исследуемого сертификата будет демонстрироваться в окошке Fingerprint (рисунок 14).

Рисунок 14. Отпечаток пальца сертификата
Figure 14. Certificate fingerprint

Пользователю (особенно администратору) следует ознакомиться с информацией отпечатка пальца, а затем, при получении соответствующей подсказки от клиента (Web-браузер или wsadmin), осуществить валидацию сертификата (это идеальный вариант).

Рисунок 15. Предупреждение о сертификате Web-сервера, часть 1
Figure 15. Web server certificate warning, Part 1
Рисунок 16. Предупреждение о сертификате Web-сервера, часть 2
Figure 16. Web server certificate warning, Part 2
Листинг 2. Предупреждение wsadmin о сертификате
./wsadmin.bat
*** SSL SIGNER EXCHANGE PROMPT ***
SSL signer from target host localhost is not found in trust store 
	C:/IBM/WebSphere/AppServer/profiles/AppSrv02/etc/trust.p12
Here is the signer information (verify the digest value matches what 
	is displayed at the server):
Subject DN:    CN=keysbotzum, O=IBM, C=US
Issuer DN:     CN=keysbotzum, O=IBM, C=US
Serial number: 1151337276
Expires:       Tue Jun 26 11:54:36 EDT 2007
SHA-1 Digest:  53:43:75:86:A8:C3:55:15:98:35:54:E7:49:B7:15:AF:16:A9:53:6F
MD5 Digest:    29:36:B1:9C:22:5A:36:AD:78:B3:7E:FD:D3:B1:B4:19
Add signer to the trust store now? (y/n)

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

31. Тщательно ограничивайте число доверенных подписывающих сторон

Vulnerable from: Network, External

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

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

  • По умолчанию «подписывающие стороны» dummyclientsigner и dummyserversigner присутствуют в доверительных хранилищах с целью обеспечения их совместимости с ячейками от предыдущих выпусков, в которых эти стороны используются по умолчанию (мы всегда рекомендовали не поступать подобным образом). Они не присутствуют по умолчанию в версии V7.
  • По умолчанию в хранилищах ключей KDB/CMS присутствуют подписывающие стороны, представляющие большинство хорошо известных центров сертификации. Для этого не существует каких-либо обоснований с точки зрения полезности или других факторов, поэтому эти стороны должны быть удалены.
  • В версии V7 хранилище доверенных сертификатов ячейки по умолчанию содержит подписывающий сертификат WebSphere DataPower, т.е. подразумевается, что все машины DataPower способны выпускать сертификаты, которым будут доверять серверы приложений. С целью обеспечения максимального уровня безопасности этот сертификат должен быть удален.

32. Ограничьтесь только прочными шифрами

Vulnerable from: Network

(В версии V7 осуществляется по умолчанию).

При коммуницировании с использованием технологии SSL трафик подвергается шифрованию. Для наилучшей защиты этого трафика следует использовать прочные криптографические шифры. К сожалению, в версиях ниже V7 имеет место следующая ситуация: в предлагаемом по умолчанию перечне прочных SSL-шифров присутствуют некоторые явно слабые шифры. Следует удалить эти шифры, чтобы клиент не смог выбрать какой-либо из них. В обычных условиях клиенты выбирают прочные шифры неявным образом, если Web-сервер поддерживает их, однако лучше иметь полную уверенность в этом вопросе (рисунок 17).

Рисунок 17. Шифры SSL
Figure 17. SSL ciphers

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

33. Обеспечьте принудительное использование транспорта CSIv2 over SSL

Vulnerable from: Network

Когда серверы и клиенты WebSphere Application Server коммуницируют с использованием CSIv2 IIOP, они договариваются о безопасности транспорта. При этом выбирается тот вариант, который является приемлемым для обеих сторон. В общем случае это работает прекрасно, однако следует иметь представление об одной потенциальной «слабости». Продукт WebSphere Application Server поддерживает CSIv2 over SSL или открытый текст. По умолчанию обе стороны стараются договориться об использовании SSL, что гарантирует шифрование коммуникационного канала. Тем не менее если какая-либо сторона в процессе переговоров запросит открытый текст, то будет использоваться именно открытый текст. Вы можете даже не осознавать, что ваш трафик отправляется в открытом виде! Например, это может произойти, если клиент был неправильно сконфигурирован. Если вы хотите гарантировать шифрование трафика (что было бы весьма желательным), то для повышения безопасности следует активировать постоянное использование SSL.

Для того чтобы гарантировать принудительное использование SSL для IIOP, на панели CSIv2 inbound transport (входящий транспорт CSIv2) выберите пункт SSL-required (требуется SSL), как показано на рисунке 18. На панели CSIv2 outbound transport (исходящий транспорт CSIv2) следует поступить аналогичным образом.

Рисунок 18. Активация использования только SSL
Figure 18. Configuring SSL only

34. Рассмотрите необходимость фильтрации портов

Vulnerable from: Network

В некоторых случаях желательно ограничить перечень сторон, имеющих возможность подключения, используя с этой целью сетевую информацию. Хотя с точки зрения безопасности этот подход имеет сомнительную значимость, он рассматривается в этой статье для полноты картины. Большинство транспортных протоколов в WebSphere Application Server (за исключением IIOP) использует инфраструктуру Channel Framework, что позволяет фильтровать входящий трафик по IP-адресам или по DNS-именам, содержащимся в списке включений или списке исключений (рисунок 19).

Рисунок 19. Фильтрация портов
Figure 19. Port filtering

Предостережение. Подделка IP-адреса осуществляется достаточно просто, поэтому полагаться на фильтрацию IP-адресов для обеспечения безопасности – это не самый разумный подход. Особенно неблагоразумно осуществлять фильтрацию по IP-адресам в среде WebSphere Application Server. Межсетевые экраны и коммутаторы обладают более мощными возможностями для распознавания ситуации, когда пакеты поступают с IP-адресов, которые не могут быть валидными. Кроме того, эти устройства способны проверять MAC-адреса.

35. Отключите неиспользуемые порты

Vulnerable from: Network, External

Основной принцип укрепления безопасности состоит в минимизации уязвимой области для возможных атак. Это положение справедливо даже для сервисов, у которых не выявлено никаких проблем безопасности. Если для корректного функционирования системы какой-либо сервис не требуется, его следует удалить – это сведет к минимуму вероятность того, что злоумышленник когда-либо в будущем сможет воспользоваться этой дополнительной функциональностью. Как показано на рисунке 20, типичное приложение WebSphere Application Server способно прослушивать большое количество портов.

Рисунок 20. Порты по умолчанию для сервера приложений редакции Network Deployment
Figure 20. Default ports for a Network Deployment application server

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

  • SAS_SSL_SERVERAUTH_LISTENER_ADDRESS: используется для совместимости с версией WebSphere Application Server V4 и ниже. Это старый протокол безопасности IIOP. Начиная с версии V5, он заменен протоколом CSIv2.
  • SIB_ENDPOINT_*: эти порты используются встроенным механизмом обмена сообщениями. Если вы не используете обмен сообщениями, то вы не нуждаетесь и в этих портах.
  • SIB_MQ_*: эти порты используются механизмом обмена сообщениями при соединении с WebSphere MQ.
  • WC_adminhost*: эти порты используются для доступа Web-браузера администратора. Если ваш сервер приложений не является менеджером развертывания, их следует деактивировать в обязательном порядке. К сожалению, большинство Web-контейнеров серверов приложений прослушивает два административных порта даже в том случае, когда на этих серверах отсутствуют какие-либо административные приложения. Это вызвано тем, что обычно серверы создаются на базе шаблона server1, в который включены эти порты. Вам следует деактивировать или удалить эти порты на всех серверах приложений.
  • WC_defaulthost*: это порты, прослушиваемые Web-контейнером по умолчанию. Если вы добавили для прослушивания специальные порты, то эти порты могут больше не потребоваться.

В зависимости от реализации разных портов для их деактивации требуются разные методики.

  • Порт SAS_SSL_SERVERAUTH_LISTENER_ADDRESS может быть деактивирован посредством выбора CSI в качестве активного протокола на панели глобальной безопасности. В версии V7 порт SAS деактивирован по умолчанию, хотя он по-прежнему присутствует в списке.
  • • Все порты WC_* относятся к Web-контейнеру. Удаление, изменение или отключение этих портов проще всего осуществить в панели конфигурации транспортной цепочки (transport chain) Web-контейнера (Application servers > servername > Web container > transport chain). Вам необходимо прослушивать только те Web-порты, которые используются вашими приложениями.
  • Порты SIB_* не запускаются, если не активирован механизм обмена сообщениями. Таким образом, никаких действий для этих портов не требуется.

Предостережение: Используйте максимальную осторожность при выборе портов для деактивации и при выборе момента для фактической деактивации выбранных портов. В противном случае вы можете непреднамеренно деактивировать один из административных портов, в результате чего останетесь без механизма для администрирования процесса, за исключением возможности удаления и повторного создания определения процесса (например, сервера).

36. Рассмотрите необходимость деактивации кэширования пароля

Vulnerable from: External

При проведении аутентификации по паролю среда исполнения кэширует пароль (для будущей валидации) в виде однонаправленной хэш-функции. Поскольку эта хэш-функция не является обратимой, захват пароля злоумышленником не представляет никакой опасности (даже из дампа памяти). Тем не менее использование этого кэша действительно может привести к определенным последствиям. При будущем поступлении запросов, нуждающихся в аутентификации и использующих прежнее сочетание идентификатор/пароль пользователя, будут использованы кэшированные данные пароля (и сведения о пользователе). Другими словами, если пароль пользователя в реестре меняется, этот пользователь по-прежнему сможет аутентифицировать себя с помощью старого пароля до тех пор, пока не истечет срок жизни кэша (который по умолчанию составляет 10 минут).

Some consider this to be a security vulnerability (the author is not among them). Некоторые специалисты полагают, что это уязвимость в системе безопасности (автор не относится к их числу). При желании вы можете отключить кэширование паролей с помощью следующего свойства уровня JVM: com.ibm.websphere.security.util.authCacheEnabled = BasicAuthDisabled. После этого пароли больше не будут кэшироваться, а любая попытка аутентификации по паролю приведет к запросу реестра. Следует помнить, что этот подход может оказать существенное отрицательное влияние на производительность. Использование протокола, который не хранит информацию о состоянии (stateless) и аутентифицируется на каждом запросе (например, WS-security с UserNameTokens), может порождать мощный аутентификационный трафик.

37. Рассмотрите необходимость активации совместимости со стандартами FIPS

Vulnerable from: Network

Существуют разнообразные криптографические алгоритмы, из которых можно выбирать при необходимости выполнения шифрования. Кроме того, при установке SSL-соединения фактически существуют три возможных варианта: SSL V2 (деактивирован по умолчанию), SSL V3 и TLS. Государственные органы США разработали стандарты компьютерной безопасности (FIPS – федеральные стандарты США по обработке информации), которые охватывают многие области. В рамках этих стандартов некоторые шифры специально сертифицируются как соответствующие требованиям FIPS. Кроме того, они также сертифицируются на соответствие требованиям TLS (но не SSL V3).

Пользователи, желающие разрешить своим приложениям использование лишь шифров, соответствующих требованиям FIPS и TLS, могут сконфигурировать каждую конечную точку в ручном режиме или просто активировать необходимость соответствия требованиям FIPS с помощью административных инструментов. После активации соответствия требованиям FIPS будет использоваться только криптография, соответствующая требованиям FIPS.


Заключение

В первой части данной серии статей, состоящей из двух частей, рассматривается несколько аспектов безопасности, при этом основной темой является укрепление безопасности среды WebSphere Application Server. Эта информация играет роль фундамента, необходимого читателю для надежной защиты своей среды Java EE.

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

Если вы хотите узнать больше о безопасности WebSphere Application Server, обратитесь на Web-сайт IBM Software Services for WebSphere и пройдите персонализированное онлайновое обучение по защите WebSphere Application Server. Это углубленное обучение охватывает такие вопросы, как укрепление безопасности, настройка аутентификации, интеграция, единый вход в систему и множество других связанных тем.


Благодарности

Автор выражает благодарность за ценный вклад и содействие при написании этой статьи следующим своим коллегам: Martin Lansche, Bill Hines, Bill O’Donnell, Paul Ilechko, Simon Kapadia, Tom Alcott.

Ресурсы

Научиться

Получить продукты и технологии

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=WebSphere
ArticleID=852085
ArticleTitle=Укрепление безопасности WebSphere Application Server V7: Часть 1. Общий обзор и подходы к укреплению безопасности
publish-date=12172012