vermin.eu.org

Przyszło mi musieć posiadać dwa rodzaje pakietów na jednym systemie - ze stabilnego etcha i lenny’ego. Sprawa wydaje się banalna - wpis w /etc/sources.list

oraz w apt.conf

Po ty wystarczy dać aptitude update… żeby otrzymać to:

A wystarczy w /etc/apt/apt.conf dodać np.

i już działa

Byłem i zakupiłem certyfikat typu wildcard dla jednej z administrowanych domen. Taki to wymóg pojawił się w obsługiwanej przeze mnie firmie, coby korzystający z aplikacji webowych klienci tejże bezpieczniej się czuli wymieniając dane z serwerem. Nie jest to certyfikat z “zielonym paskiem” (swoją drogą jest to niezły absurd jako wysoko płatne bezpieczeństwo, szczególnie jak ktoś ma oskórkowanego FF/IE/Opera/whatever…) Kupiłem go od firmy polskiej, coby obce imperialistyczne świnie wolnorynkowe elementy ze znaczącym udziałem kapitału zagranicznego nie pasły się kosztem firmy.

Generacja certyfikatu oczywiście za pomocą paczki openssl - prosta komenda openssl req -new -key server.key -out server.csr i już mamy żądanie, które musimy wrzucić do Centrum Certyfikującego. Jak na razie wszystko fajnie i działa - abstrahując od tego, że oważ firma nie za bardzo przygotowana była ze swoim systemem sprzedaży webowej do certyfikatów typu wildcard i chciała wysyłać mi maila na adres webmaster@*.firma.com.pl albo sprawdzać siakieś pliki na takowymż serwerze. Niemniej pomoc ichnia zadziałała szybko i poprawnie i bezproblemowo certyfikat ów dostatałem wraz z instrukcjami jak to go wgrać do mego apache/iis/whatever_web_server. Miłe.

Niestety mój apache, (w przeciwieństwie do IIS, który łyknął wszystko bez słowa), stwierdził w zasadzie, że on nie obsługuje SSL pomimo całej odprawionej w konfiguracji virtual hosta magii mówiącej wprost, że SSL działać ma, że klucze i certyfikaty są (zweryfikowane) w odpowiednich miejscach:

Zgłaszał to na dodatek tak uprzejmie, że rzucał kodem nie do odnalezienia, informując poprzez FF/IE, że “blah.firma.com.pl wysłał nieprawidłowy lub niespodziewany komunikat. Kod błędu: -12263″. Wredne to o tyle, że włożenie w google “-12263″ zwróciło mi 0 wyników… Niemniej problem okazał się absurdalny w sensie swojej prostoty. Otóż (błędnie) nie miałem podefiniowanych wirtualnych hostów jako stojących na odpowiednich portach, tj. brakowało mi w odpowiedniej linijce informacji o porcie:

Dokonana w ten sposób separacja pomiędzy hostami szyfrowanymi (443) i nieszyfrowanymi (80) załatwiła sprawę… ale nie do końca. W końcu klient chciał coby komunikacja zachodziła w sposób bezpieczny. Ponieważ obciążenia serwera średniomałe w pliku odpowiadającym za port 80 dorzuciłem co następuje:

No i śmiga, loguje gdzie trza co trza i jeszcze spełnia założenia firmy. Ufff.

P.S.
Oczywiście wszystko to jest przy założeniu, że wcześniej wykonało się takie magiczne komendy w Debianie, które powrzucały w /etc/apache2/mods-enabled i /etc/apache2/sites-enabled odpowiednie moduły i site’y. Wystarczyło w tym celu wykonać sekwencję:

i sprawdzić czy wszystko działa za pomocą apache2ctl -t Ale to przecież oczywiste…

Skoro wspomnieliśmy już ogólnie o tym cóż to to monitorowanie jest, warto by wszystko skonfigurować, żeby móc cieszyć nasze oczy pięknymi grafami/tabelkami/wykresami czy też jakąkolwiek inną reprezentacją zbieranych danych.

