One of the most comprehensive open source intrusion detection systems Suricata held its annual conference in Prague. And because CZ.NIC intensively uses Suricata in its Turris routers to protect users, we have become a proud partner of the event. There, we shared our experience with other Suricata users and showed the technological solution of the Turris Omnia router, where Suricata can be operated with ease.
The conference participants liked the entire technical solution that enables them to run the complete Suricata on their router and manage it at their own discretion. The participants were also intrigued by the design of the parental and corporate network access control system PaKon, which is an add-on to Suricata to be released for regular users of the router in version 3.9 at the end of 2017.
For the Turris team, it was very important to exchange experience with other teams and participants. A whole range of interesting lectures offered both experience and specific solutions.
One of the major topics that Suricon addressed in several lectures was how to protect internal network users and detect various spammers, ransomware, malware in general, and phishing attempts.
How to detect phishing attempts?
For example, one can search for suspicious domains and isolate them. These are typically one-time domains intended only for distribution and control of malware. Such a domain can be quite easily recognized by its cheap price and recent registration date. The domain name itself usually does not make any sense, as it was generated randomly.
One of the interesting ways to detect suspicious domains is to try to calculate their entropy. Because they are randomly generated, their entropy will be significantly higher than in domains containing normal words.
This approach, of course, is not 100% reliable; as always, it is necessary to set a reasonable threshold, use a suitable words corpus for the calculation, and still you may encounter new cool startup names resembling meaningless domain names for spreading malware.
What causes significant problems though, are CDNs. Their functioning and behavior are indistinguishable from those of suspicious domains. The problem can be partially solved with whitelists of known CDNs, but this adds false-negative reactions to the false-positive ones from the previous case. The entire detection system becomes demanding maintenance-wise and hard to keep up-to-date — an essential for it to serve users well.
Looking for malware
Looking for and analyzing malware also bring about many interesting problems. There are whole kits out there designed for making malware and ransomware, which “customers” can buy and modify according to their needs. So you can set up a vulnerable computer, connect it to the Internet, and when it gets infected you can watch what’s going on. This issue was covered in detail in the lecture “Like Sigging Phish in a Barrel” by Jason Williams, Emerging Threats/Proofpoint/OISF.
However, even the authors of malware kits have hard times with their customers. A typical newbie wannabe attacker’s miss is to download a malware .zip archive from the “malware vendor”, upload it to the server from where it is to be spread, unzip it and forget to delete the original file with instructions. That makes it easier for malware fighters: by adding the .zip extension to the last directory in the URL they get to download the entire kit with instructions and thus better analyze what the kit is doing, what “customers” can and cannot modify and how the malware kit can be detected.
An interesting way to detect a phishing website is to monitor a situation when someone accesses a website that redirects them to a legitimate service (Facebook or Gmail) and then sends to it their login and password. This a bit more difficult to detect; one should take a note that this internal client accessed a suspicious webpage with a suspicious redirect, although this may still be harmless. But if within five minutes the same client accesses the same http server and posts their username and password there, one should set off the alarm, deny the user’s permissions, properly instruct them and to deal with the compromise of their account. A bit of a problem with this approach is that today, thanks to Letsencrypt, spammers can use https as well, and that is something to be addressed.
Another approach to studying phishing are bots that go through incoming e-mails and search for suspicious websites. To those, they try to send fake data and watch what happens with these data and where they eventually emerge or are used. Based on this they create records and derive rules for the firewall and Suricata.
Another interesting issue is detection of infected computers within the local network. Machine learning techniques prove themselves useful here. It is possible to extract information about the behavior of users/computers on the network, to train some form of artificial intelligence to do it and then to detect users who do not behave according to the trained model. It sounds complicated and a little bit like sci-fi, what with the artificial intelligence. But in the end, it turns out that a simple ratio of the number of sent and received bytes is of much help.
A typical Internet user is mainly a consumer of content whose download significantly exceeds their upload. On the other hand, an infected computer has an urgent need to spread the infection. This is why it would show numerous attempts to connect to the Internet and of course the efforts to send spam.
Industry under attack
Let us stop at another lecture, “Current & Future Industrial Detection in Suricata” by Gene Stevens & Danny Browning of ProtectWise, which concerned the security of industrial control systems and the Suricata application in this environment. We already know the first attacks: Stuxnet or Duqu. However, have we learned the lesson from them?
What is interesting here is the competence dispute “OT vs. IT”, a dispute between the people who are in charge of the factories and the people who care (not only) about the security of information systems in the production and the company. While the first group wants to be able to control the factory as easily as possible in order to respond quickly in case of a problem, the second group wants to introduce security measures that protect the factory from attacks from the outside. This, however, inevitably complicates the production control.
By now, Suricata already understands the most commonly used Modbus and DNP3 protocols from SCADA systems. This makes it possible to write rules directly without having to deal with the individual reports of this protocol. This greatly simplifies the overview of what is happening in the production infrastructure, but administrators of such a network should stay on guard.
Suricon 2018
The next fall, Suricon will take place somewhat farther, in Vancouver, Canada. That will probably not allow us to visit the event in such great numbers as this year, nor shall we have a stand there. However, the events around Suricata are gaining momentum, as with increasing interest in detecting security penetrations it is becoming increasingly popular, and we will continue to use it and to spread awareness about it.
Michal Hrušecký, Jan Bodnár