Etykiety

linux (14) php (14) Laravel (9) mysql (9) Hardware (8) Windows (6) sieci (5) PowerShell (4) software (4) MariaDB (3) apache (3) html (3) Microsoft (2) bezpieczeństwo LAN (2) cygwin (2) Akcesoria (1) CMS (1) Laptop (1) Open Office (1) drupal 7 (1) gpg (1) hosting (1) jquery (1) sieci LAN (1) xml (1) zabezpieczenie sieci LAN (1)

niedziela, 30 listopada 2014

Linux w windzie? Cygwin!

Linux i Windows to dwa odmienne światy i różnią się od siebie jak dzień i noc.

Windows jest dziś najbardziej popularnym na świecie systemem operacyjnym, ale nie wszystkie zadania mogą zostać z jego pomocą zrealizowane z typową dla Linuksa efektywnością, prostotą i minimalnym wykorzystaniem dostępnych zasobów. Z drugiej strony Linux, którego możliwości i skalowalność są niesamowite, nie zyskał jak dotąd popularności porównywalnej do tej, jaką mogą się cieszyć systemy operacyjne Microsoft, głównie z powodu mitu według którego Linux jest tylko dla ekspertów. Mit ten był zgodny z rzeczywistością 10-15 lat temu, ale dziś, w czasach dostępności prostych w instalacji i użytkowaniu desktopowych dystrybucji Linuksa, pozostaje on tylko mitem wprowadzającym w błąd i przynoszącym duże zyski korporacji Microsoft. Dzisiejsze dystrybucje Linuksa, szczególnie te przeznaczone dla instalacji desktopowych, nie są trudniejsze w użytkowaniu od systemów Microsoft, a w dodatku są zupełnie darmowe, podczas gdy większość osób dobrze znających tajniki i możliwości Linuksa, często zmuszona jest do korzystania równolegle z systemów Windows głównie z powodu niekompatybilności z systemem Linux najbardziej powszechnych aplikacji programistycznych dostępnych na rynku. Być może sytuacja kiedyś się zmieni, ale jak dotąd zwolennicy Linuksa korzystający z przymusu z systemów Windows często czują duże ograniczenie spowodowane brakiem w nim prostych i efektywnych narzędzi, które są powszechnie dostępne w dystrybucjach systemów Linux i za pomocą których można wykonywać złożone zadania z wielką prostotą oraz minimalnym zużyciem zasobów sprzętowych i programistycznych.
Istnieje jednak pewne rozwiązanie, umożliwiające uruchamianie w systemie Windows wielu narzędzi dostępnych tylko w świecie Linux, a w dodatku z wiersza poleceń, który sprawia pełne linuksowe wrażenie. To rozwiązanie nazywa się Cygwin.

Cygwin
Cygwin to Linux w Windows!


Cygwin jest bardzo ciekawym oprogramowaniem udostępniającym Linuksową powłokę w systemach operacyjnych Microsoft Windows. Cygwin udostępnia wiele różnych pakietów aplikacji, którymi można zarządzać z udostępnianego wiersza poleceń. Należy przy tym jednak pamiętać, że oprogramowanie Cygwin nie jest oknem na Linuksowy świat w systemach Windows, ponieważ poza możliwością uruchamiania pakietów typowo Linuksowych aplikacji, które zostały sprowadzone do kodu Cygwin, korzystanie z natywnych aplikacji Linuksowych nie jest w ten sposób możliwe.
Aby ropocząć przygodę z oprogramowaniem Cygwin należy ściągnąć instalator aplikacji ze strony http://cygwin.com/install.html .

Sama instalacja oprogramowania jest bardzo intuicyjna. Instalator umożliwia wybór jednej spośród 3 rodzai instalacji:

a) Instalacja pakietów z internetu (ściągnięte pliki pakietów zostaną zachowane i będzie z nich można ponownie skorzystać);

b) Ściągnięcie pakietów z pominięciem samego procesu instalacji;
c) Instalacja pakietów z lokalnego źródła.

Istnieje również możliwość uruchomienia instalatora Cygwin z wiersza poleceń Windows. Jest to zalecane głównie wtedy gdy istnieje konieczność określenia szczegółowych parametrów związanych z procesem instalacyjnym. Takich parametrów jest sporo:


 -A --disable-buggy-antivirus           Wyłączenie podejrzanych aplikacji antywirusowych
                                        podczas uruchamiania instalatora
 -C --categories                        Specify entire categories to install
 -D --download                          Download from internet
 -d --no-desktop                        Disable creation of desktop shortcut
 -h --help                              print help
 -K --pubkey                            URL of extra public key file (gpg format)
 -L --local-install                     Install from local directory
 -l --local-package-dir                 Local package directory
 -n --no-shortcuts                      Disable creation of desktop and start menu
                                        shortcuts
 -N --no-startmenu                      Disable creation of start menu shortcut
 -O --only-site                         Ignore all sites except for -s
 -P --packages                          Specify packages to install
 -p --proxy                             HTTP/FTP proxy (host:port)
 -q --quiet-mode                        Unattended setup mode
 -r --no-replaceonreboot                Disable replacing in-use files on next
                                        reboot.
 -R --root                              Root installation directory
 -S --sexpr-pubkey                      Extra public key in s-expr format
 -s --site                              Download site
 -U --keep-untrusted-keys               Use untrusted keys and retain all
 -u --untrusted-keys                    Use untrusted keys from last-extrakeys
 -X --no-verify                         Don't verify setup.ini signatures

W trakcie instalacji należy podać ścieżkę do katalogu głównego Cygwin (root directory), np. C:\cygwin oraz wskazać katalog, w którym mają być przechowywane ściągnięte z internetu pakiety aplikacji Cygwin.

Instalator Cygwin umożliwia wybór pakietów, które użytkownik zamierza zainstalować. Po ukończonej aplikacji można ponownie korzystać z instalatora w celu instalacji nowych pakietów lub usunięcia zainstalowanych pakietów.

Miłej zabawy!


Bezpieczeństwo sieci WiFI

