plik

PRAKTYKA

HAKIN9 1/2010

Z ARTYKUŁU

DOWIESZ SIĘ

co to jest system wsparcia

reagowania na incydenty

bezpieczeństwa,

co ma do zaoferowania RTIR,

jak efektywnie używać RTIR.

CO POWINIENEŚ

WIEDZIEĆ

znać podstawy administracji

systemów UNIX,

posiadać działające serwery

MySQL, Apache, Sendmail,

mieć zainstalowany Perl.

a wstępie warto zdać sobie sprawę,
co to jest incydent w kontekście
bezpieczeństwa informatycznego. Otóż

jest to każda bezprawna lub nieautoryzowana
akcja dokonana przy użyciu komputera lub sieci
komputerowej. Jako przykłady z jednej strony
podać tutaj można skanowanie portów czy ataki
DoS, a z drugiej malwersacje, kradzieże poufnych
danych, czy pornografię dziecięcą. Jasne
jest, że zdarzenia takie są w praktyce nie do
uniknięcia, a odpowiednia reakcja na nie powinna
minimalizować ich skutki i pociągać sprawców
do odpowiedzialności.

W idealnej sytuacji, za obsługę incydentów

bezpieczeństwa w każdym przedsiębiorstwie
czy organizacji odpowiadać powinien
specjalnie wydzielony zespół CERT/CSIRT
(ang. Computer Emergency Response
Team/Computer Security Incident Response
Team). Ponadto, odpowiedzialność za obsługę
każdego incydentu powinna być jednoznacznie
przypisana do konkretnych członków zespołu.
Niestety, w praktyce taka sytuacja, szczególnie
w małych firmach, rzadko ma miejsce. Obsługą
incydentów bezpieczeństwa często zajmują się
administratorzy systemu, lub tzw. przypadkowe
osoby, które niekiedy przeciążone obowiązkami,
nie są w stanie wykonywać tej funkcji rzetelnie
i co najważniejsze efektywnie (co zwykle
oznacza po prostu szybko). Nie trzeba chyba
nikomu uświadamiać, że obsługa incydentów
jest krytyczna nie tylko z punktu widzenia

MARCIN TEODORCZYK

bezpieczeństwa, ale również, a może przede
wszystkim, jeśli chodzi o zachowanie dobrej
reputacji. W sytuacji takiej niektóre firmy decydują
się nawet na zlecenie, tak ważnych przecież
zadań, podwykonawcom zewnętrznym.

A przecież reakcja na incydenty

bezpieczeństwa na styku zgłaszający –
obsługujący może zostać znacznie usprawniona
z wykorzystaniem systemów wsparcia takich jak
RTIR (ang. Request Tracker for Incident Response).

Systemy wsparcia reagowania

na incydenty

Reakcja na incydent jest procesem złożonym.
Typowo łańcuch zdarzeń przebiega następująco.
Pierwszym etapem jest przygotowanie
do obsługi incydentów – wyznaczenie
pracowników, zainstalowanie i skonfigurowanie
oprogramowania, przeprowadzenie szkoleń itp.
Kolejnym etapem jest wykrywanie incydentów,
które najczęściej sprowadza się do przyjmowania
zgłoszeń użytkowników. Następnie, po
szybkiej, wstępnej odpowiedzi na zgłoszenie,
podejmowane jest dochodzenie. Dochodzenie
to działania mające na celu zminimalizowanie
skutków incydentu i wyjaśnienie jego przyczyn
(ewentualnie pociągnięcie jego sprawców do
odpowiedzialności). Działanie takie zakończone
powinno być raportem, przeznaczonym także dla
przełożonych. Na każdym etapie tego procesu
spotyka się trudności. W niniejszym artykule
skupimy się na problemie skoordynowania

Stopień trudności

RTIR – nie

trać czasu na

papierkową robotę

Wiadomo, że zdarzenia związane z naruszaniem

bezpieczeństwa są nie do uniknięcia. Czy nie warto

przygotować się do efektywnej ich obsługi? Nieocenionym

narzędziem jest tutaj system wsparcia reagowania na

incydenty.

RTIR

HAKIN9

1/2010

działań wielu osób, będących na różnych
szczeblach decyzyjnych, a często nawet
pracujących w różnych firmach. Poza tym,
bardzo często pojawia się też potrzeba
komunikacji z organizacjami publicznymi, w
tym organami ścigania.

I tutaj, członkom zespołów CERT/

CSIRT z pomocą przychodzą systemy
wsparcia reagowania na incydenty,
takie jak RTIR. Mają one zastosowanie
na prawie każdym etapie procesu
obsługi incydentów, a służą głównie do
usprawnienia komunikacji i umożliwienia
rozliczania pracowników. Podstawowymi ich
funkcjami są organizacja i automatyzacja
wymiany informacji. Wstępne odpowiedzi
na zgłoszenia mogą być generowane
automatycznie, zachowywana jest cała
historia korespondencji (w dodatku w
postaci nieedytowalnej), kopie wybranych
wiadomości mogą być przekazywane
przez system np. zarządowi. Incydentom
mogą być nadawane priorytety, a
użytkownikom określone prawa dostępu. W
praktyce, systemy wsparcia reagowania na
incydenty zwykle opierają się na biletach
(ang. tickets) i poczcie elektronicznej, a
często udostępniają także interfejs WWW.

RTIR

RTIR jest jednym z przykładowych
rozwiązań tego typu. System rozwijany od

