Случайно наткнулся на дискуссию трехмесячной давности, о необходимости переноса порта SSH. Очень много участников дискуссии убеждено в отсутствии необходимости переноса порта на нестандартный порт.
Достаточно перейти на авторизацию по ключам и поставить Fail2ban и это уже будет гарантией безопасности. К сожалению, мы живем в реальном и мире, который постоянно меняется и предложенные меры безопасности уже не являются всегда достаточными.
Давайте разберем — авторизация по ключам остались два относительно безопасных ssh-ключа это RSA-4096 и ED25519, DSA ключи уже не включаются в последние версии OpenSSH. При этом нужно учитывать наличие в Интернете некоторых сомнений по поводу надежности ED25519, гугл в помощь, если кому интересно.
Кроме ключей рекомендована, достаточно длинная кодовая фраза для Ваших ключей из случайных символов в разном регистре и цифр, как минимум.
Brute force attacks — давайте кратко посмотрим, что происходят, если Ваш хост атакуется целенаправленно.
Этот сбор информации далеко не всегда отражается в Ваших логах, например, сканирование портов может идти без установления соединения. Fail2ban здесь бесполезен, он работает только по записям в логах. На первом этапе могут также отслеживаться установленные системы защиты. Например, определяется количество попыток авторизации до блокировки, время блокировки.
Для взлома используются ботнеты с тысячами адресов и сканирование в простом случае идет, чтобы обходить установки по умолчанию Fail2ban с сотен и тысяч адресов, при серьезном сканировании с учетом настроек системы защиты жертвы. Fail2Ban здесь также бесполезен, особенно если SSH находится на 22 порту и настройки Fail2Ban оставлены по дефолту.
У меня на внешнем периметре одного из серверов все порты закрыты, но за пару дней набирается до нескольких тысяч хостов, которые пытаются установить соединение на стандартные порты. Причем сканирование идет с учетом возможных защит, пакеты с одного адреса идут, как правило, с интервалом в несколько минут.
Конечно, Fail2ban может быть эффективен, для защиты некоторых других сервисов при нестандартных настройках под Ваши хосты и сервисы.
Почему-то всегда, кажется, что второй этап самый опасный, на самом деле на первом этапе ищутся возможные уязвимости на хосте, они могут быть гораздо опаснее, простого Brute force SSH. Зачем ломать SSH, когда рядом находится открытая дверь с уязвимостью.
Что касается смены стандартного порта, есть свежий обзор BestPractic по обеспечению безопасности SSH, там смена стандартного порта стоит 8 пунктом, авторизация по ключам стоит первым пунктом и установка Fail2ban или аналогов 10 пункт. Top 20 OpenSSH Server Best Security Practices.
Перевод порта SSH на нестандартный позволяет использовать стандартные порты как ловушку для отслеживания попыток сканирования, и блокировать полученные IP адреса на длительное время и по всем портам, это 11 пункт, в статье BestPractic. Естественно необходимо указывать белые адреса чтобы не получить случайную блокировку это 7 и 8 пункты в статье BestPractic.
Таким образом мы повышаем стоимость сбора информации о нашей системе. Информация о открытых портах будет стоить несколько тысяч IP адресов или месяцы на сканирование нашей системы. Если для потенциального взломщика неизвестен мой порт SSH, даже при появлении уязвимости он не сможет ей воспользоваться.
Достаточно перейти на авторизацию по ключам и поставить Fail2ban и это уже будет гарантией безопасности. К сожалению, мы живем в реальном и мире, который постоянно меняется и предложенные меры безопасности уже не являются всегда достаточными.
Давайте разберем — авторизация по ключам остались два относительно безопасных ssh-ключа это RSA-4096 и ED25519, DSA ключи уже не включаются в последние версии OpenSSH. При этом нужно учитывать наличие в Интернете некоторых сомнений по поводу надежности ED25519, гугл в помощь, если кому интересно.
Кроме ключей рекомендована, достаточно длинная кодовая фраза для Ваших ключей из случайных символов в разном регистре и цифр, как минимум.
Brute force attacks — давайте кратко посмотрим, что происходят, если Ваш хост атакуется целенаправленно.
1 этап — сбор информации о хосте, в том числе и открытых портах
Этот сбор информации далеко не всегда отражается в Ваших логах, например, сканирование портов может идти без установления соединения. Fail2ban здесь бесполезен, он работает только по записям в логах. На первом этапе могут также отслеживаться установленные системы защиты. Например, определяется количество попыток авторизации до блокировки, время блокировки.
2 этап — попытки получить доступ к системе через взлом SSH
Для взлома используются ботнеты с тысячами адресов и сканирование в простом случае идет, чтобы обходить установки по умолчанию Fail2ban с сотен и тысяч адресов, при серьезном сканировании с учетом настроек системы защиты жертвы. Fail2Ban здесь также бесполезен, особенно если SSH находится на 22 порту и настройки Fail2Ban оставлены по дефолту.
У меня на внешнем периметре одного из серверов все порты закрыты, но за пару дней набирается до нескольких тысяч хостов, которые пытаются установить соединение на стандартные порты. Причем сканирование идет с учетом возможных защит, пакеты с одного адреса идут, как правило, с интервалом в несколько минут.
Конечно, Fail2ban может быть эффективен, для защиты некоторых других сервисов при нестандартных настройках под Ваши хосты и сервисы.
Почему-то всегда, кажется, что второй этап самый опасный, на самом деле на первом этапе ищутся возможные уязвимости на хосте, они могут быть гораздо опаснее, простого Brute force SSH. Зачем ломать SSH, когда рядом находится открытая дверь с уязвимостью.
Что касается смены стандартного порта, есть свежий обзор BestPractic по обеспечению безопасности SSH, там смена стандартного порта стоит 8 пунктом, авторизация по ключам стоит первым пунктом и установка Fail2ban или аналогов 10 пункт. Top 20 OpenSSH Server Best Security Practices.
Перевод порта SSH на нестандартный позволяет использовать стандартные порты как ловушку для отслеживания попыток сканирования, и блокировать полученные IP адреса на длительное время и по всем портам, это 11 пункт, в статье BestPractic. Естественно необходимо указывать белые адреса чтобы не получить случайную блокировку это 7 и 8 пункты в статье BestPractic.
Таким образом мы повышаем стоимость сбора информации о нашей системе. Информация о открытых портах будет стоить несколько тысяч IP адресов или месяцы на сканирование нашей системы. Если для потенциального взломщика неизвестен мой порт SSH, даже при появлении уязвимости он не сможет ей воспользоваться.