W sieciach WiFi dane są transmitowane poprzez sygnał radiowy, który teoretycznie można z łatwością przechwycić. Aby zapewnić poufność i bezpieczeństwo danych, szyfrowanie transmisji staje się niezbędne. Celem stosowania bezpiecznych protokołów LAN jest ograniczenie dostępu do sieci poprzez szyfrowanie połączeń oraz ograniczenie publicznego dostępu do sieci.
Z przeprowadzonych przez nas anonimowych ankiet wynika jednak, że wiele domowych użytkowników sieci bezprzewodowych LAN, uruchamia funkcje sieciowe WiFi bez zastosowania jakichkolwiek protokołów zabezpieczających, a niektórzy użytkownicy nie mają nawet pojęcia o konieczności zastosowania przynajmniej podstawowych zabezpieczeń, uruchamiając urządzenia dostępowe WiFi po najniższej linii oporu. Na całe szczęście tego typu podejście ma miejsce coraz rzadziej, głównie dzięki ogólnodostępnej w naszych czasach podstawowej wiedzy o sieciach WiFi. Co jednak szokujące, okazało się, że nawet w dużych korporacjach zdarzało się informatykom uruchamiać urządzenia dostępowe WiFi (Routery bądź punkty dostępu), bez zastosowania protokołów zabezpieczających, narażając korporacje na utratę cennych i poufnych danych.

Do niezabezpieczonych i słabo zabezpieczonych sieci LAN WiFi, może teoretycznie dostać się każdy, kto znajduje się w zasięgu sieci (do około 70 metrów od urządzenia dostępowego w pomieszczeniach zamkniętych i do około 130 metrów w przestrzeni otwartej) i ma dostęp do komputera, laptopa, smtartfona bądź innego urządzenia wyposażonego w interfejs sieciowy zgodny ze standardami WiFi oraz do specjalistycznego oprogramowania hakerskiego, które jednak może być zbędne w przypadku słabo zabezpieczonych sieci WiFi. Dostając się do niezabezpieczonej sieci WiFi, haker ma już sporo pracy za sobą i z wielką łatwością może dobrać się do każdego komputera osobistego bądź nawet serwera znajdującego się w sieci. Co ciekawe, może to zrobić bez posiadania nieprzeciętnych umiejętności. Hakerzy spragnieni szybkich zarobków krążą autami po miastach z uruchomionymi laptopami, na których specjalistyczne oprogramowanie zbiera dane dotyczące napotkanych po drodze sieci WiFi oraz poziomu ich zabezpieczenia. Złoczyńcy wybierają przeważnie najsłabsze cele, czyli sieci które w ogóle nie są zabezpieczone. Zdarzają się jednak skuteczne włamania do sieci LAN WiFi średnio, a nawet i dobrze zabezpieczonych. Ale po co kusić los, skoro można w prosty sposób utrudnić życie hakerom, zabezpieczając własną sieć WiFi? Średniego poziomu zabezpieczenie sieci WiFi nie musi wcale wymagać specjalistycznej wiedzy. Sprawa wygląda prościej, niż mogło by się wydawać.

Najbardziej popularne protokoły służące do zwiększenia poziomu bezpieczeństwa sieci WiFi to WEP (Wired Equivalent Privacy) i WPA2 (WiFi Protected Access). Istnieją również inne, bardziej złożone metody zabezpieczania sieci WiFi, stosowane głównie w korporacjach, które omówimy osobno.

Oba przedstawione tutaj protokoły korzystają z tajnych kluczy służących do szyfrowania transmisji danych. Klucz szyfrujący wykorzystywany jest wyłącznie przez urządzenie generujące sygnał źródłowy, w celu zabezpieczenia transmisji danych, podczas gdy klucz odszyfrowujący wykorzystywany jest w każdych podpiętym do sieci WiFi urządzeniu, w celu odszyfrowania transmisji. W przeciwieństwie do protokołu WPA2, protokół WEP wymaga od urządzeń mniejszej mocy obliczeniowej, ale jego zabezpieczenia są słabsze. Korzystanie z protokołu WEP nie jest generalnie najlepszym pomysłem i nie zapewnia odpowiedniego poziomu zabezpieczeń. Nie wchodząc w głębsze detale techniczne, warto nadmienić iż w obu protokołach do szyfrowania transmisji wykorzystywane są tak zwane wektory inicjujące IV. Protokół WEP korzysta z 24-bitowych wektorów inicjujących, co umożliwia tylko 16.7 różnych miliona kombinacji, podczas gdy protokół WPA2 stosuje 48-bitowe wektory inicjujące IV, co umożliwia aż 500 trylionów kombinacji.

Zasady bezpieczeństwa w sieciach LAN

Wykonanie typowej sieci LAN, polegające w zasadzie na przeprowadzeniu odpowiednich kabli i podłączeniu ze sobą różnych urządzeń, może wydawać się dosyć prostym zadaniem i faktycznie nie ma w nim nic nadzwyczajnie trudnego. Każdy, kto nauczył się przynajmniej podstaw technologii  sieci teleinformatycznych i nabrał w tej dziedzinie minimalnego doświadczenia jest w stanie prawidłowo zaprojektować i oddać do użytku prostą, typową sieć LAN. Lecz aby oddana do użytku sieć LAN nie stanowiła potencjalnego zagrożenia dla jej użytkowników, powinna ona zostać prawidłowo zabezpieczona. Prawda jest taka, że cała sieć LAN jest na tyle bezpieczna, na ile dobrze zabezpieczone jest jej najsłabsze ogniwo, a więc zabezpieczenie sieci LAN wymaga nieco odmiennej i bardziej obszernej wiedzy, niż ta, która wystarcza do jej fizycznego zaprojektowania i oddania do użytku. Istotną kwestią jest zabezpieczenie nie tylko stacji roboczych i serwerów znajdujących się w sieci, lecz także wszelkich modemów, routerów, punktów dostępu WiFi oraz wszystkich innych urządzeń, które mogą wchodzić w skład sieci LAN, również takich jak sprzętowe zapory ogniowe, przełączniki, moduły sieciowe urządzeń takich jak plotery, drukarki czy zasilacze awaryjne, w co wchodzi często konieczność aktualizacji firmware, biosów, ręcznego pisania reguł zapór ogniowych, prawidłowego ustawienia adresów IP, co z kolej nieraz wymaga dobrej znajomości protokołu TCP/IP, szczególnie w przypadku pracy z podsieciami i łączącymi ich routerami.

