Użytkownicy komputerów podobno dzielą się na tych, którzy już robią backupy i tych, którzy zaczną je robić jak tylko stracą swoje dane. My mamy nadzieje, że nasi Czytelnicy dzielą się na tych, którzy robią backupy i tych, którzy także je szyfrują.
W sieci nie brakuje usług tworzenia kopii bezpieczeństwa w chmurze. Znaleźć można także dostawców, którzy oferują również szyfrowanie przechowywanych danych. Można też uruchomić gotowe rozwiązania do tworzenia kopii bezpieczeństwa na własnych lokalnych lub zdalnych serwerach. Naszym zdaniem warto jednak czasem zrobić coś samodzielnie i od początku do końca, by przy okazji nauczyć się czegoś nowego. Dlatego też dzisiaj przypomnimy podstawy kryptografii asymetrycznej oraz wykorzystamy ją do stworzenia bezpiecznych, zaszyfrowanych kopii bezpieczeństwa na zdalnym serwerze.
We współpracy z firmą ArubaCloud pokazaliśmy Wam, jak postawić swój serwer backupów, jak skonfigurować własny serwer VPN i podłączyć do niego komputer, telefony komórkowe oraz domowy ruter a także jak schować się przed cenzurą sieci i jak zacząć serwer zabezpieczać, jak postawić swój własny zdalny pulpit, swój serwer WWW, jak monitorować zmiany w plikach oraz jak zablokować reklamy na komórce.
Jeśli nie macie jeszcze swojego własnego serwera, to jest to dobra okazja by się w taki wyposażyć. Aruba oferuje dwa miesiące korzystania ze swojego podstawowego serwera gratis – a po zakończeniu promocji będzie on Was kosztował zaledwie 4 złote miesięcznie. Instrukcję jak krok po kroku skorzystać z promocji i uruchomić swój serwer znajdziecie w tym artykule. Jeśli macie już swój serwer – to zapraszamy do lektury kolejnych akapitów.
Cały proces konfiguracji serwera możecie obejrzeć na poniższym filmie. Pod nim znajdziecie szczegółowy opis tekstowy.
Kryptografia asymetryczna
Na początek szczypta teorii. W kryptografii asymetrycznej wyróżniamy dwa pojęcia:
- Klucz prywatny
Klucz ten służy do odszyfrowywania oraz podpisywania danych. Posiadając klucz prywatny możemy uwierzytelnić naszą tożsamość. Klucza prywatnego nikomu nie wysyłamy – nie udostępniamy go osobom trzecim, nie udostępniamy go również w internecie. Jak sama nazwa wskazuje – jest to klucz prywatny. Podglądając zawartość pliku z kluczem prywatnym warto zwrócić uwagę, że plik ten rozpoczyna się linią „BEGIN PGP (lub RSA) PRIVATE KEY BLOCK”. Utrata klucza uniemożliwia nam odszyfrowanie danych – sami musimy zadbać o jego bezpieczne przechowywanie. - Klucz publiczny
Jak sama nazwa wskazuje – klucz ten może być udostępniany osobom trzecim. Klucz publiczny służy do szyfrowania danych. Jeśli nadawca chce zaszyfrować dane przesyłane do właściciela klucza, korzysta wyłącznie z klucza publicznego. Zawartość pliku publicznego rozpoczyna się linią „BEGIN PGP PUBLIC KEY BLOCK”
W artykule wygenerujemy dwie pary kluczy:
- Klucz publiczny i prywatny do uwierzytelnienia przez SSH. Ta para kluczy będzie wykorzystywana do łączenia się do zdalnego serwera kopii zapasowych przez protokół SSH bez konieczności wpisywania hasła.
- Klucz publiczny i prywatny PGP do szyfrowania danych. Klucze te będą wykorzystywane do szyfrowania i odszyfrowania plików, które znajdują są na serwerze kopii zapasowej.
Wygenerowane klucze wykorzystują kryptografię asymetryczną.
Nasz plan działania:
- utworzymy klucze do autoryzacji SSH,
- wgramy klucz publiczny na serwer zdalny aby uwierzytelnić się za pomocą kluczy,
- utworzymy parę kluczy PGP,
- zaszyfrujemy przykładowe dane,
- zsynchronizujemy katalog lokalny z katalogiem zdalnym.
Klucze SSH
Na komputerze lokalnym generujemy parę kluczy do autoryzacji za pomocą protokołu SSH. Klucz prywatny zostawiamy na komputerze/serwerze, z którego będziemy przesyłali dane na serwer zdalny.
$ ssh-keygen -t rsa -b 4096 -C "twoj_adres@email"
Generating public/private rsa key pair. Enter file in which to save the key (/home/krystian/.ssh/id_rsa): - enter Enter passphrase (empty for no passphrase): - czy klucz prywatny powinien być zabezpieczony hasłem? - enter Enter same passphrase again: - enter Your identification has been saved in /home/krystian/.ssh/id_rsa. Your public key has been saved in /home/krystian/.ssh/id_rsapub. The key fingerprint is: fe:86:9c:5b:63:87:23:e4:a6:b2:b7:26:12:3a:79:ba twoj_adres@email The key's randomart image is: +--[ RSA 4096]----+ | | | | | | | | | S | | . + . | | o . .=o* . | |+ o o oo+=.+ | |E= ..*o..o. | +-----------------+
Poleceniem 'ssh-keygen’ utworzyliśmy parę kluczy RSA. Klucz prywatny został zapisany do pliku /home/krystian/.ssh/id_rsa, natomiast klucz publiczny – /home/krystian/.ssh/id_rsa.pub.
Klucz publiczny (id_rsa.pub) wgrywamy na serwer kopii bezpieczeństwa. Wgranie klucza publicznego umożliwi nam logowanie się do konta bez potrzeby podawania hasła.
Zanim wgramy klucz publiczny na serwer kopii zapasowej, utwórzmy na nim konto, na które będziemy logowali się bez podawania hasła – na przykład konto o nazwie „backup”
$ ssh root@aruba-cloud # adduser backup # passwd backup - tymczasowo ustawiamy hasło do konta by wgrac klucz publiczny # chmod 700 /home/backup - ustawiamy odpowiednie uprawnienia do katalogu /home/backup
Mając utworzone konto o nazwie 'backup’ na serwerze zdalnym, możemy wgrać klucz publiczny by logować się na konto bez podawania hasła
$ ssh-copy-id -i /home/krystian/.ssh/id_rsa.pub backup@aruba-cloud
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys backup@aruba-cloud password: Number of key(s) added: 1 Now try logging into the machine, with: "ssh 'backup@aruba-cloud'" and check to make sure that only the key(s) you wanted were added.
Po wgraniu klucza sprawdzamy, czy możemy zalogować się do konta za jego pomocą:
$ ssh backup@aruba-cloud Last login: Fri Apr 28 11:44:07 2017 [backup@aruba-cloud ~] $
Tym oto sposobem uzyskaliśmy autoryzację za pomocą pary kluczy RSA do logowania się na konto o loginie „backup” na serwerze zdalnym. Logujemy się po raz drugi na serwer w Aruba Cloud jako root i blokujemy hasło dla użytkownika 'backup’:
$ ssh root@aruba-cloud # passwd -l backup
Klucze PGP
Na komputerze lokalnym utworzymy parę kluczy PGP którymi będziemy szyfrować/odszyfrowywać pliki.
Generujemy klucz publiczny oraz klucz prywatny o długości 4096 bitów – pod koniec generowania klucza będziemy poproszeni o podanie hasła w celu zabezpieczenia klucza prywatnego:
$ gpg2 --gen-key
gpg (GnuPG) 2.0.22; Copyright (C) 2013 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Please select what kind of key you want: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only) Your selection? RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) 4096 Requested keysize is 4096 bits Please specify how long the key should be valid. 0 = key does not expire <n> = key expires in n days <n>w = key expires in n weeks <n>m = key expires in n months <n>y = key expires in n years Key is valid for? (0) 0 Key does not expire at all Is this correct? (y/N) y GnuPG needs to construct a user ID to identify your key. Real name: Krystian Email address: twoj_adres@email Comment: You selected this USER-ID: "Krystian <twoj_adres@email>" Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O You need a Passphrase to protect your secret key. gpg: /home/krystian/.gnupg/trustdb.gpg: trustdb created gpg: key E53476EB marked as ultimately trusted public and secret key created and signed. gpg: checking the trustdb gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u pub 4096R/BF189AE0 2017-04-29 Key fingerprint = 8B02 0C56 75AF F0F9 A1A7 C78E C03A 3F11 BF18 9AE0 uid Krystian <twoj_adres@email> sub 4096R/9EB2A3AF 2017-04-29
Utworzyliśmy klucz główny od identyfikatorze BF189AE0 oraz podklucz o identyfikatorze 9EB2A3AF do szyfrowania danych i plików.
Szyfrujemy pliki i wysyłamy na serwer
Tworzymy dwa katalogi: /tmp/pliki/zaszyfrowane oraz /tmp/pliki/niezaszyfrowane w którym utworzymy plik dane.txt:
$ mkdir -p /tmp/pliki/{zaszyfrowane,niezaszyfrowane} $ echo "Dane testowe" > /tmp/pliki/niezaszyfrowane/dane.txt
Następnie zaszyfrujemy plik dane.txt naszym kluczem PGP – zaszyfrowany plik zapiszemy do katalogu /tmp/pliki/zaszyfrowane jako dane.txt.pgp:
$ gpg --encrypt --output /tmp/pliki/zaszyfrowane/dane.txt.pgp --recipient twoj_adres@email /tmp/pliki/niezaszyfrowane/dane.txt
Po wykonaniu powyższej komendy został utworzony plik dane.txt.gpg:
$ file /tmp/pliki/zaszyfrowane/dane.txt.gpg dane.txt.gpg: GPG encrypted data $ ls -la /tmp/pliki/zaszyfrowane/dane.txt.gpg -rw-r--r-- 1 root root 608 Apr 26 20:40 dane.txt.gpg
Aby wgrać go na zdalny serwer instalujemy pakiet 'rsync’.
$ sudo yum install rsync -y
Po instalacji pakietu wgrywamy zawartość katalogu /tmp/pliki/zaszyfrowane na zdalny serwer:
$ rsync -avz -e "ssh" --progress /tmp/pliki/zaszyfrowane/ backup@aruba-cloud:/home/backup/ sending incremental file list ./ dane.txt.gpg 608 100% 0.00kB/s 0:00:00 (xfer#1, to-check=0/2) sent 706 bytes received 34 bytes 296.00 bytes/sec total size is 608 speedup is 0.82
Rsync idealnie nadaje się do synchronizacji wielu plików oraz katalogów – jeśli będziecie chcieli zsynchronizować katalog lokalny z katalogiem zdalnym – jest to narzędzie którym warto się posłużyć.
Skrypt automatyzujący szyfrowanie
Na potrzeby artykułu utworzyliśmy bardzo prosty skrypt. Skrypt ten pobiera listę plików w zdefiniowanym katalogu, szyfruje je do oddzielnego katalogu, a następnie wysyła je na serwer zdalny.
#!/bin/bash # adres e-mail właściciela klucza pgp PGP_ADDRESS="twoj_adres@email" # katalog w którym przechowywane są niezaszyfrowane pliki SOURCE_DIR="/tmp/pliki/niezaszyfrowane/*" # katalog do którego będą wgrywane zaszyfrowane pliki DESTINATION_DIR="/tmp/pliki/zaszyfrowane" # adres serwera zdalnego REMOTE_SERVER=aruba-cloud # użytkownik na serwerze zdalnym REMOTE_USER=backup # pełna scieżka na serwerze zdalnym REMOTE_DIR="/home/backup/" # pętla główna - sprawdzamy każdy plik w SOURCE_DIR for f in ${SOURCE_DIR} do plik=$(basename "$f.gpg") echo "Szyfruję plik $f do pliku ${DESTINATION_DIR}/${plik}" gpg --output ${DESTINATION_DIR}/${plik} --encrypt \ --recipient ${PGP_ADDRESS} $f # sprawdzamy czy wystąpił błąd podczas szyfrowania pliku if [ $? == 0 ] then echo -n " Sprawdzam czy istnieje zaszyfrowany plik..." # sprawdzamy czy plik istnieje if [ -f ${DESTINATION_DIR}/${plik} ] then echo " Plik istnieje" # jesli plik nie istnieje else echo " Błąd! Brak zaszyfrowanego pliku ${DESTINATION_DIR}/${plik}!" fi # jeśli wystąpi błąd podczas wykonywania polecenia `gpg` else echo " Bład podczas szyfrowania pliku" fi # koniec petli glownej done echo "Przenoszę zaszyfrowane pliki na serwer zdalny" rsync --dry-run --remove-source-files -avz -e \ "ssh" --progress \ ${DESTINATION_DIR} \ ${REMOTE_USER}@${REMOTE_SERVER}:${REMOTE_DIR}
W zmiennej SOURCE_DIR zdefiniowano katalog, gdzie znajdują się pliki gotowe szyfrowania. Zaszyfrowane pliki będą zapisywane do katalogu zdefiniowanego w zmiennej DESTINATION_DIR. Ostatnim etapem jest przeniesienie plików na zdalny serwer. Dla bezpieczeństwa w poleceniu rsync użyto argumentu –dry-run – użycie tego argumentu powoduje, że narzędzie rsync zostanie uruchomione bez faktycznego wprowadzania zmian na dysku.
Nadajemy odpowiednie uprawnienia dla pliku:
$ chmod 700 autobackup.sh
Usuwamy plik 'dane.txt.gpg’ z katalogu /tmp/pliki/zaszyfrowane oraz uruchamiamy plik autobackup.sh:
$ rm /tmp/pliki/zaszyfrowane/dane.txt.gpg $ ./autobackup.sh Szyfruje plik /tmp/pliki/niezaszyfrowane/dane.txt do pliku /tmp/pliki/zaszyfrowane/dane.txt.gpg Sprawdzam czy istnieje zaszyfrowany plik... Plik istnieje Przenoszę zaszyfrowane pliki na serwer zdalny sending incremental file list zaszyfrowane/ zaszyfrowane/dane.txt.gpg sent 97 bytes received 19 bytes 77.33 bytes/sec total size is 608 speedup is 5.24 (DRY RUN) sent 121 bytes received 22 bytes 95.33 bytes/sec total size is 33569969 speedup is 234755.03 (DRY RUN)
Zadanie cykliczne
Ustawiamy nasz ulubiony edytor tekstu:
export EDITOR=nano export VISUAL=nano
oraz edytujemy crontab by uruchamiał skrypt autobackup.sh codziennie o pierwszej godzinie w nocy:
$ crontab -e 0 1 * * * /home/krystian/autobackup.sh
Podsumowanie
Celem artykułu było wytłumaczenie na czym idei klucza publicznego i klucza prywatnego oraz pokazanie ich praktycznego zastosowania do tworzenia bezpiecznych kopii zapasowych. Mamy nadzieję, że już szyfrujecie swoje backupy. Bo robicie je regularnie, prawda? :)
Dla pełnej przejrzystości – za przygotowanie oraz opublikowanie powyższego artykułu otrzymujemy wynagrodzenie.
Komentarze
Jeśli mogę się wtrącić z kryptoreklamą – znacznie pewniejszym rozwiązaniem od ręcznego dziergania będzie użycie jakiegoś gotowego rozwiązania.
Np. framework Server Farmer automatyzuje cały proces szyfrowanego backupu serwera, począwszy od w pełni automatycznego wykrycia, jakie katalogi i inne zasoby (np. bazy danych) na danym serwerze wymagają zabezpieczenia, poprzez ich zaszyfrowanie GPG i zaciąganie do ustalonej lokalizacji.
Różnica pomiędzy SF a rozwiązaniem opisanym wyżej jest przy tym taka, że to serwer backupu inicjuje kopiowanie z serwerów „podległych”. Dzięki temu jeśli ktoś się nam włamie na jeden z takich serwerów, nie będzie w stanie skasować backupów, jak to miało miejsce np. rok temu w 2BE.pl.
Jeśli ktoś będzie zainteresowany stworzeniem gotowego profilu dla Aruby, aby zainstalować całe rozwiązanie jednym poleceniem – zapraszam do kontaktu, chętnie pomogę.
Więcej informacji:
http://serverfarmer.org/
https://github.com/serverfarmer
Cały myk polega na tym aby nie używać gotowych rozwiązań i świadomie wiedzieć co się dzieje z naszymi danymi
A żeby to wszystko zrobić znacznie wygodniej możemy użyć Duplicati.
Polecam zobaczyć narzędzie „duplicity”.
http://duplicity.nongnu.org/features.html
Robi automatycznie wszystko to, co w artykule (poza oczywiście generowanie kluczy ssh i gpg), ma dużo dodatkowych funkcji, dobrze sobie radzi z oszczędzaniem miejsca dzięki backupom różnicowym.
Trochę lokowanie produktu..
Ja bym z tego skryptu nie korzystał. Nic w nim nie jest zabezpieczone przed word splittingiem. A z tego co wiem to nazwy plików mogą i często nawet zawierają spacje…
Mam jedno pytanie:
Co w razie awarii dysku kompa lokalnego / straty kompa / umycia przez dziecko w wannie i wsłania w kosmos klucza prywatnego PGP?
Klucze prywatne też się backupuje. Np. na smart card trzymany w sejfie, ale to chyba temat na oddzielny artykuł.
Jak to co? Przecież masz zaszyfrowaną kopię w backupie…. ;)
Warto pamiętać i podkreślić backupu kluczy. Jeśli nie ma backupu kluczy to tak jakby backupu nie było, bo i tak nie rozszyfrujemy backupu.
PGP nie szyfruje danych kluczem asymetrycznym.
Działa to mniej więcej tak:
1. Tworzony jest klucz sesyjny (duża liczba losowa).
2. Dane są szyfrowane symetrycznie za pomocą klucza sesyjnego (np. AES).
3. Klucz sesyjny jest szyfrowany kluczami publicznymi odbiorców i jest doklejany do danych (kryptografia asymetryczna).
Odszyfrowywanie jest odwrotne:
1. Odbiorca odszyfrowuje klucz sesyjny za pomocą swojego klucza prywatnego (kryptografia asymetryczna).
2. Dane są odszyfrowywane za pomocą klucza sesyjnego (kryptografia symetryczna).
Do tworzenia bezpiecznych kopii polecam BORG Backup – https://github.com/borgbackup/borg#what-is-borgbackup
Szyfrowanie po stronie klienta, deduplikacja, kompresja, automatyzacja – działają elegancko. BORGa można postawić praktycznie wszędzie. Na Arubie również się sprawdzi. ;)
No kurde chłopaki mamy dziś ed25519, a wy dalej lansujecie rsa…
Jeśli mogę trochę skrytykować – szyfrowanie plików nie odbywa się za pomocą szyfrów asymetrycznych. Tak co najwyżej szyfruje się symetryczny klucz sesyjny. Niby dałoby się, ale to obliczeniowo słabo by działało. Za to „certyfikat prywatny” to już chyba jednak nie bardzo w tym kościele.
A nie lepiej skorzystać z narzędzia które wspiera GPG out of the box? Duplicity z nakładką duply jest znacznie prostszy w konfiguracji i wspiera backendy jak AWS lub Azure.
Szkoda tylko, że nasza infrastruktura nadal nie dorosła do kopii w chmurze. Z łączem 0,45 Mb/s niewiele się zrobi.
W ogóle nieskomplikowane…
Taki podział tez funkcjonuje:
Ludzie dzielą sie na takich którzy robią backupy i na tych którzy myślą, że robią.
Polecam proste rozwiązania np. Ferro Backup, który szyfruje AESem 256 i można replikować na USB lub owncloud jak ktoś lubi backup online. Działa na linuksie (docker).
Aplikacja płatna.
Nie wiem czemu się czepiacie, przecież wyraźnie jest zaznaczone, że tekst miał w priorytecie użycie kryptografii asymetrycznej i należy go traktować przede wszystkim jako tekst edukacyjny. Jak ktoś wcześniej nie spotkał się np. z generowaniem kluczy, to z pocałowaniem ręki weźmie taki przykład. Poza tym zamiast backupu można sobie do skryptu wrzucić dowolne wrażliwe dane, np. zdjęcie teściowej. ;)
Dokładnie jak Przemek napisał — tylko duply, który jest wrapperem do duplicity. Działanie, bezawaryjność, konfigurowalność — osom.
Potwierdzam i podtrzymuję opinię przedmówców – jak backup via linuch to tylko duply/duplicity: kładzie niejedno komercyjne rozwiązanie na łopatki…
;)
A ja mam pytanie – kto rozsadny wrzuca swoje backup’y do roznego rodzaju 'chmur’?
Przeciez te dane zostana juz tam na zawsze (patrz dropbox – jakie mamy gwarancje ze jak cos usuniemy to bedzie to na prawde usuniete).
Czy moge rozniez zalozyc ze za kilka lat nasze dane bedzie mozna odszyfrowac jako ze klucze uzyte pierwszy raz beda juz zbyt male?
Backup – tak. Szyfrowany – tak. Gdzies na sieci – nigdy.
Pozdr,
-M.
Lepiej w skrypcie dać plik=${f##*/}
Wtedy nie odpala się kolejny proces przy każdym przejściu pętli.
Od jakiegoś czasu korzystam z tarsnap i jestem bardzo zadowolony: pliki są szyfrowane lokalnie, jest dobra deduplikacja a dzięki rozliczeniom w pikodolarach (tak, pikodolarach – to nie jest literówka ;)) niewiele to kosztuje.