Я понимаю Ваше разочарование, поскольку мы имеем дело в большой степени с изображениями Windows на EC2, и как потребитель и как поставщик решения/инструмента управления EC2.
Пустое извлечение журнала является огромным раздражением и, кажется, просто происходит время от времени. Я связался с Amazon об этом, и общий ответ состоит в том, что иногда информация о журнале является пробелом... Не очень для продолжения, таким образом, я просто сообщаю своей собственной связи об этом.
Перезагрузки экземпляров Windows EC2 также раздражают меня. После многих неудавшихся перезагрузок я могу только рекомендовать наготове восстановить изображение и базу данных в случае необходимости. Я провел много часов, ища информацию о задержках перезагрузки на EC2, и обычно существует два результата:
Удачи!
Я предпринял несколько шагов для защиты своих серверов:
Первый очевиден:
Не запускать ssh на стандартном порту избавит вас от обычных атак со скриптами. .
Второй - также состояние-of -art:
Использовать демон стука. Демон стука сначала ожидает последовательности ударов по определенным портам и протоколам, прежде чем открыть порт для ssh-соединения на сервере. Таким образом, ssh-сервер невидим для злоумышленников, пока они не попадут в нужную последовательность портов клиентом knock. Большинство реализаций демонов knock-daemon предоставляют механизм для интеграции транзакционных последовательностей, поэтому последовательность стуков изменяется после каждого успешного входа в систему.
С этой стандартной настройкой вам предоставляется немного больше уровня безопасности.
Также рекомендуется использовать зашифрованные имена пользователей и пароли и ограничить вход по ssh определенным (не root) пользователем. Затем вы можете переключиться на пользователя root на сервере при выполнении задач root.
Установка системы мониторинга, такой как nagios, также обеспечивает большую безопасность для вас и вашей среды, ее легко настроить и она также предоставляется через систему упаковки ubuntu. Вы можете настроить его так, чтобы он отправлял вам электронные письма, когда кто-то входит на ваш сервер через ssh, чтобы вы, по крайней мере, получили информацию, необходимую для дальнейшего расследования.
Но, честно говоря: если кто-то получил доступ к вашему серверу как root , вам следует сделать полную переустановку всего. Могут быть замены двоичных файлов, которые нелегко обнаружить, с введением бэкдоров. Представьте, что вы запускаете простую команду, такую как useradd, и двоичные файлы были заменены, так что во время выполнения команды открывается TCP-соединение, а учетные данные пользователя отправляются вашему злоумышленнику. Или, что еще хуже: двоичный файл ssh-server был заменен специальной версией, которая разрешает доступ через определенную комбинацию пароля пользователя.
Вместо использования ограничений на основе IP вы можно настроить вход без пароля с помощью сертификатов.
Вам нужно будет разместить публичный сертификат на сервере, к которому вы обращаетесь. Вам нужно будет убедиться, что разрешения на необходимые файлы в ~ /.