Czytając sobie artykuł na temat TORyfikacji zapytań do serwerów kluczy GPG, pomyślałem, że w sumie mógłbym zreprodukować przedstawione tam kroki dotyczące implementacji tego rozwiązania na windowsie i wdrożyć je na linux'ie. Chodzi generalnie o to, by serwer kluczy GPG nie był odpytywany bezpośrednio przy szukaniu/przesyłaniu kluczy przez sieć, bo to może identyfikować nas, jak i grupę ludzi, która się z nami komunikuje. Jakby nie patrzeć, klucze GPG składają się z dość newralgicznych informacji, typu imię, nazwisko czy adres email, a serwer kluczy GPG tych danych w żaden sposób nie zabezpiecza i są one zwykle przesyłane otwartym tekstem przez sieć.

Poniższy wpis ma na celu stworzenie infrastruktury WiFi w oparciu o oprogramowanie freeradius zainstalowane na debianowym serwerze. Projekt zakłada wykorzystanie osobnego urządzenia NAS (AP), w tym przypadku jest to router TP-Link TL-WR1043N/ND v2, na którym jest zainstalowane oprogramowanie OpenWRT. W oparciu o te dwie maszyny spróbujemy skonfigurować protokół WPA2 Enterprise z obsługą trzech metod uwierzytelniania, tj. EAP-TLS, EAP-TTLS oraz PEAP (v0) . Będziemy również potrzebować kilku certyfikatów (w tym CA), bez których to pewne mechanizmy mogą nie działać.

Jakiś czas temu przedstawiłem manualny sposób na generowanie certyfikatów, które można z powodzeniem wykorzystać przy ssl, openvpn czy freeradius. Nie było tego znowu aż tak dużo ale jakby nie patrzeć trochę parametrów trzeba znać, a najlepiej mieć przygotowane odpowiednie linijki, by sam proces generowania certyfikatów przebiegł dość sprawnie. Jednak wychodzi na to, że nie trzeba się znowu aż tak wysilać, bo istnieją dedykowane narzędzia, które wygenerują nam wszystkie potrzebne pliki. Mowa o easy-rsa i to niego będzie dotyczył ten wpis.

Jakiś czas temu, na forum DUG'a wyczytałem coś o przesyłaniu logów systemowych przez sieć. W sumie, to nigdy mi to do głowy nie przyszło ale jeśli by się nad tym głębiej zastanowić, tego typu mechanizm może okazać się całkiem użyteczny. Na dobrą sprawę nie wiem jak to jest rozwiązane w debianie opartym o systemd, natomiast jeśli chodzi o inne init'y (openrc i sysvinit), to tego typu funkcjonalność można zaimplementować wykorzystując narzędzie rsyslog lub syslog-ng . W tym wpisie zostanie opisana konfiguracja debianowego serwera, na którym będzie nasłuchiwał daemon rsyslog . Dodatkowo, zostanie przedstawiona konfiguracja dwóch klientów, z których jeden będzie miał zainstalowanego syslog-ng , a drugi rsyslog . Z klientów logi zostaną przesłane do serwera. Dodatkowo, postaramy się zaszyfrować ruch przy pomocy kanału TLS.

Certyfikaty mogą zostać wykorzystane wszędzie tam, gdzie mamy do czynienia z protokołami szyfrującymi ruch. Zwykle są to serwisy hostujące strony www ale też mogą to być i inne usługi, np. OpenVPN. Można je także spotkać w sieciach bezprzewodowych gdzie wykorzystywany jest protokół WPA2-Enterprise. Jeśli operujemy na linux'ie, to prawdopodobnie spotkaliśmy się już z oprogramowaniem, które wykorzystuje certyfikaty, np. serwer apache2 . Dobrze jest sobie zatem przyswoić wiedzę na temat generowania certyfikatów.

Dnia 2014-10-07 w Debianie była aktualizacja pakietu encfs , która to zawierała informację na temat audytu bezpieczeństwa jaki się dokonał parę miesięcy wstecz. Wyniki niezbyt dobrze wypadły, a nawet można powiedzieć, że wręcz katastrofalnie. Generalnie cały test został skwitowany słowami, że jeśli szyfrujemy pliki przy pomocy tego narzędzia, to jesteśmy relatywnie bezpieczni, nawet w przypadku jeśli ktoś te pliki przechwyci. Natomiast jeśli zaczniemy zmieniać/dodawać pliki i ten ktoś ponownie przechwyci nasz zaszyfrowany katalog, wtedy może on bez problemu odszyfrować całą jego zawartość. Jeśli wykorzystujemy encfs lokalnie, to być może nam nic nie grozi, nawet w przypadku raidu NSA na naszą chałupę. Problem w tym, że ogromna rzesza ludzi wykorzystuje encfs do zaszyfrowania plików w chmurze, np. na Dropbox'ie czy MEGA, a jak wiadomo, przy każdej synchronizacji, zmiany w danym katalogu są przesyłane do chmury i wszelkie zabezpieczenie jakie daje encfs diabli biorą. Może najwyższy czas zainteresować się ecryptfs?

