Hur man säkrar MySQL/MariaDB-servrar

Efter attacker mot MongoDB-databaser har vi nyligen också sett att MySQL-servrar är måltavla av ransomware. Detta borde inte komma som en överraskning med tanke på det ökande antagandet av offentliga och privata moln. Att köra en dåligt konfigurerad databas i molnet kan bli en stor skuld.

I det här blogginlägget kommer vi att dela med dig av ett antal tips om hur du skyddar och säkrar dina MySQL- eller MariaDB-servrar.

Förstå attackvektorn

Citerar SCMagazine:
“Attacken börjar med brute-forcering av root-lösenordet för MySQL-databasen. När du är inloggad hämtas MySQL-databaserna och tabellerna. Angriparen skapar sedan en ny tabell som heter "VARNING" som innehåller en kontaktadress, en bitcoin-adress och ett betalningskrav. ”

Baserat på artikeln börjar attackvektorn med att gissa MySQL root-lösenordet via brute-force-metoden. Brute-force attack består av att en angripare försöker många lösenord eller lösenfraser med hopp om att så småningom gissa rätt. Detta innebär att korta lösenord vanligtvis kan upptäckas ganska snabbt, men längre lösenord kan ta dagar eller månader.

Brute-force är en vanlig attack som skulle hända med vilken tjänst som helst. Tyvärr för MySQL (och många andra DBMS) finns det ingen out-of-the-box-funktion som upptäcker och blockerar brute-force-attacker från specifika adresser under användarautentisering. MySQL fångar dock autentiseringsfel i felloggen.

Granska din lösenordspolicy

Att granska MySQL-lösenordspolicyn är alltid det första steget för att skydda din server. MySQL root-lösenord bör vara tillräckligt starkt med en kombination av alfabet, siffror och symboler (vilket gör det svårare att komma ihåg) och förvaras på ett säkert ställe. Byt lösenordet regelbundet, åtminstone varje kalenderkvartal. Baserat på attackvektorn är detta den svagaste punkten som hackare riktar in sig på. Om du värdesätter din data, glöm inte bort den här delen.

MySQL-distributioner som utförs av ClusterControl kommer alltid att följa leverantörens bästa säkerhetspraxis, till exempel kommer det inte att finnas någon jokerteckenvärd definierad under GRANT och känsliga inloggningsuppgifter lagrade i konfigurationsfilen är endast tillåtna för OS:s rotanvändare. Vi rekommenderar starkt våra användare att ange ett starkt lösenord under implementeringsstadiet.

I en standardproduktionsmiljö är databasservrar vanligtvis placerade på en lägre nivå. Detta lager ska vara skyddat och endast tillgängligt från den övre nivån, såsom applikation eller lastbalanserare. Om databasen är samlokaliserad med applikationen kan du till och med låsa ned mot icke-lokala adresser och använda MySQL-socketfil istället (mindre overhead och säkrare).

Det är viktigt att konfigurera parametern "bind-adress" här. Observera att MySQL-bindning är begränsad till antingen ingen, en eller alla IP-adresser (0.0.0.0) på servern. Om du inte har något val och behöver MySQL för att lyssna på alla nätverksgränssnitt, begränsa åtkomsten till MySQL-tjänsten från kända bra källor. Använd ett brandväggsprogram eller en säkerhetsgrupp för att vitlista åtkomst endast från värdar som behöver komma åt databasen direkt.

Ibland måste MySQL-servern exponeras för ett offentligt nätverk för integrationsändamål (t.ex. övervakning, revision, säkerhetskopiering etc). Det är bra så länge du ritar en kant runt den. Låt inte oönskade källor "se" MySQL-servern. Du kan satsa på hur många människor i världen som vet att 3306 är standardporten för MySQL-tjänsten, och genom att helt enkelt utföra en portskanning mot en nätverksadress kan en angripare skapa en lista över exponerade MySQL-servrar i subnätet på mindre än en minut. Använd en anpassad MySQL-port genom att konfigurera "port"-parametern i MySQL-konfigurationsfilen för att minimera exponeringsrisken.

Läs användarpolicyn

Begränsa vissa användare att inneha de kritiska administrationsrättigheterna, särskilt GRANT, SUPER och PROCESS. Du kan också aktivera super_read_only om servern är en slav, endast tillgänglig på MySQL 5.7.8 och Percona Server 5.6.21 och senare (tyvärr inte med MariaDB). När den är aktiverad kommer servern inte att tillåta några uppdateringar, förutom att uppdatera replikeringsförråden om slavstatusloggar är tabeller, även för de användare som har SUPER-behörighet. Ta bort standardtestdatabasen och alla användare med tomma lösenord för att begränsa penetrationsområdet. Detta är en av säkerhetskontrollerna som utförs av ClusterControl, implementerad som en databasrådgivare.

Det är också en bra idé att begränsa antalet tillåtna anslutningar till ett enda konto. Du kan göra det genom att ställa in variabeln max_user_connections i mysqld (standard är 0, lika med obegränsat) eller använda resurskontrollalternativen i GRANT/CREATE USER/ALTER USER-satser. GRANT-satsen stöder begränsning av antalet samtidiga anslutningar till servern med ett konto, till exempel:

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

