Wszystkie wpisy, których autorem jest w.trampczynski

Hermes

Wśród wielu sposobów walki ze spamem, oprócz typowych systemów antyspamowych (spamassassin, dspam), dużą popularność zyskały systemy oparte na tzw greylistingu. Program Hermes jest jednym z nich.
Zalety programu to niewielkie obciążenie systemu i duża niezawodność, nie są to bowiem skrypty w językach wysokiego poziomu i oprócz sqlite3 nie wymaga żadnych innych skryptów i programów dodatkowych. Przygotowanie go do pracy jest również bardzo proste. Współpracuje też z każdym MTA, który potrafimy przestawić ze standardowego portu na inny.

Pakiet instalujemy poleceniem pacman -S hermes (od 13.08.2007 jest w repozytorium testing). Po instalacji należy przejść do katalogu /etc/hermes i poddać edycji plik hermes.conf. Należy tam wpisać swoją domenę w dwóch liniach:
server_host = „twoja.domena.pl lub localhost” (jeśli po wpisaniu localhost, będą problemy, wpisac domenę)
hostname = „twoja.domena.pl”

Następnie należy zmienić sposób uruchamiania swojego MTA. W NND będzie to w 99,99% exim.
Jeśli mamy nieco starsza wersję, zmieniamy w /etc/rc.d/exim port z 25 na 2525.
Będzie wyglądać to tak:
/usr/sbin/exim -bd -q15m -oX 2525
Jest też możliwy inny sposób – bardziej elegancki.
W pliku startowym zostawiamy wyłącznie wpis /usr/sbin/exim -bd -q15m i resztę ustawiamy w pliku exim.conf, dodając w sekcji MAIN CONFIGURATION (można na samym początku):
daemon_smtp_ports = 2525 : 465
tls_on_connect_ports = 465

W przypadku NND, exima i hermesa to jest już koniec czynności konfiguracyjnych. Jeśli mamy inny MTA, to należy się dobrze przyjrzeć plikowi konfiguracyjnemu. Trzeba będzie jeszcze zmienić ścieżkę do plików klucza i certyfikatu, no i zastanowić się w jaki sposób demona smtp uruchomić na innym porcie.
Teraz wystarczy wykonać dwie czynności:
/etc/rc.d/exim restart
/etc/rc.d/hermes start (należy hermes dopisać do sekcji DAEMONS w rc.conf)
Możemy z jakiegoś innego hosta sprawdzić działanie programu, używając komendy telnet nasza.domena 25. Poniżej listing tego polecenia:

[maciek@klaptop ~]$ telnet domena.org 25
Trying 83.21.201.21…
Connected to domena.org.
Escape character is ‚^]’.
220 domena.org ESMTP

EHLO [127.0.0.1]
250-domena.org
250-AUTH CRAM-MD5
250-AUTH=CRAM-MD5
250-STARTTLS
250-SIZE 8388608
250 8BITMIME

MAIL FROM: maciek@domena
250 ok
RCPT TO: maciek@inna.domena
421 Greylisted!! Please try again in a few minutes.

Pochyłą czcionką zaznaczono te fragmenty, które są odpowiedziami serwera.
Łatwo zauważyć, że hermes wprowadza krótkie opóźnienia w komunikacji. Większość automatów spamerskich nie czeka na odpowiedzi serwera, tylko od razu wysyłają ciąg komend (MAIL FROM, RCPT TO, DATA), w tym wypadku brak komunikacji dwustronej spowoduje, że kolejne po pierwszej komendzie pójdą w niebyt, bowiem hermes wymaga komunikacji dwustronnej. Jeśli jednak automat jest doskonalszy i ma możliwość dwustronnej komunikacji, i zgadza się na opóźnienia, to dostaje komunikat o błędzie tymczasowym 421 z komentarzem „Greylisted! Please try again in a few minutes.” Spamerzy nie mają czasu na takie zabawy, więc nie spróbują tego maila wysłać ponownie za kilka minut. Zapewne spróbują później, ale najczęściej z innym losowo wybranym nadawcą i być moze z innego IP, a to uruchomi ponownie całą procedurę.
Normalny serwer smtp połaczy się po kilku minutach i wtedy poczta zostanie przyjęta bez problemu. Z doświadczeń wynika, że serwery na eximie, postfixie i qmailu radza sobie z tym bez problemu, jedynie na eximie 3.36 można było zaobserwowac czasami opóźnienie większe niż kilka minut.
Dodatkową zaletą programu jest to, że tworzy on sobie białą listę nadawców, którzy są przetrzymywani przez 36 dni. W ten sposób nasz stały korespondent zostanie opóźniony tylko przy pierwszym połączeniu. Apetyt na zasoby systemowe hermes ma naprawdę niewielki, bowiem nie analizuje listów, a jedynie na moment odwołuje się do swojej bazy w celu sprawdzenia serwera i nadawcy.
Na koniec jeszcze mała uwaga o pewnej wadzie hermesa. Należy zmienić ustawienia w programach pocztowych naszych użytkowników, o ile nadal korzystają z mało bezpiecznego portu 25. Ponieważ w wielu publikacjach podkreślano, że najlepiej używać smtps na porcie 465, więc mam nadzieję, że większość użytkowników konfiguruje bezpieczną pocztę z SSL. Jednak jeśli ktoś korzystał z portu 25, w swoim programie pocztowym musi go zmienić na 2525. Zaś administrator w ustawieniach firewalla powinien otworzyć ten port. W standardowym firewallu NND można dodać linijkę:
$i -A INPUT -p tcp -i $EXTIF –dport 2525 -j ACCEPT
w sekcji dotyczącej poczty.
Użytkownicy zaawansowani mogą skorzystać także z innych opcji hermesa – posiada on możliwość współpracowania z serwerami blacklist i whitelist, a także możliwość ustawienia procentu restrykcyjności korzystania z tych list. Obecnie wydaje się, że hermes jest najprostszym i jednocześnie bardzo skutecznym sposobem walki ze spamem.
Uzupełnienia
Do pakietu zostały dodane dwa skrypty hermes_black i hermes_white – skrypty pozwalają z konsoli w bardzo prosty sposób, bez zagłębiania się w niuanse działania sqlite3, ręcznie przeglądać czarną i białą listę, dodawać i usuwać wpisy. Jest to niezwykle przydatne np. gdy dostajemy pocztę z gmail.com, który co 15 minut ponawia wysyłanie poczty z innego numeru IP. Po dodaniu tych IP do białej listy nie ma już problemu z otrzymywaniem poczty od użytkowników gmaila.
Jako dodatek do hermesa powstał hermes-panel. Jest to zestaw skryptów www, które uruchomimy mając serwer www i php. Pierwszą czynnością po instalacji musi być założenie pliku .htaccess i ustawienie usera oraz hasła do panelu. Bez tego, będzie on dostępny dla każdego. Panel służy do dodawania IP do białej listy, przeglądanie szarej i dodawanie wpisów własnych do czarnej listy, wymaga apache i php.
Znane problemy
Niewiele osób na razie sprawdziło pakiet. W chwili uzupełniania artykułu znane mi są dwa problemy na sześc działających instalacji. Jeden z problemów to być może nieprawidłowo założona baza przy pierwszym starcie programu, należy wówczas bazę usunąc i uruchomić program na nowo – po sprawdzeniu praw katalogu /var/lib/hermes.
Drugi problem wynikał z nieprawidłowej identyfikacji sieciowej. Brakowało interfejsu lo i odpowiedniego wpisu w hosts dotyczącego 127.0.0.1. W razie problemów z resolwowaniem nazwy serwera należy w zmiennej „server_host” wpisac albo numer IP komputera w LAN,  albo IP zewnętrzne (w przypadku serwera forwardowanego raczej to pierwsze). Wpisanie localhost – jak to zostało podane w dyskusji na forum, owszem skutkuje, ale exim staje się open relay.

autor: W. Trąmpczyński (Maciek)

DSPAM – panel użytkownika

Jednym z plusów używania systemu DSPAM jest wygodny sposób zarządzania przez administratora, a także przez każdego użytkownika. W połączeniu z wysoką skutecznością programu, używanie systemu staje się wręcz przyjemne.
Logo, jakie wymyślił autor programu Jonathan Zdzierski jest adekwatne to możliwości.
Logo Dspam

Panel dla użytkownika zawiera Centrum kontroli z zakładkami, których najważniejsza jest Historia. Znajduje sę tam historia ostatnich kilkuset maili użytkownika. Każdy oznaczony odpowiednim kolorem i napisem.

Oznaczenia

Maile oznaczone jako Resend to te, które zostały przez użytkownika lub administratora powtórnie przesłane przy użyciu funkcji Redirect, czasem także sam system je oznacza jako wymagające uwagi. Używając funkcji Retrain można, zmienić kwalifikacje danego maila, jeśli jest błędna.
Zmiana kwalifikacji

Oznaczenie na danym mailu zmienia się na Miss i kolor również w zależności, jak mail został oznaczony.

Miss

W zakładce Analiza każdy użytkownik może zobaczyć, statystykę odwzorowaną graficznie. Są dwa wykresy, jeden przedstawia ostatnia dobę, drugi okres dwóch tygodni.

Wykres

W zakładce Kwarantanna są maile zakwalifikowane jako spam. Można zobaczyć punktację, zaznaczyć dany mail do usunięcia lub zobaczyć jego zawartość.

Kwarantanna

W podglądzie maila nie działa opcja Dostarcz (wynika to z problemów na linii exim – dspam). Jednak na podstawie adresu można użyć własnego programu pocztowego, aby po przeczytaniu maila ewentualnie odpisać. Oczywiscie można też użyć opcji Retrain, aby skorygować na przyszłość decyzje systemu.
Administrator ma dodatkowy panel, na którym widzi dane o pracy systemu.

System

Może także zobaczyć ile maili przyszło w ciagu ostatniej doby i godziny.

Dane admina

Może też zobaczyć wykres godzinowy w ciągu ostatniej doby i wykres dzienny z ostatniego miesiąca.

Wykres - dni

Może także obejrzeć statystyki użytkowników, sprawdzić czy skrzynka ze spamem u któregoś nie jest zbyt duża i w razie potrzeby ją oczyścić. Może też dokonywac operacji Retrain na mailach każdego użytkownika. Funkcja istotna tam, gdzie admin musi czuwać nad całością poczty (np. w jakiejś instytucji, czy firmie).
Samo używanie panelu jest bardzo łatwe i dowolnie wybrany użytkownik poczty może być administartorem panelu. Ustala się to w pliku admins w /home/httpd/dspam/cgi-bin. Tam też znajduje się plik configure.pl. w którym ustawiamy adres naszego serwera. Tak więc instalacja i konfiguracja nie jest trudna, jednak wcześniej trzeba zainstalować mod_perl apache (informacja zmian w httpd.conf, wyświetla się po zainstalowaniu panelu) i kilka dodatkowych modułów perla: ‚mod_perl’ ‚perl-error’ ‚perl-digest-sha1’ ‚perl-cache-cache’ ‚perl-apache-authpop3’ ‚perl-gd’ ‚perl-gd-graph’ ‚perl-gd-graph3d’ ‚perl-gdtextutil’ – system nie był sprawdzany na innym serwerze www niż apache. Warunkiem krytycznym jest obsługa skryptów perla i zainstalowane moduły umożliwiające logowanie użytkowników poczty. Dodatkowo potrzebne są moduły umożliwiające wyświetlanie wykresów.
Aby działała funkcja Retrain i pokazywanie statystyk użytkowników należy dodać w /etc/sudoers dwa wpisy:
nobody ALL=(ALL) NOPASSWD: /usr/bin/dspam
nobody ALL=(ALL) NOPASSWD: /usr/bin/dspam_stats
Przy czym trzeba zaznaczyć, że ta ostatnia opcja działa tylko w połaczeniu z bazą mysql. Jeśli administrator zdecyduje się używać dspam bez bazy, panel nie będzie miał skąd wyświetlić statystyk użytkowników. Będą jednak działać pozostałe funkcje, które dane biora bezpośrednio z logów.
W konfiguracji apache należy dodać (po innych modułach):
LoadModule perl_module           /usr/lib/apache/mod_perl.so
oraz po wpisie ScriptAlias dla cgi:
ScriptAlias /dspam/ /home/httpd/dspam/cgi-bin/
Alias /dspam-files/ /home/httpd/dspam/htdocs/
<Directory /home/httpd/dspam/cgi-bin>
Options None
AllowOverride AuthConfig
Order allow,deny
Allow from all
</Directory>

