A high-quality
Staffbase Protect is a powerful tool that helps you mitigate these security risks. It uses Cloudflare solutions to detect and neutralize cyber attacks before they reach the Staffbase infrastructure. To achieve this,
How Staffbase Protect works
The Cloudflare servers act as the initial destination for routed traffic. Once the traffic reaches the Cloudflare servers, it is decrypted to undergo a thorough inspection for potential cyber threats or signs of attacks. After the inspection, the traffic is re-encrypted and forwarded to the Staffbase servers. It’s important to note that the traffic is always encrypted during transit. On the other hand, malicious traffic is blocked from reaching Staffbase servers.
How Staffbase Protect works based on your hosting infrastructure
If you are on the
If a user uses your App or Intranet from a location outside of Europe, their encrypted traffic is sent to a server in the EU before being decrypted for inspection. After inspection, the traffic is encrypted again and sent to the Staffbase infrastructure.
DNS setup
A standard
If you are on the
- The Staffbase client uses a custom domain, such as example.customer.com, to access the App or Intranet.
- The custom domain has a
Canonical Name (CNAME) record , which points back to the domain. For example,examplecompany-custom.staffbase.com
- The CName domain, in this case,
examplecompany-custom.staffbase.com
, then points to a fallback domain. For example,fallback.de1.staffbase.com
- Finally, the fallback domain
fallback.de1.staffbase.com
is resolved to Cloudflare IP addresses that are geographically closest to the user’s device.
This way, Staffbase routes the traffic from your domain to Cloudflare to analyze the oncoming traffic. Cloudflare filters out malicious traffic and allows only legitimate traffic to reach the Staffbase servers. This ensures that your users do not experience any downtime due to malicious attacks and that your organization and user data remain protected.
Staffbase blocks network ports other than 80 and 443 on the higher layer in the network stack as per Cloudflare requirements. Cloudflare’s edge nodes, which serve multiple customers as shared resources, have various ports open at a lower level of the network stack. As a result, if you perform a port scan on your domain, you might see some ports appearing as open, even though they are not accessible for your specific use. For more details on blocked traffic, see the Cloudflare documentation.
Example
➜ ~ dig customer.example.com @1.0.0.1
; <<>> DiG 9.10.6 <<>> customer.example.com @1.0.0.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36321 ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;customer.example.com. IN A
;; ANSWER SECTION: customer.example.com. 108 IN CNAME example-custom.staffbase.com. example-custom.staffbase.com. 181 IN CNAME fallback.de1.staffbase.com. fallback.de1.staffbase.com. 181 IN A 141.101.90.98 fallback.de1.staffbase.com. 181 IN A 141.101.90.96 fallback.de1.staffbase.com. 181 IN A 141.101.90.99 fallback.de1.staffbase.com. 181 IN A 141.101.90.97
;; Query time: 52 msec ;; SERVER: 1.0.0.1#53(1.0.0.1) ;; WHEN: Tue Jan 23 14:30:01 CET 2024 ;; MSG SIZE rcvd: 172