|
W części trzeciej tej serii artykułów zobaczyliśmy, że Snort rejestrował właściwie wszystkie czynności, jakie się wydarzyły w czasie, gdy serwer sieciowy był wykorzystywany przez hakera. Jednak nie zdołał wykorzystać programu kluczowego, który został tam przeniesiony przez hakera. Tak jak wspomniałem w części trzeciej, IDS nie jest narzędziem gwarantującym bezpieczeństwo sieci. IDS jest tak naprawdę wzorem pasującym do programu. Te wzory są podpisami, które zostały napisane w tym celu i – wraz z upływem czasu – są aktualizowane. I chociaż producenci IDS starają się, aby zgromadzić w miarę szeroki zbiór podpisów, nadal da się wiele udoskonalić.
Źródło: www.windowsecurity.com
Tłumaczenie: Tymon Górski, Poznań
Istnieje szeroki wachlarz złośliwego oprogramowania, którego analityk ds. bezpieczeństwa sieci powinien być świadomy i którego powinien się obawiać. Jednym z takich przykładów są rootkity, a w przypadku tego artykułu jest to rootkit FU. Innymi przykładami mogą być trojany czy backdoor, taki jak netcat. I dlatego naprawdę sensownym rozwiązaniem byłby rozwój podpisów dla złośliwego oprogramowania, takiego jak to przed chwilą wspomniane. Nauczymy się tutaj, jak napisać podpis Snort IDS. Jak wkrótce zobaczysz, nie jest to wcale takie trudne.
Pisanie podpisów Snort
Najlepszym sposobem, aby czegoś się nauczyć, jest zrobienie tego, a także posiadanie pod ręką przykładu, z którego można się uczyć lub wykorzystać jako podstawę czegoś, co działa. Mając to na uwadze, przyglądnijmy się podpisom Snort poniżej, które wziąłem z domyślnego zestawu zasad.
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"SCAN ipEye SYN scan"; flow:stateless; flags:S; seq:1958810375; reference:arachnids,236; classtype:attempted-recon; sid:622; rev:7;)
Przyjrzyjmy się dokładnie powyższemu podpisowi, ponieważ pomoże on nam zbudować własny, jeśli zrozumiemy jego sedno. Pierwsze pole jest zupełnie proste, ponieważ mówi po prostu alert.
tcp this relates to the protocol type in use
$EXTERNAL_NET is used to state traffic coming in from an external source ie: Internet
any this says that any port applies ie: no specific port stated
--> the director symbol show the flow of traffic in this case from external to internal
$HOME_NET is used to identify the person’s network
(msg:”SCAN ipEye……….) will be the message printed out when the signature fires
flow:stateless is used to have the signature fire regardless of the state of the session
flags:S is used to specify exact TCP flags or flag combinations
seq:1958810375 is used to look for a specific TCP sequence number
reference:arachnids,236 is used to identify a specific signature in the Arachnids IDS database
classtype:attempted-recon is used to denote what classtype the signature belongs to
sid:622 is a value used to uniquely identify Snort signatures
rev:7 is used to identify the revision number for the signature
Tak więc, mając tę informację pod ręką, jesteśmy teraz gotowi, aby spróbować zbudować własny, niestandardowy podpis Snort, a następnie sprawdzić go, aby potwierdzić jego efektywność. Dobrym podpisem do opracowania byłby taki dla rootkita FU, który był używany w tej serii artykułów. Na czym go jednak zbudować? Czy posiada on jakieś cechy do zdefiniowania? Czy używa on ustalonego portu czy ma unikatowy numer sekwencyjny TCP? W zasadzie cokolwiek, co się wydaje dla niego unikatowe. Pamiętając o tym, że wszystko co jest dla niego unikatowe, jest nazwą, która ma w sobie fu.exe. Jest to dobry początek do budowania naszego podpisu Snort.
Zbudujmy nasz własny podpis Snort
Wykorzystamy kilka z tych samych pól w naszym próbnym podpisie, ale jak widać powyżej nie użyjemy ich wszystkich.
alert ip any any -> any any (msg:"FU rootkit transfer or usage"; content:”fu.exe”; rev;1)
To, co widać powyżej, to w zasadzie schematyczny podpis dla rootkita FU. Wiemy, że dwójkowy plik fu.exe był w czasie włamania przesyłany do serwera sieciowego ofiary jako protokół TFTP. Naprawdę mówimy o tym wszystkim, co go identyfikowało, poza samym jego użyciem. W pakiecie poniżej widać ciąg tekstowy ASCII pliku fu.exe.
15:06:12.109375 IP (tos 0x0, ttl 128, id 451, offset 0, flags [none], proto: UDP (17), length: 43) 192.168.111.23.1032 > 192.168.111.17.69: 15 RRQ "fu.exe" octet
0x0000: 4500 002b 01c3 0000 8011 d985 c0a8 6f17 E..+..........o.
0x0010: c0a8 6f11 0408 0045 0017 c560 0001 6675 ..o....E...`..fu
0x0020: 2e65 7865 006f 6374 6574 0000 0000 .exe.octet....
Nie dodałem tutaj external_net ani home_net, aby uprościć to jak najbardziej. Zawartości pliku snort.conf mogą się różnić, więc czasami upraszczanie jest najlepszym podejściem, a przynajmniej do momentu, gdy pisanie podpisów będzie szło nam sprawniej. Zauważysz także, że w moim podpisie brak jest numerów portów, przepływu instrukcji, kombinacji flag oraz innych tego typu pól. Mimo że powoduje to, że podpis jest raczej luźny, nadal powinien być skuteczny. Ponadto zawartość treści zasadniczej pliku fu.exe powinna być wystarczająco unikatowa, aby zminimalizować jakiekolwiek błędy pierwszego rodzaju, które mogą się pojawić podczas przypadkowych połączeń kodu ASCII w treści zasadniczej innych legalnych pakietów. W tym miejscu pójdźmy dalej i wstawmy naszą zasadę do innej i sparsujmy plik pakietu binarnego tego włamania.
[**] [1:0:1] FU rootkit transfer or usage [**]
[Priority: 0]08/09-15:40:58.171875 192.168.111.23:1029 -> 192.168.111.17:4321
TCP TTL:128 TOS:0x0 ID:665 IpLen:20 DgmLen:742 DF
***AP*** Seq: 0xAA205B6C Ack: 0x2039E4DD Win: 0xFA2D TcpLen: 20
Sukces! Nasz podpis Snort zadziałał. Teraz – jak wcześniej wspomniałem – jest to w miarę skromny podpis, który nie ma w sobie zbyt dużo innych pól, aby zminimalizować błędy pierwszego rodzaju. Jeżeli zechcesz spróbować wprowadzić inne pola zasad Snort, sugerowałbym, żebyś zajął się samym rootkitem FU trochę bardziej, a potem sprawdził wynikły z niego pakiet śledzący. Pozwoli Ci to poszukać dalszych cech do zdefiniowania. Jeśli jakieś znajdziesz, możesz dołączyć je do powyższego podpisu lub może to być pomocne przy pisaniu innych określonych podpisów, odnoszących się do rootkita FU.
Podsumowanie
To, czym zajmowaliśmy się w tej czteroczęściowej serii artykułów, to przyglądnięcie się na sposób, w jaki haker może potencjalnie sprofilować Twoją sieć. Mając pod ręką te informacje, poznaliśmy sposób, w jaki ten sam haker może wykorzystać sieć, a następnie zastosować dalsze strategie. Te wszystkie czynności pozostawiają jednak ślady typu „tell-tale” na poziomie pakietu. Te same ślady mogą zostać wykorzystane do budowy podpisów IDS. Nie każde włamanie do sieci będzie oparte na dobrze znanych narzędziach, takich jak Nmap, czy znanych rootkitach, takich jak rootkit FU. To, co należy wtedy zrobić, to spróbować wymyśleć inne podpisy, które wyłapią typową czynność hakera.
Pisanie podpisów jest jednak tylko połową batalii, musisz także zapewnić, że będą one działały i nie będą powodowały zbyt wielu błędów pierwszego rodzaju. Jeśli podpis wywoła zbyt wiele przypadków błędów, prawdopodobnie zostaną one zignorowane przez analityka. Nauczenie się jak pisać podpisy jest procesem pouczającym, wymagającym czasu oraz ćwiczeń. Nie zniechęcaj się, ponieważ – jak zauważyłeś – pisanie ich nie jest aż tak trudne. Mam szczerą nadzieję, że ta seria artykułów była pomocna i zawsze oczekuję Waszych reakcji. Do następnego razu!
|
