Sådan sikrer du MySQL/MariaDB-servere

Efter angreb på MongoDB-databaser har vi for nylig også set, at MySQL-servere bliver ramt af ransomware. Dette burde ikke komme som en overraskelse i betragtning af den stigende anvendelse af offentlige og private skyer. At køre en dårligt konfigureret database i skyen kan blive et stort ansvar.

I dette blogindlæg deler vi en række tips med dig om, hvordan du beskytter og sikrer dine MySQL- eller MariaDB-servere.

Forstå angrebsvektoren

Citerer SCMagazine:
“Angrebet starter med brute-forcering af root-adgangskoden til MySQL-databasen. Når du er logget ind, hentes MySQL-databaserne og -tabellerne. Angriberen opretter derefter en ny tabel kaldet 'ADVARSEL', der inkluderer en kontakt-e-mailadresse, en bitcoin-adresse og et betalingskrav. ”

Baseret på artiklen starter angrebsvektoren med at gætte MySQL root-adgangskoden via brute-force-metoden. Brute-force-angreb består af, at en angriber prøver mange adgangskoder eller adgangssætninger med håbet om til sidst at gætte rigtigt. Det betyder, at korte adgangskoder normalt kan opdages ret hurtigt, men længere adgangskoder kan tage dage eller måneder.

Brute-force er et almindeligt angreb, der ville ske for enhver tjeneste. Desværre for MySQL (og mange andre DBMS) er der ingen out-of-the-box-funktion, der registrerer og blokerer brute-force-angreb fra specifikke adresser under brugergodkendelse. MySQL fanger dog godkendelsesfejl i fejlloggen.

Gennemgå din adgangskodepolitik

Gennemgang af MySQL-adgangskodepolitikken er altid det første skridt til at beskytte din server. MySQL root-adgangskoden skal være stærk nok med en kombination af alfabeter, tal og symboler (hvilket gør det sværere at huske) og opbevaret et sikkert sted. Skift adgangskoden regelmæssigt, mindst hvert kalenderkvartal. Baseret på angrebsvektoren er dette det svageste punkt, som hackere målretter mod. Hvis du værdsætter dine data, skal du ikke overse denne del.

MySQL-implementeringer udført af ClusterControl vil altid følge leverandørens bedste sikkerhedspraksis, for eksempel vil der ikke være nogen wildcard-vært defineret under GRANT, og følsomme login-legitimationsoplysninger gemt i konfigurationsfilen er kun tilladt for OS's root-bruger. Vi anbefaler kraftigt vores brugere at angive en stærk adgangskode under implementeringsfasen.

I et standardproduktionsmiljø er databaseservere normalt placeret på et lavere niveau. Dette lag skal være beskyttet og kun tilgængeligt fra det øverste niveau, såsom påføring eller belastningsbalancer. Hvis databasen er placeret sammen med applikationen, kan du endda låse ned mod ikke-lokale adresser og bruge MySQL socket-fil i stedet (mindre overhead og mere sikker).

Konfiguration af parameteren "bind-adresse" er afgørende her. Vær opmærksom på, at MySQL-binding er begrænset til enten ingen, én eller alle IP-adresser (0.0.0.0) på serveren. Hvis du ikke har noget valg og har brug for MySQL til at lytte til alle netværksgrænseflader, skal du begrænse adgangen til MySQL-tjenesten fra kendte gode kilder. Brug et firewallprogram eller en sikkerhedsgruppe til kun at hvidliste adgang fra værter, der skal have direkte adgang til databasen.

Nogle gange skal MySQL-serveren eksponeres for et offentligt netværk til integrationsformål (f.eks. overvågning, revision, backup osv.). Det er fint, så længe du tegner en grænse omkring det. Lad ikke uønskede kilder "se" MySQL-serveren. Du kan vædde på, hvor mange mennesker i verden, der ved, at 3306 er standardporten for MySQL-tjenesten, og ved blot at udføre en portscanning mod en netværksadresse, kan en angriber oprette en liste over udsatte MySQL-servere i undernettet på mindre end et minut. Det anbefales at bruge en tilpasset MySQL-port ved at konfigurere "port"-parameteren i MySQL-konfigurationsfilen for at minimere eksponeringsrisikoen.

Gennemgå brugerpolitikken

Begræns visse brugere til at have de kritiske administrationsrettigheder, især GRANT, SUPER og PROCESS. Du kan også aktivere super_read_only, hvis serveren er en slave, kun tilgængelig på MySQL 5.7.8 og Percona Server 5.6.21 og senere (desværre ikke med MariaDB). Når den er aktiveret, vil serveren ikke tillade nogen opdateringer, udover at opdatere replikeringslagrene, hvis slavestatuslogfiler er tabeller, selv for de brugere, der har SUPER-rettigheder. Fjern standardtestdatabasen og alle brugere med tomme adgangskoder for at indsnævre omfanget af penetration. Dette er en af ​​de sikkerhedstjek, der udføres af ClusterControl, implementeret som en databaserådgiver.

Det er også en god idé at begrænse antallet af tilladte forbindelser til en enkelt konto. Du kan gøre det ved at indstille max_user_connections-variablen i mysqld (standard er 0, lig med ubegrænset) eller bruge ressourcekontrolmulighederne i GRANT/CREATE USER/ALTER USER-sætninger. GRANT-erklæringen understøtter begrænsning af antallet af samtidige forbindelser til serveren med en konto, for eksempel:

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

