Кожен аудит на відповідність вимогам вимагатиме від вас захистити SSH, і щоразу, коли сканер перевірятиме конфігурацію або CSPM вашого хмарного облікового запису, ви отримуватимете попередження про це. Наприклад, якщо ви не захистили SSH на EC2, ви неодмінно отримаєте критичне попередження про те, що одна з ваших груп безпеки має відкритий SSH-порт (22).

Коли таке трапляється, ви можете подумати: невже мене зламали?

І ви не будете в цьому винні, оскільки інтернет-інформація та маркетингові матеріали часто досить тривожні на цю тему. Але чи справді все так погано? У цій статті ми чесно пояснимо реальні загрози, на які ви наражаєтесь, коли маєте таке неправильне налаштування.

Що таке SSH на EC2?

Протокол захищеної оболонки (SSH) є стандартом для віддаленого керування сервером/машиною і замінює telnet як безпечна альтернатива. Це основна точка входу для зловмисників, оскільки, отримавши доступ через SSH, ви стаєте на кілька кроків ближче до отримання контролю над всією машиною. Тому важливо захищати і проводити аудит входів по SSH.

Якщо говорити про AWS, то в екземплярах EC2 SSH увімкнено за замовчуванням. Як тільки ви запускаєте машину, доступ по SSH налаштовується за допомогою пари ключів RSA. І досить легко підключитися через SSH-клієнт, якщо у вас є доступ до цих ключів. Однак така легкість доступу також робить його зручним для зловмисників. AWS пояснює, як захистити SSH на EC2, використовуючи найкращі практики.

Підсумовуючи:

• Не виставляйте порт SSH на загальний огляд.
• Не дозволяйте користувачеві root використовувати термінал SSH.
• Змусьте всіх користувачів входити за допомогою пари ключів SSH, а потім деактивуйте автентифікацію за допомогою пароля.

Які проблеми виникають при відкритті SSH-з’єднань з ненадійних джерел?

Це основна відповідь, яку ми розглянемо в цій статті. Нумо зануримося в кілька прикладів:

• Збільшення вразливої поверхні атаки.
• Атаки грубого підбору паролів.
• Витоки пар ключів.

CIS Benchmark – 0.0.0.0.0/0

Якщо ви досвідчений хмарний інженер, який займається питаннями безпеки або відповідності, ви, можливо, вже знайомі з відомим CIS Benchmark і кращими практиками безпеки. Для решти, ось як цей стандарт охоплює захист SSH у хмарних провайдерів.

Проходження цих перевірок необхідне для забезпечення відповідності, тому ваша команда, ймовірно, використовує деякі інструменти, які допомагають перевіряти неправильні конфігурації. Існує багато інструментів з відкритим вихідним кодом, які можуть допомогти вам контролювати стан хмарної безпеки (CSPM) і усувати подальші проблеми, серед яких Prowler є одним з найвідоміших.

Якщо заглибитися в елементи керування, то саме він сповіщає нас про відкриття порту в AWS CIS Benchmark:

4.1 Переконайтеся, що жодна група безпеки не дозволяє вхід з 0.0.0.0/0 на порт 22 (AWS)
CIS пояснив вплив наступним чином: «Видалення необмеженого підключення до віддалених консольних служб, таких як SSH, знижує вразливість сервера до ризиків».

Це стосується не тільки AWS. Два інших провайдери публічних хмар, GCP та Azure, мають такий самий контроль.

3.6 Переконайтеся, що доступ до SSH обмежено з Інтернету (GCP)
6.2 Переконайтеся, що доступ до SSH обмежено з Інтернету (Azure)
Це основна причина більшості тривог, які ви бачите.

Таким чином, мета цього контролю зрозуміла, оскільки він зменшує вразливість сервера до ризиків. Але якщо спрацювала одна з цих тривог, чи означає це, що нас зламали в момент, коли порт відкритий? Нумо подивимося на реальні ризики.

Реальність вразливості SSH

Залежно від CSPM або конфігурації вашої машини EC2, зловмисник може отримати контроль над більшою або меншою частиною ваших ресурсів. Кінцевий результат залежить від комбінації неправильних конфігурацій.

Ми хотіли б пояснити три сценарії, в яких ваш SSH-порт є доступним:

AWS підтримує SSH-демон, встановлений на всіх офіційних AMI, в актуальному стані, тому неможливо використати відому уразливість, якщо ми запустимо новий EC2.