1. Instalacja
Przede wszystkim musimy zainstalować oprogramowanie agentów. W wypadku systemów Windows ścieżka jest prosta:
Panel Sterowania -> Dodaj lub usuń programy -> Składniki systemu Windows -> Narzędzia zarządzania i monitorowania. Po chwili mamy już zainstalowanego agenta.
W Debianie sytuacja jest także prosta. Wystarczy zainstalować paczkę snmpd (aptitude install snmpd). Dodatkowo przydadzą się nam narzędzia z paczki snmp (aptitude install snmp).
Pod Windows, jeśli nie chce nam się szukać, ściągąc i kompilować net-snmp tools z którego to pakietu pochodzi wykorzystywane w dalszej części narzędzie snmpwalk, warto ściągnąć Windows Management Instrumentation (WMI) SNMP Provider, który pozwoli na odpytywanie SNMP z poziomu WMI.

2. Weryfikacja
W systemie Windows zweryfikujemy działanie SNMP poprzez uruchomienie MMC Usługi (services.msc) i sprawdzenie czy działa serwis Usługa SNMP oraz (ewentualnie) Usługa SNMP Trap. Jest to też ciekawostka, ponieważ jest to jedyna (znana mi) usługa, która całą swoją konfigurację ma właśnie w tym miejscu. Wydawałoby się, że warto jej poświęcić chociaż małe MMC, a tu nic.
W systemie Debian wystarczy oczywiście wydać komendę ps `cat /var/run/snmpd.pid`, dzięki której zobaczymy, czy demon SNMP działa. Daemon tu jest agentem a nie serwerem, o czym warto pamiętać.

OK, może i SNMP działa, ale czy coś do nas powie? Czy odpowie na na nasze wołania? Wystarczy wydanie komendy snmpwalk -v 1 -c public localhost żeby ekran (jeśli wszystko jest ok) pokrył się tonami kodu, wyglądającego mniej więcej tak:

Te kody swoją droga coś znaczą - pierwsza pozycja to tzw. MIB, czyli nie “faceci w czerni”, ale nazwa danej (tu w postaci numerycznej), np. naszego czujnika temperatury albo pokrętła. Część po znaku równości to jak łatwo się domyśleć, aktualna wartość tegoż MIBa. MIBy można podawać za pomocą cyfrowego łańcucha znaków… albo, jeśli mamy coś co to ładnie przetłumaczy (czyli zbiory tekstowe z opisem MIBów), możemy zapytać się ładniej - snmpwalk -v 1 -M. -c public localhost IP-MIB::ipAdEntIfIndex co poda nam indeksy interfejsów w systemie.
Sama komenda ma strukturę snmpwalk -v wersja_protokołu -M katalog_z_MIBami -c community_name hostname MIB.

3. Konfiguracja
Domyślnie SNMP działa na lokalnym serwerze (localhost) z communityname public dla odczytu i private dla odczytu/zapisu (tak, za pomocą SNMP można także sterować urządzeniem!). Windows ma tylko community public i przyjmuje połączenia od dowolnego hosta. Warto zmienić ciut te wartości oraz podać, gdzie nasz sprzęt się znajduje (jeśli trochę go mamy). Odpowiednie wartości wpiszemy we właściwościach usługi (services.msc -> usługa SNMP -> własciwości: zakładka Agent i Zabezpieczenia) lub w /etc/snmp/snmpd.conf.
Tutaj także możemy zmodyfikować jakiego rodzaju informacje agent SNMP będzie monitorować (sieć, procesor, dyski, etc.) Gama możliwości jest naprawdę duża.

W systemie Windows możemy poza standardowymi parametrami odpytać następujące serwisy:

• WINS
• DHCP
• IIS
• LAN Manager
• RRAS (Routing and remote access)
• IAS
• liczniki System Monitora (wszystkie liczniki wydajności TCP/IP i usług na nim opartych)

Z czego sterować można IAS, Lan Managerem i WINSem.

4. Zarządca
Było zarządców wielu, ale żaden z nich nie śmiał zagrać przy… Cóż, ciężko powiedzieć. W zasadzie to HP OpenView narzuca się samo, niemniej my mamy mniejsze potrzeby. Chcemy monitorować. Chcemy żeby było prosto, łatwo i darmo. Chcemy MRTG (tak, wiem jest też Cacti - ale ono jest za bardzo rozbudowane na początek).
MTRG można zainstalować pod Windows oraz pod Linuxem. Program odpytuje agenta (agentów) w zadanych interwałach czasu (cron/at), zbiera dane i przetwarza je na postać graficzno -tekstową (HTML + obrazki PNG). Konfiguracja wygląda tak samo pod obydwoma systemami. Należy podać mu skąd ma pobrać dane, jakie MIBy nas interesują, podać parametry interfejsu, czyli tak naprawdę wytyczne odnośnie rysowania obrazka i już.
Na dodatek MRTG ma przyjemne “wizardy” tworzące samoczynnie konfigurację:

