There are three attack surfaces the platform has outside of the security of the platform. They are Linux, Postgres, and Nginx. The platform design helps mitigate the exposure of Postgres to the outside world but best practices should still be followed. Most importantly Linux and Nginx should be reviewed for latest security policies and best practices. Current best practice thoughts are documented below.

Linux Configuration

Since nginx handles the incoming requests, our issues with Linux will mostly arise from the network stack and non-platform operations like SSH, ICMP. To those ends, most of the recommendations involve changing file permissions and updating the configuration files to mitigate Denial-of-Service attacks (DOSs), limit the impact of reverse shells, and improve performance.

  1. Monitor users
  2. Enable linux firewall solution
  3. Enable access via SSH only
  4. Disable user based login
  5. Use token based authentication only
  6. Ensure maintence upgrades
  7. Configure /etc/sysctrl.conf net.ipv4.icmp_echo_ignore_broadcasts = 1 net.ipv4.icmp_ignore_bogus_error_responses = 1 net.ipv4.conf.all.accept_source_route = 0 net.ipv4.conf.default.accept_source_route = 0 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.default.accept_redirects = 0 net.ipv4.conf.all.secure_redirects = 0 net.ipv4.conf.default.secure_redirects = 0


Possible Postgres liability comes in two places:

  • Snooping on the communications link between Postgres nodes -
    • This is more likely to happen on a public network rather than an internal
    • This can is mitigated by the use of SSL between Postgres nodes
  • Someone injecting arbitrary SQL into the query
    • This is mitigated by the use of Postgres userspace to silo information
    • The platform does not allow for direct execution of statements as they are built from the REST API.
    • The platform does perform checks for SQL injection on all query parameters.

Web Server

Nginx has been well hardened by its wide community support. Serveral configurations do exist to mitigate DOSs and clean up connection handling.

Recommended configuration updates include

  • Obfusicate the nginx server name: This will prevent attackers from being able to identify the server type as nginx This is done by modifying and compiling file src/http/ngx_http_header_filter_module.c with code like

    static char ngx_http_server_string[] = “Server: nginx” CRLF;
    static char ngx_http_server_full_string[] = “Server: “ NGINX_VER CRLF;
    static char ngx_http_server_string[] = “ClearBlade Platform” CRLF;
    static char ngx_http_server_full_string[] = “ClearBlade Platform” CRLF;

  • Cut down response times: This will limit an external attacker from performing a syn flood type attack Modify etc/nginx/nginx.conf with

    client_body_timeout 20;
    client_header_timeout 20;
    keepalive_timeout 5 5;
    send_timeout 30;

Additional tools

Snort - Utilizing an intrusion detection system to log all incoming packets provides additional support if an attack does occur. Snort is an open source industry standard for monitoring and alerting when certain network events occur. Snort will not to prevent an attack, but will provide additional information if an attacker does occur to heighten security and react appropriately


External Networking

All data currently runs across three ports from the platform. These ports should be the only available platform interfaces for the SDKs and external devices.

  • 80 (REST API, Console access)
  • 443 (Encypted REST API, Console access)
  • 1883 (MQTT based messaging)
  • 1884 (Encrpyted MQTT based messaging)
  • 8904 (Websocket messaging)

Intranet Additionally ClearBlade recommends implementation of corporate best practices for firewall installation and virtual private networks.

Use of Mobile Device Management or Mobile Application Management software is encouraged as an additional layer of security for data. These solutions can easily be configured to allow for the platform to efficiently transmit data to end clients and devices.

Data Encryption

All data from the public APIs and made available by the SDKs is designed to run over SSL. This requires that the hosting server be correctly configured with a certificate issued by a valid certificate signing authority.

The platform does offer the ability to run without SSL or with self-signed certificates but it requires specific override implementation and is not recommended by ClearBlade

Platform Administration

The platform allows for developers to signup and create systems. The platform provides a Management console where these developers can be granted rights for:

  • Creating new systems
  • Accessing other systems
  • Monitoring usage by developer with metrics include number of systems and number of transactions

Platform Auth

Each System defined in a platform instance has security automatically. The system may be implemented by providing a user registry or simply using anonymous users. In both cases the API requires that a user first request a token and this token will be included for analytics monitoring. Any user (named or anonymous) in a system has behaviors available for historical audit.
The user token is designed such that any man in the middle attacks will be mitigated.

When a user registry is included each asset within the system can be controlled via a defined role based on the activities create, read, write, and delete. Each user is assigned a role and has authorities managed. This results in a developer of a System being able to control its users and their authorities via the web based console.