eironside-esristaff

GeoEvent Server: Securing Receiver REST Endpoints

Blog Post created by eironside-esristaff Employee on Apr 30, 2020

One common input for GeoEvent is to create a REST endpoint to receive XML, JSON, or CSV events.  Once created the URL is displayed on the input and is available for data providers to POST data to.  But some have wondered how you secure such an endpoint.  In general, this type of endpoint is relatively secure because it requires an attacker know two very specific things:

  1. The exact case-sensitive URL of the receiver endpoint.
  2. The GeoEvent definition that the receiver endpoint is listening for.

 

Current versions of GeoEvent exposed a directory of GeoEvent configurations, making it easier to discover this information.  When GeoEvent 10.8.1 is released, this will all change and the directory will be secured just like the /geoevent/admin/ API. 

 

This blog discusses one option for securing your receiver end points, regardless of version. These two steps are not foolproof, but do go a long way toward making your receiver endpoints as secure as possible.  

 

Step 1: Reverse Proxy

The first step is to obscure the endpoint behind a reverse proxy.  The proxy will translate an externally available HTTP URL on a standard port (80/443) to the internal URL on port 6143.  When communicating with external/3rd party data providers, you can give them the external URL and don't have to expose your internal network names.

 

Utilizing a reverse proxy also allows you to hide the directory information above so that external entities cannot browse your GeoEvent configuration.

 

Step 2: White List IPs

For the second step, you will need to know the IP addresses that your data provider will be POSTing data from. This could be a single IP or a range/set of IPs in cases where the data provider is using a cluster of servers or has fail-over/disaster recovery set up on their system.  Have your IT administration white list these IP addresses and block all other communication to the external URL.  Once this step is done, only the white listed IP addresses will be able to post data to your external receiver URL.

 

Step 3: Monitor

As with any good security system, your receiver endpoints must be monitored.  At a minimum be sure to periodically inspect the data that is received and compare it to known information you have about the event stream (like a separate API for querying data, equipment logs, or known operating parameters).  In addition, you could monitor event rates looking for situations where the number of events per period of time increases, indicating someone is injecting events or a denial of service attack.

Outcomes