Jak zabezpečit servery MySQL/MariaDB

Po útocích na databáze MongoDB jsme nedávno také viděli, že servery MySQL jsou terčem ransomwaru. Vzhledem k rostoucímu přijímání veřejných a soukromých cloudů by to nemělo být překvapením. Provozování špatně nakonfigurované databáze v cloudu se může stát velkým problémem.

V tomto příspěvku na blogu se s vámi podělíme o řadu tipů, jak chránit a zabezpečit servery MySQL nebo MariaDB.

Pochopení útočného vektoru

Cituji SCMagazine:
“Útok začíná hrubým vynucením hesla root pro databázi MySQL. Po přihlášení jsou načteny databáze a tabulky MySQL. Útočník poté vytvoří novou tabulku s názvem „VAROVÁNÍ“, která obsahuje kontaktní e-mailovou adresu, bitcoinovou adresu a požadavek na platbu. ”

Na základě článku začíná útočný vektor uhodnutím kořenového hesla MySQL metodou hrubou silou. Útok hrubou silou spočívá v tom, že útočník zkouší mnoho hesel nebo přístupových frází s nadějí, že nakonec uhodne správně. To znamená, že krátká hesla lze obvykle zjistit poměrně rychle, ale delší hesla mohou trvat dny nebo měsíce.

Brute-force je běžný útok, který by se stal jakékoli službě. Bohužel pro MySQL (a mnoho dalších DBMS) neexistuje žádná předem připravená funkce, která by detekovala a blokovala útoky hrubou silou z konkrétních adres během ověřování uživatele. MySQL však zaznamenává selhání autentizace do protokolu chyb.

Přečtěte si zásady týkající se hesla

Kontrola zásad hesel MySQL je vždy prvním krokem k ochraně vašeho serveru. Kořenové heslo MySQL by mělo být dostatečně silné s kombinací abeced, čísel a symbolů (což ztěžuje zapamatování) a mělo by být uloženo na bezpečném místě. Heslo pravidelně měňte, minimálně každé kalendářní čtvrtletí. Na základě vektoru útoku se jedná o nejslabší bod, na který se hackeři zaměřují. Pokud si ceníte svých dat, tuto část nepřehlédněte.

Nasazení MySQL prováděné ClusterControl se budou vždy řídit osvědčenými bezpečnostními postupy dodavatele, například během GRANT nebude definován žádný zástupný hostitel a citlivá přihlašovací pověření uložená v konfiguračním souboru jsou přípustná pouze pro uživatele root OS. Důrazně doporučujeme našim uživatelům, aby během fáze nasazení zadali silné heslo.

Ve standardním produkčním prostředí jsou databázové servery obvykle umístěny na nižší úrovni. Tato vrstva by měla být chráněna a přístupná pouze z vyšší vrstvy, jako je aplikace nebo nástroj pro vyrovnávání zatížení. Pokud je databáze umístěna společně s aplikací, můžete se dokonce uzamknout proti nelokálním adresám a místo toho použít soubor soketu MySQL (méně režijní a bezpečnější).

Konfigurace parametru "bind-address" je zde zásadní. Vezměte na vědomí, že vazba MySQL je omezena buď na žádnou, jednu nebo všechny IP adresy (0.0.0.0) na serveru. Pokud nemáte na výběr a potřebujete, aby MySQL naslouchalo všem síťovým rozhraním, omezte přístup ke službě MySQL ze známých dobrých zdrojů. Pomocí aplikace brány firewall nebo skupiny zabezpečení můžete přidat na seznam povolených přístupů pouze od hostitelů, kteří potřebují přímý přístup k databázi.

Někdy musí být server MySQL vystaven veřejné síti pro účely integrace (např. monitorování, auditování, zálohování atd.). To je v pořádku, pokud kolem toho nakreslíte hranici. Nedovolte nechtěným zdrojům „vidět“ server MySQL. Můžete se vsadit, kolik lidí na světě ví, že 3306 je výchozí port pro službu MySQL, a pouhým provedením skenování portu proti síťové adrese může útočník vytvořit seznam vystavených serverů MySQL v podsíti za méně než minutu. Doporučujeme použít vlastní port MySQL nakonfigurováním parametru "port" v konfiguračním souboru MySQL, abyste minimalizovali riziko expozice.

Přečtěte si zásady pro uživatele

Omezte určité uživatele na držení kritických administrátorských práv, zejména GRANT, SUPER a PROCESS. Můžete také povolit super_read_only, pokud je server slave, dostupný pouze na MySQL 5.7.8 a Percona Server 5.6.21 a novějších (bohužel ne s MariaDB). Je-li povoleno, server nepovolí žádné aktualizace kromě aktualizace úložišť replikace, pokud jsou protokoly stavu podřízeného zařízení tabulkami, a to i pro uživatele, kteří mají oprávnění SUPER. Odeberte výchozí testovací databázi a všechny uživatele s prázdnými hesly, abyste zúžili rozsah penetrace. Toto je jedna z bezpečnostních kontrol prováděná ClusterControl, implementovaná jako databázový poradce.

Je také dobré omezit počet povolených připojení k jednomu účtu. Můžete tak učinit nastavením proměnné max_user_connections v mysqld (výchozí je 0, rovná se neomezeně) nebo použít možnosti řízení zdrojů v příkazech GRANT/CREATE USER/ALTER USER. Příkaz GRANT podporuje omezení počtu současných připojení k serveru pomocí účtu, například:

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