tworzy podstawowy plik konfiguracyjny dla społeczności public na localhost informując że dane będą w katalogu WorkDir

stworzy dla nas odpowiednie pliki
Teraz tylko parokrotne uruchomienie mrtg (mrtg /etc/mrtg/MartaG.cfg) tworzące resztę wymaganych plików uwieńczy naszą pracę sukcesem. Podstawowa konfiguracja zakończona i możemy popatrzeć jak to wszystko wygląda.

Należy pamiętać, że aby odczytać te dane na stacji administratorskiej to albo skonfigurujemy poprawnie IISa pod Windows lub Apache pod Linuxem, albo postawimy jakiś mały dedykowany serwer, jak np. microhttp, który idealnie sprawdzi nam się do rzadkiego publikowania statycznych informacji (chyba, że planujemy inne obciążenie tegoż serwisu - ale po co?).

Do czego właściwie potrzebne to wszystko? Żeby móc stworzyć własny, rozproszony SMS dla ubogich. Jakby nie można było kupić licencji… No, ale ten system daje także rzeczy, których wprost z SMSa wyciągnąć się nie da, a poznać je warto - jak chociażby lista aktualnych połączeń z danego komputera (stos TCP/IP), że nie wspomnę o podstawowym zadaniu MRTG, czyli monitorowaniu urządzeń sieciowych.

Dodatki: Narzędzia SNMP dla Windows.

Wyobraź sobie urządzenie, która ma ileś tam czujników - np. kaloryfer z termoregulacją. Masz odczyt temperatury (wartość1) i pokrętło (wartość2). Chcielibyśmy (jeśli kaloryfer to umożliwia) pobierać i monitorować urządzeniem zewnętrznym wartość tej temperatury (wartość1), a także ustawienie pokrętła (wartość2). Jak to zrobić (w dziedzinie komputerów)?

Monitorowanie sprzętu jest ważne - na przykład dlatego, że pozwala wykryć sytuacje prowadzące do nieodpowiednich zachowań. Zaczynając od tak banalnych rzeczy jak wysycenie pewnych parametrów (np. mierzenie poziomu zajętości dysku, badanie obciążenia procesora, stronicowanie pamięci i inne wąskie gardła), do zagadnień bezpieczeństwa (tu dla odmiany monitorowania bramki internetowej, co pozwoli nam stwierdzić, czy ktoś przypadkiem nie wykorzystuje naszego łącza pomimo (braku) zabezpieczeń w czasie teoretycznego braku aktywności). Monitorować można na wiele różnych sposobów, niemniej warto zainteresować się jednym z nich, dostępnym zarówno w systemach Windows i Linux - a przede wszystkim w dużej ilości urządzeń zewnętrznych (w szczególności sieciowych).

Do monitorowania wykorzystuje się protokół SNMP. Ten prosty protokół jest szeroko rozpowszechniony i doczekał się już swojej trzeciej wersji. Niemniej ponieważ w użyciu są przede wszystkim wersje 1 i 2, skupimy się na nich - żeby to zaczęło działać.

Do podstawowego działania każde monitorowane urządzenie powinno mieć program (agenta), który będzie pobierał stan jakiegoś wewnętrznego rejestru (np. przepływność interfejsu sieciowego) a następnie, odpytany przez zarządcę, podawał mu te dane. Agent może być także ciut proaktywny i w wypadku zadziałania zdefiniowanego warunku wysyłać do zarządcy odpowiednią informację (zwaną trap/pułapką). Do poprawnego działania w środowisku sieciowym potrzebne będą porty TCP 161 (odpytywanie) i 162 (pułapki). Przyda się jeszcze tzw. community name, czyli nazwa o którą będziemy odpytywać nasze urządzenie.

Na boku: Widać tu wyraźnie, że skoro jedynym zabezpieczeniem jest znajomość community name musimy przedsięwziąć inne środki bezpieczeństwa… lub wdrożyć wersję 3 protokołu SNMP.

