Administracja serwerem PostgreSQL

Sierpień 11th, 2008 Brak komentarzy »

Rajmund Radziewicz

Po standardowej kompilacji oprogramowania PostgreSQL – instalacja znajdzie się w katalogu /usr/local/pqsql.Docelowe miejsce może różnić się, jeśli instalujemy bazę z paczek (np. debów lub rpmów). Wszystkie polecenia Postgresa są dostępne z poziomu /usr/local/pgsql/bin. Należy więc dodać tę lokalizację do zmiennej PATH powłoki z którą pracujemy. Jeśli jest to bash, csh lub tcsh powinieneś dodać:

% set path = ( /usr/local/pgsql/bin path )

W bazowym katalogu znajdzie się siedem podkatalogów przechowujących składniki naszej bazy: programy, biblioteki, pliki nagłówkowe itp. Mamy więc podkatalog bin (programy składające się na PosgreSQL), include, lib (biblioteki i pliki nagłówkowe pomocne przy tworzeniu aplikacji klienckich), doc (dokumentacja), man (strony podrecznika systemowego), share (przykłady plików konfiguracyjnych i kopie zapasowe) oraz data (instalacja bazy).
Za tworzenie nowej bazy odpowiedzialny jest program initdb.
Domyślna instalacja przykładowej bazy za pomocą tego programu zawiera informacje o koncie superusera oraz bazę template1. Aby utworzyć dodatkową, można uzyć analogicznego programu o nazwie createdb.
Serwer PostgreSQL uruchamia się jako proces w systemach uniksowych. Taki proces nazywa się postmaster i musi cały czas działać jako demon, żeby umożliwić łączenie się z bazą. W czasie połaczeń z serwerem postmaster uruchamia dodatkowy proces – postgres. Obsługuje on połączenia aplikacji klienckich z bazą danych. Postmaster nie może być uruchamiany z uprawnieniami użytkownika root. Powinno się utworzyć specjalnego użytkownika do tego celu (np. postgres).
Do sterowania procesem postmaster słuzy narzedzie pg_ctl. Za jego pomocą możemy zatrzymywać, uruchamiać i sprawdzać status serwera:

pg_ctl start [-w] [-D DATADIR] [-s] [-l FILENAME] [-o "OPTIONS"]
pg_ctl stop [-W] [-D DATADIR] [-s] [-m SHUTDOWN-MODE]
pg_ctl restart [-w] [-D DATADIR] [-s] [-m SHUTDOWN-MODE] [-o "OPTIONS"]
pg_ctl reload [-D DATADIR] [-s]
pg_ctl status [-D DATADIR]

Wszyscy użytkownicy bazy PosgreSQL muszą figurować w odpowiedniej tabeli
pg_user. Wydając więc dla przykładu zapytanie:

simp=# SELECT usename, usesysid FROM pg_user;

- otrzymamy wykaz wszystkich użytkowników wraz z ich identyfikatorem.
Do utworzenia nowego użytkownika służy program createuser. Pozwala on na ustawienie serwera do którego chcemy przypisać użytkownika, oraz praw (np. do aktualizowania danych w bazie). Uzytkownika możemy też stworzyć ręcznie np:

simp=# CREATE user “simp” WITH PASSWORD ‘password’ NOCREATEDB

Do usunięcia użytkownika służy polecenie sql DROP ( dropuser [opcje] nazwa_usera).
Możemy tworzyć też w Postgresie grupy (do ustawiania zbiorowych uprawnień). Służy do tego polecenie: CREATE GROUP nazwa. Do kontroli uprawnień (zarówno na poziomie uzytkowników jak i grup) służy polecenie GRANT:

simp=# GRANT SELECT, INSERT ON simp TO GROUP studenci;

W tej chwili użytkownicy z grupy studenci mogą wybierać i wprowadzać dane
do tablicy simp. Do obierania uprawnień służy polecenie REVOKE:

simp=# REVOKE INSERT ON simp FROM rajmund;

To polecenie odbiera użytkownikowi rajmund uprawnienia do wprowadzania
danych do tabeli simp.

Perspektywy

Perspektywy umożliwiają tworzenie ograniczonego widoku na określone
dane w bazie. Jeśli mamy np. tabelę studenci – i nie chcemy, żeby wszystkie dane z tej tabeli były dostępne nawet dla osób majacych uprawnienia do tej tabeli – możemy posłużyć się perspektywą.

Tworzenie i usuwanie bazy.

Nową bazę tworzymy za pomocą polecenia CREATE DATABASE np:

simp=# CREATE DATABASE nazwa
[WITH [LOCATION = 'sciezka']
[TEMPLATE = szablon]
[ENCODING = kodowanie]

Do usunięcia bazy posłuży oczywiście polecenie DROP.

Kopie zapasowe

PosgreSQL pozwala na tworzenie kopii zapasowych i procedur odtwarzania danych. Służą do tego programy: pg_dump, pg_dumpall i pg_restore. Polecenie utworzenia kopii zapasowej w najprostszej
postaci może wyglądać następująco:

pg_dump simp | gzip > simp_kopia.gz

Pg_dumpall służy do wykonywania kopii wszystkich baz w całej instalacji.
Ponieważ polecenie pg_dump pozwala na określanie formatu wykonywanego
backupu (np. pg_dump -F t, utworzy format archiwum tar), polecenie
pg_restore służy do odtwarzania kopii z archiwum.

Aktualizacja wersji

Co jakiś czas ukazuje się nowa wersja serwera PostgreSQL. Proces
aktualizacji całego systemu baz danych wspomaga narzedzie pg_upgrade. Przed aktualizacją należy jednak zrobić kopię zapasową wszystkich danych.

Wydajność

Jeżeli nasza baza jest niezbyt pokaźnych rozmiarów, sprawy takie jak indeksy czy wydajność mogą nie mieć dużego znaczenia. Nabierają go jednak – gdy okazuje się, że nasze dane rozrastają się
w szybkim tempie, bądź mają być wykorzystywane przez wiekszą liczbę użytkowników. Jednym z poleceń, poprawiających wydajność bazy jest VACUUM. Za jego pomocą odzyskujemy m.in miejsce w bazie (utracone np. w
wyniku procedur rollback, czyli cofania nieudanych transakcji) oraz aktualizujemy statystyki optymalizatora. Dla przykładu:

simp=# vacuum verbose studenci;
NOTICE: –Relation studenci–
NOTICE: Pages 1: Changed 1, reaped 1, Empty 0, New 0, Crash 0
UnUsed 0, MinLen 110, MaxLen 128, Re-using: Free/Avail. Space
7005/0 EndEmpty/Avail. Pages 0/0. CPU 0.00s/0.00u sec.
[...]

Ponieważ dodaliśmy do polecenia opcję verbose, system wyświetlił
nam też niektóre statystyki .

Sposób autoryzacji (kwestia pytania o hasło przy próbie połączenia z bazą) zdefiniowana jest w pliku pg_hba.conf znajdującym się w katalogu z danymi Postgresa. Na końcu tego pliku znajują się dwie takie linie:

local all trust
host all 127.0.0.1 255.255.255.255 trust

Oznaczają one, że dla połączeń lokalnych (local) – czyli takich gdzie łączymy się nie korzystająć z socketów tcp/ip, dla dowolnej bazy (all) system ma przyjąć regułę niepytania o hasło (trust).
dla połączeń zdalnych, ale tylko z maszyny o adresie 127.0.0.1 (czyli z tego samego komputera, ale przez sockety tcp/ip), też będzie ta sama reguła.
Aby to zmienić należy zmienić ostatnie słowo (trust) na “password”, “crypt” lub “md5″ (różnią się one metodą przesyłania hasła oraz akceptowalną długością hasła). Np. zapis:

host all 81.15.147.193 255.255.255.0 password

Oznacza, że osoby łączące się z serwera o ip 81.15.147.193 oraz z całej klasy C muszą podać hasło, aby dostać się do dowolnej bazy

Sieciowy system plików NFS

Sierpień 11th, 2008 Brak komentarzy »

Rajmund Radziewicz

Sieciowy system plików NFS – jest mechanizmem pozwalającym na współdzielenie zasobów pomiędzy komputerami w sieci. Jest to narzędzie o tyle korzystne w przypadku dystrybucji livecd (Knoppix, Linux-EduCD, Ubuntu), że podczas pracy bezpośrednio z płyty mamy możliwość centralnego zapisywania danych przez użytkowników – np. na szkolnym serwerze.Ponieważ w linuksie każde urządzenie reprezentowane jest jako plik, można w ten sam sposób udostępniać w sieci wszelkie wymienne napędy. Najprostszy scenariusz wykorzystania NFS-a w sieci mógłby wyglądać następująco: Na jednym komputerze (będzie to nasz “serwer plików”) zainstalowany jest Knoppix na twardym dysku. Udostępnia on poprzez NFS katalog: users. W katalogu tym są podkatalogi utworzone specjalnie dla użytkowników w taki sposób .. że każdy z poszczególnych hostów w sieci – ma prawo zapisu tylko do swojego katalogu (np. /mnt/users/rajmund). Pozostałe komputery pracują pod kontrolą Knoppiksa uruchomionego z płyty CD. Przy odpowiedniej ilości pamięci RAM, mogłyby nawet nie posiadać twardych dysków. Użytkownik Rajmund pracujący na hoście X – może w wygodny sposób zapisywać wyniki swojej pracy na komputerze pełniącym rolę wewnętrznego serwera, zupełnie tak, jakby zapisywał dane na lokalnym dysku. To tyle może w ramach wstępu.

NFS składa się z dwóch części: serwera i klienta. Demony wchodzące w jego skład to:

nfsd – demon obsługujący zapytania klientów.
mountd – demon montowania NFS obsługujący zapytania przesyłane do niego przez nfsd
portmap – pozwala klientom NFS “zgadnąć”, który port serwera używa NFS
Najprościej na początek uruchomić NFS-a na dwóch komputerach. Zakładam, że mamy min. dwa komputery w sieci, które nawzajem się “widzą” (najlepiej sprawdzić programem ping). W razie potrzeby niezwykle pomocny okazuje się netcardconfig. Załóżmy, że komputer udostępniający katalog users do zapisu ma ip 192.168.0.8
Komputer pełniący rolę klienta: 192.168.0.10. Przechodzimy do komputera, który będzie udostępniał katalog. Zamieniamy się w root-a i uruchamiamy na tej maszynie demona portmap:

# cd /etc/init.d
# ./portmap start

Możemy też za pomocą ‘ps aux’ upewnić się, czy portmap nie jest już uruchomiony.
Następnie tworzymy w/w katalog users (przykładowo w katalogu /home/knoppix)

# mkdir /home/knoppix/users

Teraz pora na utworzenie pliku /etc/exports, w którym umieścimy informację co i komu będziemy udostępniać. Zawartość naszego /etc/exports wygląda następująco:

/home/knoppix/users 192.168.0.10(rw)

Zapis (rw) mówi o tym, że komputer 192.168.0.10 ma prawo zarówno zapisu, jak i odczytu do katalogu users na serwerze. Tym też możemy regulować prawa dostępu do określonych podkatalogów users, w przypadku gdybyśmy umieszczali w pliku /etc/exports więcej komputerów (wystarczy dopisywać ‘rw’ tylko przy katalogach, do których określony użytkownik ma mieć prawo zapisu). Następnie uruchamiamy skrypt zarządzający nfsd i obsługą nfs-a w kernelu. W katalogu /etc/init.d/ wykonujemy polecenie:

# ./nfs-kernel-server start
# rpc.mountd && rpc.nfsd

cellulitis treatment

Pamiętajmy, że przy każdej zmianie pliku /etc/exports należy “odnowić” usługę eksportowania zasobów. Najprościej: exportfs -a

Tym sposobem sprawę serwera mamy za sobą. Przechodzimy teraz do klienta. W naszym przypadku jest to komputer z uruchomionym z płyty Knoppiksem 3.2. Tu także wystartujmy portmap-a (pamiętajmy, że tu także pracujemy z konta root-a):

# cd /etc/init.d
# ./portmap start

Następnie utwórzmy katalog, w którym zamontujemy zdalny katalog users:

# mkdir /mnt/domowy_zdalny

Zamontujmy udostępniony przez serwer zasób:

# mount -t nfs 192.168.0.8:/home/knoppix/users /mnt/zdalny

… teraz wystarczy cd /mnt/domowy_zdalny/ … i widzimy co udostępnił nam komputer 192.168.0.8. Możemy także do tego katalogu zapisywać. W przypadku klienta pracującego pod kontrolą Knoppiksa z twardego dysku, warto montowanie /home/knoppix/users dopisać do /etc/fstab – a demony odpowiedzialne za NFS startować razem z systemem.

HDPARM – kontrola napędów w systemie

Sierpień 11th, 2008 Brak komentarzy »

Rajmund Radziewicz

W Linuksie możemy bardzo precyzyjnie odczytywać i ustawiać parametry twardego dysku czy pozostałych napędów IDE naszego komputera. Daje to ogromną kontrolę nad wieloma operacjami systemowymi i często pozwala zwiększyć wydajność takich operacji, w szczególności związanych z zapisem bądź odczytem danych. Do kontrolowania tego typu ustawień służy program hdparm.Pozwala m.in na:

  • testowanie, diagnozowanie i ustawianie szybkości odczytu/zapisu urządzeń
  • włączanie/wyłączanie DMA
  • sterowanie zachowaniem buforów podręcznych (cache)
  • ustawianie urządzeń w trybach: tylko-do-odczytu/tylko-do-zapisu
  • Włączanie/wyłączanie automatycznej funkcji oszczędzania energii w niektórych napędach
  • Wyłączanie/włączanie wbudowanej w napęd opcji zarządzania uszkodzeniami. Przy tej opcji firmware urządzenia próbuje automatycznie zarządzać uszkodzonymi sektorami, przenosząc je w zapasowe miejsce

Oczywiście dobór wszelkich ustawień pownien być dobrze przemyślany. Nieostrożne posługiwanie się hdparmem i stosowanie “zbyt wygórowanych opcji” na “niezbyt wygórowanym sprzęcie”, może doprowadzić nawet do utraty danych. Warto więc przed “eksperymentami” zrobić kopię zapasową i dowiedzieć się (np. z dokumentacji) na co możemy sobie pozwolić, zwiększając wydajność dysków.
Domyśle ustawienia jądra przy dostępie do kontrolerów i dysków IDE w Linuksie są dosyć “ostrożne” i najczęściej do normalnej pracy w zupełności wystarczają. W momencie kiedy potrzebujemy jednak zwiekszyć wydajność, przykładowo dlatego, że stosujemy aplikacje przetwarzające duże ilości danych — wówczas hdparm może okazać się przydatny. Przed ustawieniami hdparma, warto dowiedzieć się więcej o możliwościach naszego dysku. Polecenie:

/sbin/hdparm -I /dev/hda

… poda nam dokładne informacje o napędzie, obsługiwaną pamieć, szybkość, liczbę cylindrów, konfigurację itp. Warto sprawdzić również w dokumentacji — czy poza samym dyskiem nasza płyta główna również obsługuje DMA, czy kontroler naszego dysku jest 32-bitowy ..itd.
Aby sprawdzić domyślne ustawienia z jakimi aktualnie pracuje nasz dysk, wystarczy polecenie:

/sbin/hdparm /dev/hda

W rezultacie możemy otrzymać coś w stylu:

/dev/hda:
multcount = 16 (on)
IO_support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 0 (off)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 8 (on)
geometry = 2432/255/63, sectors = 39070080, start = 0

Z tych ważniejszych parametrów, istotne są:

IO_support — sposób przekazywania danych do kontrolera. W naszym przypadku jest to tryb 16-bitowy. Bardzo “ostrożny”, ale większość dzisiejszych układów obsługuje już 32 bity.
using_dma — ta flaga określa nam, czy dysk używa tzw: bezpośredniego dostępu do pamięci (DMA).
unmaskirq — ustawienie to pozwala sterownikowi na “niemaskowanie” innych przerwań podczas przetwarzania przerwania dyskowego, co może znacznie poprawić czas reakcji systemu. Należy pamiętać, że nie wszystki urządzenia potrafią obsłużyć taką opcję!

Sprawdźmy aktualną wydajność naszego dysku:

/sbin/hdparm -Tt /dev/hda

Program hdparm z flagą -T pokazuje nam test szybkości odczytu pamięci podręcznej, -t test szybkości odczytu danych, nie znajdujących się w pamięci podręcznej. Wynik powyższego polecenia może wyglądać następująco:

/dev/hda:
Timing buffer-cache reads: 492 MB in 2.01 seconds = 244.78 MB/sec
Timing buffered disk reads: 42 MB in 3.07 seconds = 13.68 MB/sec

Można zwiększyć te parametry, jeżeli pozwala na to nasze urządzenie. Tak więc po kolei:

-d1 włącza obsługę DMA
-c1 32-bitową obsługę we/wy
-u1 ustawienie opisanego wyżej “niemaskowania” przerwań
-m16 (w niektórych dyskach również -m32) ustawia tzw: wielosektorowe we/wy. Często powoduje znaczn zwiększenie przepływu danych

Należy pamiętać, że powyższe opcje często mogą nie przynieść oczekiwanego rezultatu, jeśli przykładowo do kontrolera podpięte są jakieś urzadzenia nie obsługujące UDMA. Podsumowując, jeśli chcemy włączyć 32-bitowy dostęp do dysku, obsługę DMA i wielosektorowe we/wy, wpisjemy:

/sbin/hdparm -m16 -c1 -d1 -u1 /dev/hda

Jeśli chcemy, żeby ustawienia te były aktywne po restarcie komputera, należy dopisać powyższą komendę do skryptu startowego.
W Debianie lub dystrybucjach na nim bazujących, można polecenie hdparm z odpowiednimi opcjami dopisać do /etc/init.d/rcS. Plik ten jest wykonywany jeszcze przed sprawdzaniem systemu plików. W RedHacie i pochodnych od niego (Fedora, Whitebox, Aurox) możemy dopisać wywołanie hdparma do /etc/rc.d/rc.local, przykładowo:

if [ /usr/sbin/hdparm ]; then

echo ‘ustawiam opcje hdparm dla /dev/hda’
hdparm -qm16 -qc3 -qd1 -qu1 /dev/hda

fi

Dodatkowe ‘-q’ powoduje, że opcje wykonywane są “cicho” (bez wyświetlania komunikatów przez system).

Odnośniki

Sierpień 10th, 2008 Brak komentarzy »

Polecane serwisy:

Knoppix.pl

SKOS

Polskie Forum Linuksowe – Linuksowo.pl

LinuxNews.pl

JakiLinux.org

Knoppix.7thguard.net

Linux.pl

Alrauna

SNTI

Security:

Phrack.org

Ha.ckers.org

Security fuzzing

PacketStorm

Doxpara.com

lcamtuf.coredump.cx

IPSEc.pl

Intelligent Debugging :)