Výchozí uživatelské jméno správce na serveru MySQL je „root“. Hackeři se často pokoušejí získat přístup k jeho oprávněním. Aby byl tento úkol mnohem těžší, přejmenujte „root“ na něco jiného. Uživatelská jména MySQL mohou mít až 32 znaků (16 znaků před MySQL 5.7.8). Pro uživatele superadmin je možné použít delší uživatelské jméno pomocí příkazu RENAME, jak je uvedeno níže:

mysql> RENAME USER root TO new_super_administrator_username;

Vedlejší poznámka pro uživatele ClusterControl, ClusterControl potřebuje znát kořenového uživatele MySQL a heslo, aby mohl automatizovat a spravovat databázový server za vás. Ve výchozím nastavení bude hledat „root“. Pokud přejmenujete uživatele root na něco jiného, ​​zadejte „monitored_mysql_root_user={new_user}“ uvnitř cmon_X.cnf (kde X je ID clusteru) a restartujte službu CMON, aby se změna uplatnila.

Zásady zálohování

I když hackeři tvrdili, že po zaplacení výkupného dostanete svá data zpět, obvykle tomu tak nebylo. Zvýšením frekvence zálohování by se zvýšila možnost obnovit smazaná data. Například místo úplné zálohy jednou týdně s denním přírůstkovým zálohováním můžete naplánovat úplnou zálohu jednou denně s hodinovým přírůstkovým zálohováním. Můžete to snadno provést pomocí funkce správy zálohování ClusterControl a obnovit svá data, pokud se něco pokazí.

Pokud máte povoleny binární protokoly (binlogy), je to ještě lepší. Každý den můžete vytvořit úplnou zálohu a zálohovat binární protokoly. Binlogy jsou důležité pro obnovu v určitém okamžiku a měly by být pravidelně zálohovány jako součást vaší zálohovací procedury. DBA mají tendenci postrádat tuto jednoduchou metodu, která stojí za každý cent. V případě, že jste byli napadeni, můžete se vždy vrátit do posledního bodu před tím, než k němu došlo, za předpokladu, že hackeři nevyčistili binární protokoly. Vezměte na vědomí, že čištění binárních protokolů je možné pouze v případě, že má útočník oprávnění SUPER.

Ještě jedna důležitá věc je, že záložní soubory musí být obnovitelné. Občas ověřte zálohy a vyhněte se nepříjemným překvapením, když potřebujete obnovit.

Zabezpečte svůj webový/aplikační server

Pokud jste izolovali své servery MySQL, stále existuje šance, že se k nim útočníci dostanou přes web nebo aplikační server. Vložením škodlivého skriptu (např. Cross-Site Scripting, SQL injection) do cílového webu se lze dostat do adresáře aplikace a získat možnost číst soubory aplikace. Ty mohou obsahovat citlivé informace, například přihlašovací údaje k databázi. Když se na to podíváte, útočník se může jednoduše přihlásit do databáze, smazat všechny tabulky a ponechat uvnitř tabulku „výkupného“. K vykoupení oběti nemusí být nutně uživatel root MySQL.

Existují tisíce způsobů, jak kompromitovat webový server, a pro tento účel nemůžete skutečně zavřít příchozí port 80 nebo 443. K ochraně vašeho webového serveru před injekcemi založenými na HTTP je vyžadována další vrstva ochrany. Můžete použít Web Application Firewall (WAF) jako Apache ModSecurity, NAXSI (WAF pro nginx), WebKnight (WAF pro IIS) nebo jednoduše provozovat své webové servery v zabezpečené síti pro doručování obsahu (CDN), jako je CloudFlare, Akamai nebo Amazon CloudFront.

Vždy udržujte aktuální informace

Pravděpodobně jste slyšeli o kritickém zero-day MySQL exploitu, kdy se neprivilegovaný uživatel může eskalovat na super uživatele? Zní to děsivě. Naštěstí všichni známí dodavatelé aktualizovali své úložiště tak, aby obsahovalo opravu chyby pro tento problém.

Pro produkční použití se důrazně doporučuje nainstalovat balíčky MySQL/MariaDB z úložiště dodavatele. Nespoléhejte na výchozí úložiště operačního systému, kde jsou balíčky obvykle zastaralé. Pokud běžíte v prostředí clusteru, jako je Galera Cluster, nebo dokonce MySQL Replication, máte vždy možnost opravit systém s minimálními prostoji. Udělejte z toho rutinu a pokuste se proces upgradu co nejvíce zautomatizovat.

ClusterControl podporuje postupný upgrade menších verzí (jeden uzel po druhém) pro MySQL/MariaDB jediným kliknutím. Upgrade hlavních verzí (např. z MySQL 5.6 na MySQL 5.7) běžně vyžaduje odinstalaci stávajících balíčků a je to riskantní úkol automatizovat. Pro takový druh upgradu je nutné pečlivé plánování a testování.

Závěr

Ransomware je zlatý hrnec se snadnými penězi. V budoucnu se pravděpodobně dočkáme dalších narušení bezpečnosti a je lepší zakročit, než se něco stane. Hackeři se zaměřují na mnoho zranitelných serverů a velmi pravděpodobně se tento útok rozšíří i na další databázové technologie. Ochrana vašich dat je pro správce databází neustálou výzvou. Skutečným nepřítelem není pachatel, ale náš postoj k ochraně našeho kritického majetku.