Suricata Setup
Last updated
Last updated
ISPbills all right reserved.
The installation of Suricata is done on an Ubuntu 18.04 Desktop, being updated.
Suricata already comes by default in the Ubuntu repositories but it may be an old version, so to ensure that the latest version is installed we will add the following PPA (Personal Package Archive) to the repository with the following command.
Then we update our team with.
And we went on to install it with.
With the previous command we install both suricata and the jq tool which will help us work with the outputs provided by the EVE.json log file.
Once suricata is installed we can confirm it using the following command to see what state it is in.
And we can also use the following command that will give us information about everything installed, both tools, such as libraries, installation directories, etc.
The next thing we will do is check which is our network and our interface, for this we can use the command ip a or any other that we want to give us the information we want.
Once we know this data we will go to the suricata configuration file, which is located in /etc/suricata/suricata.yaml , once inside we look for the HOME_NET and specify the network we have, for example if we have the following ip 192.168.0.10 , we will define in the Home_Net that our network is in 192.168.0.0/24 or we can directly define the ip of our interface as long as it is fixed.
Then we will search in the document for all the eth0 interfaces and we will replace them with ours, once finished we save, and we will go to the following text file / etc / default / suricata where we will look for all the eth0s and we will replace them with our interface, when we finish we save and we went out.
Our next step will be to install the Suricata-update tool which is very important in suricata because it provides us with the rules for the alerts that suricata will use, these are signed from various sources, in this way we can download them and always keep them updated. To do this, we just have to execute the following command.
This command works with versions of suricata from 4.1 onwards, if they are older, it will be necessary to install it with the following commands:
All the rules will be installed in the default path / var / lib / suricata / rules , inside the suricata.rules file.
Now we restart meerkat with.
Then we make sure that suricata is running by checking its log file, using the command.
The most important line of all that it shows us is the following.
Once we verify that suricata is installed and running, we are going to update the sources, for this we execute.
Then we see a list of all the fonts available with.
Once we see the one that interests us, we just have to activate it, in this example the OISF is activated, using the full name that we saw in the previous list.
And then we update our rules.
Now we must restart meerkat with.
We check the active lists of the source with.
As said before, all the rules go to a file called suricata.rules that is located in the path / var / lib / suricata , to check that suricata is reading correctly from this address we go to the configuration file which is located in / etc /suricata/suricata.yaml and we look for rule-files where the suricata.rules file should be and in default-rule-path the path / var / lib7suricata / rules should be .
In order to define which rules we want to have active and which are deactivated, it is normal to modify the suricata.rules file, in order to enter the directory where / var / lib / suricata is located , we must be root.
Another way that does not come by default when installing the suricata-update is having several files in the / etc / suricata path to define what we want to do with each rule, those files are the following.
/etc/suricata/enable.conf , activate rules
/etc/suricata/disable.conf , disable rules
/etc/suricata/drop.conf , delete rules
/etc/suricata/modify.conf , modify rules We can execute the following command to have an example of each of them with.
Apart from having these files we must specify them in the suricata configuration file the suricata.yaml , in order to see a clearer example of this we can visit the following suricata-update page. Anyway, the future of using suricata is doing everything from the suricata.rules file.
Once we have Suricata installed and tested, our next step will be to make it work with Mikrotik, for this we will first do a few previous steps. On the computer where we have Suricata installed, we download the Trafr tool which is an application written by Mikrotik to convert TZSP traffic to PCAP . The application is 32-bit, so to start it you will need to enable support for 32-bit applications in 64-bit Ubuntu. Therefore, the first thing to do is install the following library with
We create a folder called mikrotik and then download Trafr from the following link with wget http://www.mikrotik.com/download/trafr.tgz
We unzip it with tar -zvxf trafr.tgz .
We test to see if it captures the packets by executing ./trafr -s if encrypted lines appear every so often it is that it is capturing the packets and it works correctly.
Now that we know that it works we move trafr to the following path / usr / local / bin
Now that we have our IDS ready, we will configure Mikrotik to send all the traffic that goes through the router to our equipment that has Suricata installed. To do this, the first thing will be to give an IP to one of the ports where it will be connected, in this example we connect the suricata team to ether5 so to differentiate it first we will give it a name.
Then we give it an address, we will not create any dhcp service because we want the Suricata ip to be fixed. We now have several ways to redirect traffic from the router to our Meerkat.
The first is with the Packet Sniffer tool for this we go to the left menu, Tool → Packet Sniffer , once here we go to the Streaming tab, we mark the Filter Stream and Streaming Enabled boxes and in the Server section we write the ip of our Suricata that will be the one that we will give as a fixed ip. Once configured we just have to press the Strart button.
The second method is creating a Mangle or markup rule , with which we will go to Ip → Firewall and then to the Mangle tab. We create a new rule where in the General tab the Chain section we leave it in forward . Then we go to the Action tab, in the Action section we select the sniff option TZSP, in Sniff Target we write the ip of our Suricata team, and in Sniff Target Port we define the port through which it will go to our Suricata team, which It will be UDP 37008 which is also recognized by Wireshark for packet encapsulation by TZSP (TaZmen Sniffer Protocol) . This port should also be open in our Suricata team.
The advantage of using the Mangle rule is that we can define what interface, port or address we want to capture and send to our Suricata team for analysis, while the Packet Sniffer tool sends all the traffic, therefore the team where Suricata is installed will require have enough RAM memory and at least 4 CPUs so that all the multithreads of Suricata work.
The third method is carried out with a Switch performing a Port Mirror , so it will not be seen here because our virtualization is being carried out on RouterOS.
In this section we are going to show examples of how suricata detects a port scan performed by nmap. For this, as can be seen in the Network Planning document of a company, in phase 3 a kali linux equipment is connected to the master router.
This is for network vulnerability testing. Because in reality an attacking team would not be mounted on your own network.
The idea is to simulate that someone from outside has been able to connect or enter our router, and your next step will be to do a network and port scan to see all the open ports and what private networks exist.
With this we intend to see how that scan detects meerkat and check the number of alerts that it would show, this will be interesting because if, for example, we have mounted a meerkat to notify us of any alert either by telegram, mail or other means, it is possible that this will saturate us by the number of notices.
To do this, it is as simple as having suricata running to collect the packages sent by mikrotik, with the fast.log and eve.json files running. And then with the kali linux team run nmap to the network, using the -sS option in this way a TCP SYN scan is being performed and the SYN packets are exchanged, the connection is not established because the ACK of the SYNC that it sends is not sent the destination server but a RESET is sent.
We will first scan the router whose ip is 192.168.0.31.
Once we have seen the ports that we have open in our router, we can go from our mikrotik router to IP → Services or also to IP → firewall in the service port tab , in both we will find information about open ports for services, where we can disable those that do not Let's use or create rules to drop what comes through them, several of the measures that we can use to secure our router can be taken from the official mikrotik page through this link
Then we scan one of the computers on the LAN2 network, for example at ip 192.168.20.3.
We can see how with meerkat it gives us many alerts, this is in part because this computer, as you can see in the capture of kali linux, has many open ports. And the eve.json file that is the one on the bottom left gives so much information that it is difficult to understand. If meerkat had to notify us of all these alerts we will have many messages.
In order to work in a more friendly way with the eve.json file, there is the jq tool which was installed in the part that explained how to install Suricata, this tool helps to analyze and filter the results of the .json file.
We can see some examples in this link from Suricata or this other from the Stamus-network page .
As examples with screenshots to see what it would look like, we have this one with the command:
and this one to filter by type of event which will be alerts, with the command:
Finally we scan the 192.168.0.0/24 network.
As we see in the image of meerkat, it shows us all the networks and open ports in each one of them.
And with meerkat the information it gives us is overwhelming, since it is collecting all the ports and IP to which it is performing I have kali scan.
As you can see, the eve.json file gives a lot of information which can be difficult to see unless it is properly filtered, and we have also checked the number of alerts that appear with just a port scan.
That is why there are so many third-party tools that use this eve.json file, such as Kibana, Elasticsearch, EveBox among others, hence there is an operating system which already has everything incorporated called SELKS , this OS is very interesting to perform a monitoring of the network, which thanks to all the tools it includes, you can see diagrams, graphs, very detailed information of the alerts, in a more visual and simple way.