Niezależnie od zainstalowanego oprogramowania na poszczególnych stacjach roboczych i serwerach, wszystkie składniki oprogramowania powinny być regularnie uaktualniane do najnowszych wersji. W miarę możliwości aktualizacja oprogramowania powinna odbywać się automatycznie. Odpowiednio skonfigurowana programowa zapora ogniowa, długie i trudne do odgadnięcia nazwy i hasła użytkowników, regularne wymuszanie przez system zmiany haseł użytkowników, odpowiednio skonfigurowane zapory ogniowe i programy antywirusowe, to tylko podstawowe środki ostrożności. Dla prawidłowego zabezpieczenia stacji roboczych i serwerów znajdujących się w sieci LAN zalecam również wyłączenie wszelkich niepotrzebnych do codziennej pracy lub zabawy usług, które są przeważnie standardowo automatycznie uruchamiane podczas startu systemów, nawet w przypadku korzystania z Linuksa. W systemach Windows XP i Vista, które dziś już są rzadko spotykane, takich usług było całe mnóstwo. Sytuacja wygląda nieco lepiej w systemach Windows 7 oraz 8, w których przy starcie systemu standardowo uruchamiana ilość usług jest nieco mniejsza. Aby sprawdzić które usługi są w danej chwili uruchomione, na komputerach pracujących pod kontrolą systemu Windows, należy skorzystać z zakładki 'Usługi' Menedżera Zadań. Konfiguracji dotyczącej automatycznego startu danej usługi można dokonać z poziomu apletu 'Usługi', znajdującego się w Panelu Sterowania. Należy w tym celu posiadać uprawnienia administracyjne. Natomiast na maszynach pracujących pod kontrolą Linuksa, aby określić czy dana usługa ma być automatycznie uruchamiana podczas startu systemu można przykładowo skorzystać z polecenia chkconfig lub update-rc.d, w zależności od dystrybucji Linuksa. W przypadku nowszych dystrybucji  z systemd, należy korzystać z polecenia systemctl, w celu wyłączenia niepotrzebnych usług. W przypadku Linuksa można w prosty sposób kompletnie odinstalować niepotrzebne usługi, lub nawet ręcznie zmodyfikować skrypty uruchamiające usługi podczas startu systemu, dopasowując wszelkie ustawienia do potrzeb użytkownika.

Oprócz komputerów, większość sieci LAN posiada jeden lub więcej routerów, które umożliwiają przesyłanie danych pomiędzy różnymi sieciami w sposób zgodny z przeznaczeniem urządzeń, np. przesyłanie danych pomiędzy siecią WAN a siecią lokalną lub pomiędzy dwoma podsieciami LAN. Prawidłowa konfiguracja routera, w przeciwieństwie do ogólnie panującego przekonania, nie jest rzeczą banalnie prostą i wymaga znajomości kilku protokołów sieciowych, a przynajmniej podstawowej znajomości protokołu TCP/IP. Oprogramowanie routerów często umożliwia automatyczne konfigurowanie parametrów routera na podstawie pytań i odpowiedzi, lecz jeżeli w sieci LAN implementowane są rozwiązania wymagające szczegółowego dopasowania parametrów routera (urządzenia implementujące protokół SNMP, kamery IP, udostępnianie zasobów serwerów na zewnątrz sieci LAN), to nie obejdzie się bez ręcznej konfiguracji urządzenia. Prawidłowo wykonana konfiguracja routera, obejmująca, między innymi, odpowiednie ustawienia parametrów portów WAN i LAN, prawidłowe ustawienia zapory ogniowej routera, prawidłowe ustawienia ewentualnych ograniczeń dostępu np. do niebezpiecznych stron internetowych (dla przykładu za pomocą Cisco ProtectLink Web), a także odpowiednie wykonaną konfiguracje ewentualnych wirtualnych sieci prywatnych, może zapewnić duży stopień ochrony sieci LAN, jeżeli chodzi o ataki z zewnątrz, pomijając oczywiście przypadki ataków backdoor, które są podejmowane pomijając wejście główne, czyli przykładowo router. 

Aby urządzenie zostało prawidłowo zabezpieczone, należy także regularnie aktualizować firmware routera, czyli jego oprogramowanie wewnętrzne, które bardzo często jest dopasowaną do potrzeb urządzenia mini-dystrybucją systemu operacyjnego Linux. Oprogramowanie routera należy pobrać ze strony producenta i wczytać do urządzenia pobrany plik poprzez uruchomienie funkcji aktualizacji oprogramowania. Na rynku są też routery, które same ściągają oraz instalują aktualizację oprogramowania. W takim przypadku zalecane jest jednak wyłączenie takiej opcji ze względów bezpieczeństwa.

Kolejnym krokiem w drodze do prawidłowego zabezpieczenia sieci LAN jest wyłączenie obsługi protokołu SNMP na wszelkich sieciowych urządzeniach, które oferują możliwość jego implementacji. Zasadniczo protokół ten stosowany jest do monitorowania statusu urządzeń, a nieraz do podstawowej, bardzo ograniczonej komunikacji pomiędzy urządzeniami sieciowymi. Protokół SNMP obsługiwany jest przeważnie przez routery, przełączniki zarządzalne, moduły komunikacyjne dużych zasilaczy UPS. Protokół ten jest poważną luką w zabezpieczeniach całej infrastruktury informatycznej ponieważ, w przypadku nieprawidłowego zablokowania całego ruchu SNMP w sieci, wszelkie dane dotyczące statusu urządzeń sieciowych, w tym często informacje o modelu urządzenia oraz o zainstalowanej wersji oprogramowania firmware, które są udostępniane za pomocą protokołu SNMP, mogą zostać odczytane przez nieautoryzowane osoby. Niewystarczające okazuje się zabezpieczenie na poziomie ACL. Jedynym rozsądnym rozwiązaniem staje się rezygnacja z obsługi SNMP w całej sieci LAN. Bardzo ważne, oprócz wyłączenia obsługi protokołu SNMP na poszczególnych urządzeniach wewnątrz sieci LAN, jest całkowite zablokowanie ruchu SNMP na wszelkich zaporach sieciowych, szczególnie na zaporach routerów.

Apache + SSL krok po kroku

Transmisja danych w internecie nie jest domyślnie szyfrowana, co oznacza, że za pomocą bardzo prostych narzędzi można odczytać większość informacji przepływających przez ocean sieci. Posiadając minimalną wiedzę na temat protokołów sieciowych oraz podstaw transmisji danych można dowiedzieć się na przykład kto wysyła lub otrzymuje jakie informacje, pod warunkiem, że informacje te właśnie nie są zabezpieczone. Nie rzadko więc zachodzi potrzeba zabezpieczenia transmitowanych informacji, szczególnie gdy dotyczą one wrażliwych danych osobowych, haseł, numerów kont czy numerów kart płatniczych bądź kart kredytowych. Przeważnie tylko tego typu informacje są szyfrowane, ponieważ sam proces szyfrowania zużywa dodatkowe zasoby.

