Атака на SSH методом підбору паролів (SSH Brute-Force)

Якщо ви запустили сервіс SSH, доступ до якого можливий з Інтернет (звичайна справа), ви напевно спостерігали подібні записи у своїх журналах аутентифікації:

Sep 26 03:12:34 skapet sshd[25771]: Failed password for root from 200724131 port 40992 ssh2

Sep 26 03:12:34 skapet sshd[5279]: Failed password for root from 200724131 port 40992 ssh2

Sep 26 03:12:35 skapet sshd[5279]: Received disconnect from 200724131: 11: Bye Bye Sep 26 03:12:44 skapet sshd[29635]: Invalid user admin from 200724131

Sep 26 03:12:44 skapet sshd[24703]: input_userauth_request: invalid user admin

Sep 26 03:12:44 skapet sshd[24703]: Failed password for invalid user admin from 200724131 port 41484 ssh2

Sep 26 03:12:44 skapet sshd[29635]: Failed password for invalid user admin from 200724131 port 41484 ssh2

Sep 26 03:12:45 skapet sshd[24703]: Connection closed by 200724131

Sep 26 03:13:10 skapet sshd[11459]: Failed password for root from 200724131 port 43344 ssh2

Sep 26 03:13:10 skapet sshd[7635]: Failed password for root from 200724131 port 43344 ssh2

Sep 26 03:13:10 skapet sshd[11459]: Received disconnect from 200724131: 11: Bye Bye Sep 26 03:13:15 skapet sshd[31357]: Invalid user admin from 200724131

Sep 26 03:13:15 skapet sshd[10543]: input_userauth_request: invalid user admin

Sep 26 03:13:15 skapet sshd[10543]: Failed password for invalid user admin from 200724131 port 43811 ssh2

Sep 26 03:13:15 skapet sshd[31357]: Failed password for invalid user admin from 200724131 port 43811 ssh2

Sep 26 03:13:15 skapet sshd[10543]: Received disconnect from 200724131: 11: Bye Bye Sep 26 03:13:25 skapet sshd[6526]: Connection closed by 200724131

Саме так виглядає атака перебором паролів, більш відома як brute-force Хтось або щось, намагається за допомогою грубої сили підібрати імя користувача та пароль для входу у вашу систему Найпростішою реакцією стане написання правила в pfconf, яке блокуватиме весь доступ Однак, це призведе до ряду проблем, першою з яких

стане питання – як надати доступ до сервісу легітимним користувачам Налаштування sshd приймає тільки аутентифікацію засновану на ключі, однак це швидше за все не зупинить спроб отримання доступу Ви можете розглянути питання про переведення сервісу на інший порт, але існує ймовірність, що ті хто сканував порт 22, з таким же упехом виявлять і порт 22222

(Практика показує, що зміна порту SSH на порт з верхнього діапазону, значною мірою скорочує число спроб несанкціонованого доступу, хоча, звичайно не виключає їх Застосовуючи цей спосіб в якість одним із заходів обережності можна домогтися деяких успіхів – пп)

Починаючи з OpenBSD 37, PF пропонує кілька більш елегантне рішення даної проблеми

Налаштування адаптивного брандмауераДля запобігання атак підбором паролів, ви можете написати правила пропуску таким чином, щоб вони підтримували певні обмеження на можливості підключаються хостів На всякий випадок, вам слід направляти порушників у таблицю адрес, для якої заборонено весь доступ або деякі види доступу Можна навіть вказати блокування всіх підключень від машин перекрили свої ліміти Для включення цієї функції, створіть таблицю додавши наступний рядок у файл

конфігурації перед правилами фільтрації:

table &ltbruteforce&gt persist

Потім, на початку набору правил блокуємо брутфорс, як показано нижче:

block quick from &ltbruteforce&gt

Нарешті додамо пропускає правило:

pass inet proto tcp to $localnet port $tcp_services keep state (max-src-conn 100, max-src-conn-rate  15/5, overload

&ltbruteforce&gt flush global)

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

•&nbsp&nbsp&nbsp&nbsp max-src-conn – Число одночасних зєднань дозволених від одного хоста У даному прикладі встановлено в 100 Ви можете встановити значення більше або менше в залежності від параметрів вашої мережі

•&nbsp&nbsp&nbsp&nbsp max-src-conn-rate  – Число нових підключень дозволу від одного будь-якого хоста Зесь встановлено в 15 зєднань за 5 секунд, записане як 15/5 Виберіть значення відповідне вашої установці

•&nbsp&nbsp&nbsp&nbsp overload &ltbruteforce&gt – Означає, що адреса будь-якого хоста, який перевищив поточні ліміти буде додано в таблицю bruteforce Відповідно, наш набір правил блокує весь трафік з адрес які у цю таблицю Як тільки хост перевищує будь-який з цих лімітів і потрапляє в таблицю перевантаження, правило перестає зіставляти трафік з цим хостом Переконайтеся, що перевантаження обробляється тільки правилом блокування за замовчуванням або аналогічним

