Spesielt nybegynnere penetrasjonstestere legger mindre vekt på databasesikkerhet generelt. En applikasjon uten databasekonfigurasjon og sikkerhetstester kan ikke være sikker. Du bruker kanskje allerede MySQL-programvare, et databasestyringssystem, så hvordan kan du gjøre det sikrere? Her er syv trinn du må følge.
1. Bruk SSH-tunneling i stedet for ekstern tilkobling
MySQL-tjenesten kjører på port 3306 som standard. Når du installerer MySQL, vil du se at port 3306 er i lyttemodus for alle tilkoblinger. Som det står, er MySQL-porten åpen for omverdenen. Det er derfor du bør stille inn MySQL-tjenesten til å bare lytte til den lokale adressen.
Siden servere vanligvis kjøres på en Linux-distribusjon, er eksemplene nedenfor basert på en Debian-distribusjon. Filen du må bruke for SSH-tunnelering i stedet for ekstern tilkobling og for å lukke standardporten til omverdenen er
/etc/mysql/my.cnf. I denne filen må du åpne et felt som heter [mysqld] og skriv følgende kommando:[mysqld]
binde-adresse=127.0.0.1
Etter denne prosessen, ikke glem å lagre denne filen og starte tjenesten på nytt med følgende kommando:
sudo systemctl start mysqld på nytt
# eller
sudosystemctlomstartmariadb.service
Med dette vil MySQL-tjenesten kun lytte til den lokale adressen.
Hvis du bruker MariaDB, kan du også undersøke /etc/mysql/mariadb.conf.d/50-server.cnf og sjekk om det finnes en definisjon for binde-adresse.
Nå som du har satt bindingsadressen til 127.0.0.1, som er lokal vert, kan du kjøre en Nmap-skanning og sjekke utdataene:
Du kan se MySQL-porten som 127.0.0.1 representerer den lokale verten du ser. Du kan prøve å endre bindingsadressen på nytt for å sikre at dette fungerer:
[mysqld]
binde-adresse=127.5.5.1
Deretter lagrer du /etc/mysql/my.cnf fil og start MySQL-tjenesten på nytt. Hvis du utfører en Nmap-skanning igjen på dette stadiet, bør du ikke se denne bindingsadressen på localhost.
Når du vet at dette fungerer, går du tilbake til innstillingene fra første trinn og setter bindingsadressen tilbake til 127.0.0.1 og lagrer igjen.
2. Sett opp en lokal filtilgangsbarriere
MySQL kan kommunisere med det lokale filsystemet. Med spørringer kan du se innholdet i en tekst i det lokale filsystemet eller brenne søkeresultatet til en disk. For å forhindre at ondsinnede angripere bruker denne funksjonen, må du forhindre MySQL i å kommunisere med det lokale filsystemet.
Du kan bruke en funksjon kalt lokal-infil for å ta forholdsregler. Tenk deg for eksempel at du har en fil som heter "/etc/secretfile.txt" og at du har et passord i denne filen. Hvis verdien av funksjonen lokal-infil i filen /etc/mysql/my.cnf er 1, er tilgangen åpen. Så du kan få tilgang til filen secretfile.txt.
Verdien av funksjonen lokal-infil er 1. Start MySQL-databasen på nytt for at endringene skal finne sted. Koble nå til MySQL med følgende kommando og sjekk om du kan se filen secretfile.txt:
PLUKKE UTLOAD_FILE("/etc/secretfile.txt");
Det er ikke vanskelig å fange informasjonen i en hvilken som helst fil på datamaskinen din.
For å løse dette problemet, endre den lokale innfilverdien i filen /etc/mysql/my.cnf som følger:
[mysqld]
lokale-infil=0
Start MySQL-tjenesten på nytt. Koble til MySQL igjen og gjenta forrige trinn; du skal ikke lenger kunne se filinnholdet.
Hvis brukere ikke allerede har lese- og skrivetillatelser på lokale filer, vil de ikke kunne se denne filen. Det er imidlertid fortsatt noe du bør sjekke i penetrasjonstester og databasesikkerhet.
3. Angi applikasjonsbrukere og passord
Databaseadministrasjonsbrukeren og MySQL-brukeren som får tilgang til databasen må være forskjellige fra hverandre. Med andre ord er det ekstremt farlig å koble applikasjoner til MySQL med root-brukere. Hvis mulig, definer brukerne av applikasjoner som ikke fungerer OPPDATERING eller INSERT operasjoner hver for seg.
En annen ting å vurdere på dette punktet er brukerpassord. Som i nesten alle felt, må passord for MySQL-brukere være komplekse og uforutsigbare. Hvis du trenger hjelp med dette, finnes det flotte passordgeneratorsystemer du kan bruke.
4. Slett anonyme brukere
Når du installerer MySQL som standard, oppstår noen anonyme brukere. Du må slette disse og blokkere tilgangen deres. For en sikker MySQL-server bør du ikke få noe svar som et resultat av følgende spørring:
PLUKKE UT * FRA mysql.user HVORBRUKER="";
# Eksempelutgang
Tømme sett (0,001 sek.)
Hvis det er noen resultater, bør du slette disse anonyme brukerne. For eksempel, hvis det var en anonym konto kalt "anonuser" i et miljø kalt "localhost", må du bruke en kommando som følgende for å slette denne kontoen:
DROPPE BRUKER 'anonuser'@'lokal vert';
5. Sjekk MySQL Local File Permissions
Tenk deg at du er databaseadministrator og vil gå tilbake til data fra en uke siden. I dette tilfellet må du kanskje koble til databaseserveren via SSH og endre MySQL-filene du ønsker. Mens du gjorde dette, kan du ha brukt root-brukerprivilegiene til Linux; det vil si at eierskapet og tillatelsene til datafilene kan endres. Det vil du ikke.
Se på /var/lib/mysql-katalogen for å sjekke tillatelsene som er gitt. Det du må sjekke her er om eieren av alle filene er MySQL-brukeren. Følgende kommando vil gjøre susen:
sudo ls -al /var/lib/mysql
Lese- og skrivetillatelsene til filene skal kun være for MySQL-brukeren. Ingen andre brukere skal ha noen tillatelser.
6. Bruk MySQL SSL
Å tenke på et konkret eksempel er den beste måten å forstå MySQL- og SSL-bruk på. Tenk deg at en av serverne i ABC-regionen, hvor det er mange forskjellige servere, blir overtatt av ondsinnede hackere. Hackere vil utføre en intern skanning i ABC-regionen. På denne måten samler de inn informasjon om serverne.
Hvis de oppdager en MySQL-server under denne prosessen, kan de utføre en Man-in-the-Middle (MitM) angrep på målserveren, noe som betyr at de kan stjele øktinformasjonen til applikasjoner og brukere som kobler til denne serveren. En av de beste måtene å unngå dette på er å aktiver SSL på MySQL-serveren.
7. Logg- og historikkfiler
Du bruker MySQL-logger for å analysere og finne feil. Du kan redigere hvor disse loggene oppbevares ved å skrive inn my.cnf som følger:
# /etc/mysql/my.cnf
[mysqld]
Logg =/var/Logg/mylogfiles
Du kan endre mylogfiles navn eller plassering som du ønsker. Det er en fil til du må sjekke. Når du kobler til MySQL-serveren i en Linux-terminal og skriver inn forskjellige kommandoer, lagres disse spørringene i mysql_history-filen. Hvis du kjører følgende kommando, kan du se spørringene du bruker i MySQL-terminalen:
cat ~/.mysql_history
Du må slette innholdet i denne filen hvis du ikke vil gi informasjon om hva slags søk du gjør inne på serveren. Bruk følgende kommando for å slette innholdet i filen:
sudo ekko "renset"> ~/.mysql_history
Du kan deretter sjekke filinnholdet på nytt.
Den som eier databasen eier systemet
Uansett hvilken bransje du jobber i, inneholder databasen din alltid viktig informasjon. Dette kan være dine kunder, bankkontoer og passord. Ondsinnede angripere vet viktigheten og verdien av disse. Databaseutviklere og -administratorer må i det minste vite det grunnleggende de vil møte i penetrasjonstester for å slå hackerne.