W niniejszym artykule ustanowienie bezpiecznej transmisji danych pomiędzy przeglądarką www, a serwerem. Do zabezpieczenia informacji transmitowanych pomiędzy przeglądarką internetową a serwerem www służą protokoły SSL (Secure Socket Layer) oraz HTTPS (Hypertext Transfer Protocol Secure), który stanowi szyfrowaną (za pomocą SSL) odmianę protokołu HTTP. Omówimy najprostszy sposób uruchomienia bezpiecznego połączenia wykorzystującego protokoły SSL + HTTPS na serwerem Apache działającym w środowisku Linux.
Do ustanowienia zabezpieczonego połączenia HTTPS wykorzystuje się protokół SSL, który jest najczęściej kojarzony właśnie z protokołem HTTP, ale może służyć do zabezpieczania także innych protokołów, np. SMTP lub IMAP. Ale jak się ma SSL do HTTPS? SSL działa w warstwie prezentacji, więc może służyć do zabezpieczania protokołów działających w warstwie aplikacji, która znajduje się wyżej, takich jak protokół HTTP.
Do ustanowienia prawidłowego i w pełni funkcjonalnego połączenia SSL pomiędzy serwerem www, a przeglądarką internetową konieczny jest podpisany certyfikat SSL. Certyfikaty SSL umożliwiają weryfikację serwera, dla którego domeny zostały wystawione. Osoby odwiedzające witrynę www, odczytując informacje zawarte w certyfikacie SSL, mogą dowiedzieć się, przykładowo, kto jest właścicielem certyfikowanej domeny lub kto wystawił dany certyfikat. Ponieważ jednak wystawienie certyfikatu SSL nie jest zadaniem niezmiernie trudnym i może ono zostać wykonane przez każdego, zostały utworzone specjalne zaufane Urzędy Certyfikacji, weryfikujące dane podmiotów ubiegających się o certyfikat SSL. W przypadku próby ustanowienia połączenia SSL z serwerem, którego certyfikat nie został podpisany przez zaufany Urząd Certyfikacji, w przeglądarce internetowej pojawia się bardzo wyraźne ostrzeżenie dotyczące tego faktu, aby ostrzec internautów przez potencjalnymi zagrożeniami. Zaufane Urzędy certyfikacji, czyli w praktyce podmioty świadczące usługi certyfikacyjne, oferują różnego rodzaju certyfikaty SSL. Ich możliwości i ceny są bardzo zróżnicowane, w zależności od przeznaczenia certyfikatu.
Ponieważ osobom nieoswojonym z tematem procedura ustanowienia połączenia zabezpieczonego protokołem SSL (HTTPS), może wydawać się skomplikowana, choć w rzeczywistości tak nie jest, podzielimy ją tutaj na poszczególne kroki aby ułatwić zrozumienie.

KROK I - CSR (Certificate Signing Request)

Aby wystąpić do podmiotu świadczącego usługi certyfikacyjne o wydanie wybranego certyfikatu SSL należy utworzyć plik zawierający wniosek o podpisanie certyfikatu (CSR – Certificate Signing Request). W celu utworzenia pliku CSR można skorzystać z narzędzi z pakietu OpenSSL. Opiszemy tutaj jak utworzyć plik CSR korzystając z pakietu OpenSSL z wiersza poleceń systemu operacyjnego Linux.
Aby rozpocząć procedurę tworzenia pliku CSR należy się upewnić, że pakiet OpenSSL jest prawidłowo zainstalowany. Przykładowo w systemach Linux z dystrybucji Red Had Linux, Fedora, Scientific Linux bądź CentOS, można to w prosty sposób sprawdzić przy pomocy narzędzia yum:

[root@server_1 ~]# yum info intalled openssl

W przypadku odnalezienia przez narzędzie yum zainstalowanego pakietu OpenSSL, po zatwierdzeniu powyższego polecenia, wyświetlane są informacje o zainstalowanym pakiecie. Przykładowo:

Name : openssl
Arch : i686
Version : 0.9.8n
Release : 2.fc11
Size : 1.4 M
Repo : updates
Summary : A general purpose cryptography library with TLS implementation
URL : http://www.openssl.org/
License : OpenSSL
Description : The OpenSSL toolkit provides support for secure communications
W przypadku nie odnalezienia zainstalowanego pakietu OpenSSL, przed kontynuowaniem należy takowy zainstalować. Przykładowo w systemach z dystrybucji Red Had Linux, Fedora, Scientific Linux bądź CentOS można to zrobić wprowadzając w wierszu poleceń następujące polecenie:

[root@server_1 ~]# yum install openssl

Zakładając, że pakiet openssl jest prawidłowo zainstalowany, w celu utworzenia pliku CSR należy z wiersza poleceń wydać następujące polecenie (nazwę domeny w poleceniu można zastąpić nazwą własnej domeny, dla której ma zostać podpisany certyfikat SSL, ale nie jest to absolutnie konieczne):

[root@server_1 ~]# openssl req -nodes -newkey rsa:2048 -keyout nazwa_domeny.key -out nazwa_domeny.csr

Po zatwierdzeniu powyższego polecenia zostaje uruchomiona interaktywna aplikacja, która generuje plik CSR, po udzieleniu przez użytkownika odpowiedzi na wyświetlane pytania.

Generating a 2048 bit RSA private key
....................+++
.............+++
writing new private key to nazwa_domeny.key
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter . the field will be left blank.
-----
Country Name (2 letter code) [GB]:PL
State or Province Name (full name) [Berkshire]:Mazowieckie
Locality Name (eg, city) [Newbury]:Warszawa
Organization Name (eg, company) [My Company Ltd]:Moja firma
Organizational Unit Name (eg, section) []:Centrala
Common Name (eg, your name or your servers hostname) []:www.nazwadomeny.pl
Email Address []: przykladowyadres@przyklad.pl

Uwaga! Common Name odnosi się do domeny, dla której ma zostać wystawiony certyfikat!
Na samym końcu pojawiają się pytania dotyczące opcjonalnych cech certyfikatu, takich jak hasło zabezpieczające certyfikat. Na pytanie dotyczące opcjonalnego hasła do certyfikatu należy koniecznie odpowiedzieć wciskając sam klawisz ENTER, bez wprowadzania jakichkolwiek znaków (nawet samym spacji).

