Hoe MySQL/MariaDB-servers te beveiligen

Na aanvallen op MongoDB-databases hebben we recentelijk ook gezien dat MySQL-servers het doelwit zijn van ransomware. Dit mag niet als een verrassing komen, gezien de toenemende acceptatie van publieke en private clouds. Het runnen van een slecht geconfigureerde database in de cloud kan een grote verantwoordelijkheid worden.

In deze blogpost zullen we een aantal tips met je delen over hoe je je MySQL- of MariaDB-servers kunt beschermen en beveiligen.

De aanvalsvector begrijpen

Citaat van SCMagazine:
“De aanval begint met het brute forceren van het root-wachtwoord voor de MySQL-database. Eenmaal ingelogd, worden de MySQL-databases en tabellen opgehaald. De aanvaller maakt vervolgens een nieuwe tabel met de naam 'WAARSCHUWING' met een e-mailadres voor contact, een bitcoin-adres en een betalingsverzoek. ”

Op basis van het artikel begint de aanvalsvector met het raden van het MySQL-rootwachtwoord via de brute-force-methode. Een brute-force-aanval houdt in dat een aanvaller veel wachtwoorden of wachtwoordzinnen probeert in de hoop uiteindelijk correct te raden. Dit betekent dat korte wachtwoorden meestal vrij snel ontdekt kunnen worden, maar langere wachtwoorden kunnen dagen of maanden duren.

Brute-force is een veelvoorkomende aanval die elke service kan overkomen. Helaas voor MySQL (en vele andere DBMS) is er geen kant-en-klare functie die brute-force-aanvallen van specifieke adressen detecteert en blokkeert tijdens gebruikersauthenticatie. MySQL legt echter authenticatiefouten vast in het foutenlogboek.

Bekijk uw wachtwoordbeleid

Het herzien van het MySQL-wachtwoordbeleid is altijd de eerste stap om uw server te beschermen. Het MySQL-rootwachtwoord moet sterk genoeg zijn met een combinatie van alfabetten, cijfers en symbolen (waardoor het moeilijker te onthouden is) en op een veilige plaats worden bewaard. Wijzig het wachtwoord regelmatig, in ieder geval elk kalenderkwartaal. Op basis van de aanvalsvector is dit het zwakste punt waarop hackers zich richten. Als u uw gegevens op prijs stelt, mag u dit deel niet over het hoofd zien.

MySQL-implementaties uitgevoerd door ClusterControl volgen altijd de best practices van de leverancier op het gebied van beveiliging, er wordt bijvoorbeeld geen host met jokertekens gedefinieerd tijdens GRANT en gevoelige inloggegevens die zijn opgeslagen in het configuratiebestand zijn alleen toegestaan ​​voor de rootgebruiker van het besturingssysteem. We raden onze gebruikers ten zeerste aan om een ​​sterk wachtwoord op te geven tijdens de implementatiefase.

In een standaard productieomgeving bevinden databaseservers zich meestal op een lager niveau. Deze laag moet worden beschermd en alleen toegankelijk zijn vanaf de bovenste laag, zoals de applicatie of load balancer. Als de database zich samen met de toepassing bevindt, kunt u zich zelfs afsluiten voor niet-lokale adressen en in plaats daarvan het MySQL-socketbestand gebruiken (minder overhead en veiliger).

Het configureren van de parameter "bind-address" is hier essentieel. Houd er rekening mee dat MySQL-binding beperkt is tot geen, één of alle IP-adressen (0.0.0.0) op de server. Als je geen keus hebt en MySQL nodig hebt om naar alle netwerkinterfaces te luisteren, beperk dan de toegang tot de MySQL-service van bekende goede bronnen. Gebruik een firewalltoepassing of beveiligingsgroep om alleen toegang op de witte lijst te zetten van hosts die rechtstreeks toegang tot de database nodig hebben.