OK - tyle teorii wystarczy. Jak to wszystko zrobić nie dopłacając? O tym w następnym artykule.

Przy tak dużej zmianie i wyborze nowego systemu warto przemyśleć kilka spraw. Pomoże w tym ten komiks.
Zawsze też można się zastanowić nad inną, niemniej fajną

Cóż - aktualizacja systemu, szczególnie, do jakby nie było jeszcze wersji testowej, powoduje pewne problemy. W tym wypadku niestety posiadanie karty działającej ze sterownikiem sundance 1.1 z jajka 2.6.18 w wypadku zainstalowania snmpd, który z automatu odpytuje to urządzenie co 30 sekund powoduje zrzut czegoś w formacie

i to dla każdej z aktywnych kart składających się na to urządzenie.

Podejrzewam, ponieważ nie towarzyszą temu żadne komunikaty o wyłączaniu komunikacji, oopsy kernela, czy inne dziwne teksty (%s: Something Wicked happened! %4.4x.), że są to informacje typu debug, które zostały wkompilowane w kernel. Niestety serwer jest zdalny i nie za bardzo mogę wyłączyć tą sieciówkę, przez którą idzie m.in. cała komunikacja ze światem zewnętrznym… a pewnie wystarczy zmiana parametrów przy ładowaniu tego modułu Cóż, będzie go trzeba w wolnej chwili przeładować albo czekać, że wraz z wersją 2.6.19 pojawi się w Debianie sterownik w wersji 1.2 (i wtedy przeładujemy system…)

[l8r that day] Po przejrzeniu kodu i stron…

Swoją drogą ciekawe jest, że RH podaje, że ten moduł nie przyjmuje żadnych parametrów, a w źródle można znaleźć takie coś:

co zresztą pokazuje modinfo. Dalsze śledztwo pokazało też, że za całe zamieszanie odpowiedzialna jest procedura netdev_ioctl, która ot tak sobie wypluwa te wszystkie informacje, przy debug=0. Raczej przyjdzie ręcznie wywalić ten kod z modułu…

Posiadając wiele interfejsów w systemie (np. dzięki wieloportowej karcie… lub kilku takim zabawkom) warto ponazywać je ciut inaczej niż domyślne w Linuksach ethX. Przydaje się to także w momencie, gdy czasem dodajemy lub zabieramy kartę z komputera przez co zmienia się numeracja interfejsów… i nagle ginie wyjście na świat, a my musimy zgadywać (dmesg), który eth za to odpowiada.
Przede wszystkim pomyślmy jak się ma ten interfejs nazywać - załóżmy, że iface do sieci nazwiemy world zaś iface do sieci wewnętrznej intranet (jakiż jestem orginalny…). Najpierw musimy wyedytować pliki odpowiedzialne za konfigurację sieci (w Debianie /etc/network/interfaces) i zamienić tam ethX na nasze nowe nazwy. Następnie otwieramy, lub, co bardziej prawdopodobne, tworzymy plik /etc/mactab, gdzie tworzymy wpisy typu nazwa_interfejsu_sieciowego adres MAC:

world 00:0D:88:11:22:33
intranet 00:0D:88:aa:bb:cc

Teraz wystarczy wydać komendę ifname i nasze nazwy zostały przypisane. To samo swoją drogą osiągnelibyśmy komendą ip link set eth3 name world.
Jedyna rzecz, jaka zostaje do zrobienia to upewnienie się, że nasze przypisania będą się odtwarzać przy starcie systemu. W Debianie (i podejrzewam, że w innych distro także) potrzeba wyedytować plik konfiguracji sieci (Debian: /etc/init.d/networking) dodając do niego:

Używanie odmiany testing Debiana ma jedną wadę - częste aktualizacje, (co nawiasem mówiąc świadczy o tym, że może etch jednak wyjdzie w TYM roku…). Chcąc podnieść sobie wersję open office trafiłem jednak na problem - otóż konfiguracja wywracała się na ttf-opensymbol. Miał on problem z dostępem do niektórych katalogów, których nie było w systemie.

"/usr/share/fonts": error scanning
"/usr/X11R6/lib/X11/fonts": error scanning
"/usr/local/share/fonts": error scanning
"/var/lib/defoma/fontconfig.d": error scanning

