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, і це довідка, яку треба перевірити перед зміною виробничого рядка з'єднання.