Доступ по SSH без облікових даних

Тут могло статися дві речі. Або людина, яка це встановила, хоче побачити, як згорить весь світ, або вона є ласим шматочком (приманкою); це єдині причини залишити вашу машину незахищеною. Це найгірший сценарій, і це майже гарантія того, що будь-який бот або павук отримає доступ до вашого EC2 за лічені години.

Відкриття SSH з автентифікацією користувача/пароля

Цей сценарій є більш поширеним, ніж попередній, але у випадку з EC2 його потрібно налаштовувати вручну. Як користувач, ви можете бути мотивовані налаштувати свої машини таким чином, щоб мати доступ через SSH з будь-якого місця. І ви створите облікові дані з помилковим відчуттям безпеки. Ось у чому проблема: у цьому конкретному сценарії, коли SSH відкритий для всього світу за допомогою простих облікових даних, таких як ім’я користувача і пароль, безпека повністю залежить від надійності вашого пароля.

Таке поєднання вразливості і поганої автентифікації дозволяє зловмиснику виконувати атаки грубої сили за допомогою різних інструментів. Тут ми пояснюємо три приклади з декількома інструментами з відкритим вихідним кодом:

• Nmap, один з найвідоміших інструментів сканування портів, має можливість виконувати атаки грубої сили за допомогою скриптів, ось приклад:

nmap -p 22 --script ssh-brute --script-args userdb=users.lst,passdb=pass.lst --script-args ssh-brute.timeout=4s <target>

• Metasploit – це фреймворк для пентестування з декількома модулями. Один з них призначений для атак грубою силою, і ви можете задати параметри, щоб експлуатувати сервер.

msf > use auxiliary/scanner/ssh/ssh_login
msf auxiliary(ssh_login) > set RHOSTS <target>
msf auxiliary(ssh_login) > set USERPASS_FILE /usr/share/metasploit-framework/data/wordlists/root_userpass.txt
msf auxiliary(ssh_login) > set PASSWORD /usr/share/metasploit-framework/data/wordlists/rockyou.txt

• Hydra – це інструмент, який дає дослідникам і консультантам з безпеки можливість показати, наскільки легко отримати несанкціонований доступ до системи віддалено.

hydra -L /usr/share/wordlists.rockyou.txt -P /usr/share/wordlists/rockyou.txt <target-IP> -t 4 ssh

Цей тип атаки може розпочатися, як тільки порт SSH стає відкритим. Згідно зі звітом Smart Honeypot, перша атака грубої сили на SSH відбувається менш ніж за 12 годин. Тому, якщо ви використовуєте цей тип автентифікації для доступу до SSH, вам слід використовувати інструменти, які запобігають частині атак грубої сили, такі як fail2ban.

Відкриття SSH і автентифікація пари ключів

Це конфігурація за замовчуванням. У цьому сценарії ваш приватний ключ не зберігається в AWS і може бути отриманий лише після його створення. Загрозою може бути витік вашої пари ключів помилково або інсайдером. Таке може статися, але не тільки з доступом по SSH.

Створення пари ключів схоже на створення пари ключів в Linux-системі, якщо ваш AMI базується на Linux або Amazon, а відкритий ключ зберігається в папці ~/.ssh/authorized_keys, і це все.

Основна проблема полягає в тому, як керувати парами ключів. Якщо ви використовуєте GitHub для їх зберігання, такі інструменти, як DumpsterDiver або git-secrets, стануть у нагоді для пошуку сертифікатів у ваших файлах або сховищах.

Криптографічні штучки

Генерація ключових пар базується на стандартах RSA або Ed25519. Ймовірність генерації двох різних пар ключів для доступу до одного і того ж екземпляру є мізерно малою. Тому атака грубою силою не є реалістичною.

Заключні слова

Зменшення поверхні атаки є одним з основних принципів безпеки, і ми хотіли б пояснити трохи більше про реальні загрози, коли ви відкриваєте SSH. Вас не зламають миттєво, але зловмисникам потрібен лише один крок, щоб отримати віддалений доступ, а для цього необхідно захистити SSH в будь-якому випадку.

Поєднання цієї неправильної конфігурації з іншою створить серйозні проблеми. Тим не менш, ми рекомендуємо захищати SSH і ніколи не дозволяти SSH приймати з’єднання з будь-якого місця, щоб уникнути непотрібних інцидентів з безпекою.