Rozwiązaniem okazało się aktualizacja pakietu fontconfig, który nie był wymagany wprost ale jedynie polecany.

Proste i banalne - czasem wystarczy przejrzeć zależności pakietu żeby znaleźć rozwiązanie. Szkoda tylko, że nie można tego zrobić od razu z poziomu aptitude, podczas wystąpienia problemów z instalacją…

Instalacja WEP jest prosta - wszystko sobie działa bezproblemowo, wystarczy wszak instalacja koniecznego i tak pakietu wireless-tools, a potem prosta komenda iwconfig eth1 essid enc restricted. Niestety z WPA trzeba się ciut namęczyć - szczególnie, jeśli posiada się kartę do której pasują sterowniki ipw2[21]00.

Pierwszym krokiem, który musimy wykonać, jest instalacja pakietu wpasupplicant, który wspomaga w autoryzacji - i to nie tylko jeśli chodzi o sieci WPA/WPA2 (TKIP, EAP), ale także WEP oraz sieci otwarte - więc jest pomocniejszy zdecydowanie niż ręczna konfiguracja przez iwconfig.
Niestety ma też swoje wady, przynajmniej w systemie Debian. Otóż nie instaluje on żadnych plików konfiguracyjnych, ani do katalogu /etc/, ani do katalogu /etc/init.d, co jak na rozpieszczającego mnie Debiana jest trzeba przyznać dziwne. Niemniej zmusza do tego, czego misie nie lubią - czyli zamiast “podejścia przez walkę” do przeczytania najpierw instrukcji. Szybkie przejrzenie katalogu /usr/share/doc/wpasupplicant powoduje, że procedura instalacji jest banalnie prosta. Potrzebujemy do niej jednak danych, których część zdobędziemy poprzez wykonanie komendy:
host:~# iwlist eth1 scan.

eth1      Scan completed :
          Cell 01 - Address: 00:16:41:60:13:B2
                    ESSID:"neostrada_195d"
                    Protocol:IEEE 802.11bg
                    Mode:Master
                    Channel:10
                    Encryption key:on
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s
                              11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s
                              48 Mb/s; 54 Mb/s
                    Quality=68/100  Signal level=-59 dBm
                    Extra: Last beacon: 4ms ago
          Cell 02 - Address: 00:16:41:10:00:30
                    ESSID:"default"
                    Protocol:IEEE 802.11bg
                    Mode:Master
                    Channel:11
                    Encryption key:on
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s
                              11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s
                              48 Mb/s; 54 Mb/s
                    Quality=89/100  Signal level=-40 dBm
                    IE: WPA Version 1
                        Group Cipher : TKIP
                        Pairwise Ciphers (2) : CCMP TKIP
                        Authentication Suites (1) : PSK
                    IE: IEEE 802.11i/WPA2 Version 1
                        Group Cipher : TKIP
                        Pairwise Ciphers (2) : CCMP TKIP
                        Authentication Suites (1) : PSK
                    Extra: Last beacon: 8ms ago

Widzimy, że w zasięgu mamy dwie sieci, jedną chronioną przez WEP, drugą zaś przez WPA - używające szyfrowania AES/TKIP oraz klucza wstępnej autoryzacji (PSK). Jeśli ów klucz znamy, to wystarczy teraz:

• skopiować plik examples/wpa-psk-tkip.conf - cp examples/wpa-psk-tkip.conf /etc/wpa_supplicant/wpa_supplicant.conf
• dokonać w nim odpowiednich zmian - czyli w liniach essid wpisujemy nazwę sieci (tu: default), w proto zostawić WPA, w key-mgmt zostawić WPA-PSK, w pairwise dodać CCMP, zaś w psk wpisać właściwy klucz
• wydać komendę wpa_supplicant -w -i eth1 -D ipw -c /etc/wpa_supplicant/wpa_supplicant.conf, co przy założeniu, że AP nas wpuści, powinno spowodować autoryzację w sieci…

Niestety zamiast podłączenia się do sieci, otrzymujemy komunikat:

ioctl[IPW_IOCTL_WPA_SUPPLICANT]: Operation not supported
ioctl[IPW_IOCTL_WPA_SUPPLICANT]: Operation not supported
Failed to set encryption.
Trying to associate with 00:16:41:10:00:30 (SSID=’default’ freq=0 MHz)
Authentication with 00:00:00:00:00:00 timed out.