Po wprowadzeniu przez użytkownika niezbędnych informacji zostają utworzone 2 pliki w katalogu, w którym została wywołana aplikacja do generowania pliku CSR.
Utworzone pliki to

nazwa_domeny.csr
nazwa_domeny.key

Pierwszy z pików, nazwa_domeny.csr, należy dostarczyć do podmiotu, który wystawia i podpisuje certyfikat SSL. Podmiot świadczący usługi certyfikacyjne wystawia i podpisuje certyfikat SSL właśnie na podstawie otrzymanego pliku CSR.
Drugi z plików, nazwa_domeny.key, będzie potrzebny do prawidłowego funkcjonowania otrzymanego certyfikatu SSL. Plik ten zawiera bowiem prywatny klucz certyfikatu, który jest niezbędny do uruchomienia podpisanego certyfikatu SSL.

Przed przejściem do instalacji na serwerze certyfikatu SSL, koniecznie należy wkleić do otrzymanego certyfikatu SSL informacje o ścieżce certyfikacyjnej do podpisanego certyfikatu SSL i zachować edytowany w ten sposób plik zawierający certyfikat SSL oraz wklejone informacje o ścieżce certyfikacyjnej. Informację o tym, jak należy to zrobić można zawsze uzyskać od podmiotu podpisującego certyfikat SSL. Generalnie procedura jest bardzo prosta i polega na połączeniu, w odpowiedni sposób, zawartości 2 plików. Plik zawierający ścieżkę certyfikacyjną otrzymujemy od wystawcy certyfikatu SSL.

KROK II – Proste operacje na plikach

Przed rozpoczęciem procedury instalacji certyfikatu, która polega na umieszczeniu plików zawierających certyfikat SSL oraz prywatny klucz certyfikatu w odpowiednich katalogach, jak również na lekkim dopasowaniu plików konfiguracyjnych Apache do nowych okoliczności, należy się upewnić, czy obecna instalacja serwera Apache jest odpowiednio skonfigurowana do obsługi protokołu SSL.
Serwer Apache może zostać skonfigurowany do obsługi protokołu SSL na kilka sposobów. Omówimy tutaj wyłącznie instalację oprogramowania obsługującego protokół SSL w postaci modułu serwera Apache, za pomocą narzędzia yum.
Aby sprawdzić, czy moduł jest już zainstalowany należy postępować jak poniżej.

[root@server_1 ~]# yum info installed mod_ssl

W przypadku odnalezienia zainstalowanego pakietu, pojawia się informacja podobna do:

Installed Packages
Name : mod_ssl
Arch : x86_64
Epoch : 1
Version : 2.2.3
Release : 76.el5.centos
Size : 183 k
Repo : installed
Summary : SSL/TLS module for the Apache HTTP server
URL : http://httpd.apache.org/
License : Apache Software License
Description : The mod_ssl module provides strong cryptography for the Apache Web
: server via the Secure Sockets Layer (SSL) and Transport Layer
: Security (TLS) protocols.

Jeżeli pakiet nie jest zainstalowany, należy go zainstalować poprzez wydanie polecenia:

[root@server_1 ~]# yum install mod_ssl

Następny krok polega na umieszczeniu w odpowiednich katalogach otrzymanego pliku, zawierającego podpisany certyfikat SSL, oraz pliku zawierającego klucz prywatny.

Plik zawierający podpisany certyfikat SSL należy umieścić w katalogu
/etc/pki/tls/certs/
, więc ścieżka do pliku powinna wyglądać następująco:

/etc/pki/tls/certs/nazwa_domeny.crt

Plik z kluczem prywatnym, utworzony w chwili wygenerowania pliku CSR należy umieścić w katalogu
/etc/pki/tls/private/
, a ścieżka do niego ma wyglądać tak:

/etc/pki/tls/private/nazwa_domeny.key

Uprawnienia do pliku z podpisanym certyfikatem SSL mogą być ustawione następująco:

-rw-r--r-- 1 root root 1688 Apr 17 14:34 nazwa_domeny.crt

Uprawnienia do pliku z kluczem prywatnym powinny być nieco bardziej restrykcyjne:

-rw------- 1 root root 1679 Apr 17 11:26 nazwa_domeny.key

KROK III – Dopasowanie konfiguracji oraz ponownie uruchomienie serwera Apache

Należy teraz edytować zawartość pliku konfiguracyjnego serwera Apache, dotyczącego ustawień SSL. Plik, którego zawartość wymaga dopasowania to

/etc/httpd/conf.d/ssl.conf

W pliku ssl.conf należy znaleźć wiersz zawierający określenie 'SSLCertificateFile', który odzwierciedla ścieżkę do pliku zawierającego podpisany certyfikat SSL + informacje o łańcuchu certyfikacyjnym. Zawartość całego wiersza powinna zostać edytowana do następującej postaci:

SSLCertificateFile /etc/pki/tls/certs/nazwa_domeny.crt

Kolejną czynnością jest znalezienie w pliku ssl.conf wiersza zawierającego określenie
'SSLCertificateKeyFile'
, odnoszące się do pliku zawierającego prywatny klucz certyfikatu SSL. Wiersz powinien zostać edytowany do postaci:

SSLCertificateKeyFile /etc/pki/tls/private/nazwa_domeny.key

Po zapisaniu zmian należy ponownie uruchomić Serwer Apache:

[root@server_1 ~]# service httpd restart

To wszystko. Połączenie SSL powinno teraz prawidłowo działać. Można to w prosty sposób sprawdzić, wpisując w pasku adresów przeglądarki www adres zabezpieczonego połączenia z witryną www, dla której został wydany i zainstalowany certyfikat SSL.

Mam nadzieję, że o niczym niezbędnym dla ustanowienia bezpiecznego połączenia SSL nie zapomniałem, choć wiele przydatnych ustawień zostało przeze mnie celowo pominiętych, takich jak np. wirtualne hosty Apache, bądź zmiany ustawień firewalla.

sobota, 29 listopada 2014

Kopia zapasowa bazy danych MySQL + zaszyfrowanie pliku + email


Wstęp 

 

