P

odsłuchiwanie ruchu sieciowego najczęściej kojarzy się nam z systemami typu: IDS/IPS lub narzędziami takimi, jak: tcpdump. Głównie programy te wykorzystywane są z różnych uzasadnionych powodów np. ochrona sieci lub rozwiązywanie problemów sieciowych. Czasami jednak proces ten może zostać użyty przez złośliwe oprogramowanie lub atakującego w celu kradzieży informacji, czy też aktywacji uśpionych tylnych wejść do systemu. Na szczęście za pomocą bezpośredniego dostępu do pliku /proc/net/packet możemy szybko zidentyfikować procesy powiązane z gniazdami pakietów. Tego typu gniazda (ang. sockets) służą do odbierania lub wysyłania surowych pakietów na poziomie sterownika urządzenia sieciowego (warstwa 2 OSI ; najczęściej karty sieciowej) pozwalając na bardziej bezpośrednią interakcję ze stosem sieciowym niż standardowe gniazda Berkeley w warstwie 4’tej (np. AF_INET / AF_INET6 + SOCK_STREAM / SOCK_DGRAM). Nas będzie interesować typ gniazda albo SOCK_RAW (dla surowych pakietów zawierających nagłówek warstwy łącza), albo SOCK_DGRAM (dla pakietów przetworzonych z usuniętym nagłówkiem warstwy łącza):

root@darkstar:~# cat /proc/net/packet
sk               RefCnt Type Proto  Iface R Rmem   User   Inode
ffff8f34c7d7d000 3      3    88cc   2     1 0      998    6666
ffff8f34c7d7c000 3      3    88cc   3     1 0      998    6685
ffff8f34c0b80000 3      3    0003   0     1 0      0      8767
ffff8f34c5243800 3      2    0003   0     1 0      0      9350

Nas będzie interesować ostatnia kolumna, czyli Inode, która pozwoli nam na identyfikację procesów i ich właścicieli. Pozostaje nam przeszukanie procfs pod numerach ze wspomnianej kolumny, aby otrzymać numery identyfikacyjne procesów odpowiedzialnych za otwarte gniazda pakietów:

root@darkstar:~# ls -al /proc/*/fd/* 2> /dev/null | egrep '(6666|6685|8767|9350)'
lrwx------ 1 root            root            64 Sep 1 19:44 /proc/1053/fd/3 -> socket:[8767]
lrwx------ 1 root            root            64 Sep 1 19:44 /proc/1067/fd/5 -> socket:[9350]
lrwx------ 1 systemd-network systemd-network 64 Sep 1 19:44 /proc/404/fd/18 -> socket:[6666]
lrwx------ 1 systemd-network systemd-network 64 Sep 1 19:44 /proc/404/fd/19 -> socket:[6685]

Powyżej widzimy dwa procesy (ID: 404) systemd przechwytujące ruch sieciowy (często są to protokoły wykrywania sieci i urządzeń sieciowych – tutaj LLDP [88cc]). Mamy również dwa kolejne podejrzane procesy (ID: 1053 oraz 1067), które wymagają zbadania – tym bardziej, że ich właścicielem jest administrator systemu i mają wartość protokołu 0003, który reprezentuje ETH_P_ALL. Oznacza to, że tego typu gniazdo pakietów skonfigurowane jest do przechwytywania każdego pakietu przechodzącego przez dany interfejs sieciowy (tryb promiscuous). Kiedy program tworzy gniazdo pakietów z protokołem ETH_P_ALL, w zasadzie mówi jądru systemu: „- Daj mi kopię wszystkich surowych ramek danych, które widzisz na tej karcie sieciowej”. Jest to podstawowa funkcja wykorzystywana przez narzędzia do analizy sieci:

root@darkstar:~# ls -al /proc/1053/cwd
lrwxrwxrwx 1 root root 0 Sep 16 19:57 /proc/1053/cwd -> /root

root@darkstar:~# ls -al /proc/1053/exe
lrwxrwxrwx 1 root root 0 Sep 16 19:57 /proc/1053/exe -> /usr/sbin/netsniff-ng