2003 roku przez firmę Best Practical (http:
//bestpractical.com/), technicznie jest
wtyczką (ang. plugin) do bardziej ogólnego
w zastosowaniu (i starszego) systemu RT
(ang. Request Tracker). RTIR stworzony
został na potrzeby zespołu JANET-CERT
i wraz z kodem źródłowym (ang. open
source) udostępniony na licencji GNU GPL
2.0. (podobnie jak RT). Aktualnie dostępna
jest wersja 3.8. Typowo, RTIR opiera się
o komunikację z wykorzystaniem poczty
elektronicznej, interfejs WWW i bilety (ang.
tickets).

System zorganizowany jest wokół

incydentów. Każdy incydent może mieć
przyporządkowanych wiele raportów,
dochodzeń, blokad i właścicieli. Raport to
każda wiadomość (zgłoszenie incydentu,
odpowiedź, komentarz itp.). Dochodzenie
to działania mające na celu zgromadzenie
dowodów oraz określenie przyczyn i
sprawców incydentu. Blokada to wyłączenie
określonych usług (np. zablokowanie
określonego portu lub hosta o określonym
adresie IP przez zaporę ogniową).
Właściciel to osoba odpowiedzialna za
dochodzenie i raport końcowy. Właściciele
(użytkownicy) mogą być organizowani w
grupy.

Oprócz podstawowej funkcjonalności

(organizacja incydentów i przekazywanie
wiadomości), za wykorzystaniem RTIR

przemawia wiele innych cech. Jedną z
nich jest internacjonalizacja. Dostępne
są 22 wersje językowe, w tym język
polski (choć tłumaczenie interfejsu jest
niedokończone). Możliwe jest także
przyporządkowanie domyślnego języka
interfejsu i strefy czasowej użytkownikowi).
Przez cały czas działania zachowywane
są nieedytowalne logi. Dostępne jest
wsparcie dla szyfrowania PGP (ang. Pretty
Good Privacy). Możliwe jest wykonywanie
akcji zbiorowych (np. wysyłanie odpowiedzi
do grupy użytkowników), a nawet tworzenie
prostych skryptów, działających na
zasadzie warunek – akcja – szablon.
Dużym plusem jest też rzetelnie wykonany
interfejs WWW, użyteczny w szerokiej
gamie przeglądarek internetowych (także
tekstowych).

Nie bez znaczenia są także

wymagania RTIR. System ten być
uruchomiony tylko pod kontrolą systemów
operacyjnych rodziny UNIX (Unix, Linux,
BSD, MacOS X, Solaris). Wymagana jest
baza danych, którą może być MySQL,
PostgreSQL, Oracle lub SQLite. Oprócz
tego potrzebny jest serwer WWW. Można
tutaj użyć Apache z mod_perl lub FastCGI,
lighthttpd z FastCGI lub dowolnego innego
serwera WWW opartego o perl.

Instalacja i konfiguracja

Czas na nieco praktyki. W dalszej części
artykułu opisano proces instalacji
i konfiguracji RTIR w wersji 3.8.4 w
następującym środowisku: Linux 2.6.30
(dystrybucja Archlinux), Apache 2.2 z
mod_perl 2.0, MySQL 5.1 i Perl 5.10.

Generalnie, system RTIR składa się

z trzech elementów (przy czym ostatni
jest dla nas opcjonalny): RT, wtyczki RTIR
i wtyczki RTFM. Kody źródłowe dostępne
są do pobrania odpowiednio na stronach:
http://bestpractical.com/rt/download.html,

Rysunek 1.

System RT w akcji

Rysunek 2.

Strona logowania do

systemu RT

PRAKTYKA

HAKIN9 1/2010

RTIR

HAKIN9

1/2010

http://bestpractical.com/rtir/download.html
i http://bestpractical.com/rtfm/
download.html.

RT, czyli baza

Na początek zajmiemy się instalacją
RT. Po pobraniu i rozpakowaniu kodu
źródłowego oraz zmianie katalogu
bieżącego na ten, w którym znajdują
się źródła, standardowo wykonujemy
polecenie

./configure

. Jak zwykle,

przekazując mu odpowiednie parametry
możemy dostosować instalację
do naszych potrzeb. W niniejszym
opracowaniu wszystkie wartości

pozostawione zostały jako domyślne. W
takim przypadku katalogiem instalacji jest
/opt/rt3/, bazą danych MySQL, serwerem
WWW Apache z

mod _ perl2

, a

systemową grupą użytkowników w obrębie
jakiej działać będzie RT jest rt.

Następnym krokiem jest sprawdzenie,

czy w naszym środowisku spełnione są
wszystkie wymagane zależności. Służy to
tego polecenie:

make testdeps

. Fragment

przykładowego wyniku jego działania
przedstawia Listing 1.

Większość wymaganych zależności

związana jest z modułami perla. Na
szczęście, dystrybucja RT udostępnia

narzędzie, które pozwala automatycznie
doinstalować wymagane moduły.
Skorzystać z niego można wywołując

make fixdeps

. Należy pamiętać, aby

polecenie to wykonać z uprawnieniami
użytkownika root. Brakujące moduły
perla można także doinstalować ręcznie,
wykorzystując powłokę

perl -MCPAN -e

shell

i polecenie

install

(np.

install

Net::Server

). Przed przystąpieniem do

