Sådan beskytter du din MySQL &MariaDB-database mod cyberangreb, når du er på et offentligt netværk

Det er nogle gange uundgåeligt at køre MySQL-databaseservere på et offentligt eller udsat netværk. Dette er en almindelig opsætning i et delt hostingmiljø, hvor en server er konfigureret med flere tjenester og ofte kører på samme server som databaseserveren. For dem, der har denne form for opsætning, bør du altid have en form for beskyttelse mod cyberangreb som denial-of-service, hacking, cracking, databrud; alt, hvilket kan resultere i tab af data. Det er ting, som vi altid vil undgå for vores databaseserver.

Her er nogle af de tips, vi kan gøre for at forbedre vores MySQL- eller MariaDB-sikkerhed.

Scan dine databaseservere regelmæssigt

Beskyttelse mod ondsindede filer på serveren er meget kritisk. Scan serveren regelmæssigt for at lede efter virus, spyware, malware eller rootkits, især hvis databaseserveren er placeret sammen med andre tjenester som mailserver, HTTP, FTP, DNS, WebDAV, telnet og så videre. Almindeligvis stammede de fleste af de databasehackede problemer fra applikationsniveauet, der står over for det offentlige netværk. Det er derfor vigtigt at scanne alle filer, især web-/applikationsfiler, da de er et af indgangspunkterne for at komme ind på serveren. Hvis disse er kompromitteret, kan hackeren komme ind i applikationsmappen og have mulighed for at læse applikationsfilerne. Disse kan indeholde følsomme oplysninger, for eksempel databasens loginoplysninger.

ClamAV er en af de mest kendte og bredt betroede antivirusløsninger til en række forskellige operativsystemer, herunder Linux. Det er gratis og meget nemt at installere og kommer med en ret god registreringsmekanisme til at lede efter uønskede ting på din server. Planlæg periodiske scanninger i cron-jobbet, for eksempel:

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

Ovenstående vil opdatere ClamAV-virusdatabasen, scanne alle mapper og filer og sende dig en e-mail om status for udførelsen og rapportere hver dag kl. 03.00.

Brug strengere brugerroller og privilegier

Når du opretter en MySQL-bruger, skal du ikke tillade alle værter at få adgang til MySQL-serveren med wildcard-vært (%). Du bør scanne din MySQL-vært og se efter en eventuel joker-værtsværdi, som vist i følgende erklæring:

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

Fra ovenstående output skal du begrænse eller fjerne alle brugere, der kun har '%'-værdi under værtskolonnen. Brugere, der har brug for at få fjernadgang til MySQL-serveren, kan tvinges til at bruge SSH-tunnelmetoden, som ikke kræver ekstern værtskonfiguration for MySQL-brugere. De fleste af MySQL-administrationsklienterne såsom MySQL Workbench og HeidiSQL kan konfigureres til at oprette forbindelse til en MySQL-server via SSH-tunelling, derfor er det muligt helt at eliminere fjernforbindelse for MySQL-brugere.

Begræns også SUPER-privilegiet til kun brugere fra localhost eller tilslutning via UNIX-socket-fil. Vær mere forsigtig, når du tildeler FILE-rettigheder til ikke-rootbrugere, da det tillader læse- og skrivefiler på serveren ved at bruge LOAD DATA INFILE og SELECT ... INTO OUTFILE-sætningerne. Enhver bruger, til hvem dette privilegium er givet, kan også læse eller skrive enhver fil, som MySQL-serveren kan læse eller skrive.

Skift standardindstillingerne for databasen

Ved at gå væk fra standardopsætningen, navngivningen og konfigurationerne kan vi reducere angrebsvektoren til et antal folder. Følgende handlinger er nogle eksempler på standardkonfigurationer, som DBA'er nemt kunne ændre, men som ofte overses i forbindelse med MySQL:

Skift standard MySQL-port til en anden end 3306.
Omdøb MySQL-rootbrugernavnet til andet end "root".
Håndhæv adgangskodeudløb og forkort adgangskodens levetid for alle brugere.
Hvis MySQL er placeret sammen med applikationsserverne, så håndhæv forbindelsen kun via UNIX-socket-filen, og stop med at lytte på port 3306 for alle IP-adresser.
Håndhæv klient-server-kryptering og server-server-replikeringskryptering.

Vi har faktisk dækket dette i detaljer i dette blogindlæg, Sådan sikrer du MySQL/MariaDB-servere.

Opsæt en forsinket slave

En forsinket slave er blot en typisk slave, men slaveserveren udfører med vilje transaktioner senere end masteren med mindst en specificeret tid, tilgængelig fra MySQL 5.6. Grundlæggende bliver en hændelse modtaget fra masteren ikke udført før mindst N sekunder senere end dens udførelse på masteren. Resultatet er, at slaven vil afspejle mesterens tilstand et stykke tid tilbage i fortiden.

En forsinket slave kan bruges til at gendanne data, hvilket ville være nyttigt, når problemet opdages med det samme, inden for forsinkelsesperioden. Antag, at vi konfigurerede en slave med en 6-timers forsinkelse fra masteren. Hvis vores database blev ændret eller slettet (ved et uheld af en udvikler eller bevidst af en hacker) inden for dette tidsinterval, er der mulighed for, at vi kan vende tilbage til øjeblikket lige før det skete ved at stoppe den aktuelle master og derefter bringe slaveserveren op indtil et bestemt punkt med følgende kommando:

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

