Skip to content

Data protection


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.



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.



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 mechanisms 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 network 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 vulnerabilities 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 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


The Kibana domain name MUST match a punch tenant name for data protection. For example, to grant the proper data access permissions over a tenant called mytenant, the related kibana domain MUST also be called mytenant. This is induced by the modsecurity rules installed by the punch deployer, which take into account :

  • The domain name for tenant data access permissions
  • The configured index name and alias patterns per domain for the data management on Kibana


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

Testing an allowed index through modsecurity looks like:

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 looks like:

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


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.

apache2ctl -M | grep security
 security2_module (shared)

All modsecurity configuration are stored in /etc/modsecurity

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.


  • 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 developed soon. At the moment, please send a request to the help desk portal


example of rule:

# 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.*"


  • 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.



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