Paweł Goleń, blog

Do tej pory obsługą Neostrady zajmował się demon pppd, OpenBSD oferuje implementację pppoe w kernelu, w związku z czym postanowiłem jej spróbować. Konfiguracja jest rzeczywiście trywialna, cały plik hostname.pppoe0 wygląda tak:

inet 0.0.0.0 255.255.255.255 NONE \ 
	pppoedev xl0 authproto pap \ 
	authname 'username' authkey 'password' up dest 0.0.0.1

!/sbin/route add default 0.0.0.1
    

Z drugiej strony od razu brakuje jednej, prostej rzeczy... Neostrada ma to do siebie, że rozłącza się co 24 godziny. W przypadku demona pppd w takim przypadku możliwe jest wywołanie skryptu, który parę rzeczy zrobi (zrestartuje pewne usługi, uaktualni wpisy DNS). W przypadku implementacji pppoe w kernelu, takiej możliwości nie ma. Tutaj już Windows radzi sobie lepiej udostępniając serię zdarzeń, które pozwalają monitorować stan sieci. A co pozostaje w OpenBSD? No chyba nic innego, jak okresowe uruchamianie zadań z crona... Ale to nie jest dobre podejście. Jeśli jakiś program oczekuje na jakieś zdarzenie, to najlepiej, gdyby był dostępny jakiś obiekt notyfikacyjny odnośnie tego zdarzenia. Okresowe sprawdzanie, czy przypadkiem nie nastąpiła zmiana jest chore.

A co chcę robić po ponownym połączeniu? To może od razu, czego nie chcę robić, nie chcę przeładowywać reguł pf. A nie chcę tego robić, bo takiej potrzeby nie ma, wbrew temu, co w niektórych przewodnikach o wykorzystaniu OpenBSD w połączeniu z dynamicznym adresem IP jest napisane. W opisie do pf.conf wyraźnie jest napisane: Host name resolution and interface to address translation are done at ruleset load-time. When the address of an interface (or host name) changes (under DHCP or PPP, for instance), the ruleset must be reloaded for the change to be reflected in the kernel. Sur- rounding the interface name (and optional modifiers) in parentheses changes this behaviour. When the interface name is surrounded by parentheses, the rule is automatically updated whenever the inter- face changes its address. The ruleset does not need to be reload- ed. This is especially useful with nat. Na pewno chcę wykonać jednak dwie akcje, uaktualnić wpis w DNS oraz zrestartować OpenNTPd. Aktualizacji wpisów w DNS dokonuję przy pomocy narzędzia ipcheck.py, które uruchamiane jest z crona, obecnie co godzinę. Restart OpenNTPd też będę wykonywał z poziomu tego narzędzia, ponieważ ma ono możliwość wykonania skryptu po udanej aktualizacji wpisu w DNS. Ale po co restartować OpenNTPd? Niestety, demon zapamiętuje sobie adres interfejsu, którym wysyła zapytania do świata. Po 24 godzinach następuje zmiana adresu i... i już nie synchronizuje się ze światem. Restart jednak wcale nie jest taki prosty, nie ma tu skryptów w init.d, a demon nawet nie zostawia po sobie pliku z pid. To jest akurat do załatwienia prostym skryptem, ale trochę rozczarowały mnie te niedogodności.

OK, to mamy już podłączony do sieci, aktualizujący (okresowo) oraz synchronizujący (z pewnymi problemami) czas, system. Co dalej?

Choć narzędzie robi to samo, co iptables, to jednak filozofia działania jest inna. Choć PF jest potężny, to nie można nim robić takich dziwactw, jak w przypadku netfiltra. Dla mnie problemem jest brak rozróżnienia przy tworzeniu reguł, czy powinny one dotyczyć pakietu adresowanego do tej maszyny, czy może tych, które są przez nie routowane. Pakiet należy najpierw "wpuścić" do bramki, a potem z niej dopiero "wypuścić". Mimo wszystko z PF jestem zadowolony... no, może kształtowanie ruchu mnie trochę zawiodło... A dlaczego? Nie widzę możliwości "połączenia dwóch interfejsów w jeden", tak jak zrobiłem poprzednio, przy pomocy IFB. Co więcej altq nie działa na enc, ale ostatecznie i tak zmieniłem nieco koncepcję szyfrowania swojej sieci więc to nie jest wielki problem. Zresztą za kształtowanie ruchu się jeszcze nie zabrałem..

OpenBSD wspiera jedynie WEP. WEP z kolei jest słaby, tak słaby, że do sieci zabezpieczonej przez WEP może wpiąć się każdy, kto potrafi uruchomić najpierw airodump-ng, a później aircrack-ng. Co więcej, można to zrobić jeszcze szybciej, przy pomocy narzędzia aircrack-ptw, które zresztą za chwil kilka zamierzam przetestować. Aby było bezpieczniej, użyć można IPSec, przerabiałem to jakiś czas temu, z sukcesem. Niestety, okazało się, że wszystko działa pięknie, do czasu, gdy wystarczy tylko ta jedna reguła tunelowania. Chciałem dorobić drugą regułę, która w transport mode zabezpieczała by ruch między wszystkimi komputerami podłączonymi po wireless. Niestety, okazało się to niewykonalne, głównie z uwagi na Windows. A to dlatego, że Windows chciał robić negocjację IKE za pośrednictwem tunelu... Mimo usilnych starań nie udało mi się wyłączyć ruchu IKE z tego tunelu, w związku z czym dałem sobie spokój. I nie, opcja "domyślnych wyjątków" nie działa w przypadku tunelu: (1) In order for IPSec transport mode to be negotiated through an IPSec tunnel mode SA, ISAKMP traffic is not exempted if it needs to pass through the IPSec tunnel first. A jeśli jest reguła tunelu typu me->0.0.0.0/0, to raczej każdy ruch przez ten tunel przejść musi... Cóż, w efekcie ruch wewnątrz sieci jest szyfrowany, ten, który idzie do świata już nie. Choć nie do końca, tam, gdzie się daje i tak używam SSL (poczta i inne takie), a ruch HTTP będzie wychodził przez proxy, do którego ruch będzie szyfrowany IPSec. Jeśli ktoś podsłucha moją transmisję, to będzie mógł sobie odtworzyć na przykład nową wersję BackTrack, którą za chwilę ściągnę przez torrent.

Na ewentualnych podpinaczy mam dwa pomysły - albo authpf albo po prostu wytnę dostęp do DNS bez IPSec.

I jeszcze o skuteczności WEP, po zebraniu 130 000 IVS aircrack-ng złamał klucz w ciągu 6 minut, 52 sekund, aircrack-ptw na razie chyba nie radzi sobie z tym zadaniem, ciekawe dlaczego...

Do tej pory zawsze używałem djbdns, w OpenBSD jest "na standardzie" BIND. Zawsze się zabierałem do tego jak do jeża, nie podoba mi się ten serwer, bo jest dla mnie za duży. Tym razem jednak się przemogłem i... i dalej uważam, że jest za duży, ale jakoś będę z tym żył. Przynajmniej na razie.

Nie mam również swojego narzędzia antyspamowego, które do tej pory dzielnie broniło mnie przed niechcianą pocztą. Z drugiej strony jednak Onet wyraźnie poprawił jakość swoich filtrów antyspamowych, dwie niechciane wiadomości dziennie jestem w stanie przetrawić. Nie mówię, że tak zostanie, ale na razie pogoda jest za ładna :)