Why You Should Consider Securing Your Servers?
Looking into port scanning and other attacks with Suricata
When living in 2021 with digital technologies you might probably know that all our devices should be secure against possible attacks (or at least against attacks that we are aware of) which are coming from various sources; inside or outside. If you are a responsible person in a corporate environment which is mostly related to web servers and cyber security, you MUST be a well experienced person in this domain.
But, you might be hosting some few servers for you own projects, client projects or even for a small startup. If that is the case you might think ‘should I worry about cyber security that much?’.
In this article we will see the importance of configuring proper security procedures even for a development server in a project.
We are going to use a tool called Suricata, which is an open-source IDS (Intrusion Detection System) to analyze the threats that are coming to a cloud hosted server.
You can easily setup Suricata in a server by referring some of these tutorials.
Suricata needs “rules” to operate. Rules are the commands which tell Suricata to what should be scanned and what should be considered as suspicious attacks. Rules can be added either at Suricata build stage or later with Oinkmaster.
Now we have a small VM running with Suricata enabled. You might think, no one knows this VM , so what happens now?
Apparently this is not the case. There are large number of attacks and port scans happening in every minute. In most of the times these scans come from bots but port scanning is one of the early steps when doing an attack.
To collect data for this article, I created a small VM in Azure and installed Suricata. From the moment I installed it, there were port scans, at least 1 or 2 scans in every minute.
Suricata maintains a log file for recording the attacks. These records looks like this.
02/21/2021-14:54:59.897071 [**] [1:2402000:5812] ET DROP Dshield Block Listed Source group 1 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 45.146.165.171:53784 -> 10.1.0.6:2830202/21/2021-14:54:59.897071 [**] [1:2403325:63572] ET CINS Active Threat Intelligence Poor Reputation IP group 26 [**] [Classification: Misc Attack] [Priority: 2] {TCP} 45.146.165.171:53784 -> 10.1.0.6:28302
Log records contain the timestamp, destination and source IPs, ports, type of the attack and the priority.
You can view some of the latest port scans and attacks with the following command. (which shows the last few lines of the log file)
tail -f /var/log/suricata/fast.logI found a small python script to convert these log records to more readable CSV format which you can access from here.
Lets look into some of the records.
As you can see, ‘rule_name’ column shows the reason for recording each scan attempt. Most of them are labelled as ‘poor reputation group’, which suggests that the source IP has been previously listed as a malicious source. By looking at ‘to_addr’ column we can observe the particular ports which were targeted by scans. I did not start any service to run in port 1433 (which typically MySQL port) in this server but still there are scans. There are also scans for port 22 which is usually the port for ssh communications. Records in the above table are a very few amount of records which were filtered from all the records. Original log file contained hundreds of scans per hour which were similar to above records.
With these observations it is reasonable to assume that your small dev servers or production servers are also vulnerable when exposed to internet. To minimize the impact, you should configure necessary security settings in various levels.
- Your application level (configure correct access levels, secure password hashing methods, preventing SQL injection etc.)
- More protection when serving static files via http. (if you have some incorrect configurations, attackers might be able to view files like .env .git . Personally I have experienced such scenarios where the application logs showed that someone tried to access the .env file).
- Enable logging/auditing in application level. Cloud vendors also provide logging services such as; AWS Cloudwatch, Azure Monitor.
- Configure firewall rules in OS level.
- In cloud environments there is another security layer called ‘Security Groups’ which is another filtering layer outside your servers. You can configure the security groups with allowed ports and IP s.
I hope now you have a fair understanding on why you should secure your servers with best security practices. Try to install Suricata in one of your dev servers and observe the scan logs and decide on what are the steps you should take to protect your server.
