Hoe u uw MySQL- en MariaDB-database kunt beschermen tegen cyberaanvallen op een openbaar netwerk

Het is soms onvermijdelijk om MySQL-databaseservers op een openbaar of blootgesteld netwerk te draaien. Dit is een gebruikelijke configuratie in een gedeelde hostingomgeving, waar een server is geconfigureerd met meerdere services en vaak op dezelfde server draait als de databaseserver. Voor degenen die dit soort instellingen hebben, moet je altijd een soort van bescherming hebben tegen cyberaanvallen zoals denial-of-service, hacking, cracking, datalekken; dit alles kan leiden tot gegevensverlies. Dit zijn dingen die we altijd willen vermijden voor onze databaseserver.

Hier zijn enkele tips die we kunnen doen om onze MySQL- of MariaDB-beveiliging te verbeteren.

Scan uw databaseservers regelmatig

Bescherming tegen kwaadaardige bestanden op de server is erg belangrijk. Scan de server regelmatig om te zoeken naar virussen, spyware, malware of rootkits, vooral als de databaseserver zich samen met andere services bevindt, zoals mailserver, HTTP, FTP, DNS, WebDAV, telnet enzovoort. Gewoonlijk zijn de meeste problemen met gehackte databases afkomstig van de applicatielaag die wordt geconfronteerd met het openbare netwerk. Het is dus belangrijk om alle bestanden te scannen, vooral web-/toepassingsbestanden, omdat ze een van de toegangspunten zijn om op de server te komen. Als deze worden gecompromitteerd, kan de hacker in de applicatiemap komen en de applicatiebestanden lezen. Deze kunnen gevoelige informatie bevatten, bijvoorbeeld de inloggegevens van de database.

ClamAV is een van de meest bekende en meest vertrouwde antivirusoplossingen voor verschillende besturingssystemen, waaronder Linux. Het is gratis en zeer eenvoudig te installeren en wordt geleverd met een redelijk goed detectiemechanisme om ongewenste dingen op uw server te zoeken. Plan periodieke scans in de cron-taak, bijvoorbeeld:

0 3 * * * /bin/freshclam ; /bin/clamscan / --recursive=yes -i > /tmp/clamav.log ; mail -s clamav_log_`hostname` [email protected] < /tmp/clamav.log

Het bovenstaande zal de ClamAV-virusdatabase bijwerken, alle mappen en bestanden scannen en u een e-mail sturen over de status van de uitvoering en elke dag om 3 uur 's nachts rapporteren.

Gebruik strengere gebruikersrollen en rechten

Als u een MySQL-gebruiker aanmaakt, laat dan niet alle hosts toegang krijgen tot de MySQL-server met jokertekenhost (%). U moet uw MySQL-host scannen en zoeken naar een hostwaarde met jokertekens, zoals weergegeven in de volgende verklaring:

mysql> SELECT user,host FROM mysql.user WHERE host = '%';
+---------+------+
| user    | host |
+---------+------+
| myadmin | %    |
| sbtest  | %    |
| user1   | %    |
+---------+------+

Van de bovenstaande uitvoer, strikt of verwijder alle gebruikers die alleen een '%'-waarde hebben in de Host-kolom. Gebruikers die op afstand toegang tot de MySQL-server nodig hebben, kunnen worden afgedwongen om de SSH-tunnelingmethode te gebruiken, waarvoor geen externe hostconfiguratie nodig is voor MySQL-gebruikers. De meeste MySQL-beheerclients zoals MySQL Workbench en HeidiSQL kunnen worden geconfigureerd om verbinding te maken met een MySQL-server via SSH-tunelling, daarom is het mogelijk om externe verbindingen voor MySQL-gebruikers volledig te elimineren.

Beperk ook het SUPER-privilege tot alleen gebruikers van localhost, of verbinding maken via UNIX-socketbestand. Wees voorzichtiger bij het toewijzen van FILE-rechten aan niet-rootgebruikers, aangezien het toestaat om bestanden op de server te lezen en te schrijven met behulp van de instructies LOAD DATA INFILE en SELECT ... INTO OUTFILE. Elke gebruiker aan wie dit privilege is verleend, kan ook elk bestand lezen of schrijven dat de MySQL-server kan lezen of schrijven.

De standaardinstellingen van de database wijzigen

Door af te stappen van de standaard setup, naamgeving en configuraties, kunnen we de aanvalsvector terugbrengen tot een aantal vouwen. De volgende acties zijn enkele voorbeelden van standaardconfiguraties die DBA's gemakkelijk kunnen wijzigen, maar die vaak over het hoofd worden gezien met betrekking tot MySQL:

Verander de standaard MySQL-poort in een andere poort dan 3306.
Hernoem de MySQL-rootgebruikersnaam in iets anders dan "root".
Dwing het verlopen van het wachtwoord af en verkort de levensduur van het wachtwoord voor alle gebruikers.
Als MySQL zich op dezelfde plaats bevindt als de applicatieservers, dwing dan de verbinding alleen af via het UNIX-socketbestand en stop met luisteren op poort 3306 voor alle IP-adressen.
Dwing client-server-encryptie en server-server replicatie-encryptie af.

We hebben dit in detail besproken in deze blogpost, MySQL/MariaDB-servers beveiligen.

Een vertraagde slave instellen

Een vertraagde slaaf is slechts een typische slaaf, maar de slaafserver voert met opzet transacties later uit dan de meester met ten minste een gespecificeerde tijdsduur, beschikbaar via MySQL 5.6. Kortom, een gebeurtenis die van de master wordt ontvangen, wordt pas uitgevoerd op ten minste N seconden later dan de uitvoering ervan op de master. Het resultaat is dat de slave de toestand van de master enige tijd terug in het verleden zal weerspiegelen.

Een vertraagde slaaf kan worden gebruikt om gegevens te herstellen, wat handig zou zijn als het probleem onmiddellijk wordt gevonden, binnen de vertragingsperiode. Stel we hebben een slave geconfigureerd met een vertraging van 6 uur vanaf de master. Als onze database is gewijzigd of verwijderd (per ongeluk door een ontwikkelaar of opzettelijk door een hacker) binnen dit tijdsbestek, is er een mogelijkheid voor ons om terug te keren naar het moment vlak voordat het gebeurde door de huidige master te stoppen en vervolgens de slave-server te openen tot op een bepaald moment met het volgende commando:

# on delayed slave
mysql> STOP SLAVE;
mysql> START SLAVE UNTIL MASTER_LOG_FILE='xxxxx', MASTER_LOG_POS=yyyyyy;

Waarbij 'xxxxx' het binaire logbestand is en 'yyyyy' de positie is vlak voordat de ramp plaatsvindt (gebruik de tool mysqlbinlog om die gebeurtenissen te onderzoeken). Promoot tot slot de slaaf om de nieuwe meester te worden en uw MySQL-service is nu weer zoals gewoonlijk operationeel. Deze methode is waarschijnlijk de snelste manier om uw MySQL-database in een productieomgeving te herstellen zonder een back-up opnieuw te hoeven laden. Het hebben van een aantal vertraagde slaves met verschillende lengtes, zoals wordt getoond in deze blog, Multiple Delayed Replication Slaves for Disaster Recovery met lage RTO over het opzetten van een kosteneffectieve vertraagde replicatieserver bovenop Docker-containers.

Binaire logboekregistratie inschakelen

Binaire logboekregistratie wordt over het algemeen aanbevolen om in te schakelen, ook al draait u op een zelfstandige MySQL/MariaDB-server. Het binaire logboek bevat informatie over SQL-instructies die de inhoud van de database wijzigen. De informatie wordt opgeslagen in de vorm van 'gebeurtenissen' die de wijzigingen beschrijven. Ondanks de prestatie-impact, biedt het hebben van binair logboek u de mogelijkheid om uw databaseserver opnieuw af te spelen tot het exacte punt waar u deze wilt herstellen, ook wel bekend als point-in-time recovery (PITR). Binaire logboekregistratie is ook verplicht voor replicatie.

Als binaire logging is ingeschakeld, moet men het binaire logbestand en de positie-informatie opnemen bij het maken van een volledige back-up. Voor mysqldump, zal het gebruik van de --master-data vlag met waarde 1 of 2 de nodige informatie afdrukken die we kunnen gebruiken als startpunt om de database verder te rollen wanneer de binaire logs later opnieuw worden afgespeeld.

Als binaire logboekregistratie is ingeschakeld, kunt u een andere coole herstelfunctie gebruiken, flashback genaamd, die in het volgende gedeelte wordt beschreven.

Flashback inschakelen

De flashback-functie is beschikbaar in MariaDB, waar u de gegevens kunt terugzetten naar de vorige snapshot in een MySQL-database of in een tabel. Flashback gebruikt de mysqlbinlog om de rollback-statements te maken en daarvoor heeft het een VOLLEDIGE binaire logrij-afbeelding nodig. Om deze functie te gebruiken, moet de MySQL/MariaDB-server dus als volgt worden geconfigureerd:

[mysqld]
...
binlog_format = ROW
binlog_row_image = FULL

Het volgende architectuurdiagram illustreert hoe flashback is geconfigureerd op een van de slave:

Om de flashback-bewerking uit te voeren, moet u eerst de datum en tijd bepalen wanneer u de gegevens of het binaire logbestand en de positie wilt "zien". Gebruik vervolgens de vlag --flashback met het hulpprogramma mysqlbinlog om SQL-instructies te genereren om de gegevens naar dat punt terug te draaien. In het gegenereerde SQL-bestand zult u merken dat de DELETE-gebeurtenissen worden geconverteerd naar INSERT's en vice versa, en ook dat het WHERE- en SET-gedeelten van de UPDATE-gebeurtenissen verwisselt.

De volgende opdrachtregel moet worden uitgevoerd op de slave2 (geconfigureerd met 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

Koppel vervolgens slave2 los van de replicatieketen, want we gaan het breken en de server gebruiken om onze gegevens terug te draaien:

mysql> STOP SLAVE;
mysql> RESET MASTER;
mysql> RESET SLAVE ALL;

Importeer ten slotte het gegenereerde SQL-bestand in de MariaDB-server voor databasewinkel op slave2:

$ mysql -u root -p shop < flashback_to_2020-02-17_013000.sql

Wanneer bovenstaande wordt toegepast, staat de tabel "producten" op de stand 2020-02-17 01:30:00. Technisch gezien kan het gegenereerde SQL-bestand worden toegepast op zowel MariaDB- als MySQL-servers. U kunt ook het binaire bestand mysqlbinlog van de MariaDB-server overbrengen, zodat u de flashback-functie op een MySQL-server kunt gebruiken. De MySQL GTID-implementatie is echter anders dan MariaDB, dus voor het herstellen van het SQL-bestand moet u MySQL GTID uitschakelen.

Een aantal voordelen van het gebruik van flashback is dat u de MySQL/MariaDB-server niet hoeft te stoppen om deze bewerking uit te voeren. Wanneer de hoeveelheid gegevens die moet worden teruggezet klein is, is het flashback-proces veel sneller dan het herstellen van de gegevens van een volledige back-up.

Alle databasequery's registreren

Algemeen logboek legt in principe elke SQL-instructie vast die door de client op de MySQL-server wordt uitgevoerd. Dit is echter misschien geen populaire beslissing op een drukke productieserver vanwege de impact op de prestaties en het ruimteverbruik. Als prestaties van belang zijn, heeft binair logboek de hogere prioriteit om te worden ingeschakeld. Algemeen logboek kan tijdens runtime worden ingeschakeld door de volgende opdrachten uit te voeren:

mysql> SET global general_log_file='/tmp/mysql.log'; 
mysql> SET global log_output = 'file';
mysql> SET global general_log = ON;

U kunt de algemene logoutput ook instellen op een tabel:

mysql> SET global log_output = 'table';

Je kunt dan de standaard SELECT-instructie gebruiken voor de mysql.general_log-tabel om query's op te halen. Verwacht wel wat meer prestatie-impact bij het uitvoeren van deze configuratie, zoals weergegeven in deze blogpost.

Anders kunt u externe bewakingshulpprogramma's gebruiken die query-sampling en -bewaking kunnen uitvoeren, zodat u de query's die op de server binnenkomen, kunt filteren en controleren. ClusterControl kan worden gebruikt om al uw zoekopdrachten te verzamelen en samen te vatten, zoals te zien is in de volgende schermafbeeldingen waarin we alle zoekopdrachten filteren die DELETE-tekenreeks bevatten:

Vergelijkbare informatie is ook beschikbaar onder ProxySQL's topquery-pagina (als uw toepassing verbinding maken via ProxySQL):

Dit kan worden gebruikt om recente wijzigingen op de databaseserver bij te houden en kan ook worden gebruikt voor auditdoeleinden.

Conclusie

Uw MySQL- en MariaDB-servers moeten te allen tijde goed worden beschermd, omdat deze meestal gevoelige gegevens bevatten waar aanvallers voor zorgen. U kunt ClusterControl ook gebruiken om de beveiligingsaspecten van uw databaseservers te beheren, zoals blijkt uit deze blogpost Hoe u uw open source-databases kunt beveiligen met ClusterControl.