P

OSF – (ang. Passive OS Fingerprinting) jest procesem mającym na celu identyfikację systemu operacyjnego (ang. OS), który jest używany przez zdalny host. Zaletą pasywnego (ang. passive) fingerprintingu jest jego niewykrywalność dla systemów IDS (ang. Intrusion Detection System) ze względu na fakt iż aplikacja służąca do POSF’gu nie wysyła żadnych danych na terenie badanej sieci.

Negatywną stroną tego rozwiązania jest potrzeba bezpośrednio połączenia z badanym hostem lub badanego hostu z nasłuchującą aplikacją POSF’gu. Technika fingerprintingu opiera się na zależności różnych stanów TCP/IP przy różnym (nie)określeniu pól nagłówków lub ustawieniu ich wartości. W przypadku mechanizmu autoryzacji – POSF może być bardzo przydatną funkcją…

Evgeniy Polyakov napisał specjalny moduł dla iptables o nazwie osf pozwalający na pasywną detekcję zdalnego systemu operacyjnego oraz podjęcie stosownych akcji. Porównuje on m.in. dane ze stosu TCP/IP: WSS (ang. Window size), MSS (ang. Maximum segment size), TTL (ang. Time to live), DF (ang. Don’t fragment flag) pobrane z pakietu SYN z załadowanymi dynamiczne sygnaturami systemów operacyjnych (ang. OS fingerprints).

Od wersji 2008_07_01 moduł OSF współpracuje jedynie z xtables, które zostały włączone do kodu jądra Linuksa od wersji 2.6.16, dlatego jest niezbędne posiadanie równej lub nowszej wersji jądra (wraz z włączonym wsparciem dla xtables) oraz zainstalowany pakiet iptables (rozwiązanie to zostało przetestowane na jądrze 2.6.27.7 oraz iptables w wersji 1.4.2). Proces instalacji tego modułu przebiega następująco:

tar -zxvf osf-latest.tar.gz
cd osf-latest
make
make lib
make bin

Po kompilacji zostanie stworzona współdzielona biblioteka libipt_osf.so, którą należy skopiować do katalogu innych bibliotek współdzielonych iptables:

cp libipt_osf.so /usr/libexec/xtables
ldconfig

Następnie należy zainstalować ładowalny moduł ipt_osf.ko do pracującego jądra oraz za pomocą narzędzia load załadować sygnatury systemów do tablicy modułu:

insmod ./ipt_osf.ko
./load ./pf.os /proc/net/netfilter/osf

Aktualne sygnatury systemów operacyjnych można pobrać ze strony OpenBSD lub narzędzia p0f (plik p0f.fp). Jeśli pragniemy wyczyścić załadowane wpisy wystarczy wydać polecenie:

echo -en FLUSH > /proc/net/netfilter/osf

Kolejnym etapem jest stworzenie odpowiedniej reguły iptables:

iptables -A INPUT -i eth0 -p tcp --dport 22 -m osf --genre Linux --log 0 --ttl 1 --connector -j ACCEPT
iptables -A INPUT -i eth1 -p tcp --dport 22 -m osf --genre Windows --log 2 --ttl 0 --connector -j REJECT

Powyższe reguły umożliwiają:

• 1. Umożliwia łączenie się systemom Linux (--genre) z usługą SSH (--dport 22) na interfejsie eth0 (-i eth0) logując tym samym wszystkie pasujące i niepasujące sygnatury (--log 0) oraz porównując czy wartość pola TTL jest mniejsza niż w sygnaturze danego systemu (--ttl 1 – działa dla sieci WAN). Jeśli to możliwe moduł OSF użyje złącza jądra (ang. kernel connector – --connector) do rejestrowania wszystkich zdarzeń.
• 2. Zabrania łączenie się systemom Windows (--genre) z usługą SSH (--dport 22) na interfejsie eth1 (-i eth1) logując tym samym wszystkie pasujące sygnatury (--log 2) oraz porównując wartość pola TTL z sygnaturą danego systemu (--ttl 0 – działa dla sieci LAN). Jeśli to możliwe moduł OSF użyje złącza jądra (ang. kernel connector – --connector) do rejestrowania wszystkich zdarzeń.

Więcej informacji na temat connector’a można znaleźć w dokumentacji źródłowego drzewa jądra Linuksa – Documentation/connector/connector.txt (od wersji 2.6.14). W celu przetestowania modułu OSF dokonano połączenia z usługą SSH systemu z załadowanymi powyższymi regułami iptables. Połączenia dokonano z trzech systemów: Linux (WAN), Windows (LAN) oraz OpenBSD (LAN i WAN z zmodyfikowanymi opcjami TCP tak by nie odpowiadały one żadnym wzorcom załadowanych sygnatur systemów operacyjnych). W pierwszym przypadku użytkownik został dopuszczony do zalogowania się poprzez usługę SSH z Internetu oraz następujące wpisy pojawiły się w logach systemowych (/var/log/messages):

Jan  3 12:22:52 slackwars kernel:
ipt_osf: Linux [google::Linux (Google crawlbot)] :
198.176.102.39:51829 -> 192.168.0.1:22 hops=10
Jan  3 12:22:52 slackwars kernel:
ipt_osf: Linux [2.4::Linux 2.4/2.6 < = 2.6.7] :
198.176.102.39:51829 -> 192.168.0.1:22 hops=10
Jan  3 12:22:52 slackwars kernel: ipt_osf:
Linux [2.6:.1-7:Linux 2.4/2.6 < = 2.6.7] :
198.176.102.39:51829 -> 192.168.0.1:22 hops=10
Jan  3 12:22:52 slackwars kernel: ipt_osf:
Linux [2.6:8:Linux 2.6.8 and newer (?)] :
198.176.102.39:51829 -> 192.168.0.1:22 hops=10

Ze względu na parametr --log 0 w logach pojawiła się również informacja o próbie połączenia z nieznanego systemu (zmodyfikowany OpenBSD):

Jan  3 12:20:03 slackwars kernel:
ipt_osf: Unknown: win: 5840, mss: 1414, totlen: 60, df: 0, ttl: 51 :
02 04 05 86 04 02 08 0A 03 F7 08 6D 00 00 00 00 01 03 03 02
80.196.47.26:55015 -> 192.168.1.11:22

W drugim przypadku użytkownik został niedopuszczony do zalogowania się poprzez usługę SSH z sieci lokalnej oraz następujące wpisy pojawiły się w logach systemowych (/var/log/messages):

Jan  3 12:26:52 slackwars kernel:
ipt_osf: Windows [XP:RFC1323:Windows XP/2000 (RFC1323 no tstamp)] :
192.168.1.15:3269 -> 192.168.1.1:22 hops=0
Jan  3 12:26:52 localhost kernel:
ipt_osf: Windows [2000:RFC1323:Windows XP/2000 (RFC1323 no tstamp)] :
192.168.1.15:3269 -> 192.168.1.1:22 hops=0

Ze względu na parametr --log 2 w logach nie pojawiła się informacja o próbie połączenia z nieznanego systemu (zmodyfikowany OpenBSD). Jak widać moduł OSF nie tylko pozwala nam na identyfikację systemów, które łączą się z naszą zaprą sieciową, ale również umożliwia nam stworzenie systemu autoryzacji na podstawie rodzaju systemu, który owego połączenia dokonuje. Jak można szybko się domyślić, fakt ten można wykorzystać do stworzenia własnej sygnatury na podstawie, której będzie przeprowadzana autoryzacja do usług, którym chcemy zapewnić bezpieczniejszy dostęp.

Więcej informacji: Moduł OSF, p0f