Запобігання жорстоким атакам на MySQL?


9

Мені потрібно ввімкнути мережу для MySQLd, але кожен раз, коли я це роблю, сервер стає змушеним в забуття. Деякий середній сценарій відгадування пароля починає забивати сервер, відкриваючи з'єднання на порту 3306 і намагаючись випадкові паролі назавжди.

Як я можу не допустити цього?

Для SSH я використовую denyhosts, який добре працює. Чи є спосіб змусити denyhosts працювати з MySQLd?

Я також розглядав можливість зміни порту, на якому працює MySQL, але це менш ніж ідеально і є лише рішенням про стоп-розрив (що робити, якщо вони відкриють новий порт?)

У когось є якісь інші ідеї?

Якщо це робить інше, я запускаю MySQL 5.x на FreeBSD 6.x.

Відповіді:


9

Я не знаю жодного програмного забезпечення, подібного до denyhosts для MySQL, але у мене є кілька рішень:

  • Обмежити вхід на певні IP-адреси. Не використовуйте%, щоб дозволити всім хостам підключитися до сервера.
  • Ще безпечніше налаштуйте iptables, щоб дозволити доступ до 3306 лише з авторизованих IP-адрес.
  • Тунель вашого трафіку до коробки з ssh, а потім підключіться через localhost
  • Змінення сценаріїв Denyhosts або BFD для аналізу журналів доступу до mysql та блокування будь-яких спроб грубої сили на брандмауері

Редагувати :

Щоб відповісти на ваш коментар, спробуйте :

iptables -A INPUT -p tcp -s 202.54.1.50 --sport 1024:65535 -d 202.54.1.20 --dport 3306 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp -s 202.54.1.20 --sport 3306 -d 202.54.1.50 --dport 1024

Де .20 - ваш MySQL, а .50 - IP-адреса віддаленого з'єднання.


Кілька зауважень: Як я можу обмежити доступ до порту 3306 лише заданим набором IP-адрес? Просто обмеження користувачів MySQL не працює, оскільки віддалені машини можуть все-таки підключатися і грубо застосовувати паролі. SSH-тунелі здаються дещо незручними для налаштування для кінцевого користувача ... Чи є у вас приклад IPTables для цього?
Кіт Палмер-молодший

2

1: Змініть порт на 3306. Не з метою кращої безпеки, але щоб взяти навантаження сервера для боротьби з помилковими атаками входу

2: Створіть сертифікат SSL та ввімкніть його на своєму сервері MySQL (для шифрування підключення клієнт-сервер потрібно обов'язково)

3: Створіть один або декілька сертифікатів клієнта (всі клієнти повинні мати сертифікат, а для його використання потрібно налаштувати клієнтське програмне забезпечення). Якщо ваші клієнти - .Не потрібно конвертувати клієнтський сертифікат у формат pkcs12, але це легко зробити, дивіться цей посібник.

4: Встановіть акаунт користувача MySQL, щоб він вимагав сертифікат клієнта x509, тоді зловмисникові потрібні облікові дані для входу І сертифікат клієнта (ви навіть можете поставити пароль на сертифікат клієнта, тоді і зловмисник теж повинен вимагати цього).

Цей посібник я використовував для створення сертифікатів та файлів ключів, але там є багато посібників.

Я вважаю за краще використовувати моє SSH-з'єднання для доступу до свого linux box з метою адміністрування, а не для доступу клієнта.


Дякую за відповідь. Я використовував цей посібник, щоб робити №2, 3 та 4: digitalocean.com/community/tutorials/…
ofri cofri

1

Використовуючи MySQL Proxy, ви можете написати невеликий скрипт LUA, який займає комбінацію користувача / проходу, але чекає X секунд, щоб обробити логін, якщо запит на з'єднання надходить із незатвердженого діапазону IP.

Крім того, ви можете додати трохи додаткової логіки до сценарію LUA до діапазону IP-адрес чорного списку після трьох невдалих спроб.

Загалом, це технічно можливо, але я збираюся з іншими рекомендаціями прокласти тунель через SSH або VPN до загального, білого (через FW або інших способів) IP-діапазону.


+1 ще одне використання для MySQL Proxy :)
Енді,

0

чому не дозволяти доступу до порту mysqld лише від захищених хостів?


Я вважав це, але це означає, що мені доведеться відстежувати зміни IP-адреси для приблизно 1000+ клієнтів. Це був би велетенський біль у задника ... Як я це все роблю? Це не допомагає заблокувати їх у MySQL, тому що вони все ще можуть підключитися до сервера MySQL, тільки фактично не вибираючи жодних баз даних ...
Кіт Палмер-молодший,

1
Цитуючи Дейва Драгера вище: "Змінити сценарії Denyhosts або BFD для аналізу журналів доступу до mysql та блокування будь-яких спроб грубої сили на брандмауері" здається найкращою ідеєю або використовувати деякі ієрогліфічні паролі :)
quaie

0

Хоча це не "справжня" відповідь - я не знаю, навіщо вам потрібно піддавати її зовнішньому світу безпосередньо.

Ви не можете ввімкнути ssh у цьому вікні та використовувати тунелювання для доступу до двигуна db?

Або будь-яке інше рішення VPN, щоб отримати доступ до нього (на розум відкриває openvpn).


0

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


-1 для безпеки від незрозумілості
thepocketwade

@thepocketwade - Ось чому я сказав, що це не справжнє рішення проблеми. Але це все-таки може бути корисним.
Ерік Петроліє

0

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

Також ви можете встановити cronjob на хости клієнтів, які будуть працювати smth на сервері, щоб запобігти блокуванню брандмауера відомих хостів.


0

використання ssh для тунелів було б найкращим, але ви можете спробувати використовувати fail2ban замість denyhosts, тому що я думаю, що він спрямований на моніторинг більше різних програм, тому це не повинно бути проблемою додавання журналу mysql до нього.


0

Пропонуйте врахувати ваш розділ my.cnf-ini [mysqld]

max_connect_errors=10  # to limit hacker/cracker attempts to guess a password.

щоб уникнути сотні спроб за 90 секунд. Подрібніть їх за 10 спроб.

Розгляньте раз на день БЛИЗЬКІ ХОСТИ, щоб очистити законних людей, які намагаються використовувати вашу систему, яка просто НЕ МОЖЕ запам'ятати свій пароль. Можливо, через кілька днів вони з цим дістануться.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.