 Good afternoon, I welcome you to the afternoon session of and in this session we will have a demo of SNOT. So, SNOT is basically a network sniffer logger and intrusion detection system. Its logger and sniffer function are similar to that of wire shock. So, we will only be focusing on intrusion detection part of SNOT. As an intrusion detection system, SNOT captures packets from the network and matches them against some conditions defined by us and generates an alert if the conditions are met. These conditions we define in SNOT rules which we will see in a while. This is a setup in which SNOT has to be installed in a network. You can see there is a router which is connected to internet and there is a firewall which is connected to the internal network and there is a switch in the middle which has a mirrored port on which SNOT has to be connected. This setup is such that all the traffic that is passing through the switch can be monitored by the SNOT. We have given you a text file which says how to run SNOT. It has the commands to run SNOT and also barnyard. Barnyard is a backend tool which is used to transfer the alerts generated from logs to databases so that we can easily view them. The first command we have it runs barnyard. You have to run this in a terminal and keep that terminal open. The next command is for running SNOT. When you run SNOT, there is an option of Ethernet interface. Here in the given command the Ethernet interface is it's 0. You have to check on your own system what is the interface there. Type ifconfig in your terminal and find out what is the interface and replace that interface with it's 0. I am sorry replace 0 with that interface in the command and also we will have a SNOT interface which is running on the local host. You can view it using this address that is given in the bottom on that file how to run SNOT. So coming back to the demo, first we will see how do we detect port scan using SNOT. As Serres already told port scan is a process by which an attacker tries to figure out what services are running on the victim's server which ports are open which OS is running. For detecting ports scan using SNOT, we don't have to write any specific rules because SNOT has already provided a pre-processor which does all the detection. We only have to switch on that pre-processor. For doing that we will have to edit a file SNOT.config. It is located in the location user slash local slash SNOT slash etc. As you can see there is a file SNOT.config in that location. We open that file and search for port scan. As you see there is a line which is commented out that says pre-processor as a port scan. So this is the directory which enables port detection of port scanning. We uncomment that line and we save this file. Here we see that there is an option of log file. There we can change where we want to we want the logs to be generated. Here it is given a var slash log slash SNOT. The log file will be generated there. We save this file and then we have to restart SNOT. We copy this command and run it on a terminal. We have here we have replaced it 0 to its 5 because that was the interface in my system. Now SNOT has started running. Now we will do a port scan on our system from some other system. That other system is the host which is running our virtual machine. This is the IP of virtual machine. We will go to Windows that is the host and in nmap tool we will give the IP of virtual system and press enter. Now nmap will take some time to finish. Now the results of port scan have come. You can see the scanned IP was this and it shows that host is up. It is showing 999 ports are closed and one port is open that is TCP. TCP on STTP and it also shows the OS that is Ubuntu. Now as port scan has been done SNOT must have detected that someone had tried to figure out what ports are open here. I mean tried to figure out the port scan. So let us go to the log and check there. Log was present in the directory var slash log. There is a directory called SNOT there. As we can see a file has been created. We open that file. In that file we can see that the first log is of TCP port scan. It was done on this time and the attackers IP was 160.242 and victim that is our virtual machine. Its IP was 160.247. The next log is for UDP port sweep and then for UDP port scan. Next we are going to see how we write rules. As I have already said rules are the conditions against which the packets are matched. Rules are located in the location user slash local slash SNOT slash rules. When you list this directory you can see that there are already so many files present. These files are the rule files that have been downloaded from a SNOT rules website. You can search on Google and go to SNOT rules website and download these rules. However you can also write our own custom rules that I am going to show. For writing our local rules we have to open file local dot rules. For this demo I have already written some rules but all are commented out. I will uncomment the most the simplest rule of all. A rule has two parts header and options. The highlighted part is header. Header tells SNOT which packets it has to look into. The first field in a header is action. Here we can see the action is alert. This means SNOT will generate an alert and lock that packet. Apart from alert the other options that we can give are log that won't generate an alert. It will only lock the packet and pass that will simply ignore the packet. The next field is protocol. Here the protocol is TCP. That means that this rule is applicable only on TCP packets. The next fields are IP and port of source. And then IP and port of destination. These are the sources and destinations of packets that have to be seen. And here NE is a wild card which will match against NE IP and NE port. For the destination IP we have given the IP of our virtual machine. So, that was the header part. The other part is options. The first option we have is message. It says what that rule does. And next option is SID. It is a unique identifier of the rule. Then we have rev that stands for revision. The revision of this rule is 1. So, what this rule will do is whenever it receives any TCP packet which is coming from any source on with any port to our machine it will generate an alert. It is basically a dummy rule. Similarly we will have another rule which will generate an alert for UDP packets. After this we save the file and exit. Now we will have to restart Snot. When Snot has started we will go to our browser and open some random web pages to create connections. After that is then we kill Snot. And yeah this is the tab which is running Barnyard. It shows that these were the alert generated which have been read from the log and transferred to database. The Barnyard does these things. Now we will go to the interface, web interface of Snot. We copy this address and paste it on our browser. In that interface we can see that two types of alerts were generated for the two rules that we uncommended from a local.rules file. The first alert is alert shows UDP detected. We can click on the summary and see the alerts in detail. As you can see the source IP of those packets are shown here along with the FQDN. It is fully qualified domain name. Similarly for TCP also we can see the summary. There were so many TCP connections. So now we are moving to a content keyword which is an option we can give in the rules. We will again open the local.rules file. We comment the previous rules and uncomment the new rule that we are going to see. The header part of this rule is almost the same except the options part. In options we have added a new keyword content which has a value some site. This will tells Snot that it has to generate an alert whenever a packet comes which has which contains this string in its payload, this string some site. Apart from giving a simple string we can have hex values instead. The hex values are enclosed within pipes. As you can see this is also a valid rule that we can give. It will search for the string some site and hex values 0000E, 2F and 01. For keeping things simple we will keep string only and then we close the file and we have to restart Snot. Remember that every time we change a rule we have to restart Snot and also if we change something in Snot.com file we have to restart. Once Snot has started we go to our browser and open some site.com. It is some random site. This ensures that there must be a TCP packet which has the string some site in its payload. Now let's go to Snot interface again and refresh the page. It shows that a new alert has come which is unauthorized keyword detected. If we see the summary we see that that packet was coming from this IP which is listed under source IP and destination IP is the IP of our machine. Now the next rule we are going to see it is for detecting SIN flood. As Saras told already SIN flood is an attack when an attacker tries to open a large number of TCP connections on a victim's server. So as to use all the resources of the server. Let's see the rule for that for detection. We will comment the previous rule and uncomment this. Here also the header part of the rule is almost the same. The changes we have done is in the options part. In options the first is message which says SIN flood detected and the other options are flag S. This will this means that Snot will check for the TCP packets which have SIN flag set. The other options are detection filter track by source count 20 seconds 20 and the rest options are same as idea and revision. So what this means is using this rule Snot will generate an alert whenever it sees 20 or more TCP SIN packets that are coming from a single source within 20 seconds. So that will basically indicate a SIN flood attack. We will again close this file save and close and then we restart Snot. Now we create a situation which simulates a SIN flood attack. We have written a small Java program which sends too many, which sends a large number of TCP requests, TCP SIN requests. We will run it from our host system targeted at our virtual machine. The attack is done. Now we will see the logs in the interface. When we refresh this page we can again see that a new alert has come which says SIN flood detected. The number of alerts is 20 and when we click on the summary we can see from which IP that attack was done. The source IP tells that and destination IP is our IP. So that was all for the demo.