Hvor "xxxxx" er den binære logfil, og "yyyyy" er positionen lige før katastrofen sker (brug mysqlbinlog-værktøjet til at undersøge disse begivenheder). Til sidst, forfrem slaven til at blive den nye mester, og din MySQL-tjeneste er nu tilbage operationel som normalt. Denne metode er sandsynligvis den hurtigste måde at gendanne din MySQL-database i produktionsmiljøet uden at skulle genindlæse en sikkerhedskopi. Med et antal forsinkede slaver med forskellig længde varighed, som vist i denne blog, Multiple Delayed Replication Slaves for Disaster Recovery with Low RTO om, hvordan man opsætter en omkostningseffektiv forsinket replikeringsserver oven på Docker-containere.

Aktiver binær logning

Binær logning anbefales generelt at være aktiveret, selvom du kører på en selvstændig MySQL/MariaDB-server. Den binære log indeholder oplysninger om SQL-sætninger, der ændrer databaseindhold. Oplysningerne gemmes i form af "begivenheder", der beskriver ændringerne. På trods af præstationspåvirkning giver det at have binær log dig mulighed for at afspille din databaseserver til det nøjagtige punkt, hvor du vil have den gendannet, også kendt som point-in-time recovery (PITR). Binær logning er også obligatorisk for replikering.

Med binær logning aktiveret, skal man inkludere den binære logfil og positionsinformation, når man tager en fuld backup. For mysqldump vil brug af --master-data flaget med værdi 1 eller 2 udskrive den nødvendige information, som vi kan bruge som udgangspunkt for at rulle databasen frem, når de binære logfiler senere afspilles.

Med binær logning aktiveret, kan du bruge en anden cool gendannelsesfunktion kaldet flashback, som er beskrevet i næste afsnit.

Aktiver Flashback

Flashback-funktionen er tilgængelig i MariaDB, hvor du kan gendanne dataene til det forrige snapshot i en MySQL-database eller i en tabel. Flashback bruger mysqlbinlog til at oprette rollback-sætningerne, og det har brug for et HELT binært logrækkebillede til det. For at bruge denne funktion skal MySQL/MariaDB-serveren konfigureres med følgende:

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

Følgende arkitekturdiagram illustrerer, hvordan flashback er konfigureret på en af slaverne:

For at udføre flashback-handlingen skal du først bestemme dato og klokkeslæt når du vil "se" dataene, eller binær logfil og position. Brug derefter --flashback-flaget med mysqlbinlog-værktøjet til at generere SQL-sætninger for at rulle dataene tilbage til det punkt. I den genererede SQL-fil vil du bemærke, at DELETE-begivenhederne konverteres til INSERTs og omvendt, og den bytter også WHERE- og SET-dele af UPDATE-begivenhederne.

Følgende kommandolinje skal udføres på slave2 (konfigureret med 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

Afmonter derefter slave2 fra replikeringskæden, fordi vi vil bryde den og bruge serveren til at rulle vores data tilbage:

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

Til sidst skal du importere den genererede SQL-fil til MariaDB-serveren til databasebutik på slave2:

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

Når ovenstående anvendes, vil tabellen "produkter" være på tilstanden 2020-02-17 01:30:00. Teknisk set kan den genererede SQL-fil anvendes på både MariaDB- og MySQL-servere. Du kan også overføre mysqlbinlog-binæren fra MariaDB-serveren, så du kan bruge flashback-funktionen på en MySQL-server. MySQL GTID-implementeringen er dog anderledes end MariaDB, så gendannelse af SQL-filen kræver, at du deaktiverer MySQL GTID.

Et par fordele ved at bruge flashback er, at du ikke behøver at stoppe MySQL/MariaDB-serveren for at udføre denne operation. Når mængden af data, der skal gendannes, er lille, er flashback-processen meget hurtigere end at gendanne dataene fra en fuld backup.

Log alle databaseforespørgsler

Generel log fanger stort set alle SQL-sætninger, der udføres af klienten på MySQL-serveren. Dette er dog muligvis ikke en populær beslutning på en travl produktionsserver på grund af ydeevnepåvirkningen og pladsforbruget. Hvis ydeevnen har betydning, har binær log den højere prioritet at blive aktiveret. Generel log kan aktiveres under kørsel ved at køre følgende kommandoer:

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

Du kan også indstille det generelle logoutput til en tabel:

mysql> SET global log_output = 'table';

Du kan derefter bruge standard SELECT-sætningen mod mysql.general_log-tabellen til at hente forespørgsler. Forvent en smule mere effekt på ydeevnen, når du kører med denne konfiguration som vist i dette blogindlæg.

Ellers kan du bruge eksterne overvågningsværktøjer, der kan udføre forespørgselssampling og -overvågning, så du kan filtrere og revidere de forespørgsler, der kommer ind på serveren. ClusterControl kan bruges til at indsamle og opsummere alle dine forespørgsler, som vist i følgende skærmbilleder, hvor vi filtrerer alle forespørgsler, der indeholder DELETE-strengen:

Lignende information er også tilgængelig under ProxySQL's topforespørgselsside (hvis din applikation er opretter forbindelse via ProxySQL):

Dette kan bruges til at spore de seneste ændringer, der er sket på databaseserveren og kan også bruges til revisionsformål.

Konklusion

Dine MySQL- og MariaDB-servere skal til enhver tid være godt beskyttet, da de normalt indeholder følsomme data, som angriberne ser efter. Du kan også bruge ClusterControl til at administrere sikkerhedsaspekterne af dine databaseservere, som vist i dette blogindlæg, Sådan sikrer du dine Open Source-databaser med ClusterControl.