Wykrywanie skanowania dzięki iplog
Napisał: Patryk Krawaczyński
21/09/2004 w Bezpieczeństwo Brak komentarzy. (artykuł nr 7, ilość słów: 1639)
I
plog jest programem logującym ruch w sieci. Obsługuje on takie protokoły jak TCP, UDP i ICMP. Dzięki tej zdolności jego kompatybilność pozwala na wykrywanie skanowania określonych przez nas portów takimi metodami jak: TCP port scan, TCP Null scan, FIN scan, TCP SYN scan, TCP “Xmas” scan, UDP scan (opis poszczególnych metod skanowania możemy znaleźć sekcji “Ataki internetowe”). Dodatkowo potrafi on wykryć przeprowadzenie takich ataków jak: “Smurf” (przy użyciu pakietów UDP oraz ICMP), ICMP ping flood oraz bogus TCP flag (używanego przez skanery w celu wykrywania rodzaju systemu operacyjnego jaki jest używany na danej maszynie).
Prawie wszystkie wyżej opisane metody skanowania (pozwalające na rozeznanie jakie usługi oferuje dany serwer) jak i ataków (powodujących częściowe lub całkowite zablokowanie poprawnego działania serwera) nie pozostawia żadnych śladów aktywności w logach systemowych (należą do typu stealth). Dlatego nie posiadając dodatkowego oprogramowania pozasystemowego, które posiada zdolność wykrywania takich zdarzeń, nie jesteśmy w stanie stwierdzić czy ktoś poddaje infiltracji nasz host, lub po powodzeniu ataku nie jesteśmy w stanie określić skąd prawdopodobnie został on zainicjonowany. Iplog, który możemy zaliczyć do reaktywnych środków takich jak IDS (ang. Instrusion Detection System – System Wykrywania Intruzów) jest prostym narzędziem pozwalającym na logowanie wszelkich aktywności ruchu sieciowego, nawet tych “ukrytych” (warto wspomnieć, że bardziej zaawansowany program tego typu jakim jest PortSentry nie zawsze loguje aktywność skanowania typu FIN oraz NULL). Po ściągnięciu źródeł programu możemy przejść do jego instalacji:
gunzip iplog-2.2.3.tar.gz tar -xvf iplog-2.2.3.tar rm iplog-2.2.3.tar cd iplog-2.3.3 ./configure make make check make install
Po wydaniu wyżej wymienionych komend zostanie przeprowadzona konfiguracja sprawdzająca posiadanie przez system niezbędnych składników do poprawnej kompilacji i działania programu. Katalog, w którym na zostać zainstalowany program zdefiniowany standardowo zostanie na /usr/local/sbin (oprogramowanie dodatkowe), a następnie zostanie wykonana kompilacja, sprawdzenie poprawności kompilacji, oraz instalacja poszczególnych elementów programu (pliku wykonawczego oraz stron manualnych). Po poprawnej instalacji wymagane jest określenie opcji konfiguracyjnych, które zdefiniują pracę programu. W tym celu musimy utworzyć plik konfiguracyjny iplog.conf (touch /etc/iplog.conf), oraz umieścić w nim odpowiednie wpisy:
user nobody # Uruchom się z prawami danego użytkownika. group nobody # Uruchom się z prawami danej grupy. pid-file /var/run/iplog/iplog.pid # Lokacja pliku pid dla iplog. logfile /var/log/iplog # Lokacja pliku log dla iplog, gdzie będzie zapisywana aktywność ruchu sieciowego. facility log_daemon priority log_info # Sposób oraz piorytet jaki ma przyjąć iplog podczas zapisu logów. interface eth0,ppp0 # Interfejs lub interfejsy, na których na pracować (nasłuchiwać) iplog. set log_ip true # Włącz zapisywanie numerów IP. set log_dest true # Włącz zapisywanie docelowych adresów otrzymywanych pakietów. set ignore_dns true # Ignoruj ruch sieciowy pochodzący z hostów zawartych w /etc/resolv.conf. set frag true # Włącz detekcję ataków typu IP fragment. set smurf true # Włącz detekcję ataków typu Smurf. set bogus true # Włącz detekcję pakietów TCP z ustawioną fałszywą flagą (bogus flag probe test). set fin_scan true # Włącz detekcję skanowania typu TCP FIN. set syn_scan true # Włącz detekcję skanowania typu TCP SYN. set udp_scan true # Włącz detekcję skanowania i flodowania typu UDP. set portscan true # Włącz detekcję skanowania protokołem TCP. set xmas_scan true # Włącz detekcję skanowania Christmas Tree. set null_scan true # Włącz detekcję skanowania NULL. set traceroute true # Włącz detekcję wykonywania traceroute. set fool_nmap true # Włącz mechanizm oszukania programów nmap i queso wykonujących rozpoznanie systemu operacyjnego. Efektem ubocznym włączenia tej opcji jest także spowodowanie, że większość skanowania ukrytego (stealth) wykonywanego przez program nmap zawiedzie. set syn_flood true # Włącz detekcję SYN Flood. set ping_flood true # Włącz detekcję Ping Flood. set verbose true # Włącz szczegółową procedurę zapisywania w pliku dziennika.
Po wstępnej konfiguracji musimy jeszcze stworzyć katalog /var/run/iplog (mkdir /var/run/iplog), w którym będzie przechowywany plik z numerem identyfikacyjnym procesu iplog, uczynić go właścicielem tego samego użytkownika, z którego prawami wystartował program (chown nobody:nobody /var/run/iplog) oraz nadać mu odpowiednie prawa pozwalające na modyfikację jego zawartości właśnie tylko temu użytkownikowi (chmod 750 /var/run/iplog). Następnie dopisujemy wywołanie programu do któregoś ze skryptów startowych – zazwyczaj do rc.local (echo /usr/local/sbin/iplog >> /etc/rc.d/rc.local). Po restarcie systemu w celu upewnienia się czy Iplog uruchomił się bez żadnych problemów wydajemy komendę: “ps auxw|grep nobody” oraz przeglądamy pierwsze wpisy w jego pliku dziennika (cat /var/log/iplog).
Oto przykład zastosowania programu iplog. Przykładowy serwer został poddany technice skanowania typu TCP stealth scanning (skanowanie ukryte) – do przeprowadzenia tej techniki został wykorzystany sławny program nmap w wersji 3.00. Dodatkową opcją jaka została użyta podczas testu to próba identyfikacji systemu operacyjnego skanowanego celu (nmap -sS -O localhost). Poniżej znajduje się zapis raportu sporządzonego przez program nmap po udanym przeprowadzeniu skanowania:
Starting nmap V. 3.00 ( www.insecure.org/nmap/ ) Interesting ports on localhost (127.0.0.1): (The 1591 ports scanned but not shown below are in state: closed) Port State Service 11/tcp open systat 22/tcp open ssh 23/tcp open telnet 37/tcp open time 79/tcp open finger 113/tcp open auth 139/tcp open netbios-ssn 512/tcp open exec 513/tcp open login 514/tcp open shell Remote operating system guess: Linux Kernel 2.4.0 - 2.5.20 Uptime 0.122 days (since Wed Feb 11 19:20:40 2004) Nmap run completed -- 1 IP address (1 host up) scanned in 6 seconds
Po wykonaniu operacji sprawdzających przez program nmap, zostały przeglądnięte standardowe dzienniki logów systemowych w poszukiwaniu aktywności związanej ze skanowaniem serwera. Oczywiście żadne takie adnotacje nie zostały znalezione, ze względu na rodzaj użytej techniki skanowania. Nmap bezproblemowo wyświetlił listę otwartych portów oraz odgadł system operacyjny na skanowanym hoście. Test ten został powtórzony, jednak tym razem przez jego wykonaniem został uruchomiony program iplog. Oto raport programu nmap:
Starting nmap V. 3.00 ( www.insecure.org/nmap/ ) Interesting ports on localhost (127.0.0.1): (The 1591 ports scanned but not shown below are in state: closed) Port State Service 11/tcp open systat 22/tcp open ssh 23/tcp open telnet 37/tcp open time 79/tcp open finger 113/tcp open auth 139/tcp open netbios-ssn 512/tcp open exec 513/tcp open login 514/tcp open shell No exact OS matches for host (http://www.insecure.org/cgi-bin/nmap-submit.cgi). TCP/IP fingerprint: SInfo(V=3.00%P=i386-slackware-linux-gnu%D=2/11%Time=402A7391%O=11%C=1) TSeq(Class=RI%gcd=2%SI=1C54F9%IPID=Z%TS=100HZ) TSeq(Class=RI%gcd=1%SI=38A92B%IPID=Z%TS=100HZ) TSeq(Class=RI%gcd=1%SI=38A955%IPID=Z%TS=100HZ) T1(Resp=Y%DF=Y%W=7FFF%ACK=S++%Flags=AS%Ops=MNNTNW) T2(Resp=Y%DF=Y%W=100%ACK=O%Flags=BUAPRSF%Ops=) T2(Resp=Y%DF=N%W=0%ACK=O%Flags=BUAR%Ops=) T2(Resp=Y%DF=Y%W=100%ACK=O%Flags=BUARSF%Ops=) T3(Resp=Y%DF=Y%W=100%ACK=O%Flags=BUAPRSF%Ops=) T3(Resp=Y%DF=Y%W=7FFF%ACK=S++%Flags=AS%Ops=MNNTNW) T4(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=) T5(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=) T6(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=) T7(Resp=Y%DF=Y%W=100%ACK=O%Flags=BUAPRSF%Ops=) T7(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=) PU(Resp=Y%DF=N%TOS=C0%IPLEN=164%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E) Uptime 0.123 days (since Wed Feb 11 19:20:40 2004) Nmap run completed -- 1 IP address (1 host up) scanned in 12 seconds
Pierwszą zmianą jaką możemy zaobserwować to brak jasnej odpowiedzi w stosunku, co do systemu operacyjnego, który jest zainstalowany na skanowanym hoście. Iplog wygenerował mylący fingerprint – czyli sygnaturę pozwalającą na rozpoznanie zdalnego lub lokalnego systemu operacyjnego. W dodatku w jego dzienniku systemowym została odnotowana aktywność przeprowadzenia skanowania daną techniką pochodząca z danego źródła:
Feb 11 19:25:09 TCP: SYN scan detected to localhost (127.0.0.1) [ports 530,761,142,344,210,491,22321,1827,851,2500,...] from localhost \ (127.0.0.1) [port 63683]
Tak więc zyskaliśmy małą przewagę nad zamaskowaniem naszego systemu operacyjnego, oraz świadomość że nasz serwer został poddany wstępnej infiltracji prowadzącej do przeprowadzenia konkretnego ataku. Jedyną wadą programu iplog jest brak jakiejkolwiek interwencji w stosunku do powstrzymania aktualnego, lub przyszłego skanowania przeprowadzanego z danego adresu. Jedyną rzeczą jaka nam pozostaje to systematyczne przeglądanie jego logów systemowych oraz własna interwencja w przypadku występowania anomalii.
Więcej informacji: Plik: INSTALL, man iplog, iplog.conf, iplog