Po wpisaniu w pasku adresu Firefox'a about:config , zostanie nam zwrócona dość długa lista parametrów konfiguracyjnych, które możemy sobie dostosować wedle uznania. Większość z nich ma spory wpływ na zachowanie samej przeglądarki ale są też i opcje, które zostały dodane za sprawą różnych dodatków. Chodzi o to, że za każdym razem gdy instalujemy nowy addon, to ten zwykle ma opcje konfiguracyjne i to właśnie one są widoczne w about:config . W przypadku gdy już nie korzystamy z tego dodatku i wyrzuciliśmy go kompletnie z Firefox'a, wpisy w konfiguracji dalej widnieją. Przydałoby się zatem nieco przeczyścić naszą przeglądarkę i usunąć te wszystkie śmieci.

Przeglądarki mają to do siebie, że każda z nich korzysta z własnych ustawień dotyczących typów MIME (mime type). Do tego dochodzi jeszcze fakt, że często te ustawienia są inne od tych, które mamy w systemie. Może to nie jest jakiś wielki problem, bo w opcjach Firefox'a możemy bez trudu szereg rzeczy poprzestawiać. Natomiast jest jeden problem, którego w prosty sposób się obejść nie da i trzeba się trochę na nim pochylić. Chodzi o dodawanie nowych typów MIME, które nie są pokazane na liście obsługiwanych typów w Preferences -> Applications. Wiąże się z tym tak skonfigurowanie przeglądarki, by automatycznie otworzyła ona jakiś program ilekroć dany typ pliku będzie pobierany.

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.