Jak widać problem leży gdzieś w sterowniku do ipw, który czegoś nie wspiera, nie ustawia szyfrowania i próbuje się autentykować do nicości/wszystkiego (ciekawe, co ma MAC ::?) Co nam pozostaje? Spróbujmy dokonać debugowania sesji - sam wpa_supplicant to dość dobrze wspiera, wystarczy, że do linii poleceń dodamy “-d”.
host:~# wpa_supplicant -w -i eth1 -D ipw -c /etc/wpa_supplicant/wpa_supplicant.conf -d. Jedną z pierwszych kluczowych dla nas linii jest:

wpa_driver_ipw_set_wpa: enabled=1
ioctl[IPW_IOCTL_WPA_SUPPLICANT]: Operation not supported

Suuuuuper. Jak zwykle kochane sterowniki ipw robią problemy (albo ich implementacja w wpa_supplicant?). Na szczęście jest rozwiązanie wygooglane w bugtracku Debiana - wystarczy zmienić sterownik dla wpa_supplicant na wext, czyli nasza linia wywołania programu powinna wyglądać następująco:
wpa_supplicant -w -i eth1 -D wext -c /etc/wpa_supplicant/wpa_supplicant.conf . Teraz pozostaje tylko skonfigurować interfejs - np. dhclient -i eth1 i voila.

W debianie testing/etch pojawiło się swego czasu jądro systemu w wersji 2.6.17.

Wielkieś mi uczyniła pustki w domu moim,
Moje drogie jądro, tym pojawieniem swoim!

Jądro to automagicznie wyłączyło mi sieć bezprzewodową, generując przy tym tonę komunikatów typu

Ponieważ jednocześnie owe jądro wnosiło sterownik w wersji 1.1.1 należało także zmienić firmware z wersji 2.4 na 3.0. Niestety - pomimo tych zmian sterownik ipw2200 w jądrze nie działał poprawnie z ieee80211. Pozostawało jedynie ściągnąć nowszą wersję sterownika i samemu znów skompilować moduł ipw2200-source lub rekompilować jądro. Co ciekawe, to zachowanie nie występowało w poprzedniej wersji jądra - 2.6.16, gdzie wszystko działało poprawnie.

Na szczęście po ostatnim upgradzie systemu pojawiło się w końcu jądro 2.6.18 z ipw2200 w wersji 1.2.0 oraz ieee80211 w wersji… 1.1.13 (czyli downgrade!). I znów wszystko działa

Wczoraj rozpoczęła się faza zamrożenia czwartej już edycji Debiana - Etch. W związku z tym można się spodziewać, że niedługo ta właśnie edycja osiągnie fazę stable. Aktualizacja większości popularnych pakietów (server) nie jest szczególnie trudna i prawie obywa się bez problemów, więc tym, którzy chcą wcześniej przesiąść się na tą distro w celu spokojnej aktualizacji już dziś mogą polecić sed -i s/sarge/etch/g /etc/apt/sources.list lub też zmienić stable (co nie wiedzieć czemu pokutuje jeszcze w konfiguracji źródeł apt) na etch właśnie.

Kolejnym krokiem jest wykonanie aktualizacji pakietów (aptitude update) oraz instalacja samego aptitude (aptitude install aptitude). Tą linię warto jednak rozszerzyć o któryś z pakietów linux-image-2.6 (np. linux-image-2.6.18-3-686), ponieważ jest bardzo prawdopodobne, że zostanie nam odinstalowane jajko 2.6.8-3 i zostaniemy zupełnie bez jądra…. Więc wykonanie aptitude install aptitude linux-image-2.6.18-3-686 powoduje, że wszystko jest już ok.

Następnie wykonujemy raz jeszcze aptitude update i w końcu możemy spokojnie wykonać upgrade distro do wersji 4.0 etch (aptitude dist-upgrade). Bez odświeżenia aptitude moglibyśmy to także zrobić, ale byłby problem z niepodpisanymi pakietami…

Jak pisałem na początku roku, wersja etch systemu debian używać będzie (w końcu) secure-apt, tj. pliki zawierające poprawki będą podpisywane, a klucze będą dystrybuowane w podpisanej paczce. Taka architektura rodzie pewne problemy - ale największym problemem jest nieumiejętność jej wykorzystania przez sam projekt debian Przykład? Dziś próba apt-get update kończy się komunikatem:

