 Today I'm going to talk about the SNOT tool, which is an open-source intuition detection system tool. SNOT has the ability to perform real-time traffic analysis on the network. SNOT can perform protocol analysis, content-matching, content-searching, and many things. It can also be used to detect probes or attacks, such as general service attacks or distributed general service attacks, ports, etc. So you can use SNOT in your network so that it keeps an eye on the traffic and generates an alarm when there is an unusual activity in your network, where typically SNOT should be deployed. This is your internal network over here, which is connected to the firewall, then to the switch, then to the router, and then to the internet. So where should be the SNOT deployed? Because SNOT has to perform real-time traffic analysis. It means that it should be able to capture all the traffic that is flowing into the network. So the ideal place to install SNOT is at the switched level with a mirrored port over here, because all the traffic flows through the switch into the, all the incoming and upcoming traffic flows through the switch into the network. So we have to just mirror the port at the switch and connect and install the SNOT on that port. I have a video of the SNOT where it does, where it involves how to write rules, and then about the SNOT report. So we are going to run SNOT through command line. Here we have to specify this command for running the SNOT. The information about how to run the SNOT and install the SNOT is available on their website. There is one PDF they have provided, and all the information is given in it. So we have to run the SNOT using this command, and I am going to run it in the verbose mode. Verbose mode means it is going to capture all the traffic that is originating or coming into my system, and then display it on the command prompt. So it is now running, SNOT is running. So as you can see, there are many packets that you can see on the console. So as you can see, there is a UDP, there is a UDP packet, and it has many information about the header such as TTL, time to live, length, etc. And it also shows many information such as the total packets that were processed. It also shows that the alerts that were generated during this session, when the SNOT was running. So right now, the alerts that were generated are zero because we haven't written any rule or something that will make us not to generate an alert. So right now, there are zero alerts. And it also shows the total TCP sessions and UDP sessions. So UDP sessions are 42, and TCP sessions are zero. This is a simple interface provided by the SNOT, SNOT report here. This interface can be used by the user to view the alerts that are generated by the SNOT when it is running. So basically when the SNOT generates an alert, it writes into the database, and this interface, this application reads that data from the database and shows here. Now we will see how to write a rule in the SNOT. Suppose I want to capture all the UDP traffic that is originating from my system, and then I want to be alerted, means I want to just see that these are the UDP packets that were originated from my system. So for that, we have to first write a rule and then run a SNOT. So let's say how to write a rule. So there is one local dot rules file that is provided by the SNOT. There you can write your own rules as you want and then run this one. First of all, what I said was I want to write a rule that will capture all the UDP traffic that was originated from my system and then alert it into generate an alert for it. So the rule can be written as, since I want to be alerted when there is a UDP traffic that is to be generated, that is going to be generated, I write alert. Then you have to specify the destination, the source address, source IP address that is home network and you have to specify the port from where this UDP traffic is originating and you have to specify then the destination of the IP address. Then it can be any and any port. I am saying that I want to be alerted when there you have to even specify the protocol that you want to capture. So in this case, since you want to capture UDP packets and you want to be alerted, you should specify UDP and then this is the source IP address from where it is originating and this is the host on the source, sorry port on the host. This is the destination IP address by any means any IP address, UDP traffic from my system to any IP address and destined to any port. So alert UDP home network any to any any, this is the rule header. The rule in this now consists of two parts rule header and rule options. So what we have written over here is this is the rule header. After rule header, we have to write the rule options. So you have to write the rule options in angular brackets, round brackets. So message UDP traffic generated SID, SID means identifier that will uniquely identify that rule and then its revision number. So I will explain this part. This part is the rule option. Here I have said that message UDP traffic generated. It means that when this conditions match, I will get a message UDP traffic is generated and SID means identifier of this rule which will uniquely identify this rule and revision means just this revision first one. So this is what the rule I have written over there and after writing this rule we will run this not again and let us see whether this not is able to, whether it is able to capture that UDP traffic and show it on the snot report. So I am going to run the snot again, snot is running and then I just visit some random website Google, gmail, yahoo.com and then I just stop the snot. Then I look at the alerts that were generated by the snot. 48 alerts were generated and 48 alerts were logged. So let us see whether they were logged into the snot report or not. So as you can see there is a chart over there and it specifies how many alerts were generated for the TCP, UDP, ICMP, port scan. I think it is very small to be visible for you. It says that 48 UDP alerts were generated and it also provides the information about it, about the alert over here, details by signature over here, this one. And if you click on the summary it will give the information of the source IP address and the destination IP address of this UDP traffic. Now suppose I want to write a rule that will detect a particular SYNFLUD attack. So what is a SYNFLUD attack? SYNFLUD attack is a attack in which the attacker generates too many TCP requests with the SYNFLUX set to 1 and these requests are then sent to the server. So this is what the SYNFLUD attack is. So I am going to write a rule that will detect this SYNFLUD attack. So I want to be alerted when there is a possibility of SYNFLUD attack. So alert TCP because TCP packets are sent from any IP address and any port to my home network and port 80. Port 80 because right now my system is acting like a server and another attacker is performing SYNFLUD attack on it. So I am listening on port 80 and message possible SYNFLUD. Now we will specify the conditions that will identify this SYNFLUD attack. In SYNFLUD attack the SYNFLUX is set to 1. So here you can specify that you have to specify flags and you have to specify which flags are set to 1. In this case I will specify S because S means SYNFLUD and you have to specify only those flags which are set to 1. So in this case flags S and then I am applying a detection filter track by source means look at a specific source a specific IP address count 20 seconds 60. So what this specifies is detection filter track by source count 20 and second 60. It says that if from the same IP address I get 20 or more packets within the duration of 60 seconds then you should alert me and then just specify the SID that will uniquely identify that rule and revision one. So have you understand this rule? I will explain again alert when there is a TCP packet from any source and any port to my home network on port 80 such that SYNFLUX is set to 1 and detection filter that is if from the same IP address I get 20 or more packets within the duration of 60 seconds then alert me. So this is the rule that I have written in that local dot rules file. Now I will again run the SNOT. So right now the SNOT is running on my system and then we send many too many TCP packets with the SYNFLUX set to 1 from another system to my system and I just check that whether it is able to detect it or not. So while the SNOT was running we kept sending to TCP SYNFLUX packets to my system and then after sometime I will just about the SNOT. Now if the SNOT sees that the TCP packets are originating from a particular source IP address with the SYNFLUX set and at a rate of 20 or more packets per minute then it will raise an alarm because it is an onset of SYNFLUX attack. So and then we can see it in the SNOT report. It has generated a report where it says that for the specific SID that I had mentioned SID unique identifier of the rule it has generated a 323 alerts yeah this 323. You can see more information in the summary. So as you can see it is specifying the sources that has triggered this attack signature and the destination that has received this attack signature. So the source that was triggering this attack signature was the system that was sending the TCP packets and the destination was my system. So it says that there were total 380 alerts that were generated. We will talk more about SNOT because we are running out of time. We will talk more about SNOT in the context of metasploit which will be done tomorrow afternoon. So tomorrow there are no lecture sessions there are only two labs one lab in the morning on forensics etc and one lab in the afternoon okay so we will see you tomorrow.