Понякога е неизбежно да се стартират MySQL сървъри на база данни в публична или открита мрежа. Това е често срещана настройка в среда за споделен хостинг, където сървърът е конфигуриран с множество услуги и често работи в рамките на същия сървър като сървъра на базата данни. За тези, които имат такъв тип настройка, винаги трябва да имате някаква защита срещу кибератаки като отказ на услуга, хакване, кракване, пробиви на данни; всичко, което може да доведе до загуба на данни. Това са неща, които винаги искаме да избягваме за нашия сървър на база данни.
Ето някои от съветите, които можем да направим, за да подобрим сигурността на MySQL или MariaDB.
Сканирайте редовно сървърите си за бази данни
Защитата срещу всякакви злонамерени файлове в сървъра е много критична. Сканирайте редовно сървъра, за да търсите вируси, шпионски софтуер, злонамерен софтуер или руткитове, особено ако сървърът на базата данни е разположен заедно с други услуги като пощенски сървър, HTTP, FTP, DNS, WebDAV, telnet и т.н. Обикновено повечето от хакнатите проблеми в базата данни произлизат от нивото на приложения, което е изправено пред обществената мрежа. По този начин е важно да сканирате всички файлове, особено файловете за уеб/приложения, тъй като те са една от входните точки за влизане в сървъра. Ако те са компрометирани, хакерът може да влезе в директорията на приложението и да има възможност да чете файловете на приложението. Те може да съдържат чувствителна информация, например идентификационните данни за вход в базата данни.
ClamAV е едно от най-широко известните и широко доверени антивирусни решения за различни операционни системи, включително Linux. Той е безплатен и много лесен за инсталиране и се предлага с доста добър механизъм за откриване за търсене на нежелани неща във вашия сървър. Планирайте периодични сканирания в заданието cron, например:
0 3 * * * /bin/freshclam ; /bin/clamscan / --recursive=yes -i > /tmp/clamav.log ; mail -s clamav_log_`hostname` [email protected] < /tmp/clamav.logГорното ще актуализира вирусната база данни ClamAV, ще сканира всички директории и файлове и ще ви изпрати имейл за състоянието на изпълнението и ще докладва всеки ден в 3 часа сутринта.
Използвайте по-строги потребителски роли и привилегии
Когато създавате потребител на MySQL, не позволявайте на всички хостове да имат достъп до MySQL сървъра със заместващи символи (%). Трябва да сканирате вашия MySQL хост и да потърсите всяка стойност на хост с заместващи знаци, както е показано в следното изявление:
mysql> SELECT user,host FROM mysql.user WHERE host = '%';
+---------+------+
| user | host |
+---------+------+
| myadmin | % |
| sbtest | % |
| user1 | % |
+---------+------+От горния изход стриктно или премахнете всички потребители, които имат само стойност „%“ в колоната Host. Потребителите, които трябва да имат отдалечен достъп до MySQL сървъра, могат да бъдат принудени да използват метода за SSH тунелиране, който не изисква отдалечена конфигурация на хост за потребителите на MySQL. Повечето от клиентите за администриране на MySQL, като MySQL Workbench и HeidiSQL, могат да бъдат конфигурирани да се свързват към MySQL сървър чрез SSH тунелинг, следователно е възможно напълно да се елиминира отдалечената връзка за потребителите на MySQL.
Освен това ограничете привилегията SUPER само до потребители от localhost или свързване чрез UNIX файл на сокет. Бъдете по-внимателни, когато присвоявате привилегия FILE на потребители без root права, тъй като това позволява четене и запис на файлове на сървъра чрез операторите LOAD DATA INFILE и SELECT ... INTO OUTFILE. Всеки потребител, на когото е предоставена тази привилегия, може също да чете или пише всеки файл, който MySQL сървърът може да прочете или запише.
Променете настройките по подразбиране на базата данни
Като се отдалечим от настройката по подразбиране, именуването и конфигурациите, можем да намалим вектора на атака до няколко пъти. Следните действия са някои примери за конфигурации по подразбиране, които DBA могат лесно да променят, но често се пренебрегват, свързани с MySQL:
- Променете порта MySQL по подразбиране на различен от 3306.
- Преименувайте потребителското име на MySQL root на различно от "root".
- Прилагане на изтичане на паролата и намаляване на нейния живот за всички потребители.
- Ако MySQL е разположен съвместно със сървърите на приложения, наложете връзка само чрез UNIX файл на сокет и спрете да слушате порт 3306 за всички IP адреси.
- Прилагане на криптиране клиент-сървър и криптиране на репликация сървър-сървър.
Всъщност разгледахме това подробно в тази публикация в блога, Как да защитим MySQL/MariaDB сървъри.
Настройте отложено подчинено устройство
Забавеният подчинен е просто типичен подчинен сървър, но подчинения сървър умишлено изпълнява транзакции по-късно от главния с поне определен период от време, достъпен от MySQL 5.6. По принцип събитие, получено от главната, не се изпълнява до най-малко N секунди по-късно от изпълнението му на главния. Резултатът е, че подчинението ще отразява състоянието на главната в миналото.
Забавено подчинено устройство може да се използва за възстановяване на данни, което би било полезно, когато проблемът бъде открит незабавно, в рамките на периода на забавяне. Да предположим, че сме конфигурирали подчинен с 6-часово закъснение от главния. Ако нашата база данни е била променена или изтрита (случайно от разработчик или умишлено от хакер) в рамките на този период от време, има възможност да се върнем към момента точно преди това да се е случило, като спрем текущия главен сървър, след което изведем подчинения сървър до определен момент със следната команда:
# on delayed slave
mysql> STOP SLAVE;
mysql> START SLAVE UNTIL MASTER_LOG_FILE='xxxxx', MASTER_LOG_POS=yyyyyy;Където „xxxxx“ е двоичният регистрационен файл, а „yyyyy“ е позицията точно преди да се случи бедствието (използвайте инструмента mysqlbinlog, за да прегледате тези събития). И накрая, повишете подчинения да стане нов главен и вашата MySQL услуга вече работи както обикновено. Този метод е може би най-бързият начин за възстановяване на вашата MySQL база данни в производствена среда, без да се налага презареждане на резервно копие. Наличието на множество забавени подчинени устройства с различна продължителност, както е показано в този блог, Множество подчинени устройства с отложена репликация за възстановяване след бедствие с нисък RTO за това как да настроите рентабилни сървъри за отложено репликация върху контейнерите на Docker.
Активиране на двоично регистриране
По принцип се препоръчва да се активира двоичното регистриране, въпреки че работите на самостоятелен MySQL/MariaDB сървър. Двоичният дневник съдържа информация за SQL изрази, които променят съдържанието на базата данни. Информацията се съхранява под формата на „събития“, които описват модификациите. Въпреки въздействието върху производителността, наличието на двоичен регистрационен файл ви позволява да имате възможността да възпроизведете сървъра на базата данни до точната точка, където искате да бъде възстановен, известен също като възстановяване в момента (PITR). Двоичното регистриране също е задължително за репликация.
С активиран двоичен регистрационен файл, трябва да включите двоичния регистрационен файл и информация за позицията, когато правите пълно архивиране. За mysqldump, използването на флага --master-data със стойност 1 или 2 ще отпечата необходимата информация, която можем да използваме като отправна точка за превъртане на базата данни при повторно възпроизвеждане на двоичните регистрационни файлове по-късно.
С активиран двоичен журнал, можете да използвате друга страхотна функция за възстановяване, наречена ретроспекция, която е описана в следващия раздел.
Активиране на Flashback
Функцията за ретроспекция е налична в MariaDB, където можете да възстановите обратно данните към предишната моментна снимка в база данни на MySQL или в таблица. Flashback използва mysqlbinlog, за да създаде операторите за връщане назад и за това се нуждае от ПЪЛНО изображение на ред в двоичен журнал. По този начин, за да използвате тази функция, сървърът MySQL/MariaDB трябва да бъде конфигуриран със следното:
[mysqld]
...
binlog_format = ROW
binlog_row_image = FULLСледната архитектурна диаграма илюстрира как ретроспекцията е конфигурирана на един от подчинените устройства:
За да извършите операцията за ретроспекция, първо трябва да определите датата и часа когато искате да "видите" данните или двоичен регистрационен файл и позиция. След това използвайте флага --flashback с помощната програма mysqlbinlog, за да генерирате SQL изрази за връщане на данните до тази точка. В генерирания SQL файл ще забележите, че събитията DELETE се преобразуват във INSERT и обратно, а също така разменя WHERE и SET части от събитията UPDATE.
Следният команден ред трябва да се изпълни на slave2 (конфигуриран с binlog_row_image=FULL):
$ mysqlbinlog --flashback --start-datetime="2020-02-17 01:30:00" /var/lib/mysql/mysql-bin.000028 -v --database=shop --table=products > flashback_to_2020-02-17_013000.sqlСлед това отделете slave2 от веригата за репликация, защото ще го разбием и ще използваме сървъра за връщане на нашите данни:
mysql> STOP SLAVE;
mysql> RESET MASTER;
mysql> RESET SLAVE ALL;Накрая импортирайте генерирания SQL файл в сървъра на MariaDB за магазин на база данни на slave2:
$ mysql -u root -p shop < flashback_to_2020-02-17_013000.sqlКогато се приложи горното, таблицата „продукти“ ще бъде в състояние на 2020-02-17 01:30:00. Технически, генерираният SQL файл може да се приложи както към MariaDB, така и към MySQL сървъри. Можете също да прехвърлите двоичния файл mysqlbinlog от сървър на MariaDB, за да можете да използвате функцията за ретроспекция на MySQL сървър. Реализацията на MySQL GTID обаче е различна от MariaDB, така че възстановяването на SQL файла изисква да деактивирате MySQL GTID.
Няколко предимства при използване на ретроспекция е, че не е необходимо да спирате MySQL/MariaDB сървъра, за да извършите тази операция. Когато количеството данни за връщане е малко, процесът на ретроспекция е много по-бърз от възстановяването на данните от пълно архивиране.
Регистрирайте всички заявки за база данни
Общият дневник по принцип улавя всеки SQL израз, изпълняван от клиента в MySQL сървъра. Това обаче може да не е популярно решение за натоварен производствен сървър поради въздействието върху производителността и консумацията на пространство. Ако производителността има значение, двоичният дневник има по-висок приоритет, който трябва да бъде активиран. Общият дневник може да бъде активиран по време на изпълнение, като изпълните следните команди:
mysql> SET global general_log_file='/tmp/mysql.log';
mysql> SET global log_output = 'file';
mysql> SET global general_log = ON;Можете също да зададете общия изход на дневника към таблица:
mysql> SET global log_output = 'table';След това можете да използвате стандартния оператор SELECT срещу таблицата mysql.general_log, за да извлечете заявки. Очаквайте малко повече въздействие върху производителността, когато работите с тази конфигурация, както е показано в тази публикация в блога.
В противен случай можете да използвате външни инструменти за наблюдение, които могат да извършват извадка и наблюдение на заявки, така че да можете да филтрирате и одитирате заявките, които идват в сървъра. ClusterControl може да се използва за събиране и обобщаване на всичките ви заявки, както е показано на следните екранни снимки, където филтрираме всички заявки, които съдържат DELETE низ:
Подобна информация е налична и в горната страница със заявки на ProxySQL (ако приложението ви е свързване чрез ProxySQL):
Това може да се използва за проследяване на последните промени, които са се случили със сървъра на базата данни и може да се използва и за одиторски цели.
Заключение
Вашите MySQL и MariaDB сървъри трябва да са добре защитени по всяко време, тъй като обикновено съдържат чувствителни данни, за които се грижат нападателите. Можете също да използвате ClusterControl, за да управлявате аспектите на сигурността на вашите сървъри на бази данни, както е показано в тази публикация в блога, Как да защитите своите бази данни с отворен код с ClusterControl.