Oczywiście po zmianach w konfiguracji serwera www, należy go uruchomić ponownie.

autor: W. Trąmpczyński (Maciek)

No już… przysyłaj mi Viagrę…

Spam staje się problemem numer jeden internetu. W zasadzie nawet małe serwery nie mogą obejść się bez jakiegoś systemu antyspamowego. Chcę zaproponować użytkownikom NND jeden z nich.

DSPAM jest programem napisanym w c++ stosującym w pracy klasyfikator bayesowski oraz testy Chi-Square i ocenę Markowa, chained tokens, BNR (Redukcja szumu bayesowskiego) i inne połączone metody. Nadaje się zarówno na małe, jak i rozbudowane systemy. Jest wydajny, szybki i nieźle wspólpracuje z eximem.
Zaletą jest dość intuicyjny panel ze statystykami i możliwością zarządzania – dla każdego użytkownika z osobna.

Administrator widzi wykresy całego systemu, może oglądać statystyki użytkowników, wykonywać czynności administracyjne dotyczące ich kont.

Oczywiście program może być także używany bez panelu www i z wykorzystaniem wyłącznie własnej bazy tekstowej. Jednak jeśli moc serwera pozwala, warto zainstalować także panel i mysql, aby ułatwić sobie pracę.
Przed przystąpieniem do instalacji należy wypisać sobie wszystkich użytkowników poczty do pliku /etc/mail/mailusers.
Jeśli jest ich kilku, można do zrobic ręcznie, w przypadku większej ilości mozna pomóc sobie poleceniem ls -w 1 /home, które w kolumnie pokaże nam całą zawartość /home i wystarczy zawartość ekranu skopiować oraz usunąć katalogi nienależące do użytkowników (np. httpd). Na końcu pliku musi byc pusta linia inaczej skrypty potraktują ostatniego użytkownika po macoszemu.
Kolejnym krokiem jest instalacja (w zależności od źródła użyjemy opcji -S lub -U). Po instalacji na ekranie wyświetli się instrukcja konfiguracji. Nie jest ona szczególnie skomplikowana, lecz dla tych mają „pamięć dobrą, ale krótką” dobra rada – skopiujcie tekst do jakiegoś edytora, aby można było powtórnie go przeczytać.
Konfiguracja
Są rozmaite możliwości konfiguracji.
A) Najprostsze jest wyłącznie znakowanie maili. Wystarczy jedynie skonfigurować exima z nowym plikiem, oraz zmienić nazwę pliku dspam.conf.hsash na dspam.conf. Można pominąć naukę, choć program będzie się częściej mylił i trzeba będzie go uczyć odsyłając mu wadliwe maile.
Druga możliwość to użycie również pliku dspam.conf.hash (czyli bez bazy mysql) i wstępny ręczny trening na własnych próbkach pojedyncze maile zgromadzone w katalogach (dspam_train nzawa-usera /katalog/spam /katalog/nospam).
Można łatwiej skorzystać z przygotowanych skryptów dspam_mbox_spam i dspam_mbox_nospam, ale trzeba sporządzić w /etc/mail spis użytkowników o nazwie mailusers.
Tak zakończyć można najprostszą konfigurację. Sugeruję jednak więcej wysiłku, co pozwoli cieszyć się potem łatwym zarządzaniem spamem.
B) Pierwszym krokiem będzie zmiana konfiguracji exima, dołączony plik exim.conf.dspam trzeba wyedytować, wpisując własną domenę i zmienić jego nazwę na exim.conf, swój stary plik warto zachować jako exim.conf.old.
Po zainstalowaniu programu utworzyć bazę danych dspam i założyć tabele w tej bazie. Plik dspam.sql znajduje się w /var/dspam. Można to zrobić w linii poleceń, ale zapewne jest to przyjemniejsze przy użyciu phpMyAdmin.
Używanie dspam z bazą mysql jest domyślne, choć można z tego zrezygnować. Z bazą mysql program działa szybciej i sprawniej. Dopiszemy też użytkownika bazy i haslo do pliku dspam.conf.
Następnie należy uruchomić kolejno skrypty automatyzujące czynności konfiguracyjne, ale wcześniej upewnić się, że mamy już w /etc/mail plik mailusers z nazwami użytkowników.
dspam_files – skrypt, który tworzy w /var/dspam/data potrzebne pliki dla każdego użytkownika z /etc/mail/mailusers i nadaje im odpowiednie prawa.
dspam_mbox_spam i dspam_mbox_nospam – te skrypty mają zadanie wykonać uczenie wstępne programu dla każdego użytkownika wpisanego w /etc/mail/mailusers.
Jeśli użytkownik ma własne maile do nauki w postaci jeden plik = jeden mail, może użyć skryptu dspam_learndir.
W późniejszym okresie do powtórnego treningu służy skrypt dspam_train (używany z parametrami user /katalog/spam /katalog/nospam).
dspam_procmail – skrypt domyślnie kieruje spam do skrzynki użytkownika w /var/dspam/$user/$user.mbox, wymaga to oczywiście użycia panelu www. Inaczej użytkownik plików nie obejrzy. Można wcześniej zdecydować się na inne rozwiązanie. Jeśli na serwerze jest używany Squirrelmail, który tworzy w katalogu użytkownika plik FOLDER.Kosz to można tam właśnie skierować spam. Można utworzyć specjalne konto spamcheck i kierować cały spam do /var/mail/spamcheck, administrator może to konto obsługiwac w swoim programie pocztowym i zarządzać spamem. Dwa ostatnie sposoby nie wymagają instalowania panelu, jednak koniecznie trzeba używać opery lub thunderbirda z wtyczką redirect. Korygowanie decyzji dspam wymaga użycia opcji „Przeadresuj”. Ostatnim sposobem jest brak wszelkich akcji, oznaczone maile wędrują do użytkownika i on decyduje, co z nimi zrobić. Jednak moim zdaniem to dla użytkownika nie oznacza żadnej zmiany, nadal będzie dostawał spam, tyle, że może filtrowanie będzie nieco łatwiejsze.
Przykładowy plik .procmailrc wygląda następująco:
MAILDIR=$HOME
PMDIR=$HOME/.procmail
LOGFILE=$HOME/procmail.log
SHELL=/bin/sh

# segregowanie spamu
:0
*^X-DSPAM-Result: Spam
# kosz usera w squirrelmail (nie wymaga panelu dspam)
#/home/nazwa/FOLDER.Kosz
# domyślnie – skrzynka dspam usera (wymaga panelu dspam
/var/dspam/data/nazwa/nazwa.mbox
# mbox usera spamcheck (trzeba go utworzyć, nie wymaga panelu dspam)
# mbox musi mieć prawa 660 (jest 600)
#/var/spool/mail/spamcheck

# reszta poczty
:0
/var/spool/mail/nazwa

Jeśli w przyszłości administrator bedzie dodawał ręcznie nowe konta i będzie chciał włączyć segregację spamu dla użytkownika, musi pamiętać dokonaniu koniecznych zmian w pliku.
To jest ostatni skrypt jaki trzeba wykonać.
Użytkowanie
Jeśli już wykonane zostały wszystkie czynności konfiguracyjne, mozna uruchomić /etc/rc.d/dspam start. Jak już wcześniej napisałem, możemy używać dspam bez mysql, procmaila, apacza i panelu. Jednak sprawniej będzie jeśli zainstalujemy także dodatki.
Opcją zalecaną jest dopisanie dspam do sekcji DAEMONS w rc.conf. Program działa dzięki temu sprawniej, nie jest wywoływany osobny proces dla każdego maila. Wyniki są natychmiast zapisywane do bazy mysql (w przeciwnym razie należałoby co pewien czas używać programu dspam_2sql).
Jeśli używamy dspam bez panelu, każdy spam trzeba odesłać na adres login-spam@twoja.domena, w ten spsoób program się uczy. Ze znanych mi programów jedynie opera i thunderbird (z wtyczką redirect) mają opcję „Przeadresuj”.
W panelu można użyć opcji „Retrain”.
Zarządzanie spamem dobrze jest zorganizowane własnie w panelu, ponieważ może to robić i administrator, i każdy użytkownik.
System przetestowałem najpierw kilkakrotnie na serwerze testowym, a potem na działającym serwerze produkcyjnym. Przez kilka dni zbierałem cały spam na osobnym koncie pocztowym. Pomyłek typu false_positives było naprawdę niewiele i takie maile forwardowałem użytkownikom na ich konta. Po kilku dniach praktycznie ich już nie było. Obserwując pracę systemu na bieżąco widzę, że ilość przepuszczonego spamu jest naprawdę minimalna.
Uwagi końcowe
Przygotowując pakiet starałem się, aby jego konfiguracja po instalacji była maksymalnie uproszczona. Dlatego też wbrew opinii niektórych kolegów zdecydowałem, że opcją domyślną będzie użycie panelu i kierowanie tam spamu. Uważałem, że dostarczenie programu, który domyślnie nic nie robi, a jego faktyczne uruchomienie wymaga dopiero działania, nie bardzo ma sens. Oczywiście jeśli komuś bardzo zależy aby przynajmniej na poczatku program faktycznie nic nie robił, wystarczy, że wybierze najprostszą wersję konfiguracji i pominie trening, nawet wtedy program będzie działać. Uczyć program można ogladając w nagłowku znacznik X-DSPAM-Result, jeśli będzie błędna diagnoza, mail odsyłamy na user-spam@domena (dla spamu) lub user-notspam@domena (jeśli znacznik wskazuje na spam, a mail spamem nie jest).
Więcej informacji o codziennym używaniu programu można znaleźć w artykule o panelu www dspam.

Notatka: autor: W. Trąmpczyński (Maciek)

Arpalert

Bezpieczeństwo sieci staje się dziś coraz ważniejszym zagadnieniem, szczególnie wtedy, gdy mamy do czynienia z sieciami radiowymi. W dużych profesjonalnych sieciach używa się skomplikowanych nieraz, ale skutecznych rozwiązań. NND jest przeznaczone dla małych sieci, często działa na niezbyt wydajnych komputerach, jak zatem zabezpieczać sieć, przy użyciu małych ale także skutecznych narzędzi? Jednym z nich jest program arpalert.

