Dziś postanowiłem się wziąć za ostatnią kartę WiFi, którą podesłał mi TP-LINK. Jest to nano adapter Archer T1U V1 na czipie MediaTek MT7610U identyfikowany w systemie jako idVendor=2357 , idProduct=0105 . Na opakowaniu pisało, że ta karta działa na linux'ach ale oczywiście w przypadku mojego Debiana, ten adapter nie został w ogóle wykryty. Winą są zbyt stare sterowniki, które nie zostały zaktualizowane przez MediaTek od 2013 roku. TP-Link może i ma u siebie na stronie nieco nowszą wersję sterowników, bo z 2015 roku ale nie udało mi się za ich sprawą zbudować poprawnie modułu mt7610u_sta na kernelu 4.6 . Na szczęście mamy jedną alternatywę, która pomoże nam jako tako wybrnąć z tej sytuacji.

Dziś podczas przenoszenia jednej z baz danych przytrafiła mi się bardzo dziwna sytuacja. Niby wszystkie kroki zostały przeprowadzone poprawnie i nic bazie nie dolega ale jest jeden problem. Okazuje się, że po wszystkim nie sposób do tej bazy uzyskać dostęp. Tak to się już czasem zdarza, że człowiek ustawi hasło administratora bazy i po chwili je zapomni. Generalnie rzecz biorąc, to komputery za mnie mają pamiętać hasła do różnych aplikacji, w tym też i do baz danych. Ja tylko ograniczam się zawsze do kilku fraz, które odblokowują keyring. Niemniej jednak, jakimś dziwnym trafem, w tym keyring'u zabrakło hasła do tej nieszczęsnej bazy danych. Jak zatem odzyskać to zagubione hasło do bazy MySQL? Odpowiedź jest nawet bardzo prosta, o ile się posiada dostęp do użytkownika root na serwerze i na szczęście takowy posiadałem, więc w sumie nikt nic nie zauważył.

Systemy operacyjne nie są w stanie wejść w interakcję ze sprzętem, do którego nie posiadają sterowników. Linux już od dość dawna żyje sobie wśród nas i coraz bardziej pcha się na desktopy. Niemniej jednak producenci tych wszystkich urządzeń niechętnie wypuszczają sterowniki dla alternatywnych systemów. Ostatnio próbowałem uruchomić adapter TL-WN823N V2 od firmy TP-LINK. Na opakowaniu widnieje napis sugerujący, że ta karta działa pod linux'em. Rzeczywistość jednak okazała się zupełnie inna. Mianowicie, mój Debian w ogóle nie rozpoznał tej karty. Jedyne informacje jakie mi zwrócił to nazwę producenta czipu, którym okazał się być Realtek , oraz idVendor=2357 i idProduct=0109 . Sterowników dostępnych na stronie TP-LINK'a nie szło zbudować na obecnym kernelu 4.6 . Trzeba było zatem poszukać innej alternatywy. Na szczęście udało się znaleźć moduł 8192eu (rtl8192eu), który się skompilował i zainstalował bez problemu. Karta TL-WN823N V2 została wykryta i działa. W tym wpisie zostanie pokazany proces kompilacji tego modułu.

Posiadanie aktualnego systemu za sprawą regularnych aktualizacji może znacząco przyczynić się do poprawy bezpieczeństwa naszego linux'a. Niemniej jednak, niezabezpieczony proces aktualizacji może zdradzić pewne informacje, które mogą się okazać przydatne dla potencjalnego atakującego. Dlatego też menadżer pakietów apt/aptitude w Debianie wyposażony jest w dodatkowe transporty umożliwiające komunikację z serwerem repozytorium w oparciu o różne protokoły. Standardowy protokół, którym posługują się maszyny mające na pokładzie dystrybucję Debian, to HTTP (ewentualnie FTP). Oba z nich ślą wszelkie informacje w postaci czystego tekstu, który nadaje się do analizy przez człowieka. Możemy jednak skorzystać z protokołu SSL/TLS i zaszyfrować proces pobierania aktualizacji za sprawą pakietu apt-transport-https .

Debian to dość stara i rozbudowana dystrybucja linux'a, którą można spotkać praktycznie w każdym zakątku naszego globu. Dziesiątki tysięcy pakietów dostępne w oficjalnych repozytoriach tylko czekają aż je pobierzemy i zainstalujemy w swoim systemie. Problem zaczyna się jednak w momencie, gdy wielu użytkowników w tym samym czasie zaczyna pobierać pakiety i to z tego samego serwera. Wtedy aktualizacja Debiana może trwać dłużej niż zazwyczaj. By zaadresować ten problem, developerzy tej dystrybucji stawiają serwery lustrzane (mirror) w różnych częściach świata i rozładowują w ten sposób ruch, który by powędrował do głównego serwera. Spora część krajów ma kilka własnych mirror'ów ale ich jakość może czasami zostawić wiele do życzenia. Co w przypadku, gdy taki mirror, z którego my korzystamy, ulegnie awarii? Trzeba będzie poddać edycji plik /etc/apt/sources.list i zmienić adres repozytorium przez dostosowanie w nim części odpowiedzialnej za lokalizację, np. ftp.pl czy ftp.us . Istnieje jednak sposób, który dostosuje lokalizację serwera lustrzanego automatycznie, a my już nie będziemy musieli sobie głowy zawracać edycją wspomnianego wyżej pliku.