•&nbsp&nbsp&nbsp&nbsp flush global – Повідомляє, що коли хост досягає ліміту, всі стани для його сполук знищуються (скидаються) Опція global означає, що міра застосовується і для станів створених для трафіку цього хоста які так само відповідали іншими правилами пропуску

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

Наші адаптивні правила діють тільки для захисту від традиційних і простих спроб підбору паролів Рапределеніе спроби підбору виробляються з низькою інтенсивністю, факт застосування яких був вперше зафіксований в 2008 році (відомі серед інших під назвою The Hail Mary Cloud) не виявляють аналогічної активності і не будуть відповідати параметрам даних правил

Цілком імовірно, що ви можете створити деяку гнучкість у наборі правил і допустити більше число зєднань до деяких сервісів, але варто бути більш економним, особливо коли мова йде про SSH У цьому випадку, ви можете основне правило пропуску вмістом схожим на наступне, додавши його в початок набору правил:

pass quick proto { tcp, udp } to port ssh \

keep state (max-src-conn 15, max-src-conn-rate 5/3, \ overload &ltbruteforce&gt flush global)

Вам доведеться самостійно знайти необхідні параметри підходящі до вашої ситуації, звернувшись до відповідних man-сторінках і керівництву PF (дивіться додаток А)

Памятайте, що дані приклади правил призначені для ілюстрування роботи, а в підтримка сервісів вашої мережі може зажадати значної переробки правил Установка занадто низького рівня кількості одночасних зєднань або швидкості зєднає може привести до блокування законного трафіку і створення внутрішнього джерела відмови обслуговування, у випадку, якщо конфігурація включає безліч вузлів знаходяться за загальним шлюзом NAT

Опції відстеження станів і механізм перевантаження не слід застосовувати виключно до сервісу SSH, а блокування всього трафіку атакуючого не завжди корисно Наприклад можна використовувати наступне правило:

pass proto { tcp, udp } to port $mail_services keep state (max 1500, max-src-conn 100)

Тут, max визначає максимальне число станів, які можуть бути створені для кожного правила (або ряду правил, залежно від того як розширюється макрос

$mail_services) Без перевантаження для захисту поштового або web сервісу з прийомом більшого числа зєднань ніж те яке він може обробити З таким правилом,

значення max визначає максимальне число станів, які будуть створені для

кожного результуючого правила Як тільки буде досягнута межа, нові зєднання не дозволятимуть аж до завершення існуючих

Альтернативно, можна видалити обмеження max і додати в правила частина overload, і призначити атакуючим чергу з мінімальним виділенням смуги пропускання (дивіться

обговорення налаштуванні черг ALTQ в главі 7)

Деякі сайти використовують overload для реалізації багаторівневої системи, де хости потрапляють під правило overload направляються на одну або кілька

проміжних випробувальних таблиць для спеціальної обробки Це може бути

корисно при роботі з web вмістом, і дозволить не блокувати трафік від хостів у таблиці перевантаження безпосередньо, а спрямовувати всі HTTP запити від цих вузлів на певні web-сторінки (як ми бачили в прикладі authpf наприкінці Глави 4)

Очищення таблиць за допомогою pfctlВикористовуючи правила overload описані в попередньому розділі, ви отримали адаптивний брандмауер, який автоматично определает небажану поведінку і добаляет IP адреси порушників у таблиці Перегляд журналів і таблиць може бути веселим заняттям, проте, оскільки правила тільки додають дані в таблиці ми стикаємося з наступною задачею: підтримка актуальності таблиць

Коли ви запускаєте конфігурацію з адаптивним набором правил, через деякий час ви виявляєте, що одні IP адреси, недавно заблоковані через брутфорса,

в даний є цілком легальними для роботи з вашою сетью1 Якщо ваші

адаптивні правила збираю багато трафіку, ви можете виявити, що таблиці перевантаження швидко розростаються і займають багато місця Рішення даної проблеми полягає у створення записів терміну закінчення таблиць (expire) – необхідних для видалення записів на які не було посилань за певний час У OpenBSD 41 інструмент pfctl придбав здатність створювати в таблиці записи expire грунтуючись на

статистичних параметрах часу, таких як останній сброс2 (Практично у всіх випадках, час скидання одно часом завантаження записи в таблицю) Використовується ключове слово expire і вік записи таблиці, що указується в секундах Наприклад:

$ sudo pfctl -t bruteforce -T expire 86400

Ця команда видалить записи таблиці bruteforce для яких статистика скидання перевищила 86400 секунд (24 години)

Вибір значення 24 години в якості часу закінчення – величина досить довільна Ви повинні вибирати значення яке вам найбільш підходить, величину відповідну розумного часу виявлення і усунення проблеми Якщо у вас присутні адаптивні правила, буде гарною думкою створити запис cron, для періодичного виконання очищення таблиць використовуючи команду вказану вище Це дозволить утримувати таблиці в актуальному стані

Джерело: Книга про PF, by Peter NM Hansteen, Переклад виконав Михайлов Олексій aka iboxjo

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*