Как да защитите MySQL/MariaDB сървъри

След атаки срещу бази данни MongoDB, наскоро също видяхме, че MySQL сървърите са насочени от ransomware. Това не трябва да е изненада, като се има предвид нарастващото приемане на публични и частни облаци. Изпълнението на лошо конфигурирана база данни в облака може да се превърне в сериозен проблем.

В тази публикация в блога ще споделим с вас редица съвети как да защитите и защитите своите MySQL или MariaDB сървъри.

Разбиране на вектора на атака

Цитирайки SCMagazine:
“Атаката започва с грубо налагане на root паролата за MySQL базата данни. След като влезете, базите данни и таблиците на MySQL се извличат. След това нападателят създава нова таблица, наречена „ПРЕДУПРЕЖДЕНИЕ“, която включва имейл адрес за контакт, биткойн адрес и искане за плащане. ”

Въз основа на статията, векторът на атаката започва с отгатване на паролата за root на MySQL чрез метода на груба сила. Атаката с груба сила се състои в това, че нападателят опитва много пароли или пароли с надеждата в крайна сметка да отгатне правилно. Това означава, че кратките пароли обикновено могат да бъдат открити доста бързо, но по-дългите може да отнемат дни или месеци.

Brute-force е често срещана атака, която би се случила на всяка услуга. За съжаление за MySQL (и много други СУБД), няма готова функция, която да открива и блокира атаки с груба сила от конкретни адреси по време на удостоверяване на потребителя. MySQL обаче улавя грешки при удостоверяване в регистъра за грешки.

Прегледайте правилата си за пароли

Прегледът на правилата за пароли на MySQL винаги е първата стъпка за защита на вашия сървър. MySQL root паролата трябва да е достатъчно силна с комбинация от азбуки, цифри и символи (което я прави по-трудна за запомняне) и да се съхранява на сигурно място. Променяйте паролата редовно, поне на всяко календарно тримесечие. Въз основа на вектора на атака, това е най-слабата точка, към която се насочват хакерите. Ако цените данните си, не пренебрегвайте тази част.

Разгръщанията на MySQL, извършвани от ClusterControl, винаги ще следват най-добрите практики за сигурност на доставчика, например няма да има хост с заместващи знаци, дефиниран по време на GRANT и чувствителни идентификационни данни за вход, съхранени в конфигурационния файл, са разрешени само за root потребител на ОС. Силно препоръчваме на нашите потребители да посочат силна парола по време на етапа на внедряване.

В стандартна производствена среда сървърите на бази данни обикновено са разположени на ниво от по-ниско ниво. Този слой трябва да бъде защитен и достъпен само от горното ниво, като приложение или балансиране на натоварването. Ако базата данни е разположена съвместно с приложението, можете дори да блокирате срещу нелокални адреси и вместо това да използвате MySQL сокет файл (по-малко излишни и по-сигурни).

Конфигурирането на параметъра "bind-address" е жизненоважно тук. Обърнете внимание, че MySQL обвързването е ограничено до нито един, един или всички IP адреси (0.0.0.0) на сървъра. Ако нямате избор и се нуждаете от MySQL, за да слушате всички мрежови интерфейси, ограничете достъпа до услугата MySQL от известни добри източници. Използвайте приложение за защитна стена или група за защита, за да включите в белия списък достъп само от хостове, които трябва да имат директен достъп до базата данни.

Понякога MySQL сървърът трябва да бъде изложен на публична мрежа за целите на интеграцията (например наблюдение, одит, архивиране и т.н.). Това е добре, стига да начертаете граница около него. Не позволявайте на нежелани източници да „виждат“ MySQL сървъра. Можете да се обзаложите колко хора по света знаят, че 3306 е портът по подразбиране за услугата MySQL и като просто извърши сканиране на порт срещу мрежов адрес, нападателят може да създаде списък с открити MySQL сървъри в подмрежата за по-малко от минута. Препоръчително е да използвате персонализиран MySQL порт, като конфигурирате параметъра "port" в конфигурационния файл на MySQL, за да сведете до минимум риска от излагане.

Прегледайте правилата за потребителя

Ограничете определени потребители да притежават критичните административни права, особено GRANT, SUPER и PROCESS. Можете също да активирате super_read_only, ако сървърът е подчинен, достъпен само на MySQL 5.7.8 и Percona Server 5.6.21 и по-нови (за съжаление не с MariaDB). Когато е активиран, сървърът няма да позволи никакви актуализации, освен актуализирането на реплицираните хранилища, ако регистрите за състоянието на подчинените са таблици, дори за потребителите, които имат СУПЕР привилегия. Премахнете тестовата база данни по подразбиране и всички потребители с празни пароли, за да стесните обхвата на проникване. Това е една от проверките за сигурност, извършени от ClusterControl, внедрена като съветник за база данни.

Също така е добра идея да ограничите броя на разрешените връзки до един акаунт. Можете да направите това, като зададете променливата max_user_connections в mysqld (по подразбиране е 0, равно на неограничен) или да използвате опциите за контрол на ресурсите в операторите GRANT/CREATE USER/ALTER USER. Инструкцията GRANT поддържа ограничаване на броя на едновременните връзки към сървъра чрез акаунт, например:

mysql> GRANT ALL PRIVILEGES ON db.* TO 'db_user'@'localhost' WITH MAX_USER_CONNECTIONS 2;

Потребителското име на администратор по подразбиране на MySQL сървъра е „root“. Хакерите често се опитват да получат достъп до неговите разрешения. За да направите тази задача много по-трудна, преименувайте „root“ на нещо друго. Потребителските имена на MySQL могат да бъдат дълги до 32 знака (16 знака преди MySQL 5.7.8). Възможно е да използвате по-дълго потребителско име за супер администраторския потребител, като използвате оператора RENAME, както е показано по-долу:

mysql> RENAME USER root TO new_super_administrator_username;

Странична бележка за потребителите на ClusterControl, ClusterControl трябва да знае root потребителя и паролата на MySQL, за да автоматизира и управлява сървъра на базата данни вместо вас. По подразбиране той ще търси „root“. Ако преименувате root потребителя на нещо друго, посочете „monitored_mysql_root_user={new_user}“ вътре в cmon_X.cnf (където X е идентификаторът на клъстера) и рестартирайте услугата CMON, за да приложите промяната.

Правила за архивиране

Въпреки че хакерите заявиха, че ще получите обратно данните си, след като откупът бъде платен, това обикновено не беше така. Увеличаването на честотата на архивиране би увеличило възможността за възстановяване на изтритите ви данни. Например, вместо пълно архивиране веднъж седмично с ежедневно инкрементално архивиране, можете да планирате пълно архивиране веднъж на ден с почасово инкрементално архивиране. Можете да направите това лесно с функцията за управление на архивиране на ClusterControl и да възстановите данните си, ако нещо се обърка.

Ако имате активирани двоични регистрационни файлове (binlogs), това е още по-добре. Можете да създавате пълен архив всеки ден и да архивирате двоичните регистрационни файлове. Binlogs са важни за възстановяване в момента и трябва да се архивират редовно като част от вашата процедура за архивиране. DBA са склонни да пропускат този прост метод, който си струва всеки цент. В случай, че сте били хакнати, винаги можете да се възстановите до последната точка, преди това да се е случило, при условие че хакерите не са изчистили двоичните регистрационни файлове. Обърнете внимание, че прочистването на двоични регистрационни файлове е възможно само когато нападателят има СУПЕР привилегия.

Още едно важно нещо е, че архивните файлове трябва да могат да бъдат възстановени. Проверявайте резервните копия от време на време и избягвайте лоши изненади, когато трябва да възстановите.

Пазете своя уеб/сървър на приложения

Е, ако сте изолирали вашите MySQL сървъри, все още има шанс на нападателите да имат достъп до тях чрез уеб или сървър на приложения. Чрез инжектиране на злонамерен скрипт (напр. Cross-Site Scripting, SQL инжекция) срещу целевия уебсайт, човек може да влезе в директорията на приложението и да има възможност да чете файловете на приложението. Те може да съдържат чувствителна информация, например идентификационните данни за вход в базата данни. Гледайки това, нападателят може просто да влезе в базата данни, да изтрие всички таблици и да остави вътре таблица за „откуп“. Не е задължително той да е root потребител на MySQL, за да откупи жертва.

Има хиляди начини за компрометиране на уеб сървър и не можете наистина да затворите входящия порт 80 или 443 за тази цел. Необходим е друг слой на защита, за да защитите вашия уеб сървър от HTTP-базирани инжекции. Можете да използвате защитна стена на уеб приложения (WAF) като Apache ModSecurity, NAXSI (WAF за nginx), WebKnight (WAF за IIS) или просто да стартирате вашите уеб сървъри в защитена мрежа за доставка на съдържание (CDN) като CloudFlare, Akamai или Amazon CloudFront.

Винаги бъдете актуални

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

За производствена употреба е силно препоръчително да инсталирате пакетите MySQL/MariaDB от хранилището на доставчика. Не разчитайте на хранилището на операционната система по подразбиране, където пакетите обикновено са остарели. Ако работите в клъстерна среда като Galera Cluster или дори MySQL Replication, винаги имате избор да коригирате системата с минимално време на престой. Превърнете това в рутина и се опитайте да автоматизирате процедурата за надстройка, доколкото е възможно.

ClusterControl поддържа минимално надграждане на версията (един възел в даден момент) за MySQL/MariaDB с едно щракване. Надстройката на основните версии (например от MySQL 5.6 до MySQL 5.7) обикновено изисква деинсталиране на съществуващите пакети и е рискована задача за автоматизиране. За такъв вид надстройка е необходимо внимателно планиране и тестване.

Заключение

Ransomware е златен пот за лесни пари. Вероятно ще видим още пробиви в сигурността в бъдеще и е по-добре да предприемем действия, преди нещо да се случи. Хакерите са насочени към много уязвими сървъри и много вероятно тази атака ще се разпространи и в други технологии за бази данни. Защитата на вашите данни е постоянно предизвикателство за администраторите на бази данни. Истинският враг не е нарушителят, а нашето отношение към защитата на нашите критични активи.