Najpierw należy zainstalować odpowiedni pakiet.
Pobieramy go stąd.
Pakiet ma swoje pliki konfiguracyjne w /etc/arpalert i musimy zacząć od edycji pliku arpalert.conf i dokonac w nim kilku zmian. Po pierwsze znajdujemy linię z wpisem user = arpalert, mamy do wyboru – utworzyć użytkownika arpalert i zgodnie z plikiem konfiguracyjnym ten użytkownik będzie uruchamiał program, utworzyć i wpisac innnego użytkownika lub wpisac użytkownika root, co może być pożyteczne, gdy będziemy chcieli uruchamiać jakieś skrypty wymagające przywilejów roota.
Następnie znajdujemy linię #interface = eth0 i odkomentowujemy ją (usuwamy #) oraz wpisujemy własny interfejs, na którym nasłuchiwac będzie program.
W zasadzie to już wystarczy, aby uruchomić program. Jednak arpalert ma służyć jako pies łańcuchowy, który będzie strzegł naszej sieci, przed niepowołanymi komputerami, które będą chciały skorzystac z naszej sieci. Zatem musimy wykonać jeszcze kilka czynności, które pozwolą arpalertowi szczekać a nawet gryźć.
W przypadku sieci LAN, do której nie jest tak łatwo się pdpiąć, wystarczy jeśli zastosujemy dodatkowy skrypt, który będzie np. wysyłał mail lub sms do administratora w przyapdku nowego MAC lub zmiany IP. W przypadku sieci WLAN warto rozważyć uruchomienie skryptu, który w takim wypadku podejmie automatyczne działania.
Szczególnie w wypadku WLAN zapewne działa DHCP przyznający stałe numery IP powiązane z MAC karty, a nawet wyłączony DHCP i numery IP ustawiane na stałe w kazdym kliencie (bezpieczniej), a do tego arp wiązący IP z MAC komputera. Musimy wypełnic plik konfiguracyjny maclist.allow, który jest „białą listą” programu.
Wpisujemy tam wszystkie komputery w naszej sieci według schematu: „00:07:95:50:97:c0 192.168.1.5 eth0”.
Od tego momentu arpalert będzie zauważał wszystkie nowe i nieautoryzowane „białą listą” adresy MAC. Początkowe doświadczenia wskazują też, że należy utworzyć plik konfiguracyjny authrq.conf z wpisami „[00:07:95:50:97:c0 eth0] 192.168.1.0/24” dla każdego komputera, który może miec dostęp do sieci.
Po pierwszym uruchomieniu program zapisze plik /var/lib/arpalert/arpalert.leases (chyba warto pamiętać o okresowym czyszczeniu tego pliku). Program można uruchamiac z różnymi opcjami, które pokaże help:
[root@router lib]# arpalert -h

arpalert [-f config_file] [-i network_interface]
[-p pid_file] [-e exec_script] [-D log_level]
[-l leases_file] [-d] [-f] [-v] [-h] [-w]
[-P][-V]

-f conf_file: configuration file
-i devices: comma separated list of interfaces
-p pid_file: file with pid of daemon
-e script: script executed whith alerts
-D loglevel: loglevel (0 to 7)
-l leases: file to store mac addresses
-d: run as daemon
-F: run in foreground
-v: dump config
-h: this help
-w: debug option: print a dump of paquets captured
(loglevel 7)
-P: run in promiscuous mode
-V: version
Na swój użytek do testów stworzyłem skrypt arpalert.sh z następująca zawartością:
#!/bin/bash
NOWYMAC=`awk /mac/'{ print $6 }’ /var/log/arpalert.log |cut -c 5-21`
iptables -I FORWARD -m mac –mac $NOWYMAC -j REJECT
echo „nowy zapis
” >/var/log/arpalert.log

Program uruchomiłem z opcjami arpalert -e /usr/local/sbin/arpalert.sh -d – arpalert uruchomił się jako demon i po podłączeniu do sieci nowego komputera wykonał regułę iptables, która nowemu komputerowi zablokowała dostęp do internetu, dodanie jeszcze reguły z INPUT odetnie go całkowicie. Oczywiście przydałoby się, aby za stworzenie regułek wziął się jakis fachowiec i napisał taką, która zablokuje dostęp do sieci ponad wszelką wątpliwość. Czas reakcji programu zwykle nie przekracza kilku sekund, więc mało prawdopodobne, że włamywacz zdąży cokolwiek zrobić zanim zostanie zablokowany.
Uwagi końcowe.
Ten opis został przygotowany na bieżąco, bez szczegółowej analizy i długich doświadczeń, zatem może się zdarzyć, że ulegnie zmianom w przyszłości, najprawdopodobniej program ma sporo innych możliwości, których jeszcze nie odkryłem, niestety dokumentacja jest dość uboga. Liczę na współpracę innych użytkowników NND.
Poniżej jeszcze podaję zawartość pliki arpalert.conf, aby ułatwić chętnym porównanie. Plik jest bardzo rozbudowany, stąd moje przypuszczenie, że program ma jeszcze wiele niewykorzystanych możliwości.

# white list
maclist file = „/etc/arpalert/maclist.allow”

# black list
maclist alert file = „/etc/arpalert/maclist.deny”

# dump file
maclist leases file = „/var/lib/arpalert/arpalert.leases”

# list of authorized request
auth request file = /etc/arpalert/authrq.conf

# log file
log file = „/var/log/arpalert.log”

# pid file
lock file = „/var/run/arpalert.pid”

# log level
use syslog = true

# log level
log level = 6

# user for privilege separation
user = root

# rights for file creation
umask = 177

# only for debugging: this dump paquet received on standard outpu
dump paquet = false

# run the program as daemon ?
daemon = false

# minimun time to wait between two leases dump
dump inter = 5

#Configure the network for catch only arp request.
#The detection type „new_mac” is desactived.
#This mode is used for CPU saving if Arpalert is running on a router
catch only arp = true

# comma separated interfaces to lesson
# if not precised, the soft select the first interface.
# by default select the first interface encontered
interface = eth0

# script launched on each detection
# parameters are: „mac adress of requestor” „ip of requestor” „supp. parm.” „type of alert”
# type of alert:
# 0: ip change
# 1: mac address only detected but not in whithe list
# 2: mac address in black list
# 3: new mac address
# 4: unauthorized arp request
# 5: abusive number of arp request detected
# 6: ethernet mac address different from arp mac address
# 6: ethernet mac address different from arp mac address
# 7: global flood detection
# 8: new mac adress without ip
# 9: mac change
action on detect = „type of alert”

# module launched on each detection
mod on detect = „”
# this chain is transfered to the init function of module loaded
mod config = „”

# script execution timeout (seconds)
execution timeout = 5

# maximun simultaneous lanched script
max alert = 20

# what data are dumped in leases file
dump black list = false
dump white list = true
dump new address = true

# after this time a mac adress is removed from memory (seconds) (default 1 month)
mac timeout = 259200

# after this limit the memory hash is cleaned (protect to arp flood)
max entry = 1000000

# this permit to send only one mismatch alert in this time (in seconds)
anti flood interval = 5
# if the number of arp request in seconds exceed this value, all alerts are ignored for
# „anti flood interval” time
anti flood global = 50

# vendor name
mac vendor file = „/etc/arpalert/oui.txt”
log mac vendor = true
alert mac vendor = true
mod mac vendor = true

# log if the adress is referenced in hash but is not in white list
log referenced address = false
alert on referenced address = false
mod on referenced address = false

# log if the mac adress is in black list
log deny address = true
alert on deny address = true
mod on deny address = true

# log if the adress isn’t referenced
log new address = true
alert on new address = true
mod on new address = true

# log if the adress isn’t referenced (for mac adress only)
log new mac address = true
alert on new mac address = true
mod on new mac address = true

# log if the ip adress id different from the last arp request with the same mac adress
log ip change = true
alert on ip change = true
mod on ip change = true

# log if the ip adress id different from the last arp request with the same mac adress
log mac change = true
alert on mac change = true
mod on mac change = true

# unauthorized arp request:
# log all the request not authorized in auth file
log unauth request = false
alert on unauth request = false
mod on unauth request = false
# dont analyse arp request for unknow hosts (not in white list)
ignore unknown sender = false
# ignore arp request with mac adresse of the lessoned interfaces for the authorizations checks
ignore me = true
# ignore windows self test
ignore self test = false
# suspend time method:
# 1: ignore all unauth alerts during „anti flood interval” time
# 2: ignore only tuple (mac address, ip address) during „anti flood interval” time
unauth ignore time method = 2

# log if the number of request per seconds are > „max request”
log request abus = true
alert on request abus = true
mod on request abus = true
# maximun request authorized by second
Max request = 1000000

# log if the ethernet mac address are different than the arp amc address (only for requestor)
log mac error = true
alert on mac error = true
mod on mac error = true

# log if have too many arp request per seconds
log flood = true
alert on flood = true
mod on flood = true

Lekki i szybki, ale nie słaby

