Szyfrowanie transmisji danych w Bacula
22 luty 2015, autor: Marcin Haba (gani)
Funkcjonalność szyfrowania w Bacula można rozpatrywać co najmniej w dwóch aspektach: szyfrowania transmisji danych pomiędzy poszczególnymi serwisami Bacula oraz szyfrowania składowanych na wolumenach danych backupu. W tym artykule spróbuję przedstawić pierwszy aspekt czyli szyfrowanie transmisji danych.
W pierwszej części niniejszego opisu chciałbym przedstawić etap przygotowania kluczy prywatnych i certyfikatów TLS do późniejszego użycia ich w konfiguracji Bacula.
Istnieje wiele narzędzi służących do generowania certyfikatów TLS, czy to narzędzia graficzne (GUI) czy narzędzia tekstowej konsoli systemu operacyjnego, mniej lub bardziej przyjazne dla użytkownika. W tym artykule, do przygotowania kluczy prywatnych i certyfikatów opiszę sposób z użyciem narzędzia openssl pochodzącego z projektu o tej samej nazwie.
I) Środowisko do generowania certyfikatów
Do przygotowania kluczy prywatnych i certyfikatów można posłużyć się dowolnym systemem operacyjnym, na którym będzie działać program openssl. Zanim jednak wygeneruję klucze prywatne i certyfikaty, najpierw stworzę mini-środowisko, w obrębie którego odbywać się będzie proces generowania. A środowisko te to nic innego, jak odpowiednia struktura katalogów oraz kilka plików tekstowych, w tym ten najważniejszy, czyli plik konfiguracyjny programu openssl.
UWAGA!
Przed przystąpieniem do eksperymentów z certyfikatami, warto upewnić się czy używana instalacja Bacula jest skompilowana z obsługą openssl. W pakietach dystrybucji GNU/Linux zazwyczaj programy Bacula są skompilowane z obsługą openssl. Warto jednak to sprawdzić, szczególnie gdy dokonuje się własnej kompilacji programów Bacula. W tym celu potrzeba użyć przełączników:
./configure --enable-openssl --with-openssl ... itd.
Krok 1
W opisywanym przykładzie tworzę katalog, w obrębie którego znajdować będzie się wyżej wspomniana struktura plików i katalogów dla programu openssl:
mkdir -m 700 /home/gani/ssl
Przy tworzeniu powyższego katalogu nadałem mu uprawienia odczytu, zapisu i wykonania tylko dla właściciela katalogu.
Krok 2
Przechodzę do nowo stworzonego katalogu
cd /home/gani/ssl
Krok 3
Tworzę nowy plik tekstowy openssl.cnf w bieżącym katalogu (/home/gani/ssl/openssl.cnf) i wpisuję do niego poniższą zawartość/szablon:
HOME = XXX_SSL_DIR_XXX
RANDFILE = $ENV::HOME/.rnd
####################################################################
[ ca ]
default_ca = CA_default # The default ca section
####################################################################
[ CA_default ]
dir = XXX_SSL_DIR_XXX # Where everything is kept
certs = $dir/certs # Where the issued certs are kept
crl_dir = $dir/crl # Where the issued crl are kept
database = $dir/index.txt # database index file.
unique_subject = no # Set to 'no' to allow creation of
# several ctificates with same subject.
new_certs_dir = $dir/certs # default place for new certs.
certificate = $dir/certs/XXX_ROOT_CA_XXX # The CA certificate
serial = $dir/serial # The current serial number
crlnumber = $dir/crlnumber # the current crl number
# must be commented out to leave a V1 CRL
x509_extensions = usr_cert # The extentions to add to the cert
name_opt = ca_default # Subject Name options
cert_opt = ca_default # Certificate field options
default_days = 36500 # how long to certify for (default: 100 years)
default_crl_days= 30 # how long before next CRL
default_md = sha256 # use public key default MD
preserve = no # keep passed DN ordering
policy = policy_match
# For the CA policy
[ policy_match ]
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
# For the 'anything' policy
[ policy_anything ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
####################################################################
[ req ]
default_bits = 4096
default_keyfile = XXX_ROOT_CA_XXX
distinguished_name = req_distinguished_name
attributes = req_attributes
x509_extensions = v3_ca # The extentions to add to the self signed cert
string_mask = utf8only
[ req_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default = XXX_COUNTRY_NAME_XXX
countryName_min = 2
countryName_max = 2
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = XXX_STATE_OR_PROVINCE_NAME_XXX
localityName = Locality Name (eg, city)
localityName_default = XXX_LOCALITY_NAME_XXX
0.organizationName = Organization Name (eg, company)
0.organizationName_default = XXX_ORGANIZATION_NAME_XXX
commonName = Common Name (e.g. server FQDN or YOUR name)
commonName_max = 64
commonName_default = XXX_COMMON_NAME_XXX
emailAddress = Email Address
emailAddress_max = 64
emailAddress_default = XXX_EMAIL_ADDRESS_XXX
[ req_attributes ]
challengePassword = A challenge password
challengePassword_min = 4
challengePassword_max = 20
unstructuredName = An optional company name
[ v3_ca ]
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer
basicConstraints = CA:TRUE
[ usr_cert ]
basicConstraints=CA:FALSE
nsComment = "OpenSSL Generated Certificate"
# PKIX recommendations harmless if included in all certificates.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
Po zapisaniu pliku, następnym krokiem jest jego edycja i dostosowanie do własnych potrzeb i parametrów. Jak zapewne zauważyłeś, drogi czytelniku, niektóre z wartości w pliku konfiguracyjnym openssl.cnf oznaczone są znakami XXX na początku i na końcu ciągu znaków. To właśnie te pola potrzeba zamienić na właściwe dla Twojego środowiska dane. Część tych pól to po prostu domyślne wartości, jakie są przyjmowane (dziedziczone) z pliku openssl.cnf w drodze do generowania certyfikatów.
W tym przykładzie założyłem następujące wartości:
- Katalog domowy środowiska openssl: /home/gani/ssl
- Katalog gdzie będą trafiać certyfikaty: /home/gani/ssl/certs/
- Katalog gdzie będą trafiać klucze prywatne: /home/gani/ssl/keys/
- Nazwa pliku certyfikatu Root CA: root_cert.pem
- Nazwa pliku klucza prywatnego dla Root CA: root_key.pem
- Domyślny kraj dla certyfikatów: PL
- Domyślne województwo: slaskie
- Domyślne miasto: Bytom
- Domyślna nazwa firmy: Bacula.pl
- Domyślny FQDN/nazwa hosta: baculahost.lan
- Domyślny adres e-mail: gani@baculahost.lan
Wszystkie te powyższe wartości uwzględniłem podczas edycji pliku openssl.cnf poprzez wstawienie odpowiednich wartości w miejsce odpowiednich pól oznaczonych w szablonie pliku konfiguracyjnego znakami XXX na początku i na końcu ciągu znaków. Teraz, mój plik konfiguracyjny wygląda następująco:
HOME = /home/gani/ssl
RANDFILE = $ENV::HOME/.rnd
####################################################################
[ ca ]
default_ca = CA_default # The default ca section
####################################################################
[ CA_default ]
dir = /home/gani/ssl # Where everything is kept
certs = $dir/certs # Where the issued certs are kept
crl_dir = $dir/crl # Where the issued crl are kept
database = $dir/index.txt # database index file.
unique_subject = no # Set to 'no' to allow creation of
# several ctificates with same subject.
new_certs_dir = $dir/certs # default place for new certs.
certificate = $dir/certs/root_cert.pem # The CA certificate
serial = $dir/serial # The current serial number
crlnumber = $dir/crlnumber # the current crl number
# must be commented out to leave a V1 CRL
x509_extensions = usr_cert # The extentions to add to the cert
name_opt = ca_default # Subject Name options
cert_opt = ca_default # Certificate field options
default_days = 36500 # how long to certify for (default: 100 years)
default_crl_days= 30 # how long before next CRL
default_md = sha256 # use public key default MD
preserve = no # keep passed DN ordering
policy = policy_match
# For the CA policy
[ policy_match ]
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
# For the 'anything' policy
[ policy_anything ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
####################################################################
[ req ]
default_bits = 4096
default_keyfile = root_cert.pem
distinguished_name = req_distinguished_name
attributes = req_attributes
x509_extensions = v3_ca # The extentions to add to the self signed cert
string_mask = utf8only
[ req_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default = PL
countryName_min = 2
countryName_max = 2
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = slaskie
localityName = Locality Name (eg, city)
localityName_default = Bytom
0.organizationName = Organization Name (eg, company)
0.organizationName_default = Bacula.pl
commonName = Common Name (e.g. server FQDN or YOUR name)
commonName_max = 64
commonName_default = baculahost.lan
emailAddress = Email Address
emailAddress_max = 64
emailAddress_default = gani@baculahost.lan
[ req_attributes ]
challengePassword = A challenge password
challengePassword_min = 4
challengePassword_max = 20
unstructuredName = An optional company name
[ v3_ca ]
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer
basicConstraints = CA:TRUE
[ usr_cert ]
basicConstraints=CA:FALSE
nsComment = "OpenSSL Generated Certificate"
# PKIX recommendations harmless if included in all certificates.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
Krok 4
Jako, że w pliku zdefiniowane są pliki i katalogi, które jeszcze nie istnieją, to teraz w bieżącej lokalizacji:
/home/gani/ssl
tworzę brakujące pliki i katalogi poprzez wydanie komend:
mkdir -m 700 keys
mkdir -m 700 certs
echo "01" > serial
echo -n "1 2 3 4 5 6" > index.txt
Krok 5
Generowanie certyfikatów TLS rozpoczyna się od wygenerowania głównego klucza prywatnego, przy pomocy którego wygenerowany zostanie certyfikat główny tzw. Root CA.
Do generowania głównego klucza prywatnego może posłużyć komendą:
openssl genrsa -out keys/root_key.pem 4096
Teraz w katalogu:
/home/gani/keys/
powinien znajdować się plik klucza prywatnego o nazwie:
root_key.pem
Krok 5
Przy użyciu nowo stworzonego klucza prywatnego, teraz pora wygenerować główny certyfikat Root CA o przyznanej ważności przez najbliższe 100 lat (parametr -days 36500):
openssl req -new -x509 -batch -config ./openssl.cnf -sha256 -key ./keys/root_key.pem -days 36500 -out ./certs/root_cert.pem
Aby sprawdzić, czy wszystkie potrzebne i podane w pliku konfiguracyjnym openssl.cnf dane zostały umieszczone w certyfikacie, można posłużyć się komendą:
openssl x509 -text -in certs/root_cert.pem
Po wydaniu komendy powinien pojawić się listing podobny do poniższego:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 15784850167946249050 (0xdb0f0d989533835a)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=PL, ST=slaskie, L=Bytom, O=Bacula.pl, CN=baculahost.lan/emailAddress=gani@baculahost.lan
Validity
Not Before: Feb 21 16:03:27 2015 GMT
Not After : Jan 28 16:03:27 2115 GMT
Subject: C=PL, ST=slaskie, L=Bytom, O=Bacula.pl, CN=baculahost.lan/emailAddress=gani@baculahost.lan
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (4096 bit)
Modulus:
00:bb:18:65:b0:db:12:23:8e:0f:52:f9:3a:96:ec:
97:39:0a:d0:a4:76:e6:69:c4:c8:cc:a4:2f:78:23:
2b:a0:1f:cc:ee:9e:4c:79:30:86:de:bb:72:a3:7b:
03:40:c6:9f:fe:0b:de:61:2c:d3:84:e8:02:3d:a1:
1b:ef:8e:61:4d:7c:c0:c3:18:1c:bc:47:58:cf:e5:
39:d5:98:63:43:bb:35:f4:c0:d9:97:40:f6:db:37:
09:a9:c0:dd:41:01:70:a2:9b:cf:9b:0e:92:7b:32:
ac:6a:41:fb:a9:df:db:83:11:c1:1a:49:45:e1:d8:
85:3a:58:63:c7:42:17:8a:53:c7:05:9b:4e:2c:d9:
67:bf:bd:cd:6d:57:6b:0e:f4:1f:23:5e:d7:2a:db:
d4:1d:2f:67:b0:7b:5d:b2:2e:7a:e3:01:88:7e:7e:
d8:d1:51:00:84:24:c9:a2:a3:49:e5:98:5d:18:3c:
6f:ae:e8:fb:c7:1c:50:3a:64:44:39:a8:46:7f:4e:
37:f6:c1:1e:ab:81:d5:3e:fb:c0:ae:90:71:ea:58:
00:0c:cc:8c:e8:c4:91:62:c6:74:e9:c9:b4:df:90:
81:0a:a7:d3:33:56:be:1d:bc:08:40:55:b7:16:cb:
ba:92:35:a6:ff:e9:02:b1:e8:2c:9e:7c:6c:9e:bd:
6e:9c:49:15:ad:dc:21:57:f4:d1:0b:c8:a8:dc:8b:
34:f6:f3:07:58:ba:3b:30:01:b4:a8:aa:67:9e:3f:
73:a2:b1:c6:bc:da:4e:13:c0:2d:b8:5c:fc:56:e7:
2c:a1:68:f4:6b:8b:c7:28:56:be:15:55:65:98:c5:
8e:a9:c6:0e:72:ff:27:a5:ed:70:da:f9:e7:b2:e3:
94:24:6a:03:06:2a:28:49:b3:f2:04:ba:97:44:e6:
e8:2e:fe:8e:76:a3:7c:a4:93:9a:86:8c:bc:3d:df:
57:3b:ad:6d:05:c6:1c:1a:3f:b9:92:8c:50:b2:81:
c8:c1:f3:16:27:ab:ef:e5:ce:93:2e:1d:62:48:32:
cf:e5:a5:5e:14:69:93:c9:7e:d2:2e:5b:af:50:8e:
ad:da:ec:a9:c1:0b:05:83:bc:ea:0c:61:27:8d:7e:
d5:e4:19:15:39:5d:38:3e:36:0b:f6:15:68:33:df:
3a:6d:19:9f:52:83:a3:86:77:f2:4f:8e:53:27:8f:
17:25:00:0b:c1:49:b8:8a:2c:80:80:a0:35:5a:c7:
90:a3:81:8f:69:83:5c:5e:de:f6:08:59:1a:fe:83:
74:e5:3c:8d:4c:93:e8:c9:13:e5:9a:da:4d:bd:32:
ac:f8:90:f1:d9:55:8b:89:47:be:c4:c1:e5:df:6d:
ed:b2:e9
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
C2:1B:ED:5E:B4:E4:CF:10:9B:B2:BC:7D:BF:BE:12:0E:0C:0D:B9:23
X509v3 Authority Key Identifier:
keyid:C2:1B:ED:5E:B4:E4:CF:10:9B:B2:BC:7D:BF:BE:12:0E:0C:0D:B9:23
X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: sha1WithRSAEncryption
9c:9b:0a:80:9d:1a:e8:aa:17:f7:3e:a4:61:ab:5e:f9:55:1a:
1e:ac:16:e8:67:90:93:de:54:e3:cc:59:5c:00:cb:23:64:50:
97:5c:36:dd:df:ce:c3:f1:fb:cc:78:63:c8:28:07:3b:c6:25:
a8:cc:2f:d0:b9:01:f7:9e:0a:ab:a7:35:84:be:58:3c:db:87:
3d:43:c3:09:a3:4a:f8:6b:c2:a9:22:99:c7:1a:01:ea:45:f7:
b5:3f:12:8a:00:76:9b:48:50:2c:fb:34:82:1e:e7:85:70:9e:
06:fe:a0:93:10:6b:ec:25:57:ab:1e:0e:c7:87:2c:23:26:44:
5f:ed:09:01:47:0e:4b:0a:a3:b8:16:cb:62:48:c7:4c:93:b6:
c9:00:fc:7b:d9:4d:01:2f:b5:76:69:c5:cb:22:1b:d1:81:b5:
aa:c0:04:f4:b6:08:1e:d8:06:e9:d9:0f:71:f1:3d:43:b2:7b:
ea:b8:f2:31:8b:c7:41:77:38:e4:89:cb:de:07:21:e3:ba:3a:
fc:f6:33:1c:d7:ef:e2:aa:4d:3b:fe:46:0e:76:47:4d:78:ac:
f9:e0:28:24:bb:1c:8f:6b:30:70:02:cf:87:2a:19:6f:bb:1c:
51:76:f7:27:30:13:f8:d4:e6:18:5c:90:a1:e5:eb:23:57:0d:
80:22:24:14:45:cd:6e:40:c7:dd:30:45:a1:41:48:2e:56:fd:
ad:29:fa:a5:3e:90:aa:a3:56:52:ee:4b:39:b0:d9:ec:b1:28:
57:63:da:36:a2:0e:88:51:b4:dd:8a:f6:25:6e:4f:53:cc:47:
2b:ce:b7:14:ff:ef:89:4b:90:05:b8:4b:c2:f6:8f:0d:0a:cc:
3b:f0:a7:e4:6a:c6:b6:2b:43:47:6e:cf:c8:f8:85:d8:db:62:
64:4e:75:44:89:0b:04:ad:d1:15:db:e4:fb:c8:05:f2:10:9c:
e7:ea:09:8b:f8:68:99:43:c7:d7:79:32:ff:3a:f5:cc:59:7b:
eb:30:42:53:93:88:19:75:15:e9:ab:83:43:c8:20:ea:f7:a0:
07:57:ab:d1:3d:69:62:4b:8f:5b:24:85:21:13:d6:c2:51:be:
2e:f8:2c:d5:ee:2b:4e:30:a7:a9:81:79:f8:a4:04:f9:86:42:
51:4b:71:f1:11:4d:c0:e0:59:ad:01:1a:1b:1a:8e:34:7f:30:
1e:8c:f9:d5:39:70:c1:fc:70:d0:9e:54:e7:55:78:a0:c7:9d:
a4:b5:7a:c5:85:a9:20:97:9f:a1:cf:2d:95:e1:fd:81:a5:b6:
0f:3c:b8:04:cf:77:8a:56:e1:35:f6:20:32:42:67:ae:11:ac:
2d:9a:7d:9c:38:82:46:a5
...
...
...
Krok 6
Gdy już istnieje wygenerowany główny klucz prywatny i certyfikat Root CA, można teraz wygenerować certyfikaty niższego poziomu względem Root CA. Będą to certyfikaty dla poszczególnych serwisów Bacula (Storage Daemon, File Daemon, Director), dla których jest potrzeba użycia szyfrowanej transmisji danych. Każdy taki certyfikat niższego poziomu będzie posiadał swój własny klucz prywatny.
Generuję trzy klucze prywatne dla Director'a, Storage Daemon'a i Klienta poprzez wydanie komend:
openssl genrsa -out ./keys/ganiwork.lan-dir_key.pem 4096
openssl genrsa -out ./keys/ganiwork.lan-sd_key.pem 4096
openssl genrsa -out ./keys/ganihome-fd_key.pem 4096
Krok 7
Aby wygenerować certyfikaty niższego poziomu przy użyciu przygotowanych w Kroku 6 kluczy prywatnych, potrzeba najpierw stworzyć odpowiednie pliki .csr (skrót od Certificate Signing Request) czyli tzw. pliki żądania podpisania certyfikatu. Pliki te można przygotować poprzez wydanie komend:
openssl req -new -config ./openssl.cnf -sha256 -batch -subj /C=PL/ST=Bytom/O=Bacula.pl/CN=ganiwork.lan -key ./keys/ganiwork.lan-dir_key.pem -out ./certs/ganiwork.lan-dir_cert.csr
openssl req -new -config ./openssl.cnf -sha256 -batch -subj /C=PL/ST=Bytom/O=Bacula.pl/CN=ganiwork.lan -key ./keys/ganiwork.lan-sd_key.pem -out ./certs/ganiwork.lan-sd_cert.csr
openssl req -new -config ./openssl.cnf -sha256 -batch -subj /C=PL/ST=Bytom/O=Bacula.pl/CN=ganihome -key ./keys/ganihome-fd_key.pem -out ./certs/ganihome-fd_cert.csr
Proszę zwrócić szczególną uwagę na wartość podaną w przełączniku -subj, czyli:
- dla pliku żądania certyfikatu Director'a i Storage Deamon'a:
/C=PL/ST=Bytom/O=Bacula.pl/CN=ganiwork.lan
- dla pliku żądania certyfikatu Klienta:
/C=PL/ST=Bytom/O=Bacula.pl/CN=ganihome
Jako wartość parametru CN (ang. skrót od Common Name) potrzeba podać FQDN, nazwę hosta czy ewentualnie adres IP komputera, pod którym dany serwis (Director, Storage Daemon i Klient) jest zainstalowany i działający (włączając interfejs sieciowy, na którym dany serwis nasłuchuje).
Dla mojej instalacji Bacula są to:
- Director i Storage Daemon na hoście ganiwork.lan,
- Serwis Klienta na hoście ganihome.
I takie też wartości podaję w parametrze CN podczas generowania pliku żądania podpisania certyfikatu.
Krok 8
Podpisanie certyfikatu niższego poziomu, czyli w tym wypadku certyfikatów serwisów Directora, Storage Daemon'a oraz File Daemon'a odbywa się poprzez komendy:
- Dla mojego Director'a:
openssl ca -keyfile ./keys/root_key.pem -config ./openssl.cnf -batch -policy policy_anything -extensions usr_cert -enddate 202502211531Z -out certs/ganiwork.lan-dir_cert.pem -infiles ./certs/ganiwork.lan-dir_cert.csr
Jako wyjściowy listing powinno pojawić się podsumowanie podobne do poniższego:
Using configuration from ./openssl.cnf
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 1 (0x1)
Validity
Not Before: Feb 21 21:13:49 2015 GMT
Not After : Feb 21 15:31:00 2025 GMT
Subject:
countryName = PL
stateOrProvinceName = Bytom
organizationName = Bacula.pl
commonName = ganiwork.lan
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
CA:2E:4E:10:63:F4:5C:DA:BF:DC:26:2C:0F:B9:21:C4:9B:86:BE:8D
X509v3 Authority Key Identifier:
keyid:A5:70:04:00:72:3F:D2:A4:3C:B2:D3:38:4D:B7:2A:3C:8B:43:E6:3C
Certificate is to be certified until Feb 21 15:31:00 2025 GMT (36500 days)
Write out database with 1 new entries
Data Base Updated
- Dla mojego Storage Daemon'a:
openssl ca -keyfile ./keys/root_key.pem -config ./openssl.cnf -batch -policy policy_anything -extensions usr_cert -enddate 202502211531Z -out certs/ganiwork.lan-sd_cert.pem -infiles ./certs/ganiwork.lan-sd_cert.csr
z listingiem na wyjściu:
Using configuration from ./openssl.cnf
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 2 (0x2)
Validity
Not Before: Feb 21 21:14:18 2015 GMT
Not After : Feb 21 15:31:00 2025 GMT
Subject:
countryName = PL
stateOrProvinceName = Bytom
organizationName = Bacula.pl
commonName = ganiwork.lan
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
C8:1D:5A:D9:2C:62:A2:D4:80:79:19:8C:AC:A8:6C:7F:D8:11:26:8A
X509v3 Authority Key Identifier:
keyid:A5:70:04:00:72:3F:D2:A4:3C:B2:D3:38:4D:B7:2A:3C:8B:43:E6:3C
Certificate is to be certified until Feb 21 15:31:00 2025 GMT (36500 days)
Write out database with 1 new entries
Data Base Updated
- Dla mojego serwisu Klienta:
openssl ca -keyfile ./keys/root_key.pem -config ./openssl.cnf -batch -policy policy_anything -extensions usr_cert -enddate 202502211531Z -out certs/ganihome-fd_cert.pem -infiles ./certs/ganihome-fd_cert.csr
również z listingiem wyjściowym podobnym do poniższego:
Using configuration from ./openssl.cnf
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 3 (0x3)
Validity
Not Before: Feb 21 21:14:51 2015 GMT
Not After : Feb 21 15:31:00 2025 GMT
Subject:
countryName = PL
stateOrProvinceName = Bytom
organizationName = Bacula.pl
commonName = ganihome
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
F1:17:B8:84:C6:80:A0:1A:E8:53:14:D4:82:E6:C0:0B:21:F9:63:D2
X509v3 Authority Key Identifier:
keyid:A5:70:04:00:72:3F:D2:A4:3C:B2:D3:38:4D:B7:2A:3C:8B:43:E6:3C
Certificate is to be certified until Feb 21 15:31:00 2025 GMT (36500 days)
Write out database with 1 new entries
Data Base Updated
We wszystkich trzech przypadkach generowania certyfikatów: dla Storage Daemon'a, Dirctor'a i Klienta użyłem daty wygaśnięcia certyfikatu na 21 luty 2025, czyli w chwili pisania tego artykułu jest to 10 lat do przodu.
W katalogu
/home/gani/ssl/
znajduje się teraz taka struktura plików i katalogów:
find /home/gani/ssl/ -print
/home/gani/ssl/
/home/gani/ssl/keys
/home/gani/ssl/keys/root_key.pem
/home/gani/ssl/keys/ganiwork.lan-sd_key.pem
/home/gani/ssl/keys/ganihome-fd_key.pem
/home/gani/ssl/keys/ganiwork.lan-dir_key.pem
/home/gani/ssl/index.txt.attr.old
/home/gani/ssl/index.txt.attr
/home/gani/ssl/openssl.cnf
/home/gani/ssl/index.txt.old
/home/gani/ssl/index.txt
/home/gani/ssl/serial
/home/gani/ssl/certs
/home/gani/ssl/certs/ganiwork.lan-dir_cert.pem
/home/gani/ssl/certs/ganiwork.lan-sd_cert.pem
/home/gani/ssl/certs/ganihome-fd_cert.csr
/home/gani/ssl/certs/03.pem
/home/gani/ssl/certs/02.pem
/home/gani/ssl/certs/ganiwork.lan-sd_cert.csr
/home/gani/ssl/certs/ganihome-fd_cert.pem
/home/gani/ssl/certs/root_cert.pem
/home/gani/ssl/certs/ganiwork.lan-dir_cert.csr
/home/gani/ssl/certs/01.pem
/home/gani/ssl/serial.old
Z czego najistotniejsze pliki dla Bacula to:
- certyfikat Root CA:
/home/gani/ssl/certs/root_cert.pem
- klucze prywatne dla Director'a, Storage Daemon'a i Klienta:
/home/gani/ssl/keys/ganiwork.lan-dir_key.pem
/home/gani/ssl/keys/ganiwork.lan-sd_key.pem
/home/gani/ssl/keys/ganihome-fd_key.pem
- podpisane certyfikaty niższego poziomu
/home/gani/ssl/certs/ganiwork.lan-dir_cert.pem
/home/gani/ssl/certs/ganiwork.lan-sd_cert.pem
/home/gani/ssl/certs/ganihome-fd_cert.pem
To wszystko odnośnie generowania i podpisywania certyfikatów dla Bacula. W drugiej części tego artykułu spróbuję przedstawić, jak użyć kluczy prywatnych i certyfikatów do szyfrowania transmisji w Bacula.
II) Szyfrowanie transmisji Director <=> File Daemon/Klient
Na komputerze z działającym serwisem Director'a (komputer o hoście ganiwork.lan) w przykładowym katalogu:
/etc/bacula/ssl/
potrzeba umieścić pliki certyfikatu i klucza prywatnego Klienta Bacula oraz certyfikatu Root CA:
- keys/ganihome-fd_key.pem
- certs/ganihome-fd_cert.pem
- certs/root_cert.pem
Struktura plików na hoście ganiwork.lan z serwisem Director'a (i Storage Daemon'a zarazem) w katalogu:
/etc/bacula/ssl/
wygląda teraz następująco:
find /etc/bacula/ssl/ -print
/etc/bacula/ssl/
/etc/bacula/ssl/ganihome-fd_cert.pem
/etc/bacula/ssl/root_cert.pem
/etc/bacula/ssl/ganihome-fd_key.pem
Odpowiednie kopiowanie plików kluczy i certyfikatów potrzeba wykonać na komputerze z serwisem Klienta (komputer o hoście ganihome). Struktura plików na hoście ganihome wygląda tak samo jak na hoście ganiwork.lan:
find /etc/bacula/ssl/ -print
/etc/bacula/ssl/
/etc/bacula/ssl/root_cert.pem
/etc/bacula/ssl/ganihome-fd_key.pem
/etc/bacula/ssl/ganihome-fd_cert.pem
Następnie potrzeba dokonać wpisów w plikach konfiguracyjnych Director'a i Klienta, aby uruchomić szyfrowaną transmisję pomiędzy Directorem a serwisem Klienta.
W tym celu do pliku konfiguracyjnego Klienta'a potrzeba dodać następujące dyrektywy do zasobu Director:
TLS Enable = yes
TLS Require = yes
TLS CA Certificate File = /etc/bacula/ssl/root_cert.pem
TLS Certificate = /etc/bacula/ssl/ganihome-fd_cert.pem
TLS Key = /etc/bacula/ssl/ganihome-fd_key.pem
Cały zasób Director w pliku konfiguracyjnym Klienta wygląda teraz tak:
Director {
Name = ganiwork.lan-dir
Password = "XXXXXXXXXXXXXX"
TLS Enable = yes
TLS Require = yes
TLS CA Certificate File = /etc/bacula/ssl/root_cert.pem
TLS Certificate = /etc/bacula/ssl/ganihome-fd_cert.pem
TLS Key = /etc/bacula/ssl/ganihome-fd_key.pem
}
Te same wpisy potrzeba dodać po stronie serwisu Director w zasobie Client:
TLS Enable = yes
TLS Require = yes
TLS CA Certificate File = /etc/bacula/ssl/root_cert.pem
TLS Certificate = /etc/bacula/ssl/ganihome-fd_cert.pem
TLS Key = /etc/bacula/ssl/ganihome-fd_key.pem
Cały zasób Client dla klienta ganihome-fd w konfiguracji Director'a wygląda u mnie następująco:
Client {
Name = ganihome-fd
Address = ganihome
FDPort = 9102
Catalog = MyCatalog
Password = "XXXXXXXXXXXXXX"
File Retention = 60 days
Job Retention = 6 months
AutoPrune = yes
TLS Enable = yes
TLS Require = yes
TLS CA Certificate File = /etc/bacula/ssl/root_cert.pem
TLS Certificate = /etc/bacula/ssl/ganihome-fd_cert.pem
TLS Key = /etc/bacula/ssl/ganihome-fd_key.pem
}
Po restarcie serwisu Klienta i po przeładowaniu konfiguracji (lub również restarcie) Director'a, komunikacja pomiędzy Directorem a Klientem jest już szyfrowana.
Można sprawdzić komunikację Director <=> Klient poprzez wydanie komendy w tekstowej konsoli Bconsole:
status client=ganihome-fd
Otrzymałem status od Klienta:
Connecting to Client ganihome-fd at ganihome:9102
ganihome-fd Version: 5.2.13 (19 February 2013) x86_64-redhat-linux-gnu unknown unknown
Daemon started 22-lut-15 08:51. Jobs: run=0 running=0.
Heap: heap=135,168 smbytes=21,667 max_bytes=21,814 bufs=54 max_bufs=55
Sizeof: boffset_t=8 size_t=8 debug=0 trace=0
Running Jobs:
Director connected at: 22-lut-15 09:00
No Jobs running.
====
Terminated Jobs:
====
Aby upewnić się, że komunikacja jest naprawdę szyfrowana, polecam użyć któregoś z programów do analizy ruchu sieciowego (tzw. sniffer). Dzięki takim narzędziom będzie można zobaczyć zawartość przesyłanych pakietów pomiędzy serwisami Bacula.
Zawartość przykładowego pakietu zaszyfrowanego, może wyglądać następująco (wynik powyższej komendy status client=ganihome-fd):
0000 52 54 00 38 ad 39 52 54 00 22 21 4c 08 00 45 00 RT.8.9RT."!L..E.
0010 04 de ad 29 40 00 40 06 73 f8 0a 00 00 01 0a 00 ...)@.@.s.......
0020 00 f8 a0 c6 23 8e 4a 72 0f f2 5a 4a 20 e6 80 18 ....#.Jr..ZJ ...
0030 01 28 19 c9 00 00 01 01 08 0a 05 25 ae bb 02 45 .(.........%...E
0040 86 cf b4 2f a4 7f 3d 1b d0 0d 6a cb d5 83 e3 c0 .../..=...j.....
0050 93 62 05 25 ab 88 40 ea 6b b0 0e 96 01 7b 51 47 .b.%..@.k....{QG
0060 77 9e dd f6 fa 8d 05 b8 78 43 06 d5 5c 88 6a 22 w.......xC..\.j"
0070 26 6e f1 bf af 0f 3b fd 42 08 c7 ee f8 1b e3 cb &n....;.B.......
0080 64 90 1c b9 c4 76 bb 3d 24 1a 49 a8 25 41 95 ba d....v.=$.I.%A..
0090 b1 a8 77 e8 d1 8b dd ac 6c 32 7b 16 03 01 02 06 ..w.....l2{.....
00a0 10 00 02 02 02 00 5a f6 a3 45 5e 1f b2 a0 9c 59 ......Z..E^....Y
00b0 ad 36 03 40 c1 75 e3 63 56 b2 b3 a5 0e 1c 54 e5 .6.@.u.cV.....T.
00c0 50 7c a6 f3 46 fb 88 82 40 de 2b b5 7d 41 20 87 P|..F...@.+.}A .
00d0 bd 0c b5 dc 25 57 4d e0 31 db 43 ac 40 46 06 31 ....%WM.1.C.@F.1
00e0 03 0d 9c 43 a3 28 1a f6 f6 c1 c8 41 2e 81 9b e1 ...C.(.....A....
00f0 88 d9 38 d1 21 40 2c e9 28 a5 32 87 2c ed d5 4d ..8.!@,.(.2.,..M
0100 73 cb de d4 78 09 cd 6e 77 71 26 b3 e1 53 c1 37 s...x..nwq&..S.7
0110 6f 8a e4 49 42 39 4c bd 83 67 7e 7d c7 d4 69 20 o..IB9L..g~}..i
0120 02 d2 15 91 bf 48 3b b9 73 f0 74 61 28 50 3f bd .....H;.s.ta(P?.
0130 22 6e 8a 0b 6b 3e ba 5e 00 0b d2 fe 79 53 76 8c "n..k>.^....ySv.
0140 1a 5a b8 2d 9f 02 c9 40 e3 54 57 85 24 2f c9 53 .Z.-...@.TW.$/.S
0150 be 29 af fc bd d3 05 ee 81 a0 71 f0 e6 26 ab 06 .)........q..&..
0160 12 fe c2 b9 33 c5 e8 4c e4 b6 a7 f3 9e 08 94 db ....3..L........
0170 c0 92 d8 19 02 7e 02 8c 4e 18 cf 49 3d 9f ca 8e .....~..N..I=...
0180 86 48 3f b8 09 88 b9 7e 39 5f f9 1a 2d e3 c5 85 .H?....~9_..-...
0190 34 c7 cc 62 af b9 3a 0a 15 85 a6 54 0d 03 e2 87 4..b..:....T....
01a0 03 4b 1e 2d 9d 0f a9 0c 30 54 de 43 3d f8 b8 62 .K.-....0T.C=..b
01b0 eb 4b 0d 63 5c d8 ad 72 8f 23 ab c1 b5 57 12 b3 .K.c\..r.#...W..
Niezaszyfrowane pakiety Bacula łatwo zlokalizować, gdyż w ich zawartości można zauważyć treści przesyłane pomiędzy serwisami Bacula jako czysty tekst (tzw. plain-text). Oto przykład zawartości pakietu dla tej samej komendy:
status client=ganihome-fd
lecz tym razem bez użycia szyfrowania:
0000 52 54 00 22 21 4c 52 54 00 38 ad 39 08 00 45 00 RT."!LRT.8.9..E.
0010 01 d2 4d d5 40 00 40 06 d6 58 0a 00 00 f8 0a 00 ..M.@.@..X......
0020 00 01 23 8e a0 e1 b7 0f 26 52 a5 2d d4 0d 80 18 ..#.....&R.-....
0030 00 72 d8 5c 00 00 01 01 08 0a 02 4f 68 70 05 2f .r.\.......Ohp./
0040 90 47 00 00 00 59 67 61 6e 69 68 6f 6d 65 2d 66 .G...Yganihome-f
0050 64 20 56 65 72 73 69 6f 6e 3a 20 35 2e 32 2e 31 d Version: 5.2.1
0060 33 20 28 31 39 20 46 65 62 72 75 61 72 79 20 32 3 (19 February 2
0070 30 31 33 29 20 20 78 38 36 5f 36 34 2d 72 65 64 013) x86_64-red
0080 68 61 74 2d 6c 69 6e 75 78 2d 67 6e 75 20 75 6e hat-linux-gnu un
0090 6b 6e 6f 77 6e 20 75 6e 6b 6e 6f 77 6e 0a 00 00 known unknown...
00a0 00 00 38 44 61 65 6d 6f 6e 20 73 74 61 72 74 65 ..8Daemon starte
00b0 64 20 32 32 2d 6c 75 74 2d 31 35 20 30 39 3a 31 d 22-lut-15 09:1
00c0 31 2e 20 4a 6f 62 73 3a 20 72 75 6e 3d 30 20 72 1. Jobs: run=0 r
00d0 75 6e 6e 69 6e 67 3d 30 2e 0a 00 00 00 00 49 20 unning=0......I
00e0 48 65 61 70 3a 20 68 65 61 70 3d 31 33 35 2c 31 Heap: heap=135,1
00f0 36 38 20 73 6d 62 79 74 65 73 3d 32 31 2c 33 31 68 smbytes=21,31
0100 39 20 6d 61 78 5f 62 79 74 65 73 3d 32 31 2c 34 9 max_bytes=21,4
0110 36 36 20 62 75 66 73 3d 34 39 20 6d 61 78 5f 62 66 bufs=49 max_b
0120 75 66 73 3d 35 30 0a 00 00 00 00 2f 20 53 69 7a ufs=50...../ Siz
0130 65 6f 66 3a 20 62 6f 66 66 73 65 74 5f 74 3d 38 eof: boffset_t=8
0140 20 73 69 7a 65 5f 74 3d 38 20 64 65 62 75 67 3d size_t=8 debug=
0150 30 20 74 72 61 63 65 3d 30 20 00 00 00 00 10 0a 0 trace=0 ......
0160 52 75 6e 6e 69 6e 67 20 4a 6f 62 73 3a 0a 00 00 Running Jobs:...
0170 00 00 28 44 69 72 65 63 74 6f 72 20 63 6f 6e 6e ..(Director conn
0180 65 63 74 65 64 20 61 74 3a 20 32 32 2d 6c 75 74 ected at: 22-lut
0190 2d 31 35 20 30 39 3a 31 31 0a 00 00 00 00 12 4e -15 09:11......N
01a0 6f 20 4a 6f 62 73 20 72 75 6e 6e 69 6e 67 2e 0a o Jobs running..
01b0 00 00 00 00 06 3d 3d 3d 3d 0a 00 00 00 00 13 0a .....====.......
01c0 54 65 72 6d 69 6e 61 74 65 64 20 4a 6f 62 73 3a Terminated Jobs:
01d0 0a 00 00 00 00 06 3d 3d 3d 3d 0a 00 ff ff ff ff ......====......
W powyższym listingu łatwo można przeczytać zawartość pakietu czyli w tym wypadku status Klienta ganihome-fd.
AKTUALIZACJA (11.08.2019) po komentarzu użytkownika "kkw":
Aktualnie w nowszych wersjach Bacula od zaprezentowanych w tekstowej konsoli bconsole w statusie klienta (status client=xyz) można zobaczyć informację o tym, czy połączenie jest szyfrowane.
III) Szyfrowanie transmisji Director <=> Storage Daemon
W analogiczny sposób do otworzenia szyfrowanej komunikacji pomiędzy Director'em a Klientem, skonfiguruję szyfrowaną komunikację Director <=> Storage Daemon.
W tym celu na komputer ze Storage Daemon'em do katalogu:
/etc/bacula/ssl/
kopiuję pliki:
- keys/ganiwork.lan-sd_key.pem
- certs/ganiwork.lan-sd_cert.pem
- certs/root_cert.pem
Teraz struktura plików w tym katalogu wygląda tak:
# find /etc/bacula/ssl/
/etc/bacula/ssl/
/etc/bacula/ssl/ganiwork.lan-sd_cert.pem
/etc/bacula/ssl/ganihome-fd_cert.pem
/etc/bacula/ssl/root_cert.pem
/etc/bacula/ssl/ganiwork.lan-sd_key.pem
/etc/bacula/ssl/ganihome-fd_key.pem
UWAGA!
Mój Storage Daemon działa na tym samym hoście co Director, dlatego w powyższym listingu znajdują się również pliki certyfikatu i klucza prywatnego Klienta.
Zdaję sobie sprawę, że nie ma większego sensu konfigurowanie szyfrowanej transmisji pomiędzy serwisami znajdującymi się na tym samym hoście :-)
Gdyby mój Storage Daemon znajdował się na osobnym hoście, wtedy struktura plików hosta Storage Daemon'a wyglądała by jak poniżej.
/etc/bacula/ssl/
kopiuję pliki certyfikatów i klucza prywatnego Director'a. Struktura plików powinna wyglądać jak poniżej:
find /etc/bacula/ssl/
/etc/bacula/ssl/
/etc/bacula/ssl/ganiwork.lan-sd_cert.pem
/etc/bacula/ssl/root_cert.pem
/etc/bacula/ssl/ganiwork.lan-sd_key.pem
U mnie wygląda to nieco inaczej ze względu na działanie Director'a i Storage Daemon'a Bacula na tym samym hoście ganiwork.lan:
find /etc/bacula/ssl/
/etc/bacula/ssl/
/etc/bacula/ssl/ganiwork.lan-sd_cert.pem
/etc/bacula/ssl/ganihome-fd_cert.pem
/etc/bacula/ssl/root_cert.pem
/etc/bacula/ssl/ganiwork.lan-sd_key.pem
/etc/bacula/ssl/ganihome-fd_key.pem
W celu skonfigurowania szyfrowanej komunikacji Director <=> Storage Daemon od strony plików konfiguracyjnych, do pliku na hoście ze Storage Daemon'em dodaję do zasobu Director następujące dyrektywy:
TLS Enable = yes
TLS Require = yes
TLS CA Certificate File = /etc/bacula/ssl/root_cert.pem
TLS Certificate = /etc/bacula/ssl/ganiwork.lan-sd_cert.pem
TLS Key = /etc/bacula/ssl/ganiwork.lan-sd_key.pem
Cały zasób Director w pliku konfiguracyjnym Storage Daemona wygląda następująco:
Director {
Name = ganiwork.lan-dir
Password = "XXXXXXXXXXXXXXXXXXXX"
TLS Enable = yes
TLS Require = yes
TLS CA Certificate File = /etc/bacula/ssl/root_cert.pem
TLS Certificate = /etc/bacula/ssl/ganiwork.lan-sd_cert.pem
TLS Key = /etc/bacula/ssl/ganiwork.lan-sd_key.pem
}
Po edycji pliku konfiguracyjnego restartuję Storage Daemon'a.
Do pliku konfiguracyjnego Director'a w zasobie Storage dodaję następujące wpisy:
TLS Enable = yes
TLS Require = yes
TLS CA Certificate File = /etc/bacula/ssl/root_cert.pem
TLS Certificate = /etc/bacula/ssl/ganiwork.lan-sd_cert.pem
TLS Key = /etc/bacula/ssl/ganiwork.lan-sd_key.pem
Zasób Storage w pliku konfiguracyjnym Director'a wygląda teraz jak poniżej.
Storage {
Name = File1
Address = ganiwork.lan
SDPort = 9103
Password = "XXXXXXXXXXXXXXXXXXXX"
Device = FileChgr1
Media Type = File1
Maximum Concurrent Jobs = 10
TLS Enable = yes
TLS Require = yes
TLS CA Certificate File = /etc/bacula/ssl/root_cert.pem
TLS Certificate = /etc/bacula/ssl/ganiwork.lan-sd_cert.pem
TLS Key = /etc/bacula/ssl/ganiwork.lan-sd_key.pem
}
Przeładowuję konfigurację Director'a i sprawdzam w tekstowej konsoli Bconsole, czy komunikacja Director <=> Storage Daemon działa:
*status storage=File1
Connecting to Storage daemon File1 at ganiwork.lan:9103
ganiwork.lan-sd Version: 7.0.5 (28 July 2014) x86_64-unknown-linux-gnu redhat One)
Daemon started 22-lut-15 09:49. Jobs: run=0, running=0.
Heap: heap=249,856 smbytes=206,421 max_bytes=287,816 bufs=112 max_bufs=114
Sizes: boffset_t=8 size_t=8 int32_t=4 int64_t=8 mode=0,0
Running Jobs:
No Jobs running.
====
Jobs waiting to reserve a drive:
====
Terminated Jobs:
JobId Level Files Bytes Status Finished Name
===================================================================
1 Full 152 2.541 M OK 21-lut-15 19:05 BackupClient1
2 Incr 0 0 Error 21-lut-15 23:05 BackupClient1
3 Full 0 0 Error 21-lut-15 23:10 BackupCatalog
====
Device status:
Autochanger "FileChgr1" with devices:
"FileChgr1-Dev1" (/tmp)
"FileChgr1-Dev2" (/tmp)
Autochanger "FileChgr2" with devices:
"FileChgr2-Dev1" (/tmp)
"FileChgr2-Dev2" (/tmp)
Device "FileChgr1-Dev1" (/tmp) is not open.
==
Device "FileChgr1-Dev2" (/tmp) is not open.
==
Device "FileChgr2-Dev1" (/tmp) is not open.
==
Device "FileChgr2-Dev2" (/tmp) is not open.
==
====
Used Volume status:
====
====
IV) Szyfrowanie transmisji Klient <=> Storage Daemon
Wszystkie potrzebne certyfikaty i klucze prywatne są już na miejscu (umieściłem je w powyższych krokach konfiguracji), więc przechodzę od razu do konfiguracji serwisów Bacula.
Do pliku konfiguracyjnego Storage Daemon'a do zasobu Storage dodaję dyrektywy:
TLS Enable = yes
TLS Require = no
TLS CA Certificate File = /etc/bacula/ssl/root_cert.pem
TLS Certificate = /etc/bacula/ssl/ganiwork.lan-sd_cert.pem
TLS Key = /etc/bacula/ssl/ganiwork.lan-sd_key.pem
Zasób Storage w pliku konfiguracyjnym Storage Daemon'a wygląda teraz tak:
Storage {
Name = ganiwork.lan-sd
SDPort = 9103
WorkingDirectory = "/opt/bacula/working"
Pid Directory = "/var/run"
Maximum Concurrent Jobs = 20
TLS Enable = yes
TLS Require = no
TLS CA Certificate File = /etc/bacula/ssl/root_cert.pem
TLS Certificate = /etc/bacula/ssl/ganiwork.lan-sd_cert.pem
TLS Key = /etc/bacula/ssl/ganiwork.lan-sd_key.pem
}
Proszę zwrócić uwagę, że tym razem dyrektywa TLS Require ustawiona jest na "no" (wyłączona). Jest to o tyle ważne, że dzięki temu zarówno Klienci komunikujący się z użyciem szyfrowania ze Storage Daemonem, jak i Klienci działający bez ustawionego szyfrowania komunikacji będą w stanie połączyć się ze Storage Daemon'em i go używać. W przeciwnym wypadku (TLS Require = yes) jedynie klienci ze skonfigurowanym szyfrowaniem mogliby korzystać ze Storage Daemon'a. Innymi słowy - jeżeli wszyscy Klienci Bacula działają z użyciem szyfrowania, wtedy można ustawić dyrektywę w zasobie Storage na:
TLS Require = yes
W każdym innym przypadku dla dyrektywy zasobu Storage:
TLS Require = no
Po powyższych zmianach restartuję serwis Storage Daemon'a.
W konfiguracji Klienta potrzeba dodać do zasobu FileDaemon następujące dyrektywy:
TLS Enable = yes
TLS Require = yes
TLS CA Certificate File = /etc/bacula/ssl/root_cert.pem
TLS Certificate = /etc/bacula/ssl/ganihome-fd_cert.pem
TLS Key = /etc/bacula/ssl/ganihome-fd_key.pem
Teraz zasób FileDaemon w konfiguracji Klienta wygląda u mnie tak:
FileDaemon {
Name = ganihome-fd
FDport = 9102
WorkingDirectory = /var/lib/bacula
Pid Directory = /var/run/bacula
Maximum Concurrent Jobs = 20
TLS Enable = yes
TLS Require = yes
TLS CA Certificate File = /etc/bacula/ssl/root_cert.pem
TLS Certificate = /etc/bacula/ssl/ganihome-fd_cert.pem
TLS Key = /etc/bacula/ssl/ganihome-fd_key.pem
}
Po powyższych zmianach restartuję również serwis Klienta.
Dla sprawdzenia, czy połączenie jest szyfrowane i czy File Daemon i Storage Daemon komunikują się poprawnie, można wykonać testowy backup z Klienta.
*run job=BackupClient1
Using Catalog "MyCatalog"
Run Backup job
JobName: BackupClient1
Level: Incremental
Client: ganihome-fd
FileSet: Full Set
Pool: File (From Job resource)
Storage: File1 (From Job resource)
When: 2015-02-22 10:27:39
Priority: 10
OK to run? (yes/mod/no): yes
Job queued. JobId=5
You have messages.
*messages
22-lut 10:27 ganiwork.lan-dir JobId 5: No prior Full backup Job record found.
22-lut 10:27 ganiwork.lan-dir JobId 5: No prior or suitable Full backup found in catalog. Doing FULL backup.
22-lut 10:27 ganiwork.lan-dir JobId 5: Start Backup JobId 5, Job=BackupClient1.2015-02-22_10.27.41_05
22-lut 10:27 ganiwork.lan-dir JobId 5: Using Device "FileChgr1-Dev1" to write.
22-lut 10:27 ganiwork.lan-sd JobId 5: Volume "Vol-0001" previously written, moving to end of data.
22-lut 10:27 ganiwork.lan-sd JobId 5: Ready to append to end of Volume "Vol-0001" size=2,549,165
22-lut 10:27 ganiwork.lan-sd JobId 5: Elapsed time=00:00:04, Transfer rate=4.594 M Bytes/second
22-lut 10:27 ganiwork.lan-sd JobId 5: Sending spooled attrs to the Director. Despooling 457,237 bytes ...
22-lut 10:27 ganiwork.lan-dir JobId 5: Bacula ganiwork.lan-dir 7.0.5 (28Jul14):
Build OS: x86_64-unknown-linux-gnu redhat One)
JobId: 5
Job: BackupClient1.2015-02-22_10.27.41_05
Backup Level: Full (upgraded from Incremental)
Client: "ganihome-fd" 5.2.13 (19Jan13) x86_64-redhat-linux-gnu,unknown,unknown
FileSet: "Full Set" 2015-02-22 10:27:41
Pool: "File" (From Job resource)
Catalog: "MyCatalog" (From Client resource)
Storage: "File1" (From Job resource)
Scheduled time: 22-lut-2015 10:27:39
Start time: 22-lut-2015 10:27:44
End time: 22-lut-2015 10:27:48
Elapsed time: 4 secs
Priority: 10
FD Files Written: 1,665
SD Files Written: 1,665
FD Bytes Written: 18,181,206 (18.18 MB)
SD Bytes Written: 18,378,226 (18.37 MB)
Rate: 4545.3 KB/s
Software Compression: None
VSS: no
Encryption: no
Accurate: no
Volume name(s): Vol-0001
Volume Session Id: 2
Volume Session Time: 1424597081
Last Volume Bytes: 20,991,947 (20.99 MB)
Non-fatal FD errors: 0
SD Errors: 0
FD termination status: OK
SD termination status: OK
Termination: Backup OK
V) Szyfrowanie transmisji Bconsole <=> Director
Na hoście z działającym serwisem Director kopiuję do lokalizacji:
/etc/bacula/ssl/
klucz prywatny i certyfikat Director'a (certyfikat Root CA jest już na miejscu, więc go nie kopiuję):
- keys/ganiwork.lan-dir_key.pem
- certs/ganiwork.lan-dir_cert.pem
Teraz zawartość tego katalogu wygląda jak poniżej.
find /etc/bacula/ssl/
/etc/bacula/ssl/
/etc/bacula/ssl/ganiwork.lan-dir_cert.pem
/etc/bacula/ssl/ganiwork.lan-sd_cert.pem
/etc/bacula/ssl/ganihome-fd_cert.pem
/etc/bacula/ssl/root_cert.pem
/etc/bacula/ssl/ganiwork.lan-sd_key.pem
/etc/bacula/ssl/ganihome-fd_key.pem
/etc/bacula/ssl/ganiwork.lan-dir_key.pem
Klucz prywatny i certyfikat Director'a oraz certyfikat Root CA kopiuję również na hosta z którego będę wykonywał połączenie przy użyciu Bconsole. Celem kopiowania jest dowolny komputer, który ma możliwość komunikacji z serwisem Director'a. Znajdują się na nim teraz pliki:
find /etc/bacula/ssl/
/etc/bacula/ssl/
/etc/bacula/ssl/root_cert.pem
/etc/bacula/ssl/ganiwork.lan-dir_cert.pem
/etc/bacula/ssl/ganiwork.lan-dir_key.pem
W pliku konfiguracyjnym Director'a w zasobie Director dodaję następujące wpisy:
TLS Enable = yes
TLS Require = yes
TLS CA Certificate File = /etc/bacula/ssl/root_cert.pem
TLS Certificate = /etc/bacula/ssl/ganiwork.lan-dir_cert.pem
TLS Key = /etc/bacula/ssl/ganiwork.lan-dir_key.pem
Po tej edycji zasób Director w pliku konfiguracyjnym Director'a wygląda u mnie tak:
Director { # define myself
Name = ganiwork.lan-dir
DIRport = 9101 # where we listen for UA connections
QueryFile = "/usr/local/bacula7/scripts/query.sql"
WorkingDirectory = "/opt/bacula/working"
PidDirectory = "/var/run"
Maximum Concurrent Jobs = 20
Password = "XXXXXXXXXXXXXXXXX"
Messages = Daemon
TLS Enable = yes
TLS Require = yes
TLS CA Certificate File = /etc/bacula/ssl/root_cert.pem
TLS Certificate = /etc/bacula/ssl/ganiwork.lan-dir_cert.pem
TLS Key = /etc/bacula/ssl/ganiwork.lan-dir_key.pem
}
Na koniec edytuję na hoście z zainstalowaną konsolą Bacula Bconsole plik konfiguracyjny Bconsole i dodaję do niego następujące wpisy do zasobu Director:
TLS Enable = yes
TLS Require = yes
TLS CA Certificate File = /etc/bacula/ssl/root_cert.pem
TLS Certificate = /etc/bacula/ssl/ganiwork.lan-dir_cert.pem
TLS Key = /etc/bacula/ssl/ganiwork.lan-dir_key.pem
Wynikiem tego zasób Director w pliku konfiguracyjnym Bconsole wygląda teraz tak:
Director {
Name = ganiwork.lan-dir
DIRport = 9101
address = ganiwork.lan
Password = "XXXXXXXXXXXXXXXXX"
TLS Enable = yes
TLS Require = yes
TLS CA Certificate File = /etc/bacula/ssl/root_cert.pem
TLS Certificate = /etc/bacula/ssl/ganiwork.lan-dir_cert.pem
TLS Key = /etc/bacula/ssl/ganiwork.lan-dir_key.pem
}
Sprawdzam połączenie Bconsole z Directorem:
# bconsole
Connecting to Director ganiwork.lan:9101
1000 OK: 1 ganiwork.lan-dir Version: 7.0.5 (28 July 2014)
Enter a period to cancel a command.
*
VI) Zakończenie
Przedstawiona w tym artykule konfiguracja szyfrowanego połączenia Bacula jest opisem podstawowym. Bardziej wnikliwi czytelnicy, oprócz samego szyfrowania komunikacji serwisów Bacula, mogą zauważyć, że w oficjalnej dokumentacji Bacula istnieje kilka dodatkowych dyrektyw do szyfrowania transmisji, o których tutaj nie wspomniałem.
Sposobów na szyfrowanie transmisji pomiędzy serwisami Bacula jest zapewne znacznie więcej, jak choćby połączenia poprzez VPN czy zwykłe tunelowanie SSH. W tym artykule przedstawiłem natywną konfigurację Bacula dla szyfrowania komunikacji serwisów.
Zachęcam do własnych eksperymentów z szyfrowaniem połączeń Bacula oraz testów z użyciem narzędzi sniffera, aby być pewnym tego, że dane są przesyłane w sposób bezpieczny.