2005 01 Nessus – skaner bezpieczeństwa [Bezpieczenstwo]

dla początkujących

styczeń 2005

Nessus – skaner

bezpieczeństwa

Piotr Machej

dy podłączamy nasz kom-
puter do Internetu, uzysku-
jemy dostęp do nieprzebra-
nych zasobów. Równocze-

śnie nasz komputer staje się dostępny dla
innych użytkowników. Nie wszyscy z nich
są nastawieni pokojowo. Trudno zresztą na
to liczyć, biorąc pod uwagę wciąż rosną-
cą liczbę mieszkańców globalnej wioski.
Z tego powodu bardzo ważne jest, aby
zdawać sobie sprawę z zagrożeń, które
mogą na nas czekać. Jeszcze ważniejsze
jest, aby potrafić się przed nimi ochronić.

W łataniu powszechnie znanych luk

bezpieczeństwa znacznie mogą nam
pomóc wszelkiego typu skanery bezpie-
czeństwa. Programy takie mają za zada-
nie przetestowanie, czy system jest podat-
ny na określoną metodę ataku. Powinni-
śmy skorzystać ze skanera (lub kilku ska-
nerów) bezpieczeństwa zaraz po zain-
stalowaniu systemu. Później powinni-
śmy powtarzać tę czynność co jakiś
czas (np. co miesiąc). Pozwoli to wykryć
znane już luki, więc będziemy mieli moż-
liwość załatać je zanim wykorzysta je wła-
mywacz. Pamiętajmy bowiem, że rów-
nież "czarne charaktery" mogą korzystać
z takiego oprogramowania.

Jednym z bardziej uniwersalnych

(a przy tym otwartym i bezpłatnym) ska-
nerem jest Nessus. Jego wielką zaletą
jest aktualność oraz łatwość rozbudowy.
Opiera się na wtyczkach, dzięki czemu
możemy dodać do niego własne testy.
Oprócz tego, możemy automatycznie uak-
tualniać listę wtyczek, dzięki czemu zosta-
ną one dołączone od razu po udostępnie-
niu. Niniejszy artykuł ma na celu popro-
wadzenie Czytelników przez instalację
i konfigurację Nessusa, a także zwróce-
nie uwagi na różne aspekty bezpieczeń-
stwa systemu.

Przykład użycia

Około rok temu, rozmawiając ze znajo-
mymi na IRC, dowiedziałem się, że kom-

puter jednego z nich padł ofiarą ataku.
Jak się okazało, zainstalował on Linuk-
sa i będąc święcie przekonany, że to
bezpieczny system, nie podjął żadnych
dodatkowych kroków w celu jego zabez-
pieczenia. Oczywiście, gdy w wyniku
ataku script-kiddies stracił dane na dysku,
był pełen pretensji do naszego ulubione-
go systemu. Wytłumaczyliśmy mu, że
system dopiero wtedy jest bezpieczny,
gdy się o to samemu zadba. I że nie ma
tu większego znaczenia, czy jest to Linux,
czy Windows. Przy okazji postanowili-
śmy sprawdzić, który z naszych kompute-
rów jest lepiej zabezpieczony. Do testów
wykorzystaliśmy Nessusa i okazało się, że
mój system zajął dopiero trzecie miejsce
(na pięć możliwych). Jak to mówią, leni-
stwo nie popłaca. Oczywiście, od razu
załatałem najgroźniejsze ze znalezionych
luk bezpieczeństwa i obiecałem sobie,
że będę częściej kontrolował system.

Analiza zabezpieczeń

Przede wszystkim musimy odpowie-
dzieć sobie na pytanie, czy nasz system
jest dobrze zabezpieczony. Odpowiedź
nie jest taka prosta. Włamywacz ma do
dyspozycji szereg różnych technik, z któ-
rych warto wymienić wykorzystanie sła-
bych haseł, dziur w oprogramowaniu lub
błędów w konfiguracji. Nie należy rów-
nież zapominać o tym, że zwykle najsłab-
szym ogniwem jest człowiek – to my sami

Na płycie CD/DVD

Na płycie CD/DVD zamieścili-

śmy oprogramowanie omawiane

w artykule.

Rysunek 1.

Nowe wersje Nessusa

pozwalają przeprowadzać również testy
lokalne i przyrostowe

dla początkujących

nessus

www.lpmagazine.org

możemy nieumyślnie podać intruzowi
hasło lub wykonać przysłany przez niego
kod, otwierając mu drogę do systemu.

Hasła powinny być łatwe do zapamię-

tania i trudne do odgadnięcia. Nie zawsze
trudność odgadnięcia hasła będzie warun-
kiem wystarczającym, gdyż jeśli jest ono
przesyłane przez sieć (np. w celu zalogo-
wania się na zdalną maszynę lub autory-
zowania się w serwisie WWW), to może
zostać podsłuchane. Z tego powodu lepiej
jest używać oprogramowania korzystającego
z szyfrowanej transmisji, a w dodatku nigdy
nie używać hasła systemowego do autoryza-
cji w innych serwisach.

