Linux

Ponieważ jakiś czas temu wydana została finalna wersja BackTrack 4 postanowiłem w końcu zaktualizować swoją instalację na USB. Ostatecznie doszedłem do wniosku, że pendrive o rozmiarze 4GiB to trochę za mało (obecnie już zalecane jest 8GiB), ale nie miałem innego wolnego o większej pojemności pod ręką, więc musiałem zadowolić się tym, co miałem. Dodatkowo okazało się, że wersja finalna jest nieco większa i nie mieści się na partycji przygotowanej pod wcześniejszą wersję. Nie chciało mi się bawić w partycjonowanie pendrive na nowo, więc stwierdziłem, że zainstaluję go nieco inaczej.

Pewnie już słyszeliście o problemach z PRNG w OpenSSL, które są specyficzne dla Debiana (i dystrybucji na nim opartych). Ciekawe jest jednak jak do tego doszło...

• More proof that crypto should be left to the experts,
• Vendors Are Bad For Security,

EDIT: Praktyczne wykorzystanie w odniesieniu do kluczy SSH.

...zmień parametry kernela... A poważnie - jeśli uruchomi się linuksa z kernelem 2.6 w środowisku wirtualizowanym (ja akurat mam doświadczenia w chwili obecnej z VirtualPC 2007), może okazać się, że czas pędzi jak oszalały. Wystarczy jednak zmienić algorytm wyliczania czasu stosowany przez kernel i wszystko zaczyna wyglądać sensowniej. Jest nawet artykuł w MSKB na ten temat.

Używam różnych systemów operacyjnych. Na stacjach roboczych głównie Windows XP, na serwerach Windows 2003, ale nie stronię również od Linuksa (głównie moje ulubione Gentoo) czy OpenBSD. Na desktopie nigdy nie mogłem się jednak do Linuksa przekonać, próbowałem różnych dystrybucji, ostatnio Ubuntu, przez krótki czas zainstalowanego BackTrack, ale to jakoś nie do końca mnie przekonywało. Ostatnio poświęciłem nieco czasu na zainstalowanie Gentoo na laptopie z KDE (jakoś KDE mnie bardziej pociąga niż Gnome, przynajmniej na chwilę obecną). Cóż, mam wrażenie, że system działa sprawniej niż Ubuntu, ale wszystko jeszcze przede mną... Może w końcu się do Linuksa na desktopie przekonam... Może...

Zamieniłem wcześniej opisywane IMQ na IFB. Działa to chyba lepiej, nie mam efektu zawieszenia maszyny w przypadku, gdy przez "interfejs" idzie ruch generowany lokalnie. IMQ przemawiało do mnie nieco bardziej z tego powodu, że ruch do "urządzenia" można było kierować przez reguły iptables, w przypadku IFB ruch należy kierować przez filtry tc z pakietu iproute, a ich składni nie lubię jakoś specjalnie. Na chwilę obecną filtr wygląda mniej więcej tak:

tc filter add dev eth0 parent 1: protocol ip prio 10 \ 
u32 match ip dst 0.0.0.0/0 flowid 1:1 \ 
action mirred egress redirect dev ifb1

Na interfejsie ifb1 mam normalne kolejki, które wcześniej miałem na interfejsie fizycznym (jak od strony wewnętrznej był tylko jeden). A jak to mniej więcej mam zorganizowane, przedstawiłem tutaj.

Ponieważ w ramach kombinacji moja lokalna sieć się nieco rozbudowała i moja maszynka, która robi kształtowanie ruchu dorobiła się trzeciej karty sieciowej, potrzebowałem czegoś do kształtowania ruchu na grupie interfejsów. Coś takiego oferuje IMQ. Działa to nawet dość dobrze, no może poza jednym fragmentem z FAQ:

It seems to be pretty stable, a lot of people are using it without problems. There is one case which is not entirely clear at this time, enqueueing packets going to a gre tunnel and also enqueueing the encapsulated packets to the same imq device results in the kernel assuming the gre device to be deadlooped.

Another thing to note is that touching localy generated traffic may cause problems.

...cóż, wygląda na to, że rzeczywiście próba wpuszczenia w IMQ lokalnego ruchu w końcu powoduje problemy (chyba kernel panic, ale nie chciało mi się podłączać monitora, by to zweryfikować. Przykre jest to, że według innego FAQ problem jest znany i już we wrześniu 2005 roku trwały prace nad jego usunięciem, najwyraźniej wciąż bez sukcesu. Na razie nie pozostaje mi nic innego jak upewnienie się, że do IMQ idzie jedynie ruch inny niż lokalnie wygenerowany przez tę maszynę. A jak dalej będzie się wieszać, to przełożę tę kartę sieciową do drugiej maszyny i nieco przerobię swoją siec :)

Dlaczego Linuks z iptables nie nadaje się na "poważny" firewall? Iptables to kawał porządnego narzędzia, jednak nie zaryzykowałbym wykorzystanie tego rozwiązania w "poważnych" zastosowaniach. Zamiast tego wykorzystałbym pf i OpenBSD.

Jak zrobić tak, by móc i coś intensywnie ściągać (nie koniecznie przez P2P), ale jednocześnie działały inne usługi na zadawalającym poziomie? Oczywiście, trzeba kształtować ruch. Jest wiele opracowań i przykładów na ten temat, więc dorzucę kilka słów od siebie. Ale takich trochę innych...

Dzisiaj na jednym forum zobaczyłem pytanie, czy można jakoś tak zrobić, by port wydawał się zamknięty dla kogoś, kto skanuje sieć, ale by "normalny" klient mógł się połączyć. Odpowiedź w zasadzie powinna brzmieć NIE (no, w każdym razie dla NORMALNEGO klienta), ale można próbować pewnej sztuczki...