Administratorzy systemów informatycznych, a szczególnie osoby odpowiedzialne za bezpieczeństwo dużych zbiorów danych dobrze wiedzą jak ważne jest prawidłowe planowanie i automatyczne wykonywanie zrzutów baz danych oraz w pełni zdają sobie sprawę z konieczności bezpiecznego przechowywania plików z kopiami zapasowymi, tak aby ich zawartość nie mogła się dostać w niepowołane ręce. Było by pięknie gdyby powyższe stwierdzenie pokrywało się z rzeczywistością, ale niestety, nie zawsze tak jest, a w wielu przypadkach, przynajmniej aż do momentu pierwszej utraty ważnych zbiorów danych. Dopiero po fakcie wiele administratorów danych uświadamia sobie jak ogromną wagę ma regularne wykonywanie kopii zapasowych.

Podstawowe zasady dotyczące bezpieczęństwa danych mówią, iż kopie zapasowe danych powinny być sporządzane w sposów zaplanowany i automatyczny, a pliki z danymi powinny być przechowywane w sposób taki, aby osoby nie uprawnione nie miały dostępu do ich zawartości.

Dziś zaprezentuję metodę umożliwiającą planowane i automatyczne wykonanie kopii zapasowej (zrzutu) bazy danych MySQL z zaszyfrowaniem wynikowego pliku kluczem kryptograficznym oraz wysłaniem zbioru danych na zewnętrzną maszynę korzystając z poczty elektronicznej. Zaszyfrowane kryptograficznie dane będą bezpieczne i nikt, poza osobą posiadającą odpowiedni klucz prywatny, konieczny do ich odszyfrowania, nie będzie miał wglądu do zbioru. Tą osobą może być także sam administrator, który automatycznie może otrzymywać zrzuty mysqldump, zaszyfrowane, na swoją domową maszynę. Pójdzmy jeszcze dalej, i wyobraźmy sobie, że zaszyfrowane pliki mogą być wysyłane na serwer poczty IMAP, z którego koszysta administrator. W takim przypadku, pliki z danymi mogą być dodatkowo archiwizowane i przechowywane na serwerze poczty, w odpowiednich katalogach IMAP, a nikt, poza osobą do tego uprawnioną nie jest w stanie rozszyfrować ich zawartości. Zaszyfrowane kluczem kryptograficznym dane, mogą być bezpiecznie przesyłanie przez internet, a nawet przechowywane na serwerach poczty IMAP w celu zapewnienia ich optymalnego sposobu przechowywania oraz pełnej dostępności w razie potrzeby.

Założenia


Niniejszy artykuł oparty jest na przykładach opracowanych i przetestowanych przeze mnie na następujących systemach:

Serwer bazy danych MySQL pracujący pod systemem operacyjnym Linux Centos 7 z zainstalowanym oprogramowaniem gpg (GnuPG) 2.0.22 - libgcrypt 1.5.3;

Domowa maszyna z systemem operacyjnym Windows 8.1 z zainstalowanym klientem pocztowym Mozilla Thunderbird w wersji anglojęzycznej.

Pojęcie kluczy kryptograficznych

 

Klucze kryptograficzne umożliwiają bezpieczną komunikację elektroniczną. Zazwyczaj generowana jest para kluczy, w skład której wchodzi klucz publiczny oraz klucz prywatny. Klucz publiczny jest udostępniany publicznie i może być porównywany z sejfem, do którego jest pakowana zawartość. Po tym, jak sejf zostaje zamknięty, tylko odpowiedni klucz prywatny może go otworzyć. Klucz prywatny, z wygenerowanej pary kluczy, jest kluczem do odszyfrowywania wiadomości zaszyfrowanych kluczem publicznym, należącym do wygenerowanej pary kluczy. Klucz prywatny powienien być należycie chroniony, a dodatkowo zabezpieczony hasłem, na przypadek gdyby miał dostać się w niepowołane ręce.

Postępowanie


Istnieje wiele odmiennych sposobów generowania kluczy kryptograficznych, jak i posługiwania się wygenerowanymi kluczami. W niniejszym artykule opiszę jedno z możliwych podejść. Aby ułatwić zrozumienie zagadnienia, para kluczy zostanie utworzona na maszynie, na której będzie odbywało się odszyfrowywanie danych. 



Krok I -Instalacja narzędzi GnuPG na maszynie Windows oraz utworzenie nowych kluczy kryptograficznych

Narzędzia cryptograficzne GnuPG umożliwiają tworzenie kluczy kryptograficznych oraz zaawansowane zarządzanie takowymi kluczami.

Pierwszą czynnością którą należy wykonać jest instalacja pakietu Gpg4Win dla systemu operacyjnego Windows. Pakiet można pobrać pod adresem http://gpg4win.org/download.html

Pakiet gpg4win umożliwia prawidłowe działanie rozszerzenia Enigmail dla klienta poczty Thunderbird.

W systemie Windows, aby ułatwić integrację kluczy cryptograficznych gpg z klientem poczty elektronicznej Thunderbird, należy zainstalować rozszerzenie Enigmail dla Thunderbird korystając z pozycji menu Thunderbird Tools->Add-ons i wybierając Extensions w lewej kolumnie menedżera dodatków. Dodatku Enigmail należy wyszukać w górnym prawym pasku wyszukiwania dodatków w menedżerze dodatków. Odnaleziony dodatek należy zainstalować korzystając w przycisku Install.

Enigmail - inatalacja
Instalacja dodatku Emigmail dla klienta poczty Thunderbird

Po prawidłowo przeprowadzonej instalacji pakietu Gpg4Win, oraz rozszerzenia Enigmail dla klienta poczty Mozilla Thunderbird, można rozpocząć tworzenie pary kluczy kryptograficznych. Należy pamiętać o tym, że klucz publiczny, który zostanie utworzony w systemie Windows będzie stosowany do szyfrowania danych w systemie Linux, a klucz prywatny, który zostanie utworzony w systemie Windows, będzie stosowany do odszyfrowywania załączników mailowych w kliencie poczty Mozilla Thunderbird. Należy również pamiętać o tym, że klucze prywatne muszą być przechowywane w sposób taki, aby nikt nie miał do nich dostępu, oprócz ich właściciela.


Aby zarządzać istniejącymi kluczami kryprograficznymi, lub utworzyć nową parę kluczy kryptograficznych w systemie Windows, należy uruchomić narzędzie Enigmail Key Management poprzez wybór pozycji Enigmail->Key Management z głównego menu klienta pocztowego Thunderbird.  W celu utworzenia nowych kluczy kryptograficznych można również skorzystać z narzędzia Enigmail Setup Wizard, lecz tutaj opiszę wyłącznie metodę z zastosowaniem Enigmail Key Management.

