MySQL përmes VPN: verifikoni serverin, jo vetëm kriptimin
Kriptimi drejt hostit të gabuar mbetet i gabuar. Krahasoni vlerat ssl-mode, më pas ekzekutoni një lidhje që emërton serverin e synuar dhe e provon atë.
Ju ruani një lidhje drejt 10.20.4.15, VPN bie dhe klienti vazhdon të lidhet. Kjo nuk është lajm i mirë. Një adresë private është një vend brenda çdo konteksti rrugëtimi ku ndodheni, dhe shumë rrjete përdorin të njëjtat intervale. Klienti arriti një server MySQL, thjesht ndoshta jo tuajin.
Rregullimi ka dy gjysma, dhe vetëm njëra prej tyre ka të bëjë me rrjetin. Mbani lidhjen në rrugën e saj të synuar dhe bëni klientin të vërtetojë serverin me të cilin flet. Gjysma e parë është ajo ku VPN ndihmon; gjysma e dytë duhet konfiguruar.
Kriptuar drejt çfarë, saktësisht?
TLS mbron bisedën nga kushdo në mes dhe nuk thotë asgjë për atë se kush pretendon se është pika e fundit, përveç nëse klienti e kontrollon. Një certifikatë që vërtetohet ndaj një autoriteti të besuar provon se certifikata erdhi nga ai autoritet. Nuk provon se certifikata u lëshua për emrin e hostit që donit të arrinit, dhe këto janë pyetje të ndryshme.
Kjo nuk është një boshllëk teorik. Portalet captive, gabimet me VRF të gabuar dhe planet e adresave që mbivendosen të gjitha prodhojnë një server plotësisht të gatshëm të negociojë TLS me ju. Nëse klienti kërkon vetëm kriptim, sesioni është privat dhe i drejtuar drejt bazës së të dhënave të gabuar.
Pra pyetja përkatëse nuk është nëse lidhja është e kriptuar, por nëse është e kriptuar drejt identitetit që kishit synuar. Në klientin MySQL, ai dallim jeton plotësisht në cilësimin ssl-mode.
Pesë vlerat ssl-mode në praktikë
Ekzistojnë pesë vlera, dhe vetëm njëra prej tyre i përgjigjet pyetjes së këtij udhëzuesi. Tabela rendit çfarë garanton në të vërtetë secila, e jo çfarë sugjeron emri i saj.
| Mode | What it guarantees |
|---|---|
DISABLED | No TLS at all; everything on the wire is readable |
PREFERRED | Tries TLS and falls back to plaintext when the account and server allow it, so it is not a fail-closed requirement |
REQUIRED | Refuses to connect without TLS, and does not validate the certificate |
VERIFY_CA | Validates the server certificate against the configured CA and does not check the hostname |
VERIFY_IDENTITY | Validates the CA and checks that the certificate names the host the client used |
Vetëm rreshti i fundit i përgjigjet pyetjes në këtë artikull. PREFERRED meriton të theksohet më vete, sepse një klient që bie në heshtje në tekst të thjeshtë është më i keq se ai që refuzon: ju besoni se keni kriptim dhe kapja e paketave nuk pajtohet.
Një lidhje që mund ta ekzekutoni sot
Komanda më poshtë është forma për t'u përdorur, me dy vendmbajtëse: emri i bazës së të dhënave i miratuar dhe një skedar CA i marrë përmes një kanali të miratuar. Asnjëri prej tyre nuk duhet të merret nga ajo që serveri ju ofron në kontaktin e parë.
mysql --host=db.corp.example --user=app_reader \
--ssl-mode=VERIFY_IDENTITY \
--ssl-ca=/approved/path/ca.pem --password--password pa vlerë kërkon input, gjë që e mban sekretin jashtë listës së proceseve dhe jashtë historikut të shell-it tuaj. Është një zakon i vogël me përfitim të madh në hostet e kërcimit të përbashkëta, ku linja e komandës është e dukshme për përdoruesit e tjerë.
Kur kjo dështon, teksti i gabimit i dallon rastet më mirë se intuita. Një dështim CA do të thotë që zinxhiri nuk vërtetohet dhe duhet të shikoni cila CA nënshkroi certifikatën e serverit. Një dështim i emrit të hostit do të thotë që zinxhiri është në rregull dhe emri nuk përputhet, që zakonisht do të thotë se jeni lidhur me serverin e duhur nën emrin e gabuar, e jo me serverin e gabuar.
Shfaqja e një prompti nuk është provë se një fjalëkalim është transmetuar tashmë, dhe një lidhje e dështuar nuk provon se asgjë nuk doli nga klienti. Nëse rindërtoni një ngjarje të kaluar, identifikoni klientin, konfigurimin e tij, shtojcën e vërtetimit dhe fazën që dështoi. Vlerësimi i ekspozimit nga mesazhi i fundit i gabimit është hamendje.
Kur emri vjen nga një tunel
Përcjellja e portit lokal e thyen kontrollin e identitetit në një mënyrë që i befason njerëzit. Nëse përcillni një port lokal drejt bazës së të dhënave dhe lidheni me localhost, klienti vërteton certifikatën ndaj localhost, dhe për atë emër nuk u lëshua asnjë certifikatë. Lidhja mund të jetë plotësisht e sigurt dhe verifikimi do të dështojë gjithsesi, që është kontrolli që funksionon siç është menduar.
Ka dy përgjigje të ndershme. Jepini pikës së fundit të përcjellë një emër që zgjidhet drejt adresës loopback dhe shfaqet në certifikatën e serverit, ose përdorni emrin e hostit nga fillimi në fund që klienti të verifikojë identitetin e vërtetë. I pari është i përshtatshëm për zhvilluesit dhe kërkon punë me certifikata; i dyti është më i lehtë për t'u menduar dhe shpesh vlera e parazgjedhur e duhur për automatizim. Çaktivizimi i verifikimit që përcjellja të funksionojë hedh poshtë vetinë që po përpiqeshit të shtonit.
Pranimi është tre kushte
Shkruani testin e pranimit si tre deklarata të veçanta: lidhja përdori rrugën e synuar, kriptimi u kërkua dhe nuk u preferua, dhe identiteti i serverit u verifikua ndaj materialit të besuar. Një ikonë e gjelbër VPN nuk vendos asnjërën prej tyre.
Për klientët GUI dhe për MariaDB, konsultoni dokumentacionin e vetë furnizuesit në vend që të supozoni se drejtshkrimi i flamurit transferohet. Dokumentacioni i MySQL për lidhjet e kriptuara mbulon dallimet midis mënyrave dhe kërkesën për shpërndarjen e CA, dhe është referenca që duhet konsultuar përpara se të ndryshoni një varg lidhjeje prodhimi.