W

nawiązaniu to artykułu „Fire(wall)walking – spacer po zaporze ogniowej” warto również wspomnieć o narzędziu noszącym nazwę tcptraceroute. Jest to przerobiona implementacja standardowego traceroute, która używa pakietów TCP. Jak zauważył jego autor – problemem zapewnienia standardu bezpieczeństwa w Internecie jest jego niestandardowe używanie.
czytaj całość »

P

oniżej przedstawiam listę zakresów numerów IP, których masowe skanowanie wiąże się z większym ryzykiem niż tylko e-mail ostrzegający od / do administratora serwera. Wiąże się to z faktem iż należą one do różnych agencji rządowych – głównie USA:
czytaj całość »

S

canlogd jest kolejnym programem dzięki, któremu możemy posiadać rozeznanie czy ktoś poddaje nasz system skanowaniu. Autorem scanlog’a jest ekspert od zabezpieczeń o pseudonimie Solar Designer. Scanlogd wyróżnia się prostotą instalacji i obsługą. Choć posiada proste mechanizmy wykrywania skanowania przy pomocy protokołu TCP potrafi dostarczyć nam niezbędnych informacji o próbie przeprowadzenia wywiadu na naszym systemie. Poza tym jest to bardzo mały program nie zużywający większych ilości pamięci oraz procesora, działający na różnych systemach operacyjnych. Aby w pełni wykorzystać możliwości programu będą nam potrzebne biblioteki poza systemowe. Oczywiście program można skompilować bez żadnych dodatkowych bibliotek, ale zaleca się, aby w systemie były one zainstalowane. Mowa jest tu o typowo sieciowych bibliotekach takich jak: libpcap, libnids i libnet. Lokalne kopie tych bibliotek możemy znaleźć na domowej stronie scanlog’a.

W zależności od bibliotek, które posiadamy w systemie, możemy skompilować program scanlogd na trzy różne sposoby:

• Bez użycia wymienionych wyżej bibliotek – program wykorzysta surowe gniazda (raw sockets);
• Z użyciem wszystkich trzech bibliotek, co pozwoli nam monitorować ruch w całej sieci oraz manipulację pofragmentowanymi pakietami
• Z użyciem wyłącznie jednej biblioteki libpcap – jednak nie jest to zalecane przez autora programu.

Instalację zaczynamy od ściągnięcia oraz rozpakowania programu:

gunzip scanlogd.tar.gz
tar -xvf scanlogd.tar
rm scanlogd.tar
cd scanlogd

Jeśli się zdecydowaliśmy na surową wersję programu wydajemy polecenie: make linux. W przeciwnym przypadku musimy na początku zainstalować biblioteki zaczynając od libpcap, która jest wymagana przez dwie pozostałe. Jest ona rozwijana przez twórców narzędzia tcpdump (które występuje w pakietach instalacyjnych Slackware). Następnie musimy skompilować bibliotekę libnet. Na sam koniec będziemy mogli zainstalować w systemie libnids (pod warunkiem, że poprzednie dwie są zainstalowane). Wszystkie trzy biblioteki kompilujemy standardowo:

./configure --prefix=/usr
make
make install

Po poprawnej instalacji możemy skompilować program z obsługą wszystkich bibliotek (make libnids) lub tylko z obsługą libpcap (make lipcap). Po kompilacji jesteśmy zmuszeni do ręcznej instalacji programu, ze względu na to, że plik Makefile naszego programu nie posiada sekcji install:

cd ~root/scanlogd
cp scanlogd /usr/local/sbin
gzip scanlogd.8
cp scanlogd.8.gz /usr/local/man/man8

Następnie musimy stworzyć użytkownika scanlogd, z którego prawami program scanlogd będzie uruchamiany:

useradd -d /none -s /dev/null scanlogd