W: There are no public key available for the following key IDs:
A70DAF536070D3A1
W: You may want to run apt-get update to correct these problems

Oczywiście rozwiązanie jest proste - wystarczy dodać ten klucz i go pobrać (jeśli się nie mylę, to ostateczny klucz wydania etch), niemniej nie po to jest tworzony pakiet z kluczami, żebym sam je sobie dodawał do keyringa! Jeśli będę dodawał wszystko jak leci, to równie dobrze pakiety mogą być niepodpisywane…

Jak to zrobić?

Standardowy proces aktualizacji Debiana to wydanie polecenia aptitude update && aptitude upgrade. Od jakiegoś czasu jednak w dystrybucjach testing i unstable Debian wprowadził zmianę swojego systemu aktualizacji i zamiast ściągac duże pliki (jak np. main/Packages.gz )m ściąga się pliki różnicowe dla danej architektury. Daje to oczywiście oszczędność pasma - jeśli coś się zmieniło, to nie ściągamy całego pliku, ale tylko różnicówkę od ostatniej aktualizacji. Jest oczywiście pewien minus - więcej plików, to dłuższy czas ściągania, ponieważ jest więcej zapisów, kończenia i rozpoczyniana transakcji.

Przy okazji - można aktualizacje różnicowe wyłączyć ustawiając opcje

Acquire::PDiffs “false”;

w /etc/apt/apt.conf lub dodając parametr przy uruchomieniu apt-get update -o Acquire::Pdiffs=false.

Podczas rozmowy z Adrianem zastanawialiśmy się, czy dałoby się zmienić jakoś także sposób aktualizacji samych pakietów. Po co za każdym razem przesyłać całe archiwum z nowym pakietem, powielającym wiele plików, które nie musiały zostać zmienione? Gdyby tak stworzyć wersję podstawową, powiedzmy mój-pakiet_1.0.0_all.deb. Następnie, w miarę poprawek (w stable) lub rozwoju (w testing/unstable), można by tworzyć do niej wersje delta mój-pakiet_1.2.1_all.deb. W skład takiego pliku wchodziłyby skrypty pre- i post- instalacyjne, plik konwersji konfiguracji, (jeśli taka by miała mieć miejsce lub o dokonfigurowaniu nowych opcji jeśli są wymagane) oraz oczywiście pliki różnicowe. Wiadomo, że przy większych zmianach, wymienia się większość plików, ale z drugiej strony często, przy modułowej budowie aplikacji występują pliki, które nie wymagają zmian. Wiadomo - wtedy, kiedy następuje rebuild wszystkiego albo gdy naprawdę stworzenie pliku zmian byłoby dłuższe niż nowy pakiet to lepiej budować nowy pakiet - ale czy często tak jest? Sprawa nie dotyczy jednak tylko plików .deb, ale wszystkich linux distro, któe zasypują użytkowników listą wielomegabajtowych poprawek. W końcu i Microsoft w końcu zmniejszył rozmiary swoich pakietów z poprawkami starając się je minimalizować (typowy cost-reduction)…

W ramach walki ze spamem przeszliśmy już przez MUA oraz wstępnie zabezpieczyliśmy MTA. Wstępnie, ponieważ nadal ktoś może podszyć się pod domenę z whitelisty a także nie wszędzie możemy zastosować greylisting. W tej sytuacji wyposażymy naszego postfixa w kolejne narzędzia.

Dwoma chyba najpopularniejszymi pakietami do walki ze spamem oraz wirusami są spamassassin oraz clamav. Ponieważ są to pakiety zewnętrzne, do integracji ich z postfixem użyjemy pośrednika - amavisd-new. Po instalacji odpowiednich pakietów, czyli standardowym aptitude install amavisd-new spamassassin clamav clamav-daemon clamav-freshclam otrzymujemy działające środowisko. Teraz musimy tylko poinstruować amavisa i postfixa jak z niego korzystać.

Read more »

