В таком случае это плохое поле для экспериментов. Процесс Apache обслуживает как 80 так и 443 порт, который подвержен атаке CVE-2009-3555, в случае которой вы получите не работоспособность обоих протоколов.
Пожалуйста, обратите этому моменту достаточное внимание.
К огромному сожалению, SSL имеет очень запутанные настройки и много тонкостей в реализации. Шаг влево, шаг вправо — можно получить противоположный безопасности результат. При запуске SSL сервера обязательно нужно делать независимые проверки или хотя бы пользоваться сторонними сервисами тестирования.
Если сейчас взглянуть на mail.ru через www.ssllabs.com/ssltest/analyze.html?d=mail.ru (Пример для одного из серверов в кластере: www.ssllabs.com/ssltest/analyze.html?d=mail%2eru&s=94%2e100%2e191%2e241 ) то можно увидеть несколько серьезных проблем:
Разрешение использовать SSL v.2.0, подверженность атаке CRIME и атаке BEAST, DDoS атаке CVE-2009-3555
Все проблемы закрываются корректными настройками веб-серверов, но естественно нужно дополнительно протестировать как поведет себя сервис под нагрузкой.
Почему стоит обратить на это внимание — хотя CRIME и BEAST сложны в исполнении, но есть внутреннее ощущение, что низкая энтропия urandom делают возможность атаки более, чем вероятной.
IMHO при такой нагрузке имеет смысл использовать аппаратный генератор случайных чисел — это сильно разгружает CPU и сохраняет высокий уровень энтропии.
Почему стоит закрывать возможность для DDoS — говорить не стоит :)
Для данного типа проникновения лучше запрещать исполнение скриптов из каталогов в которые можно загружать файлы. Это более простой и быстрый способ. SELinux хорош при обслуживании больших проектов, для глобального контроля безопасности. Настраивать каждый раз на маленьких проектах не всегда удобно (хотя желательно это делать).
Наличие DRAC еще не означает полный контроль, тк существуют разные типы лицензий и не во все включены «Virtual Console and Media».
Еще, как правило, крупные западные ДЦ давно работают с серверами у которых по умолчанию есть «панели управления». Чего не скажешь про отечественные ДЦ, где на получение KVM необходимо становиться в очередь и пользоваться ограниченное время.
Да, в DRAC5 есть проблема работы с браузерами кроме IE. Но эта проблема решена в DRAC6. DRAC7 еще более стабильный.
Справедливости ради скажу, что имел достаточно большой опыт работы с панелями разных производителей — самой надежной и отлаженной является DRAC Dell'а. Кроме того Dell вкладывает достаточно много средств в исправление ошибок и совершенствование своей панели, чего не скажешь об остальных производителях.
Эффективнее использовать перенос подняв rsync-демон на бакапном сервере и использовать для авторизации rsync password-file, вместо ssh-ключей. Передача данных в таком случае значительно вырастет, особенно актуально при больших объемах передаваемых данных.
Пожалуйста, обратите этому моменту достаточное внимание.
Если сейчас взглянуть на mail.ru через www.ssllabs.com/ssltest/analyze.html?d=mail.ru (Пример для одного из серверов в кластере: www.ssllabs.com/ssltest/analyze.html?d=mail%2eru&s=94%2e100%2e191%2e241 ) то можно увидеть несколько серьезных проблем:
Разрешение использовать SSL v.2.0, подверженность атаке CRIME и атаке BEAST, DDoS атаке CVE-2009-3555
Все проблемы закрываются корректными настройками веб-серверов, но естественно нужно дополнительно протестировать как поведет себя сервис под нагрузкой.
Почему стоит обратить на это внимание — хотя CRIME и BEAST сложны в исполнении, но есть внутреннее ощущение, что низкая энтропия urandom делают возможность атаки более, чем вероятной.
IMHO при такой нагрузке имеет смысл использовать аппаратный генератор случайных чисел — это сильно разгружает CPU и сохраняет высокий уровень энтропии.
Почему стоит закрывать возможность для DDoS — говорить не стоит :)
Еще, как правило, крупные западные ДЦ давно работают с серверами у которых по умолчанию есть «панели управления». Чего не скажешь про отечественные ДЦ, где на получение KVM необходимо становиться в очередь и пользоваться ограниченное время.
Да, в DRAC5 есть проблема работы с браузерами кроме IE. Но эта проблема решена в DRAC6. DRAC7 еще более стабильный.
Справедливости ради скажу, что имел достаточно большой опыт работы с панелями разных производителей — самой надежной и отлаженной является DRAC Dell'а. Кроме того Dell вкладывает достаточно много средств в исправление ошибок и совершенствование своей панели, чего не скажешь об остальных производителях.
rsa, dsa зависит какой ключ был сгенерирован