Soms moet de MySQL-server worden blootgesteld aan een openbaar netwerk voor integratiedoeleinden (bijv. monitoring, auditing, back-up enz.). Dat is prima, zolang je er maar een rand omheen trekt. Laat ongewenste bronnen de MySQL-server niet "zien". Je kunt er zeker van zijn hoeveel mensen in de wereld weten dat 3306 de standaardpoort is voor MySQL-service, en door simpelweg een poortscan uit te voeren op een netwerkadres, kan een aanvaller in minder dan een minuut een lijst met blootgestelde MySQL-servers in het subnet maken. Gebruik bij voorkeur een aangepaste MySQL-poort door de parameter "poort" in het MySQL-configuratiebestand te configureren om het blootstellingsrisico te minimaliseren.

Bekijk het gebruikersbeleid

Beperk bepaalde gebruikers tot de kritieke beheerdersrechten, met name GRANT, SUPER en PROCESS. U kunt ook super_read_only inschakelen als de server een slaaf is, alleen beschikbaar op MySQL 5.7.8 en Percona Server 5.6.21 en later (helaas niet met MariaDB). Indien ingeschakeld, zal de server geen updates toestaan, behalve het updaten van de replicatie-repository's als slave-statuslogs tabellen zijn, zelfs niet voor gebruikers met SUPER-privileges. Verwijder de standaard testdatabase en alle gebruikers met lege wachtwoorden om het bereik van penetratie te verkleinen. Dit is een van de beveiligingscontroles die ClusterControl uitvoert, uitgevoerd als databaseadviseur.

Het is ook een goed idee om het aantal toegestane verbindingen voor één account te beperken. U kunt dit doen door de variabele max_user_connections in mysqld in te stellen (standaard is 0, gelijk aan onbeperkt) of door de opties voor resourcebeheer te gebruiken in de instructies GRANT/CREATE USER/ALTER USER. Het GRANT-statement ondersteunt het beperken van het aantal gelijktijdige verbindingen met de server door een account, bijvoorbeeld:

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

De standaard gebruikersnaam van de beheerder op de MySQL-server is "root". Hackers proberen vaak toegang te krijgen tot de machtigingen. Om deze taak veel moeilijker te maken, hernoemt u "root" naar iets anders. MySQL-gebruikersnamen kunnen maximaal 32 tekens lang zijn (16 tekens vóór MySQL 5.7.8). Het is mogelijk om een ​​langere gebruikersnaam voor de hoofdgebruiker te gebruiken door de RENAME-instructie te gebruiken, zoals hieronder weergegeven:

mysql> RENAME USER root TO new_super_administrator_username;

Een kanttekening voor ClusterControl-gebruikers:ClusterControl moet de MySQL-rootgebruiker en het wachtwoord kennen om de databaseserver voor u te automatiseren en te beheren. Standaard zoekt het naar 'root'. Als u de rootgebruiker naar iets anders hernoemt, specificeert u "monitored_mysql_root_user={new_user}" in cmon_X.cnf (waarbij X de cluster-ID is) en start u de CMON-service opnieuw om de wijziging toe te passen.

Back-upbeleid

Hoewel de hackers zeiden dat je je gegevens terug zou krijgen zodra het losgeld is betaald, was dit meestal niet het geval. Het verhogen van de back-upfrequentie zou de mogelijkheid vergroten om uw verwijderde gegevens te herstellen. In plaats van een keer per week een volledige back-up met een dagelijkse incrementele back-up, kunt u bijvoorbeeld een keer per dag een volledige back-up plannen met een incrementele back-up per uur. U kunt dit eenvoudig doen met de back-upbeheerfunctie van ClusterControl en uw gegevens herstellen als er iets misgaat.

