Upload
ngotuyen
View
214
Download
1
Embed Size (px)
Citation preview
Jerzy Konorski
Wydział ETI, Politechnika Gda�ska
80-233 Gda�sk, ul. Narutowicza 11/12,
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,
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
w�zeł IIPw�zeł IIP
������
���������
�������
��������
��������
���
�� �����������
���� ����
� ������������
�������� ��������
Infrastruktura transmisyjna
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.
w�zeł IIPw�zeł IIP
������
���������
�������
��������
��������
���
�� �����������
���� ����
� ���
Bezpieczne ł�cze IIP
�������� ��������
Infrastruktura transmisyjna
injection
����
��������
������������
��������
��������
reseq/replay
PDU
PI- CAN-PDUIIP-PDU
w�zeł IIPw�zeł IIP
������
���������
�������
��������
��������
���
�� �����������
���� ����
� ���
Bezpieczne ł�cze IIP
�������� ��������
Infrastruktura transmisyjna
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).
PRZEGL D TELEKOMUNIKACYJNY * ROCZNIK LXXXVI * i WIADOMO CI TELEKOMUNIKACYJNE * ROCZNIK LXXXII * nr 8-9/2013 1032
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.
w�zeł IIPw�zeł IIP
������
���������
�������
��������
��������
���
�� �����������
���� ����
� ���
�������� ��������
Infrastruktura transmisyjna
forging
����
��������
������������
��������
��������
�*��� �*���
0!#� $��$���
)-������"4
ruffling
LO ::1 54320
IPv6
*�+�,��$*�
'����'�����
$*��,�$$-�
�" �"
SRE
w�zeł IIPw�zeł IIP
������
���������
�������
��������
��������
���
�� �����������
���� ����
� ���
�������� ��������
Infrastruktura transmisyjna
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
PRZEGL D TELEKOMUNIKACYJNY * ROCZNIK LXXXVI * i WIADOMO CI TELEKOMUNIKACYJNE * ROCZNIK LXXXII * nr 8-9/2013 1033
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
PRZEGL D TELEKOMUNIKACYJNY * ROCZNIK LXXXVI * i WIADOMO CI TELEKOMUNIKACYJNE * ROCZNIK LXXXII * nr 8-9/2013 1034
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
PRZEGL D TELEKOMUNIKACYJNY * ROCZNIK LXXXVI * i WIADOMO CI TELEKOMUNIKACYJNE * ROCZNIK LXXXII * nr 8-9/2013 1035
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.
PRZEGL D TELEKOMUNIKACYJNY * ROCZNIK LXXXVI * i WIADOMO CI TELEKOMUNIKACYJNE * ROCZNIK LXXXII * nr 8-9/2013 1036
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).
PRZEGL D TELEKOMUNIKACYJNY * ROCZNIK LXXXVI * i WIADOMO CI TELEKOMUNIKACYJNE * ROCZNIK LXXXII * nr 8-9/2013 1037