następnego kroku, należy się ponownie
upewnić, czy wszystkie zależności
są spełnione oraz utworzyć grupę
użytkowników rt (przykładowo za pomocą:

groupadd rt

Teraz można skopiować pliki do

/opt/rt3/ wykonując polecenie

make

install

. Kolejnym krokiem jest edycja

pliku konfiguracyjnego /opt/rt3/etc/RT_
SiteConfig.pm. Przed przystąpieniem do
tego, najprościej jest skopiować zawartość
/opt/rt3/etc/RT_Config.pm (stanowi ona
bardzo dobrą bazę do dalszych zmian).
Najważniejsze zmienne (które znaleźć
można w wyżej wymienionym pliku) ich
wartości i znaczenie przedstawia Tabela
1. Po zakończeniu edycji, należy utworzyć
i zainicjować bazę danych wykorzystując
polecenie

make initialize-database

Fragment przykładowego wyniku jego
działania przedstawia Listing 2. W
przypadku błędnego wykonania, bazę
danych można usunąć używając

make

dropdb

, a następnie powtórzyć polecenie

make initialize-database

(po

dokonaniu koniecznych zmian w pliku
/opt/rt3/etc/RT_SiteConfig.pm).

Listing 3.

Fragment pliku

konfiguracji serwera Apache (/etc/

httpd/conf/httpd.conf)

# Konfiguracja dla RT
# Ścieżka do plików interfejsu WWW

Alias

/rt/

/opt/rt3/share/html/

<Directory

/opt/rt3/share/html/

Order

allow,deny

Allow

from

all

</Directory>

# Zależności perla

PerlRequire

/opt/rt3/bin/webmux.pl

<Location

/rt/

AddDefaultCharset

UTF-8

SetHandler

perl-script

PerlHandler

RT::Mason

</Location>

Listing 2.

Fragment pomyślnego wyniku działania make initialize-database

Type:   mysql
Host:   localhost
Name:  rt3
User:  rt_user
DBA:  rt_user
Now populating database schema.
Done.
/usr/bin/perl -Ilib -I/opt/rt3/local/lib -I/opt/rt3/lib \
/opt/rt3/sbin/rt-setup-database –action acl \
–datadir etc –dba rt_user –prompt-for-dba-password
In order to create or update your RT database,
this script needs to connect to your mysql instance
on localhost as rt_user.
Please specify that user's database password below.
If the user has no database password, just press return.

Password:
Working with:
Type:  mysql
Host:  localhost
Name: rt3
User:   rt_user
DBA:  rt_user
Now inserting database ACLs.
Done.

Listing 1.

Fragment pomyślnego wyniku działania make testdeps

XML::RSS >= 1.05...found
HTML::Mason >= 1.36...found
Digest::MD5 >= 2.27...found
MYSQL dependencies:
DBD::mysql >= 2.1018...found
SMTP dependencies:
Net::SMTP...found
STANDALONE dependencies:
Net::Server::PreFork...found
Net::Server...found
HTTP::Server::Simple >= 0.34...found
HTTP::Server::Simple::Mason >= 0.09...found

All dependencies have been found.

PRAKTYKA

HAKIN9 1/2010

RTIR

HAKIN9

1/2010

Dostęp przez interfejs WWW

Czas na konfigurację dostępu przez
przeglądarkę WWW. Istnieją dwie
możliwości wyboru adresu dostępowego:
subdomena (np. http://rt.ath/) lub
podkatalog (np. http://ath/rt/). W
niniejszym opracowaniu wybrano wersję
drugą. Konfiguracja odpowiedzialna za
udostępnienie interfejsu WWW znajduje
się w dwóch plikach: /opt/rt3/etc/
RT_SiteConfig.pm (plik konfiguracyjny
RT) i /etc/httpd/conf/httpd.conf (plik
konfiguracyjny serwera Apache). Adres
dostępowy określany jest na podstawie
zmiennych WebDomain i WebPath (patrz
Tabela 1) w następujący sposób: http:
//WebDomain/WebPath/. W naszym
przypadku zmienne te ustawiono
odpowiednio na ath i /rt, dzięki czemu
otrzymano adres dostępowy: http:
//ath/rt/ (przy czym ath jest w naszym
przypadku nazwą hosta lokalnego).
Kolejnym krokiem jest konfiguracja
serwera Apache. Przykładowe ustawienia
zaczerpnięte z pliku /etc/httpd/conf/
httpd.conf przedstawia Listing 3. Tworzony
przy jego pomocy alias dla katalogu z
plikami interfejsu WWW RT (/opt/rt3/share/
html/) oraz włączane jest użycie perla.
Jeśli nie zostało to wykonane wcześniej,
należy też włączyć wtyczkę mod_perl w
konfiguracji modułów Apache. Można to
zrobić dopisując w pliku /etc/httpd/conf/
httpd.conf linię:

LoadModule perl _

module modules/mod _ perl.so

Aby nowe ustawienia przyniosły

efekt, należy zrestartować serwer WWW:

/etc/rc.d/httpd restart

. Serwer www

należy restartować także po zmianach
dokonanych w pliku /opt/rt3/etc/RT_
SiteConfig.pm.

Konfiguracja interfejsu e-mail

Ostatnim elementem do skonfigurowania
jest obsługa poczty elektronicznej.
System RT może współpracować z
serwerem poczty udostępnianym na
innej, nielokalnej maszynie, jednak
w niniejszym artykule ograniczymy
się do użycia serwera lokalnego. Do
wysyłania e-maili, RT używa bramki
zaimplementowanej w perlu: /opt/rt3/rt-
mailgate. Dla zapewnienia poprawnego
działania systemu konieczna jest
odpowiednia konfiguracja serwera poczty

(w naszym przypadku Postfix). Zazwyczaj,
w pliku /etc/mail/aliases dodać należy
następujące wpisy:

rt: „|/opt/rt3/bin/rt-mailgate
   --queue General –action correspond
   --url http://ath/rt”
rt-comment: „|/opt/rt3/bin/rt-mailgate
   --queue General –action comment
   --url http://ath/rt”

Należy w tym miejscu mieć świadomość,
że General jest nazwą jedynej, domyślnie
tworzonej kolejki (kolejki służą do
grupowania biletów). Podobne operacje
należy wykonać dla każdej kolejki
utworzonej później w systemie.

Tymczasem, jeśli wszystko do tej

pory zostało wykonane poprawnie, nasz
system powinien być już dostępny przez

przeglądarkę WWW pod adresem http://
ath/rt/ (Rysunek 2). Domyślny login i hasło
podczas pierwszego logowania to root
i password. W tym momencie polecam
poświęcić kilka minut na zapoznanie się z
interfejsem WWW.

Wtyczki RTIR i RTFM

Czas na to, na czym nam najbardziej
zależy, czyli wtyczkę RTIR. Dodatkowo,
zainstalujemy też wtyczkę RTFM. Po
rozpakowaniu pobranych wcześniej
archiwów z kodami źródłowymi,
zmieniamy katalog bieżący na katalog z
kodem źródłowym (kolejno RTIR i RTFM) i
wykonujemy (w każdym z nich) polecenia:

perl Makefile.PL
make install
make initdb

Rysunek 3.

Zarządzanie użytkownikami

Rysunek 4.

Zarządzanie kolejkami

PRAKTYKA

HAKIN9 1/2010

RTIR

HAKIN9

1/2010

Stworzą one zestaw plików makefile,
zainstalują pliki wtyczek w katalogu
/opt/rt3/ i zaktualizują bazę danych, w
podobny sposób jak to miało miejsce
podczas instalacji systemu RT.
Następnie należy edytować plik
konfiguracyjny /opt/rt3/etc/RT_
SiteConfig.pm, dodając linię:

Set(@Plugins, 'RT::FM', 'RT::IR');

Oczywiście, aby zmiany przyniosły efekt,
należy ponownie uruchomić serwer
WWW (Apache):

/etc/rc.d/httpd

restart

Wraz z wtyczką RTIR do naszego

systemu dodane zostały 4 kolejki (wcześniej
była tylko General): Blocks, Incident Reports,
Incidents oraz Investigations. Należy
zatem uaktualnić konfigurację serwera
poczty, dodając w pliku /etc/mail/aliases
następujące linie:

rt: „|/opt/rt3/bin/rt-mailgate
   --queue Blocks –action correspond
   --url http://ath/rt”
rt-comment: „|/opt/rt3/bin/rt-mailgate
   --queue Blocks –action comment
   --url http://ath/rt”

dla każdej z kolejek (zmieniając Blocks
kolejno na nazwę każdej z nich).

Tym razem, po zalogowaniu się,

naszym oczom powinien ukazać
się interfejs z menu po lewej stronie,
zawierającym między innymi pozycji RTIR i
RTFM (które to nie były dostępne podczas
po poprzednim logowaniu). Czytelnicy
posiadający język polski jako domyślny
w swojej przeglądarce WWW, zauważą
zapewne niekompletność tłumaczenia
interfejsu (niektóre pozycje są po polsku,
niektóre po angielsku). Z tego powodu, aby
zachować czytelność, w dalszej części
artykułu używany będzie interfejs w wersji
angielskiej.

W tej chwili nasz system nie nadaje się

jeszcze do praktycznego użycia. Konieczne
jest założenie i skonfigurowanie kont
użytkowników oraz dostosowanie go nieco
do naszych potrzeb (w tym stworzenie grup
i przyznanie im uprawnień).

Typowy przypadek użycia

Czas na wypróbowanie naszego nowo
zainstalowanego systemu. Pierwsze co
powinniśmy zrobić po zalogowaniu się,
to oczywiście zmiana hasła użytkownika
root. W tym celu należy wybrać Home ->

Configuration -> Users -> root, wprowadzić
nowe hasło i potwierdzić zmiany. Następnie
możemy zabrać się za dostosowywanie
systemu. Bogactwo opcji jest tak ogromne,
że w niniejszej części artykułu ograniczymy
się tylko do dodania kilku użytkowników i
grup, podstawowej konfiguracji i obsługi
jednego, przykładowego zgłoszenia
wykonanego przy pomocy interfejsu WWW.

Użytkownicy i grupy

Generalnie, użytkowników podzielić można
na dwie grupy: personel (konta uprawnione)
i użytkowników zewnętrznych (konta
nieuprawnione). Po otrzymaniu nowego
zgłoszenia (biletu) od niezarejestrowanego
użytkownika (drogą poczty elektronicznej),
system automatycznie tworzy konto
nieuprzywilejowane. Konta użytkowników
mogą być też zakładane ręcznie, ale nie
mogą być usuwane (mogą być co najwyżej
wyłączane).

Na początek utworzymy kilku

użytkowników. Będą to pracownicy firmy ATH:
cezary i cyryl (z zespołu CSIRT), nikodem
i norbert (z zespołu NOT (ang. Network
Operations Team)) i zenon (z zarządu ATH).
Aby dodać użytkownika, z menu należy
wybrać Home -> Configuration -> Users ->
Create i wypełnić wszystkie potrzebne pola.
Ważne jest tutaj zaznaczenie opcji Let this
user be granted rights znajdującej się nad
polem Nowe hasło. Jeśli tego nie zrobimy,
użytkownik będzie nieaktywny i domyślnie
niewidoczny na liście użytkowników (Home ->
Configuration -> Users).

Grupa jest zbiorem użytkowników

posiadających wspólne cechy. Wyróżnia
się 5 rodzajów grup: zdefiniowane przez
użytkownika, systemowe (użytkownicy
uprawnieni i nieuprawnieni), role
(zgłaszający, właściciel itp.), grupy
personalne oraz podgrupy. Rodzaj grupy
można określić dopiero po jej utworzeniu.
W niniejszym artykule ograniczymy się
do utworzenia grup rodzaju pierwszego,
reprezentujących działy firmy. Utwórzmy
więc grupy CSIRT, NOT i Management
(wybierając z menu Home -> Configuration
-> Groups -> Create) oraz przypiszmy do
nich użytkowników utworzonych wcześniej
(wybierając z menu Home -> Configuration
-> Groups -> CSIRT -> Members, dla każdej
z utworzonych grup zmieniając CSIRT na
właściwą nazwę).

Listing 4.

Przykładowy szablon automatycznej odpowiedzi

RT-Attach-Message: yes
Subject: {$Ticket->Subject}

{$Transaction->Content()}

-------------------------------------------------------------------------
Proszę o umieszczanie identyfikatora:

[{$rtname} #{$Ticket->id}]

w tematach przyszłych wiadomości dotyczących niniejszego
incydentu. Aby to zrobić wystarczy wysłać wiadomość jako
odpowiedź na niniejszą.

Dziękuję,
{$Ticket->QueueObj->CorrespondAddress()}

Listing 5.

Szablon wiadomości o zmianie priorytetu biletu

RT-Attach-Message: yes
Subject: {$Ticket->Subject}

Priorytet Twojego biletu nr {$Ticket->id} został zmieniony.

Dziękuję,
{$Ticket->QueueObj->CorrespondAddress()}

PRAKTYKA

HAKIN9 1/2010

RTIR

HAKIN9

1/2010

Grupy, podobnie jak użytkownicy, nie

mogą być usuwane. Jeśli sądzimy, że jakaś
grupa jest już niepotrzebna w systemie,
możemy ją co najwyżej wyłączyć. W naszej
instalacji, oprócz nowo utworzonych
grup istnieją domyślne Duty Team, Duty
Team EDUNET i Duty Team GOVNET.
Wyłączmy je, wybierając z menu Home
-> Configuration -> Groups -> Duty Team
(oraz pozostałe grupy) i odznaczając opcję
Udostępniona. Dzięki temu, domyślnie
nie będą one wyświetlane na liście grup
Home -> Configuration -> Groups (można
to zmienić zaznaczając opcję Include
disabled groups in listing).

Utwórzmy teraz jeszcze jednego

użytkownika spoza firmy ATH (będącego
pracownikiem ATJ) o nazwie urban.
Przyda on nam się później do
zgłoszenia incydentu. Użytkownika
tego nie przypisujemy do żadnej grupy.
Spowoduje to umieszczenie go w grupach
systemowych Nieuprawnieni i Wszyscy
(ang. Unprivileged i All).

Kolejki i prawa dostępu

Jak już wspomniano wcześniej, kolejki służą
do grupowania biletów. W tym momencie
w naszym systemie powinno być widoczne
(Home -> Configuration -> Queues) 5
następujących kolejek: Blocks, Incident
Reports, Incidents, Investigations i General,
przeznaczonych odpowiednio dla blokad,
raportów na temat incydentów, zgłoszeń
incydentów, dochodzeń i pozostałych
zgłoszeń.

Prawa dostępu mogą być przyznawane

w odniesieniu do użytkowników, grup i
kolejek. W praktyce, przed przyznaniem
praw dostępu, musimy zadać sobie trzy
pytania. Po pierwsze, komu przyznać
prawa dostępu (użytkownikowi, grupie,
właścicielowi biletu, wszystkim)? Po drugie,
do czego przyznać prawa dostępu
(konkretnej kolejki, kilku kolejek kolejek,
globalnie)? Po trzecie, jakie prawa dostępu
przyznać (przeglądanie, edycja, tworzenie)?

Przyznajmy więc odpowiednie

uprawnienia dla użytkowników i grup,
które właśnie stworzyliśmy, zadając sobie
wspomniane 3 pytania. Na początek
przyznajmy grupie NOT prawa dotyczące
kolejki Blocks, tak aby użytkownicy byli
w stanie tworzyć, odczytywać i brać
w posiadanie bilety zgrupowane w tej

kolejce, a także na nie odpowiadać.
Możemy to zrobić wybierając z menu
Home -> Configuration -> Queues -> Blocks
-> Group rights oraz przyznając grupie
NOT następujące uprawnienia: OwnTicket,
ReplyTicket, SeeQueue, ShowTicket, i
TakeTicket (aby wybrać z listy więcej niż
jedno uprawnienie, przytrzymaj klawisz
[Control]). Ustalmy też od razu uprawnienia

dla grupy CSIRT, pozwalające co najmniej
na tworzenie biletów dla tej samej kolejki:
CreateTicket, ShowTicket. Kolejna kolejka,
dla której ustawimy uprawnienia to
Incidents. Ponieważ chcemy, aby każdy kto
posiada konto w systemie mógł zgłosić
incydent, przyznajmy następujące prawa
(wyberając z menu Home -> Configuration
-> Queues -> Incidents -> Group rights) dla

Rysunek 5.

Zarządzanie uprawnieniami

Tabela 1.

Najważniejsze zmienne konfiguracyjne, ich znaczenie i użyte wartości

Zmienna

Wartość Znaczenie

rtname

ath

nazwa domeny, w obrębie której RT ma

funkcjonować (w naszym przypadku nazwa

hosta, na którym pracujemy)

DatabaseType

mysql

typ bazy danych

DatabaseUser

rt_user

użytkownik bazy danych

DatabasePassword

******

hasło bazy danych dla systemu RT

DatabaseName

rt3

nazwa bazy danych

WebDomain

ath

domena instalacji interfejsu WWW

WebPath

/rt

ścieżka do instalacji interfejsu WWW

PRAKTYKA

HAKIN9 1/2010

grupy systemowej Everyone: CreateTicket,
Modify Ticket, SeeQueue, ShowTicket.
Oprócz tego, chcemy aby członkowie
CSIRT mogli przejmować bilety oraz
na nie odpowiadać, przyznajmy zatem

tej grupie uprawnienia: OwnTicket,
ReplyToTicket, TakeTicket. Czas wreszcie
na określenie uprawnień do ostatnie (w
naszym przypadku kolejki) – Investigations.
Ponieważ w naszym systemie

dochodzenia będą tworzone przez
członków zespołu CSIRT, wybierzmy z
menu Home -> Configuration -> Queues ->
Investigations -> Group rights i przyznajmy
następujące uprawnienia grupie CSIRT:
CreateTicket, OwnTicket, ShowTicket.

Przykład obsługi zgłoszenia

Można już powiedzieć, że nasz system ma
podstawową funkcjonalność – sprawdźmy
więc jego działanie. W tym celu stworzymy
nowe zgłoszenie używając interfejsu
WWW. Logujemy się jako użytkownik
urban i w prawym górnym rogu interfejsu
wybieramy kolejkę Incidents (która w tym
momencie powinna być jedyną dla nas
dostępną) oraz naciskamy przycisk New
ticket in. Wypełniamy pola tematu (Subject)
i wiadomości (Message) wpisując
odpowiednio np.: Skanowanie portów i
Nasi administratorzy wykryli skanowanie
portów przeprowadzone z adresu IP
192.168.0.13. Następnie tworzymy
powiadomienie o incydencie, naciskając
przycisk Create.

Po otrzymaniu komunikatu o

pomyślnym utworzeniu incydentu
możemy się jeszcze upewnić, że jest
on już widoczny na stronie głównej
(Home) w ramkach Most due unowned
incidents oraz Most due incidents.
W tym momencie rola naszego
użytkownika z firmy zewnętrznej jest
już zakończona. Zalogujmy się więc
jako jeden z członków zespołu CSIRT,
np. cezary. Widzimy na stronie głównej
nowy bilet (incydent) . Decydujemy się
na zajęcie tym zgłoszeniem (klikamy
link Take). Następnie, po zapoznaniu
się z treścią ogłoszenia i ocenie, że nie
istnieje jeszcze żadne dochodzenie
związane z podobnymi zgłoszeniami,
tworzymy nowe dochodzenie (ramka
Investigations, link Launch). Ponieważ
jednak wkrótce kończymy pracę, należy
wylogować się z systemu. Teraz możemy
zalogować się jako cyryl i zapoznać z
dochodzeniem. Jako cyryl decydujemy
się na zajęcie dochodzeniem (link Take).
Oczywiście próbujemy skontaktować się z
właścicielem nieszczęsnego nr IP, jednak
ponieważ nam się to nie udaje, tworzymy
blokadę (ramka Blocks, link New), prosząc
o zablokowanie adresu IP 192.168.013 i
należy się wylogować. Analogicznie do

Rysunek 6.

Tworzenie powiadomienia o incydencie

Rysunek 7.

Odpowiedź na bilet z kolejki Blocks

PRAKTYKA

HAKIN9 1/2010

poprzednich czynności, po zalogowaniu
się jako nikodem zajmujemy się nowym
biletem w kolejce Blocks, tworząc blokadę
w rzeczywistości (aktualizując ustawienia
firewalla) oraz odpowiadając na bilet (link
Reply) (Rysunek 7).

Następnie logujemy się ponownie

jako cezary. Otwieramy jedyny bilet
jaki posiadamy. Tym razem, widzimy
dwa kolejne bilety z nim powiązane
(w ramkach Investigations i Blocks).
Otwieramy bilet kolejki Blocks i widzimy
odpowiedź nikodema, że blokada
została wykonana. Wracamy do strony
zgłoszenia które przyjęliśmy od urbana
i odpowiadamy na nie (przycisk Reply),
że wykonana została blokada, a
dochodzenie trwa.

Tak oto przeszliśmy przez przykładowy

łańcuch reakcji na incydent (w bardzo
okrojonym wydaniu i ciągle nie
dokończony). W praktyce wymaga to
nieco więcej zachodu, jednak trudno
zaprzeczyć, że teraz bardzo dobrze
widać, iż przy odpowiedniej konfiguracji
i dużej liczbie zgłoszeń, RTIR może
znacznie usprawnić pracę. A to nie
wszystko. System udostępnia nam jeszcze
bardziej zaawansowane możliwości,
takie jak zgłoszenia z użyciem poczty
elektronicznej, priorytezowanie biletów,
szablony wiadomości, skrypty, tablice
ogłoszeń (które możemy zmieniać wg
własnych potrzeb) oraz wiele rozszerzeń i
narzędzi (np. wtyczka RTFM, niszczarka), o
których w dalszej części artykułu.

Bardziej zaawansowana

funkcjonalność

System RTIR może być w bardzo szerokim
zakresie dostosowany do specyficznych
potrzeb. Możliwe jest m.in. tworzenie
dodatkowych, własnych pól dla biletów,
kolejek, grup i użytkowników (Home ->
Configuration -> Custom Fields -> Create).
Pola takie mogą być użyte przykładowo
do dodania nowych stanów biletów
(np. oprócz domyślnych open, resolved,
abandoned można sobie zdefiniować
spam) lub nowych atrybutów użytkowników
(np. narodowości, czy stażu pracy).

Kolejną użyteczną funkcjonalnością,

o której warto wspomnieć w tym
miejscu, jest system priorytetów biletów.
Priorytety pozwalają na kolejny stopień

(po kolejkach) uporządkowania biletów.
Każdy bilet może mieć nadany priorytet
liczbowy od 0 do 99, przy czym wyróżnia
się dodatkowo 5 poziomów słownych:
Low, Medium, High, Critical, Fatal, z
przyporządkowanymi im zakresami
liczbowymi (odpowiednio 11-20, 21-30,
31-40, 41-50, 51-60). Przyporządkowane
określeniom słownym zakresy można
oczywiście zmieniać wg potrzeb.

Przekazywanie wiadomości

Przekazywanie wiadomości jest
bardzo użyteczną funkcjonalnością.
Pozwala ono na automatyczne
powiadomienie określonych osób o
biletach określonego typu. W praktyce
sprowadza się to do przyznania
użytkownikowi, grupie użytkowników lub
roli odpowiednich praw dla odpowiedniej
kolejki.

Rysunek 8.

Dodanie nowego obserwatora kolejki

Rysunek 9.

Zarządzanie globalne szablonami

RTIR

HAKIN9

1/2010

Skonfigurujmy więc nasz system tak,

aby wiadomości dotyczące dochodzeń
(ang. investigations) były przekazywane

zenonowi. Można to zrobić dodając zenona
do grupy (roli) Cc. Logujemy się jako root i
wybieramy z menu Home -> Configuration

-> Queues -> Investigations -> Watchers.
Następnie dodajemy zenona jako Cc
(np. wybierając Name i wpisując zenon).
Nie działa? Nic dziwnego, zenon nie miał
przecież przyznanych odpowiednich
praw dostępu. Zanim będzie on mógł
być dodany jako obserwator (watcher),
musimy mu przyznać prawo WatchAsCc.
Aby to zrobić wybieramy z menu Home ->
Configuration -> Queues -> Investigations ->
UserRights i przyznajemy zenonowi prawo
Watch. Ponownie próbujemy dodać ustalić
zenona jako obserwatora, wybierając
Home -> Configuration -> Queues ->
Investigations -> Watchers i dodając
go jako Cc (Rysunek 8). Od tej pory,
zenon będzie dostawał kopie wszystkich
informacji przesyłanych w kolejce
Investigations.

Szablony i skrypty

Szablony wiadomości (ang. templates)
mogą być tworzone globalnie (jako
przeznaczone dla wszystkich kolejek)
lub lokalnie (wewnątrz wybranej kolejki).
Umiejętne ich użycie w znaczny sposób
odciąża pracowników. Skrypty (celowo
nazywane przez autorów RTIR Scrips, nie
Scripts), podobnie jak szablony, mogą być
tworzone globalnie lub lokalnie (wewnątrz
kolejek). Zasada działania skryptów opiera
się na łańcuchu warunek – akcja – szablon.
Jako warunek może podać np. utworzenie
incydentu, otrzymanie komentarza lub
zakończenie dochodzenia. Akcją może być
np. wysłanie powiadomienia do właściciela
biletu, którego dotyczyło zdarzenie
spełniające warunek. W takim wypadku, do
wygenerowania treści wiadomości używany
jest właśnie szablon.

Spróbujmy dostosować szablony

wiadomości wysyłanych automatycznie w
przypadku tworzenia nowych dochodzeń
(Investigations). Można to zrobić wybierając
z menu Home -> Queues -> Investigations
-> Templates -> Autoreply. Przykładowy
(zmodyfikowany już) szablon Autoreply dla
kolejki Investigations przedstawia Listing
4. Widać na nim sposób odwoływania się
do właściwości biletu z użyciem znaków

. Przykładowo wyrażenie

{$Ticket-

>QueueObj->CorrespondAddress()}

przy wysyłaniu wiadomości zostanie
zastąpione domyślnym adresem
korespondencyjnym dla niniejszego

Rysunek 10.

Tworzenie nowego skryptu

Rysunek 11.

Tworzenie nowego artykułu (wtyczka RTFM)

PRAKTYKA

HAKIN9 1/2010

biletu, natomiast

{$Ticket->id}

będzie

zastąpione nr id biletu.

Spróbujmy jeszcze utworzyć nowy

szablon globalny, który przyda nam za
chwilę do zademonstrowania zasady
działania skryptów. Z menu wybieramy
Home -> Configuration -> Global ->
Templates -> New. Wpisujemy nazwę
ZmianaPriorytetu, opis powiadomienie
o zmianie priorytetu i zawartość, którą
przedstawiona Listing 6.

Tak utworzony szablon będzie służył

do automatycznego poinformowania
zgłaszającego o zmianie priorytetu jego
zgłoszenia. Aby to uzyskać musimy
jeszcze utworzyć skrypt. Ponieważ chcemy
aby dotyczył on wszystkich biletów,
niezależnie od kolejki, do jakiej zostają
przyporządkowane, tworzymy go także w
sekcji globalnej. Aby to zrobić wybieramy
z menu Home -> Configuration -> Global
-> Scrips -> New (Rysunek 10). Podajemy
opis (ang. description) Powiadomienie
OZmianiePriorytetu, wybieramy warunek
(condition) On Priority Change, operację
Autoreply To Requestors oraz szablon
(które przed chwilą utworzyliśmy) Globa
template: ZmianaPriorytetu. Analogicznie
można tworzyć skrypty dla szerokiej gamy
innych akcji.

Wtyczki, narzędzia i rozszerzenia

Jedną z dostępnych dla RT wtyczek
(która może być szczególnie użyteczna
w systemie RTIR) jest RTFM. Daje ona
możliwość tworzenia przez użytkowników
artykułów i może być wykorzystana np.
do popularyzowania wśród użytkowników

schematów postępowania po wykryciu
incydentu bezpieczeństwa. Spróbujmy
stworzyć prosty artykuł z wykorzystaniem
RTFM. Zalogowanie jako root, wybieramy
z menu Home -> RTFM -> Articles -> New
Article oraz pozycję in class Templates.
Następnie wypełniamy wszystkie pola wg
uznania i naciskamy Create. Szczególnie
użyteczne są tutaj pola Refers to: oraz
Referred by:, w których można zdefiniować
połączenia z innymi artykułami i – co w
naszym przypadku ważniejsze – biletami
(Rysunek 11). Artykuły mogą być też
tworzone z poziomu obsługi biletu poprzez
kliknięcie linku New w ramce Articles
(podobnie jak wcześniej było tworzone
np. dochodzenie z użyciem ramki
Investigations).

Oprócz wtyczek dostępne są także

użyteczne narzędzia, m.in. raporty (Home
-> Tools -> Reports), pozwalające na
sprawdzanie biletów rozwiązanych lub
utworzonych w określonym przedziale
czasu, kolejce i przez określonego
użytkownika.

Kolejnym narzędziem są tablice

ogłoszeń (ang. dashboards), pozwalające
na współdzielenie wybranych danych
(np. kliku naszych biletów o największych
priorytetach) z innymi użytkownikami,
zwalniając ich z konieczności wyszukiwania
takich danych na własną rękę.

Szereg narzędzi można też

doinstalować w formie rozszerzeń
(ang. extensions). Jednym z nich jest
Export search results as XLS. Pozwala
ono na tworzenie zestawień biletów/
użytkowników posiadających określone

atrybuty w formacie Microsoft Excel.
Innym użytecznym rozszerzeniem jest
RT3StatisticsPackage, które pozwala
na generowanie raportów na temat
czasu, liczby obsłużonych zgłoszeń
itp. dla poszczególnych użytkowników.
Istnieje także możliwość kontrolowania
systemu z użyciem wiadomości e-mail,
dzięki rozszerzeniu Command by email.
Udostępnia ono polecenia m.in. polecenia
typu utwórz kolejkę czy zmień priorytet biletu
poprzez użycie odpowiednich tematów
wiadomości. Inne przykłady rozszerzeń to
niszczarka (shredder), SLA (Service Level
Agreements), kalendarz (RTx::Calendar),
scalanie użytkowników (RT::Extension::
MergeUsers), wizualizacja biletów na osi
czasu (RT::Extension::Timeline). Obecnie, na
oficjalnej stronie projektu dostępne jest w
sumie ponad 30 rozszerzeń.

Podsumowanie

Systemy wsparcia reagowania na incydenty
stanowią bardzo użyteczne narzędzie,
pozwalające zorganizować pracę zespołów
CERT/CSIRT. W niniejszym artykule
przedstawiono jedynie ogólne koncepcje
realizacji takich systemów oraz pokrótce
scharakteryzowano jedno z istniejących,
popularnych, wolnodostępnych rozwiązań
o otwartym kodzie źródłowym. Zarówno
możliwości RTIR jak i wielu innych systemów
tego typu są znacznie szersze, a dogłębne
ich omówienie na łamach kilkustronicowego
artykułu – niemożliwe. RTIR mimo
swych wad niewynikających z oficjalnej
dokumentacji (takich jak niedokończone
tłumaczenie interfejsu na język polski),
posiada jedną, ważną zaletę – bogate
możliwości dostosowania do własnych
potrzeb. W wersji obecnej omówiony system
stanowi, jeśli nie bardzo dobre rozwiązanie
końcowe, to co najmniej bardzo dobrą bazę
do wypracowania takiegoż.

Bardziej dociekliwych odsyłam do

ramki W Sieci, gdzie znaleźć można kilka
ciekawych linków na temat RT (w tym
oficjalne demo on-line, w którym brakuje
niestety wtyczki RTIR).

Akronimy

•   Computer Emergency Response Team – CERT,
•   Computer Security Incident Response Team – CSIRT,
•   Request Trackter – RT,
•   Request Tracker FAQ Manager – RTFM,
•   Request Tracker for Incident Response – RTIR.

W Sieci

•   http://www.bestpractical.com/ – Best Practical,
•   http://bestpractical.com/rt/ – RT,
•   http://bestpractical.com/rtir/ – RTIR,
•   http://bestpractical.com/rtfm/ – RTFM
•   http://wiki.bestpractical.com/view/HomePage – RT Wiki,
•   http://rt.easter-eggs.org/demos/stable/ – RT Demo.

Marcin Teodorczyk

Autor jest absolwentem kierunku Informatyka jednej

z największych polskich uczelni technicznych.

Obecnie pracuje jako asystent informatyczny w dziale

bezpieczeństwa jednego z wiodących w Polsce

dostarczycieli usług obliczeniowych i sieciowych.

Kontakt z autorem: marcin@teodorczyk.info.