Standardadministratörens användarnamn på MySQL-servern är "root". Hackare försöker ofta få tillgång till dess behörigheter. För att göra denna uppgift mycket svårare, byt namn på "root" till något annat. MySQL-användarnamn kan vara upp till 32 tecken långa (16 tecken före MySQL 5.7.8). Det är möjligt att använda ett längre användarnamn för superadminanvändaren genom att använda RENAME-satsen som visas nedan:

mysql> RENAME USER root TO new_super_administrator_username;

En sidoanteckning för ClusterControl-användare, ClusterControl behöver känna till MySQL-rotanvändaren och lösenordet för att automatisera och hantera databasservern åt dig. Som standard kommer den att leta efter "root". Om du byter namn på root-användaren till något annat, anger du "monitored_mysql_root_user={new_user}" i cmon_X.cnf (där X är kluster-ID) och startar om CMON-tjänsten för att tillämpa ändringen.

Säkerhetskopieringspolicy

Även om hackarna uppgav att du skulle få tillbaka din data när lösensumman är betald, så var det vanligtvis inte fallet. Att öka säkerhetskopieringsfrekvensen skulle öka möjligheten att återställa dina raderade data. Till exempel, istället för en fullständig säkerhetskopiering en gång i veckan med daglig inkrementell säkerhetskopiering, kan du schemalägga en fullständig säkerhetskopiering en gång om dagen med inkrementell säkerhetskopiering varje timme. Du kan göra detta enkelt med ClusterControls funktion för säkerhetskopiering och återställa dina data om något går fel.

Om du har aktiverat binära loggar (binlogs) är det ännu bättre. Du kan skapa en fullständig säkerhetskopia varje dag och säkerhetskopiera de binära loggarna. Binlogs är viktiga för punkt-in-time återställning och bör säkerhetskopieras regelbundet som en del av din säkerhetskopiering. DBA:er tenderar att missa denna enkla metod, som är värd vartenda öre. Om du blev hackad kan du alltid återhämta dig till den sista punkten innan det hände, förutsatt att hackarna inte rensat de binära loggarna. Observera att rensning av binära loggar endast är möjlig när angriparen har SUPER-behörighet.

En annan viktig sak är att säkerhetskopiorna måste kunna återställas. Verifiera säkerhetskopiorna då och då och undvik dåliga överraskningar när du behöver återställa.

Skydda din webb-/applikationsserver

Tja, om du har isolerat dina MySQL-servrar, finns det fortfarande chanser för angriparna att komma åt dem via webben eller applikationsservern. Genom att injicera ett skadligt skript (t.ex. Cross-Site Scripting, SQL-injektion) mot målwebbplatsen kan man komma in i applikationskatalogen och ha möjlighet att läsa applikationsfilerna. Dessa kan innehålla känslig information, till exempel databasens inloggningsuppgifter. Genom att titta på detta kan en angripare helt enkelt logga in i databasen, ta bort alla tabeller och lämna en "lösensumma"-tabell inuti. Det behöver inte nödvändigtvis vara en MySQL root-användare för att lösa ett offer.

Det finns tusentals sätt att kompromissa med en webbserver och du kan inte riktigt stänga den inkommande porten 80 eller 443 för detta ändamål. Ytterligare ett lager av skydd krävs för att skydda din webbserver från HTTP-baserade injektioner. Du kan använda Web Application Firewall (WAF) som Apache ModSecurity, NAXSI (WAF för nginx), WebKnight (WAF för IIS) eller helt enkelt köra dina webbservrar i ett säkert Content Delivery Network (CDN) som CloudFlare, Akamai eller Amazon CloudFront.

Håll dig alltid uppdaterad

Du har säkert hört talas om den kritiska zero-day MySQL-exploateringen, där en icke-privilegierad användare kan eskalera sig själv till superanvändare? Det låter läskigt. Lyckligtvis har alla kända leverantörer uppdaterat sitt arkiv för att inkludera en buggfix för detta problem.

För produktionsanvändning rekommenderas det starkt att du installerar MySQL/MariaDB-paketen från leverantörens arkiv. Lita inte på standardlagringsplatsen för operativsystemet, där paketen vanligtvis är föråldrade. Om du kör i en klustermiljö som Galera Cluster, eller till och med MySQL Replication, har du alltid valet att patcha systemet med minimal driftstopp. Gör detta till en rutin och försök att automatisera uppgraderingsproceduren så mycket som möjligt.

ClusterControl stöder rullande mindre versionsuppgradering (en nod i taget) för MySQL/MariaDB med ett enda klick. Uppgradering av större versioner (t.ex. från MySQL 5.6 till MySQL 5.7) kräver vanligtvis avinstallation av befintliga paket och det är en riskabel uppgift att automatisera. Noggrann planering och testning är nödvändig för en sådan typ av uppgradering.

Slutsats

Ransomware är en guldkruka för lätta pengar. Vi kommer förmodligen att se fler säkerhetsintrång i framtiden, och det är bättre att vidta åtgärder innan något händer. Hackare riktar sig mot många sårbara servrar där ute, och mycket troligt kommer denna attack att sprida sig till andra databastekniker också. Att skydda dina data är en ständig utmaning för databasadministratörer. Den verkliga fienden är inte gärningsmannen, utan vår inställning till att skydda våra kritiska tillgångar.