MySQL праз VPN: правярайце сервер, а не толькі шыфраванне
Шыфраванне да няправільнага хоста ўсё роўна няправільнае. Параўнайце значэнні ssl-mode, затым выканайце злучэнне, якое называе патрэбны сервер і даказвае гэта.
Вы захоўваеце злучэнне з 10.20.4.15, VPN адвальваецца, а кліент усё роўна падключаецца. Гэта не добрая навіна. Прыватны адрас — гэта месца ў любым кантэксце маршрутызацыі, у якім вы апынуліся, і шматлікія сеткі выкарыстоўваюць адныя і тыя ж дыяпазоны. Кліент дасягнуў сервера MySQL, проста, магчыма, не вашага.
Выпраўленне мае дзве паловы, і толькі адна з іх пра сетку. Трымайце злучэнне на патрэбным шляху і прымусьце кліент правяраць сервер, з якім ён размаўляе. Першая палова — там, дзе дапамагае VPN; другая палова патрабуе налады.
Шыфраванне да чаго менавіта?
TLS абараняе размову ад любога пасярэдніка і нічога не кажа пра тое, кім сябе абвяшчае канцавы пункт, калі кліент не правярае. Сертыфікат, які праходзіць праверку ў даверанай установы, даказвае, што сертыфікат выдадзены гэтай установай. Ён не даказвае, што сертыфікат выдадзены на імя хоста, да якога вы хацелі дасягнуць, і гэта розныя пытанні.
Гэта не тэарэтычная прага. Захопныя парталы, памылкі з няправільным VRF і перакрыжаваныя схемы адрасаў — усё гэта стварае сервер, які цалкам гатовы ўзгадніць з вамі TLS. Калі кліент патрабуе толькі шыфраванне, сеанс прыватны і накіраваны на не тую базу даных.
Такім чынам, пытанне не ў тым, ці злучэнне шыфраванае, а ў тым, ці шыфраванае яно да той асобы, якую вы мелі на ўвазе. У кліенце MySQL гэта розніца цалкам змяшчаецца ў параметры ssl-mode.
Пяць значэнняў ssl-mode на практыцы
Існуе пяць значэнняў, і толькі адно з іх адказвае на пытанне гэтага кіраўніцтва. Табліца пералічвае, што кожнае з іх насамрэч гарантуе, а не тое, што мяркуе яго назва.
| 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 |
Толькі апошні радок адказвае на пытанне гэтага артыкула. PREFERRED варта асобна адзначыць, бо кліент, які моўчкі пераходзіць на адкрыты тэкст, горшы за той, што адмаўляецца: вы верыце, што ў вас шыфраванне, а запіс пакетаў кажа іншае.
Злучэнне, якое можна выканаць сёння
Каманда ніжэй — гэта форма, якую трэба выкарыстоўваць, з двума запаўняльнікамі: зацверджаная назва базы даных і файл CA, атрыманы праз зацверджаны канал. Ні адно з іх нельга браць з таго, што сервер прапануе пры першым кантакце.
mysql --host=db.corp.example --user=app_reader \
--ssl-mode=VERIFY_IDENTITY \
--ssl-ca=/approved/path/ca.pem --password--password без значэння запытвае ўвод, што трымае сакрэт па-за спісам працэсаў і па-за гісторыяй абалонкі. Гэта дробная звычка з вялікай аддачай на агульных прамежкавых хостах, дзе камандны радок бачны іншым карыстальнікам.
Калі гэта не ўдаецца, тэкст памылкі адрознівае выпадкі лепш, чым інтуіцыя. Памылка CA азначае, што ланцуг не правяраецца, і трэба глядзець, які CA падпісаў сертыфікат сервера. Памылка імя хоста азначае, што ланцуг у парадку, а імя не супадае, — гэта звычайна значыць, што вы падключыліся да правільнага сервера пад няправільным імем, а не да няправільнага сервера.
З'яўленне запыту не з'яўляецца доказам, што пароль ужо перададзены, а няўдалае злучэнне не даказвае, што нічога не пакінула кліент. Калі вы аднаўляеце мінулае здарэнне, вызначце кліент, яго налады, плагін аўтэнтыфікацыі і этап, які не ўдаўся. Ацэнка ўздзеяння па канчатковым паведамленні пра памылку — гэта здагадка.
Калі імя прыходзіць з тунеля
Перанакіраванне лакальнага порта ламае праверку асобы так, што здзіўляе людзей. Калі вы перанакіроўваеце лакальны порт на базу даных і падключаецеся да localhost, кліент правярае сертыфікат супраць localhost, а сертыфікат на такое імя не выдаваўся. Злучэнне можа быць цалкам бяспечным, і праверка ўсё роўна не пройдзе — гэта праверка працуе як задумана.
Ёсць два сумленныя адказы. Дайце перанакіраванаму пункту імя, якое развязаецца ў адрас зваротнай сувязі і прысутнічае ў сертыфікаце сервера, або выкарыстоўвайце імя хоста ад пачатку да канца, каб кліент правяраў сапраўдную асобу. Першае зручна для распрацоўнікаў і патрабуе працы з сертыфікатамі; другое прасцей абдумаць і часта слушная прадвызначанасць для аўтаматызацыі. Адключэнне праверкі, каб перанакіраванне працавала, адкідае ўласцівасць, якую вы спрабавалі дадаць.
Прыёмка — гэта тры ўмовы
Запішыце прыёмачны тэст як тры асобныя сцверджанні: злучэнне выкарыстала патрэбны маршрут, шыфраванне патрабавалася, а не было пажаданым, і асоба сервера была праверана супраць давераных матэрыялаў. Зялёная іконка VPN не ўсталёўвае ніводнай з іх.
Для GUI-кліентаў і для MariaDB правярайце ўласную дакументацыю пастаўшчыка, а не мяркуйце, што напісанне сцяга пераносіцца. Дакументацыя MySQL пра шыфраваныя злучэнні ахоплівае адрозненні рэжымаў і патрабаванне распаўсюджвання CA, і гэта даведка, якую трэба праверыць перад зменаю прамысловага радка злучэння.