root@darkstar:~# cat /proc/1053/comm
netsniff-ng

root@darkstar:~# cat /proc/1053/cmdline
netsniff-ng--inany--filterport 80--jumbo-support--ascii-V

root@darkstar:~# cat /proc/1053/maps
62484cd10000-62484cd15000 r--p 00000000 08:02 533368  /usr/sbin/netsniff-ng
75fc96400000-75fc966c5000 r--p 00000000 08:02 683102  /usr/share/GeoIP/GeoIP.dat
75fc91c00000-75fc95c00000 rw-s 00000000 00:08 8767    socket:[8767]

root@darkstar:~# ls -al /proc/1067/cwd
lrwxrwxrwx 1 root root 0 Sep 16 20:10 /proc/1067/cwd -> /root

root@darkstar:~# ls -al /proc/1067/exe
lrwxrwxrwx 1 root root 0 Sep 16 20:10 /proc/1067/exe -> /usr/bin/tcpflow

root@darkstar:~# cat /proc/1067/comm
tcpflow

root@darkstar:~# cat /proc/1067/cmdline
tcpflow-iany-cport80

root@darkstar:~# cat /proc/1067/maps
60590f0bd000-60590f0c5000 r--p 00000000 08:02 531829  /usr/bin/tcpflow
7c0bf2b0a000-7c0bf2d0a000 rw-s 00000000 00:08 9350    socket:[9350]

Oczywiście, aby przyśpieszyć ten proces, możemy użyć takich poleceń jak lsof oraz ss. Programy te są przydatne, jeśli są już zainstalowane w systemie, ale istnieją pewne zastrzeżenia. Po pierwsze – jeśli ich nie ma w systemie nie możemy ich zainstalować, ponieważ zmienimy stan badanego systemu i możemy nadpisać dowody kompromitacji systemu. Po drugie niektóre warianty złośliwego oprogramowania często przechwytują wywołania systemowe i filtrują wyniki programów, aby ukryć się przed takimi narzędziami, więc istnieje ryzyko, że nic nie ustalimy. Niemniej warto znać ich zastosowanie:

root@darkstar:~# lsof -p 1053
COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF   NODE NAME
netsniff- 1053 root  cwd    DIR    8,2     4096 655362 /root
netsniff- 1053 root  txt    REG    8,2   250136 533368 /usr/sbin/netsniff-ng
netsniff- 1053 root  mem    REG    0,8            8767 socket:[8767]
netsniff- 1053 root    3u  pack   8767      0t0    ALL type=SOCK_RAW

root@darkstar:~# lsof -p 1067
tcpflow 1067 root  cwd       DIR    8,2     4096 655362 /root
tcpflow 1067 root  txt       REG    8,2   581064 531829 /usr/bin/tcpflow
tcpflow 1067 root  mem       REG    0,8            9350 socket:[9350]
tcpflow 1067 root    5u     pack   9350      0t0    ALL type=SOCK_DGRAM

root@darkstar:~# ss -0 -p
Netid  Recv-Q  Send-Q  Local Address:Port  Peer Address:Port  Process
p_raw  0       0              LLDP:enp0s3              *      users:(("systemd-network",
                                                                       pid=404,fd=18))
p_raw  0       0              LLDP:enp0s8              *      users:(("systemd-network",
                                                                       pid=404,fd=19))
p_raw  0       0                 *:*                   *      users:(("netsniff-ng",
                                                                       pid=1053,fd=3))
p_dgr  0       0                 *:*                   *      users:(("tcpflow",
                                                                       pid=1067,fd=5))

Teraz już wiemy, jak /proc/net/packet może pomóc nam ujawnić podsłuchujące ruch sieciowy procesy, a nawet może ujawnić rozbieżność z tym, co widzimy w wynikach ze standardowych narzędzi.

Więcej informacji: Detecting Packet Sniffing Malware on Linux, List packet sniffers

S

pójrzmy na poniższy nagłówek HTTP przechodzący przez urządzenie BIG-IP firmy F5 Networks zawierający ciasteczko powodujące przywiązanie klienta do jednego serwera z backendu:

HTTP/1.1 403 Forbidden
Date: Mon, 17 Oct 2016 07:56:53 GMT
Server: Apache
Content-Type: text/html; charset=iso-8859-1
Set-Cookie: BIGipServerCRM-entryhttps_WAF-Pool=872768522.15168.0000; path=/
Transfer-Encoding: chunked

Zamieńmy liczbę 872768522 na wartość heksadecymalną: 3405640A, rozbijmy ją od tyłu na bloki i ponownie wróćmy do wartości decymalnych:

0A = 10
64 = 100
05 = 5
34 = 52

Hmm… czyżby właście wyciekła informacja o wewnętrznym adresie serwera 10.100.5.52? Zróbmy analogiczną konwersję z liczbą 15168 (3B40), która pewnie oznacza port do komunikacji:

403B = 16443

Finalnie otrzymujemy: 10.100.5.52:16443. Dość ciekawą informacją jest fakt, że samo F5 Networks ujawnia, jak zaszyfrować i rozszyfrować takie dość nieprzemyślane ciasteczko.

Więcej informacji: Overview of BIG-IP persistence cookie encoding

W

końcu znalazłem trochę czasu, aby za radą Hendrego zobaczyć, co tak naprawdę wychodzi z mojego telefonu (aktualnie korzystam z radioodbiornika wyposażonego w Android w wersji 6.0). Analogicznie, jak w poradniku przekierowałem streaming pakietów (na razie tylko UDP) z routera Mikrotik do komputera, na którym nasłuchiwał Wireshark filtrując tylko ruch z telefonu. Pierwszym adresem, jaki pojawił się na ekranie po włączeniu WiFi na urządzeniu był:
[ czytaj całość… ]

S

krótów takich jak: RPS, RFS, XPS nie trzeba przedstawiać chyba nikomu – jeśli tak to warto się z nimi dogłębnie zapoznać. Zostały one wdrożone w wersji jądra 2.6.35 – 2.6.38 przez Toma Herberta z teamu Google i są aplikacyjną implementacją RSS (ang. Receive-Side Scaling). Na dedykowanych serwerach fizycznych do natłoku ruchu sieciowego możemy wykorzystać sprzętowe wsparcie kart sieciowych i mechanizmy do rozładowywania kolejek. Niestety na serwerach wirtualnych (Xen, KVM) cała ta praca spada na przypisany do maszyny procesor(y).
[ czytaj całość… ]

W

ięc stworzyliśmy swoją niezawodną aplikację / system / usługę (* niepotrzebne skreślić) i jesteśmy gotowi na produkcję. Wszystko logicznie zostało zaprogramowane – wyłączyliśmy / włączyliśmy – przetestowane. Jednak cykl życia aplikacji w prawdziwej dżungli IT wygląda trochę inaczej.
[ czytaj całość… ]

W

2005 roku Peter Smith napisał książkę o bezpieczeństwie sieciowym systemu Linux.

„ISBN:1584503963 Linux networks are becoming more common, but security is often overlooked. Using a mix of theory and practical techniques, this text teaches administrators how to install and use security applications, and why they are necessary.”

Po ośmiu latach jego wydawca niestety wyleciał z branży, a sam autor stał się wolny od restrykcji publikacji swojego materiału, więc zdecydował się on na publikację całej książki online. Oczywiście od 2005 roku wiele zmieniło się pod względem mechanizmów bezpieczeństwa w Linuksie – dlatego niektóre informacje mogą być przestarzałe (wówczas SELinux i bezpieczeństwo WiFi były w powijakach, a MD5 był uważany za rozsądnie silny mechanizm szyfrowania). Mimo to możemy w niej znaleźć wiele przydatnych i istotnych informacji.

Więcej informacji: Linux Network Security

N

etdiscover jest aktywno/pasywnym narzędziem do przeprowadzania rekonesansu w sieci lokalnej (LAN) głównie zaprojektowanym dla sieci bezprzewodowych, np. po przeprowadzeniu udanego wardrivingu w celu orientacji w sieci. Bez problemu jednak może zostać użyte w sieciach przewodowych opartych o huby, routery i przełączniki.
[ czytaj całość… ]