Use Case: Securing Database Servers

Scenario

This use case describes a system of publicly accessible application servers and microservices that are connected to database servers.

Since the application servers and microservices are publicly accessible, they are exposed to a variety of threats, such as malware, port scans, etc. For this reason, they are located in a demilitarized zone (DMZ). A load balancer assigns requests to the servers depending on their available capacity.

The application servers communicate with each other and with the database servers via the internal connection.

The utilization of the connection between the application servers/microservices and database servers averages 2.4 Gbit/s with peaks of up to 10 Gbit/s.

Securing Database Servers

Security Goals

To secure this setup and to protect the database servers, it is vital to have full control of the communication on the network perimeter and inside the network. Infections and break-ins need to be prevented from spreading from one application or database server to the next. Furthermore, it has to be possible to restrict access to sensitive data.

Implementation

Only protecting the network at the outer perimeter is not sufficient in this scenario. Protection also needs to be implemented inside the network. In theory, this means creating individual network segments with a perimeter firewall for each device in the network. Since this is not feasible in practice, conventional next-generation firewalls implement a zone concept and operate basically like routers with an integrated firewall on layer 3 of the OSI model.

A more flexible alternative to this approach is offered by cognitix, a German cyber security start-up. The cognitix Threat Defender provides next-generation firewall features in a layer 2 device that can be installed at any point in the network. This way, it can apply firewall features to all or individual segments of the network. Furthermore, it monitors the behavior of the devices in the network and isolates devices displaying suspicious behavior.

In addition, the Threat Defender has a sophisticated interactive reporting system that provides administrators quickly with comprehensive overviews of the network.

In the above scenario, one Threat Defender is used as a firewall between the internet and load balancer. It monitors traffic to and from the internet and prevents threats from entering the network. Using application detection, it can control which protocols are transmitted on the allowed ports and block the transmission of unwanted protocols.
A second Threat Defender appliance is placed within the network between the application servers/microservices and the database servers. It isolates the network parts from each other and restricts access between them.
This setup creates a DMZ where the application servers and microservices are located. This approach is recommended by authorities, such as the German Federal Office for Information Security, BSI.

The outer Threat Defender at the network perimeter detects and blocks malicious software, such as port scanners, and acts as a last line of defense against DDOS attacks. The inner Threat Defender detects threats in the DMZ and in the internal network and prevents them from spreading.
The Threat Defender has an integrated IPS. With this database of known threats it can block intrusion attempts. If a device in the network is infected nevertheless, the Threat Defender isolates it and blocks the infected device from communicating with the network, barring the intruder from any further access to the network.

With the Threat Defender it is possible to create static and dynamic network objects to segment the network. They can be used in inline real-time correlations that analyze millions of flows and packets to detect abnormal behavior that can be the indication of an attack. Based on these results, access from servers in the DMZ to servers in the internal network can be restricted. For example, only dedicated services in the DMZ can communicate with dedicated services running on the database servers in the internal network. Communication is implemented via dedicated ports and layer 7 protocols and monitored on the basis of the valid and expected number of connections per time unit and/or traffic.
If the Threat Defender detects abnormal behavior in one of the servers, it can be isolated and blocked from accessing the network at all.

Hardware Information

The Threat Defender runs on the following hardware:

 

Motherboard Supermicro X10DRi
Chipset Intel C612
Processors 2x Intel Xeon E5-2690v4
28 cores / 56 thread in total
2.6 GHz base / 3.5 GHz turbo
Memory 256 GB DDR4 ECC RAM @ 2400MHz
Network cards 2x Intel X710-AM1 with 4x 10GbE SFP+
Storage 960 GB SM863
Samsung Enterprise SSD
Chassis 2U, 19” standard rack

 

Using the above hardware set, the cognitix Threat Defender achieves the following performance values:

 

New sessions per second (1 byte) 460,000
New sessions per second (64 byte HTTP) 110,000
Maximum sessions 6,200,000
Throughput (1518 byte UDP) 32 Gbit/s
Minimal feature throughput (Cisco EMIX 2012) 26.1 Gbit/s
Full feature throughput (Cisco EMIX 2012) 12.3 Gbit/s
Minimal feature throughput
(IXIA BreakingPoint Enterprise Mix) 11.8 Gbit/s
Full feature throughput
(IXIA BreakingPoint Enterprise Mix) 12.1 Gbit/s

 

If you want to try out the cognitix Threat Defender, you can get a free trial license here.

 

Summary

Two Threat Defenders create a DMZ where the application servers and microservices are located. The database servers are located behind the DMZ which grants them a second level of protection.

If an application server in the DMZ is infected, it is automatically isolated using inline real-time correlation and the infection is prevented from spreading any further.