Channel security

Overview

Access to Zato services is mediated through channels, i.e. it is channels that receive incoming requests
Channels represent a particular combination of technology and configuration specific to it, including authentication. For instance, a REST channel will contain information about what URL path or HTTP method to use but it will also include information what credentials are needed to invoke that particular channel.
A single security definition may be assigned to multiple channels
Changes to channels or to security definitions do not require any restarts

Before it can be assigned to a channel, a security definition needs to be created
All types of security definitions can be found in Dashboard, in the Security menu option
Not all security types are applicable to all channel types, e.g. Basic Auth, JWT or Vault can be used with REST or JSON-RPC but they are not applicable to channels such as AMQP or other types
To assign a security definition to a channel, create a security definition in Dashboard and then create or edit a channel of the expected type, as below:

Working in Dashboard is quick and convenient and, for automation purposes, all Zato objects can be also exported to YAML or JSON using a tool called enmasse
With enmasse, it is possible to store configuration in a repository and import it from command line in an automated manner
In this approach, Dashboard is used only initially during development but any actual automated work makes use of enmasse for repeatable builds
Refer to the chapter on enmasse

A rate limit can be assigned to a specific channel, to its service, or to a security definition
A single limit may specify IP addresses or IP ranges that the limit applies to, e.g. a channel may limit external users from specific IP ranges to 10k requests per day but requests from localhost may be unlimited
Refer to this article on rate limiting for details

Zato includes an internal firewall that automatically blocks URL paths known to be used by automated vulnerability scanners and script-based attackers
When a request arrives for a blocked path, the firewall holds the connection open for 60 seconds before returning an HTTP 403 response - this technique is known as tarpitting and it wastes the attacker's resources while your server does no real work
Examples of paths that are blocked include:
/.env, /.env.bak, /.env.production and other environment files that may contain secrets
/.git/config, /.git/HEAD and other version control paths
/.aws/credentials, /.kube/config and other cloud credential files
/wp-login.php, /wp-admin/, /xmlrpc.php and other WordPress paths
/actuator/env, /actuator/heapdump and other Spring Boot actuator endpoints
/phpmyadmin/, /adminer.php, /jenkins/script and other admin panels
/shell.php, /c99.php, /cmd.php and other webshell filenames
/backup.sql, /backup.zip, /dump.sql and other backup artifacts
The full list contains over 250 paths covering configuration files, cloud metadata endpoints, CMS paths, framework debug endpoints, admin panels, VPN gateways, and known backdoor filenames
This feature requires no configuration and is active by default