Als je binaire logs (binlogs) hebt ingeschakeld, is dat nog beter. U kunt elke dag een volledige back-up maken en een back-up maken van de binaire logboeken. Binlogs zijn belangrijk voor herstel op een bepaald tijdstip en er moet regelmatig een back-up worden gemaakt als onderdeel van uw back-upprocedure. DBA's hebben de neiging deze eenvoudige methode te missen, die elke cent waard is. Als je gehackt bent, kun je altijd herstellen tot het laatste punt voordat het gebeurde, op voorwaarde dat de hackers de binaire logboeken niet hebben gewist. Houd er rekening mee dat het opschonen van binaire logboeken alleen mogelijk is als de aanvaller SUPER-rechten heeft.

Nog een belangrijk ding is dat de back-upbestanden herstelbaar moeten zijn. Controleer de back-ups zo nu en dan en voorkom onaangename verrassingen wanneer u moet herstellen.

Beveilig uw web-/toepassingsserver

Welnu, als je je MySQL-servers hebt geïsoleerd, zijn er nog steeds kansen voor de aanvallers om er toegang toe te krijgen via een web- of applicatieserver. Door een kwaadaardig script (bijv. Cross-Site Scripting, SQL-injectie) tegen de doelwebsite te injecteren, kan men in de applicatiemap komen en de applicatiebestanden lezen. Deze kunnen gevoelige informatie bevatten, bijvoorbeeld de inloggegevens van de database. Door hiernaar te kijken, kan een aanvaller eenvoudig inloggen op de database, alle tabellen verwijderen en een "losgeld"-tabel achterlaten. Het hoeft niet per se een MySQL-rootgebruiker te zijn om een ​​slachtoffer losgeld te geven.

Er zijn duizenden manieren om een ​​webserver te compromitteren en je kunt de inkomende poort 80 of 443 voor dit doel niet echt sluiten. Er is nog een beveiligingslaag nodig om uw webserver te beschermen tegen op HTTP gebaseerde injecties. U kunt Web Application Firewall (WAF) gebruiken zoals Apache ModSecurity, NAXSI (WAF voor nginx), WebKnight (WAF voor IIS) of uw webservers eenvoudig laten draaien in een beveiligd Content Delivery Network (CDN) zoals CloudFlare, Akamai of Amazon CloudFront.

Blijf altijd op de hoogte

Je hebt waarschijnlijk gehoord van de kritieke zero-day MySQL-exploit, waarbij een niet-bevoorrechte gebruiker zichzelf kan escaleren tot supergebruiker? Het klinkt eng. Gelukkig hebben alle bekende leveranciers hun repository bijgewerkt met een bugfix voor dit probleem.

Voor productiegebruik wordt het ten zeerste aanbevolen om de MySQL/MariaDB-pakketten te installeren vanuit de repository van de leverancier. Vertrouw niet op de standaard repository van het besturingssysteem, waar de pakketten meestal verouderd zijn. Als u in een clusteromgeving zoals Galera Cluster of zelfs MySQL-replicatie draait, heeft u altijd de keuze om het systeem te patchen met minimale downtime. Maak hier een routine van en probeer de upgradeprocedure zoveel mogelijk te automatiseren.

ClusterControl ondersteunt een doorlopende upgrade van een kleine versie (één knooppunt tegelijk) voor MySQL/MariaDB met een enkele klik. Bij het upgraden van grote versies (bijv. van MySQL 5.6 naar MySQL 5.7) moet u vaak de bestaande pakketten verwijderen en het is een riskante taak om te automatiseren. Zorgvuldige planning en testen zijn nodig voor een dergelijke upgrade.

Conclusie

Ransomware is een makkelijk te verdienen gouden pot. We zullen in de toekomst waarschijnlijk meer beveiligingsinbreuken zien en het is beter om actie te ondernemen voordat er iets gebeurt. Hackers richten zich op veel kwetsbare servers die er zijn, en het is zeer waarschijnlijk dat deze aanval zich ook naar andere databasetechnologieën zal verspreiden. Het beschermen van uw gegevens is een constante uitdaging voor databasebeheerders. De echte vijand is niet de dader, maar onze houding ten opzichte van het beschermen van onze kritieke activa.