PTiWT - Zeszyt 8-9, 2013 -...

Jerzy Konorski

Wydział ETI, Politechnika Gda�ska

80-233 Gda�sk, ul. Narutowicza 11/12,

[email protected]

Piotr Pacyna, Jerzy Kasperek, Wojciech Romaszkan

Akademia Górniczo-Hutnicza

30-059 Kraków, Al. Mickiewicza 30,

[email protected], [email protected]

Zbigniew Kotulski, Krzysztof Cabaj

Wydział EiTI, Politechnika Warszawska

00-665 Warszawa, ul Nowowiejska 15/19, [email protected], [email protected]

Grzegorz Kołaczek

Politechnika Wrocławska

50-370 Wrocław, ul. Wybrze�e Wyspia�skiego 27,

[email protected]

INTEGRACJA NISKOPOZIOMOWEGO PODSYSTEMU BEZPIECZE�STWA DLA SYSTEMU IIP

Streszczenie: Artykuł omawia prace nad prototypowaniem i integracj� podsystemu bezpiecze�stwa Systemu IIP na poziomie wirtualizacji zasobów sieciowych. Przedstawiono jego zakres funkcjonalny, sposób funkcjonowania w sieci badawczej PL-LAB oraz realizacj� scenariusza ochrony danych przesyłanych w Równoległym Internecie CAN.

1. WPROWADZENIE

W ramach projektu In�ynieria Internetu Przyszło�ci

(IIP) [1] opracowano podsystem bezpiecze�stwa na

poziomie wirtualizacji zasobów sieciowych dla ekspe-

rymentalnego �rodowiska sieciowego pod nazw� System

IIP. Proponowana architektura bezpiecze�stwa zawiera

trzy linie obrony [2-6]; pierwsz� z nich stanowi mecha-

nizm kryptograficznej sumy kontrolnej (HMAC − Hash-

based Message Authentication Code) w ł�czu wirtual-

nym, drug� − moduły lokalnej detekcji anomalii (LAD −

Local Anomaly Detection) w ruchu sieciowym i zacho-

waniach w�zła IIP wykorzystuj�ce wyniki testów

HMAC i dane z monitoringu w�złów i ł�czy wirtual-

nych, za� trzeci� − system reputacyjny analizuj�cy rapor-

towane przez HMAC i LAD zdarzenia oznaczaj�ce mo�-

liwe zagro�enia bezpiecze�stwa (SRE – security related

events). Jak wynika z wcze�niejszych analiz, architektura

taka zapewnia ochron� przed atakami o ró�nym pocho-

dzeniu i zasi�gu oddziaływania, polegaj�cymi na fał-

szowaniu ruchu IIP (forging), wstrzykiwaniu obcego

ruchu do Systemu IIP (injection) oraz zaburzaniu kolej-

no�ci jednostek danych (IIP-PDU) w strumieniu ruchu

IIP (resequencing/replay), b�d� relacji czasowych po-

mi�dzy ich przesyłaniem (ruffling). Rys. 1 przedstawia

wspomniane zagro�enia na tle wykorzystywanego w

trakcie prototypowania �rodowiska testowego, w którego

skład wchodz� dwa w�zły Systemu IIP (zlokalizowane

w Krakowie i Wrocławiu) wyposa�one w serwery wirtu-

alizacji i specjalistyczne karty programowalne NetFPGA

1G, poł�czone poprzez infrastruktur� transmisyjn� sieci

badawczej PL-LAB, udost�pnian� poprzez przeł�czniki

EX 3200. Do bada� wykorzystano ruch generowany w

jednym z definiowanych w projekcie IIP Równoległych

Internetów (PI − Parallel Internet), b�d�cym tzw. sieci�

�wiadom� tre�ci (PI-CAN − content aware network).

w�zeł IIPw�zeł IIP

��

��

��

��

��

��

��

��

� ��

��

Infrastruktura transmisyjna

forging

injection reseq/replay/ruffling

IIP-PDUPDU

PI- CAN-PDU


��

��

��

��

��

��

��

��

� ��

��


forging

injection reseq/replay/ruffling

IIP-PDUPDU

PI- CAN-PDU

Rys. 1. Konfiguracja programowo-sprz�towa dla testo-

wania architektury bezpiecze�stwa na ł�czu wirtualnym

Kraków-Wrocław.

W niniejszej pracy przedstawione zostan� wybrane

zagadnienia implementacji i testowania proponowanej

architektury bezpiecze�stwa po integracji elementów i

modułów realizuj�cych poszczególne linie obrony, jak

równie� po integracji z sieci� badawcz� PL-LAB, sieci�

PI-CAN oraz podsystemem zarz�dzania Systemu IIP.

2. PROTOTYP PODSYSTEMU BEZPIECZE�STWA

Organizacj� elementów hardwarowych wchodz�-

cych w skład prototypu podsystemu bezpiecze�stwa oraz

sposób poł�czenia w�złów IIP przedstawia Rys. 2. Ze

wzgl�du na to, �e drug� i trzeci� lini� obrony stanowi�

rozwi�zania programowe, na rysunku widoczne s� jedy-

nie moduły HMAC, stanowi�ce pierwsz� lini� obrony.

Widoczne s� dwa w�zły IIP, krakowski i wrocławski, z

obecnymi tam modułami HMAC, zapewniaj�cymi uwie-

rzytelnianie i integralno�� IIP-PDU w ł�czu dzi�ki

PRZEGL D TELEKOMUNIKACYJNY * ROCZNIK LXXXVI * i WIADOMO CI TELEKOMUNIKACYJNE * ROCZNIK LXXXII * nr 8-9/2013 1031