Serwery z systemem NND pracują na różnym sprzęcie. Czasem niezbyt wydajnym. Jeśli trzeba na takim słabym sprzęcie uruchomić serwer www, to okazuje się, że wspólpraca z apache odbija się czkawką. Wbudowany w NND thttpd ma zaś mizerne możliwości. Jest jednak alternatywa – lighttpd (http://www.lighttpd.net). Poniżej dokładny artykuł Andrzeja na ten temat.

Serwer Apache jest bardzo popularnym i solidnym serwerem WWW. Nie dziwi więc powszechne używanie jego modułów do obsługi Perla, PHP czy Pythona. Przywiązanie do mod_php, czy mod_python wiąże nas na dobre i złe z tym serwerem. Większe pole manewru daje nam korzystanie z FastCGI. Nie dość, że zyskujemy większą uniwersalność, objawiającą się możliwością wyboru odpowiadającego nam serwera WWW z całej gamy dostępnych programów, to jeszcze niektóre frameworki (Aranha czy Ruby on Rails) „odwdzięczą” nam się lepszą pracą i mniejszym zużyciem pamięci. Inną kwestią jest stabilność. Ponieważ moduły Apache’a są związane z rdzeniem serwera poważny błąd w skryptach przez nie obsługiwanych może odbić się bardzo niebezpiecznie na stabilności całego serwera. Procesy FastCGI są izolowane od serwera. Jak któryś się zawiesi, to serwerowi nic się nie stanie. Proces można ubić, zrestartować. Daje to znacznie większą stabilność pracy serwera. Ostatnią, ale bardzo istotną kwestią jest bezpieczeństwo. Każdy skrypt odpalany w trybie mod_php, mod_python czy mod_perl na Apache’u jest odpalany w kontekście tego samego uzytkownika. Tworzy to dosyć poważną dziurę bezpieczeństwa na serwerach hostingowych. Każdy użytkownik na serwerze za pomocą prostego kodu PHP może przeglądać źródła dowolnego pliku innych użytkowników. Wszyscy mają dostęp do wszystkich! W FastCGI tego problemu nie ma. Kod skryptu można uruchomić na prawach użytkownika a nie serwera WWW, dzięki czemu można pracować w pełnej izolacji. Dlaczego w takim razie nie stosuje się FastCGI w Apache’u ?
Odpowiedź jest prosta – moduł FastCGI do Apache’a ma opinię nie do końca stabilnego i dopracowanego. 🙂
Jest to pierwszy powód, dla którego zwróciłem uwagę na serwer Lighttpd, który od samego początku kładł nacisk na dobrą implementację swego modułu FastCGI. Jest on stabilniejszy i lepiej dopracowany niż pod Apache.
Innymi zaletami Lighttpd jest szybkość, niewielkie zasoby zajmowane na dysku i dość spore możliwości. Ten serwer WWW obsłuży nam nie tylko statyczne strony w HTML, ale również dość skomplikowane portale napisane w PHP czy Ruby z użyciem baz danych mysql. Mając taki portal nie unikniemy obciążenia systemu przez mysql i php, ale nie dodamy do zajętych zasobów dość wymagającego serwera Apache.
Wstępne porównania przeprowadzone przez Maćka na komputerze P350 ze 128 MB RAM pokazały korzyści. Proces lighttpd ani razu nie znalazł się na czele listy top i strony były serwowane wyraźnie sprawniej. Na szybszych komputerach też jest widoczna różnica w serwowaniu dynamicznie generowanej zawartości. I tak na Celeronie 1,7 GHz (Wilamette) i 512 MB pamięci różnica szybkości działania systemu akwizycji danych napisanego w PHP pod Lighttpd w porównaniu do mod_php pod Apachem przewyższa 50%.
Także od strony administracyjnej Lighttpd ma kilka zalet, a przede wszystkim łatwą konfigurację. Jeden plik konfiguracyjny lighttpd.conf znajdujący się domyślnie w katalogu /etc/lighttpd/. Do poprawnej pracy w pliku konfiguracyjnym wystarczą wpisy:

server.document-root = „/var/www/”

server.port = 80

mimetype.assign = (
„.html” => „text/html”,
„.txt” => „text/plain”,
„.jpg” => „image/jpeg”,
„.png” => „image/png”
)

static-file.exclude-extensions = ( „.rb”, „.pl”, „.fcgi”, „.php”, „~”, „.inc” )

server.indexfiles = ( „index.htm”, „index.html”, „index.rb”)
ssi.extension = ( „shtml” )
server.modules = ( „mod_cgi”, „mod_ssi” )

cgi.assign = ( „.pl” => „/usr/bin/perl”,
„.sh” => „”,
„.cgi” => „/usr/bin/perl” )

Przy prawidłowym uruchomieniu taki wychudzony konfig pozwoli nam mieć serwer HTTP pracujący na zadanym porcie, z obsługą CGI oraz mechanizmu Server Side Includes. Plik konfiguracyjny znajdujący się w pakiecie do NND jest znacznie bardziej skomplikowany. Większość opcji jest poprzedzona znakiem „#”, a co za tym idzie nieaktywna. Na stronie http://trac.lighttpd.net/trac/wiki/Docs%3AConfigurationOptions dostępny jest szczegółowy opis konfiguracji parametrów samego programu jak i modułów. Na początku ustawiamy w zmiennej server.document-root ścieżkę do katalogu, z którego Lighttpd domyslnie pobiera wszystkie obsługiwane przez siebie dokumenty. Zmienna server.port deklaruje port, na którym będzie pracował serwer a zmienne server.username i server.groupname definiują odpowiednio użytkownika i grupę, na którego prawach będzie uruchomiony serwer. Warto jest także ustawić zmienną server.errorlog, która wskazuje na pełną ścieżkę do pliku logu błędów. Ktoś, kto poradził sobie z konfiguracją Apache’a nie powinien mieć problemu z Lighttpd. Zapewne niektórzy pamiętają opcje ServerTokens i ServerSignature Apache’a, dzięki którym Apacz nie przedstawia się w sposób ułatwiający szukanie eksploita. W Lighttpd mamy o niebo lepiej – w zmiennej server.tag możemy sobie wpisać dowolny string identyfikujący serwer albo ciąg pusty aby wyłączyć identyfikację. Możemy wpisać np.: „Apache/2.2.3 (Unix) DAV/2 mod_ssl/2.2.3 OpenSSL/0.9.8b PHP/5.1.6 Server at xxx.pl Port 80” (żywcem zerżnięte z pierwszego lepszego serwera WWW działającego na NND) albo „Microsoft-IIS/5.0” i niech się domorosłe hakiery dziwią dlaczego eksploit nie zadziałał 🙂
W zmiennej server.modules znajdziemy dość długi łańcuch modułów, które mogą być uruchomione. Moduły te zapewniają możliwość uzyskania praktycznie wszystkich funkcji, które znamy z popularnego apacza (np. vhosty, czy katalogi użytkowników). Modułów używaj z głową, jest pewne, że nie potrzebujesz ich wszystkich do szczęścia. Zwróć uwagę, że każdy moduł spowalnia w pewnym stopniu serwer i zwiększa zapotrzebowanie na pamięć. Niektóre moduły pokrywają się częściowo funkcjonalnie (np.: mod_simple_vhost i mod_mysql_vhost) i ich włączenie prowadzi do dziwnych efektów. Dla przykładu jednoczesne włączenie mod_compress i mod_deflate skutecznie pomoże nam pozbyć się wyświetlania stron indeksu.
Moduły, których nie ma na liście w pliku konfiguracyjnym nie występują w tej wersji Lighttpd lub też nie są z nią kompatybilne.
Większość modułów takich jak: mod_accesslog (tworzy konfigurowalne wpisy historii żądań HTTP w pliku dziennika serwera), mod_auth (autentyfikacja użytkownika), mod_compress (wysyłanie strony w postaci skompresowanej), mod_evasive (ograniczenie liczby połączeń), mod_rewrite (mapowanie adresów URL) czy mod_usertrack (śledzenie użytkownika) ma swoje bezpośrednie odpowiedniki w Apache’u. Istnieją także moduły, których tam nie znajdziecie: mod_deflate (wysyłanie dynamicznie generowanej zawartości w postaci skompresowanej), mod_secdownload (zaawansowana blokada hotlinkingu), mod_magnet (sterowanie przetwarzaniem zapytań) czy mod_uploadprogress (śledzenie postępu uploadu pliku).
W przeważającej części przypadków do określania wzorców możemy używać wyrażeń regularnych, np. w mod_redirect:

url.redirect = ( „^/get/([0-9]+)/([0-9]+)$” => „http://www.example.org/get.php?isdn=$1&page$2” )

Taki wpis spowoduje, że wejście na stronę http://<adres_serwera>/get/21/4 spowoduje przekierowanie na adres http://www.example.org/get.php?isdn=21&page4
Natomiast w module mod_dirlisting za pomocą wyrażeń regularnych w zmiennej dir-listing.exclude możemy ustalić kryteria obiektów, które będą pomijane przy wyświetlaniu zawartości katalogów. W tym samym module, podobnie jak w Apache’u możemy wyświetlić przy zawartości katalogu nagłówek i stopkę zawierającą, np.: komentarz odnośnie zawartości katalogów. W tym celu przygotowujemy dwa pliki tekstowe nazwane HEADER.txt i README.txt (proszę zwrócić uwagę na małe i duże litery) zawierające tekst nagłówka i stopki. Pliki kopiujemy do katalogu udostępnionego przez WWW a do pliku konfiguracyjnego dodajemy opcje:

dir-listing.encoding = „iso-8859-2”
dir-listing.show-readme = „enable”
dir-listing.hide-readme-file = „enable”
dir-listing.show-header = „enable”
dir-listing.hide-header-file = „enable”

Niewątpliwie ciekawym dodatkiem jest wsparcie Ligttpd dla rrd, co w łatwiejszy sposób pomoże w uzyskaniu ciekawych statystyk rysowanych przez rrd.
Jeśli będziemy chcieli korzystać z połączeń szyfrowanych SSL, nie powinno to także sprawić kłopotu. W pliku konfiguracyjnym umieszczamy odpowiednie wpisy włączające połączenia szyfrowane i ustawiające parametry:

$SERVER[„socket”] == „twoja.domena.pl:443” {
ssl.engine = „enable”
ssl.pemfile = „/etc/lighttpd/server.pem”
#ssl.ca-file = „/etc/lighttpd/CA_issuing.crt”
#server.name = „twoja.domena.pl”
#server.document-root = „/home/httpd/https”
#server.errorlog = „/var/log/lighttpd/serror.log”
#accesslog.filename = „/var/log/lighttpd/saccess.log”
}

W zasadzie wystarczy ustawienie dwóch lub trzech zmiennych, reszta (zahashowana) przyda się gdy będziemy chcieli ustawić inną zawartość strony niż przy połączeniach HTTP, czy też utworzyć oddzielne pliki logu odnoszące się tylko do połączeń szyfrowanych. W przypadku kiedy wykupiliśmy odpowiedni certyfikat do zabezpieczenia serwerów WWW w urzędzie certyfikującym, musimy wskazać do niego pełną ścieżkę w zmiennej ssl.ca-file. Jeżeli nie mamy takiego certyfikatu SSL musimy go sobie wygenerować i podpisać sami.
Odbywa się to w nieco inny sposób niż dla serwera Apache – prościej i bez utrudnień typu usuwanie hasła:
openssl req -new -x509 -keyout server.pem -out server.pem -days 365 -nodes
Plik server.pem kopiujemy w upatrzone miejsce (np.: do /etc/lighttpd/) i nadajemy mu odpowiednie prawa:
chown nobody:nogroup /etc/lighttpd/server.pem && chmod 0600 /etc/lighttpd/server.pem

Lighttpd dobrze sprawuje się zarówno w małych serwisach internetowych, jak i portalach. W przypadku tych drugich stosowane są wbudowane w niego mechanizmy rozkładające obciążenie na kilka lub kilkanaście maszyn (load-balancing). Przy mocno obciążonych serwisach przyda się także możliwość ograniczania transferu. Lighttpd obsługuje globalne ograniczanie szybkości każdego połączenia do określonej wartości, ale także nakładanie niezależnych limitów prędkości na poszczególne dokumenty.
Czas na współpracę z PHP. Ponieważ PHP z repozytorium przygotowane jest tak, że nadaje się tylko do Apache’a, na nic się nam nie przyda. Mamy dwie możliwości: kompilujemy wszystko sami lub korzystamy z gotowego pakietu przygotowanego przez Maćka (http://nnd-linux-router.one.pl/pkg/). Przy samodzielnej kompilacji z parametrów skryptu configure usuwamy –with-apxs2 i dodajemy na końcu parametry –enable-fastcgi –enable-discard-path –enable-force-redirect. Gdy mamy już PHP nie spsute pod jeden jedyny serwer WWW, w pliku php.ini dodajemy wpis cgi.fix_pathinfo = 1. Kolejnym krokiem jest edycja pliku konfiguracyjnego serwera /etc/lighttpd/lighttpd.conf, odnajdujemy i usuwamy hashe sprzed modułów:
mod_proxy_core
mod_proxy_backend_http
mod_proxy_backend_fastcgi
a następnie np.: na końcu pliku konfiguracyjnego dodajemy wpis:

$HTTP[„url”] =~ „.php$” {
proxy-core.balancer = „round-robin”
proxy-core.allow-x-sendfile = „enable”
proxy-core.check-local = „enable”
proxy-core.protocol = „fastcgi”
proxy-core.backends = ( „unix:/tmp/php-fastcgi.sock” )
proxy-core.max-pool-size = 16
}

Po zainstalowaniu Lighttpd z przygotowanego pakietu nie ma konieczności przeprowadzania żadnych zmian w jego konfiguracji, aby działała integracja z PHP. Powyższe informacje podaje na wypadek jakby ktoś przy ekperymentowaniu z konfiguracją zepsuł współpracę z PHP. Całość możemy przetestować wykonując polecenie:
echo ‚<?php phpinfo(); ?>’ > /var/www/phpinfo.php
a następnie wpisując w przeglądarce adres http://ip_serwera/phpinfo.php – powinna nam się wyświetlić strona z informacjami na temat PHP.
Lighttpd posiada możliwość generowania informacji o stanie webserwera takich jak uptime, aktywne połączenia i ich stan, ilość przesłanych danych, szybkość transferu, używane moduły, wkompilowane rozszerzenia, czy zestawy liczników używanych do śledzenia stanu FastCGI lub innych protokołów. Żeby mieć dostep do tych statystyk wystarczy odhashować mod_status i ustawić zawartość zmiennych status.status-url, status.config-url i status.statistics-url. Ponieważ informacje zawarte w statystykach nie powinny trafić do każdego, powinniśmy w jakiś sposób ograniczyć dostęp do nich osobom z zewnątrz. Najprościej zrobić do dodając do pliku konfiguracyjnego wpis:

$HTTP[„remoteip”] == „192.168.0.0/24” {
status.status-url = „/server-status”
status.config-url = „/server-config”
status.statistics-url = „/server-statistics”
}

Oznacza on, że zmienne status.status-url, status.config-url i status.statistics-url zostaną ustawione (a tym samym zostaną włączone statystyki) tylko gdy IP komputera łączącego się z serwerem zawiera się z zakresie od 192.168.0.1 do 192.168.0.254. Podane ścieżki nie mają reprezentować określonych plików czy katalogów a co za tym idzie nie istnieją w systemie plików. Nawet gdy w /var/www/ mamy tylko jeden plik index.html i żadnych innych plików czy katalogów, a w pliku konfiguracujnym Lighttpd umieścimy wpis status.status-url = „/nobodyliveshere” to po wpisaniu w przeglądarce http://adres_serwera/nobodyliveshere otrzymamy stronę podobną jak ta http://orion.isx.pl/server-status.htm . Przy większej liczbie połączeń możemy je sortować wg. zadanych kryteriów klikając na wybranej komórce nagłówka tabeli, np.: „State:”.
Przy okazji otrzymaliśmy prosty przykład konfiguracji warunkowej, która to jest bardzo potężnym narzędziem. Oprócz pola $HTTP[„remoteip”], oznaczającego adres hosta zdalnego, możemy użyć dopasowań sprawdzających:
$HTTP[„cookie”] – cookie
$HTTP[„host”] – hosta
$HTTP[„useragent”] – nagłówek identyfikujący program, który połączył się z naszym serwerem
$HTTP[„referer”] – nagłówek referer, pozwalający sprawdzić z jakiej strony ktoś wszedł na naszą stronę
$HTTP[„url”] – adres URL
$SERVER[„socket”] – socket w formacie „ip:port”
Oprócz ostatniego dopasowania możemy użyć różnych operatorów porównania zadanego stringa czy wyrażenia regularnego Perla np:.

# zabroń dostępu do swojego serwera <cośtam>.example.org wszystkim złodziejom obrazków

$HTTP[„referer”] !~ „^(.*.)?example.org$” {
url.access-deny = ( „.jpg”, „.jpeg”, „.gif”, „.png” )
}

Po szczegóły odsyłam do dokumentacji Lighttpd.
A skoro jesteśmy już przy metodach zabezpieczania stron przed niepożądanym dostępem pewnie zainteresuje nas poniższy wpis do konfiguracji ilustrujący możliwość łączenia warunków:

$HTTP[„host”] == „www.example.org” {
$HTTP[„remoteip”] !~ „195.117.23.38|192.168.0.2” {
$HTTP[„url”] =~ „^/admin/” {
url.access-deny = ( „” )
}
}
}

W ten sposób zabezpieczyliśmy stronę http://www.example.org/admin/ tak aby mieć do niej dostęp z komputera w domu i w pracy. Wpis należy tłumaczyć w ten sposób: jeżeli łączysz się z serwerem www.example.org a twoje IP jest inne niż 195.117.23.38 i inne niż 192.168.0.2 i próbujesz się dostać do zawartości ścieżki admin to zostaniesz zablokowany.
No dobrze, ale przecież, gdy ktokolwiek z twojej pracy będzie próbował wejść na tą stronę ze swojego komputera to także uzyska dostęp. Apache miał możliwość zabezpieczania wybranych katalogów hasłem za pomocą pliku .htaccess. Nie próbuj robić W Lighttpd kontroli dostępu do zasobów za pomocą tej metody. It doesn’t work.
Żeby było trudniej załóżmy, że chcemy udostępnić statystyki serwera tylko adresom IP z sieci lokalnej – z zewnątrz mają być niewidoczne. Nie chcemy, aby użytkownicy naszej sieci mieli dostęp do takich strategicznych danych bo im też może przyjąć ochota na psoty. Niestety czasami jesteśmy u usera, który zgłasza np.: dziwne zachowanie sieci i od niego chcemy mieć dostęp do statystyk. Zrobimy więc tak aby z twojego komputera (192.168.0.2) był nieograniczony dostęp do statystyk a z komputerów userów uzyskamy dostęp dopiero po podaniu użytkownika i hasła.
Na początku tworzymy plik .htpasswd, jego struktura jest identyczna jak w Apache’u co z pewnością ucieszy zakochanych w programie The Apache Software Foundation. Zamiast kombinować ręcznie, wykorzystajmy narzędzie htpasswd:

htpasswd -c /etc/lighttpd/user.htpasswd admin
Adding password for admin
New password: <wpisujemy hasło>
Re-type new password: <wpisujemy to samo hasło jeszcze raz>

Następnie analogicznie dodamy kolejnego użytkownika poleceniem:
htpasswd /etc/lighttpd/user.htpasswd user

Utworzony plik .htpasswd ma postać:
admin:hlia.D4ebSZAw
user:sqLQtkpRyERMI

W pliku konfiguracyjnym lighttpd.conf dodajemy wpis:

$HTTP[„remoteip”] == „192.168.0.0/24” {
status.status-url = „/server-status”
status.config-url = „/server-config”
status.statistics-url = „/server-statistics”
$HTTP[„remoteip”] != „192.168.0.2/32” {
auth.backend = „htpasswd”
auth.backend.htpasswd.userfile = „/etc/lighttpd/user.htpasswd”
auth.require = ( „/server-config” =>
(
„method” => „basic”,
„realm” => „Statystyki serwera”,
„require” => „valid-user”
), „/server-status” =>
(
„method” => „basic”,
„realm” => „Statystyki serwera”,
„require” => „valid-user”
), „/server-statistics” =>
(
„method” => „basic”,
„realm” => „Statystyki serwera”,
„require” => „valid-user”
))
}
}

Możemy zadeklarować globalnie jeden plik user.htpasswd, albo do każdego zabezpieczanego katalogu przypisać zupełnie inny plik z hasłami. Nazwa user.htpasswd jest tylko przykładowa, nie musimy trzymać jakiegoś szablonu.
Gdy mamy jeden globalny plik z hasłami i kilka zasobów zabezpieczonych przy jego wykorzystaniu (tak jak w przykładzie ze statystykami), po autoryzowaniu się przy jednej statystyce uzyskuje dostęp do reszty statystyk już bez wpisywania hasła. Niektóre przeglądarki przechowują uwierzytelnione sesje do czasu zamknięcia całej przeglądarki (a nie tylko karty z daną stroną). Jeśli miałbym np.: phpMyAdmina zabezpieczonego w taki sposób i z pośpiechu nie zamknąłbym przeglądarki, na której wcześniej zalogowałem się do statystyk, użytkownik tego komputera uzyskałby dostęp do phpMyAdmina. Problem jest natury ogólnej i dotyczy także innych serwerów WWW takich jak Apache, czy thttpd. Rozwiązań jest kilka. Najprostsze to w pliku user.htpasswd utworzyć kilku użytkowników i zamienić opcje w konfigu „require” => „valid-user” np.: na „require” => „user=user” w przypadku statystyk i na „require” => „user=admin” w przypadku phpMyAdmina. Gdy będziemy próbowali zalogować się na siłę do phpMyAdmina za pomocą loginu „user” i prawidłowego hasła przeglądarka zwróci nam bład „400 – Bad Request”. Lepszym rozwiązaniem jest stworzenie oddzielnego pliku z hasłami do każdego zabezpieczonego zasobu. W Lighttpd można ten problem rozwiązać jeszcze inaczej, a przy okazji załatwić kolejny problem bezpieczeństwa. Od kilku lat zmieniłem chyba ze 4 sieci osiedlowe. Jedne obejmowały dziesiątki, inne nawet setki komputerów, ale cechą wspólną wszystkich sieci był brak zabezpieczeń przed sniffowaniem. Kiedyś admin jednej z tych sieci zapytany o kwestię zabezpieczeń przed podsłuchem (udałem przestraszonego klienta) powiedział, że oni używają switchów więc problemu nie ma. A skoro problemu nie ma to nie pochwaliłem się mu że przez pół dnia pracy sniffera w moje łapy wpada kilkanaście haseł poczty, czasem jakieś hasła do ftpów. Podsłuchiwać można także transmisję HTTP; szyfrowanie transmisji za pomocą SSL znacznie utrudnia sprawę, jednakże czasem zdarzają się sytuacje kiedy nie możemy wykorzystać SSL. Jak to wygląda w praktyce ?! Załóżmy, że w przeglądarce wpisałem adres http://192.168.0.1/server-status i pojawił mi się monit o podanie użytkownika i hasła. Statystyki zabezpieczyliśmy wg. ostatniego przykładu. Wpisujemy login i hasło i uzyskujemy dostęp do strony ze statystykami. W tym samym czasie sniffer uruchomiony na innym komputerze w sieci wypisał:
Host: 192.168.0.1
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: pl,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-2,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cache-Control: max-age=0, max-age=0
Authorization: Basic dXNlcjpTZWNyZXQ=

Hmmm, w polu „Authorization” mamy „zaszyfrowane” hasło. Problem w tym, że jest ono zakodowane tylko za pomocą Base64 i wystarczy użyć odpowiedniego programu lub wejść na jedną z setek stron z dekoderami online, skopiować „dXNlcjpTZWNyZXQ=” do schowka i wkleić ją np.: na http://www.opinionatedgeek.com/dotnet/tools/Base64Decode/ potem wciskamy „Decode” i mamy wszystko jak na dłoni.
Apache posiada specjalny moduł mod_auth_digest, który implementuje uwierzytelnienie HTTP Digest. Moduł nie został jednak dobrze przetestowany i jest oznaczony jako eksperymentalny. W Lighttpd nie ma nawet takiego eksperymentalnego modułu. Nie znaczy to, że Lighttpd nie obsługuje uwierzytelnienia HTTP Digest – nie dość, że obsługuje to jego uzyskanie jest bardzo proste. Zabezpieczmy w ten sposób katalog phpMyAdmina. Na początek musimy usunąć phpMyAdmina z wpisów auth.require o ile taki wpis zrobiliśmy podczas eksperymentów z plikiem konfiguracyjnym. W konfiguracji Lighttpd wstawiamy sekcję:

$HTTP[„url”] =~ „^/phpMyAdmin/” {
auth.backend = „htdigest”
auth.backend.htdigest.userfile = „/etc/lighttpd/user.htdigest”
auth.require = („/phpMyAdmin” => (
„method” => „digest”,
„realm” => „Wymagana autoryzacja”,
„require” => „valid-user”
))
}

Następnie tworzymy plik z hasłami:
echo -n ‚user:realm_z_przykładu_wyżej:’ > /etc/lighttpd/user.htdigest
echo ‚user:realm_z_przykładu_wyżej:hasło’ | md5sum | cut -b -32 >> /etc/lighttpd/user.htdigest

Przykładowa poprawna zawartość pliku user.htdigest:
master:Wymagana autoryzacja:ce7d499772512198344a1370a36f04f6

Eee, to już wszystko. Wystarczy tylko przeładować serwer, żeby przyjął zmiany w konfiguracji. Czas na testy, otwieramy przeglądarkę i wpisujemy adres http://192.168.0.1/phpMyAdmin/ , pojawił się monit o wprowadzenie nazwy użytkownika i hasła, zupełnie jak przy poprzedniej metodzie. Wpisujemy login i hasło i uzyskujemy dostęp do strony phpMyAdmina. W tym samym czasie sniffer uruchomiony na innym komputerze w sieci wypisał:
Host: 192.168.0.1
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: pl,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-2,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: pma_fontsize=100%25; pma_theme=original; pma_lang=pl-utf-8; pmaCookieVer=4; pma_charset=iso-8859-2; pma_collation_connection=cp1250_general_ci; phpMyAdmin=a5c538360d2eb3c3d64511d0696d5503
Authorization: Digest username=”master”, realm=”Wymagana autoryzacja”, nonce=”c683f7897c1d09b80192285cc1a80fba”, uri=”/phpMyAdmin/”, response=”11ba3e4f297c8765ad461946a2e0e19c”, qop=auth, nc=00000001, cnonce=”51b9b094e570e4ea”
Cache-Control: max-age=0, max-age=0

OK, usera mamy jak na dłoni, ale hasło?! Hasło jest zaszyfrowane i wysyłane jako hash z użyciem mechanizmu Challenge/Response. Nie zaleca się używania tej metody do zabezpieczania hasłem stron dostępnych od zewnątrz… zresztą ryzyko podsłuchu w sieci wewnętrznej jest wielokrotnie większe.

Możliwe jest uzyskanie efektu, dzięki któremu każda spisana ścieżka w URL będzie prawidłowa, wystarczy wpisać w pliku konfiguracyjnym server.error-handler-404 = „/index.html” a gdy użytkownik spróbuje połączyć się ze stroną, która nie istnieje, zostanie wyświetlona strona znajdująca się w pliku /var/www/index.html. Jeśli wszystkie zawarte w niej odnośniki podane są jako bezwzględne uzyskamy efekt przekierowania na stronę początkową, a przeglądarka dostanie w odpowiedzi kod 200 oznaczający, że dokument istnieje. Jeśli nie podobają się nam domyślne strony błędów, możemy podmienić je na własne za pomocą zmiennej server.errorfile-prefix.
Warto poświęcić trochę czasu na konfigurację programu, a zyskamy sprawny i bardzo szybki serwer www.

Andrzej Boreczko (Orion)

Strażnik sieci

Pod takim nieco przewrotnym tytułem anonsuję nowy pakiet do NND,którego zadanie jest niewątpliwie ważne – ochrona przed nieautoryzowanym dostępem do LAN czy WLAN. Program nazywa sie ip-sentinel i choć nie jest nowy (źródła pochodzą z 2005 roku), to dość skutecznie spełnia swoje zadanie.

Instalacja
Program instalujemy poleceniem pacman -U http://nnd-linux-router.one.pl/pkg/ip-sentinel/ip-sentinel-0.12-1emti.pkg.tar.gz i uruchamiamy poleceniem /etc/rc.d/ipsentinel start (W przyszłości znajdzie się w oficjalnym repozytorium i będzie go można instalować przez pacman -S)
Program domyślnie rozpoczyna działanie na pierwszym interfejsie wewnętrznym (INTIF1 w rc.conf), jeśli więc ma pracować na innym, to przed uruchomieniem trzeba zamiast zmiennej $INTIF1 w pliku /etc/rc.d/ipsentinel podstawić odpowiednią dla własnej sieci.
Konfiguracja
Przed uruchomieniem należy jeszcze przygotować sobie wszystkie dozwolone w naszej sieci IP oraz MAC kart sieciowych i wpisać je do pliku /var/lib/ip-sentinel/ips.cfg.
Przykładowy plik konfiguracyjny wygląda następująco:
192.168.1.2@!00:07:95:50:97:C0
192.168.1.{3-4}
192.168.1.5@!00:D0:59:12:AF:15
192.168.1.6@!00:30:BD:66:EC:77
192.168.1.{7-254}

Pierwszy wpis to IP pierwszego komputera w mojej sieci oraz jego mac. Następny dotyczy dwóch nieużywanych IP, które w razie potrzeby będą blokowane, trzeci i czwarty to numery IP i MAC laptopa oraz Access Pointa. Ostatni wpis powoduje, że wszelkie pozostałe numery będa blokowane. Należy zauważyć, że w konfiguracji nie ma numeru 192.168.1.1 (numer serwera). Powtórzę, że każdy IP i MAC, kóry ma być „zostawiony w spokoju” przez ip-sentinel musi miec postać NR_IP@!ADRES_MAC – spowoduje to, że ten sam numer IP z innym MAC będzie blokowany.
Działanie
Program nie korzysta z iptables, nie musi być zatem uruchomiony na prawach superużytkownika (w pakiecie pracuje jako nobody). Jest to bezpieczniejsze. Działania programu polegają na tym, że jeśli odkryje nowy MAC, którego nie ma w pliku ips.cfg, podejmuje działanie zmierzające do zakłócenia tcp/ip tego komputera. Program mozna uruchamiac także z opcją –action /sciezka/program (uruchomi się wywołany przez administratora program lub skrypt po wykryciu „lewego” MAC w sieci).
Przykład praktyczny
Program został uruchomiony na serwerze NND, do którego podłączony jest komputer stacjonarny, laptop i AP (wszystkie wpisane w konfiguracji). Następnie odłączyłem laptopa i uruchomiłem na nim kartę radiową symulując działania włamującego się do sieci.
Pierwszym zaskoczeniem było to, że komputer otrzymał IP nadany przez dhcp.

ath0   Link encap:Ethernet  HWaddr 00:0A:EB:A7:2A:0D
          inet addr:192.168.1.4  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::207:95ff:fe50:97c0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1177 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1445 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:237981 (232.4 KiB)  TX bytes:152554 (148.9 KiB)

Zdziwiłem się, ale szybko zauważyłem, że MAC karty jest zupełnie różny od prawdziwego. Włamywacz mający tak łatwy dostęp spróbowałby zapewne komendy ping, aby pomacać trochę komputery w sieci albo nmap, aby się dowiedzieć więcej, a na koniec użyłby arp -n, aby sprawdzić i zanotować IP oraz MAC. Nie zastosowałem programu Kismet, bo miałem tylko jeden komputer podłączony radiowo, więc nic bym „nie wyłapał”. Jednak efekty działania programu Kismet byłyby podobne.

[maciek@laptop~]# ping 192.168.1.2
PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=0.082 ms
[maciek@laptop~] arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.1.2              ether   01:80:C2::00:00:01   C                       ath0
192.168.1.1              ether   01:80:C2::00:00:01   C                       ath0

Zastanawiające jest, że dwa komputery podają ten sam MAC. Jeśli przebadalibyśmy sto, byłoby identycznie, kismet również podałby te same wartości. Próbowałem zmienić MAC swojej karty radiowej w locie, ale nie pomógł nawet macchanger, sterownik karty nie wspiera takich operacji.
Kolejnym krokiem było uruchomienie Windows na laptopie. Efekt był taki sam. Otrzymałem numer IP, możliwość pingowania do komputerów w sieci też, ale brak dostępu do internetu, nie mozna sie też było zdalnie zalogować do serwera, ani do drugiego komputera. Poza pingiem nie działało nic. Sterownik windowsowy również nie wspierał zmiany MAC w locie, ale udało się to zrobić po wyjęciu karty, gdy ją włożyłem zaczęła pracę normalnie – było pełny dostęp do wszystkiego.
Jednak włamywacze nie mają się z czego cieszyć. Po pierwsze wardiver nasłuchujący sieć radiową nie dostanie najprawdopodobniej ani jednego prawidłowego MAC, aby mógł go zmienić, a jeśli nawet uda mu się i zmieni MAC „on the fly” to ip-sentinel natychmiast to wychwyci. Pomoże tylko wyłączenie karty, zmiana MAC i ponowne włączenie karty. O ile wiadomo taka operacja nie bardzo się uda w linuksie (nie da się tam ustawiać właściwości nieistniejących urządzeń). Jest to możliwe w Windows, ale po pierwsze trzeba na to wpaść, a po drugie trzeba mieć jakiś MAC do wpisania. No chyba żeby potencjalny zły haker zaczął wzorem Kevina Mitnicka uprawiać manipulację psychologiczną i chodziłby po osiedlu pytając kolejnych lokatorów o MAC ich karty (większość zapewne w ogóle nie wiedziałaby, co to jest). Zresztą dodatkowym elementem zaskakującym włamywacza będzie to, że Windows ddość szybko głupieje atakowany przez ip-sentinela. W moim przypadku po kilkunastu minutach prób doszło do tego, że IP laptopa zmieniał się np. na 0.0.0.0 lub na zwyczajowy z puli 169.xxx.xxx.xxx, aż wreszcie się zawiesił. Wniosek oczywisty, że do dłuższego „macania” tak zabezpieczonej sieci nadaje się tylko linux. Znacząco to ograniczy liczbę potencjalnych chętnych na darmowe łącze w naszej sieci.
Uwagi końcowe
Test jaki przeprowadziłem, trwał tylko parę godzin i był ograniczony z powodów sprzętowych, na pewno nie mogłem zasymulowac wszystkich możliwych konfiguracji. Jednak skuteczność ip-sentinela jest na tyle duża, że z całą pewnością sprawdzi się w małych (pracujących w klasie C) sieci.
Chciałbym też podziękować Orionowi (Andrzejowi Boreczko), który wskazał mi ten program, podał prawidłową konfigurację i opisał jego działanie we własnej sieci. Bez jego pomocy nie powstałby ani pakiet ani ten opis.
Na koniec jeszcze fragment wpisów z /var/log/ip-sentinel.out (znakiem # poprzedzone są moje komentarze).

# Program rozpoczyna pracę
@400000004635cdc80b1668d0: (Re)reading blacklist
# Po wykryciu IP zostaje mu nadany fake-MAC i podany fake-MAC serwera
@400000004635cec63686e490: 192.168.1.4/0:a:eb:a7:2a:d >- 192.168.1.1/0:0:0:0:0:0 [1:80:c2:0:0:1]
# Podczas próbypingowania „dobrego” komputera ip-sentinel przechwytuje dobry MAC podając zamiast niego fake-MAC
@400000004635cf981abdc788: 192.168.1.2/0:7:95:50:97:c0 -> 192.168.1.4/0:0:0:0:0:0 [1:80:c2:0:0:1]
# O, a tu już jakiś inny IP (ktos już zauważył widać nieszyfrowaną sieć z rozgłaszającym się SSID)
@400000004635d08b22d0df50: 192.168.1.3/0:b:ec:a7:2a:d >- 192.168.1.1/0:0:0:0:0:0 [1:80:c2:0:0:1]

Dużą zaletą programu ip-sentinel jest brak konieczności jakichkolwiek działań po stronie użytkownika końcowego, żadnego logowania, żadnych wirtualnych interfejsów. Ewentualną wadą, niepotwierdzoną doświadczalnie, mogą być problemy z kiepskiej jakości switchami, taka informacja pojawiła się na jednej ze stron.

autor: W. Trąmpczyński (Maciek)

Prosty backup

Złośliwe powiedzonko informatyków głosi, że prawdziwi mężczyźni backupów nie robią. Przypomina się je tym, którzy właśnie płaczą iż stracili dane w wyniku awarii dysku. O ile w przypadku komputera domowego, wystarczy, jeśli ważniejsze dane zgrywamy od czasu do czasu na płytę, o tyle na maszynach serwerowych, gdzie zmiany są codziennie, trzeba wymyślić jakiś sposób automatycznego robienia kopi zapasowych. Nie trzeba przy tym wyważać otwartych drzwi, bo potrzebne oprogramowanie jest dostępne we wszystkich dystrybucjach linuksowych.

Robienie kopii w 3 krokach

1. Instalujemy rsync (w każdej dystrybucji będzie się to robić innym poleceniem – pacman, urpmi, apt-get, ale efekt jest ten sam), oczywiście w przypadku NND robimy to poleceniem pacman -S rsync. Po zainstalowaniu na komputerze, z którego będą robione kopie, musimy uruchomić rsync jako demona, zapewne w Waszej dystrybucji będzie już gotowy skrypt pozwalający na uruchomienie /usr/bin/rsync –daemon (w NND dopisujemy rsyncd do sekcji DAEMONS pliku rc.conf), jeśli nie musicie sobie to polecenie dopisać, np. do pliku rc.local. Jeśli zamierzamy robić kopię na odległym komputerze, musimy otworzyć na firewallu port 873, koniecznie tylko dla jednego komputera o określonym IP, w przeciwnym wypadku może się zdarzyć, że ktoś inny zrobi sobie kopię waszego serwera.
polecenie:
iptables -A INPUT -p tcp -i eth0 --dport 873 -s XXX.XXX.XXX.XXX -j ACCEPT
Nie ma tego problemu w większości przypadków, kiedy serwer backupów stawiamy w tej samej sieci, choć też lepiej się zabezpieczyć przed niepowołanym dostępem.
2. Na komputerze, na którym będą robione kopie, także instalujemy rsync, ale uruchamiac go będziemy okresowo według reguł zapisanych w cronie. W ten sposób będą nam powstawać tzw. kopie przyrostowe. Oznacza, to, że kopia będzie zawierać pliki zmienione na serwerze źródłowym, usuwać te usunięte, natomiast nie będą nadpisywane pliki, w których się nic nie zmieniło. Dzięki czemu, po pierwszym wykonaniu kopii następne czynności rsynca będa szybkie i nie będą przesyłać zbyt wielu danych.
Nie ma tez sensu robienie kopii całego systemu. Cały system możemy zbackupowac po instalacji i konfiguracji, ręcznie także zrobić kopie w przypadku aktualizacji oprogramowania, zas na co dzień wystarczy nam kopia przyrostowa katalogów z danymi (najczęściej /home), oraz katalogu plików konfiguracyjnych (/etc). W tym celu odpowiednie polecenie dopisujemy do crona.
polecenie:
20 3 * * * /usr/bin/rsync -a -z --delete-after rsync://root@192.168.1.4:873/etc /var/backup/szkola/etc
Powyższe polecenie uruchomi robienie kopii zapasowej o 3:20 w nocy z atrybutami (-a) archiwum i (-z) kompresowania w czasie przesyłania protokołem rsync z poziomu roota (możliwość zachowywania oryginalnych atrybutów plików) z komputera 192.168.1.4 (katalog /etc) do katalogu /var/backup.. na dysku lokalnym.
W moim przypadku zbieram sobie do backupu umieszczonym w katalogu szkola dane nie tylko z /etc, ale również strony www, dane użytkowników oraz pocztę.
3. Dodatkowym elementem ułatwiającym korzystanie z backupu jest skompresowanie wszystkiego do pojedynczego archiwum z datą w nazwie. Zdecydowałem się na to, aby umozliwić łatwe przegranie backupu na płytę dvd. Taka płytę robi się ręcznie, tylko w przypadku poważniejszych zmian i nie widziałem już potrzeby automatyzowania tego zadania. Natomiast codzienne robienie archiwum wykonuje skrypt, który wykonuje się również cyklicznie (należy oczywiście pamiętać, aby czas wykonywania skryptów przypadkiem się nie pokrywał)

#! /bin/sh
cd /var/backup
# wykonanie archiwum
tar zcvf /home/httpd/html/backup/szkola-`date +%y%m%d`.tar.gz szkola
# kasowanie wczorajszego, bo nie mam za dużo miejsca...
rm -f /home/httpd/html/backup/szkola-`date -d yesterday +%y%m%d`.tar.gz

Oczywiście lepiej byłoby zachować archiwa z kliku lub kilkunastu dni, ale niestety nie mam az takiej przestrzeni dyskowej, a moje archiwa mają po dwa GB danych. Mozna też archiwa podzielić i np. odpowiednim użytkownikom udostepniać określone pliki. Np. webmaster niech sam sobie przywraca kopie, jeśli coś niopatrznie skasował…
Każdy przeciez może sobie odrobinę zmodyfikować te proste regułki i skrypty. Na koniec powiem, że robienie kopii to naprawdę pożyteczny zwyczaj i może się przydać 🙂

Przygotowanie plików do budowy pakietu

Informacje o podstawach budowania własnych pakietów.

1. Budowa pakietu polega na przygotowaniu pliku PKGBUILD i innych np.: pakiet.install, pliki startowe itp…

2. W katalogu tymczasowym stwórz podkatalog o nazwie pakietu, który chcesz zbudować. Do niego skopiuj plik PKGBUILD.proto (powinien być w /var/abs) i zmień nazwę na PKGBUILD. Jeśli twój pakiet będzie wymagał jakichś specjalnych działań przed/po instalacji, upgradzie, usunięciu, skopiuj również install.proto i zmień nazwę na nazwa_pakietu.install.

3. W pliku PKGBUILD wpisz wartości do zmiennych:
pkgname – nazwa pakietu (taka sama jak nazwa katalogu z plikiem PKGBUILD). Ta zmienna NIE MOŻE być pusta!
przykład: pkgname=glibc
pkgver – wersja programu. Ta zmienna NIE MOŻE być pusta!
przykład: pkgver=2.3.3
pkgrel – „wydanie” pakietu. Ta zmienna powinna mieć format: Xnnd, gdzie X to numer kolejnego wydania. Numer wydania zmieniać się będzie przy każdej budowie pakietu. Ta zmienna NIE MOŻE być pusta!
przykład: pkgrel=23nnd
pkgdesc – Krótki opis pakietu. Ta zmienna NIE POWINNA być pusta!
przykład: pkgdesc=”GLIBC – Podstawowa biblioteka systemowa”
url – Adres strony domowej pakietowanego programu. Ta zmienna NIE POWINNA być pusta!
przykład: url=”http://www.glibc.org”
license – licencja na której wydano program (np. GPL, BSD).
przykład: license=GPL
depends – zmienna tablicowa, gdzie podawane są wszystkie nazwy pakietów niezbędnych do działania naszego programu. O tym jakie pakiety są niezbędne powie nam dokumentacja, znajomość pakietowanego programu i polecenie ldd.
przykład: depends=(‚bash’ ‚inny_pakiet’ ‚jeszcze_inny_pakiet>=2.6.7’)
Zwróć uwagę, że można podawać tu dodatkowe wymogi co do wersji potrzebnego pakietu.
makedepends – jak wyżej, z tym że tu podajesz nazwy pakietów niezbędnych na etapie budowy pakietu i kompilacji, a niepotrzebne do prawidłowego działania.
przykład: makedepends=(‚gcc’ ‚binutils’)
conflicts – tu podajemy nazwy pakietów z którymi nasz pakiet NIE MOŻE być jednocześnie zainstalowany.
przykład: conflicts=(‚uClibc’ ‚cos_jeszcze’)
replaces – nazwa pakietu, który zostanie podmieniony przez nasz pakiet.
provides – pacman (i make_nnd_pkg) podczas instalacji, upgrade, usuwania i budowy pakietu sprawdzają zależności w zmiennych $pkgname i właśnie w $provides.
przykład: mamy dwie wersje kernela: kernel24-ide i kernel24-scsi. Ponieważ obie dostarczają tych samych narzędzi więc w zmiennej $provides oba pakiety maja ustawione „kernel24” natomiast pakiety, które do działania (lub budowy) wymagają obecności kernela mają w zmiennej $depends ustawione kernel24. Powoduje to, że bez znaczenia jaki kernel mamy zainstalowany w systemie – zależności zostaną spełnione.
install – nazwa pliku (zazwyczaj nazwa_pakietu.install), który będzie zawierał dyrektywy co należy zrobić przed/po instalacji, przed/po upgradzie, przed/po usunięciu pakietu. Często ta zmienna pozostaje pusta.
source – zmienna tablicowa w której są podane wszystkie pliki niezbędne do budowy pakietu: źródła programu dodatkowe scripty, patche, itp… Zazwyczaj źródła programu i patche ściągane są bezpośrednio ze strony domowej i podawany jest tylko url do plików. Dodatkowe scripty/pliki powinny być umieszczone w katalogu roboczym. Podczas budowy pakietu zostaną skopiowane do katalogu src, który będzie stworzony jako podkatalog katalogu roboczego.
przykład: source=(http://jakis_url/katalog/$pkgname-$pkgver jakis-plik inny_plik)
md5sums – zmienna tablicowa w której są podane sumy kontrolne wszytkich plików umieszczonych w zmiennej source.
przykład: md5sums=(‚jhgjkhrjahgkrahgreu976’ ‚73642j34h5kj43h876gbv’ ‚sjhgzrd876gragregfdfg’)
nosplit – zmienna przyjmująca jedną z dwóch wartości – ‚yes’ lub ‚no’. Jeśli w pliku PKGBUILD pojawi się nosplit=yes, to taki pakiet NIE BĘDZIE podzielony na pakiet, pakiet-devel, pakiet-man. Zazwyczaj nie jest potrzebne ustawianie tej zmiennej.
pre_packing – zmienna przyjmująca jedną z dwóch wartości ‚yes’ lub ‚no’. Ustawienie jej na wartość ‚yes’ spowoduje wykonanie dodatkowej funkcji tuż przed skompresowaniem pakietu. Funkcję tę trzeba oczywiście przygotować i umieścić w pliku PKGBUILD.

Zmienne $nosplit i $pre_packing, oraz związane z nimi funkcje zostały przygotowane specjalnie dla NND.
Plik PKGBUILD rozumie również inne zmienne – są one opisane w man makepkg.

4. W pliku PKGBUILD popraw funkcję build(). W niej należy umieścić wszystko to co musimy wykonać aby skompilować program. Ta funkcja to nic innego jak kawałek scriptu shella, w którym krok po kroku przygotowujemy program do kompilacji – patchujemy, modyfikujemu pliki, dodajemy/usuwamy pliki itp… Tu również wywoływane jest polecenie ./configure (o ile jest) przygotowujące źródła do kompilacji. Uwaga, ponieważ większość programów jest domyślnie instalowana w /usr/local należy pamietać o dodaniu do ./configure parametru –prefix (np. ./configure –prefix=/usr). Nie wolno zapomnieć o „cd” do odpowiednich katalogów.
Dla typowego programu kompilowanego i instalowanego serią poleceń ‚./configure && make && make install’ odpowiednia funkcja build() jest już zawarta w pliku PKGBUILD.proto. Na uwagę zasługuje linia:
make DESTDIR=$startdir/pkg install
Powoduje ona, że skompilowany program zostanie zainstalowany w katalogu wskazanym przez zmienną DESTDIR, a nie w strukturze katalogów naszego systemu. Zmienna $startdir to po prostu katalog, w którym znajduje się plik PKGBUILD.
UWAGA. Czasem zmienna DESTDIR nie jest wykorzystywana przez autorów programu. Wtedy należy zamiast niej użyć zmiennej prefix. Czyli powyższa linia wyglądałaby następująco:
make prefix=$startdir/pkg/usr install # przy założeniu, że użyte było ./configure –prefix=/usr
Niestety nie wszystkie programy instaluje się łatwo. Czasem wymagana jest edycja plików Makefile (lub innych), czasem należy zmienić domyślne położenie jakichś plików,
coś usunąć, zmienić nazwę jakiegoś pliku – możliwości są setki. Dokładne informacje o sposobie budowy i instalacji danego programu zazwyczaj są zawarte w pliku INSTALL w katalogu głównym źródeł programu. Zapoznanie się z tym, a także z innymi (README, readme.first) plikami dokumentacji zdecydowanie skróci czas budowy pakietu. Jeśli podczas prób dojdziesz do wniosku, że automatyczny podział kompilowanego programu nie jest poprawny, możesz dodać funkcję pre_packing() w której umieść instrukcje przenoszący pliki do odpowiednich katalogów.
O ile w obrębie katalogu $startdir możesz korzystać z funkcji build(), o tyle przenosznie plików pomiędzy katalogami pakiet <–> pakiet-devel <–> pakiet-man jest możliwe dopiero tuż przed kompresją pakietu. Wcześniej nie istnieją odpowiednie katalogi. Tu właśnie przydaje się użycie funkcji pre_packing(). Dodatkowo w obrębie tej funkcji jest możliwość wprowadzenia poprawek do plików PKGBUILD dla pakietów *-devel i *-man. Katalogi zawierające te pliki znajdują sie w katalogu nadrzędnym do $startdir.

5. Po przygotowaniu funkcji build() (i ewentualnie pre_packing()), należy w katalogu zawierającym plik PKGBUILD wykonać polecenie:

make_nnd_pkg -g >> PKGBUILD

spowoduje ono że zostaną pobrane źródła programu (na podstawie adresów ze zmiennej source) i dla każdego z plików źródłowych zostanie wygenerowana suma kontrolna i zapisana na końcu pliku PKGBUILD. Jeśli źródeł programu nie ma na dysku i są one pobierane z internetu to poza sumami kontrolnymi znajdzie się tam trochę śmieci. Należy usunąć wszytko co jest położone poniżej OSTATNIEGO znaku ‚}’ i nie jest sumą kontrolną (patrz przykład md5sums). Jeśli korzystaliśmy z pliku PKGBUILD.proto to mamy teraz dwie zmienne md5sums – jedną pustą i jedną z właśnie wygenerowanymi sumami kontrolnymi. Należy usunąć pustą i przenieść wygenerowane sumy kontrolne powyżej funkcji build(). Nie jest to, co prawda, niezbędne, ale jest logiczne i pomaga utrzymać porządek w pliku.

6. Plik PKGBUILD został przygotowany do budowy pakietu. Teraz należy przygotować plik nazwa_pakietu.install, w którym będą dokładne dyrektywy, co należy zrobić przed/po instalacji, przed/po upgrade i przed/po usunięciu pakietu. Wzór takiego pliku jest w katalogu /var/abs (install.proto). Nie należy w nim zmieniac nic poza dodaniem odpowiednich poleceń do odpowiednich funkcji… np. po instalacji/usunięciu bibliotek należy wykonać polecenie ‚ldconfig’, po instalacji/deinstalacji modułów jądra należy uruchomić ‚depmod -a’. Tutaj również można umieścić komunikaty dla użytkownika (np. po zmianie kernela: „Uruchom Lilo…”) Niestety, na razie nie można używać tych funkcji interaktywnie – tzn. user nie może odpowiadać na pytania systemu.

Dalsze postępowanie opisane zostało w artykule Budowa pakietu i tworzenie repozytorium.

Michał Lechański (Mis’)

Budowa pakietu i tworzenie repozytorium

Budowanie pakietu. Krótki opis jak to zrobić oraz jak zbudować własne lokalne lub zdalne repozytorium.

1. Jeśli prawidłowo został zbudowany PKGBUILD, wszystko jest gotowe do budowy pakietu. W katalogu z plikiem PKGBUILD wykonujemy polecenie:

make_nnd_pkg

2. Po wydaniu polecenia make_nnd_pkg źródła zostaną pobrane z lokalnego cache (z intenetu zostały pobrane podczas generowania sum kontrolnych), sprawdzone zostaną sumy kontrolne plików, źródła zostaną rozpakowane. Następnie zostanie wywołana funkcja build() kompilująca i instalująca program w katalogu tymczasowym. Jeśli ustawiliśmy zmienną pre_packing=yes to po funkcji build(), kilku funkcji wewnętrznych zostaje wykonana funkcja pre_packing(). Jeśli wszystko poszło prawidłowo to po skompilowaniu zostaniemy zapytani o to czy chcemy wprowadzić poprawki do automatycznego podziału pakietów. Odpowiadamy ‚T’, sprawdzamy czy wszystko jest na swoim miejscu, wciskamy F10 aby wyjść z Midnight Commandera, skrypt kończy budować pakiet. Znów jesteśmy w katalogu z plikiem PKGBUILD, ale plików mamy już nieco więcej – mamy, przede wszystkim, pakiet (oraz pakiet-devel i pakiet-man, jeśli takowe zostały stworzone), mamy pliki filelist-* zawierające listy plików w każdym ze zbudowanych pakietów, mamy katalogi ‚src’, ‚pkg’, ‚dev_pkg’, ‚man_pkg’. Usuwamy wszystko poza tym co mieliśmy przed rozpoczęciem budowy pakietu. Można (a nawet powinno się) ostateczną budowę pakietu wykonać poleceniem:

make_nnd_pkg -cw /jakiś_katalog

spowoduje to, że wszystkie tymczasowe pliki zostaną usunięte automatycznie, a pakiety zostaną zapisane w katalogu /jakiś_katalog. Warto sobie taki katalog dla pakietów stworzyć…

3. Jeśli pakiet budowaliśmy jednym z podkatalogów drzewka cvs (NIE ZALECANE!!) to wykonujemy update i commit wprowadzonych zmian, następnie wychodzimy z naszego dotychczasowego katalogu do katalogu nadrzędnego, wchodzimy kolejno do katalogów *-devel i *-man (o ile istnieją) i w każdym z nich wykonujemy cvs update i commit. Jeśli budowaliśmy pakiet w katalogu tymczasowym to najpierw uaktualniamy pliki w odpowiednim katalogu dzewa cvs, a następnie robimy cvs update i commit.

4. Dla tych, którzy nie chcą/potrafią bawić się cvs (badź nie mają dostępu do cvs):
Tworzymy katalog tymczasowy nazywający się tak jak pakiet, kopiujemy do niego katalogi: pakiet, pakiet-devel, pakiet-man, oraz odpowiednie pliki pakietów. Tymczasowy katalog kompresujemy i wysyłamy do kogoś, kto wrzuci nam wszystko do cvs, wygeneruje bazy pakietów i zrobi update repozytorium.

5. Budowanie repozytorium lokalnego:
Mamy katalog (nazwijmy go np. lokalne) zawierający podkatalogi z plikami PKGBUILD i innymi niezbędnymi do budowy pakietów i drugi, zawierający zbudowany przez nas pakiety. Generujemy bazę danych pakietów poleceniem:

gensync /sciezka/lokalne /katalog/z/pakietami/lokalne.db.tar.gz

po chwili mamy w katalogu z pakietami bazę danych naszych lokalnych pakietów. Możemy teraz do pacman.conf dodać linie:

[lokalne]
Server = file:///scieżka/do/katalogu/z/pakietami

Od tej chwili pacman będzie synchronizował pakiety również z tym katalogiem.

6. Budowa repozytorium zdalnego przebiega tak samo. Jeśli chcemy robić samodzielnie update oficjalnych repozytoriów to niezbędne jest posiadanie na dysku WSZYSTKICH pakietów z repozytorium. Genereujemy bazę pakietów, a następnie podmieniamy/dodajemy/usuwamy odpowiednie pliki na serwerze.

Michał Lechański (Mis’)

Apache i PHP

Apache jest popularnym serwerem www. Jeśli zamierzamy budować zaawansowane aplikacje internetowe, zapewne będzie potrzebny.
Instalujemy go poleceniem:
pacman -S apache
i od razu gotowy jest do działania w swojej domyślnej (najprostszej) konfiguracji. Należy dopisać jego uruchamianie do rc.conf, a pierwszy raz dla sprawdzenia uruchomić ręcznie.

Jednak większość administratorów będzie potrzebować bardziej zaawansowanych funkcji. W tym celu trzeba doinstalować jeszcze pakiet mysql (opis w oddzielnym artykule) i php. Po zainstalowaniu php musimy jeszcze dostosować konfigurację. W tym celu otwieramy /etc/httpd/conf/httpd.conf i odnajdujemy linię 262:
#LoadModule php4_module lib/apache/libphp4.so
i usuwamy znak #, a potem restartujemy serwer httpd. Potrzebne nam ustawienia php edytujemy w pliku php.ini. Zapewne niektórzy webmasterzy odkryją błędy we wcześniejszych aplikacjach php. Najczęściej będą one związane z dyrektywą RegisterGlobals=off. Nie zaleca się zmiany tej dyrektywy ze względu na bezpieczeństwo. Fachowcy z reguły sugerują przebudowanie kodu php.
Kolejny element to uruchomienie serwera https (czyli bezpiecznego połączenia SSL), który będzie przydatny chocby do umieszczenia na nim aplikacji do obsługi e-mail przez www. Najpierw trzeba wygenerować certyfikat. Poniżej opis czynności.
Najpierw przechodzimy do katalogu /etc/httpd, bo w nim umiescimy certyfikat, generujemy klucz, a potem właściwy certyfikat. Poniżej mój przykład:

[root@router_nnd]# cd /etc/httpd
generowanie klucza
[root@router_nnd httpd]# openssl genrsa -des3 -rand /etc/random-seed -out /etc/httpd/server.key 1024
512 semi-random bytes loaded
Generating RSA private key, 1024 bit long modulus
…………………….++++++
……………..++++++
e is 65537 (0x10001)
Enter pass phrase for /etc/httpd/server.key:
Verifying – Enter pass phrase for /etc/httpd/server.key:
generowanie certyfikatu
[root@router_nnd httpd]# openssl req -new -x509 -days 3650 -key /etc/httpd/server.key -out /etc/httpd/server.crt
Enter pass phrase for /etc/httpd/server.key:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‚.’, the field will be left blank.
—–
Country Name (2 letter code) [AU]:PL
State or Province Name (full name) [Some-State]:pomorskie
Locality Name (eg, city) []:Slupsk
Organization Name (eg, company) [Internet Widgits Pty Ltd]:eMTi
Organizational Unit Name (eg, section) []:webdesign
Common Name (eg, YOUR name) []:emti.one.pl
Email Address []:admin@emti.one.pl
usuwanie hasła z klucza
[root@router_nnd httpd]# cp server.key server.key.old
[root@router_nnd httpd]# openssl rsa -in server.key.old -out server.key
Enter pass phrase for server.key.old:
writing RSA key

Teraz jeszcze pozostaje kilka końcowych czynności.
W pliku /etc/conf.d/httpd wpis HTTPD_USE_SSL=”no” musimy zmienić na yes. Następnie dopisać prawidłową ścieżkę klucza i certyfikatu w ssl.conf (linia 110 i linia 118) oraz dodać ścieżkę do katalogu który będzie głównym katalogiem https (linia 88).
PS. Numery linii mogą być nieaktualne w kolejnych wersjach pakietu, użyj F7 w mc – aby znaleźć odpowiedni wpis.