With recent security disasters, such as NordVPN falling a victim to credit stuffing attacks affecting around 2000 users, Mastercard's data leak affecting 90,000 users, ixigo falling a victim to intrusions affecting as much as 17 million users, and many more similar cases; data-security has never been more important.
It is a common pattern noticed that the companies have blamed it on data-center providers for not hardening security of the infrastructure provided by them. In their defense, the Cloud providers claim that their job is merely to provision hardware as per the customer's need, and securing the infrastructure is not their responsibility. While both stand corrected, it is neither only the cloud provider nor only the customer's individual responsibility to secure their environment. Security is a shared responsibility, and both the parties have to do their part.
Intrusion Detection Systems (IDS)
Intrusion Detection System (IDS) is not something that is new to the security scene. The core function of an IDS, as the name suggests, is to identify and detect intrusion attempts, and alert of notify the concerned stakeholders regarding the same. It does this by analyzing and monitoring network traffic, system resources or files for signs that indicate attackers are using known threats to infiltrate or steal data from the network or the resources within.
One may ask why would we need an IDS if we already have a firewall? The reason for the need of an IDS stems from the fact that a traditional firewall only analyzes network and transport layer headers. These headers may include information like: source IP, destination IP, metadata regarding the protocol used (IPv4, IPv6, ICMP, etc.), source port, destination port and more similar information. With advances in technology and cyber security awareness, attackers today do not target simply the network or the transport layers. They prefer focusing their attention on exploiting vulnerabilities in the OS, applications, protocols, etc. The traditional firewalls go blind on such attacks. While the importance and necessity of a traditional firewall cannot be denied, we still need an IDS in place for protecting ourselves from such possible attacks.
Different variations of an IDS have been quietly existing and being implemented in various forms, such as:
Network-based Intrusion Detection System (NIDS)
The placement of a Network-based Intrusion Detection System (NIDS) in the data center's network is critical. Usually an NIDS is placed typically on the inside of the traditional firewall. This allows the NIDS to monitor all the network traffic from and to all the devices. It is able to do so by working in promiscuous mode. In promiscuous mode, the network device is able to intercept and read each network packet that arrives in its entirety. This is usually done using a Switch Port Analyzer (SPAN) configurations or similar switch features. A SPAN allows traffic sent or received on one interface to be copied to another monitoring interface. Using this technique, an NIDS analyzes traffic by comparing it against a database of known attacks, also known as signatures, or by detecting anomalies in traffic patterns. When identified, an NIDS event is generated, logged and reported to the stakeholder through a management system.
Advantages of an NIDS
- Monitors network traffic
- Does not impact network performance as all operations are carried out on the copy of the packet
- No impact on network availability as it does not interfere with network traffic
Limitations of an NIDS:
- Cannot analyze network traffic
- Requires up-to-date signatures
- Unable to block attacks
Host-based Intrusion Detection System (HIDS)
As the name suggests, a Host-based Intrusion Detection System (HIDS) manages both: the state and behavior of a host as well as the network traffic passing through it. It is able to do so by running an agent on the host and forwarding the events to the stakeholders on a management system. A HIDS
typically monitors running processes, the resources accessed by them, system-specific logs and unauthorized changes in the file system.
Advantages of a HIDS
- Monitor activities on a host
- Detect changes in file, system and application
- Detects attacks that NIDS fails to identify, for example: changes done by accessing the system console
Limitations of a HIDS
- Agent needs to be deployed on host that needs to be monitored
- Does not detect network level attacks
- Host itself still remains vulnerable to attacks and failures
NIDS or HIDS?
As can be seen, since both: NIDS and HIDS have their own sets of advantages and limitations, neither NIDS alone nor HIDS alone are sufficient by themselves for prevention against intrusions. While NIDS can detect attacks over a network, HIDS detects those on a particular host on that network. While NIDS goes blind for encrypted traffic, HIDS can decrypt and analyze the traffic at the host. Therefore, a combination of both NIDS and HIDS should be considered while securing a Cloud Infrastructure against intrusion attempts.
Open source offerings
Open source offers a vast variety of solutions for both, NIDS as well as HIDS. Each solution caters for different needs and use cases. We will now compare some of the popular Open-source software (OSS) out there to see which one can be a good bet:
NIDS OSS:
Snort
Snort is a popular NIDS and has been in the market since 1998. It was developed by maintained by SourceFire which was later acquired by Cisco. The main advantage of using Snort is it's ability for real-time traffic analysis and packet logging on networks. It uses a set of rules to check for hostile packets in a network and then generate alerts to the respective stakeholders or the network administrators. Its engine combines the benefits of both: signatures as well as anomaly-based detection techniques.
Zeek
Zeek , formerly known as Bro IDS monitors network traffic passively for suspicious activities and attacks. Just like Snort, Zeek is also a combination of both: signature and anomaly based detection. The traffic captured is converted into a series of packets by the analysis engine. It uses policy-based intrusion detection.
Suricata
Suricata is a signature-based NIDS developed by Open Information Security Foundation (OSIF). It uses existing rule sets to monitor network traffic and provide alerts on detecting suspicious events. Suricata offers high speed and efficiency in network traffic analysis due to its multi-threaded design.
Head-to-head comparison
| Parameters | Snort | Zeek | Suricata |
| Multi-thread | No | No | Yes |
| OS compatibility | Any | Unix-like system | Any |
| Installation / deployment | Installation also available from packages | Manual Installation | Manual Installation |
| GUI Support | A lot | Few | Few |
HIDS OSS
OSSEC
OSSEC stands for Open Source Security Event Correlator. It performs log analysis, file integrity checking, policy monitoring, rootkit detection, and active response, using both: signature and anomaly based detection. OSSEC employs a server-agent model - meaning a dedicated server provides aggregation and analysis for every host.
Samhain
Samhain is a HIDS with central management that helps check file integrity, monitor log files, rootkit detection, port monitoring and detect hidden processes. It provides centralized and encrypted monitoring capabilities over TCP / IP communications. While the Samhain community is good, it is relatively a bit difficult to install, especially when compared to other HIDS solutions.
Tripwire
Tripwire is known for its great capabilities to ensure data integrity, it helps system administrators to detect alterations to system files and notifies them if they are corrupt or tampered files. The open-source solution of Tripwire supports most distributions by offering package installations. It does however come with a few limitations. For example, it does not notify in real-time and one has to rely on logs for the same.
Head-to-head comparison
| Parameters | OSSEC | Samhain | Tripwire |
| Ubuntu official repository | No | Yes | Yes |
| CentOS official repository | No | No | Yes |
| File | Yes | Yes | Yes |
| Network | Yes | No | No |
| Logs | Yes | Partial | Yes |
Implementation of IDS in a Cloud Infrastructure
As can be found after careful comparison, Suricata and OSSEC can be concluded as relatively better offerings for NIDS and HIDS respectively. So our ultimate NHIDS offering that we can use for our Cloud Infrastructure would be integrating them with a Security Information and Event Management System (SIEM). A SIEM is a combination of Security Event Management (SEM) - which analyzes log and event data in real time to provide threat monitoring, event correlation and incident response - with Security Information Management (SIM) which collects, analyzes and reports on log data. One of the most comprehensive SIEM solution is the Elastic Stack or the ELK Stack. The Elastic stack consists of open-source products: Elasticsearch, Logstash, Kibana and the Beats family of log shippers.
Before we proceed to integrate all the above solutions we have one more OSS which was not discussed above:
Wazuh
Wazuh was originally a fork of OSSEC. As the official document indicates, it is built with more reliability and scalability. Wazuh uses anomaly as well as signature based detection methods to perform rootkit detection, log analysis, integrity checking, registry monitoring, and active response. In its latest version, Wazuh offers out-of-the-box integration of OSSEC, Suricata and the Elastic stack. It also provides file monitoring within Docker containers by focusing on the persistent volumes and bind mounts.
In an environment where thousands of nodes are involved, a deployment mechanism which will scale is often preferred. Here we will see how to deploy Wazuh using Ansible for CentOS / RHEL / Fedora platform. For installation on other platforms, please refer their excellent documentation.
Install Ansible
Install EPEL repository
[wazuhmanager@centos ~]$ sudo yum -y install epel-release
Install Ansible
[wazuhmanager@centos ~]$ sudo yum install ansible
Now, we will need to generate the SSH authentication key pair for the Ansible server using the ssh-keygen tool. SSH implements public key authentication using RSA or DSA. Version 1 of the SSH protocol only supports RSA, while version 2 supports both systems.
[wazuhmanager@centos ~]$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/ansible/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/ansible/.ssh/id_rsa.
Your public key has been saved in /home/ansible/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:Z2nkI+fOVMa21NxP8YZaKpQWFqbm4cnAKXZezkuG/0g ansible@ansible
The key's randomart image is:
+---[RSA 2048]----+
| o |
| . . o . |
| o = = + . |
| . + @ * = o oo|
| o S % * = =|
| + @ * = o.|
| E + + .|
| . * . |
| . + |
+----[SHA256]-----+
If you wish you can include a passphrase.
Install Wazuh Manager
Obtain the necessary playbooks and roles for the installation of the Wazuh server components, Elastic Stack components and Wazuh agents cloning the repository in /etc/ansible/roles.
[wazuhmanager@centos ~]$ cd /etc/ansible/roles/
[wazuhmanager@centos /etc/ansible/roles]$ sudo git clone --branch 3.10.2_7.3.2 https://github.com/wazuh/wazuh-ansible.git
[wazuhmanager@centos /etc/ansible/roles]$ ls
wazuh-ansible
Edit /etc/ansible/roles/wazuh-ansible/playbooks/wazuh-manager.yml as per your needs. It should look something like this:
- hosts: 192.168.0.180
roles:
- role: /etc/ansible/roles/wazuh-ansible/roles/wazuh/ansible-wazuh-manager
- { role: /etc/ansible/roles/wazuh-ansible/roles/wazuh/ansible-filebeat, filebeat_output_elasticsearch_hosts: '192.168.0.108:9200' }
Once done, run the playbook:
[wazuhmanager@centos /etc/ansible/roles/wazuh-ansible/playbooks]$ ansible-playbook wazuh-manager.yml -b -K
Here, we use
- -b option to indicate that we are going to become a super user
- -K option to indicate Ansible to ask for the password
Install Elastic Stack Server
Edit /etc/ansible/wazuh-ansible/wazuh-elk.yml so that it looks like the following:
[wazuhmanager@centos /etc/ansible/wazuh-ansible]$ cat wazuh-elk.yml
- hosts: 192.168.0.108
roles:
- { role: role: /etc/ansible/roles/wazuh-ansible/roles/elastic-stack/ansible-elasticsearch, elasticsearch_network_host: 'localhost' }
- { role: /etc/ansible/roles/wazuh-ansible/roles/elastic-stack/ansible-kibana, elasticsearch_network_host: 'localhost' }
Just like before, we run the playbook
[wazuhmanager@centos /etc/ansible/roles/wazuh-ansible/playbooks]$ ansible-playbook wazuh-elk.yml -b -K
Install Wazuh Agent
First make sure that the manager's SSH key is added into .ssh/authorized_keys of each of your server on which you want to install the agent
[wazuhmanager@centos ~]$ cat .ssh/id_rsa.pub | ssh centos@192.168.0.180 "cat >> .ssh/authorized_keys"
centos@192.168.0.180's password:
On the agent node that you wish to manage, open the SSH config
[wazuhagent@centos ~]$ sudo vi /etc/ssh/sshd_config
Check the SSH config of your agent to make sure that the following options have been set to
- PubkeyAuthentication yes
- AuthorizedKeysFile .ssh/authorized_keys
Once done, restart the SSH service
[wazuhagent@centos ~]$ systemctl restart sshd
Edit /etc/ansible/roles/wazuh-ansible/playbooqks/wazuh-agent.yml so that it looks similar to:
- hosts: 192.168.0.102
roles:
- /etc/ansible/roles/wazuh-ansible/roles/wazuh/ansible-wazuh-agent
vars:
wazuh_managers:
- address: 192.168.0.180
port: 1514
protocol: udp
api_port: 55000
api_proto: 'http'
api_user: ansible
wazuh_agent_authd:
enable: true
port: 1515
ssl_agent_ca: null
ssl_auto_negotiate: 'no'
Run the playbook:
[wazuhagent@centos /etc/ansible/roles/wazuh-ansible/playbooks]$ ansible-playbook wazuh-agent.yml -b -K
Once all this is done, you will now have a fully functioning IDS solution consisting of an HIDS, NIDS and an SIEM.
Conclusion
IDS is not a holy grail. Simply having an IDS won't ensure security, but will be a relatively hardened security nonetheless. Apart from IDS, we can have an IPS, NGFW, UTM, etc. With careful planning and a plan for ongoing maintenance, you can build a secure network with these tools.