W poprzednim artykule tyczącym się walki ze spamem na stacji klienckiej wspomniałem o konieczności przerzucenia ciężaru filtrowania na serwer. Ten sposób filtrowania ma niestety, jak każdy dobry kij, conajmniej dwa końce. Po pierwsze - musimy zapewnić użytkownikowi możliwość dotarcia do przesyłki, która jednak może spamem nie być (false positives), po drugie wszystkie wiadomości i tak są wrzucane na serwer - czyli mamy zajęte pasmo oraz przestrzeń dyskową.

Metodą, która pozwala obejść te minusy jest graylisting. Działa on w sposób bardzo prosty, wykorzystując sposób działania serwerów SMTP oraz typowe zasady działania spamerów.
Serwery SMTP próbują przesłać wiadomość ‘do skutku’, to znaczy jeśli sesja SMTP nie powiedzie się przy pierwszej próbie, po chwili (równej zazwyczaj długości kolejki i interwałowi jej opróżniania - wiadomość na serwerze wysyłającym przesuwana jest na koniec kolejki przy niemożności dostarczenia), próbują ponownie. Spamerzy zazwyczaj nie wysyłają wiadomości ponownie i ignorują kody błędów. Oznacza to, że jeśli przy pierwszej próbie wysłania nowej wiadomości serwer specjalnie odpowie kodem błędu, to “za chwilę” ta wiadomość jednak do niego dotrze. Jak każda metoda, także ta ma pewne minusy - pierwszym i podstawowym jest zgoda zarządu na jej wprowadzenie - niektóre firmy nie chcą/nie mogą pozwolić sobie na opóźnienia w przyjmowaniu poczty. Ponadto ze względów organizacyjnych wprowadza się często adres publiczny, na który może przychodzić niezamówiona oferta handlowa. Drugim powodem, techcznicznym, jest dodanie kolejnego punktu, gdzie może pojawić się problem w sposobie działania serwera pocztowego. Trzecim, także technicznym problemem są sytuacje, gdy serwer po uzyskaniu kodu 450 zaprzestaje prób i raportuje problem z wysłaniem wiadomości - niestety takie rzeczy także się zdarzają.

Sposobem na zminiminalizowanie opóźnień w kontaktach z partnerami biznesowymi jest stworzenie listy ich domen pocztowych i dodanie ich do białej listy domen, które nie będą poddawane graylistingowi. Oczywiście, jeśli nie jest wprowadzony SPF pozwalający na jako-taką weryfikację adresu nadawcy, to każdy kto wstawi sobie adres domeny z białej listy będzie mógł przesłać spam na nasz serwer pocztowy… Implikuje to niestety także konieczność zastosowania także innych metod walki ze spamem.

To tyle tytułem przydługiego wstępu o samej metodzie, w końcu warto jednak dać odpowiedź na temat - czyli jak dodać graylisting do naszego postfixa? Za przykład posłuży oczywiście mój ulubiony debian i jego pakiet postgrey - o którym warto poczytać na stronie autora. Paczki postgrey są dostępne także dla gentoo, fBSD oraz Fedory.
Jego instalacja jest prosta - komenda aptitude install postgrey spowoduje zainstalowanie dwóch pakietów libberkeleydb-perl oraz postgrey. Automatycznie po instalacji wstaje demon postgrey umiejscawiający się na porcie tcp 60000. Port oraz interfejs (domyślnie localhost) możemy zmodyfikować w /etc/default/postgrey. Możemy tam także zmodyfikować komunikat pojawiający się wraz z błędem 450 - wystarczy do opcji dodać parametr –greylist-text. Najprostsza część instalacji za nami.
Teraz musimy w /etc/postfix/main.cf dodać do smtpd_recipient_restrictions część check_policy_service inet:127.0.0.1:60000. Warto zastanowić się po jakich regułach dodamy tą wartość. U mnie występuje ona po permit_mynetworks, permit_sasl_authenticated co pozwala ominąć greylisting dla wysyłających z moich sieci oraz dla użytkowników zautentykowanych.

Po restarcie postfixa mamy już działający greylisting - jak teraz jednak dopuścić pracę bez graylistingu dla konkretnych domen oraz adresów? Odpowiednie pliki znajdują się w /etc/postgrey - są to odpowiednio whitelist_clients (częściowo zapełniony) oraz whitelist_recipients.

Na koniec ciekawostka - ze względu na te pliki właśnie, postgrey znajduje się także w repozytorium volatile…