SecurityFocus

Graficzne centrum administracyjne

Sierpień 10th, 2008 Brak komentarzy »

W Linux-EduCD dostępne jest graficzne centrum administracyjne mcc (Mandriva Control Center) znane z Mandrivy czy PCLinuxOS. Narzędzie znajdziemy w KMenu -> Centrum administracyjne. Można też uruchomić je z konsoli poleceniem:
drakconf lub mcc.

W skład MCC wchodzą m.in:

drakconnect – konfiguracja sieci (ethernet, wireless, ISDN, Satelita (DVB), bluetooth, GPRS)
drakhardware – konfiguracja i wykrywanie sprzętu
drakperm – konfiguracja uprawnień do zasobów systemu
draksec – profile/poziomy bezpieczeństwa (nakładka na msec)
drakxservices – zarządzanie usługami/demonami w systemie
diskdrake – zarządzanie dyskami/partycjami
drakgw – współdzielenie połączenia sieciowego
printerdrake – zarządzanie/konfiguracja drukarki
drakbackup – tworzenie kopii zapasowych
draklog – narzędzie do monitorowania logów
drakxtv – konfiguracja karty telewizyjnej
userdrake – zarządzanie użytkownikami
drakfirewall – konfiguracja firewalla
drakfont – instalacja i zarządzanie czcionkami, pobieranie czcionek windowsowych
drakauth – uwierzytelnianie
drakboot – konfiguracja opcji logowania do systemu
draknet_monitor – monitorowanie połączeń sieciowych
mousedrake – konfiguracja myszy
drakedm – konfiguracja graficznego menadżera logowania
draksambashare – udostępnianie zasobów/drukarek
drakproxy – konfiguracja pośrednika proxy
drakvpn – konfiguracja VPN
drakx11 – konfiguracja karty graficznej/monitora
drakups – konfiguracja UPS’a
drak3d – efekty 3D pulpitu
scannerdrake – konfiguracja skanera
draklocale – wybór/zmiana języka/kodowania/lokalizacji
drakTermServ – zarządzanie pakietem TerminalServer

Automatyczne montowanie partycji NTFS

Sierpień 10th, 2008 Brak komentarzy »

Za montowanie partycji NTFS w Linux-EduCD 0.9 odpowiada sterownik ntfs-3g. Możemy w każdej chwili zamontować partycję (z poziomu konta root) do zapisu poleceniem:

ntfs-3g /dev/partycja /mnt/win_d

Możemy również zautomatyzować cały proces. Jeśli chcemy – aby system montował partycje NTFS do zapisu automatycznie, musimy zmodyfikować nieco pliki modprobe.preload oraz fstab. Edytujemy jako użytkownik root plik /etc/modprobe.preload (za pomocą vim’a, mcedit, kate) i dopisujemy na jego końcu: “fuse”.

Następnie jako root modyfikujemy plik /etc/fstab

Jeśli posiadamy jakieś partycje NTFS zobaczymy coś w stylu:

———
## fstab dla Linux-EduCD

none    /proc   proc    defaults        0 0
none    /dev/pts        devpts  mode=0620       0 0
none    /proc/bus/usb   usbfs   defaults        0 0

# /dev/sda1, size=104968710, type=7: NTFS (primary)
/dev/sda1       /mnt/win_d      ntfs    user,exec,ro,noauto,nls=utf8,umask=0    0 0

# /dev/sda4, size=48195, type=131: Linux native (primary)
/dev/sda4       /mnt/sda4       ext2    user,exec,rw,noauto     0 0

# /dev/sda5, size=83955627, type=131: Journalised FS: ext3 (extended)
/dev/sda5 / ext3 noatime 1 1
——————

W pliku tym zmieniamy wszystkie wystąpienia “ntfs” na “ntfs-3g”.

Następnie wydajemy polecenie: modprobe fuse

Odmontowujemy partycje:

umount /mnt/win_d

Oraz montujemy ponownie:

mount /mnt/win_d

Jeśli chcemy – aby partycje NTFS montowane były w trybie do-zapisu przy każdym uruchomieniu system, możemy do pliku /etc/rc.local dopisać:

ntfs-3g /dev/partycja /mnt/partycja

Cron – uruchamianie zadań w określonym czasie

Sierpień 10th, 2008 Brak komentarzy »

Demon cron służy do uruchamiania zadań systemowych o określonym czasie, z dokładnością do minuty. Przydatny jest zarówno do harmonogramowania czynności administracyjnych (archiwizacja, usuwanie plików tymczasowych, audyty bezpieczeństwa), jak również do uruchamiania asynchronicznie dowolnych programów/skryptów czy innych usług np. z określonymi parametrami.

Cron przeszukuje pliki “crontab” (tabele) które znajdują się w /var/spool/cron/crontabs i odczytuje zawarte w nich instrukcje. W pliku /etc/crontab wpisane są dodatkowe reguły, które uruchamiają zadania cogodzinowe, codzienne, cotygodniowe oraz comiesięczne. Zadania te (w postaci skryptów) znajdują się kolejno w : /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly i /etc/cron.monthly.

