Skip to content

Data protection

Architecture

Punch platform respects the 3-Tiers network architecture where data is in the deeper network zone.

Three-tier architecture:

Presentation tier:

This is the topmost level of the application. The presentation tier displays information related to such services as browsing merchandise, purchasing and shopping cart contents. It communicates with other tiers by which it puts out the results to the browser/client tier and all other tiers in the network. In simple terms, it is a layer which users can access directly (such as a web page, or an operating system's GUI).

Application tier (business logic, logic tier, or middle tier):

The logical tier is pulled out from the presentation tier and, as its own layer, it controls an application’s functionality by performing detailed processing.

Data tier:

The data tier includes the data persistence mechanisms (database servers, file shares, etc.) and the data access layer that encapsulates the persistence mechanisms and exposes the data. The data access layer should provide an API to the application tier that exposes methods of managing the stored data without exposing or creating dependencies on the data storage mechanisms. Avoiding dependencies on the storage mechanisms allows for updates or changes without the application tier clients being affected by or even aware of the change. As with the separation of any tier, there are costs for implementation and often costs to performance in exchange for improved scalability and maintainability.

three-tier

Security:

With the three-tier network architecture, the data ix protected from the external access first by authentication, then by application. This is a perimetric protection.

Then, firewall, proxy and sensors are configured and monitored to supervise access and potential abnormal behaviours.

Confidentiality

EXTERNAL

Punch platform has by design a perimetric security with the 3-Tiers network architecture. However the platform interfaces (input & output) are vulnerable.

To prevent sniffing at the platform interface, punch provides a SSL configuration for the most used components:

  • Syslog Spout & Bolts
  • Lumberjack Spout & Bolts

Several SSL provider and level of encryption are available.

The full description of the components is available here:

INTERNAL (multi-tenancy)

Punch provides mecanisms to protect an allowed user from a tenantA (end user or expertise user) to access to the tenantB data.

Authentication and frontal access

A proxy is configured at the front netork level to route a user to the right kibana instance.

There are several ways to configure this proxy.

1) With a simple apache

An HOWTO procedure is available to help an integrator to configure correctly apache.

2) With Keycloak

Please read the authentication section

Enforce kibana protection

Because kibana suffers from several vulnerabilies since the last three years, we provide a logical segregation between each kibana instances with chroot. Chroot put all kibana process in a jail. If a kibana is exploited, the attacker can not access to the others kibana.

To enable the feature, update the kibana section of your punchplatform.properties with the chroot settings.

Protect elasticsearch

Punch provide a security component based on modsecurity to guarantee the confidentiality of each tenant.

HOWTO deploy the modsecurity

Testing

Considering that the domain is admin and the filtering rule is mytenant-events-[(. *)].

Testing a allowed index through modsecurity:

1
2
3
4
5
6
7
curl -X POST -I -H 'Content-Type: application/json' localhost:9100/admin/mytenant-events-2019.03.12/_search 

HTTP/1.1 200 OK
Date: Wed, 20 Mar 2019 14:49:40 GMT
Server: Apache/2.4.18 (Ubuntu)
content-type: application/json; charset=UTF-8
content-length: 2076

Testing a forbidden index through modsecurity:

1
2
3
4
5
6
7
curl -X POST -I -H 'Content-Type: application/json' localhost:9100/admin/mytenant-metrics-2019.03.12/_search 

HTTP/1.1 403 Forbidden
Date: Wed, 20 Mar 2019 14:48:19 GMT
Server: Apache/2.4.18 (Ubuntu)
Content-Length: 327
Content-Type: text/html; charset=iso-8859-1

HOW IT WORKS

Modsecurity is a WAF:

A web application firewall (or WAF) filters, monitors, and blocks HTTP traffic to and from a web application. A WAF differs from a regular firewall in that a WAF is able to filter the content of specific web applications while regular firewalls serve as a safety gate between servers.

During the deployment phase, the deployer install an apache on the configured nodes and enable the modsecurity module.

1
2
apache2ctl -M | grep security
 security2_module (shared)

All modsecurity configuration are stored in /etc/modsecurity

1
2
ls /etc/modsecurity/
blocked.conf  default.conf  modsecurity.conf-recommended  modsecurity-punchplatform-tenant.conf  unicode.mapping
  • default.conf: show the internal settings of modsecurity

  • modsecurity-<tenant>.conf: show the list of rules of a given tenant

  • blocked.conf: basic rule that blocks every requests

Theses files are automatically deployed by the deployer following these principles:

  • modsecurity is configured as a white list firewall which means only wanted request are allowed
  • each tenant has its own configuration file - modsecurity-.conf
  • only blocking rules log the request and the body.

DEBUG:

  • logs are stored in the current apache2 logs with the name: modsec_audit.log
  • it's possible to increase the logging verbosity by updating the settings "nolog" by "log" to a specific rule.

HOWTO add custom rules:

This feature will be developped soon. At the moment, please send a request to the help desk portal

TECHNICAL:

example of rule:

1
2
3
4
5
6
7
8
# specific for content-type application/json
SecRule REQUEST_HEADERS:Content-Type "application/json" "phase:1,nolog,pass,ctl:requestBodyProcessor=URLENCODED,id:4000"
# specific for content-type application/x-ndjson for _msearch kibana 5 request
SecRule REQUEST_HEADERS:Content-Type "application/x-ndjson" "phase:1,nolog,pass,ctl:requestBodyProcessor=URLENCODED,id:5000"

SecRule REQUEST_METHOD "^POST$" "nolog,chain,phase:2,id:4002"
  SecRule REQUEST_URI "^/punchplatform-tenant/.kibana-punchplatform-tenant/doc/search.*" chain
    SecRule REQUEST_BODY "^\{\"type\":\"search\".*title.*"

Explanations:

  • During the phase 1, modsecurity analyses the headers of the request.
  • Because we need to analyse also the body, we process the body if the content-type is json or x-ndjson (line 2 and 4)
  • Because at this step modsecurity doesn't know if the request is legitimate, the rule "passes" the request to the next rules.
  • During the phase 2, the body can be analysed (line 8)
  • To avoid CPU consumption we "chain" secrule from very easy to more complex.
  • rule id must be unique.

Features

Tracevault

To ensure the integrity of the logs, in some cases, punch integrates a specific configuration based on hash generation, strongbox and check verification channels.

A model can be sent on demand - ask contact@punchplatform.com