wspólnemu dla obu w�złów kluczowi kryptograficzne-

mu [5]. Daje to w wyniku abstrakcj� ł�cza wirtualnego w

postaci symbolicznie uwidocznionego na rysunku bez-

piecznego ł�cza wirtualnego, chronionego przed atakami

typu injection i resequencing/replay. W�zeł IIP podł�-

czony jest do przeł�cznika dost�powego EX3200 stano-

wi�cego brzeg sieci badawczej PL-LAB za po�rednic-

twem modułu HMAC zrealizowanego w układzie pro-

gramowalnym NetFPGA 1G.


��

��

��

��

��

��

��

��

� ��

Bezpieczne ł�cze IIP

��


injection

��

��

��

��

��

reseq/replay

PDU

PI- CAN-PDUIIP-PDU


��

��

��

��

��

��

��

��

� ��

Bezpieczne ł�cze IIP

��


injection

��

��

��

��

��

reseq/replay

PDU

PI- CAN-PDUIIP-PDUIIP-PDU

Rys. 2. Konfiguracja programowo-sprz�towa urz�dze�

realizuj�cych pierwsz� lini� obrony

na ł�czu Kraków-Wrocław.

Rys. 3 prezentuje schemat logiczny podsystemu

bezpiecze�stwa skonfigurowany na potrzeby prototypo-

wania i wst�pnych eksperymentów w kierunku we-

wn�trznej integracji trzech linii obrony oraz integracji z

podsystemem zarz�dzania Systemu IIP. Wykorzystano

osiem w�złów (nie wszystkie pokazano na rysunku) −

cztery fizyczne, w tym dwa wykorzystuj�ce wirtualizator

Xen oraz dwa wykorzystuj�ce maszyny z kartami Net-

FPGA oraz cztery zrealizowane jako maszyny wirtualne.

Na siedmiu w�złach działał lokalny agent bezpiecze�-

stwa (LSA − Local Security Agent) i lokalny moduł

wykrywania anomalii (LAD). Natomiast na ósmej ma-

szynie został uruchomiony główny agent bezpiecze�stwa

(MSA − Master Security Agent) zawieraj�cy moduł

REP, który wylicza warto�ci globalnych metryk zaufania

i reputacji wirtualnychw�złów IIP, opieraj�c si� na ra-

portach z poszczególnych LSA, oraz moduł globalnej

detekcji anomalii o zasi�gu Równoległego Internetu (PI-

AD − Parallel Internet-wide Anomaly Detection), któ-

rych nie s� w stanie wykry� moduły LAD, gdy� ich

wykrycie wymaga globalnego widoku stanu sieci. MSA

posiada taki widok dzi�ki współpracy z modułami LAD

w w�złach Systemu IIP. Na Rys. 4 i 5 pokazano konfigu-

racj� i zasady współpracy drugiej i trzeciej linii obrony,

odpowiednio z punktu widzenia akwizycji i dystrybucji

danych przez MSA z wykorzystaniem podsystemu za-

rz�dzania Systemu IIP.

�� !

�"��

!#�� $� $%#$��&�

�# ��'��()

�*&+ ��,)��,�-��,��,,�)-

��"

��./�� !

��0 1

�"��

�& �2�3&$��! ��

��

�"��

�!#��

�"��

�!#��

�"��

�!#�-

��./��Krk

�� !

�"��

!#�� $� $%#$��&�

�# ��'��()

�*&+ ��,)��,�-��,��,,�)-

��"

��./�� !

��0 1

�"��

�& �2�3&$��! ��

��

�"��

�!#��

�"��

�!#��

�"��

�!#�-

��./��Krk

Rys. 3. Schemat logiczny podsystemu bezpiecze�stwa

Systemu IIP.

w�zeł IIP

w�zeł IIP

��

��

�"

��

w�zeł IIP

��

w�zeł IIP

��

�"

�"

Podsystemzarz�dzaniaSystemu IIP

(SNMPv3)

�� !��"��#$��%�

�� &'��%��(��%�

��

�� &'��%��

��)%��(

��

��

��

��

i/f w podsytemie

zarz�dzania

�3� �

3!1�3��

�3� �

��

��

�"

��

��

��

�"

��

��

�"

��

�"

��

��

SRE

Wylicza lokalne

metryki zaufania

s�siednich LSA na

podstawie cz�sto�ci

i wyceny zagro�enia

wykrytych anomalii

MSA

local security agent

master security agent

w�zeł IIP

w�zeł IIP

��

��

�"

��

w�zeł IIP

��

w�zeł IIP

��

�"

�"

Podsystemzarz�dzaniaSystemu IIP

(SNMPv3)

�� !��"��#$��%�

�� &'��%��(��%�

��

�� &'��%��

��)%��(

��

��

��

��

i/f w podsytemie

zarz�dzania

�3� �

3!1�3��

�3� �

��

��

�"

��

��

��

�"

��

��

�"

��

�"

��

��

SRE

Wylicza lokalne

metryki zaufania

s�siednich LSA na

podstawie cz�sto�ci

i wyceny zagro�enia

wykrytych anomalii

MSA

local security agent

master security agent

Rys. 4. Organizacja drugiej i trzeciej linii obrony:

akwizycja danych przez MSA.

��

��

MSA

metryki zaufania/reputacji

prezentowane poprzez podsystem zarz�dzania

��

�� reputacji

��

w�zeł IIP

��

��

SRE

w�zeł IIP

��

�3� �

��

�3� �

3!1�3��

Podsystem zarz�dzaniaSystemu IIP

(SNMPv3)

��

��

MSA

metryki zaufania/reputacji

prezentowane poprzez podsystem zarz�dzania

��

�� reputacji

��

w�zeł IIP

��

��

SRE

w�zeł IIP

��

�3� �

��

�3� �

3!1�3��

Podsystem zarz�dzaniaSystemu IIP

(SNMPv3)

Rys. 5. Organizacja drugiej i trzeciej linii obrony:

dystrybucja danych przez MSA.

Współpraca pomi�dzy LSA i MSA prowadzi do

wypracowania i dystrybucji globalnych metryk zaufania

i reputacji poszczególnych LSA w obr�bie całego Rów-

noległego Internetu; odpowiedni algorytm wraz z obja-

�nienami przedstawiono obrazowo w punkcie 6 (szcze-

góły matematyczne mo�na znale�� w [2], [6]). Dodat-

kowo na maszynie, na której pracował agent MSA, zo-

stał uruchomiony graficzny interfejs webowy prezentu-

j�cy aktualny poziom zaufania w�złów wirtualnych.

Informacje te mog� by� wykorzystane przez inne pod-

systemy Systemu IIP, np. zarz�dzania czy routingu.

Pó�niejsza integracja podsystemu bezpiecze�stwa

w �rodowisku PL-LAB nast�powała według schematu

przedstawionego na Rys. 6. Dla przeprowadzanych eks-

perymentów wyodr�bniono dwie sieci wirtualne: sie�

VLAN404 słu�yła do przenoszenia ruchu IIP chronione-

go przez HMAC w płaszczy�nie danych, podczas gdy

sie� VLAN403 słu�yła do zarz�dzania elementami pod-

systemu bezpiecze�stwa oraz do ich wzajemnej komuni-

kacji w celu przekazywania danych z monitoringu stanu

w�złów IIP pomi�dzy LSA i MSA.

Rys. 6. Schemat integracji z sieci� PL-LAB: sieci VLAN

komunikacji chronionej i zarz�dzania bezpiecze�stwem

(z lewej w�zeł krakowski, z prawej w�zeł wrocławski).


3. LOKALNE WYKRYWANIE ANOMALII

Moduły LAD w w�złach IIP (druga linia obrony).

przeciwdziała zagro�eniom, których nie jest w stanie

powstrzyma� mechanizm HMAC, tj. atakom typu for-

ging i ruffling (operuj�cych poprawnie sformatowanymi

IIP-PDU o niebezpiecznej semantyce b�d� zaburzonych

relacjach czasowych, niezgodnych ze specyfikacj� sta-

nowi�c� podstaw� wymiarowania sieci). Przedstawia to

symbolicznie Rys. 7.


��

��

��

��

��

��

��

��

� ��

��


forging

��

��

��

��

��

�*�� *��

0!#� $��$��

)-��"4

ruffling

LO ::1 54320

IPv6

*�+�,��$*�

'��'��

$*��,�$$-�

�" �"

SRE


��

��

��

��

��

��

��

��

� ��

��


forging

��

��

��

��

��

�*�� *��

0!#� $��$��

)-��"4

ruffling

LO ::1 54320

IPv6

*�+�,��$*�

'��'��

$*��,�$$-�

�" �"

SRE

Rys. 7. Lokalne wykrywanie anomalii.

Zastosowane podej�cia do wykrywania anomalii

mo�na podzieli� w zale�no�ci od rodzaju zagro�e�, jakie

sygnalizuj�, oraz algorytmów generuj�cych odpowiednie

alerty (alarmy) i wyliczone dla nich miary zagro�enia. W

proponowanej architekturze moduł LAD posiada wbu-

dowane algorytmy i metody w ramach dwóch uzupełnia-

j�cych si� podej��. Jedno z nich wykorzystuje wybrane

metody eksploracji danych do analizy SRE polegaj�cych

na odbiorze IIP-PDU o potencjalnie niebezpiecznej se-

mantyce, za� drugie wykorzystuje analiz� szeregów

czasowych reprezentuj�cych statystyki systemowe −

dane diagnostyczne z monitoringu ł�czy i wykorzystania

zasobów w�złów wirtualnych Systemu IIP. Aktualna

implementacja modułu LAD wykorzystuje pi�� ródeł

danych do analizy SRE. Cztery wykorzystywane s�

przez metody eksploracji danych, za� pi�te �ródło −

dost�p do statystyk systemowych uzyskiwany przy po-

mocy protokołu SNMP − jest wykorzystywane do anali-

zy szeregów czasowych. Rys. 8 przedstawia schema-

tycznie opisane �ródła danych oraz sposób ich przekaza-

nia do modułu LAD.

56$�7 ��

��

��

��

��

�*��

��

�"��

��

�89

�� 2��3� ��

��

StatystykiSystemowe

�� *�'�

5� !#��&�

$� $%#$��&�

��3!�

��#�� !+� & ��:3��

3!��

��;(� &*

3!��<� ! ��=-��

3!��<� ! ��=-��

Dane diagnostyczne

56$�7 ��

��

��

��

��

�*��

��

�"��

��

�89

�� 2��3� ��

��

StatystykiSystemowe

�� *�'�

5� !#��&�

$� $%#$��&�

��3!�

��#�� !+� & ��:3��

3!��

��;(� &*

3!��<� ! ��=-��

3!��<� ! ��=-��

Dane diagnostyczne

Rys. 8. �ródła danych o SRE oraz ich przekazywanie do

modułu LAD.

4. LAD – ANALIZA SRE

Spo�ród wymienionych wy�ej czterech �ródeł da-

nych dla analizy SRE dwa wykorzystuj� odpowiedni�

konfiguracj� standardowych mechanizmów systemu

Linux − zapor� ogniow� (firewall) oraz serwer SSH.

Informacje o naruszeniach polityki bezpiecze�stwa, takie

jak na przykład próby poł�cze� do zabronionych zaso-

bów, bł�dne logowania lub próby logowania do kont, s�

wysyłane do serwera syslog. Odpowiednia konfiguracja

tego serwera powoduje przesyłanie wszystkich interesu-

j�cych logów bezpo�rednio do modułu LAD. Trzecim

�ródłem danych jest zaimplementowany w ramach pro-

jektu serwer proxy SNMP, umo�liwiaj�cy dost�p do

niezabezpieczonych lokalnych zasobów SNMPv1 i

SNMPv2c za pomoc� protokołu SNMPv3. Podobnie jak

dla dwóch poprzednich �ródeł, logi dotycz�ce narusze�

polityki bezpiecze�stwa, na przykład zwi�zane z prób�

dost�pu do zabronionych fragmentów bazy MIB lub

u�yciem bł�dnych kluczy, s� przesyłane do modułu LAD

poprzez systemowy serwer syslog. W ten sposób wy-

krywane s� ataki z obszernej kategorii forging.

Czwarte �ródło danych zwi�zane jest z modułem

HMAC i w zwi�zku z tym dost�pne jedynie na dwóch

w�złach IIP posiadaj�cych karty NetFPGA. Pozwala ono

analizowa� bł�dy wykryte przez moduł HMAC, takie jak

u�ycie bł�dnego klucza, negatywna weryfikacja kodu

uwierzytelniaj�cego (MAC − message authentication

code), czy te� brak pola MAC, �wiadcz�ce o próbie

ataku injection, wzgl�dnie niepoprawna kolejno�� pakie-

tów lub wysłanie duplikatu ju� otrzymanego pakietu

�wiadcz�ce o próbie ataku resequencing/replay (dzi�ki

�ledzeniu numerów sekwencyjnych IIP-PDU, tak�e

zabezpieczonych przez MAC). Wszystkie tego rodzaju

zdarzenia SRE s� przekazywane poprzez odpowiednio

zdefiniowany interfejs diagnostyczny z karty NetFPGA i

za po�rednictwem przechwytuj�cej je aplikacji przeka-

zywane dalej do modułu LAD w postaci datagramów

UDP opakowanych w nagłówek protokołu IPv6.

Zaimplementowana metoda analizy SRE przy po-

mocy tzw. zbiorów cz�stych została opisana we wcze-

�niejszych pracach, por. np. [6]. W metodzie tej analizu-

je si� krotki atrybutów SRE zapisanych w logu SRE; w

zbiorze takich krotek wyszukuje si� zbiory cz�ste pod-

krotek, �wiadcz�ce o wyst�powaniu powtarzaj�cych si�

wzorców zachowa�. Testy zintegrowanego podsystemu

bezpiecze�stwa potwierdziły poprawno�� metody i nie-

wielki wzrost nakładów obliczeniowych w odniesieniu

do testów w konfiguracjach o połow� mniejszych (3 lub

4 w�zły z LSA i jeden z MSA), co pozwala mie� nadzie-

j� na skalowalno�� metody tak�e dla wi�kszych sieci.

5. LAD – ANALIZA SZEREGÓW CZASOWYCH

Ze wzgl�du na niepełne przedstawienie metody

szeregów czasowych w poprzednich publikacjach, zo-

stanie ona tutaj potraktowana nieco szerzej. Zaimple-

mentowana w module LAD metoda oceny poziomu

bezpiecze�stwa w�zła Systemu IIP korzysta z podej�cia

polegaj�cego na wykrywaniu warto�ci nietypowych

(anomalii) w szeregach czasowych opisuj�cych zmiany

charakterystycznych warto�ci stanu w�zła. Rezultat


oceny dokonanej przez moduł LAD przekazywany jest

nast�pnie do modułu odpowiedzialnego za obliczanie

poziomu zaufania dla elementów Systemu IIP. Zastoso-

wane w module LAD podej�cie do oceny poziomu bez-

piecze�stwa umo�liwia wykrycie szerokiego zbioru

zagro�e� takich jak np. próby zaburzania poprawnej

komunikacji pomi�dzy w�złami Systemu IIP poprzez

ruffling, czy te� wykrycie ruchu „paso�ytniczego”, który

jest generowany poprzez zło�liwe oprogramowanie w

wyniku eskalacji uprawnie� maszyny wirtualnej, b�d�

uzyskania nieuprawnionego dost�pu do w�zła IIP przez

intruza. Metoda analizy szeregów czasowych funkcjonu-

je w ramach podej�cia model-free, tj. abstrahuje od kon-

kretnych modeli zagro�e� i techniki naruszania bezpie-

cze�stwa w Systemie IIP, a przez to daje równie� mo�-

liwo�� wykrycia ataków, które nie zostały jeszcze ziden-

tyfikowane i opisane odpowiedni� sygnatur� (tzw. ataki

dnia zerowego). Analiza koncentruje si� na ocenie wpły-

wu nieuprawnionej aktywno�ci na obserwowalne warto-

�ci parametrów charakteryzuj�cych stan w�zła.

Dodatkow� korzy�ci� z takiego podej�cia jest mo�-

liwo�� ujednolicenia analizy zorientowanej na zagro�e-

nia bezpiecze�stwa oraz na diagnoz� niezawodno�ci

w�zła Systemu IIP. Rezultaty analizy modułu LAD do-

tycz�ce nietypowego wykorzystania zasobów mog�

zatem wskazywa� nie tylko na wyst�pienie celowych

ataków przeciw bezpiecze�stwu, ale równie� bł�dów

b�d� awarii w�złów i ł�czy Systemu IIP. Podej�cie takie

sytuuje si� w obr�bie podstawowej filozofii proponowa-

nej architektury bezpiecze�stwa Systemu IIP, w my�l

której metryki zaufania odzwierciedlaj� zarówno bezpie-

cze�stwo jak i niezawodno�� (security & trustiness).

5.1. Konfiguracja modułu LAD zorientowana na analiz� szeregów czasowych

Zaimplementowany w projekcie moduł LAD anali-

zuj�cy szeregi czasowe dostarcza szerokich mo�liwo�ci

konfiguracyjnych, które pozwalaj� dostosowa� jego

działanie do lokalnej specyfiki monitorowanego w�zła

jak i w sposób optymalny wykorzysta� mo�liwo�ci udo-

st�pniane przez inne moduły i podsystemy Systemu IIP.

Dane do analizy mog� by� dostarczane do modułu LAD

w dwojaki sposób. Pierwszy, lokalny sposób akwizycji

danych, korzysta z warto�ci udost�pnianych bezpo�red-

nio przez system operacyjny na którym został urucho-

miony moduł LAD. Druga metoda wykorzystuje proto-

kół SNMPv3. Dzi�ki zaimplementowanym mechani-

zmom jest mo�liwe pobieranie danych do analizy z bazy

MIB dowolnego urz�dzenia sieciowego, przez co moduł

LAD mo�e zdalnie ocenia� poziom bezpiecze�stwa

dowolnego elementu infrastruktury Systemu IIP.

Metoda analizy danych udost�pnianych lokalnie

daje mo�liwo�� oceny poziomu bezpiecze�stwa w�zła

Systemu IIP na podstawie obserwacji zmienno�ci liczby

bajtów lub IIP-PDU odbieranych b�d� wysyłanych przez

wskazany interfejs sieciowy. Metoda zdalnej akwizycji

danych z wykorzystaniem protokołu SNMPv3 daje mo�-

liwo�� analizy dowolnego elementu Systemu IIP, o któ-

rym informacje gromadzone s� w bazie MIB (np. po-

ziom zaj�to�ci pami�ci operacyjnej, liczba aktywnych

procesów itp.).

Konfiguracji podlega równie� sposób raportowania

wykrytych anomalii. Podstawowym elementem podlega-

j�cym konfiguracji jest adres głównego agenta bezpie-

cze�stwa Systemu IIP (MSA, Rys. 3 i 4), który przetwa-

rza informacje zebrane z modułów LAD i na tej podsta-

wie oblicza i udost�pnia informacje o poziomie zaufania

dla poszczególnych w�złów Systemu IIP. Moduł LAD

przekazuje do MSA informacj� w formacie:

"anomaly; <nodeID>; <timestamp>; <severity>; <prob-

ability>; <comment>",

gdzie „anomaly" oznacza typ komunikatu, „nodeID” jest

identyfikatorem ocenianego w�zła, „timestamp” jest

znacznikiem czasu w systemie UNIX, „severity” jest

liczbow� miar� wykrytego zagro�enia, „probability” jest

miar� cz�sto�ci wyst�powania danego typu anomalii w

ustalonym okresie czasu, za� „comment” zawiera dodat-

kowe informacje o anomalii. Warto�ci „severity” i „pro-

bability” ł�cznie okre�laj� poziom anomalii. W celu

ułatwienia kalibracji mechanizmu odpowiedzialnego za

szacowanie poziomu zaufania opcje konfiguracyjne

LAD umo�liwiaj� okre�lenie, czy poziom anomalii ma

by� warto�ci� binarn� ze zbioru {0, 1}, gdzie warto�� ‘0’

oznacza brak anomalii, za� warto�� ‘1’ oznacza wyst�-

pienie sytuacji anomalnej, czy te� warto�ci� z ustalonego

przedziału ci�głego. W tym drugim przypadku moduł

LAD wymaga okre�lenia warto�ci poziomu, powy�ej

którego anomalia b�dzie raportowana.

Podstawowymi elementami konfiguracji LAD, któ-

re wymagaj� podania warto�ci pocz�tkowych s� parame-

try pracy algorytmu wykrywania sytuacji anomalnych,

por. [2]. Parametry te pozwalaj� okre�li� długo�� okresu

obserwacji, okna przesuwnego i okresu zmienno�ci mo-

nitorowanego parametru, wag� bie��cej obserwacji oraz

obserwacji historycznych w wyra�eniu, na którego pod-

stawie wylicza si� warto�ci „severity” i „probability” [4].

5.2. Przykład analizy szeregów czasowych w �rodowisku PL-LAB

Moduł LAD oparty na analizie szeregów czaso-

wych został zainstalowany we wrocławskim w��le IIP,

dost�pnym poprzez infrastruktur� transmisyjn� rozpro-

szonej sieci badawczej PL-LAB (Rys. 9). W tym samym

w��le został umiejscowiony w�zeł wirtualny Równole-

głego Internetu PI-CAN, który został skonfigurowany do

wymiany tre�ci z analogicznymi w�złami IIP ulokowa-

nymi w Krakowie oraz Warszawie.

Rys. 9. Schemat w�zła IIP Wrocław.

Na potrzeby wst�pnej walidacji moduł LAD oparty

na analizie szeregów czasowych został skonfigurowany


do pracy lokalnej w Dom0 w�zła IIP. Jako �ródło da-

nych do analizy został wskazany interfejs sieciowy w�-

zła PI-CAN, za� jako analizowana cecha charakteryzuj�-

ca stan w�zła − liczba bajtów odbieranych przez w�zeł.

Szeroko�� okna przesuwnego została ustalona na 50

sekund, za� długo�� okresu obserwacji na 1000-krotno��

okna przesuwnego. Algorytm został skonfigurowany tak,

by dane pochodz�ce z bie��cej obserwacji były najbar-

dziej znacz�ce, tzn. miały najwi�kszy wpływ na szaco-

wan� warto�� poziomu anomalii zachowania w�zła;

osi�ga si� to poprzez odpowiednie ustawienie stałej

uczenia w algorytmie ruchomej �redniej.

Podczas typowej pracy w�zła PI-CAN ilo�� ode-

branych danych wahała si� mi�dzy 15kB a 35kB w trak-

cie trwania okna przesuwnego (Rys. 10). Jak wida� z

Rys. 11, moduł LAD szybko nauczył si� takiej charakte-

rystyki zachowania w�zła i po pi�ciu oknach przesuw-

nych warto�� poziomu anomalii była ju� niewielka.

Rys. 10. Pocz�tkowe 50 warto�ci obserwacji danych

odebranych z w�zła PI-CAN.

Rys. 11. Pocz�tkowe 50 warto�ci poziomu anomalii

w�zła PI-CAN

Po osi�gni�ciu granicy pierwszego okresu obser-

wacji, o czasie trwania równym 1000 oknom przesuw-

nym (Rys. 12), przy braku zmian w charakterystyce

pracy w�zła PI-CAN, tj. odbiorze danych ci�gle na po-

ziomie 15kB do 35kB w trakcie trwania okna przesuw-

nego, dało si� zaobserwowa� zmian� w raportowanym

poziomie anomalii (Rys. 13). Zmiana ta wynika z ró�nic

pomi�dzy poziomami transferu danych w pierwszym i

drugim okresie obserwacji, wywołanych ni�ej opisanym,

sztucznie wywołanym atakiem.

W oknach przesuwnych nr 1402 oraz 1406 zasymu-

lowano atak polegaj�cy na wstrzykni�ciu dodatkowej

porcji danych do w�zła PI-CAN (Rys. 14). W efekcie

mo�na było równie� zaobserwowa� gwałtowne zmiany

w poziomie anomalii zgłaszanym przez LAD (Rys. 15).

W zwi�zku ze skal� ataku poziom anomalny w�zła jest

raportowany o jedno okno przesuwne dłu�ej ni� miało

miejsce samo zaburzenie (okna przesuwne nr 1405-

1407). Uwidacznia si� tutaj wpływ chwilowych zabu-

rze� ruchu na raportowany poziom anomalii. Niemniej

jednak w przypadku, gdy atak nie jest kontynuowany,

za� obserwowany profil zachowania w�zła odpowiada

wcze�niejszym obserwacjom, równie� poziom anomalii

szybko wraca do typowych, niewielkich warto�ci (okna

przesuwne nr 1409 i dalsze).

Rys. 12. Warto�ci obserwacji w�zła CAN na granicy

pierwszego i drugiego okresu obserwacji

Rys. 13. Zmiana poziomu anomalii w�zła PI-CAN

na granicy pierwszego i drugiego okresu obserwacji

Rys. 14. Warto�ci obserwacji danych odebranych

z w�zła PI-CAN w trakcie symulowanego ataku.

Rys. 15. Warto�ci poziomu anomalii w�zła PI-CAN

w trakcie symulowanego ataku


6. SYSTEM REPUTACYJNY

6.1. Zasada działania W podsystemie bezpiecze�stwa Systemu IIP trzeci�

lini� obrony stanowi system reputacyjny opisany np. w

[2], [6]). Składa si� on z agenta MSA oraz agentów LSA

rozmieszczonych w w�złach IIP i skomunikowanych

pomi�dzy sob� oraz MSA za pomoc� zabezpieczonego

kryptograficznie protokołu SNMPv3. Dodatkowo baza

MIB zwi�zana z informacjami podsystemu bezpiecze�-

stwa jest dost�pna wył�cznie dla modułów LSA i MSA.

Oprócz wykrywania globalnych anomalii przez

moduł PI-AD na zasadach podobnych do przedstawio-

nych w punkcie 4, wyliczane s� dla innych wirtualnych

w�złów (b�d� ł�czy) metryki zaufania i reputacji. Doko-

nuje tego pokazany na Rys. 4 i 5 moduł REP na podsta-

wie raportów dostarczanych przez lokalne moduły LAD.

Rys. 16 obrazowo podsumowuje zasad� pracy systemu

reputacyjnego. Ocena poziomu anomalii wykrytych w

kontaktach z innymi w�złami IIP, tj. liczbowych miar

zwi�zanych z nimi zagro�e� (por. punkt 5), dokonywana

jest przez moduły LAD w kolejnych cyklach pracy i

normalizowana do warto�ci z zakresu [0, 1]. Dopełnienie

miary zagro�e� do 1 stanowi lokaln� metryk� zaufania w

odniesieniu do danego w�zła, raportowan� do modułu

REP w agencie MSA. Globalne metryki zaufania do

danego w�zła IIP wyliczane s� jako sumy metryk lokal-

nych raportowanych przez wszystkie LSA, wa�one repu-

tacjami raportuj�cych w�złów. Warto�ci reputacji wyli-

czane s� nast�pnie przy pomocy algorytmu ruchomej

�redniej i staj� si� wagami sumowania w kolejnym cyklu

pracy; zarazem za po�rednictwem podsystemu zarz�dza-

nia podlegaj� dystrybucji do poszczególnych LSA i

mog� tam stanowi� podstaw� rekonfiguracji polityki

bezpiecze�stwa, zarz�dzania, wyboru tras w płaszczy�-

nie danych Systemu IIP itp.

Rys 16. System budowy metryk zaufania i reputacji

pod kontrol� MSA: zasada pracy.

6.2. Dyskusja W niniejszej pracy, stanowi�cej podsumowanie

projektowania, implementacji i integracji podsystemu

bezpiecze�stwa z poziomem wirtualizacji zasobów sie-

ciowych Systemu IIP, warto zwróci� uwag� na niektóre

aspekty wyborów szczegółowych rozwi�za� w zakresie

systemu reputacyjnego, korygowanych w ró�nych eta-

pach projektu. Pierwszym z nich było przyj�cie, �e sys-

tem reputacyjny b�dzie działał nie na podstawie subiek-

tywnych rekomendacji dokonywanych okresowo przez

w�zły w stosunku do innych w�złów, lecz na podstawie

obiektywnej oceny zachowania w�złów s�siednich w

topologii Równoległego Internetu, dokonywanej na

podstawie pomiarów parametrów odbieranego ruchu.

Taki model zaufania i reputacji z jednej strony wymaga

zastosowania narz�dzi do analizowania odbieranego

ruchu (w naszym wypadku s� to moduły HMAC i LAD),

z drugiej za� pozwala na natychmiastowe zmiany lokal-

nych metryk zaufania (w przypadku wykrycia odpo-

wiednich zdarze� SRE) i odpowiedni� modyfikacj�

metryk reputacji poprzez algorytm ruchomej �redniej w

module REP. Ostatecznie zaproponowany system repu-

tacyjny mo�na wi�c zakwalifikowa� jako oparty na

obiektywnej wzajemnej walidacji w�złów (cross-

validation), poniewa� ostateczna warto�� metryk zaufa-

nia i reputacji zale�y od ocen w�złów maj�cych mi�dzy

sob� bezpo�redni kontakt.

Wa�n� zalet� walidacyjnego systemu reputacyjne-

go jest mo�liwo�� wykrywania przez MSA tzw. ataków

podprogowych, przeprowadzanych przez grup� w�złów

przej�tych przez intruzów przeciwko wybranemu w�-

złowi, b�d� lub przez jeden przej�ty w�zeł przeciwko

grupie w�złów. W alternatywnym rekomendacyjnym

systemie reputacyjnym lokalne metryki zaufania do

danego w�zła opieraj� si� tak�e na rekomendacjach

innych w�złów wypracowanych przez lokalne moduły

analogiczne do REP. W systemach takich atak podpro-

gowy mo�e zosta� zignorowany w cz��ci w�złów i w

konsekwencji niewykryty przez MSA. Zastosowany

system walidacyjny raportuje nawet najmniej znacz�ce

anomalie, zatem �aden atak nie zostanie zignorowany w

wyniku subiektywnych ocen w�złów.

Słabo�ci� systemu reputacyjnego w zaproponowa-

nej wersji jest jego scentralizowany charakter, tj. obec-

no�� pojedynczego punktu nara�enia w postaci główne-

go agenta MSA. Zablokowanie MSA lub jego wrogie

przej�cie mogłoby sparali�owa� działanie systemu repu-

tacyjnego. Mo�na jednak zauwa�y�, �e w takim przy-

padku podsystem zarz�dzania dysponuje informacjami

niezb�dnymi do odtworzenia MSA w nowej lokalizacji.

Jej wybór mo�e nast�pi� np. w drodze głosowania roz-

proszonego, na podstawie ostatnio dystrybuowanych

warto�ci metryk reputacji.

7. SCENARIUSZ OCHRONY KOMUNIKACJI W SIECI PI-CAN

W ramach testowania podsystemu bezpiecze�stwa

w �rodowisku PL-LAB przeprowadzono konfiguracj�

w�zła PI-CAN w Krakowie, jako rozbudow� istniej�ce-

go Równoległego Internetu PI-CAN. W rezultacie, za

po�rednictwem technologii Digital Living Network Al-

liance (DLNA) uzyskano zdalny dost�p do serwera tre�ci

takich jak filmy czy muzyka, zlokalizowanego w war-

szawskim w��le IIP i oferowanych na ��danie. Wybrane

tre�ci s� kierowane do przegl�darki Windows Media

Player lub Video LAN Client u�ytkownika. Dost�p do

sieci PI-CAN jest realizowany poprzez wirtualn� maszy-

n� dost�pow� HNM, która posiada interfejs komunika-

cyjny do sieci PI-CAN oraz interfejs do sieci lokalnej

IPv6, w której znajduje si� u�ytkownik. Szczegóły kon-

figuracyjne wykraczaj� poza ramy niniejszej pracy.

Po wybraniu ��danego materiału nast�puje jego

pobranie, podczas którego podsystem bezpiecze�stwa

obsługuje strumie� IIP-PDU w relacji pomi�dzy w�zła-

mi: krakowskim i wrocławskim, dokonuj�c przetwarza-

nia w kartach netFPGA 1G (Rys. 17). Odbywa si� to w

sposób niezauwa�alny dla u�ytkownika − wprowadzane

opó�nienia s� zaniedbywalne w porównaniu z natural-

nymi opó�nieniami transmisyjnymi w sieci PI-CAN.


Rys 17. Test podsystemu bezpiecze�stwa dla ochrony

komunikacji w sieci PI-CAN.

Wst�pne testy oraz demonstracja podsystemu bez-

piecze�stwa przeprowadzona podczas zamkni�cia pro-

jektu IIP w Warszawie w maju 2013 roku potwierdziły

poprawno�� działania proponowanej architektury bez-

piecze�stwa i podejmowanie wła�ciwych działa� w

przypadku wyst�pienia zdarze� SRE stwarzaj�cych

zagro�enia dla Systemu IIP.

8. WNIOSKI

Integracja zrealizowanego podsystemu bezpiecze�-

stwa w �rodowisku PL-LAB potwierdziła poprawno��

zało�e� przyj�tych podczas opracowywania architektury

bezpiecze�stwa. W szczególno�ci punktem wyj�cia w

projekcie było przekonanie, �e klasyczne podej�cie pe-

rymetryczne (typu firewall) staje si� niewystarczaj�ce i

niezb�dnych jest kilka linii obrony o charakterze zarów-

no proaktywnym jak i reaktywnym. Dotyczy to zwłasz-

cza �rodowisk zwirtualizowanych, w których model

intruza i mo�liwe wektory ataku s� trudne do przewidze-

nia, ponadto istnieje mo�liwo�� przej�cia nie tylko stru-

mienia danych, ale równie� wirtualnego ł�cza lub w�zła.

Wytworzone oprogramowanie LSA/MSA potwierdziło

zdolno�� wykrywania anomalii o zasi�gu lokalnym oraz

odzwierciedlania zagro�e� globalnych w metrykach

zaufania i reputacji w�złów wirtualnych.

Wskazana jest kontynuacja prac m. in. w kierunku

wy�szych przepływno�ci bitowych 10 Gbit/s, uelastycz-

nienia funkcji bezpiecze�stwa w Systemie IIP (uwzgl�d-

niaj�ca np. mo�liwo�� ochrony grupy lokalizacji, nie za�

tylko poszczególnych ł�czy i w�złów − podsystem bez-

piecze�stwa posiada wsparcie dla poł�cze� wielopunk-

towych, jednak wskutek ograniczonej dost�pno�ci kart

netFPGA był testowany wył�cznie w relacji pomi�dzy

dwoma w�złami IIP) oraz rozbudowy mechanizmów

budowy zaufania w kierunku ich rozproszenia i integra-

cji z podsystemem zarz�dzania.

PODZI�KOWANIA

Praca została wykonana w ramach projektu POIG

In�ynieria Internetu Przyszło�ci nr POIG.01.01.02-00-

045/09-00. Autorzy pragn� podzi�kowa� Łukaszowi

Dolacie i Radosławowi Krzywani za pomoc w

przygotowaniu i przeprowadzeniu eksperymentów,

Grzegorzowi Rzymowi za pomoc w konfiguracji w�zła

Xen oraz Andrzejowi B�bnowi za pomoc w integracji

podsystemu bezpiecze�stwa z PI-CAN. Dzi�kujemy te�

Michałowi Pleszkunowi i Rafałowi Demkiewiczowi za

długotrwał� pomoc i zaoferowane wsparcie.

SPIS LITERATURY

[1] W. Burakowski, H. Tarasiuk, A. B�ben, System IIP

for supporting ‘parallel internets (networks), FIA Me-

eting, Ghent [online] fi-ghent.fiweek.eu/files/2010/12/

1535-4-System-IIP-FIA-Ghent-ver1.pdf, 2010.

[2] K. Cabaj, G. Kołaczek, J. Konorski, P. Pacyna, Z.

Kotulski, Ł. Kucharzewski, P. Szałachowski, Security

architecture of the IIP System on resources virtualiza-

tion level, Telecommunication Review - Telecommuni-

cation News, Vol. 84(80), No. 8-9, pp. 846-851, 2011.

[3] K. Cabaj, Z. Kotulski, P. Szałachowski, G. Kołaczek,

J. Konorski, Implementation and testing of Level 2 secu-

rity architecture for the IIP System, Telecommunication

Review - Telecommunication News, Vol. 85(81), No. 8-

9, pp.1426-1435, 2012.

[4] J. Konorski, P. Pacyna, G. Kołaczek, Z. Kotulski, K.

Cabaj, P. Szałachowski, A Virtualization-Level Future

Internet Defense-in-Depth Architecture, CCIS, vol. 335,

Recent Trends in Computer Networks and Distributed

Systems Security, Part 1, pp. 283-292, Springer-Verlag,

Berlin Heidelberg New York 2012. ISBN 978-3-642-

34134-2 (DOI: 10.1007/978-3-642-34135-9_29)

[5] J. Konorski, J. Kasperek, P. Pacyna, D. Rzepka, W.

Romaszkan, M. Rupi�ski, J. Zimnowoda, A. Kamisinski,

P. Rajda, Implementacja sprz�towa modułu HMAC-

SHA-1 do ochrony komunikacji w systemie IIP, Tele-

communication Review - Telecommunication News

(Przegl�d Telekomunikacyjny), Vol. 85(81), No. 8-9, pp.

1418-1425, 2012.

[6] J. Konorski, P. Pacyna, G. Kołaczek, Z. Kotulski, K.

Cabaj, P. Szałachowski, Theory and implementation of a

virtualisation level Future Internet defence in depth

architecture, Int. J. Trust Management in Computing and

Communications 2013 (to appear).


PTiWT - Zeszyt 8-9, 2013 -...

Documents

Transcript of PTiWT - Zeszyt 8-9, 2013 -...