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.

Przy okazji uszczelniania serwera Apache2, przypomniał mi się atak logjam , przez który to było niemałe zamieszanie. Pamiętam, że w tamtym czasie próbowałem zabezpieczyć swój serwer testowy, by był na tę formę ataku odporny. Niemniej jednak, wersja Apache2, która w tamtym czasie była u mnie zainstalowana, nie do końca dawała taką możliwość. Dziś podszedłem do tej kwestii jeszcze raz i w oparciu o ten link udało mi się poprawnie skonfigurować mój serwer www.

Szukając co by tutaj jeszcze poprawić w moim środowisku testowym, w którym działa między innymi apache, natrafiłem na komunikat w firefoxie, który oznajmił mi, że certyfikat mojego serwera korzysta z przestarzałego już algorytmu mieszającego (hash). W tym przypadku jest to SHA-1. Jak można przeczytać na blogu mozilli, algorytm SHA-1 wypadł z łask jakiś czas temu i obecnie nie zaleca się jego używania ze względów bezpieczeństwa. Postanowiłem zatem poprawić tę lukę.

Po ostatnich doniesieniach na temat błędu jaki został znaleziony w Firefox'ie , doszedłem do wniosku, że najwyższy czas nauczyć się obsługi narzędzia AppArmor . Ma ono pomóc w kontrolowaniu praw dostępu do zasobów systemu operacyjnego, np. plików, katalogów czy określonych urządzeń. Jeśli weźmiemy przytoczony wyżej błąd, to przeglądarka bez takiego profilu AppArmor'a była w stanie przeszukać lokalne pliki i wysłać je gdzieś na net, co powodowałoby udostępnienie poufnych danych, np. historia poleceń shell'owych, czy klucze prywatne.

Prędzej czy później, każdy z nas będzie musiał zabezpieczyć dostęp do swojego komputera w sieci. Do tego zadania na stacjach z linux'em jest oddelegowane narzędzie iptables wraz z szeregiem dodatków, jak np. ipset . By zbudować solidny firewall nie potrzeba zbytnio się wysilać. Niemniej jednak, temat zapory linux'owej jest bardzo rozległy i nie będziemy tutaj opisywać wszystkich możliwych scenariuszy jej zastosowania. Zamiast tego skupimy się jedynie na bazowym skrypcie, który można rozbudować bez przeszkód i dostosować go zarówno pod maszyny klienckie jak i te serwerowe.

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?

Menadżery plików potrafią automatycznie montować nośniki wymienne w oparciu o pakiet udisks2. Potrafią także uruchamiać odpowiednie aplikacje zlokalizowane na tych urządzeniach. Może to prowadzić do oczywistych zagrożeń i jeśli nasz system ma być bezpieczny, to musimy wyłączyć obie te opcje. W różnych menadżerach plików, ten proces przebiega inaczej. Ja korzystam ze spacefm i w jego przypadku mamy dość rozbudowany mechanizm polityki dotyczącej tych dwóch powyższych kwestii. Niemniej jednak, w przypadku każdego z menadżera plików, proces postępowania powinien przebiegać mniej więcej w ten sam sposób.

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.

Każdemu z nas zdarzyło się zostawić włączoną konsolę, na której byliśmy zalogowani jako administrator systemu root. Być może nie zdajemy sobie sprawy jak często potrafimy popełnić tego typu gafę. Jedną z metod obrony jest oczywiście wyłączenie konta root w systemie i korzystanie z sudo. Ja jednak wolę inne rozwiązanie, które zakłada ograniczenie czasu bezczynności, po którym to użytkownik zostanie automatycznie wylogowany.