Wpisy w plikach crontab zbudowane są z 6 pól. Pierwsze 5 pól określa czas wykonania, natomiast 6 pole czynność.

Opis poszczególnych pól:

- Minuta (od 0 do 59)
- Godzina (od 0 do 23)
- Dzień (od 0 do 31)
- Miesiąc (od 0 do 12)
- Dzień tygodnia (od 0 do 7)
- Polecenie (reszta)

Jeśli dane pole zawiera gwiazdkę (*), oznacza “wykonuj zawsze”.

Żeby uruchomić określony skrypt lub zadanie, wydajemy polecenie:

crontab -e (edytuj tablicę crona)

i dopisujemy do niej przykładowo:

*/2 * * * * exec /ścieżka/do/skryptu

Teraz co dwie minuty będzie wykonywany skrypt – do którego ścieżkę podaliśmy w tablicy. Inne przykłady:
0 2 * * * /sbin/shutdown -h now - wpis oznacza, że codziennie o 2.00 będzie wyłączany komputer

0 22 * * 1-5 mail -s “Mail od crona” – codziennie o 22.00 wysyłaj maila o podanej treści do właściciela

0 11 * * 1,3 /opt/skrypt.sh – uruchamiaj /opt/skrypt.sh w każdy poniedziałek i środę o godz. 11

Ponadto:

crontab -l – wyświetla listę zadań bieżącego użytkownika systemowego zdefiniowaną w tablicy crona

crontab -e – edytuje tablicę

crontab -r czyśc tablicę

Cron loguje wszystkie swoje czynności do /var/log/cron (pośredniczy w tym demon syslogd).

System e-learningowy MOODLE

Sierpień 10th, 2008 Brak komentarzy »

Rajmund Radziewicz


Artykuł w rozszerzonej wersji opublikowany został na łamach drugiego numeru kwartalnika “Linux w Szkole”

Moodle – jest wysokiej jakości Systemem Zarządzania Nauczaniem, dostarczanym na licencji GPL. Służy do prowadzenia zdalnych kursów oraz projektowania, tworzenia, składowania i udostępniania materiałów szkoleniowych.
Oczywiście jego funkcjonalność jest bardzo zróżnicowana. Może służyć przykładowo jako platforma do budowy portalu internetowego. Termin Moodle jest skrótem od “Modular Object-Oriented Dynamic Learning Environment” (modularne, zorientowane obiektowo, dynamiczne środowisko nauczania) i w wolnym tłumaczeniu oznacza również proces “leniwego wałęsania się”, “przyjemnego majsterkowania”, prowadzacego do zdobywania wiedzy i kreatywności. Według twórcy tego oprogramowania, każdy korzystajacy z Moodle’a, jest właśnie takim “Moodlerem”, “kreatywnym majsterkowiczem”.
Ogromną zaletą systemu jest to, że pomimo wielu, często bardzo rozbudowanych funkcji – jest wyjątkowo prosty w obsłudze i użytkowaniu. Interfejs jest bardzo dobrze zaprojektowany. Zupełnie pozbawiony wszelkich “wodotrysków”, z wygodnym menu nawigacyjnym, dostępnym na każdym “poziomie” pracy z systemem – ma w zasadzie tylko to, co jest niezbędne. Wytyczne autorów Moodle’a, których celem było ograniczenie potrzeby interwencji administratora do minimum, przy jednoczesnym zachowaniu bezpieczeństwa i jak największej elastyczności podczas pracy, są tu bardzo widoczne. Moodle ma również doskonałe wsparcie dla prawie 30 języków – a liczba ta powiększa się z wersji na wersję.

Przy projektowaniu wirtualnych lekcji, czy kursów, mamy dostęp do zbioru wielu “składowych systemu”. Są więc dostępne: fora dyskusyjne, pokoje rozmów, dzienniki, quizy, zasoby, ankiety, zadania. Mamy możliwość generowania rozbudowanych testów, tzw: wyborów, dodatkowych skal ocen, czy punktowania wykonanych prac. Możemy określać, które zasoby i części interfejsu Moodle’a mają być widoczne dla zarejestrowanego użytkownika, a które dla “gościa”, odwiedzającego przypadkowo nasz serwis. Zebrane przez system oceny mogą być wyeksportowane w formacie arkusza Excella, bądź w postaci tekstowej tabeli. Długo by tak jeszcze można wymieniać – więc chyba lepiej będzie jak od razu zabierzemy się za instalację.


Instalacja i konfiguracja

Moodle jest systemem napisanym w PHP i wykorzystującym bazę danych. Początkowo dedykoway był dla Linuksa, serwer WWW Apache, i serwer baz danych MySQL. W tej chwili potrafi pracować również z PostgreSQL oraz na innych platformach systemowych. My zajmiemy się instalacją zalecaną przez autorów, czyli skomponujemy całość przy pomocy bazy MySQL, Apache’a i dołożymy do tego PHP4. Przyda się nam również biblioteka PHP4-GD, z obsługą formatów JPG i PNG. Jest ona wykorzystywana go generowania wykresów w “raportach aktywności” wszystkich użytkowników systemu. Nie jest oczywiście obowiązkowa do instalacji, czy też prawidłowego działania Moodle’a. Całość zainstalujemy i skonfigurujemy na Debianie, ale jako że system nie będzie instalowany z pakietów binarnych, czy też kompilowany ze źródeł (w końcu to PHP), sposób jego instalacji będzie niemalże taki sam w każdej dystrybucji Linuksa. Różnice mogą co najwyżej dotyczyć lokalizacji plików httpd.conf, czy php.ini, które będziemy edytować. Ewentualnie katalogu głównego serwera WWW, w którym umieścimy wszystkie pliki instalowanego systemu.

W Debianie najwygodniej będzie posłużyć się programem apt-get, który automatycznie pobiera odpowiednie paczki *.deb z sieciowych repozytoriów i instaluje je w systemie. Jako użytkownik root uaktualniamy więc listę źródeł, znajdującą się w /etc/apt/source.list:

apt-get update

Po zaktualizowaniu, instalujemy wymagane oprogramowanie:

apt-get install mysql-common mysql-client php4-mysql php4-gd apache apache-common apache-utils

Jak widać tym jednym poleceniem zainstalowaliśmy serwer Apache z obsługą PHP4, bibliotekę PHP4-GD oraz serwer baz danych. Oczywiście powyższy sposób zakłada, że nie mieliśmy żadnego z wymaganych przez Moodle’a komponentów. Gdybyśmy proces instalacji przeprowadzali przykładowo w zainstalowanym na dysku Knoppiksie lub bazującym na nim Linux-EduCD (oba również wykorzystują pakiety *.deb), powinniśmy zainstalować jedynie php4-gd.
Teraz w pliku /etc/apache/httpd.conf ustawiamy właściwą nazwę serwera. Wpisujemy ją za odkomentowaną dyrektywą “ServerName”. Pamiętajmy również o “DocumentRoot”, który powinien wskazywać na /var/www/. Jako że będziemy chwilowo testować system lokalnie, stąd ServerName wskazuje u mnie na “localhost”.
Następnie pobieramy najnowszą stabilną wersje systemu Moodle ze strony http://moodle.org/download/ i umieszczczamy w katalogu /var/www/. Jako użytkownik root rozpakowujemy ją i tworzymy katalog moodledata:

cd /var/www
unzip moodle-1.1.1.zip
cd moodle
mkdir moodledata

Teraz w katalogu moodledata, który będzie służył jako miejsce do wysyłania (uploadowania) zewnętrznych plików, wykorzystywanych przez system (np. prac, dodatkowych materiałów kursowych itp) tworzymy ukryty plik o nazwie .htaccess, zawierający linię :

deny from all

Upewnijmy się również, że Moodle oraz Apache (w zasadzie właściciel jego procesów) będzie miał prawo odczytu i zapisu do tego katalogu! W razie potrzeby, możemy posłużyć się poleceniem chmod. Teraz powinniśmy ustawić hasło roota dla serwera MySQL i założyć użytkownika, który będzie właścicielem bazy moodle. Jeśli system działa wyłącznie lokalnie – właścicielem może być również administrator serwera baz danych. Najpierw uruchamiamy sam serwer:

cd /etc/init.d ; ./mysql start

Następnie ustawiamy hasło administratora:

mysqladmin -h localhost -u root password “haslo_administratora”
mysqladmin -p reload

Wreszcie uruchamiamy tzw. monitor mysql (program, za pomocą którego możemy interaktywnie komunikować się z serwerem baz danych MySQL) i tworzymy pustą bazę o nazwie moodle. Jeśli użytkownikiem tej bazy ma być administrator – nie musimy definiować dodatkowych uprawnień. Jeżeli natomiast ma być to jakiś “dedykowany” dla Moodle’a użytkownik, musimy założyć mu konto i ustawić odpowiednie uprawnienia do operacji na bazie. Reasumując:

treatment of acute asthma

mysql -u root -p

Podajemy utworzone przed chwilą hasło. Następnie już w “wierszu poleceń” mysql wykonujemy dalsze działania:

mysql> USE mysql;
mysql> INSERT INTO user set Host=’localhost’, User=’uzytkownik’, Password=PASSWORD(‘jakies haslo’);
mysql>FLUSH PRIVILEGES;

Na koniec najważniejsze:

mysql> CREATE DATABASE moodle;
mysql> GRANT select,insert,update,delete,create,drop,index,alter ON moodle.*
mysql>TO uzytkownik@localhost;
mysql>FLUSH PRIVILEGES;
mysql> quit

Teraz powinniśmy sprawdzić, czy nasz serwer WWW będzie potrafił odczytywać index.php, jako główną stronę – kiedy po skończonej już konfiguracji i instalacji wpiszemy w przeglądarce: http://localhost/moodle. W naszym /etc/apache/httpd.conf, w linii gdzie znajduje się dyrektywa “DirectoryIndex”, powinno być przynajmniej coś takiego:

DirectoryIndex index.html index.htm index.php

Jeżeli korzystamy z Apache w wersji 2.X powinniśmy również koniecznie dodać do pliku httpd.conf następujący wpis:

AcceptPathInfo on

Teraz pozostała jeszcze konfiguracja pliku php.ini. Domyślne ustawienia mogą niestety nie być wystarczające dla Moodle’a. W /etc/php4/apache/php.ini, powinny znaleźć się opcje, ustawione w następujący sposób:

magic_quotes_gpc = 1
magic_quotes_runtime = 0
file_uploads = 1
short_open_tag = 1
session.auto_start = 0
session.bug_compat_warn = 0

Poza notacją “1″ i “0″, dopuszczalna jest również “ON” i “OFF”. Jeżeli jakiejkolwiek opcji brakuje, należy ją dopisać.
Po tych czynnościach możemy przejść do przygotowania głównego skryptu konfiguracyjnego Moodle’a – /var/www/moodle/config.php. Pierwotnie, po rozpakowaniu katalogu, znajdziemy w nim jedynie config-dist.php. Robimy więc kopię, tworząc w ten sposób właściwy plik:

cd /var/www/moodle/
cp config-dist.php config.php

A następnie edytujemy config.php i wpisujemy odpowiednie wartości w miejsce zmiennych “dbname”, “dbuser” itd:

$CFG->dbtype = ‘mysql’;
$CFG->dbhost = ‘localhost’;
$CFG->dbname = ‘moodle’;
$CFG->dbuser = ‘uzytkownik’;
$CFG->dbpass = ‘jakies_haslo’;

$CFG->wwwroot = ‘http://localhost/moodle’;
$CFG->dirroot = ‘/var/www/moodle’;
$CFG->dataroot = ‘/var/www/moodle/moodledata’;

Pozostała część konfiguracji odbywa się już za pomocą przegladarki WWW. Wymagane jest, aby zezwalała ona na zapis plików cookies. Otwieramy więc dowolną i wpisujemy:

