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.
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.
- Monitor users
- Enable linux firewall solution
- Enable access via SSH only
- Disable user based login
- Use token based authentication only
- Ensure maintence upgrades
- 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.
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;becoming
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;
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
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.
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
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
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.