vermin.eu.org

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ć?

Okazuje się, że dość łatwo odpowiedzieć na to pytanie. Sprawdzamy najpierw za pomocą lspci jego numer:

Teraz sprawdzamy jego identyfikator za pomocą lspci -n:

Wiemy już jak linux zidentyfikuje urządzenie - czy je obsłuży out-of-the-box? Otwieramy /lib/modules/`uname -r`/modules.pcimap i szukamy odpowiedniej linii - w naszym wypadku:

.

Źródło: red hat magazine, wrzesień 2006

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…

Powstał następujący problem - chciałem sobie włączyć film pod linuxem. Rzadko to robię, bo jednak jak jestem pod linuxem to pracuję, a relax mam pod Windowsem. Okazało się jednak, że totem, który jest domyślnie zainstalowany jako odtwarzacz filmów wywraca się przy starcie pisząc coś o katalogu mcop (can’t create mcop directory).
To było proste - wystarczyło stworzyć katalog o nazwie maszyny, a dokładniej wydać polecenie:

Niby pomogło, ale totem nadal wywracał się po starcie, sugerując zbyt mało pamięci (BadAlloc (insufficient resources for operation) BadRequest (invalid request code or no such operation)). Okazało się, że ładuje grafikę PNG (splashscreen), która po dekompresji coś mu się nie zgadzała i powodowała wyjątek. Super program swoją drogą, że niemożność załadowania splashscreena to krytyczny wyjątek…
Znowuż trzeba było odwołać się do operacji na plikach - tym razem wystarczyło zmienić rozmiar pliku totem_logo.png w /usr/share/totem na 800×600… lub go skasować. To nie powoduje problemów.

Haha! Teoretycznie już wszystko powinno działać! Niestety, tu na przeszkodzie stanęły dla odmiany sterowniki do chipsetu. Z niewiadomych przyczyn po starcie aplikacji film odtwarza się w miarę ok. Niemniej już drugie włączenie powoduje ostre zniekształcenia kontrastu i jasności - jakby jakieś wartości ustawiały się od razu w położeniach maksymalnych. Tego problemu na razie nie udało mi się zwalczyć

Jeśli używamy SBSa, to łącząc się z jego witryną możemy pod Windows załadować automagiczny programik, który nam sam skonfiguruje połączenie z siecią SBS. Oczywiście to żadna magia, chociaż w widoku połączeń sieciowych pod XP widać, coś co się nazywa magaer połączeń sieciowych. To samo można uzyskać dodając nowe połączenie i zestawiając normalne połączenie VPN.

Skoro można zestawić VPN, to czemu nie zrobić tego spod linuxa? To do roboty.
Po pierwsze instalujemy pakiecik pptp-linux, a następnie przystępujemy do jego banalnej konfiguracji.

1. W /etc/ppp/options.pptp dodajemy linię
   lock noauth nobsdcomp nodeflate

   ,

2. W /etc/ppp/chap-secrets dodajemy domenową nazwę logowania oraz hasło w następującej formie
   domena\\login PPTP hasło *
3. Tworzymy plik /etc/ppp/peers/nazwa_tunelu, w którym wpisujemy:
   pty “pptp serwer –nolaunchpppd”
   name domena\\login
   remotename PPTP
   require-mppe-128
   file /etc/ppp/options.pptp
   ipparam nazwa_tunelu
4. Teraz wystarczy wystartować tunel komendą pon nazwa_tunelu lub też, w celu zwiększenia diagnostyki pon nazwa_tunelu debug dump logfd 2 nodetach

Tunel zamykamy komendą poff. Niestety sam pon konfiguruje tunel, niemniej nie ustawia routingów, nie ustawia serwerów DNS - trzeba się tym zająć na własną rękę. Ponieważ dla mnie skonfigurowany tunel ma się automatycznie podnosić się przy starcie maszyny - wystarczyło do /etc/network/interfaces dodać następujące linijki rozwiązujące problemy trasowania.

Do /etc/if-up.d trzeba dodać mały skrypcik (jak napiszę to zamieszczę) który sprawdza czy interfejs ppp jest podniesiony i jeśli tak, to dodaje do /etc/resolv.conf linijkę zawierającą namiary tegoż nameserwera. Oczywiście w if-down.d trzeba zamieścić regułkę odwrotną, wyjmującą tegoż NSa z listy.

