То, что 'глюк' разработчик программного обеспечения, должно высматривать, если определено задачу с установкой производства готовый сервер?
Что-то неправильно со сценарием, если бы Ваше использование Ubuntu я предложил бы su'ing учетной записи ejabberd и попытался бы запустить скрипт. У меня была подобная проблема, где она отказывалась проходить проверку подлинности из-за проблем разрешения, когда сценарий пытался открыть файл журнала.
Существует множество общих правил, применимых ко всем типам серверов, например:
Удалите неиспользуемое программное обеспечение и отключите неиспользуемые порты / службы. Они тратят ресурсы и представляют собой возможную уязвимость.
Постоянно применяйте исправления и обновления, особенно при обнаружении какой-либо ошибки или уязвимости.
Измените все пароли по умолчанию и / или отключите гостевые учетные записи / учетные записи по умолчанию, когда это возможно.
Используйте надежные пароли.
Используйте SSL для защиты ваших транзакций, когда это применимо и целесообразно.
Кроме того, для каждой конкретной службы можно найти несколько советов по ее защите.
Есть ли руководство по AZ для манекенов по установке и защите производственный сервер?
Нет. Для этого существует слишком много возможных комбинаций программного обеспечения, кода, платформы, оборудования и т. Д. Однако если вы разделите свой стек, вы найдете полезную информацию для каждого уровня (например, усиление защиты вашей ОС, лучшие практики безопасности веб-приложений и т. Д.).
Сильно ли различается процесс в зависимости от платформы (Windows или Linux)?
Процесс усиления защиты такой же, но детали реализации - нет.
Существуют ли какие-то общие правила, которые можно применять на разных платформах (и стеках приложений)?
Да. Вы должны создать профиль конфигурации вашего приложения: задокументировать зависимости вашего приложения (любые службы, которые должны быть запущены; любые сетевые порты / протоколы, которые должны быть открыты (входящие и исходящие); любые сторонние библиотеки / компоненты) для установки базовые требования для работы вашего приложения. Систематически удаляйте / отключайте любые службы, приложения и порты, которые вам не нужны; запускать службы и приложения с минимальными необходимыми привилегиями. Испытайте каждый шаг на пути; вы что-нибудь сломаете.
Приобретите соответствующий брандмауэр и включите фильтрацию исходящего трафика (если ваш компьютер перейдет в собственность, не позволяйте ему устанавливать прямые TCP-соединения); используйте прокси из белого списка, чтобы разрешить исходящий HTTP только для необходимых обновлений (windowsupdate.com и др., репозитории Linux). Настройка предупреждений и надлежащее ведение журнала: предупреждение о неудачных попытках входа в систему, запуске / остановке служб, установке, повышении привилегий и т. Д. Важное значение имеет управление исправлениями; разработать разумное окно обслуживания и придерживаться его. Не позволяйте обновлениям накапливаться слишком долго.
Если это веб-приложение, просмотрите свои точки входа, сопоставления HTTP-глаголов с URI и внесите в белый список свои параметры POST или GET, очистите формы (не доверяйте никаким входным данным), экранируйте свой SQL (или используйте сторонняя библиотека, которая делает это за вас), регистрируйте все ваши SQL-запросы, и т. д.
В дополнение к ответу Халеда :
Измените имена учетных записей по умолчанию, включая:
saимя учетной записи в SQL Server или MySQLимя учетной записи администраторав Windows- любое имя учетной записи администратора по умолчанию в любом другом продукте с удаленным доступом (Plesk, Wordpress и т. д.)
В случае SQL Server или любого другого сервера БД отключите удаленные подключения, если необходимо, и если они необходимы, рассмотрите возможность блокировки портов, используемых сервером, и занесения в белый список разрешенных IP-адресов.
используйте брандмауэр, такой как iptables, и уделите время планированию того, какие подключения к машине должны быть возможными и необходимыми. ограничивать входящий И ДАЖЕ исходящий трафик.
Специальный совет для tomcat: привяжите его порты к localhost и используйте соответствующий веб-сервер (например, apache httpd) в качестве интерфейса. Многие из последних слабых мест tomcat могли быть использованы только в том случае, если у вас был доступ к приложению-менеджеру.
Так что, если ваше приложение запущено и работает, неплохо также избавиться от приложения-менеджера. Отключите автоматическое развертывание.
В полной мере используйте различные роли - веб-серверу httpd не нужен доступ на уровне операционной системы к файлам, которые предоставляет tomcat, и наоборот. Так что, если кто-то использует уязвимость httpd и переходит к командной строке, убедитесь, что он не может написать ничего важного.
Взгляните на ISO 27001 - есть также форум обмена стеками, который специализируется на безопасности ].