Gds Security

How an Inbound Connection is Handled

When a new request is generated from a web browser the following outlines how this is handled on a Gds Server.

• The server receives a TCP connection from the client browser. The source address of the caller is decoded into the source of internet, LAN or localhost using the IANA address allocations.
• The address source is verified as acceptable for this port using the information in gds.ctl

  interface
  port=6375
  type=debug,normal,internet,private
  

  As this definition has "type=internet", connections from the internet are permitted. It also has "type=normal", which permits connections from LAN addresses. Localhost connections are always permitted.

  If the source address is not permitted to connect, the server calls closesocket() to immediately terminate the network connection. No HTTP response is sent - this can lead of 502 Bad Gateway type errors if the browser connection went via a CDN, load balancer or proxy

• Hardcoded network protections are checked using information in gds.ctl

  interface
  port=6375
  filter-internet=allow(110.0.20.32)
  filter-internet=require-password(MyLoginName:MySecretPassword)
  

  These protections exist so that network administrators can set rules that cannot be seen or changed using the web management screens.
• Network level security/velocity stage 1 checks are performed. This feature can be enabled or controlled with "Dynamic Blocking" settings.
  Dynamic blocking is looking for high volume repeated failed access attempts, or access attempts from known script-kiddies that are polling for known access points.
• The HTTP headers are read and decoded
• If HTTP headers have any serious anomolies the network connection is dropped and the source IP address added as a potential address for dynamic blocking. While not fully disclosed the range of checks include things such as
  • Excessively large number of headers
  • Excessively long header values
  • Malformed headers that could have side effects
  • Direct checks for known attacks such as struts header attack. We do not use struts.
  Many of these checks may have already been performed if you are using a DDOS service, CDN or intelligent proxy
• If the connection arrives via a Proxy, CDN or any device that forwards request to the server, then the X-Forwarded-For and equivalent headers are decoded and the original source address extracted. The original source address is also verified according to the checks outlined in the previous step.
• Security/velocity stage 2 checks are performed now that additional information is available.
• If security is enabled for the target environment, the firewall rules are processed
  • If any rule performs the action "bypass", all remaining security steps are skipped and request processed
    A bypass rule has a seperate entry are within the web management screens, as it is commonly used, but it is simply a firewall rule no different to any others.
    Bypass rules are intended for common operations that do not need security protection, such as serving public domain images
  • Only those rules that reference network or http header information are processed. Rules that check higher level concepts are deferred until this information is available.
• If no direct action was taken by the firewall rules (ie it fell through with an explicit accept or block style action) and the server is in "needlogin" configuration the login credentials of the request are checked. This uses the HTTP Authorizaton header and/or X-API-Key header. If these headers do not validly exist a 401 Unauthorized response is returned.