http://localhost/moodle/admin

Jest to tzw: strona administracyjna, za pomocą której skończymy konfigurację naszej platformy. Na pierwszym ekranie musimy potwierdzić warunki licencji GPL. Po kliknięciu “Yes” przejdziemy do następnej strony, na której Moodle rozpocznie konfigurację bazy danych i tworzenie tabel. Widoczna będzie seria poleceń SQL, a po nich podsumowanie w kolorze zielonym lub czerwonym, najczęściej w postaci komunikatu: “SUCCESS”. Przejdziemy tak przez kilka kolejnych stron, aż dojdziemy do formularza, w którym określimy tzw. zmienne instalacji: język interfesju, kraj, hosty SMTP itd. Na koniec klikamy w “Save changes” i przechodzimy dalej.

W trakcie nastąpi zmiana języka interfejsu (oczywiście jeżeli na ekranie “zmiennych” wybraliśmy z listy język polski a jako “locale” wpisaliśmy “pl”) i przejdziemy do formularza, przy pomocy którego utworzymy konto administratora. Domyślnie konto nazywa się “admin” i jego domyślne hasło również brzmi “admin”.
Po ostatecznej instalacji i konfiguracji, system wyświetli główną stronę serwisu. Po lewej stronie zobaczymy zbiór odnośników administracyjnych, za pomocą których możemy zarządzać całym systemem Moodle. Pozwalają one na: tworzenie i usuwanie kursów, zakładanie i modyfikowanie kont użytkowników i wprowadzanie globalnych zmian w systemie. Każdy założony kurs, posiada własny panel administracyjny (dostępny tylko dla administratora, bądź prowadzącego, którego “mianował” administrator) pozwalający na zarządzanie ustawieniami w obrębie danego kursu i jego składowymi.

Na zakończenie części instalacyjnej warto tylko jeszcze przypomnieć, że Moodle posiada mechanizm wykonywania zadań okresowych. Wywoływane są one przez skrypt o nazwie cron.php, znajdujący się w katalogu admin. Są to zadania “konserwacyjne”, niezbędne na dłuższą metę do poprawnego działania systemu. Ponadto Moodle automatycznie sprawdza aktywne fora dyskusyjne i wysła kopie postów użytkownikom, którzy się na nie zapisali. Skrypt ten można w dowolnym momencie wywołać “ręcznie”, przez wpisanie w oknie adresowym przeglądarki: http://localhost/moodle/admin/cron.php.
Przy aktywnym użytkowaniu i dużej liczbie pracujacych osób, powinniśmy jednak ustawić automatyczne wykonywanie się tego skryptu, najlepiej dopisując jego wywołanie do tabeli linuksowego crona. Edycje takich tabel wykonuje się za pomocą polecenia “crontab -e”. Po wykonaniu tego polecenia dodajemy poniższą linię:

*/15 * * * * wget -q -O /dev/null http://localhost/moodle/admin/cron.php

To spowoduje, że cron będzie uruchamiał co 15 minut program wget, wywołujacy skrypt /var/www/moodle/admin/cron.php, a wynik wywołania przekieruje do /dev/null/, swojego rodzaju systemowej “czarnej dziury”. Jest to korzystne rozwiązanie, w przypadku kiedy obsługujemy jakieś aplikacje wsadowo.

Instalacja Moodle w systemie FreeBSD 5.2

Zakładam, że w naszym FreeBSD nie jest zainstalowany żaden z wymaganych przez Moodle serwerów, ani też moduł mod_php4. Do instalacji tych pakietów bedziemy potrzebowali aktualnej kolekcji portów. Jeżeli ktoś podczas instalowania FreeBSD zapomniał jej zaznaczyć, powinien teraz doinstalować. Do tego celu można wykorzystać program konfiguracyjny sysinstall. Jako użytkownik root wydajemy polecenie:

/stand/sysinstall

Z wyświetlonego menu wybieramy pozycję “Configure”. Z kolejnego podmenu “Distributions”, następnie “ports” (zaznaczamy tę opcję spacją), wkładamy płytkę z FreeBSD do napędu i z wyświetlonych metod instalacyjnych wybieramy CD-ROM. Po instalacji wychodzimy z programu sysinstall. W tym momencie zbiór naszych portów znajduje się w /usr/ports/. Udajemy się tam po reszte potrzebnych rzeczy:

cd /usr/ports/databases/mysql323-server
make && make install && make clean

Cała operacja może chwilę potrwać. System ściągnie nam źródła serwera MySQL, z wszelkimi wymaganymi zależnościami, następnie skompiluje je i zainstaluje. Analogicznie postępujemy z pozostałymi, wymaganymi pakietami:

cd /usr/ports/www/apache13
make && make install && make clean

cd /usr/ports/www/mod_php4
make && make install && make clean

Po wszystkim, katalog główny Apache’a znajdzie się w /usr/local/www/. Edytujemy również plik konfiguracyjny httpd.conf, znajdujący się w /usr/local/etc/apache/, w którym ustawiamy nazwę naszego serwera (dyrektywa ServerName). Sam serwer możemy uruchomić komendą:

sh /usr/local/etc/rc.d/apache.sh

Analogicznie możemy wystartować serwer baz danych MySQL:

/usr/local/etc/rc.d/mysql.sh

Następnie pobieramy spakowanego Moodle’a ze strony http://moodle.org/download/. Najnowsza stabilna wersja nosi numerek 1.1. Paczkę umieszczamy w katalogu /usr/local/www/data/ i rozpakowujemy:

cd /usr/local/www/data/
unzip moodle-1.1.1.zip

Teraz tworzymy katalog moodledata, w którym przechowywane będą pliki, wysyłane przez użytkowników Moodle’a na serwer:

cd /usr/local/www/data/moodle/
mkdir moodledata

Konfiguracja config.php, zakładanie hasła administratora MySQL i bazy moodle są praktycznie identyczne jak w opisie instalacji pod Linuksem. Jedyne o czym powinniśmy pamiętać, to o ścieżkach do wwwroot, dirroot i dataroot, które ustawiamy w pliku config.php. Jako że katalog główny Moodle’a znajduje się w przypadku FreeBSD w /usr/local/www/data/, a nie, jak to miało miejsce w Debianie – w /var/www/ – ścieżki powinny oczywiście odnosić się do prawidłowej lokalizacji.

Tworzymy kurs ‘Obsługa urządzeń w systemie Linux’

Moodle jest w tej chwili w pełni zainstalowany i skonfigurowany. Mamy założone konto “admin” i dostęp do “panelu sterowania”. Pora na założenie pierwszego kursu i dodanie do niego użytkowników. Dla większej zgodności z terminologią Moodle’a, w dalszej części artykułu pozwolę sobie na stosowanie terminów “studenci” (lub “uczniowie”), a także “prowadzący”, “goście”, “autorzy kursów” i oczywiście “administrator”, w odniesieniu do osób pracujących z platformą.
Kurs będzie oczywiście zwiazany z Linuksem, a dokładniej – z obsługą urządzeń w systemie Linux. Klikamy więc w odnośnik “Kursy” i dodajemy nową kategorię. Otworzy się nam ekran z formularzem zatytułowanym “Kategorie kursów”. Klikamy w przycisk “Dodaj nową kategorię”, nazywamy ją “Linux” i w obrębie tej kategorii dodajemy za pomocą analogicznego formularza kurs o nazwie “Obsługa urządzeń w systemie Linux”. Na formularzu dodawania nowego kursu, możemy ustawić takie parametry jak nazwę, datę rozpoczęcia, streszczenie i format. Możemy również określić, czy kurs ma być dostępny po uwierzytelnieniu się za pomocą dodatkowego klucza (jego wartość wpisujemy do formularza), czy osobom logującym się, ma być wyświetlany “skrócony raport ostatnich wydarzeń”, oceny itp.
Jeśli chodzi o wspomniany przed chwilą format, Moodle obsługuje trzy ich “typy”:

Format tygodniowy

Kurs podzielony jest na jednostki, odpowiadajace tygodniom. Tygodnie dzielą się na dodawane przez prowadzącego “składowe”. Są to “zasoby”, “ankiety”, “testy”, “dzienniki”, “czaty”, “fora”, “zadania” itd. Dostępne są z rozwijalnego menu, widocznego kiedy pracujemy w tzw: “trybie edycji”. Niektóre z nich, mogą być dostępne tylko przez określony okres czasu, zdefiniowany przez prowadzącego kurs.

Format tematyczny

Jest to format bardzo podobny do tygodniowego. Jedyną różnicą jest to, że jednostki zamiast na tygodnie – dzielą się na “tematy”. Nie ma również żadnych ograniczeń czasowych związanych z dostępem do poszczególnych “składowych”.

Format towarzyski

Format bazujący jedynie na forum dyskusyjnym, które wyświetlone jest na główej stroniej. Wykorzystywany przy mniej sprecyzowanych zapotrzebowaniach. Autorzy systemu zalecają taki format do generowania np. uczelnianej tablicy ogłoszeń.

My wybieramy “format tematyczny”. Po przejściu na główną stronę nowego, pustego jeszcze kursu, klikamy przycisk “Włącz tryb edycji”. W momencie pracy w takim trybie – możemy dla każdej jednostki (tematu bądź tygodnia) dodawać poszczególne składowe. Przy każdej “edytowalnej” części serwisu pojawiają nam się wówczas rozwijane listy i specjalne ikony. Możemy za ich pomocą usuwać, edytować, ukrywać, bądź przenosić dodane elementy, a także definiować sposób wyświetlania jednostek naszego kursu (np. ustawić, żeby użytkownicy widzieli tylko jeden tydzień lub temat po zalogowaniu). Dostępna jest również pomoc kontekstowa (żółte ikony ze znakiem zapytania). W każdej chwili możemy zmienić ustawienia, które definiowaliśmy w momencie zakładania kursu, czy też całej platformy. W tym celu, na głównej stronie serwisu wybieramy odnośnik “Administracja”.
Poza samą zmianą ustawień, można konfigurować tu również “Tematy” czyli takie elementy wyglądu serwisu jak: kolory, czcionki, logo. Można również zarządzać modułami, czyli “składowymi”. Zarządzanie polega na konfigurowaniu bądź usuwaniu modułów. Konfigurować możemy np. takie rzeczy, jak “liczbę sekund po której w przypadku braku reakcji, system uzna, że użytkownik opuścił pokój rozmów”, ewentualnie “maksymalną ilość dyskusji pokazywanych na jednej stronie forum”. Większość składowych ma właśnie tego typu “możliwości konfiguracyjne”.
Możemy tu również tworzyć i edytować użytkowników. Moodle zapewnia zaawansowany sposób uwierzytelniania podczas zakładania kont, o czym jeszcze za chwilę. W ramach poszczególnych kursów możemy także wysyłać zewnętrzne pliki, zapisywać studentów i definiować prowadzących. Pamiętajmy, że zarówno tryb edycji, jak i panele administracyjne, są widoczne jedynie dla administratora i prowadzących.

