На этой странице приведены рекомендации, которые, насколько нам известно, помогут предотвратить атаки безопасности на вашу установку JIRA.
Использовать надежные пароли
Администраторы должны использовать надежные пароли
Все администраторы JIRA, системные администраторы JIRA и администраторы всех продуктов Atlassian должны иметь надежные пароли. Попросите ваших администраторов обновить свои пароли на надежные пароли.
Не используйте пароли, которые являются словарными словами. Используйте буквы смешанного типа, цифры и символы для паролей администратора и убедитесь, что они достаточно длинны (например, 14 символов). Мы рекомендуем вам обратиться к генератору сильных паролей для получения рекомендаций по выбору паролей.
Использование надежных паролей значительно увеличивает время, требуемое хакерам для извлечения ваших паролей. Использование хакерами метода многократных попыток входа в систему, делает такую атаку непрактичной.
Администраторы должны иметь разные пароли для разных систем
Помимо выбора надежного пароля, администраторы должны иметь разные надежные пароли для разных систем.
Это уменьшит влияние, которое может оказать хакер, если ему удастся получить учетные данные администратора на одной из ваших систем.
Применение патчей безопасности JIRA
Примените исправления, найденные в любых рекомендациях по безопасности, которые мы публикуем для вашей версии JIRA.
Эти исправления защищают JIRA от недавно обнаруженной эскалации привилегий и уязвимостей XSS.
Защита от жестокой атаки
Вы также можете активно защищать свои системы от повторных неудачных попыток входа в систему, известных как атаки «грубой силы».
Включение защиты входа против «грубой силы» в систему Brute на веб-сервере
Также можно включить защиту входа в систему с использованием переборки на вашем веб-сервере, обнаружив повторные ошибки аутентификации в журналах приложений. После того, как обнаружены повторные попытки входа в систему, вы можете настроить автоматическую систему для запрета доступа к вашему веб-серверу с этого конкретного IP-адреса.
Для получения дополнительной информации о том, как настроить автоматизированный подход к этому виду предотвращения входа, см. в разделе «Использование Fail2Ban для ограничения попыток входа в систему».
Ограничение сетевого доступа к административным разделам приложений
Интерфейс администрирования приложения Atlassian является важной частью приложения; любой, кто имеет доступ к нему, может потенциально поставить под угрозу не только экземпляр приложения, но и всю машину. Помимо ограничения доступа только к тем пользователям, которые действительно нуждаются в нем, и использованию надежных паролей, вы должны ограничить доступ к ним определенным машинам в сети.Для получения дополнительной информации о том, как реализовать правила блокировки Apache, чтобы ограничить доступ к административным или чувствительным действиям в:
- JIRA, см. «Использование Apache для ограничения доступа к интерфейсу администрирования JIRA».
- Confluence, см.« Использование Apache для ограничения доступа к интерфейсу администрирования Confluence».
Вы можете использовать аналогичный подход для защиты всех приложений Atlassian.
Ограничение доступа к файловой системе серверам приложений
Сервер приложений (например, Tomcat) работает как процесс в системе. Этот процесс выполняется конкретным пользователем и наследует права файловой системы этого конкретного пользователя. Ограничивая каталоги, которые могут быть записаны пользователем сервера приложений, вы можете ограничить ненужное воздействие вашей файловой системы на приложение.
Например, убедитесь, что на сервер приложений JIRA может быть записано только следующие каталоги:
-
Следующие подкаталоги вашего каталога установки JIRA для «рекомендуемых» дистрибутивов JIRA (или для дистрибутивов JIRA WAR, каталог установки приложения Apache Tomcat с JIRA):
- logs
- temp
- work
- Ваш домашний каталог JIRA. Подробные инструкции см. в лучших рекомендациях по безопасности Tomcat.
Отключить Jelly
Jelly отключено в JIRA по умолчанию. Если вам нужно использовать Jelly, вы должны включить его непосредственно перед использованием и немедленно отключить его после. Подробнее см. «Документацию JIRA Jelly Tags».
Настройка «Tomcat для использования файлов HttpOnly Session ID»
«Рекомендуемые» (ранее автономные) дистрибутивы JIRA из версии 4.1.2 по умолчанию применяют флаг HttpOnly к файлам cookie идентификатора сеанса как средство минимизации риска общих атак XSS. Для получения дополнительной информации об этой функции обратитесь к JIRA Security Advisory 2010-06-18.
Если вы используете дистрибутив JIRA WAR на Tomcat (версия 5.5.27+ или другой сервер приложений, который не поддерживается), вполне вероятно, что cookie идентификатора сеанса JIRA не будет передаваться с помощью флага HttpOnly. Следовательно, чтобы снизить риск общих атак XSS, мы рекомендуем настроить сервер приложений для передачи файлов cookie HttpOnly.
Для того чтобы настроить распределение JIRA WAR на Tomcat для использования файлов HttpOnly Session ID Cookies, выполните следующие шаги:
Этот файл обычно находится в подкаталоге conf основного каталога установки Tomcat.
…
<Context useHttpOnly=”true”>
… <Manager/> … </Context> …
Чтобы отключить cookies HttpOnly Session ID, измените значение параметра useHttpOnly на false.
Смотрите также
Если вы подозреваете, что ваша общедоступная установка JIRA была скомпрометирована атакой безопасности, обратитесь к нашему руководству по обнаружению для получения дополнительной информации о том, как идентифицировать признаки атаки.
–