Źródło: PPTP

Mam na dysku laptopa kilka systemów - ze 3 XPki (każdy z innej domeny), Vistę i oczywiśce (last but not least) - Debiana. Miałem tych systemów o dwa więcej - wszystko było ładnie, wszystko było poustawiane. Wstawał boot loader visty z którego wybierałem starszego windowsa , a potem opcja linux i odpalał mi się grub. (Tak - mam 3 boot loadery.) Problem jednak z tym, że ten boot manager po porządkach na dysku zaczął mieć grobowe problemy.

Otóż po wyrzuceniu jednego ze zbędnych systemów na dysku zostało mi nieprzydzielone do niczego miejsce (reserved for future use). Niby żaden problem, ale dla GRUBa jednak jest. Otóż partycje linuxa znajdują się ZA tym wolnym miejscem. Oznacza to, że linux widzi patycję /boot jako /dev/sda9. Problem jest w tym, że dla GRUBa ta sama partycja oznaczana jest jako (hd0,8). No i teraz nie mogę tak ściągnąć boot sectora, żeby automatycznie mi się załadowało boot menu. Jeśli ściągnę tak jak powinienem, z /dev/sda9, to on po załadowaniu się się widzi… 10, czyli /. Jeśli ściągnę z /dev/sda8 - to nic się nie stanie, bo tam jest swap.

Nie mogę w żaden sposób, nie zmieniając kolejności partycji powiedzieć mu jak ma się ładować, nie pisząc ręcznie komend. Oczywiście, wystarczyłoby to wolne miejsce oznaczyć jako partycję i grubowi zacznie się wszystko zgadzać, niemniej to nie jest rozwiązanie na miarę geek’a, nieprawdaż? Any hints?

Dziennik Internautów podał intrygującego newsa, że HP będzie wspierać Debiana na swoich serwerach. Dla mnie to piękna wiadomość, w końcu będzie można pomendzić na infolinii jak coś nie zadziała poprawnie… Szkoda tylko, że FSC nie zdecydowało się na ten krok, wspierając jednak RH i Suse… Ile to czasu zabiera zanim zepsuje inną dystrybucję podobnie do tej, która naprawdę jest produkcyjna, żeby móc uzyskać support

Czasem może zdarzyć się, że ISP blokuje bezpośredni dostęp do portów 25 w sieciach znajdującej się poza jego domeną. Tak akurat dzieje się w lokalizacji gdzie aktualnie się znajduję, co oznacza, że trzeba własny serwer pocztowy przestawić na inny port. Oczywiście nie można go przestawić całkowicie, ponieważ inne serwery pocztowe nie porozumieją się z nami nie mogąc znaleźć punktu wejścia serwera.

Okazuje się jednak, że konfiguracja postfixa jest przygotowana na taką ewentualność. Jeśli mamy w posfixie uruchomiony mechanizm TLS to spokojnie możemy uruchomić postfixa na porcie 465 (smtps). Wystarczy w pliku /etc/postfix/master.cf odhaszować linijkę:

oraz oczywiście dodać regułkę do firewall’a przepuszczającą ruch na wzmiankowanym porcie
Warto zauważyć, że demon czuwający na porcie 465 nie przedstawia się tak ładnie jak ten porcie 25 - od razu wymaga rozpoczęcia negocjacji TLS.

Osięgniemy w ten sposób dwa cele - pierwszy z nich to możliwość wysyłania poczty, drugi - to pewność bezpiecznego skonfigurowania klientów pocztowych, którym oczywiście nakazujemy łączyć się z portem 465 zamiast 25. Pozostaje jeszcze problem dobrego dopasowania certyfikatów, ale to temat na inny art.

Na serwerze nie używaj jako domyślnej dla łańcucha INPUT polisy DENY. Lepiej użyć polisy ACCPET i dodać regułę

.

Dlaczego? Zrób czyszczenie reguł (

) przez ssh. Zrozumiesz.

A ze śmiesznych rzeczy - praca zdalna dziś: reboot drugiego komputera z laptopa, i patrzenie przez okulary na odległy o circa trzy metry monitor czy się komputer podniesie i co pisze w logach przy starcie.