Projekt, o którym traktuje poniższy wpis, nie jest już rozwijany przez Debiana. Więcej info tutaj.

Dystrybucja linux'a Debian oferuje możliwość pobierania pakietów .deb za pomocą sieci TOR. W ten sposób jesteśmy w stanie ukryć nieco informacji na temat zainstalowanego w naszym systemie oprogramowania. Jakby nie patrzeć, aplikacje mają pełno dziur i nie wszystkie z tych programików są łatane natychmiast po opublikowaniu podatności. Z chwilą dokonywania aktualizacji systemu, potencjalny atakujący może dowiedzieć się zatem z jakich programów korzystamy, wliczając w to ich wersje. Znając te dane, można ocenić czy system posiada jakieś błędy. By zaimplementować w menadżerze pakietów apt/aptitude możliwość korzystania z sieci TOR, musimy posiadać w systemie skonfigurowanego klienta TOR oraz zainstalować pakiet apt-transport-tor . W tym artykule postaramy się skonfigurować ten cały mechanizm TOR'owych aktualizacji.

Serwery udostępniające nam różnego rodzaju strony www na protokole SSL/TLS posiadają certyfikaty, które są ważne przez pewien okres czasu. Z reguły jest to rok albo, jak w przypadku letsencrypt, są to 3 miesiące. Taki certyfikat może zostać unieważniony z różnych przyczyn ale informacja o tym fakcie musi trafić do wszystkich klientów odwiedzających taki serwis www. Do tego celu mogą posłużyć dwa mechanizmy. Pierwszym z nich są listy Certificate Revocation Lists (CRL). Drugim zaś jest Online Certificate Status Protocol (OCSP). W tym wpisie postaramy się zaimplementować to drugie rozwiązanie na serwerze Apache2.

Apache2 ma kilka ciekawych modułów, które mogą uchronić nasz serwer www przed atakami DOS i DDOS. Jednym z nich jest moduł evasive . Nie jest on jednak oficjalnym modułem i brak o nim jakiejkolwiek wzmianki w oficjalnej dokumentacji na stronie Apache2. Niemniej jednak, jest to bardzo prosty moduł składający się dosłownie z kilku dyrektyw, które są w stanie zablokować zapytania o zasoby serwera w przypadku, gdy zostanie przekroczony pewien ustalony przez nas limit. Dodatkowo, ten moduł może współgrać z filtrem iptables oraz ipset , dając nam możliwość wygodnego blokowania uporczywych klientów na poziomie pakietów sieciowych.

W stabilnej dystrybucji linux'a Debian niewiele rzeczy ulega zmianie w przeciągu roku czy dwóch lat. Dlatego też ta gałąź jest wykorzystywana głównie w przypadku serwerów, min. na tym VPS. Na co dzień jednak korzystam z Debiana SID, czyli gałęzi niestabilnej, która jest nieco bardziej aktualna i przystosowana do otaczającej nas tej wirtualnej rzeczywistości. Chodzi generalnie o nowsze oprogramowanie implementujące całą masę ficzerów, których starsze wersje nie posiadają. W tym przypadku problem dotyczy serwera Apache2, który ostatnimi czasy wypracował szereg mechanizmów obronnych adresujących ataki na protokół SSL/TLS. Jedną z podatności jest słaba liczba pierwsza wykorzystywana w protokole Diffie-Hellman'a. Ten problem można stosunkowo łatwo poprawić w nowszej wersji Apache2 wykorzystując dyrektywę SSLOpenSSLConfCmd . W starszych wersjach ona niestety nie działa. Niemniej jednak, w dalszym ciągu możemy użyć własnych parametrów dla protokołu Diffie-Hellman'a, z tym, że trzeba to zrobić nieco inaczej.

Mając serwer www oparty o oprogramowanie Apache2, w pewnym momencie zacznie nas nieco przytłaczać kwestia logowania do pliku /var/log/apache2/access.log wszystkiego co się nawinie. Jak nazwa pliku sugeruje, znajdują się w nim komunikaty, które serwer generuje ilekroć tylko ktoś odwiedzi nasz serwis. Każdy zasób przesłany do klienta, np. style CSS czy obrazki, zostanie zalogowany w powyższym pliku. Generalnie rzecz ujmując, nie musimy logować wszystkich tych informacji, chyba, że ich faktycznie potrzebujemy. Trzeba jednak wziąć pod uwagę fakt, że w przypadku obciążonych serwerów, ilość operacji I/O dysku może być znaczna. Dodatkowo, miejsce na dysku za sprawą takiego obszernego logu może bardzo szybko się wyczerpać. W tym artykule postaramy się nieco ograniczyć apetyt serwera Apache2 na logi i oduczymy go logować większość zbędnych komunikatów za sprawą dyrektywy SetEnvIf/SetEnvIFNoCase .