Enigmail - zarządzanie kluczami
Uruchomienie narzędzia Enigmail Key Management z programu Thunderbird

Należy wygenerować nową parę kluczy kryptograficznych wybierając Generate->New Key Pair z menu Enigmail Key Management Tool.


Enigmail - generowanie kluczy
Rozpoczęcie generowania nowej pary kluczy kryptograficznych


Klucz prywatny powinien być chroniony hasłem, które należy wprowadzić, aby rozpocząć generowanie pary kluczy. Zalecane jest zaznaczenie opcji Use generated key for the selected identity, która spowoduje przypisanie wygenerowanych kluczy kryptograficznych do wybranej tożsamości programu Thunderbird.


Klucze kryptograficzne OpenPGP - Enigmail
Generowanie kluczy kryptograficznych OpenPGP

Po zatwierdzeniu procesu przyciskiem Generate key, generowanie kluczy kryptograficznych może trochę potrwać. W trakcie procedury tworzenia kluczy pojawia się możliwość wygenerowania i zapisania certyfikatu odwołującego klucz publiczny. Zalecane jest utworzenie i zapisanie w bezpiecznym miejscu takiego certyfikatu. Certyfikat odwołujący klucz publiczny będzie mógł zostać zastosowany w przypadku, gdy nie będziemy już mieli zamiaru korzystać z klucza publicznego, który zdążyliśmy jednak już wysłać do korzystających z niego osób.

Krok II - Eksportowanie klucza publicznego z Enigmail oraz importowanie klucza w systemie Linux

Po wygenerowaniu pary kluczy, należy eksportować z programu Enigmail utworzony klucz publiczny, ponieważ będzie on potrzebny do szyfrowania przesyłanych danych z systemu Linux. Klucz publiczny należy eksportować korzystając z pozycji File->Export Keys to File narzędzia Enigmail Key Management, po uprzednim utworzeniu pary kluczy. Dla celów niniejszego artykułu należy wyeksportować wyłącznie klucz publiczny, wybierając opcję Export Public Keys Only. Druga opcja, która pojawia się przy eksporcie kluczy do pliku, daje możliwość eksportowania również klucza prywatnego. Dobrą praktyką jest eksportowanie klucza prywatnego wraz z publicznym i zachowanie pliku z kluczem prywatnym w bezpiecznym miejscu.

Eksportowanie klucza publicznego
Eksportowanie klucza publicznego OpenPGP


Klucz publiczny może również zostać wysłany pocztą elektroniczną do wybranego odbiorcy, korzystając z odpowiedniej pozycji powyżej przedstawionej listy wyboru.
Dla celów opisanych w niniejszym artykule ważne jest, aby plik z kluczem publicznym, wygenerowany programem Enigmail został przeniesiony do systemu Linux, tak aby mógł zostać tam zaimportowany do listy kluczy publicznych w oprogramowaniu GnuPG systemu Linux.

W systemie Linux, po skopiowaniu pliku z wygenerowanym w systemie Windows kluczem publicznym do wybranego katalogu, należy zaimportować klucz publiczny w następujący sposób:

[root@myserver]# gpg --import plik-z-kluczem-publicznym.asc
gpg: key AXA1ZX: public key "Jan Kowalski <j.kowalski@kowalski.pl>" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)

Po zaimportowaniu pliku z kluczem publicznym należy przejść do edytowania zaimportowanego klucza publicznego oraz przypisania do klucza najwyższego poziomu zaufania. Jest to ważne, aby uniknąć konieczności ręcznego potwierdzania procesu szyfrowania z zastosowaniem tego klucza. Dobrą praktyką jest także sprawdzenie czy odciski kluczy (fingerprint) zgadzają się na obu systemach.

Aby sprawdić, czy klucz został prawidłowo zaimportowany do listy kluczy, wystarczy wydać komendę gpg --list-keys. Klucz publiczny j.kowalski@kowalski.pl powinien widnieć w spisie kluczy publicznych.

Aby edytować zaimportowany klucz publiczny należy wydać komendę gpg z odpowiedną opcją:

[root@myserver]# gpg --edit-key j.kowalski@kowalski.pl
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.

pub  xxxxxxxxx  created: 2014-11-29  expires: never       usage: SCA
                     trust: unknown       validity: unknown
sub  xxxxxxxxx created: 2014-11-29  expires: never       usage: E
[ unknown] (1). Jan Kowalski <j.kowalski@kowalski.pl>


Po uruchomieniu trybu edytowania klucza publicznego, aby sprawdzić jego odcisk (fingerprint) należy użyć komendy fpr pozostając w trybie edytowania:

gpg> fpr
pub   xxxxxxxxx 2014-11-29 Jan Kowalski <j.kowalski@kowalski.pl>
Primary key fingerprint: 8SSC 4220 3AAA 8A3A 00A1  6D06 8E52 81E1 B041 3D75

Aby ustawić odpowiedni poziom zaufania dla zaimportowanego klucza publicznego należy wydać komendę trust pozostając w trybie edytowania klucza:

gpg> trust
pub  xxxxxxxxx  created: 2014-11-29  expires: never       usage: SCA
                     trust: unknown       validity: unknown
sub  xxxxxxxxx created: 2014-11-29  expires: never       usage: E
[ unknown] (1). Jan Kowalski <j.kowalski@kowalski.pl>

Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)

  1 = I don't know or won't say
  2 = I do NOT trust
  3 = I trust marginally
  4 = I trust fully
  5 = I trust ultimately
  m = back to the main menu

Your decision? 5
Do you really want to set this key to ultimate trust? (y/N) y

pub  xxxxxxxxx  created: 2014-11-29  expires: never       usage: SCA
                     trust: unknown       validity: unknown
sub  xxxxxxxxx created: 2014-11-29  expires: never       usage: E
[ unknown] (1). Jan Kowalski <j.kowalski@kowalski.pl>

Please note that the shown key validity is not necessarily correct
unless you restart the program.

Po wyznaczeniu najwyszego poziomu zaufania dla klucza, należy wyjść z trybu edytowania wprowadzając komendę quit.