W dobie NSA, podsłuchów rządowych i wszelkiego rodzaju pogwałcenia prawa do prywatności, ludzie wymyślili VPN. VPN to nic innego jak tunel łączący dwie odległe od siebie maszyny, które chcą wymieniać ze sobą dane w sposób uniemożliwiający osobom trzecim podejrzenie całej tej komunikacji. Zalety korzystania z takiego dobrodziejstwa natury są oczywiste. Można obejść cenzorów, gdyż cały ruch z naszej maszyny jest przesyłany do serwera w postaci szyfrowanej, a dopiero z tego serwera sygnał idzie dalej w świat. Jest wiele komercyjnych usług, które za drobną opłatą mogą zapewnić nam tego tupu usługi ale ja nie będę tutaj się o nich rozpisywał. Bez problemu można je znaleźć w góglu. My tutaj za to zajmiemy się VPN jaki zapewnia riseup. By móc korzystać z ich usług, trzeba założyć na ich stronie konto, a to z kolei jest przyznawane tym, którzy w jakiś sposób działają na rzecz szeroko pojętej wolności. Ja wysłałem zgłoszenie i konto zostało mi przyznane. Dlatego też opiszę jak wygląda konfiguracja VPN na ich przykładzie.

Szyfrowanie wiadomości email można uznać za paranoiczne podejście do kwestii wymiany informacji, bo zwykły człowiek mówi sobie: "ja przecie za pomocą poczty nie wysyłam nic ważnego, nawet swoich nagich fotek, a nawet jeśli już, to są one od pasa w dół. Poza tym, gmail jest szyfrowany, bo używa SSL/TLS". SSL/TLS, co prawda, jest ale ogranicza się do szyfrowania tego co robimy na gmailu. Same wiadomości natomiast są przesyłane między różnymi serwerami i niekoniecznie są szyfrowane. Poza tym google kiedyś wspominał, że w przypadku gdy policja będzie żądała dostępu do naszej skrzynki pocztowej, to nie dość, że on im to umożliwi, to jeszcze wyciągnie wszelkie maile jakie przez tę skrzynkę zostały przepuszczone -- zarówno te odebrane jak i wysłane.

Do protokołów SSL/TLS w serwisach www chyba wszyscy już przywykli. Obecnie praktycznie na każdej stronie, gdzie jest okienko logowania, mamy do czynienia z szyfrowaniem danych przesyłanych w różnego rodzaju formularzach. Co prawda, klucze nie są zbyt długie (512-2048 bitów) ale zawsze to lepsze niż nic. O ile dane służące do logowania czy też wszelkie operacje dokonywane w panelach administracyjnych da radę ukryć bez większego problemu, o tyle zapytania DNS są przesyłane otwartym tekstem i każdy może je sobie podejrzeć. Pytanie tylko, po co szyfrować ruch DNS? Czy są tam przesyłane jakieś ważne informacje? Jeśli przyjrzymy się jak działa system DNS, możemy dojść do wniosku, że szyfrowanie zapytań jest pozbawione sensu, bo z reguły nazwa domeny oznacza konkretny adres IP. Znając adres IP, możemy ustalić kto na jakie strony wchodzi. Nie do końca jest to prawdą, poza tym istnieją jeszcze inne czynniki, które sprawiają, że ukrycie zapytań DNS ma jak najbardziej sens. W tym wpisie zaimplementujemy sobie na naszych linux'ach szyfrowanie zapytań DNS przy wykorzystaniu narzędzia dnscrypt-proxy.

W poprzednim wpisie przygotowywaliśmy sobie plik gpg.conf. Opcje w nim ustawione są niezbędne do wygenerowania dobrego pod względem bezpieczeństwa klucza GPG. Taki klucz GPG nie powinien być krótszy niż 4096 bitów. Dodatkowo, nie powinno się ustawiać daty ważności dłuższej niż 2 lata, a to z tego powodu, że zawszę tę datę można zmienić i to nawet w przypadku gdy klucz straci ważność. Chodzi generalnie o ustawienie jakiegoś mechanizmu zabezpieczającego na wypadek gdyby nasz klucz GPG wpadł w niepowołane ręce i stracilibyśmy nad nim panowanie. Wtedy po jakimś czasie automatycznie się on unieważni i nie będziemy musieli się martwić czy ktoś może przez przypadek go używać. Jest również szereg innych rzecz, o które powinniśmy się zatroszczyć i tej tematyce będzie poświęcony ten wpis, który w dużej mierze powstał w oparciu o te dwa linki.