Atak SYN flood to rodzaj ataku DoS, którego celem jest wyczerpanie zasobów serwera uniemożliwiając mu tym samym poprawne realizowanie danej usługi, do której został oddelegowany. Jest to dość popularne zjawisko i w przypadku, gdy mamy postawioną jakąś maszynę na publicznym adresie IP, przydałoby się nieco zainteresować tym problem, który może wystąpić w najmniej oczekiwanym momencie. W tym wpisie rzucimy okiem na mechanizm SYN cookies.

Internet nie jest zbyt przyjaznym miejscem i jest wielce prawdopodobne, że prędzej czy później ktoś zaatakuje jedną z naszych maszyn, która świadczy w nim jakieś usługi. Są różne typy ataków, w tym przypadku chodzi o ataki DDoS z wykorzystaniem pakietów wchodzących w proces potrójnego witania (three way handshake) przy nawiązywaniu połączenia w protokole TCP, tj. pakiety SYN , SYN-ACK i ACK . Istnieje szereg mechanizmów, które adresują problem SYN flooding'u ale żaden z nich nie jest doskonały. Jakiś czas temu, do kernela linux'owego trafił patch implementujący mechanizm SYNproxy i w tym wpisie obadamy go sobie nieco dokładniej.

Raczej na pewno spotkaliśmy się już z modułami kernela w linux'ie. Generalnie rzecz biorąc, taki moduł może być ładowany dynamicznie i w sporej części przypadków niezależnie, choć z zwykle jest pociągany przy zdarzeniach udev'a. Czasem jednak, dany moduł nie działa jak należy i może to być wynikiem, np. problemów w samym module, lub też jego niewłaściwej konfiguracji, która konfliktuje z podzespołami naszego komputera. Ten wpis będzie dotyczył tego jak ustalić parametry modułów i ich domyślne wartości, tak by móc je sobie zmienić w późniejszym czasie.

Jakiś czas temu opisywałem konfigurację dla menadżera pakietów apt i aptitude w pliku apt.conf. Ten wpis również tyczy się konfiguracji wspomnianych menadżerów, z tym, że zostanie tutaj opisana pewna funkcjonalność, która może nam zaoszczędzić trochę czasu przy aktualizacji systemu. Chodzi o to, że pakiety praktycznie zawsze muszą być pobrane na dysk przed ich instalacją. Gdy nie dysponujemy dobrym pod względem przepustowości łączem, proces pobierania pakietów jest zwykle dłuższy niż sama ich instalacja. Przydałoby się zatem zaprogramować pobieranie plików w tle, tak by nie musieć ich pobierać tuż przez przed procesem instalacyjnym.

Wykorzystywanie pełnego szyfrowania dysku twardego ma jedną zasadniczą wadę. O ile nasze dane są należycie zabezpieczone, o tyle trzeba zwracać uwagę na to komu zezwalamy na dostęp do naszego komputera. Nie chodzi tutaj o to, kto będzie używał samego systemu operacyjnego, choć to też jest ważne, ale przede wszystkim chodzi o te osoby, które mają dostęp fizyczny do naszej maszyny. Czasem możemy nabrać podejrzenia, że ktoś mógł nam jakąś pluskwę podłożyć. Wykrycie takiego robala, np. w postaci sprzętowego keylogger'a, nie powinno sprawić problemów. Z kolei już manipulacja boot sektorem dysku twardego, lub też zmiany w initramfs, który znajduje się na niezaszyfrowanej partycji /boot/ mogą przejść niezauważone. Jak zatem odratować system, co do którego mamy jakieś zastrzeżenia?

Linux jest w stanie operować na wielu systemach plików, np. ext4, ntfs, fat. Większość z nich odnosi się do dysków twardych, czy też innych urządzeń przechowujących spore ilości danych. Problem z tego typu systemami plików jest taki, że operacje na plikach w ich obrębie, jak i same pliki, zostawiają ślady. Dlatego też jeśli musimy tymczasowo skopiować plik zawierający tajne dane, lub też taki plik poddać obróbce, nie powinniśmy go umieszczać bezpośrednio na dysku. No chyba, że wykorzystujemy pełne szyfrowanie. Inną opcją (i o wiele prostszą w implementacji) jest przeznaczenie części pamięci operacyjnej RAM pod system plików tmpfs i o tym będzie ten wpis.

Ogarnęliśmy już szyfrowanie plików na Dropbox przy pomocy encfs oraz kontenerów TrueCrypt. Każda z w/w operacji drastycznie poprawiła prywatność naszych plików, które przechowujemy w chmurze. Poniższy wpis będzie w podobnym klimacie, tj. spróbujemy umieścić na Dropbox kontener LUKS, co niesie ze sobą sporo udogodnień i czyni korzystanie z zaszyfrowanego Dropbox'a praktycznie transparentnym.

Żyjemy w czasach, w których mobilność jest tak samo ważna albo może i ważniejsza (dla niektórych ludzi na pewno) jak i bezpieczeństwo i poufność danych. Użyteczność zwykle nie idzie w patrze z bezpieczeństwem, bo im prostszy jest dla nas dostęp do danych, tym bardziej zagraża ich bezpieczeństwu. W tym przypadku chcielibyśmy mieć możliwość dostępu do plików, np. naszego domowego PC, z dowolnego miejsca na ziemi. Czy można w prosty i w miarę bezpieczny sposób coś takiego osiągnąć? Jakiś czas temu opisywałem implementację encfs na dropbox'ie, w tym artykule zostanie zaś opisane sprzęgnięcie dropbox'a z kontenerem TrueCrypt.

Jakiś czas temu, można było usłyszeć, że TrueCrypt nie dba wcale o bezpieczeństwo danych zaszyfrowanych za jego pomocą. Audyt bezpieczeństwa jednak nie wykazał większych podatności w tym oprogramowaniu. Analiza binarek dostępnych na stronie TrueCrypt'a pod kątem Reproducible Builds również nie wykazała większych odchyłów w stosunku do binarek generowanych prosto z kodu źródłowego. Problematyczne może być jednak to, że tak naprawdę nie wiadomo kto stoi za tym całym projektem, przynajmniej gdy był jeszcze rozwijany. Cała sytuacja zamknięcia TrueCrypt'a z sieci była też co najmniej dziwna. W obliczu takich niewiadomych, powinniśmy rozważyć przejście na natywne rozwiązania linux'owe, które są jawnie rozwijane, wiadomo kto za nimi stoi i, co najważniejsze, mają wsparcie w samym kernelu.

Jako, że ostatnio zaszyfrowaliśmy katalog domowy przy pomocy encfs , to nie sposób sobie nie zadać pytania czy tego typu mechanizm może działać w oparciu o serwisy online takie jak, np. dropbox. Chodzi o to, że dropbox umożliwia synchronizację plików w czasie rzeczywistym, co może być problematyczne, gdy w grę wchodzi szyfrowanie danych. Wszelkie inne rozwiązania na bazie LUKS są mało praktyczne w tym przypadku. Natomiast synchronizowanie pojedynczych plików zaszyfrowanych przy pomocy encfs zapowiada się obiecująco.