Istotnymi są, aby katalog o tej nazwie nie istniał, a powłoka nie umożliwiała logowanie się do systemu. Po tych wszystkich czynnościach możemy uruchomić program poleceniem: scanlogd. W celu sprawdzenia czy program został uruchomiony i działa w tle wydajemy polecenie: ps -u scanlogd. Jeśli chcemy, aby uruchamiał się on na starcie systemu dodajemy jego wywołanie do demona /etc/rc.local (echo „/usr/local/sbin/scanlogd” >> /etc/rc.local). Możemy także stworzyć demona zarządzającego scanlog’iem – /etc/rc.d/rc.scanlogd:

#!/bin/sh
# Start/stop/restart scanlogd.

# Start scanlogd:
scanlogd_start() {
  if [ -x /usr/local/sbin/scanlogd ]; then
    echo "Starting Scanlogd daemon:  /usr/local/sbin/scanlogd"
    /usr/local/sbin/scanlogd
  fi
}

# Stop scanlogd:
scanlogd_stop() {
  killall scanlogd
}

# Restart scanlogd:
scanlogd_restart() {
  scanlogd_stop
  sleep 1
  scanlogd_start
}

case "$1" in
'start')
  scanlogd_start
  ;;
'stop')
  scanlogd_stop
  ;;
'restart')
  scanlogd_restart
  ;;
*)
  echo "usage $0 start|stop|restart"
esac

Następnie dodajemy jego wywołanie do skryptu /etc/rc.d/rc.inet2:

if [ -x /etc/rc.d/rc.scanlogd ]; then
  /etc/rc.d/rc.scanlogd start
fi

Teraz wystarczy tylko poddać testom nasz mały detektor. Poniżej zawarto logi wygenerowane przez program scanlogd, który wykrył skanowanie. Skanowanie odbyło się z lokalnej maszyny, przy użyciu programu nmap, który został uruchomiony kolejno z flagami: -sS -sT -sF -sX -sN -sR. Są to kolejne metody skanowania oferowane przez program nmap, które za każdym razem zostały wykryte przez scanlogd.

Jun 11 09:37:30 darkstar scanlogd: 127.0.0.1 to 127.0.0.1
ports 706, 67, 549, 1520, 4144, ..., f??pauxy, TOS 00 @09:37:30
Jun 11 09:39:40 darkstar scanlogd: 127.0.0.1 to 127.0.0.1
ports 363, 1012, 326, 545, ..., f??pauxy, TOS 00, TTL 64 @09:39:40
Jun 11 09:42:17 darkstar scanlogd: 127.0.0.1 to 127.0.0.1
ports 16959, 236, 969, 890, 1488, ..., ?s?pauxy, TOS 00 @09:42:17
Jun 11 09:49:24 darkstar scanlogd: 127.0.0.1 to 127.0.0.1
ports 589, 44, 315, 757, 740, 477, ..., ?s??a?xy, TOS 00 @09:49:24
Jun 11 09:50:40 darkstar scanlogd: 127.0.0.1 to 127.0.0.1
ports 424, 6101, 3999, 1488, 65301, ..., fs?pauxy, TOS 00 @09:50:40
Jun 11 09:51:11 darkstar scanlogd: 127.0.0.1 to 127.0.0.1
ports 7003, 248, 5305, 1469, 693, ..., f??pauxy, TOS 00 @09:51:11

Warto wspomnieć, że przy użyciu skanowania wykorzystującego protokół UDP, program nie odnotował żadnej aktywności. Choć scanlogd nie posiada mechanizmów mylących próbę detekcji systemu lub blokujących kolejne próby, jak również wykrywania skanowania przy użyciu innych protokołów takich jak UDP czy ICMP – świetnie nadaje się do monitorowania pojedynczych hostów oraz malutkich sieci lokalnych. Może być z pewnością wykorzystany na serwerze, który oferuje usługi oparte wyłącznie na protokole TCP/IP.

Więcej informacji: scanlogd, tcpdump, packetfactory, Phrack Issue 53, art nr 13

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