Z błędami w oprogramowaniu trzeba

zawsze się liczyć. Praktycznie każdy pro-
gram, bardziej skomplikowany niż popu-
larny Hello World, może zawierać błąd – jest
to sprawa naturalna. Odpowiednie wyko-
rzystanie niektórych błędów może pro-
wadzić do uzyskania przez intruza więk-
szych uprawnień w systemie niż miałby
normalnie. Może też pozwolić na uzyska-
nie dostępu do systemu, do którego intruz
w zwykłych okolicznościach nie powinien
mieć wcale dostępu. Takie błędy są wcześniej
lub później ujawniane, a jeśli autorzy progra-
mu opiekują się swoim projektem, to publi-
kują odpowiednie poprawki. W przypad-
ku programów Open Source mogą to zrobić
również inni programiści, a nawet my sami
(o ile posiadamy odpowiednie umiejętności).
Warto więc dbać o to, aby w systemie były
zainstalowane jak najnowsze wersje oprogra-
mowania – szczególnie chodzi tu o progra-
my najbardziej narażone na atak, takie jak
serwery WWW czy programy pocztowe.

Bardzo często zdarza się, że użytkow-

nik przez własną nieuwagę lub niewiedzę
staje się ofiarą włamania lub zwykłej utraty
danych. Swego czasu wiele osób korzystają-
cych z IRC miało zwyczaj doradzać nowym
użytkownikom Linuksa zalogowanie się na
konto root i wydanie polecenia

rm -rf /

. Jeśli

delikwent był łatwowierny, a na dodatek nie
znał jeszcze podstawowych poleceń linukso-
wych, mogło skończyć się to dla niego nie-
zbyt przyjemnie (wspomniane polecenie
bez pytania kasuje wszystkie pliki na dysku).
Jak widać, należy mieć mocno ograniczo-
ne zaufanie do tego, co mówią inni – czy
to na IRC, w listach elektronicznych, czy za
pośrednictwem komunikatora. Nie należy
też bez namysłu uruchamiać zasłyszanych
poleceń czy programów nadesłanych przez
nie do końca zaufane osoby. To samo zresztą
dotyczy podawania haseł czy udostępniania
naszego komputera innym – jeśli to robimy,

to musimy być święcie przekonani, że tej
konkretnej osobie możemy zaufać.

Wspomniałem o błędach konfigu-

racji. Tu w zasadzie również wchodzi
w grę czynnik ludzki, gdyż błąd w kon-
figuracji jest zwykle wynikiem nasze-
go przeoczenia, pomyłki w planowaniu
lub po prostu nieznajomości niektórych
dostępnych opcji. Wyobraźmy sobie sytu-
ację, gdy wydaje nam się, że zabezpieczy-
liśmy dobrze nasz komputer. Założyliśmy
dobre hasła, uruchomiliśmy zaporę sieciową
i udostępniliśmy na zewnątrz tylko wybrane
usługi. I wszystko byłoby w porządku, ale...
w zaporze sieciowej pomyliliśmy kolejność
dwóch regułek. I to wystarczy, aby działa-
ła nie do końca zgodnie z naszymi oczeki-
waniami – może przykładowo dawać dostęp
do portu, który miał być zablokowany.
A włamywacz tylko czeka na takie okazje.

Instalacja Nessusa

Przed zainstalowaniem Nessusa warto
zadbać o to, aby w systemie były zain-
stalowane biblioteki i pliki nagłówkowe
OpenSSL. W przypadku Auroksa jest to
pakiet openssl-devel.

Zaczynamy od wejścia na stronę do-