Zaczniemy więc od przesłania do serwisu kilku plików. Będą to grafiki wykorzystane później w “testach kwalifikacyjnych” podsumowujących zagadnienia poruszane na kursie. Dołączane w ten sposób mogą być zresztą pliki praktycznie dowolnego typu. Zapisane na serwerze można przenosić, edytować i usuwać. Żeby skorzystać z tych opcji, klikamy w odnośnik “Pliki” w menu administracjyjnym. W katalogu moodledata, poza samymi plikami, system będzie również przechowywał kopie zapasowe kursu, jeśli taką kiedykolwiek wykonamy.
Moduł kopii zapasowych dostępny jest w panelu “Administracja”.
Po przesłaniu grafik – przejdźmy teraz do trybu edycji i dodajmy kilka tzw. “składowych”. Jako że dysponujemy trzema tekstami w formacie html, które chcemy wykorzystywać podczas kursu, wybierzemy z rozwijanego menu pozycję “Zasób”. Następnie jako “Typ zasobu” możemy podać “Strona WWW”. Jako nazwę, którą będzie widział student po zalogowaniu wpisujemy: “Dźwięk w Linuksie”. Klikamy teraz “Kontynuuj”. Teksty znajdują się fizycznie na serwerze w katalogu /var/www/art/, więc jako adres strony, podajemy: http://localhost/art/sound.html. Analogicznie dodajemy również pozostałe dwa teksty: “HDPARM – kontrola twardego dysku” i “Linux – obsługa modemów”.
Teraz pora na składową o nazwie “Quiz”. Jest to ciekawy moduł bardzo konfigurowalnych testów. Mamy tu możliwość dodawania pytań “wielokrotnego wyboru”, pytań typu “prawda/fałsz”, “krótkich odpowiedzi”, “opisowych”, “dopasowywania właściwych odpowiedzi”, “pytań wybieranych losowo” i kilku innych. Możemy zdefiniować, czy ilość prób rozwiązania testu ma być limitowana, ile czasu ma on być aktywny, czy kolejne próby mają odbywać się na podstawie poprzednich itd. W przykładowym “teście sprawdzającym” chciałbym umieścić pytania typu “prawda/fałsz”, “wielokrotna odpowiedź”, “krótka odpowiedź” i “dopasuj odpowiedź”. Po wypełnieniu więc głównych pól formularza testu (w razie wątpliwości, przy każdym polu jest ikona pomocy kontekstowej), zostajemy przekierowani na stronę zarządzania bazą danych pytań. Pytania przechowywane są w obrębie zdefiniowanych wcześniej kategorii i mogą być wykorzystane w dowolnej jednostce kursu. Takie “scentralizowane” zarządzanie bazą pytań jest o tyle wygodne, że wystarczy, zmodyfikować jakikolwiek z nich wyłącznie w bazie – alby zmiana ta zadziałała automatycznie we wszystkich innych miejscach, w których aktualnie dane pytanie jest w użyciu.

Poza testem, dodajemy również do kursu składową “Zadanie”, zatytułowane “Praca zaliczeniowa – konfiguracja drukarki sieciowej (CUPS)”. W opisie zadania umieściłem krótką informację: “Opisz na dowolnym przykładzie sposób konfiguracji drukarki za pomocą CUPS”. Przy pomocy formularza wyłączyłem również “zezwolenie na wielokrotne przesyłanie rozwiązania”, a także ustawiłem maksymalny rozmiar przesyłanego pliku na wartość 1 Mb. W tej chwili, do ustalonej w konfiguracji zadania daty – uczestnicy kursu zobowiązani są przesłać wykonany przez siebie opis do oceny. Ponadto dodałem także moduł “Wybór”. Jest to pewnego rodzaju krótka ankieta, zakładająca odpowiedź “tak” lub “nie”, przydatna przy wszelkiego rodzaju głosowaniach, czy zbieraniu opinii na dany temat.
Jeśli chodzi o “Forum dyskusyjne”, to dostępne są różne typy forów, takie jak tylko-dla-nauczycieli, nowości kursu, otwarte dla wszystkich i jeden-wątek na każdego użytkownika.
Do każdego wysłanego postu dołączane jest zdjęcie autora, o ile ten ustawił je w swoim Konfiguracja pozwala również na to – żeby kopia każdego posta była przesyłana do nich pocztą elektroniczną. Prowadzący kurs ma możliwość blokowania wybranych wątków.

Na liście “składowych” znalazł się również “Czat” (pokój rozmów) oraz “Dziennik”. Jeśli chodzi o zastosowanie dzienników w Moodle – to funkcjonują one podobnie jak popularne ostatnimi czasy witryny opartę o technologię Wiki. Najczęściej stosowane przez moodlerów są dzienniki tygodniowe. Dla każdej składowej kursu prowadzący może zaproponować jakiś ciekawy temat, dodatkową, uzupełniającą treść, którą uczestnicy kursu mogą edytować, dopisywać do niej dodatkowe teksty itd. Prowadzący ma również możliwość oceniania wpisów do dziennika. Studenci automatycznie otrzymują komentarz prowadzącego pocztą elektroniczną. Jeśli jesteśmy już przy dziennikach, warto może również dodać, że formularze w Moodle pozwalają na kilka sposobów formatowania wprowadzanego tekstu. Poza oczywiście “czystym tekstem”, mamy do dyspozycji:

1.Autoformatowanie Moodle

Przy tym sposobie formatowania zachowane zostają przeniesienia linii, adresy typu www.onet.pl zostają automatycznie konwertowane na odnośniki. Emotikony wpisywane “z klawiatury” zostaną automatycznie zamienione na charakterystyczne dla Moodle’a “buźki”.

2. Format HTML

Wprowadzany tekst traktowany jest jak kod HTML.

4.Format Wiki

Pozwala na stosowanie specyficznego “formatowania wiki”: **pogrubienie**, //kursywa//, –przekreślenie–, >>wyśrodkowanie<<.

Moodlerzy – studenci, prowadzący, autorzy kursów i administratorzy

Administrator platformy Moodle ma uprawnienia do zakładania i modyfikowania kont systemowych użytkowników. Określa również sposób ich uwierzytelniania, w przypadku kiedy zezwalamy na samodzielną rejestrację za pośrednictwem strony WWW. Domyślną metodą uwierzytelniania jest poczta elektroniczna. Po rejestracji, w procesie której użytkownik podaje swój login, hasło i adres e-mail – wysyłane jest do niego potwierdzenie, w postaci maila ze specjalnym odnośnikiem do strony, na której użytkownik potwierdza rejestrację konta. Są oczywiście w Moodle’u również inne metody uwierzytelniania, takie jak LDAP, czy też zewnętrzna baza danych. Możemy również zupełnie zablokować automatyczną rejetrację kont i w formularzu “opcje uwierzytelniania” (dostępnym w momencie zakładania nowego użytkownika), wybrać metodę “Tylko konta utworzone ręcznie”. Wówczas wszelkie konta w systemie będą musiały być tworzone osobiście przez administratora.

Żeby utworzyć nowe konto, należy jako administrator kliknąć w odnośnik “Użytkownicy” znajdujący się po lewej stronie na głównej stronie serwisu. Przypominam, że odnośnik ten, podobnie jak pozostałe o charakterze “czysto administracyjnym” nie są nawet widoczne dla innych użytkowników Moodle’a.
Proces dodawania moodlerów jest w zasadzie identyczny dla wszystkich, natomiast administrator może “przypisywać” poszczególne osoby do specjalnie uprzywilejowanych grup. Te grupy to: administratorzy, autorzy kursów i prowadzący. Administratorzy mają pęłną kontrolę zarówno nad kursami, użytkownikami, jak również wyglądem i ustawieniami całej platformy. Autorzy kursów mają uprawnienia do tworzenia nowych kursów i nauczania w nich. Najmniej uprawnień mają studenci. W zasadzie mają prawo zapisywać się na kursy (o ile w ustawieniach danego kursu nie zmienił tego prowadzący), wypiywać się z nich, modyfikować swój profil oraz … uczyć się. Odnośnie wymienionego “profilu”, ciekawą funkcją jest również to – że użytkownik może określić swoją strefę czasową, i wówczas każda data podana w Moodle będzie tłumaczona na tą strefę.
Oczywiście sam fakt bycia użytkownikiem Moodle’a, wcale nie oznacza uprawnień do uczestnictwa w każdym założonym kursie. Administratorzy, autorzy kursów i prowadzący mogą ustawić dodatkowy “klucz” w postaci hasła, o który zostaniemy poproszeni przy próbie zalogowania się do danego kursu. Najpewniej też, przy takiej próbie, system poinformuje nas o konieczności posiadania takiego klucza.
Jeśli chodzi o wspominane już wcześniej konto Gościa, to można się na nie zalogować klikając na ekranie logowania przycisk “Zaloguj się jako gość”. Oczywiście administrator może ukryć ten przycisk i uniemożliwić korzystanie z takiej opcji. Użytkownicy korzystający z takiego konta nie mają jednak uprawnień do wysyłania postów ani wykonywania czegokolwiek, co wymagało by zapisu do bazy danych.
Mierzenie aktywności użytkowników Moodle’a i rejestrowanie prac w obrębie systemu, odbywa się za pomocą wygodnych narzędzi raportujących. Możemy wybierając podgląd profilu danej osoby, obejrzeć sobie jej “raport aktywności”. Są to szczegółowe logi, wyświetlane w oknie przeglądarki, wzbogacone o wygenerowane przez PHP-GD wykresy. Pokazują zarejestrowane przez Moodle operacje, jakie wykonywał dany użytkownik po uwierzytelnieniu się w systemie. Logi mogą mieć formę przejrzystego, mniej szczegółowego “zarysu” oraz szczegółowej listy, przedstawiajacej określony okres czasu. Ponadto po każdym zalogowaniu się użytkownika, standardowo widzimy tzw. “ostatnie działania”. Są one pokazywane na głównej stronie kursu, w specjalnej ramce. Pokazują wszystkie zaistaniałe w systemie zdarzenia, które miały miejsce od momentu ostatniego uwierzytelnienia się w serwisie.

