Безопасно ли разрешить входящий 0.0.0.0/0 в группе безопасности EC2?
Я создал экземпляр EC2 на AWS, и мне была назначена «группа безопасности» по умолчанию. Я понимаю, что это действует как виртуальный брандмауэр для моего сервера.
я имел беда подключение к этому экземпляру EC2 с помощью SSH, и выяснилось, что проблема заключалась не в установке для параметра "Источник" значения 0.0.0.0/0 в группе безопасности «Правила для входящих подключений», как показано на изображении ниже.
Насколько безопасно хранить это так, или мне следует ограничить источник IP-адресом моей домашней сети?
Никто не может подключиться к моему экземпляру EC2 по ssh без файла * .pem, верно?
Безопасность работает не двоично. Ваши экземпляры никогда не бывают «безопасными».
Существуют сотни или тысячи векторов атак, и вы принимаете рентабельные решения, чтобы обеспечить защиту от некоторых из этих векторов. Полностью защищаться от них непомерно дорого.
В вашей ситуации ваша система может иметь уязвимость в любой службе / приложении, которое прослушивает сетевой интерфейс, например, вызывая утечку данных.
Вы открыли все порты TCP и UDP. Достаточно иметь TCP / 22, если вы хотите использовать этот * .pem и любой другой порт, который вам нужен.
Даже OpenSSH может иметь уязвимость. Следовательно, да, лучше иметь только диапазон IP-адресов вашей домашней сети.
Безопасность подобна луку - все дело в слоях, вонючих слоях, подобных людоеду.
Разрешив соединения SSH отовсюду, вы удалили один уровень защиты и теперь зависите исключительно от ключа SSH, который в настоящее время считается безопасным, но в будущем может быть обнаружен недостаток, уменьшающий или удаляющий этот уровень.
А когда слоев больше нет, у вас ничего не остается.
Быстрый уровень - установить fail2ban или аналогичный. Эти демоны отслеживают ваш файл auth.log, и в случае сбоя подключения SSH их IP-адреса добавляются в iptables цепочку на время. Это уменьшает количество попыток подключения клиентом каждый час / день. Я заканчиваю занесение в черный список плохих источников на неопределенный срок, но хосты, которые должны отключать SSH, беспорядочно прослушивая, все равно могут получать 3000 неудачных попыток входа в систему root в день. Большинство из них из Китая, за ними следуют Восточная Европа и Россия.
Если у вас есть статические исходные IP-адреса, то включение их в политику группы безопасности - это хорошо, а это означает, что остальной мир не может подключиться. С другой стороны, что делать, если по какой-то причине вы не можете зайти с авторизованного IP-адреса, например, ваш интернет-провайдер работает динамически или ваша ссылка не работает?
Разумным решением является запуск VPN-сервера на вашем экземпляре, прослушивание всех исходных IP-адресов, а затем, когда туннель открыт, подключиться через туннель через SSH. Конечно, это не идеальная защита, но это еще один слой в вашем щите. абляционная броня... OpenVPN - хороший кандидат,
Вы также можете использовать решение AWS «Client VPN», которое представляет собой управляемый OpenVPN, предоставляющий доступ к вашему VPC. Нет личного опыта в этом, жаль.
Другие (правда, тонкие) уровни предназначены для переноса SSH на другой порт. На самом деле это не делает ничего, кроме уменьшения количества зондов script-kiddy, которые по умолчанию используют порт 22 / tcp. Любой, кто изо всех сил старается, просканирует все порты и найдет ваш SSH-сервер на 2222 / tcp или 31337 / tcp или где-то еще.
Если возможно, вы можете исследовать только IPv6 ssh, опять же, он просто ограничивает доступ, не добавляя реальной безопасности. Количество незапрошенных SSH-подключений на IPv6 в настоящее время намного меньше, чем в IPv4, но все еще не равно нулю.
Если бы программное обеспечение было идеальным, вы могли бы оставить свой сервер полностью открытым для Интернета, как и у вас, но на практике есть ошибки и другие способы скомпрометировать сервер.
Лучшая практика - открывать определенные порты только для минимального количества IP-адресов для достижения ваших целей. Например:
- Откройте порт 22 (SSH) только для тех IP-адресов, которые этого требуют, например для домашнего или рабочего IP-адреса.
- Откройте для всего мира порты 80 и 443, если вы хотите обслуживать веб-трафик. Однако, если вам нужна дополнительная защита, вы можете использовать CDN / WAF, например CloudFront / CloudFlare (у которого есть бесплатный уровень), и открывать только 443/80 для IP-адресов CloudFlare.
- Открывайте порты базы данных для определенных IP-адресов только при необходимости. Если вы это сделаете, ваша база данных должна быть настроена для приема этих подключений, которых RDS не по умолчанию.
Вы склонны открывать другие порты только в случае крайней необходимости и с минимальным количеством IP-адресов, которое позволит вам достичь того, что вам нужно.
Чем строже вы можете быть со своими правилами, тем лучше.
Стоит отметить, что некоторые домашние интернет-провайдеры будут использовать динамические адреса, и если в какой-то момент вы не можете подключиться к своему экземпляру, сначала проверьте это.