mową programu (http://www.nessus.org/ ).
Wybieramy sekcję Download, a następ-
nie odnośnik Nessus 2.2 (w chwili pisa-
nia artykułu była to wersja najnowsza).
Z wyświetlonej strony możemy dowie-
dzieć się o trzech metodach instalacji Nessu-
sa. My zdecydujemy się na drugą – prostą,
a równocześnie bezpieczniejszą od najła-
twiejszej metody. W sekcji The easy and
less dangerous way znajdziemy spis adre-
sów, pod którymi możemy znaleźć insta-
lator. Wybieramy jeden z nich (np. http://
ftp.gwdg.de /pub/linux /misc/nessus/
nessus-2.2.0/nessus-installer/ ) i pobieramy
z niego plik nessus-installer.sh. Teraz
już wystarczy wejść do katalogu,
w którym zapisaliśmy plik i uruchomić
go poleceniem

sh nessus-installer.sh

. Tę

operację wykonujemy z poziomu zwykłe-
go użytkownika (nie wchodzimy na konto
root).

Po przeczytaniu informacji powital-

nej możemy wcisnąć klawisz [Enter]. Pro-
gram zostaje rozpakowany, a następnie
jesteśmy powiadomieni, że zostanie utwo-
rzona tymczasowa powłoka z ustawio-
nym bitem SUID. Pozwoli to instalatorowi
w razie potrzeby na automatyczne korzysta-
nie z uprawnień użytkownika uprzywile-
jowanego. Przyjmujemy to do wiadomości
wciskając klawisz [Enter], a następnie poda-

jemy hasło użytkownika root (przy pyta-
niu o Root Password). Instalator pyta nas
o katalog, w którym chcemy zainstalo-
wać Nessusa. Klawiszem [Enter] zatwier-
dzamy domyślny wybór (chyba, że
z jakiegoś powodu chcemy go zmie-
nić – wówczas wpisujemy naszą ścieżkę).
Po kolejnym wciśnięciu klawisza [Enter]
następuje kompilacja i instalacja programu
(w razie konieczności poprzedzona usu-
nięciem starszej wersji). Na koniec zostają
wyświetlone ostatnie wskazówki i możemy
opuścić instalator ponownym wciśnięciem
klawisza [Enter]. Jak widać, dzięki instalato-
rowi mogliśmy ograniczyć się do wciskania
tylko jednego klawisza, chociaż pozostało
przed nami jeszcze kilka czynności.

Najpierw musimy wygenerować cer-

tyfikat, który będzie wykorzystywa-
ny do szyfrowania komunikacji pomię-
dzy serwerem i klientem Nessusa. W tym
celu wydajemy polecenie

/usr/local/

sbin/nessus-mkcert

(do tego już potrze-

bujemy

uprawnień

superużytkowni-

ka, więc najpierw korzystamy z polecenia

su -

i podajemy hasło użytkownika root).

Oczywiście, jeśli zainstalowaliśmy Nessusa w
innym katalogu niż domyślny, to ścieżka do
programu nessus-mkcert będzie odpowied-
nio inna. Kolejno będziemy musieli podać
następujące informacje:

• termin ważności certyfikatu CA

(w dniach),

• termin ważności certyfikatu serwera

(w dniach),

• kod naszego państwa (np. dla Polski

– PL),

• nazwa naszego województwa lub

powiatu,

• nazwa miasta,
• nazwa naszej organizacji.

Jeśli mamy wątpliwości, co powinniśmy
wpisać, możemy skorzystać z wartości

Rysunek 2.

Nessus potrafi

przeprowadzać równoczesne testy na
różnych komputerach

dla początkujących

styczeń 2005

domyślnych. Po przeczytaniu informa-
cji o nazwach plików, w których zosta-
ły zapisane poszczególne certyfikaty,
możemy wcisnąć [Enter].

Teraz musimy dodać użytkownika,

który będzie mógł korzystać z Nessusa.
Nie opuszczając konta użytkownika root,
wydajemy polecenie

/usr/local/sbin/

nessus-adduser

. Podajemy nazwę użyt-

kownika, a następnie wybieramy sposób
uwierzytelniania. Prostsze jest korzysta-
nie z hasła niż z certyfikatu, więc wybie-
ramy tę pierwszą metodę (pass). Oczywi-
ście, należy też podać nasze hasło. Pamię-
tajmy jednak, aby nie było to takie samo
hasło, jak do któregoś z naszych kont. Jeśli
wybraliśmy metodę uwierzytelniania za
pomocą certyfikatu, to będziemy musieli
odpowiedzieć na te same pytania, co przy
tworzeniu certyfikatu Nessusa (a oprócz
tego, na dwa dodatkowe – o nazwisko
i imię oraz o adres e-mail).

Tworząc użytkownika możemy od

razu nałożyć na niego ograniczenia. Doty-
czą one adresów komputerów, które
może testować dany użytkownik. Jeśli
nie chcemy ustalać żadnych ograniczeń,
to po prostu możemy wcisnąć kombi-
nację klawiszy [Ctrl]+[d]. W innym przy-
padku możemy wpisać szereg reguł
(po jednej w każdej linii), np.:

accept 192.168.100.0/24
accept 192.168.5.1
default deny

Powyższe linie pozwalają użytkow-
nikowi na testowanie komputerów
w sieci 192.168.100.0/24 oraz kompute-
ra 192.168.5.1. Żadnego innego kompu-
tera nie będzie mógł przetestować, gdyż
domyślna reguła odmawia mu dostępu
(default deny). Oczywiście, reguły można
zbudować inaczej – zabronić dostępu do
określonych komputerów i pozwolić do
wszystkich pozostałych. Ciekawostką jest
możliwość użycia słowa client_ip zamiast

adresu komputera. W jego miejsce pod-
stawiany jest adres komputera, z którego
łączy się użytkownik korzystający z Nes-
susa. Dzięki temu łatwo można pozwolić
użytkownikowi tylko na testowanie jego
własnego komputera. Odpowiednie reguł-
ki wyglądają następująco:

accept client_ip
default deny

Wpisywanie regułek kończymy znaną już
kombinacją [Ctrl]+[d]. Wprowadzone dane
potwierdzamy wpisując y.

Przed uruchomieniem serwera warto

sprawdzić, czy nie pojawiły się nowe
wtyczki. Wydajemy polecenie

/usr/local/

sbin/nessus-update-plugins

– jeśli zosta-

ną znalezione nowe wtyczki, program je
zainstaluje. Oczywiście, do wykonania
tego polecenia potrzebujemy połączenia
z Internetem.

Teraz możemy już uruchomić serwer

Nessusa poleceniem

/usr/local/sbin/

nessusd -D

. Pojawi się informacja o łado-

waniu wtyczek (ang. plugins). Jeśli nie
zadbaliśmy o skompilowanie Nessusa
z obsługą OpenSSL, to może pojawić się
kilka ostrzeżeń. Jeśli zainstalowaliśmy
wcześniej wspomniany pakiet openssl-
devel, to powinniśmy zobaczyć napis All
plugins loaded. Klienta Nessusa urucha-
miamy już z konta zwykłego użytkownika
poleceniem

/usr/local/bin/nessus

Konfiguracja Nessusa

Po uruchomieniu pokazuje się nam okno
programu z kilkoma zakładkami. Na
razie interesuje nas tylko pierwsza, gdyż
musimy połączyć się z serwerem Nessu-
sa. W polu Nessusd Host wpisujemy nazwę
komputera, na którym jest uruchomiony
serwer. Jeśli jest uruchomiony na kompu-
terze, z którego korzystamy, możemy po
prostu wpisać

localhost

. Pole Port pozo-

stawiamy bez zmian – Nessus standardo-
wo nasłuchuje na porcie 1241. W polach
Login i Password wpisujemy nazwę i hasło
użytkownika Nessusa (te, które wpisywa-
liśmy po wydaniu polecenia

nessus-addu-

ser

). Teraz wystarczy wcisnąć przycisk Log

in. Przy pierwszym uruchomieniu pojawi
się informacja o certyfikacie. Sprawdzamy,
czy jest on poprawny, tzn. wyświetlone
wartości zgadzają się z tym, co podawali-
śmy podczas jego tworzenia, a następnie
zatwierdzamy go wciskając Yes.

Po zalogowaniu się zostaniemy prze-

niesieni do drugiej zakładki (Plugins),

gdzie możemy zapoznać się ze wszyst-
kimi dostępnymi wtyczkami. Biorąc pod
uwagę, że jest ich obecnie sporo ponad 5
tysięcy, mamy lekturę na dłuższy czas. Na
szczęście, jeśli chcemy przeprowadzić
kompletny test, nie musimy czytać opisu
wszystkich wtyczek (opisy są dostęp-
ne po wskazaniu konkretnej wtyczki).
W górnej części znajduje się spis grup,
natomiast w dolnej spis wtyczek nale-
żących do danej grupy. Możemy zazna-
czyć wszystkie wtyczki wciskając przy-
cisk Enable all. Należy zwrócić uwagę, że
niektóre testy mają na celu destabilizację
testowanego systemu (tzw. ataki odmowy
usługi). Jeśli wolimy nie przeprowadzać
aż tak niebezpiecznych testów, możemy
je wyłączyć przyciskiem Enable all but
dangerous plugins. Dodatkowo możemy
wyłączyć całą grupę testów związanych
z odmową usługi (Denial of Service).

Oczywiście, nic nie stoi na przeszko-

dzie, aby przeprowadzić tylko pojedyn-
cze, wybrane testy. W tym celu wystar-
czy najpierw wcisnąć przycisk Disable
all, a następnie ze spisu wybrać potrzeb-
ne nam wtyczki. Warto przy tym zazna-
czyć opcję Enable dependencies at runti-
me, dzięki czemu w razie potrzeby zosta-
ną zaznaczone inne potrzebne wtyczki
(jeśli są potrzebne do działania wybra-
nych przez nas testów). Dostępny przycisk
Filter pozwala nam na wyświetlenie tylko
wtyczek spełniających określone kryteria
(np. w nazwie lub opisie zawierających
słowo ssh).

Następne dwie zakładki (Prefs.

i Scan options) służą do ustawie-
nia dokładniejszych opcji. Możemy tu
zdecydować, jaka technika skanowa-
nia portów ma być zastosowana, jakie

Rysunek 3.

Te systemy wymagają

wprowadzenia jeszcze kilku zabezpieczeń

Ostrzeżenie

Skaner systemowy możemy stosować
tylko względem systemów komputero-
wych i sieci, które należą do nas lub co
do których uzyskaliśmy stosowną zgodę.
Niezastosowanie się do tej zasady może
grozić niezbyt przyjemnymi konsekwen-
cjami, z odpowiedzialnością karną włącz-
nie. O ile bowiem trudno podstawowe
skanowanie jednoznacznie uznać za
próbę ataku, o tyle niektórzy administra-
torzy są na tym punkcie mocno przewraż-
liwieni. Ponadto, niektóre testy mogą
doprowadzić do zawieszenia niektórych
usług, a to w przypadku systemów pro-
dukcyjnych nie może już być traktowane
w kategorii żartu.

dla początkujących

nessus

www.lpmagazine.org

nazwy użytkowników i hasła mają być
użyte przy logowaniu się do poszcze-
gólnych usług oraz możemy określić
liczbę testów wykonywanych w tym
samym czasie. Jest tu też dostępna
opcja Safe checks (domyślnie włączona).
Powoduje ona, że potencjalnie groźne
wtyczki wykonują "łagodniejsze" testy,
np. opierając się na rozpoznaniu wersji
oprogramowania, zamiast na własnych
testach. Należy pamiętać, że nie wszyst-
kie wtyczki uwzględniają tę opcję. Jej
użycie może też prowadzić do pojawie-
nia się większej liczby fałszywych alar-
mów (więcej informacji w ramce Fałszy-
we alarmy). Jeśli nie wiemy, do czego
służy dana opcja, lepiej pozostawić ją
w domyślnym ustawieniu.

W zakładce Target selection może-

my wreszcie określić, który kompu-
ter chcemy skanować. Jego adres wpi-
sujemy w polu Target(s). Oczywiście,
zamiast pojedynczego adresu (np.

127.0.0.1

) możemy od razu wpisać cały

zakres (np.

192.168.0.1-192.168.2.50

lub

192.168.10.1/24

). Możemy też

wymienić kilka pojedynczych kompu-

terów i kilka zakresów oddzielając je
przecinkami.

Te opcje powinny nam wystarczyć.

Teraz już możemy wcisnąć widoczny na
dole okna przycisk Start the scan. Otwo-
rzy się kolejne okno, w którym będziemy
mogli obserwować przebieg skanowania
poszczególnych komputerów. Gdy ska-
nowanie zakończy się, otwarte zostanie
okno z raportem.

Analiza wyników

Pora sprawdzić, co znalazł Nessus na
naszym systemie. Okno raportu podzie-
lone jest na pięć części. Po lewej stro-
nie widzimy adresy testowanych podsieci
(Subnet). Przy ich adresach można zauwa-
żyć znaczek określający, czy Nessus wykrył
jakieś problemy. Ikona żarówki oznacza
informację, znak ostrzeżenia z wykrzyk-
nikiem oznacza ostrzeżenie dotyczące
bezpieczeństwa, a znak zakazu wjazdu
oznacza potencjalną lukę w bezpieczeń-
stwie. Po wybraniu konkretnej podsieci
w okienku poniżej (Host) pojawi się spis
przetestowanych komputerów należących
do tej podsieci. Również tutaj możemy na

pierwszy rzut oka ocenić, który kompu-
ter jest najbardziej zagrożony. Po zazna-
czeniu adresu komputera w umiesz-
czonym na górze oknie Port, pojawi się
spis znalezionych portów (ponownie
z informacją o zagrożeniach). Wybranie
jednego z nich sprawia, że w umieszczo-
nym obok okienku Severity zobaczymy
listę zagrożeń uporządkowaną względem
powagi. Dopiero, gdy wskażemy jedno
z nich, w głównej części okna zobaczy-
my szczegółowy opis luki. Metody sorto-
wania w poszczególnych oknach możemy

Rysunek 4.

Z pomocą obszernego

podręcznika możemy napisać własne
wtyczki do Nessusa

dla początkujących

styczeń 2005

dowolnie zmieniać, dzięki czemu znaj-
dywać luki w inny sposób. Przykłado-
wo, warto zamienić miejscami pola Port
i Severity, ale również inne kombina-
cje mogą dać ciekawe efekty – wszystko
zależy od tego, jakie informacje bardziej
nas interesują.

Istotne jest, abyśmy zapoznali się

ze wszystkimi informacjami zawartymi
w głównym oknie. W przypadku ostrzeżeń
i powiadomień o lukach w bezpieczeń-
stwie otrzymujemy opis zagrożenia. Przy-
kładowo, w sytuacji wykrycia przez Nes-
susa serwera WWW Apache w wersji star-
szej niż 2.0.51, jesteśmy powiadamiani o
jego wrażliwości na zdalny atak odmowy
usługi (DoS – Denial of Service). Wersje
te są również podatne na atak z wyko-
rzystaniem przepełnienia bufora. Oprócz
takiego opisu, możemy też zobaczyć
kilka dodatkowych rubryk. Adres podany
w See also pozwala nam zapoznać się
z szerszym opisem błędu. Najważniej-
sza dla nas jest zawartość rubryki Solu-
tion, gdyż opisuje ona możliwe rozwiąza-
nie problemu. W przypadku wspomnia-
nego błędu rozwiązaniem jest uaktualnie-
nie serwera Apache do wersji 2.0.51 lub

nowszej. Dalej możemy dowiedzieć się,
jak duże ryzyko (Risk factor) jest związane
z danym błędem. W tym przypadku
ryzyko jest wysokie (High). Najlepiej jak
najszybciej uaktualnić oprogramowanie.
W przypadku innych ostrzeżeń, ryzyko
może być średnie (Medium) lub niskie
(Low), a w przypadku informacji o bez-
pieczeństwie – nawet zerowe (None). Nie-
mniej, powinniśmy zapoznać się ze wszy-
stkimi informacjami, gdyż każda z nich
może być istotna. Przykładowo, może
okazać się, że jedna z usług, pomimo
naszych starań, nadal jest dostępna z Inter-
netu, a nie tylko z sieci lokalnej. Nie należy
od razu podejmować czynności opisanych
w Solution bez zapoznania się z całym
opisem problemu. Może bowiem okazać
się, że w ten sposób zablokujemy sobie
usługę, na której nam zależało, a co do
której tylko dostaliśmy pewne pouczenie
(jak ma to miejsce w przypadku zainstalo-
wanego oidentd, potrzebnego do łączenia
z niektórymi serwerami IRC).

Jeśli chcemy uzyskać jeszcze więcej

informacji na temat błędu, możemy sko-
rzystać z wartości podanych w rubrykach
CVE i BID. Pierwsza z nich podaje sym-
bole, według których możemy wyszuki-
wać informacje na stronie Common Vul-
nerabilities and Exposures (pod adre-
sem

http://www.cve.mitre.org/cve/index

.html wpisujemy symbol w polu CVE
Name). Druga podaje identyfikator błędu
na liście BugTraq (możemy go wpisać
w polu Bugtraq ID na stronie http://
www.securityfocus.com/bid/bugtraqid/ ).

Raport ze skanu możemy zapisać na

dysku korzystając z przycisku Save report.
Do wyboru mamy kilka różnych forma-
tów zapisu danych. Jeśli zdecydujemy się
zapisać raport w formacie NBE, to później
będziemy mogli go ponownie otworzyć
w kliencie Nessusa. Jeśli natomiast chcemy
później obejrzeć raport wraz z różnymi
wykresami i zestawieniami w przeglądar-
ce internetowej, to powinniśmy wybrać
format HTML with Pies and Graphs.

Wyniki skanowania zależą od tego,

jakie opcje dobierzemy. Warto zapoznać
się z obszerną dokumentacją dostępną
na stronie domowej Nessusa, aby lepiej
poznać jego możliwości i zastosowa-
nie poszczególnych opcji konfiguracyj-
nych. Z pewnością sprawi to, że będzie-
my mogli lepiej dobierać ustawienia do
naszych potrzeb, co w rezultacie pozwo-
li skuteczniej zwiększyć bezpieczeństwo
systemu i sieci.

Dodatkowe

oprogramowanie

Nessus, oprócz własnych wewnętrz-
nych testów, może wykorzystywać kilka
innych programów. Przykładowo, pro-
gram Nmap może być użyty do skano-
wania portów i wielu bardziej zaawan-
sowanych operacji, takich jak rozpozna-
wanie systemu operacyjnego. Jeśli zależy
nam na przeprowadzeniu testów odpor-
ności haseł na złamanie, możemy zain-
stalować program Hydra. Pozwoli on na
wykonanie prób brutalnego złamania
haseł (bruteforce attack) w takich usłu-
gach, jak Telnet, WWW, POP3, IMAP
i inne. Oprócz tego, można wykorzy-
stać program Nikto – zapewnia on obsłu-
gę specyficznych ataków i testów doty-
czących serwerów WWW i usług skryp-
tów CGI.

O ile program Nmap możemy zna-

leźć w większości dystrybucji Linuksa,
o tyle pozostałe programy raczej
musimy zainstalować osobno. Nie są
one niezbędne do działania Nessusa,
ale zwiększają jego funkcjonalność.
Adresy ich stron domowych znajdują się
w ramce W Internecie.

Przykładowe testy

W rozdziale Analiza wyników mogliśmy
zapoznać się ze sposobem odczytywania
wyników testów. Spróbujmy teraz zoba-
czyć kilka wyników z prawdziwego ska-
nowania i zastanowić się, jak je trakto-
wać. Analizie został poddany kompu-
ter z dosyć dawno instalowanym sys-
temem, tylko w razie potrzeby uzupeł-
nianym nowymi pakietami, więc zgło-
szeń błędów było dosyć dużo (7 luk, 18
ostrzeżeń i 39 informacji). Raport został
zapisany w formacie HTML with Pies and
Graphs.

Na pierwszej stronie raportu został

przedstawiony w formie graficznej pro-

Fałszywe alarmy

Należy pamiętać, że Nessus przepro-
wadza analizę na podstawie dostępnych
informacji. Może się okazać, że będą
one niewystarczające lub doprowadzą do
błędnych wniosków. Z tego powodu część
ostrzeżeń, a nawet powiadomień o lukach
w zabezpieczeniach, może okazać się fał-
szywa.

Może się tak przykładowo zdarzyć

w sytuacji, gdy Nessus jest w stanie roz-
poznać oprogramowanie nasłuchujące
na określonym porcie, ale nie umie usta-
lić jego wersji. W tym przypadku może
ostrzec o błędach, które dotyczą wcze-
śniejszych wersji tego programu niż zain-
stalowana w naszym systemie.

Inna sytuacja, gdy ostrzeżenie może

być fałszywe, to przypadek, gdy błąd
sam w sobie jest groźny, ale ze wzglę-
du na podjęte przez nas inne czynności
(np. odpowiedni podział dysku na party-
cje), w naszym systemie okazuje się być
nieszkodliwy.

Nie da się wyliczyć wszystkich sytu-

acji, gdy Nessus może zwrócić fałszy-
we alarmy. Dobrze jest uważnie czytać
opisy zgłoszeń i starannie je analizować.
Nessus zwraca stosunkowo mało fałszy-
wych alarmów, ale nie należy mu ufać
bezgranicznie.

Rysunek 5.

W serwisie SecurityFocus

możemy wyszukiwać informacje o lukach
na podstawie różnych kryteriów

dla początkujących

nessus

www.lpmagazine.org

W Internecie:

• Strona domowa programu Nessus:

http://www.nessus.org/

• Strona domowa programu Nmap:

http://www.insecure.org/nmap/
index.html

• Strona domowa programu Hydra:

http://www.thc.org/releases.php

• Strona domowa programu Nikto:

http://www.cirt.net/code/nikto.shtml

• Wprowadzenie do Nessusa (artykuł

autorstwa Harry'ego Andersona):
http://www.securityfocus.com/
infocus/1741

• Lista BugTraq:

http://www.securityfocus.com/
archive/1

centowy udział poszczególnych pozio-
mów ryzyka. Ponieważ poziomy High
i Medium uzyskały odpowiednio po
11% i 28%, to odpowiednie kroki
powinno podjąć się jak najszybciej. Naj-
bardziej zagrożonymi usługami oka-
zały się CVSpserver i usługa działają-
ca na porcie 5432 (zidentyfikowana
później jako PostgreSQL). co przedsta-
wił kolejny wykres. W celu uzyskania
dokładniejszych informacji powinniśmy
przejść do części drugiej raportu, wska-
zując nazwę testowanego komputera.

Tu możemy zobaczyć listę otwar-

tych portów. Okazuje się, że jest ich
aż 34, z czego na pięciu Nessus zna-
lazł luki bezpieczeństwa (CVSpserver,
MySQL, HTTPS, Microsoft-ds i port
5432, wykorzystywany przez Postgre-
SQL), a dla sześciu wyświetlił ostrzeże-
nia. Poza tym jedenaście portów zosta-
ło opatrzonych informacjami, a pozo-
stałe zostały tylko zakomunikowane
jako nasłuchujące. Zapoznajmy się naj-
pierw z dwoma lukami dotyczącymi
serwera CVS.

Pierwsza z nich została wykryta

przez wtyczkę opisaną na stronie
http://cgi.nessus.org/plugins/dump.php3?id
=11970. Do opisów wtyczek prowadzą
odnośniki umieszczone w polu Nessus
ID. Jest to ostrzeżenie przed błędem ist-
niejącym w CVS do wersji 1.11.10, mogą-
cym pozwolić intruzowi na wykonywa-
nie w systemie poleceń z uprawnienia-
mi użytkownika root. Ponieważ Nessus
nie był w stanie określić numeru wyko-
rzystywanej wersji CVS, pojawiło się
ostrzeżenie, że może to być fałszywy
alarm. Niestety, sprawdzenie w testowa-
nym systemie (

rpm -q cvs

) wykazało, że

jednak jest on narażony na atak – zain-
stalowana wersja CVS to 1.11.2-10. Zale-
canym przez Nessusa (i w zasadzie naj-
lepszym) rozwiązaniem jest aktualiza-
cja oprogramowania do wersji co naj-
mniej 1.11.11.

Zanim to zrobimy, zapoznajmy się

z opisem drugiej luki. Ta została wykry-
ta przez wtyczkę opisaną na stro-
nie http://cgi.nessus.org/plugins/dump.
php3?id=12265. Również ta luka nie
jest mała – ze względu na brak termi-
natora NULL w źle sformatowanych cią-
gach tekstowych, intruz może wykony-
wać pewne polecenia w naszym sys-
temie. Zalecana jest aktualizacja aż do
wersji 1.11.17, a więc wyższej niż przy
poprzedniej luce.

Obie te luki umożliwiają atak

z zewnątrz, więc należą do najbardziej
niebezpiecznej grupy. O ile w przypad-
ku pierwszej z nich nie potwierdzono
istnienia działających eksploitów, o tyle
w przypadku drugiej taki kod istnieje.

Oprócz nich, Nessus zgłosił dwa

ostrzeżenia dotyczące serwera CVS.
Pierwszy z nich (http://cgi.nessus.org/
plugins/dump.php3?id=11947) dotyczy
błędu sprawdzania wprowadzanych
danych, mogącego pozwolić intruzo-
wi na tworzenie katalogów i plików
w głównym katalogu systemu plików
przechowującego drzewo CVS. Drugi
z kolei (http://cgi.nessus.org/plugins/
dump.php3?id=12212) może pozwalać
na pobieranie plików RCS nawet spoza
głównego katalogu CVS. Do poprawie-
nia tych błędów powinno wystarczyć
uaktualnienie CVS do wersji 1.11.15 lub
wyższej.

Korzystając z informacji zawartych

we wszystkich czterech zgłoszeniach,
ostatecznie powinniśmy się zdecydo-
wać na wersję 1.11.17 lub wyższą.

Warto zwracać uwagę na komuni-

katy informacyjne. Właśnie odnośnie
serwera CVS został wyświetlony jeden
taki komunikat (http://cgi.nessus.org/
plugins/dump.php3?id=10051). Sugeruje
on, aby zablokować dostęp z zewnątrz
dla portu CVS. Jest to mądre, i o ile
tylko nie musimy udostępniać serwera
CVS osobom z sieci, powinniśmy dopi-
sać odpowiednią regułkę w zaporze sie-
ciowej. Jeśli koniecznie musimy udo-
stępnić serwer, to powinniśmy przy-
najmniej ograniczyć liczbę komputerów,
które mogą się z nim łączyć. Warto też
zauważyć, że powinno to automatycz-
nie zniwelować możliwość wykorzysta-
nia przez włamywacza wymienionych
wcześniej luk.

Innym przykładem portu, który

powinien być odfiltrowany na zapo-
rze sieciowej, jest port 901, należą-
cy do programu SWAT. O ile bowiem
błąd przedstawiony w ostrzeżeniu
(http://cgi.nessus.org/plugins/dump.
php3?id=10273) dotyczy dosyć starej
wersji 2.0.7 (więcej informacji na stro-
nie http://www.securityfocus.com/bid/
1872). o tyle rzeczywiście możliwe jest
wykonanie brutalnego ataku na tę
usługę. Może to być szczególnie nie-
bezpieczne, jeśli hasła Samby są zsyn-
chronizowane z hasłami systemowymi.
Oczywiście, zamiast filtrować port na

zaporze sieciowej możemy po prostu
wyłączyć SWAT (o ile go nie potrze-
bujemy).

Jak widać, w celu wyrobienia sobie

obrazu tego, co musimy zrobić, powin-
niśmy zapoznać się ze wszystkimi opi-
sami błędów, ostrzeżeniami, a nawet
zwykłymi informacjami. W przypad-
ku, gdy chodzi o bezpieczeństwo, nie
powinniśmy pozwalać sobie na nie-
dbałość. Poza tym, szkoda naszej pracy
– gdybyśmy działali od razu po przeczy-
taniu każdej informacji, to serwer CVS
uaktualnialibyśmy w najgorszym przy-
padku cztery razy.

Zakończenie

Zabezpieczanie komputerów i sieci to
wyścig bez końca. Należy pamiętać, że
istnieje pewna granica, której podczas
zabezpieczania nie możemy lub nie
powinniśmy przekroczyć. Jest to grani-
ca wygody naszej lub naszych klientów
w korzystaniu z systemu lub sieci.
Nie ulega bowiem wątpliwości, że nie
ma sensu zabezpieczać komputera do
tego stopnia, że nikt nie będzie chciał
z niego korzystać. Jakie dane będzie-
my wtedy chronić? Znalezienie kom-
promisu pomiędzy wygodą i bezpie-
czeństwem to właśnie nasze zada-
nie. Należy do niego nie tylko zabez-
pieczenie sprzętu i oprogramowania,
ale również odpowiednie wychowa-
nie użytkowników. Pamiętajmy zawsze
o tym, że łańcuch zabezpieczeń jest
tak silny, jak jego najsłabsze ogniwo.
A najsłabszym ogniwem bardzo często
okazuje się człowiek.