Typowy scenariusz - mamy serwerek FTP, oczywiście chrootujemy użytkowników do katalogów domowych. Nagle okazuje się, że jeden z nich musi mieć dostęp do dodatkowych danych, np. utrzymać stronę WWW, którą do tej pory zajmował się inny użytkownik. Symlinki oczywiscie nie wchodzą w grę, ale jest kilka opcji:

• można dać mu kolejny login i hasło, (które zgubi, zapomni), co jest proste dla admina, ale niewygodne dla usera
• można przekopiować dane do jego katalogu, zmienić uprawnienia, zmienić konfigurację apache, co jest trudne, długie, wymaga restartu usługi, no i jak ten user odejdzie, to trzeba operację powtórzyć
• można też zastosować rzecz wygodną i dla admina i dla usera - czyli mount

W zasadzie wydanie komendy

załatwia nam sprawę (jak to jest na czas powyżej średniego uptime maszyny to warto to dodać do /etc/fstab). Proste, czyste, przyjemne

Źródło: MDLog:/sysadmin

Sobota, godziny popołudniowe, szybki look w logi i co widzę? Gdzieś w środku nocy, jakiś dzieciak zza oceanu wybrał sobie jeden z moich serwerków w celu przetestowania swoich narzędzi. Bardzo to niefajne, bo szybkie łącze pozwoliło mu na dosłownie zalanie serwera requestami o autoryzację - do DOSa nie doszło - niemniej jest to trochę wkurzające…

O ile SSH się w miarę łatwo zabezpiecza przed zbyt duża ilością wpisów, to już serwery FTP zabezpieczyć trudniej. Z pomocą przychodzą dwa narzędzia - pierwsze z nich to znane z pakietu *sentry Logsentry, zaś drugie, nad którym się skupię - fail2ban. Obydwa działają tak samo - monitorują logi i na tej zasadzie podejmują odpowiednie działania. Obydwa mają zbliżone zalety i tą samą wadę - regexpy¹. Obydwa używają /etc/deny.hosts lub iptables. Obydwu nie ma w stable

Fail2ban niestety nie znajduje się w stable - jest za to w testing i unstable, więc można go ściągnąć stamtąd lub bezpośrednio ze stron projektu Debian. Z wymogów instalacyjnych trzeba wspomnieć o pythonie i lsb-base, które na szczęście są w stable i to w odpowiednich wersjach. Po instalacji fail2ban od razu rozpoczyna działanie - niemniej dobrego admina to nie zadawala i od razu rusza do /etc/fail2ban.conf, żeby poprawić konfigurację.

Co warto zmienić? Na pewno warto dodać listę adresów, które nie będą blokowane (bo w końcu każdy może wysłać stworzone przez siebie pakiety wskazujące na dowolne IP) - opcja ignoreip. Kolejną opcją, którą warto zmienić, to czas blokady (bantime) - domyślne 10 minut to za mało - warto dać więcej, a mając fizyczny dostęp do maszyny nawet -1 (for ever). Jeśli ktoś lubi, to warto włączyć opcję powiadamiania emailem o zablokowaniu konkretnego IP (jeśli dostajemy wiadomości w stylu in-your-face, to trudniej zapomnieć, że taki niskopoziomowy mechanizm gdzieś tam sobie działa i można szybciej zdiagnozować problem). Pozostaje włączenie odpowiednich demonów, czyli zmiana enabled na true w odpowiednich sekcjach pliku konfiguracyjnego.
Domyślnie skrypt ma wpisane kilka typowych demonów - SSH (włączone domyślnie), SASL, Apache, ApacheAttacks, VSFTPD, PROFTPD, ale bazując na wyrażeniach regularnych¹ można dodać dowolne inne, co jest duuużym plusem. Kolejnym plusem jest przyjemna konfiguracja iptables, którą wykonuje program - tworzy własne łańcuchy opisujące przez jaką regułę dany IP został zablokowany, co pozwala łatwiej przejrzeć logi w razie narzekań userów czy innych adminów.

¹regexpy to mieszane błogosławieństwo - pozwalają na wspaniałe dostosowanie programu pod de facto dowolnego demona, niemniej pozwalają także na przemycenie, przez użycie zbyt szerokiego zakresu wyrażenia, błędów, pozwalających w tym wypadku na DOS maszyny…

Warto poczytać dodatkowo: Debian Administration