Web Mapping Services & Security
mapserver, security, web development, wms
wms mapserver security ogc
For the majority of public GIS systems I’ve worked on all the data in a database is available to users via the mapping interface. If someone wanted to hack in and “steal” data the only concern would be the bandwidth they took up. Security for these systems is fairly low down on the list of priorities, if it’s on the list at all.
GIS systems with organisational data are often only accessible (in theory) through an Intranet, so if the network is well protected then so isthe GIS.
There have only been a few mapping systems I’ve worked on where there is a mix of public data and datasets with restrictive access in the same database. The location of rare bird species (people will go to some lengths for a rare egg) and hallucinogenic mushrooms in a Biodiversity GIS being an example.
I’m currenty designing a MapServer system that will serve out WMS layers to the public, and a few which are limited to certain IP address ranges. WMS and security was something I had never previously investigated. The rest of this post outlines the current situation, and an attempt to restrict WMS access on my server.
WMS and the HTTP Protocol
WMS servers interact with their clients via the HTTP protocol, which uses plain text. For example a client (the user’s browser) would send a “GET” request (along with a number of parameters and headers) such as:
GET mapserv.exe?map=/ms4w/apps/... HTTP/1.1 Host: www.example.com
The server would then send a number of response headers as plain text and, for a valid WMS request, hopefully an image.
“The rationale behind this is that text protocols allows you to see what’s going on on the network by just dumping everything that goes through. You don’t need a specialized analyzer as you need for TCP/IP. This makes it easier to debug and easier to maintain.” - PolyThinker
Clearly anything sent between two computers in plain text is never going to be very secure. The OGCannounced via a press release last August, that they would begin an “Authentication Interoperability Experiment” on the 2nd of October, 2009. This experiment “will test standard ways of transferring authentication information between OGC clients and OGC services using existing mechanisms such as `HTTP Authentication <http://en.wikipedia.org/wiki/HTTP_Authentication>`__, `HTTP Cookies <http://en.wikipedia.org/wiki/Http_cookies>`__, `SSL <http://en.wikipedia.org/wiki/Transport_Layer_Security>`__/`X509 <http://en.wikipedia.org/wiki/X.509>`__, `SAML <http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language>`__, `Shibboleth <http://en.wikipedia.org/wiki/Shibboleth_%28Internet2%29>`__, `OpenID <http://en.wikipedia.org/wiki/OpenID>`__and `WS-Security <http://en.wikipedia.org/wiki/WS-Security>`__.”
The experiments participants include the National Geospatial-Intelligence Agency, and the Carbon Project and its observers include ESRI. Their presence hopefully would mean any resulting decision would be implemented in their software, and lead to the widespread acceptance of a standard. The experiment is led by Jeff Harrison of www.cubewerx.com, who’s website states:
“Concerned about standards? So are we. In fact we literally wrote the book on many of them”
There don’t seem to have been any updates since then, but a good place to keep up with any developments in WMS is through the OGC WMS mailing list - a “discussion list for people implementing and deploying instances of the OGC Web Map Server Interface specification”, and the experiments web page.
Securing MapServer in Apache
In the meantime I was still looking for a way to limit access to my WMS services. I’m using MapServer for Windows (ms4w) which installs MapServer and Apache on a Windows machine. Apache (and IIS) can be used to limit access to certain files based on an IP address which is exactly what I require.
Unfortunately MapServer runs through CGI which means limiting access to certain .MAP files was impossible. MapServer uses the SYSTEM account in Windows which means it has the same access rights no matter what IP address is used to start the process.
There are ways to run CGI processes as different users (suExec seems to be frequently mentioned), but examples on the web all seem to use Linux, and I’d imagine there would need to be a pre-processing script checking IPs to decide which user account should start the MapServer process.
In the end it seemed the simplest option was to have two instance of ms4w on two different servers (the advantages of several virtual servers on one physical server are becoming clearer and clearer). I could then limit access to the CGI program on the server with the more restricted Map files in the following way:
Open C:\ms4w\Apache\conf\httpd.conf and search for the following text:
# # Configure MS4W locations and directories # <Location "/cgi-bin"> Options None Order allow,deny Allow from all </Location>
The edit these settings to limit the access to the CGI folder to IP ranges, addresses, domains etc. For further details see the Apache documentation and this blog post. In the example below only the computer with the IP 192.168.1.10 can access MapServer through CGI:
<Location "/cgi-bin"> Options None Order allow,deny Allow from 192.168.1.10 </Location>
After every change you will need to restart the Apache service to activate your changes. The same settings can also be applied to FastCGI. To see which IPs are accessing your MapServer look in C:\ms4w\Apache\logs\access.log. If you have limited access then IPs without permission should receive a HTTP 403error> These are also recorded in the access.log file.
Ideally I’d like to be able to set access to each MAP file or directory by IP range on the same MapServer, so if anyone has achieved this with ms4w please let me know!