Administrator ma oczywiście dostęp do tego typu danych, również z poziomu swojego panelu administracynego. Wybierając opcję “Logi” ma możliwość obejrzenia tych najbardziej bieżących (opcja “Bieżące logi z ostatniej godziny”), bądź obszernirjszego raportu – z podziałem na poszczególne osoby i zadane okresy czasu.
Jak widać System Zarządzania Nauczaniem – Moodle ma sporo możliwości. Jest przykładem oprogramowania napisanego bardzo “elegancko”, z uwzglednieniem wielu ważnych czynników, takich jak funkcjonalnośc, łatwość obsługi, szybkość i konfigurowalność. Jest również systemem, który dynamicznie się rozwija. Po liczbie pracujących w sieci Moodle-serwerów widać wyraźnie, że zainteresowanie dobrej jakości alternatywą dla komercyjnych platform LMS bynajmniej nie maleje.
Na zakończenie, warto może również wspomnieć, że pod koniec 2003 rozpoczęła działalność firma (http://moodle.com), świadcząca usługi związane z komercyjnym wsparciem technicznym dla systemu. Ten fakt jest kolejnym dowodem na to, że Moodle wart jest polecenia.

Snort & ACID – inteligentne węszenie w sieci

Sierpień 10th, 2008 Brak komentarzy »

Rajmund Radziewicz

[Artykuł ukazał się w biuletynie internetowym SKOS ]

Systemy wykrywania włamań (IDS – Intrusion Detection System) to zasadniczo dość nowe narzędzia, służące do badania anomalii, wykrywania nieprawidłowości i dodatkowego zabezpieczania określonych segmentów sieci. Stanowią one swoiste uzupełnienie firewalli, z którymi potrafią współpracować – a które często nie wystarczają do zapobiegania szczególnie wyrafinowanym i dobrze przemyślanym atakom na naszą sieć.

IDS’y jako systemy służące przede wszystkim do monitorowania ruchu TCP/IP (niektóre pozwalają na ingerowanie w ten ruch) potrafią o wiele więcej niż jedynie filtrować pakiety, które wychodzą i przychodzą do naszego komputera. Jako że posiadają one jednocześnie funkcje wyspecjalizowanych snifferów (sniffing – węszyć) i analizują cały ruch sieciowy według bardzo precyzyjnych reguł – pozwalają np. na wykrywanie niesprawnych urządzeń (np. serwera DNS, rutera) lub atakujących nasz serwer wirusów (co może być groźne w przypadku sieci opartych na systemie MS Windows). Są jak komputerowe systemy wczesnego ostrzegania, które pozwalają wykryć nieporządane działania i niebezpieczne narzędzia, zanim jeszcze dotrą do naszego firewalla.

Żeby w pełni zrozumieć zasadę działania systemu IDS, sniffera, czy chociażby firewalla – powinniśmy przypomnieć sobie mechanizm działania protokołów z rodziny TCP/IP odpowiedzialnych za przesyłanie danych w sieci. Jako że o samym TCP/IP powstało wiele opasłych tomów i obszernych dokumentów RFC, pozwole sobie tylko na krótkie wyjaśnienie kilku najistotniejszych kwestii. Zasadniczo TCP/IP jest zbiorem zwartych protokołów, niezależnych od sprzętu czy systemu operacyjnego. To właśnie ten zbiór tworzy dzisiejszy Internet, do którego podłączona jest nasza sieć, czy też serwer.

Podstawą jest protokół IP (Internet Protocol). Odpowiada on za przesyłanie danych i jest protokołem transportowym sieci. Najmniejszą jednostkę danych nazywa się czasami datagramem IP. Zawiera informacje o adresie docelowym i źródłowym przesyłanego datagramu. Zajmuje się dzieleniem tego datagramu na mniejsze kawałki przed wysłaniem, oraz sklejaniem go kiedy dotrze już do komputera docelowego. Zajmuje się także wyborem najdogodniejszej trasy podczas wędrówki przez Internet (trasowanie – routing). IP posiada jednak pewną wadę. Jest protokołem bezpołączeniowym, co oznacza że sam nie ustanawia połączenia i nie sprawdza czy odległa maszyna jest gotowa na odebranie przysłanych jej danych. Nie zapewnia też wykrywania błędów podczas transmisji i ich korekty.

Protokołem który doskonale uzupełnia IP jest TCP (Transmission Control Protocol). Jest to protokół połączeniowy, który sprawdza czy dane zostały dostarczone bezawaryjnie do adresata. Ustanawia też bezpieczne połączenie z tym adresatem i po przesłaniu danych zamyka połączenie. W dużym uproszczeniu TCP przesyła tak długo dane, aż otrzyma potwierdzenie od komputera docelowego że wszystkie dane zostały przez niego odebrane prawidłowo. Każdy segment takich danych (dla IP dane są datagramami, dla TCP segmentami) posiada swoją sumę kontrolną (tzw. CRC) która jest sprawdzana. Precyzując nieco ten mechanizm – odbywa się to na zasadzie tzw “trójetapowego uzgadniania połączenia”. Znajomość mechanizmu tego “uzgadniania” jest bardzo istotna, ponieważ wiele wirusów i eksploitów wykorzystuje go właśnie do tego, żeby przedostać się do naszej sieci i/lub systemu.

W momencie wymiany informacji pomiędzy dwiema maszynami w sieci, połączenie to jest uzgadniane i synchronizowane za pomocą specjalnych bitów, dodawanych do przesyłanych datagramów. TCP hosta inicjującego połączenie nie zaczyna od razu wysyłać faktycznych danych, a wysyła kontrolny datagram z bitem SYN ustawionym na 1. Oznacza to chęć synchronizacji połączenia. Po odebraniu takiego pakietu serwer (o ile określony port, na który klient chce się połączyć nie jest zajęty) przydziela odpowiednie bufory TCP oraz potwierdza odbiór odpowiadając bitem SYN+ACK – czyli zgodą na połączenie. Host po otrzymaniu SYN+ACK odpowiada kolejnym SYN, ustawionym tym razem na 0. To oznacza zakończenie uzgadniania połączenia i rozpoczęcie przesyłania danych. Po zakończeniu przesyłania danych, połącznie zamykane jest również w sposób bezpieczny i kilkuetapowy. Serwer wysyła do klienta datagram z ustawionym bitem FIN (oznaczającym chęć zakończenia połączenia), klient odpowiada FIN+ACK, a na sam koniec serwer potwierdza ostateczne “pożegnanie” wysyłając datagram z ustawionym ACK.

Jest jeszcze specjalna odmiana protokołu, lżejszego od TCP, który również nie jest nastawiony połączeniowo (wysyła pakiety nie pilnując czy dotrą na pewno na miejsce), pozwala natomiast na znacznie szybsze realizacje połączeń. Pilnuje również integralności pakietów w trakcie transportu. Protokół nazywa się UDP (User Datagram Protocol) i wykorzystywany jest np. w usłudze TFTP (Trivial FTP).

TCP/IP opisuje się również często na przykładzie czterowarstwowego modelu. Składa się on z następujących elementów:

- warstwy aplikacji
- warstwy transportowej
- warstwy sieciowej
- warstwy fizycznej

Żeby nie rozwodzić się zbyt technicznie, można zobrazować taki model na bardzo prostym przykładzie. Załóżmy że pobieramy z serwera WWW stronę internetową. Aplikacja nazywająca się “serwer WWW” wysyła w tym przepadku do aplikacji nazywającej się “przeglądarka” po stronie klienta pakiety zawierające daną stronę (tekst, grafikę itd). Pakiety obsługiwane są na poziomie aplikacji przez protokół HTTP. Ten protokół dodaje do takich pakietów własne nagłówki i przekazuje je do warstwy transportowej. W warstwie transportowej pakiety trafiają do protokołu TCP. Otrzymuje on pakiety sklejone z nagłówkami HTTP. Adresuje je dodając do nich numer portu komputera lokalnego, z którego wychodzą i numer portu komputera docelowego. Numery te umieszcza w swoim własnym nagłówku, który również dokleja i przekazuje całość do warstwy sieciowej. W tej warstwie pakiety przejmuje protokół IP. Dodaje on kolejny (własny) nagłówek, w którym umieszcza adres IP komputera źródłowego i docelowego. Tak oklejone paczuszki IP przekazuje do warstwy najniższej – fizycznej. W tej warstwie (najczęściej jest to warstwa ethernetu) dodawany jest kolejny nagłówek zawierający adresy kart sieciowych (MAC) komputera lokalnego i zdalnego. Z tyloma nagłówkami pakiety wędrują następnie przez Internet. Po dotarciu na miejsce, komputer docelowy rozpoznaje po nagłówku warstwy fizycznej że paczki adresowane są akurat do niego. Usuwa taki nagłówek i przekazuje paczki do wyższych warstw. Tam są one kolejno “rozbierane” z poszczególnych nagłówków, aż trafią do warstwy najwyższej (aplikacji), gdzie przekazane zostaną przeglądarce internetowej. Ewentualne komunikaty o błędach w trakcie wedrówek pakietów zgłasza nam jeszcze inny protokół – ICMP (Internet Control Message Protocol). Zajmuje się on zgłaszaniem wszelkich błędów w trakcie wędrówki datagramów przez sieć. Takie błędy to np. wyłączona maszyna docelowa, nieosiągalna sieć, albo wyczerpanie się licznika “czasu życia pakietu” (TTL – Time to Live. Protokoły TCP/IP wymagają aby każdy router przez który przechodzi pakiet zmniejszał wartość pola TTL o 1. Zapobiega to błąkaniu się się wszelkich zagubionych pakietów zbyt długo po Internecie.

Rola systemu IDS polega na śledzieniu ruchu TCP/IP wg określonych reguł, przechwytywaniu wyżej opisanych pakietów i ich analizie. Taka analiza oraz ocena zaistniałej w sieci sytuacji możliwa jest dzięki wykorzystaniu tzw. bazy sygnatur oraz w przypadku niektórych systemów wykrywania włamań – badaniu anomalii na podstawie pobranych wcześniej próbek ruchu sieciowego (stanowiącego następnie punkt odniesienia). Np. specjalny preprocesor snorta – SPADE implementuje właśnie taką funkcjonalność. Baza sygnatur jest zestawem specjalnych regułek, określających jakie działania IDS ma traktować jako niebezpieczne. Przykładowo jeśli pakiety TCP wychodzące z portu 110 (pop3, czyli poczta) zawierają w przenoszonych danych określone ciągi znaków wskazujące na obecność skryptu VBScript (najczęściej wirus w załączniku) – IDS może o tym zaalarmować lub przykładowo wyrzucić taki pakiet z bufora TCP, zanim dotrze do celu. Informuje go o tym specjalna regułka. IDS’y mają więc najczęściej obszerne i często aktualizowane bazy takich regułek (sygnatur).

To chyba tyle w ramach wstępu do zagadnienia jakim jest analiza ruchu sieciowego. Oczywiście bardzo pobieżnego wstępu. Warto może jeszcze nadmienić, że systemy wykrywania włamań (anomalii) dzielą się na:

apnea treatment

- systemy oparte na serwerze – czyli takie które służą do ochrony pojedyńczej maszyny. Analizują logi systemowe, nawiązane aktualnie połączenia sieciowe, często mają także wbudowaną funkcję kontroli integralności plików systemowych

- systemy oparte na sieci (NIDS – Network IDS) – to systemy analizujące całą sieć, potrafiące kontrolować połaczenia pomiędzy różnymi maszynami w tej sieci. Wymagają ustawienia interfejsu sieciowego w tzw. tryb “promiscous” (rozwlekły), pozwalający na przechwytywanie wszystkich pakietów w sieci (nie tylko tych, ktore są skierowane do maszyny na której pracuje NIDS).

SNORT + ACID

Snort, którego symbolem jest węsząca świnka, jest właśnie przykładem jednego z najlepszych i najskuteczniejszych NIDS’ów. Dostępny jest na wiele platform systemowych (w tym również Windows) i udostępniany na zasadach licencji GPL. Potrafi wyszukiwać i dopasowywać do wzorców podejrzane treści w strumieniach pakietów, wykrywać wiele ataków i anomalii, np. takich jak przepełnienia bufora, skanowanie portów, ataki na usługi WWW, FTP, SMB, ataki typu ARP spoofing. Posiada często aktualizowaną bazę sygnatur. Między innymi źródłem regułek dla Snorta jest baza arachNIDS udostępniana publicznie przez firmę Max Vision Network Security. Nasza świnka potrafi również integrować się z systemami baz danych (jak np. z MySQL) – co pozwala na stosowanie bardzo wygodnych dodatków, takich jak chociażby ACID. Wspomniany ACID (Analysis Console for Intrusion Databases) jest specjalnym modułem Snorta tworzącym interfejs WWW do analizy logów umieszczonych w bazie danych. Jest to rozbudowany system raportujący, na który składa się zestaw skryptów PHP, znacznie ułatwiających przeglądanie alarmów, sortowanie i zaawansowane wyszukiwanie wykrytych ataków.

Snort przechwycone przez siebie pakiety przepuszcza przez tzw. preprocesory. To one filtrują strumień TCP/IP szukając na różnych jego warstwach wszelkich nieprawidłowości (wykrywanych na podstawie regułek lub badaniu anomalii na podstawie pobranych próbek ruchu sieciowego). Do standardowo aktywnych zaraz po instalacji preprocesorów należą:

  • http_decode – który przetwarza adresy HTTP i konwertuje na ASCII znaki zakodowane szesnastkowo. Zapobiega to ukrywaniu pewnych danych, które zakodowane mogłby być przekazane za pomocą zapytania do serwera WWW.
  • portscan – wykrywa skanowania portów, w tym skanowania typu NULL, FIN, SYN+FIN
  • frag2 – skleja i buforuje zdefragmentowane pakiety. Często analiza pojedyńczych datagramów nie wykazuje żadnych niebezpieczeństw. Dane wędrują sobie pofragmentowane do portu jednego z komputerów w naszej sieci. Po dotarciu do tego komputera i złożeniu ich przez aplikację – okazuje się że może to być np. niebezpieczny eksploit albo wirus
  • stream4 – bardzo rozbudowany preprocesor służący do śledzenia połączeń, odtwarzania i szczegółówej analizy strumieni TCP. Wykrywa niektóre wysublimowane skanowania portów, testuje sumy kontrolne i poprawność pojedyńczych datagramów.
  • rpc_decode – wykrywa próby podejrzanych odwołań do usługi RPC (zapewnianej przez portmappera).

Po przepuszczeniu pakietów przez preprocesory oraz ich analizie na podstawie sygnatur, Snort zarejestrowane zdarzenia zapisuje do plików dziennika. Potrafi stosować zresztą różne odmienne formy tego zapisu: rejestrowanie w binarnym formacie tcpdump, rejestrowanie w pełnej, opisowej postaci, wysyłanie komunikatu na gniazdo uniksowe (np. w celu dalszej obróbki przez inną aplikację), zapisywanie do bazy danych itd.

Możemy też zdefiniować własne regułki – na podstawie których Snort będzie np. resetował lub blokował podejrzane połączenia. Zajmiemy się tym zaraz po instalacji i konfiguracji samego NIDS’a i dodatkowego modułu raportującego ACID.

Rysunek 1. Składowe systemu NIDS.

INSTALACJA I KONFIGURACJA

Zaczynamy od instalacji odpowiednich pakietów. To czego potrzebujemy to Snort z domyślnym wsparciem dla MySQL’a oraz ACID:

apt-get install snort-mysql acidlab-mysql

Po pobraniu pakietów przeprowadzona zostanie wstępna konfiguracja. W przypadku paczki acidlab-mysql zostaniemy m.in zapytani o serwer WWW z jakiego chcemy korzystać (zasadniczo wystarczy zostawić domyślne “Apache”), o nazwę bazy w której przechowywane będą logi (snort_log), nazwę hosta, nazwę i hasło użytkownika, nazwę bazy przeznaczoną na archiwa (snort_archive). W przypadku snort-mysql zostaniemy zapytani o konfigurację tzw. sensora (czyli interfejsu sieciowego na którym nasłuchiwać ma NIDS. Domyślnie jest to eth0). Następnie wpisujemy adres sieci jaką Snort ma monitorować. Jeśli komputer ze Snortem wpięty jest np. do switcha rozdzielającego kilka podsieci – możemy oczywiście wpisać tu kilka adresów rozdzielonych przecinkiem. Rzecz w tym, że przez komputer z systemem wykrywania włamań pakiety adresowane do danej sieci muszą przechodzić. Nowsze switche mają specjalny port zarządzalny, na który przełączany jest cały ruch z pozostałych portów. Do niego właśnie należy wpinać komputer z NIDS’em. Jeśli mamy np. tylko jeden komputer który chcemy monitorować – wystarczy zamiast adresu sieci wpisać adres IP tego komputera.

Rysunek 2. Konfiguracja poinstalacyjna pakietu ACID.

Po wykonaniu całej wstępnej konfiguracji, musimy utworzyć dwie bazy danych: snort_log i snort_archive na archiwa alarmów. W tym celu uruchamiamy serwer MySQL:

# cd /etc/init.d ; ./mysql start

Następnie:

# mysql -u mysql -p
Enter password:
mysql> create database snort_log;
Query OK, 1 row affected (0.01 sec)
mysql> create database snort_archive;
Query OK, 1 row affected (0.01 sec)
mysql> quit

Po utworzeniu naszych baz należy wygenerować dla nich odpowiednie tabele. Tym razem nie musimy robić tego ‘ręcznie’, ponieważ z pakietami snort-mysql i acidlab-mysql mamy dostarczone odpowiednie pliki *.sql. Wystarczy się nimi posłużyć. Najpierw tworzymy tabele wymagane przez ACID’a:

# mysql -u root -p snort_log < /usr/share/acidlab/create_acid_tbls_mysql.sql
# mysql -u root -p snort_archive < /usr/share/acidlab/create_acid_tbls_mysql.sq

Teraz tabele Snorta (jako że są spakowane, najszybciej będzię kiedy posłużymy się zcatem):

# zcat /usr/share/doc/snort-mysql/contrib/create_mysql.gz |mysql -u root -p snort_log
# zcat /usr/share/doc/snort-mysql/contrib/create_mysql.gz |mysql -u root -p snort_archive

Po tej operacji powinniśmy jeszcze dokonać małej zmiany w głównym pliku konfiguracyjnym Snorta. Jeśli skonfigurowaliśmy system tak, żeby nasłuchiwał tylko na jednym interfejsie (jeden aktywny sensor), będzie to plik /etc/snort/snort.conf. Gdyby sensorów było więcej – pliki będą się kolejno nazywały: snort.eth0.conf, snort.eth1.conf itd.

Najważniejsze opcje jakie musimy ustawić w tym pliku – to definicja dwóch zmiennych: $HOME_NET oraz $EXTERNAL_NET. HOME_NET oznacza naszą sieć domową (jeśli mamy tylko jeden komputer, wpiszemy tam IP tego komputera). EXTERNAL_NET to cała strefa zewnętrzna, z której wszelki ruch sieciowy będzie wnikliwie analizowany. Przykładowy wpis może więc wyglądać następująco:

var HOME_NET 192.168.0.0/24
var EXTERNAL_NET !$HOME_NET

Wpis 192.168.0.0/24″ przy HOME_NET oznacza sieć o adresie 192.168.0.0 z maską podsieci klasy C. Jest to specjalna notacja oznaczania adresów – CIDR (Classes Internet Domain Routing) domyślnie używana przez Snorta. Dzieje się tak dlatego – że NIDS nie może beztrosko zakładać, że wszystkie adresy w sieci używają standardowych masek podsieci.

Poniżej mamy wpis równoważny mniej więcej temu – że wszystko co nie jest naszą siecią domową traktowane będzie jak sieć zewnętrzna, z której potencjalnie może nastąpić jakiś atak. Zamiast takiego wpisu moglibyśmy wstawić tam jakiś konkretny adres, czy też zestaw adresów. W /etc/snort/snort.conf znajdziemy również kilka innych, opcjonalnych zmiennych jak np.

var DNS_SERVERS $HOME_NET
var SMTP_SERVERS $HOME_NET
var HTTP_SERVERS $HOME_NET
var SQL_SERVERS $HOME_NET

Domyślnie oznaczają one, że wszelkie serwery DNS, poczty, czy też baz danych w naszej sieci – obejmuje zmienna HOME_NET. Gdyby się jednak okazało, że np. nasz lokalny serwer DNS jest w zupełnie innej podsieci, a z wiadomych przyczyn będzie następował nasilony ruch pomiędzy tym serwerem a komputerami w naszej sieci domowej (oznaczonymi przez zmienną HOME_NET) – to warto poinformować o tym Snorta wpisując:

var DNS_SERVERS [tu adres IP serwera DNS]

W innym przypadku nasz NIDS mógłby taki wzmożony ruch uznać za podejrzany i niepotrzebnie o tym alarmować.

Po ustawieniu tych zmiennych możemy uruchomić Snorta poleceniem:

cd /etc/init.d ; ./snort start

Musimy pamiętać, że jeśli chcemy korzystać z dodatkowego modułu raportującego ACID, w tle musi pracować cały czas serwer WWW Apache i serwer baz danych MySQL.

Po wystartowaniu Snorta za pomocą skryptu znajdującego się w /etc/init.d uruchomi się on w trybie NIDS, czyli jako sieciowy system wykrywania anomalii. Można go natomiast uruchomić również w dwóch innych trybach – jako sniffer i tzw. “packet logger”. W trybie sniffer przechwytuje na bieżąco wszystkie pakiety i wyświetla ich zawartość na ekranie (działa jak typowy sniffer). Żeby uczynić z naszego Snorta zwykłego sniffera, wystarczy polecenie:

snort -vd

Opcja “-v” powoduje że Snort będzie wyświetlał informacje o nagłówkach TCP/IP/UDP/ICMP, opcja “-d” wymusza wyświetlanie również zawartości tzw. payloadu (czyli właściwych danych przeznaczonych dla warstwy aplikacji).

Fragment przykładowej sesji Snorta uruchomionego w trybie “sniffer”:

------------------------------------------------------------------------
root@Linux-EduCD:~# snort -vd
Running in packet dump mode
Log directory = /var/log/snort

Initializing Network Interface eth0

        --== Initializing Snort ==--
Initializing Output Plugins!
Decoding Ethernet on interface eth0

        --== Initialization Complete ==--

-*> Snort! <*-
Version 2.2.0 (Build 30)
By Martin Roesch (roesch@sourcefire.com, www.snort.org)
01/10-17:49:29.857678 80.53.200.14:2446 -> 213.46.243.88:53
UDP TTL:64 TOS:0x0 ID:12530 IpLen:20 DgmLen:60 DF
Len: 32
41 C7 01 00 00 01 00 00 00 00 00 00 03 77 77 77  A............www
07 73 69 6D 70 2D 73 74 02 70 6C 00 00 01 00 01  .simp-st.pl.....

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

01/10-17:49:30.053323 213.46.243.88:53 -> 80.53.200.14:2446
UDP TTL:239 TOS:0x0 ID:58362 IpLen:20 DgmLen:165 DF
Len: 137
41 C7 81 80 00 01 00 01 00 03 00 00 03 77 77 77  A............www
07 73 69 6D 70 2D 73 74 02 70 6C 00 00 01 00 01  .simp-st.pl.....
C0 0C 00 01 00 01 00 00 1C 20 00 04 D9 1C 92 9E  ......... ......
C0 10 00 02 00 01 00 00 1C 20 00 10 05 69 6E 64  ......... ...ind
--------------------------------------------------------------------------

Jeśli chcemy uruchomić Snorta w trybie “packet logger” wykonujemy polecenie:

snort -b -l katalog

Opcja “-b” oznacza że aplikacja będzie zrzucać logi w binarnym formacie tcpdump, natomiast “-l” powoduje że logi te zapisywane będą w określonym katalogu. Przed uruchomieniem w ten sposób Snorta wspomniany katalog należy utworzyć. Zapisane w takim formacie logi można następnie poddawać dodatkowej obróbce za pomocą aplikacji Ethereal (który również obsługuje format tcpdumpa).

Oczywiście właściwym i najbardziej rozbudowanym trybem jest NIDS i takim też będziemy się dalej posługiwać. Jeśli mamy działającego i uruchomionego Snorta, MySQL’a i Apache’a – wchodzimy na adres:

http://localhost/acidlab

Zobaczymy interfejs ACID’a, pokazujący nam liczbę sensorów, wskaźniki zarejestrowanych alarmów oraz kilka innych opcji. Możemy przeglądać wszystkie dzienniki Snorta, mamy też łatwy dostęp do baz sygnatur, wyszukiwarki itp.

Żeby przetestować możliwości naszego świeżo upieczonego systemu wykrywania anomalii, spróbujmy z maszyny znajdującej się poza zdefiniowanym HOME_NET przeskanować porty komputera, na którym uruchomiliśmy NIDS’a. Możemy posłużyć się bardzo funkcjonalnym programem do testowania otwartych portów, wykrywania zdalnego systemu operacyjnego – nmapem. Założmy że chroniony serwer to 213.50.120.72. Wykonujemy standardowe skanowanie, polegające na tym, że nmap wysyła na nasz serwer pakiety TCP z ustawioną flagą SYN, testując w ten sposób otwarte porty (bit SYN, jak już wspominane było na początku artykułu oznacza chęć połączenia na określony port):

nmap -sS 213.50.120.72

Po sprawdzeniu w powyższy sposób maszyny ze Snortem, możemy odświeżyć uruchomionego w przeglądarce ACID’a i sprawdzić czy zarejestrował on jakieś podejrzane działania. Okazuje się że nie tylko wykrył skanowanie systemu – ale zidentyfikował je jako “ICMP PING NMAP”. Pokazuje również dodatkowe informacje, m.in adres komputera z którego wyszło skanowanie i dokładny czas incydentu. Nawet jeśli spróbujemy użyć specjalnych flag “-sF”, w celu częsciowego ukrycia połączeń na określone porty – Snort i tak bezbłędnie je wykrywa.

Spróbujmy teraz np. zasymulować działanie robaka CodeRed i wyszukajmy poprzez serwer WWW pliku “scripts/root.exe”. Wpisujemy więc na zewnętrznej maszynie:

http://213.50.120.72/scripts/root.exe

W odpowiedzi dostajemy odpowiednie alarmy:

56:22.426969 [**] [1:1256:2] WEB-IIS CodeRed v2 root.exe access [**]

[Classification: Web Application Attack][Priority: 1]

Rysunek 3. Interfejs modułu raportującego.

Oczywiście jako że nasza maszyna pracuje pod kontrolą Linuksa – regułkę dotyczącą CodeRed można usunąć z arsenału Snorta (o tym jak to zrobić za chwilę), no chyba że w naszej sieci znajdują się jakieś maszyny z systemem podatnym na takie ataki.

Podobnie bezbłędnie reaguje nasz NIDS na dyskretne, rozproszone w czasie skanowanie portów pojedyńczymi pakietami FIN, czy np. próby ataków na skrypty PHP, polegające na wykorzystaniu przesyłania danych za pomocą metody “get”. Jeśli nie sprawdza się wówczas danych wejściowych – można pod taka zmienną podczepić np. własny skrypt. Na podobne błędy narażone są skrypty zawierające funkcję include(), w których nie sprawdza się parametrów. Wpisanie więc w przeglądarce:

http://213.50.120.72/skrypt.php?file=../../../etc/passwd

również spowoduje wygenerowanie alarmu.

REGUŁKI SNORTA – TWORZENIE SYSTEMU PREWENCYJNEGO

Póki co Snort sprawdza się doskonale jako system monitorujący naszą sieć. Pliki z poszczególnymi regułkami, które wykorzystuje, znajdują się w katalogu /etc/snort/rules. Wszystkie mają rozszerzenie *.rules, natomiast w pliku konfiguracyjnym /etc/snort/snort.conf znajduje się sekcja określająca jakie pliki będą przez NIDS’a używane. Fragment tej sekcji może wyglądać jak poniżej:

include $RULE_PATH/local.rules
include $RULE_PATH/bad-traffic.rules
include $RULE_PATH/exploit.rules
include $RULE_PATH/scan.rules

Jeśli przykładowo nie jesteśmy zainteresowani określoną regułką – wystarczy wykomentować linię z jej nazwą z tego właśnie pliku. Reguły identyfikujące poszczególne ataki określają kilka sposobów reagowania na zaistniałe zdarzenie. Może to być przepuszczenia pakietu (pass), zarejestrowanie incydentu (log), czy ogłoszenie alarmu (alert). Jeśli mamy wkompilowaną obsługę tzw. flexresp (“fexible response” zapewniane jest przez bibliotekę libnet i pozwala na ingerencję w strumień TCP/IP) – możemy także używać bardziej wyrafinowanych parametrów: resp i react. Pozwalają one aktywniej reagować na atak. Za pomocą opcji resp można doprowadzić do zerwania podejrzanego połączenia, natomiast opcja react służy do blokowania dostępu do określonych usług (np. WWW). Pakiet snort-mysql instalowany z repozytoriów Debiana posiada już wkompilowaną obsługę flexresp.

Przykładowa regułka którą możemy np. dopisać do /etc/snort/rules/local.rules mogłaby wyglądać następująco:

log tcp $EXTERNAL_NET any -> $HOME_NET 110 \
("msg: Próba połączenia z pop3";)

Oznacza to, że wszelkie próby połączeń TCP przychodzące z sieci zewnętrznej (jednokierunkowy operator “->”), z dowolnego portu (any) do sieci zdefiniowanej przez zmienną HOME_NET na port 110, mają być zarejetrowane w logach z komunikatem “Próba połączenia z pop3″. Język sygnatur umożliwia również zadeklarowanie reguły, która określa pakiety poruszające się w obie strony, za pomocą dwukierunowego operatora: “<>” zamiast “->”.

Bardziej aktywne reguły można definiować za pomocą wspomnianych opcji “resp” i “react”. Np:

alert tcp any any -> $HOME_NET 80 \
(msg: "Uwaga! Próba połączenia z serwerem WWW"; resp: rst_all;)

spowoduje, że dowolne połączenia TCP z dowolnego portu na port 80 jakiegoś komputera w naszej sieci będą zapisywane do logów w postaci alarmu “Uwaga! Próba połączenia z serwerem WWW” oraz przerywane za pomocą “rst_all” (nadawca otrzyma pakiet z TCP z ustawioną flagą RST, która przerwie połączenie). W wyniku działania powyższej regułki nikt spoza sieci HOME_NET nie zobaczy naszego serwisu WWW.

Można również filtrować pakiety po ich zawartości (opcja “content”), np.

alert  tcp any any -> $HOME_NET any \
(msg: "Ktoś próbuje odpalić shellkod!";
content:"|90 90 90 e8 c0 ff ff ff|/bin/sh";
resp: icmp_all)

Jak można wywnioskować z bardzo prostej składni – wszelkie pakiety z dowolnego portu skierowane do naszej sieci na dowolny port docelowy, zawierające podejrzany fragment kodu (w tym wypadku może być to shellkod próbujący wykonać przepełnienie stosu), zostaną “poczęstowane” informacją że zarówno sieć, port jak i host są nieosiągalne (opcja icmp_all). Inne przydatne opcje “active response” to:

rst_snd – wysłanie pakietu TCP RST do nadawcy
rst_rcv – wysłanie pakietu TCP RST do odbiorcy
icmp_net – wysłanie pkaietu ICMP_NET_UNREACH do nadawcy
icmp_host – wysłanie pakietu ICMP_HOST_UNREACH do nadawcy
icmp_port – wysłanie pakietu ICMP_PORT_UNREACH do nadawcy

Opcje icmp_all i rst_all są sumą wszystkich powyższych.

Wszelkie logi zaistaniałych zdarzeń widoczne w postaci estetycznych tabelek ACID’a, możemy również przeglądać zaglądając bezpośrednio do dzienników Snorta. Spis wszystkich alarmów znajduje się w pliku /var/log/snort/alert. Pliki /var/log/snort/*log* zawierają dzienniki w binarnym formacie programu tcpdump. Spróbujmy przenalizować jeden z alarmów znajdujący się w pliku alert:

[**] [1:469:3] ICMP PING NMAP [**]
[Classification: Attempted Information Leak] [Priority: 2]
01/10-14:55:34.714891 217.28.146.158 -> 80.53.200.14
ICMP TTL:40 TOS:0x0 ID:57742 IpLen:20 DgmLen:28
Type:8  Code:0  ID:63871   Seq:55619  ECHO
[Xref => http://www.whitehats.com/info/IDS162]

Pierwsza linia to:

[**] [1:469:3] ICMP PING NMAP [**]

Na samym jej początku mamy trzy liczby oddzielone od siebie dwukropkiem. Liczba “1″ to tzw. identyfikator generatora. Jedynka w tym wypadku oznacza samego Snorta (mogą być również poszczególne podsystemy NIDS’a i wówczas wartość ta będzie inna). Liczba 469 to identyfikator konkretnej sygnatury o nazwie “ICMP PING NMAP” występującej w jednej z baz sygnatur.

Kolejna linia to:

[Classification: Attempted Information Leak] [Priority: 2]

Mówi nam ona, że alarm jest zaklasyfikowany do szerszej kategorii o priorytecie 2 (im niższa znajdzie się tutaj wartość, tym poważniejszy wydarzył się incydent).

Następnie:

01/10-14:55:34.714891 217.28.146.158 -> 80.53.200.14

Ten wpis mówi o dokładnej dacie zarejestrowanego połączenia i podaje adresy źródłowy i docelowy datagramów TCP.

No i ostatnia linijka:

[Xref => http://www.whitehats.com/info/IDS162]

oznacza łącze do bazy sygnatur Snorta. W tym wypadku jest to baza znajdująca się na www.whitehats.com. W przypadku jakiegoś innego zdarzenia mogłaby pojawić się tu równie dobrze baza arachnids.

PODSUMOWANIE – CZYLI STUDIUM DROBNEGO OSZUSTWA

Pamiętajmy o tym że żaden, nawet najlepiej zaprojektowany system NIDS nie zastąpi administratora. To on ostatecznie decyduje, które ze zgłoszonych alarmów są rzeczywiście poważne – a które wynikają z pewnych nieścisłości konfiguracyjnych lub sposobu działania określonych aplikacji sieciowych. Pamiętajmy również że NIDS nie będzie nigdy nieomylny. Jeśli ktoś bardzo się postara może “obejść” pewne jego mechanizmy. Nie należy więc zbyt restrykcyjnie i dosłownie podchodzić do wszystkich zgłaszanych alarmów. Dla przykładu wyobraźmy sobie pewną sytuację, w której ktoś skanuje porty naszego serwera. Snort komunikuje nas o tym – podając również adres komputera, z którego następiło skanowanie. Jak wiemy, adres źródłowy i docelowy wszystkich przesyłanych w sieci pakietów zapisany jest w nagłówku IP. Wystarczy teraz że ów ktoś (np. za pomocą nmapa) sfałszuje adres źródłowy w nagłówku i wyśle pakiety TCP, np. z ustawionym bitem FIN na kilka portów naszego komputera:

nmap -S 83.238.29.145 -e eth0 -P0 -sF -v ip_naszego_komputera

Po tej operacji Snort zakomunikuje – że ktoś z adresu 83.238.29.145 (w tym przypadku jest to www.knoppix.pl) skanował nam porty ;-) Czy pomyłka NIDS’a oznacza że coś z nim jest nie tak? Raczej nie. Nasz system nie sniffuje przecież wszystkich połączeń w Internecie. Jeśli paczka ze sfałszowanym adresem wyszła z komputera “ciekawskiego” i dotarła przez sieć do naszego serwera – system wykrywania anomalii nie może przecież prześledzić całej jej trasy. Tego typu drobiazgi należy mieć po prostu na uwadze kiedy analizujemy logi naszej “inteligentnej świnii”.

Na zakończenie warto jeszcze dodać że Snort jest narzędziem, które zasadniczo nie odbiega od swoich komercyjnych i bardzo drogich odpowiedników. Obecnie wiele firm – jak np. SourceFire założona przez twórcę opisywanego systemu, Martina Roescha – zajmuje się świadczeniem komercyjnych usług zwiazanych ze Snortem oraz sprzedażą specjalistycznych urządzeń (sprzętowych NIDS’ów), stanowiących rozbudowane sensory oparte o Snorta, podłączane w różnych punktach sieci. Powstaje cała masa aplikacji zwiększająca jego funkcjonalność. Przykładowo pakiet Snortsam łączący Snorta z Checkpoint Firewall-1 lub Cisco Pix. Wystarczy zajrzeć zresztą na http://www.sourceforge.net i wpisać w wyszukiwarce “snort” – żeby przekonać się ile dodatkowych narzędzi, modułów i rozszerzeń powstaje dla tego popularnego NIDS’a. Prawdziwą jego “siłę przebicia” stanowi przede wszystkim otwarta architektura i duża liczba developerów skupiona wokół projektu. To że wspierany jest on dodatkowo przez wyspecjalizowane firmy zajmujące się bezpieczeństwem – należy chyba uznać za duży plus.

Zaawansowane wyszukiwanie plików

Sierpień 10th, 2008 Brak komentarzy »

Możliwość zaawansowanego wyszukiwanie plików w systemie (za pomocą wyrażeń regularnych, reguł, czy po określonych atrybutach) dostarcza narzędzie find. Dla przykładu wyszukanie plików w katalogu /root zaczynających się od słówka linux:

find /root/ -name “linux*”

Aby wyświetlić listę wszystkich plików w systemie, których nazwa zaczyna się od słowa “linux”, po którym występują dokładnie 3 dowolne znaki:

find / -name “linux???”

Aby wyświetlić wszystkie pliki w katalogu /usr większe niż 10MB:

find /usr -size +10000k

Aby wyszukać wszystkie puste pliki znajdujące się np. w katalogu domowym:

find ~ -empty

Wyszukanie plików w katalogu domowym, które były odczytywane w ciągu ostatniej godziny:

find ~ -amin 60

Wyszukaj wszystkie pliki w /etc które były odczytywane 3 dni temu:

find /etc -daystart -atime 3

Wyszukaj pliki w katalogu /tmp należące do użytkownika rajmund:

find /tmp  -user rajmund