Download: Spolecznosc_Projekty

SPOŁECZNOŚĆ
Projekty
Przegląd najciekawszych projektów Open Source
Projekty pod lupą
W tym miesiącu poświęcimy uwagę dwóm projektom: najnowszej wersji
OpenBSD oraz serwerowi telefonicznemu Asterisk.
ARTUR SKURA
OpenBSD 3.5
Kolejna wersja OpenBSD, oznaczona numerem 3.5[1], pojawiła się 1 maja.
Oprócz wielu usprawnień związanych z bezpieczeństwem zawiera kilka innowacji, które
powinny zainteresować Czytelników Linux
Magazine, zwłaszcza administratorów sieci.
Jak wiadomo, OpenBSD jest bardzo często
wykorzystywany w roli routera i firewalla,
głównie ze względu na niezwykle elegancki
sposób konfiguracji filtra pakietów pf, który –
od wersji 3.4 – został połączony z mechanizmem zarządzania pasmem ALTQ, dzięki
czemu za pomocą jednego pliku konfiguracyjnego, wykorzystując przejrzysty zestaw reguł,
możemy kontrolować najistotniejsze aspekty
ruchu sieciowego.
Wraz z wersją 3.5 nasze firewalle zostają
wzbogacone o nowy protokół, CARP (Common Address Redundancy Protocol), pozwalający uzyskać redundancję routerów/firewalli w dużych sieciach. Oznacza to, że ruch między sieciami kontroluje nie jeden, lecz kilka
firewalli: jeśli główny firewall przestanie działać, jeden z pozostałych przejmie jego pracę,
włączając w to utrzymywanie stanu połączenia, w sposób przezroczysty nie tylko dla komputerów w Internecie, lecz również w sieci wewnętrznej – co wymaga nadania firewallom
tego samego numeru IP i adresu MAC.
Co ciekawe, wykorzystano w tym celu zupełnie nowy protokół zamiast oprzeć się na
Strona domowa wersji 3.5 OpenBSD
102
Czerwiec 2004
już istniejącym (VRRP, Virtual Router Redundancy Protocol) z powodu zagrożenia patentowego ze strony Cisco. Nowopowstały
CARP nie zawiera błędów i niedoskonałości
VRRP, wzbogacono go również o podstawowe
funkcje kryptograficzne.
Jak działa redundancja w najprostszym
przypadku? Ruch sieciowy przechodzi przez
główny firewall. Komputer ten wysyła również komunikaty CARP. Pozostałe firewalle
jedynie nasłuchują. W sytuacji, kiedy komunikaty przestają nadchodzić, zaczynają je wysyłać firewalle zapasowe. Ten z nich, który będzie je wysyłał najczęściej, przejmuje rolę
głównego firewalla.
No dobrze, ale co w takim razie z regułami
i tablicami stanu firewalla? Ich synchronizacją zajmuje się pfsync. Jest to pseudourządzenie odpowiedzialne za transfer danych między firewallami.
Ze względu na specyfikę tego typu ruchu,
w wersji podstawowej nie przewidziano szyfrowania, dlatego nie wolno używać pfsync
w ogólnodostępnych segmentach sieci LAN –
należy do tego celu stworzyć dedykowaną sieć
(w najprostszej wersji wystarczy kabel krosowany między głównym a zapasowym firewallem). W przeciwnym wypadku napastnik
z dostępem do sieci mógłby łatwo dodawać,
usuwać i modyfikować reguły firewalla.
Jakie są implikacje powszechnej dostępności CARP i pfsync? Przede wszystkim administratorzy sieci, którzy zdecydują się wprowadzić redundancję firewalli, będą mogli częściej aktualizować oprogramowanie na firewallu, zwłaszcza w sytuacji, kiedy od jego pracy
zależy dostępność serwerów odpowiedzialnych
za komunikację między firmą a Internetem.
Częstsza aktualizacja oprogramowania to
zwiększony poziom bezpieczeństwa. Nie należy jednak traktować CARP i pfsync jako panaceum – siłą rzeczy obydwa firewalle znajdują
się w jednej sieci i w przypadku poważnego
problemu fizycznego (uszkodzenie łącza, po-
www.linux-magazine.pl
żar) redundancja nie pomoże.
Deweloperzy OpenBSD zwrócili się do IANA (amerykańskiej organizacji zajmującej się
przyznawaniem numerów protokołów internetowych) o przydzielenie numeru dla CARP.
IANA jednak odmówiło. Dlaczego? Organizacja chcąca uzyskać numer dla swojego protokołu ma dwa wyjścia:
(1) protokół musi zostać uznany za standard przez IETF,
(2) zapłacić ekspertom IANA, by ci ocenili
przydatność protokołu. Pierwsza droga jest
dla twórców CARP zamknięta, ponieważ mimo sporów na ten temat w IETF, przeważający głos na forum tej organizacji mają członkowie-korporacje, takie jak Cisco, Microsoft czy
IBM, mocno broniący standardów zawierających ograniczenia patentowe, z których można czerpać bezpośredni zysk. OpenBSD nie
stać z kolei na drugie rozwiązanie, które jest
niezwykle kosztowne. Tak więc w OpenBSD
CARP jest protokołem internetowym numer
112, poprzednio zarezerwowanym dla VRRP.
Jest to w pewnym sensie wyzwanie rzucone
IETF i Cisco, ponieważ CARP jest protokołem całkowicie pozbawionym ograniczeń patentowych, zaś jego implementacja dostępna
jest na zasadach liberalnej licencji BSD – inne
firmy mają więc coraz mniej powodów, by
używać VRRP, zwłaszcza że CARP zawiera
w stosunku do niego wiele usprawnień.
Projekty
Jako ciekawostkę należy odnotować fakt, że
powstała wersja CARP działająca w przestrzeni użytkownika, czyli Userland Carp[2]. Dzięki temu z CARP mogą korzystać użytkownicy
innych systemów operacyjnych, w tym Linuksa – i nie tylko po to, by uzyskać redundancję
firewalli, ale i innych serwerów oferujących
istotne usługi. Należy jednak pamiętać, że
kod stanowiący część jądra jest bardziej zwięzły, przez co bardziej odporny na potencjalne
błędy. Oczywiście jeśli zależy nam na redundancji innych usług, musimy sami zatroszczyć się o synchronizację danych między
głównym serwerem a serwerami zapasowymi,
choć czasem wystarczy jedynie identyczna
konfiguracja wszystkich hostów.
Kolejna interesująca funkcjonalność, dla
której warto zaznajomić się z najnowszą wersją OpenBSD, to wprowadzenie obsługi tzw.
szarych list.
Jak wiadomo, w walce ze spamerami jednym z najbardziej popularnych mechanizmów działających na poziomie MTA są czarne listy (black lists), czyli listy adresów IP (i
nie tylko) faktycznych i potencjalnych rozsiewaczy elektronicznych śmieci. Znacznie
mniej popularne, i działające często na poziomie MUA, są białe listy -- czyli listy nadawców, od których nie spodziewamy się otrzymać niechcianej poczty.
Czym są więc szare listy? Wbrew pozorom
nawiązanie do czarnych i białych list nie jest
wcale odległe. W praktyce chodzi o takie
skonfigurowanie MTA, by odrzucał przyjęcie
każdego listu przychodzącego z nowego adresu (a dokładniej – każdej nowej kombinacji
adres IP-nadawca-odbiorca), prosząc o dostarczenie go później. List zostaje zaakceptowany
dopiero przy kolejnej próbie. Dlaczego?
Spamerzy zazwyczaj rozsyłają wiadomości
z danego adresu IP dopóki nie zostaną pozbawieni tej możliwości – czy to przez odcięcie
przez swojego ISP, czy też umieszczenie na
jednej z popularnych czarnych list.
Najczęściej atak z jednego adresu IP trwa
stosunkowo krótko. Ponawianie wysyłki niedostarczonych listów to ogromny koszt, na
który trudno w takiej sytuacji sobie pozwolić.
Zmiana adresu IP nic nie pomoże, ponieważ
zmieniony IP resetuje licznik kombinacji
i list znów zostanie odrzucony. Oczywiście
normalni użytkownicy nie powinni mieć problemów – wszystkie serwery zgodne z RFC
muszą spróbować dostarczyć wiadomość ponownie, jeśli serwer adresata o to prosi. Jeśli
list zostanie w ten sposób dostarczony za drugim razem, kolejne opóźnienia nie będą konieczne i użytkownicy nie powinni zauważyć
żadnych anomalii.
Istnieje oczywiście obawa, że spamerzy
w ten czy inny sposób przystosują się do nowej
sytuacji. Będzie się to jednak nieuchronnie
wiązało ze zwiększeniem kosztów wysyłania
spamu, dlatego warto rozważyć wykorzystanie
tej metody w swojej sieci. Obsługą szarych list
w OpenBSD zajmuje się demon spamd (odpowiedzialny również za czarne listy), który
w połączeniu z filtrem pakietów stanowi potężne narzędzie marnujące zasoby spamerów
i chroniące skrzynki użytkowników przed niechcianą pocztą.
Asterisk
Istnieje wiele projektów Open Source, które –
choć mogą wiele zaoferować użytkownikom –
są rozwijane bez rozgłosu, czekając na swój
czas. Jednym z takich projektów jest Asterisk[3]: oprogramowanie, które bardzo trudno
określić jednym słowem, choć najbliższy będzie zapewne termin „otwarta, programowa
centrala telefoniczna” (Open Source PBX).
Sponsorem projektu jest firma Digium[4],
producent kart PCI, umożliwiających podłączenie zwykłego PC m.in. do różnego typu linii telefonicznych. Wiadomo jednak, że karty
te przedstawiałyby sobą niewielką wartość bez
odpowiedniego oprogramowania -- tak więc
rozwój Asteriska jest ważnym czynnikiem
zwiększającym sprzedaż sprzętu Digium.
Co może Asterisk? Chciałoby się powiedzieć „wszystko”, bowiem lista zaimplementowanych funkcji to kilkaset pozycji. Nie
wdając się w analizę bardziej egzotycznej
funkcjonalności, powiedzmy tylko, że Asterisk umożliwia prowadzenie rozmów przy
wykorzystaniu tradycyjnych linii telefonicznych, sieci IP oraz połączenia ich obu, obsługę numerów wewnętrznych, poczty głosowej,
automatycznej sekretarki, przekazywania połączeń, konferencji, rozpoznawania numeru
dzwoniącego (CallerID), określania uprawnień dzwoniącego i wiele innych – a wszyst-
SPOŁECZNOŚĆ
kim tym możemy sterować za pomocą skryptów i plików konfiguracyjnych, tworząc centralę najlepiej odpowiadającą naszym potrzebom. Przykładowo, możemy stworzyć bramkę, która -- w zależności od wybieranego numeru – połączy się z nim wykorzystując VoIP
(Asterisk obsługuje SIP, H.323 i własny protokół IAX) lub tradycyjną linię telefoniczną.
Możemy całościowo monitorować połączenia
telefoniczne w firmie. W USA popularne stają się konfiguracje, w których automatycznie
odrzucane są połączenia nie posiadające
identyfikatora dzwoniącego, co pozwala
uniknąć plagi telemarketingu.
Nie bez znaczenia jest też niski koszt kart
Digium – najtańsze możemy kupić już za około 100 USD. Jeśli dodamy do tego adapter do
telefonów stacjonarnych, taki jak Cisco ATA-186, koszt minicentralki zamknie się w kwocie o rząd wielkości niższej, niż dostępne na
rynku centrale sprzętowe. Jak mówi jeden
z inżynierów Digium, Greg Vance, zarówno
Cisco jak i Avaya (oferujący produkty, dla
których Asterisk jest bezpośrednią konkurencją) testują Asteriska w swoich laboratoriach,
do tej pory nie było jednak oficjalnych kontaktów między tymi firmami.
Asterisk nie jest prosty w konfiguracji –
wymaga nie tylko pewnej teoretycznej wiedzy teleinformatycznej, ale i praktycznej
umiejętności radzenia sobie z zawiłościami
protokołów, zwłaszcza w rozbudowanych instalacjach łączących kilka oddziałów firmy
oraz różne sposoby komunikacji. W Internecie znaleźć można jednak sporą ilość materiału pomocnego w przygotowaniu Asteriska
do wykonywania najbardziej wymyślnych zadań. Jak na tego typu aplikację przystało,
większość funkcji można obsłużyć i rozszerzyć za pomocą skryptów. Skrypty te, zwane
skryptami AGI, mogą być napisane w dowolnym języku (programista operuje na zmiennych środowiskowych, analogicznie jak
w przypadku skryptów CGI).
■
INFO
[1] Więcej informacji o wersji 3.5
można znaleźć na stronie
http://www.openbsd.org/35.html
[2] Strona domowa projektu Userland Carp:
http://www.ucarp.org
Implementacja ta jest dostępna
na licencji BSD.
[3] Strona domowa projektu Asterisk:
http://www.asterisk.org
Program Gnophone, programowy telefon
[4] Strona domowa Digium:
http://www.digium.com
współpracujący z Asteriskiem.
www.linux-magazine.pl
Czerwiec 2004
103