Det är ibland oundvikligt att köra MySQL-databasservrar på ett offentligt eller exponerat nätverk. Detta är en vanlig installation i en delad värdmiljö, där en server är konfigurerad med flera tjänster och ofta körs inom samma server som databasservern. För de som har den här typen av inställning bör du alltid ha något slags skydd mot cyberattacker som denial-of-service, hacking, cracking, dataintrång; allt som kan resultera i dataförlust. Det här är saker som vi alltid vill undvika för vår databasserver.
Här är några av tipsen som vi kan göra för att förbättra vår MySQL- eller MariaDB-säkerhet.
Skanna dina databasservrar regelbundet
Skydd mot alla skadliga filer på servern är mycket viktigt. Skanna servern regelbundet för att leta efter virus, spionprogram, skadlig programvara eller rootkits, särskilt om databasservern är samlokaliserad med andra tjänster som e-postserver, HTTP, FTP, DNS, WebDAV, telnet och så vidare. Vanligtvis härrörde de flesta av de databashackade problemen från applikationsnivån som står inför det offentliga nätverket. Därför är det viktigt att skanna alla filer, särskilt webb-/applikationsfiler eftersom de är en av ingångspunkterna för att komma in på servern. Om dessa äventyras kan hackaren komma in i applikationskatalogen och ha möjlighet att läsa applikationsfilerna. Dessa kan innehålla känslig information, till exempel databasens inloggningsuppgifter.
ClamAV är en av de mest kända och pålitliga antiviruslösningarna för en mängd olika operativsystem, inklusive Linux. Det är gratis och väldigt lätt att installera och kommer med en ganska bra upptäcktsmekanism för att leta efter oönskade saker på din server. Schemalägg periodiska skanningar i cron-jobbet, till exempel:
0 3 * * * /bin/freshclam ; /bin/clamscan / --recursive=yes -i > /tmp/clamav.log ; mail -s clamav_log_`hostname` [email protected] < /tmp/clamav.logOvanstående kommer att uppdatera ClamAV-virusdatabasen, skanna alla kataloger och filer och skicka ett e-postmeddelande om statusen för utförandet och rapportera varje dag kl. 03.00.
Använd striktare användarroller och privilegier
När du skapar en MySQL-användare, tillåt inte alla värdar att komma åt MySQL-servern med jokerteckenvärd (%). Du bör skanna din MySQL-värd och leta efter alla jokerteckenvärden, som visas i följande uttalande:
mysql> SELECT user,host FROM mysql.user WHERE host = '%';
+---------+------+
| user | host |
+---------+------+
| myadmin | % |
| sbtest | % |
| user1 | % |
+---------+------+Från ovanstående utdata, sträng eller ta bort alla användare som bara har '%'-värde under värdkolumnen. Användare som behöver få åtkomst till MySQL-servern på distans kan tvingas använda SSH-tunnelmetoden, som inte kräver fjärrvärdkonfiguration för MySQL-användare. De flesta MySQL-administrationsklienter som MySQL Workbench och HeidiSQL kan konfigureras för att ansluta till en MySQL-server via SSH-tunelling, därför är det möjligt att helt eliminera fjärranslutning för MySQL-användare.
Begränsa också SUPER-privilegiet till endast användare från localhost, eller ansluter via UNIX-socket-fil. Var mer försiktig när du tilldelar FILE-behörighet till icke-rootanvändare eftersom det tillåter läsning och skrivning av filer på servern med satserna LOAD DATA INFILE och SELECT ... INTO OUTFILE. Alla användare som har denna behörighet kan också läsa eller skriva vilken fil som helst som MySQL-servern kan läsa eller skriva.
Ändra standardinställningarna för databasen
Genom att gå bort från standardinställningarna, namngivningen och konfigurationerna kan vi reducera attackvektorn till ett antal veck. Följande åtgärder är några exempel på standardkonfigurationer som DBA:er lätt kan ändra men ofta förbises relaterade till MySQL:
- Ändra MySQL-standardporten till annan än 3306.
- Byt namn på MySQL-rotanvändarnamnet till något annat än "root".
- Tvinga till att lösenordet löper ut och minska lösenordets livslängd för alla användare.
- Om MySQL är samlokaliserat med applikationsservrarna, framtvinga anslutning endast via UNIX-socket-filen och sluta lyssna på port 3306 för alla IP-adresser.
- Tvinga igenom klient-server-kryptering och server-server-replikering.
Vi har faktiskt behandlat detta i detalj i det här blogginlägget, Hur man säkrar MySQL/MariaDB-servrar.
Konfigurera en fördröjd slav
En fördröjd slav är bara en typisk slav, men slavservern utför avsiktligt transaktioner senare än mastern med åtminstone en specificerad tid, tillgänglig från MySQL 5.6. I grund och botten exekveras inte en händelse som tas emot från mastern förrän åtminstone N sekunder senare än dess utförande på mastern. Resultatet är att slaven kommer att återspegla befälhavarens tillstånd en tid tillbaka i det förflutna.
En fördröjd slav kan användas för att återställa data, vilket skulle vara till hjälp när problemet upptäcks omedelbart, inom fördröjningsperioden. Anta att vi konfigurerade en slav med en 6-timmars fördröjning från mastern. Om vår databas modifierades eller raderades (av misstag av en utvecklare eller avsiktligt av en hacker) inom detta tidsintervall, finns det en möjlighet för oss att återgå till ögonblicket precis innan det hände genom att stoppa den nuvarande mastern och sedan ta upp slavservern tills en viss punkt med följande kommando:
# on delayed slave
mysql> STOP SLAVE;
mysql> START SLAVE UNTIL MASTER_LOG_FILE='xxxxx', MASTER_LOG_POS=yyyyyy;Där "xxxxx" är den binära loggfilen och "åååå" är positionen precis innan katastrofen inträffar (använd verktyget mysqlbinlog för att undersöka dessa händelser). Till sist, främja slaven att bli den nya mästaren och din MySQL-tjänst är nu åter i drift som vanligt. Denna metod är förmodligen det snabbaste sättet att återställa din MySQL-databas i produktionsmiljön utan att behöva ladda om en säkerhetskopia. Att ha ett antal fördröjda slavar med olika längd varaktighet, som visas i den här bloggen, Multiple Delayed Replication Slaves for Disaster Recovery with Low RTO om hur man ställer in en kostnadseffektiv fördröjd replikeringsserver ovanpå Docker-behållare.
Aktivera binär loggning
Binär loggning rekommenderas generellt att aktiveras även om du kör på en fristående MySQL/MariaDB-server. Den binära loggen innehåller information om SQL-satser som ändrar databasinnehåll. Informationen lagras i form av "händelser" som beskriver ändringarna. Trots prestandapåverkan ger binär logg dig möjligheten att spela upp din databasserver till exakt den punkt där du vill att den ska återställas, även känd som punkt-i-tidsåterställning (PITR). Binär loggning är också obligatorisk för replikering.
Med binär loggning aktiverad måste man inkludera den binära loggfilen och positionsinformation när man tar upp en fullständig säkerhetskopia. För mysqldump kommer att använda flaggan --master-data med värde 1 eller 2 att skriva ut den nödvändiga informationen som vi kan använda som utgångspunkt för att rulla fram databasen när de binära loggarna spelas om senare.
Med binär loggning aktiverad kan du använda en annan cool återställningsfunktion som kallas flashback, som beskrivs i nästa avsnitt.
Aktivera Flashback
Flashback-funktionen är tillgänglig i MariaDB, där du kan återställa data till föregående ögonblicksbild i en MySQL-databas eller i en tabell. Flashback använder mysqlbinlog för att skapa rollback-satserna och den behöver en HELT binär loggradbild för det. För att använda den här funktionen måste MySQL/MariaDB-servern konfigureras med följande:
[mysqld]
...
binlog_format = ROW
binlog_row_image = FULLFöljande arkitekturdiagram illustrerar hur flashback konfigureras på en av slavarna:
För att utföra flashback-operationen måste du först bestämma datum och tid när du vill "se" data, eller binär loggfil och position. Använd sedan --flashback-flaggan med mysqlbinlog-verktyget för att generera SQL-satser för att återställa data till den punkten. I den genererade SQL-filen kommer du att märka att DELETE-händelserna konverteras till INSERTs och vice versa, och den byter även WHERE och SET delar av UPDATE-händelserna.
Följande kommandorad ska köras på slave2 (konfigurerad 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.sqlTa sedan loss slave2 från replikeringskedjan eftersom vi kommer att bryta den och använda servern för att återställa våra data:
mysql> STOP SLAVE;
mysql> RESET MASTER;
mysql> RESET SLAVE ALL;Importera slutligen den genererade SQL-filen till MariaDB-servern för databasbutik på slave2:
$ mysql -u root -p shop < flashback_to_2020-02-17_013000.sqlNär ovanstående tillämpas kommer tabellen "produkter" att ha statusen 2020-02-17 01:30:00. Tekniskt sett kan den genererade SQL-filen appliceras på både MariaDB- och MySQL-servrar. Du kan också överföra mysqlbinlog-binären från MariaDB-servern så att du kan använda flashback-funktionen på en MySQL-server. Men implementeringen av MySQL GTID skiljer sig från MariaDB, så att återställa SQL-filen kräver att du inaktiverar MySQL GTID.
Ett par fördelar med flashback är att du inte behöver stoppa MySQL/MariaDB-servern för att utföra denna operation. När mängden data som ska återställas är liten är flashback-processen mycket snabbare än att återställa data från en fullständig säkerhetskopia.
Logga alla databasfrågor
Allmän logg fångar i princip varje SQL-sats som exekveras av klienten i MySQL-servern. Men detta kanske inte är ett populärt beslut på en upptagen produktionsserver på grund av prestandapåverkan och utrymmesförbrukning. Om prestanda spelar roll, har binär logg högre prioritet att aktiveras. Allmän logg kan aktiveras under körning genom att köra följande kommandon:
mysql> SET global general_log_file='/tmp/mysql.log';
mysql> SET global log_output = 'file';
mysql> SET global general_log = ON;Du kan också ställa in den allmänna loggutgången till en tabell:
mysql> SET global log_output = 'table';Du kan sedan använda standardsatsen SELECT mot tabellen mysql.general_log för att hämta frågor. Förvänta dig lite mer prestandapåverkan när du kör med den här konfigurationen som visas i det här blogginlägget.
Annars kan du använda externa övervakningsverktyg som kan utföra frågesampling och övervakning så att du kan filtrera och granska de frågor som kommer in på servern. ClusterControl kan användas för att samla in och sammanfatta alla dina frågor, som visas i följande skärmdumpar där vi filtrerar alla frågor som innehåller DELETE-strängen:
Liknande information finns också tillgänglig under ProxySQL:s sida med vanliga frågor (om din applikation är ansluter via ProxySQL):
Detta kan användas för att spåra de senaste ändringarna som har hänt på databasservern och kan även användas för revisionsändamål.
Slutsats
Dina MySQL- och MariaDB-servrar måste alltid vara väl skyddade eftersom de vanligtvis innehåller känslig data som angripare ser efter. Du kan också använda ClusterControl för att hantera säkerhetsaspekterna för dina databasservrar, vilket framgår av detta blogginlägg, How to Secure Your Open Source-databaser med ClusterControl.