Standard administratorbrugernavnet på MySQL-serveren er "root". Hackere forsøger ofte at få adgang til deres tilladelser. For at gøre denne opgave meget sværere, omdøb "root" til noget andet. MySQL-brugernavne kan være op til 32 tegn lange (16 tegn før MySQL 5.7.8). Det er muligt at bruge et længere brugernavn til superadmin-brugeren ved at bruge RENAME-sætningen som vist nedenfor:

mysql> RENAME USER root TO new_super_administrator_username;

En sidebemærkning til ClusterControl-brugere, ClusterControl skal kende MySQL root-brugeren og adgangskoden for at automatisere og administrere databaseserveren for dig. Som standard vil den søge efter 'root'. Hvis du omdøber root-brugeren til noget andet, skal du angive "monitored_mysql_root_user={new_user}" inde i cmon_X.cnf (hvor X er klynge-id'et) og genstarte CMON-tjenesten for at anvende ændringen.

Sikkerhedskopieringspolitik

Selvom hackerne sagde, at du ville få dine data tilbage, når løsesummen er betalt, var det normalt ikke tilfældet. Forøgelse af sikkerhedskopieringsfrekvensen vil øge muligheden for at gendanne dine slettede data. For eksempel, i stedet for en fuld backup en gang om ugen med daglig trinvis backup, kan du planlægge en fuld backup en gang om dagen med trinvis backup hver time. Du kan nemt gøre dette med ClusterControls sikkerhedskopieringsstyringsfunktion og gendanne dine data, hvis noget går galt.

Hvis du har aktiveret binære logfiler (binlogs), er det endnu bedre. Du kan oprette en fuld backup hver dag og tage backup af de binære logfiler. Binlogs er vigtige for punkt-i-tidsgendannelse og bør sikkerhedskopieres regelmæssigt som en del af din sikkerhedskopieringsprocedure. DBA'er har en tendens til at savne denne simple metode, som er hver en øre værd. I tilfælde af, at du blev hacket, kan du altid komme tilbage til det sidste punkt, før det skete, forudsat at hackerne ikke rensede de binære logfiler. Bemærk, at rensning af binære logfiler kun er mulig, når angriberen har SUPER-privilegier.

En mere vigtig ting er, at backupfilerne skal kunne gendannes. Bekræft sikkerhedskopierne nu og da, og undgå dårlige overraskelser, når du skal gendanne.

Beskyt din web-/applikationsserver

Nå, hvis du har isoleret dine MySQL-servere, er der stadig chancer for, at angriberne kan få adgang til dem via web- eller applikationsserver. Ved at injicere et ondsindet script (f.eks. Cross-Site Scripting, SQL-injektion) mod målwebstedet, kan man komme ind i applikationsbiblioteket og have mulighed for at læse applikationsfilerne. Disse kan indeholde følsomme oplysninger, for eksempel databasens loginoplysninger. Ved at se på dette kan en angriber blot logge ind i databasen, slette alle tabeller og efterlade en "løsesum"-tabel inde. Det behøver ikke nødvendigvis at være en MySQL root-bruger for at løse et offer.

Der er tusindvis af måder at kompromittere en webserver på, og du kan ikke rigtig lukke den indgående port 80 eller 443 til dette formål. Et andet beskyttelseslag er påkrævet for at beskytte din webserver mod HTTP-baserede injektioner. Du kan bruge Web Application Firewall (WAF) som Apache ModSecurity, NAXSI (WAF for nginx), WebKnight (WAF for IIS) eller blot køre dine webservere i et sikkert Content Delivery Network (CDN) som CloudFlare, Akamai eller Amazon CloudFront.

Hold dig altid opdateret

Du har sikkert hørt om den kritiske zero-day MySQL udnyttelse, hvor en ikke-privilegeret bruger kan eskalere sig selv til superbruger? Det lyder skræmmende. Heldigvis har alle kendte leverandører opdateret deres lager til at inkludere en fejlrettelse til dette problem.

Til produktionsbrug anbefales det stærkt, at du installerer MySQL/MariaDB-pakkerne fra leverandørens lager. Stol ikke på standardoperativsystemlageret, hvor pakkerne normalt er forældede. Hvis du kører i et klyngemiljø som Galera Cluster eller endda MySQL-replikering, har du altid valget mellem at patche systemet med minimal nedetid. Gør dette til en rutine, og prøv at automatisere opgraderingsproceduren så meget som muligt.

ClusterControl understøtter rullende mindre versionsopgradering (én node ad gangen) til MySQL/MariaDB med et enkelt klik. Opgradering af større versioner (f.eks. fra MySQL 5.6 til MySQL 5.7) kræver almindeligvis afinstallation af de eksisterende pakker, og det er en risikabel opgave at automatisere. Omhyggelig planlægning og test er nødvendig for en sådan form for opgradering.

Konklusion

Ransomware er en guldpotte til let penge. Vi vil sandsynligvis se flere sikkerhedsbrud i fremtiden, og det er bedre at tage affære, før der sker noget. Hackere retter sig mod mange sårbare servere derude, og meget sandsynligt vil dette angreb også sprede sig til andre databaseteknologier. Beskyttelse af dine data er en konstant udfordring for databaseadministratorer. Den virkelige fjende er ikke gerningsmanden, men vores holdning til at beskytte vores kritiske aktiver.