Na tym etapie kryptograficzny klucz publiczny, który został utworzony przy pomocy oprogramowania Enigmail w środowisku Windows, znajduje się na liście kluczy publicznych oprogramowania GnuPG na serwerze Linux, posiada najwyższy poziom zaufania i może być śmiało stosowany do szyfrowania wiadomości wysyłanych do posiadacza opdowiedniego klucza prywatnego, bez konieczności ręcznego zatwierdzania procesu szyfrowania. Zaszyfrowane załączniki wiadomości, przy pomocy takiego klucza publicznego, będą mogły zostać odszyfrowane wyłącznie poprzez osobę posiadającą opdowiedni klucz prywatny, należący do wygenerowanej pary kluczy, oraz znającą hasło do klucza prywatnego.

Krok III - sprawdzenie czy wszystko działa

W tym momencie warto sprawdzić czy można bezproblemowo szyfrować pliki korzystając z uprzednio zaimportowanego oraz edytowanego klucza publicznego. Najprostszym sposobem na przeprowadzenie takiego testu może być wykonanie następujących czynności:


[root@myserver]# echo "jakiś tekst" > doc.txt
[root@myserver]# gpg --output doc.gpg --encrypt --recipient j.kowalski@kowalski.pl doc.txt
[root@myserver]# cat doc.gpg

Tutaj powinna pojawić się zaszyfrowana zawartość pliku. Pojawienie się zaszyfrowanej zawartości oznacza, że wszystko działa jak powinno, więc można przejść do następnego kroku.

Krok IV - Automatyczna procedura zrzutu bazy danych z zaszyfrowaniem zawartości pliku kopii zapasowej oraz wysłanie pliku na domową maszynę z systemem Windows 8.1

Opisana przeze mnie procedura tworzenia kopii zapasowej bazy danych MySQL opiera się na narzędziu mysqldump, które generuje zrzut danych, w określony przez użytkownika sposób. Należy pamiętać, że aby wykonać zrzut bazy danych MySQL należy mieć do tego odpowiednie uprawnienia.
W tym przykładzie zakładam, że użytkownikiem MySQL, który wykonuje zrzut jest sam root.

Należy utworzyć odpowiedni skrypt, odpowiedzialny za wykonywanie całej procedury, a następnie dodać odpowiedni wpis do crontab'a w cely totalnej automatyzacji.

Poniższy skrypt, opracowany przeze mnie jako prosty przykład, może być podstawą do dalszej rozbudowy, wegług potrzeb. Skrypt wywołuje procedurę generowania zrzutu wszystkich baz danych MySQL obecnych na serwerze, uruchamia gpg w celu zaszyfrowania danych kopii zapasowej
oraz powoduje wysłanie pocztą elektroniczną zaszyfrowanego kluczem publicznym załącznika do ustalonego odbiorcy. Skrypt, z uprawnieniami 700 [-rwx------], powinien być umieszczony w katalogu użytkownika, do którego pliku crontab zostanie przypisane zadanie w celu jego automatyzacji.
 
#!/bin/bash
# Set variables.
#
#                      Uwaga!
#                      EMAIL_FROM, EMAIL_TO oraz GPG_RECIPIENT
#                      zależy ustawić wg. własnych potrzeb
#                 
#
#
EMAIL_FROM="root@myserver.exampledomain.com"
EMAIL_TO="j.kowalski@kowalski.pl"
EMAIL_SUBJECT="MySQL-data-dump"
DATETIME=`date +%d-%m-%Y-%H.%M.%S`
BASE_FILENAME="mysqldump"_$DATETIME
GPG_RECIPIENT="j.kowalski@kowalski.pl"
# Dump tables
echo "Dumping tables...";
# uwaga: mojehasło należy zastąpić prawdziwym hasłem MySQL użytkownika --user !!!
mysqldump -c ---user=root --all-databases --password=mojehasło > $BASE_FILENAME.sql
#If file exists and is not zero then encrypt the file
 if [ -e $BASE_FILENAME.sql ] && [ -s $BASE_FILENAME.sql ]; then
  echo "OK!\n";
  echo "Encrypting dumped data with recipient's public key...";
  gpg --output $BASE_FILENAME.gpg --encrypt --recipient $GPG_RECIPIENT  $BASE_FILENAME.sql;
#If encrypted file exists and is not zero then send file as email attachement
  if [ -e $BASE_FILENAME.gpg ] && [ -s $BASE_FILENAME.gpg ]; then
   echo "OK!\n";
   echo "Sending encrypted data to "$EMAIL_TO"...";
   echo $DATETIME | mailx -r $EMAIL_FROM -s $EMAIL_SUBJECT -a $BASE_FILENAME.gpg $EMAIL_TO
   echo "OK!";
  else
   echo "\n\nMySQL tables content could not have been encrypted..." | mailx -r $EMAIL_FROM -s $EMAIL_SUBJECT $EMAIL_TO;
  fi
 else
  echo "\n\nMySQL tables could not have been dumped..." | mailx -r $EMAIL_FROM -s $EMAIL_SUBJECT $EMAIL_TO;
 fi

Zakładając, że skrypt zawarty jest w pliku /root/daily_mysqldump, aby zautomatyzować wykonywanie kopii zapasowych bazy danych należy edytować crontab wybranego użytkownika dodając, przykładowo, następujący wpis:

20      22      *       *       * /root/daily_mysqldump

Powyższy wpis do crontaba powoduje codzienne wykonanie zadania, o godzinie 22.20.

Krok V  - Odszyfrowywanie

Aby sprawdzić czy wszystko działa prawidłowo, można wykonać skrypt daily_mysqldump ręcznie. Jeżeli wszystko zostało skonfigurowane poprawnie, w skutek uruchomienia skryptu zaszyfrowany załącznik z kopią zapasową bazy danych powinien zostać wysłany na wskazany w skrypcie adres poczty elektronicznej. Na maszynie z systemem operacyjnym Windows 8.1 należy odebrać zaszyfrowany załącznik za pomocą klienta poczty Thunderbird, ze wczesniej skonfigurowanymi opcjami Enigmail. Po kliknięciu w załącznik powinna pojawić się prośba o wprowadzenie hasła kryptograficznego klucza prywatnego. Po wprowadzeniu hasła klucza prywatnego, należącego do uprzednio wygenerowanej pary kluczy, powinno być możliwe odczytanie odszyfrowanej zawartości załącznika, zawierającego kopię zapasową bazy danych.

W przypadku jakichkolwiek niejasności proszę o komentarze. Służę pomocą.