Jak sprawdzić, czy replikacja mysql odbywa się za pośrednictwem protokołu SSL


4

Mamy replikację serwera SQL. Próbuję upewnić się, że replikacja odbywa się za pośrednictwem bezpiecznych kanałów. Biorąc pod uwagę, że MASTER_SSL_Allowedto prawda („Tak”), czy to sugeruje, że rzeczy podróżują przez SSL / TLS?

Jak mogę się upewnić, że połączenie replikacji jest szyfrowane? Jak mogę skutecznie zabronić nieszyfrowanego ruchu między urządzeniem głównym a replikacją?

mysql> show slave status\G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 192.168.10.100 Master_User: slave_user Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000192 Read_Master_Log_Pos: 37748817 Relay_Log_File: mysqld-relay-bin.000032 Relay_Log_Pos: 1244 Relay_Master_Log_File: mysql-bin.000092 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: omega Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 37748817 Relay_Log_Space: 124980 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: Yes Master_SSL_CA_File: /etc/mysql/certs/omega-ca-cert.pem Master_SSL_CA_Path: Master_SSL_Cert: /etc/mysql/certs/omega-client-cert.pem Master_SSL_Cipher: Master_SSL_Key: /etc/mysql/certs/omega-client-key.pem

Odpowiedzi:


2

Możesz zrobić dwie rzeczy

SUGESTIA # 1: Sprawdź Mistrza

Upewnij się, że MySQL został uruchomiony na Master z takimi liniami w my.cnf

[mysqld]
ssl-ca=cacert.pem
ssl-cert=server-cert.pem
ssl-key=server-key.pem

Zaloguj się do Master i uruchom

SHOW GLOBAL VARIABLES LIKE '%ssl%';

Powinieneś zobaczyć coś takiego:

+---------------+----------+
| Variable_name | Value    |
+---------------+----------+
| have_openssl  | DISABLED |
| have_ssl      | DISABLED |
| ssl_ca        | ...      |
| ssl_capath    | ...      |
| ssl_cert      | ...      |
| ssl_cipher    | ...      |
| ssl_key       | ...      |
+---------------+----------+

Jeśli have_open_ssl i have_ssl są wyłączone, to mysqld na Master nie używa SSL.

Proszę zapoznać się z dokumentacji MySQL na ssl_ca , ssl_capath , ssl_cert , ssl_cipher i ssl_key w jaki sposób z nich korzystać. Oczywiście, jeśli żaden z nich nie jest ustawiony, nawet jeśli włączone są opcje have_open_ssl i have_ssl , to mysqld na Master nie używa SSL.

SUGGESTION # 2: Sprawdź granty MySQL na Master

Samo połączenie powinno korzystać z opcji SSL. W SHOW SLAVE STATUS\Gwyniku widzę, że masz użytkownika o nazwie slave_user. Na Master, uruchom to:

SELECT CONCAT('SHOW GRANTS FOR ',QUOTE(user),'@',QUOTE(host),';')
INTO @slaveusergrants FROM mysql.user WHERE user='slave_user';
PREPARE s FROM @slaveusergrants; EXECUTE s; DEALLOCATE PREPARE s;

W wyniku tego powinien zostać wyświetlony jeden lub więcej następujących elementów:

REQUIRE SSL
REQUIRE SUBJECT
REQUIRE X509
REQUIRE ISSUER
REQUIRE CIPHER

Jeśli użytkownik slave na Master ma co najmniej jedną z tych rzeczy zdefiniowanych w grancie, polecenie CHANGE MASTER TO uruchamiane na Slave musi odpowiadać ustawieniom SSL na Master.

Aby uzyskać więcej wyjaśnień, przeczytaj Konfigurowanie replikacji przy użyciu protokołu SSL z dokumentacji MySQL

SUGESTIA # 3: Sprawdź połączenie na żywo

Powinieneś użyć tcpdump i sprawdzić port 3306 . Jeśli widzisz rzeczy w postaci zwykłego tekstu, protokół SSL nie działa dla Ciebie. Jeśli tego nie zrobisz, nie oznacza to również, że jest zaszyfrowany. Czemu ? Zgodnie z wytycznymi dotyczącymi bezpieczeństwa w dokumentacji MySQL (patrz dół strony) :

Nie przesyłaj zwykłych (niezaszyfrowanych) danych przez Internet. Informacje te są dostępne dla każdego, kto ma czas i możliwość ich przechwycenia i wykorzystania do własnych celów. Zamiast tego użyj szyfrowanego protokołu, takiego jak SSL lub SSH. MySQL obsługuje wewnętrzne połączenia SSL. Inną techniką jest wykorzystanie przekierowania portów SSH do utworzenia zaszyfrowanego (i skompresowanego) tunelu do komunikacji.

Naucz się korzystać z narzędzi tcpdump i ciągów. W większości przypadków można sprawdzić, czy strumienie danych MySQL nie są szyfrowane, wydając polecenie takie jak poniżej:

shell> tcpdump -l -i eth0 -w - src lub dst port 3306 | ciągi Działa to pod Linuksem i powinno działać z małymi modyfikacjami w innych systemach.

Ostrzeżenie Jeśli nie widzisz danych w postaci czystego tekstu, nie zawsze oznacza to, że informacje są faktycznie zaszyfrowane. Jeśli potrzebujesz wysokiego bezpieczeństwa, skonsultuj się z ekspertem ds. Bezpieczeństwa.


1
+1 do sugeruje wykorzystania tcpdump, Wiresharklub inny analizator pakietów w sieci. To najlepszy sposób, aby wymyślić, że replikacja odbywa się za pomocą TLS zamiast czystego tekstu. Technika „sprawdzania wzorca” tutaj nie jest pomocna, ponieważ pokazuje tylko, czy wzorzec może obsługiwać TLS, a nie czy faktycznie jest używany. Podobnie możesz chcieć upewnić się, że TLS faktycznie działa, zanim zmodyfikujesz GRANTs, aby użytkownik wymagał TLS.
Christopher Schultz
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.