Leica Geosystems Networked Reference Stations

Leica Geosystems Networked Reference Stations GPS Spider IT and Security A guide to communication technology and security for GPS Spider administrators and IT specialists White Paper November 2007

WhitePaper_GPS_Spider_IT_Technology&Security.doc Page 2 of 14

CONTENTS CONTENTS...3 Preface 4 Computer Setup...4 GPS Spider Servers...4 Personal Firewall...5 SQL Server...6 Computer hardware...7 Computer setup and maintenance...7 Computer Environment...8 Network Setup...8 Distributed server setup...8 Bandwidth...8 Network Security...9 De-Militarized zone (DMZ)...9 Reference Station Receiver Access...10 Access to data streams from the Internet...11 Publish GNSS data files on the Internet...11 Trouble shooting...12 Isolate firewall problems...12 Remember...13 REFERENCES...14 WhitePaper_GPS_Spider_IT_Technology&Security.doc Page 3 of 14

PREFACE This guide is aimed at the experienced IT specialist. It is intended to assist the deployment of GPS Spider into a state of the art IT infrastructure. It will provide an overview about the current IT technologies, which GPS Spider utilises. There are many aspects that the Administrator should consider, in operating a secure system setup to provide 24/7-availability of a GNSS data service. It is assumed that the reader is familiar with GPS Spider and has red the following documents: GPS Spider Installation guide GPS Spider Getting started guide COMPUTER SETUP The GPS Spider software consists of a Graphical User Interface Client (GUI) and four different types of servers: the Site Server, Network Server, Cluster Server and RTK proxy server. GPS Spider Servers Every GPS Spider server is running as a Windows service. The start up and recovery behavior can be changed with the windows service control manager. Status information of the service and Start/Stop actions can be easily accessed via the SpiderTray application, which is running in the windows systems tray. Site Server Remote GUI Network Server Remote GUI NTRIP caster 9877, 1433 9879, 1433 9877, 1433 Cluster Server 1433 2101 (configurable) GNSS Ref.Station Sensors (Sites) configurable Site Server 9882..9892 (or 9878)* 9877,1433 Network Server 9880 RTK Proxy Server 21 25 25 21 user defined configurable FTP Server (File push) SMTP Server FTP Server (File pop - PreEphem) RTK Clients Figure 1 Control flow diagram of a full GPS Spider installation (Client Server) The configuration for the Site Server is stored in an SQL database called Spider on the local MSQL server. The configuration for network server is stored in an SQL database call SpiderNetwork on the local MSQL server. The Network Server will provide the configuration for the Cluster and the RTK proxy servers. WhitePaper_GPS_Spider_IT_Technology&Security.doc Page 4 of 14

The simplest GPS Spider setup is an all-in-one installation, which means the whole software is installed on one single machine. This is an ideal setup for the operator to perform tests or do demos with the GPS Spider software. No security configuration changes have to be done on the local computer for this type of setup. From this control flow diagram (see Figure 1 Control flow diagram of a full GPS Spider installation (Client Server)), you can determine who is acting as client or as server. This is important to understand when configuring the firewalls, which are in between the servers, because you will have to specify directional connections in the configuration of the firewall. Every connection over a machine border is a TCP/IP connection. In case the connection is done on a local server, GPS Spider will use shared memory for communication. Shared memory (also called Interprocess communication - IPC) is around 50% faster as a TCP/IP connection. This reduces the latency of the GNSS data streams that are sent through the system. To reduce the latency, keep as many data streams as possible on the local system. Personal Firewall Most personal firewalls block per default all incoming connections from other machines. The built-in Windows personal firewall is doing the same. If you have an all-in-one installation of GPS Spider and you do not consider to do remote connections, GPS Spider will not interfere with the personal firewall. You can block all ports for incoming connections. This is the most secure setup. If you want to access a GPS Spider server from a different machine (Remote GUI or distributed server installation, RTK clients), you have to open the ports on the personal firewall that you want to access. Remote access to Open port on local Use case example machine Site Server 9877,1433 Distributed installation: Network Server wants to use a Site Server or access via remote GUI Cluster Server (V2.2.x or earlier) 9878 Distributed installation: Cluster Server is used by a Network Server Cluster Server (V2.3 or later) 9882... 9892 Distributed installation: Cluster Server is used by a Network Server. Open all ports that you use for multiple cluster servers. First default single cluster server runs on port 9882. Network Server 9879, 1433 Remote GUI access to the Network server RTK proxy server 9880 Distributed installation: RTK proxy server installed in a De-Militarised Zone (DMZ) for access from the internet RT Product Depends on the setting of the RT-Product Access RTK data from a rover via GPRS or TCP/IP WhitePaper_GPS_Spider_IT_Technology&Security.doc Page 5 of 14

If you open these ports on a personal firewall GPS Spider is, like with any other networking software, theoretically vulnerable for attacks on these ports. Connections with the GPS Spider servers will only be granted if the authentication is successful. The credentials are transmitted in an encrypted format to the GPS Spider server. The communication protocol is done with a proprietary binary format. The credentials are required for local connections via shared memory as well. The authentication of RTK clients is depending on the configuration of the Real time product. During the GPS Spider installation procedure, port checks will be performed on the local computer, to ensure that no other application is using already these ports, which are required by the GPS Spider servers. In case a port, which is required by the GPS Spider server, is already in use, you have to shut down the application that uses this port. These ports used by the GPS Spider inter-server communication cannot be changed. Note: In case you have enabled the Windows integrated firewall, the GPS Spider installation will change the firewall configuration in a way, that the GPS Spider server and the SQL server can be accessed from outside. If you do not need remote access, you should deny the access with the Windows tool Firewall.cpl. In case you have a third party personal firewall installed, GPS Spider will not change any configuration settings. You have to unblock the required ports manually. SQL Server The configuration data for the GPS Spider servers are stored in an SQL server database on a Microsoft SQL Server. There are two authentication modes supported: Windows Authentication and SQL server authentication. GPS Spider always tries to authenticate itself via windows authentication first. With the default installation the GPS Spider Services are running under the built-in Local System account. This account is authorized to access the Spider databases. GPS Spider will use the SQL server authentication, if the windows authentication was denied. There are two different SQL server accounts. One is used to the access the Site server database and the other one to access the Network server database. You can enter the passwords during the installation. Please choose secure passwords. But make sure you remember them, for later remote GUI access configurations. If the SQL server is being installed for the first time, you will be asked to enter a password for the sa (SQL server Administrator) account. Please choose secure passwords here as well, because this is the administrators account on the SQL server, and the default password is a security weakness. You will not need this password again when you work with GPS Spider. From a security point of view the SQL server is the most likely first point of attack for a hacker, worm or virus to harm your installation. SQL is a well-known protocol. This is the reason, why you should choose appropriate passwords for the SQL server accounts. For security reasons you should always keep your SQL server up-to-date with the latest patches and service packs. The GPS Spider CD will always provide you with the latest versions including service packs of the SQL server that are available at the release time of the GPS Spider version. In a remote setup GPS Spider will access the SQL server via TCP port 1433. In case of a local SQL connection named pipes or shared memory are used to ensure faster access. WhitePaper_GPS_Spider_IT_Technology&Security.doc Page 6 of 14

It is always recommended to make regular backups of your site and network server databases. You can use the DatabaseManagementTool, which is installed with the GPS Spider software. If you want to perform the backup automatically you can schedule the provided database backup batch files with the Windows scheduler on a regular basis. The batch files are named *Backup.bat in the GPS Spider program folder. Computer hardware Each of the four different GPS Spider servers have different requirements within the IT hardware environment. When you choose the hardware for a Site server you should always look for a PC with fast hard disk throughput, because it s most time consuming task is the file creation. If you have many different file products, you should consider a SCSI RAID system, which is operating in RAID Level 0 (Striping). If you have to push all the files to an external FTP server, make sure that the entire communication link to the FTP server can handle the amount of data. When you have to look for the hardware for a Cluster server, choose a PC with a fast CPU. GPS Spider is not optimized for hyper threading. If your PC supports it, you can turn it off in the BIOS, as it will only need additional performance. If you have a machine with multiple processors they are optionally used, if you run a second cluster server on this machine and assign every cluster server manually to a dedicated CPU. You can configure this in Windows 2003 Server in the Windows Task Manager. The Network server is currently the server with the lowest requirements within the hardware environment. You do not have to consider high-end computer hardware, if this server is installed standalone on a computer. Typically the Cluster server is installed together with a Network server. The RTK proxy server needs some consideration. Especially when you expect many RTK clients connected simultaneously to the RTK proxy server, you will need high CPU performance. A standalone RTK proxy server won t create files on the hard disk. The computers on which GPS Spider is running should be linked with at least a 100 MBit/sec network. A higher speed of network or a reduction of the traffic will reduce the latency of the data streams, which are passed through the system. If you run an All-in-one installation, which combines all GPS Spider servers on one machine, make sure that the hardware used provides all necessary resources for each service. Computer setup and maintenance If you want to supply connectivity for users to access real time GNSS data over the Internet, you are confronted with unwelcome guests like worms, viruses, and hacking attacks. To mitigate this risk you should plan to keep your entire software up-to-date with the latest service packs and software versions. Some updates will force a system shutdown. This will interrupt your RTK service. The best practice is to collect all software updates over a certain period of time and install them all at once at a suitable point of time, to minimize service downtime and the impact on your clients. Windows offers an automatic update functionality to install the latest patches and service packs. Make sure the automatic updates are disabled, because they could reboot the computer or install patches in an uncontrolled manner. Perform Microsoft updates manually. Included available patches for the SQL server as well. WhitePaper_GPS_Spider_IT_Technology&Security.doc Page 7 of 14

It is recommended to always run an anti virus software on your computer. The virus library should be kept up-to-date. There are basically two different types of virus protection: file base and memory based. It makes sense to use them both on the computer where GPS Spider is installed, but they can interfere with your operational installation. Keep an eye on the system resources. If you run a file based virus scan, check if the site server is still able to create all configured File Products on time. Make sure the system does not run into a backlog. You can perform this task automatically with the Leica GNSS QC software. The memory base virus scan can interfere with the GPS Spider services that are running on the same computer and demanding CPU time. In particular, this is especially important on the Cluster and the RTK proxy servers. You can use the Windows Performance Logger to monitor the CPU usage over a longer period of time. Make sure the Windows integrated power management is always disabled. The shutdown of the hard disk could cause a system stall for a couple of seconds. This might result in data gaps in your GNSS data. Make sure the computer will never be switched into the standby mode, because this will create some temporary CPU peaks, which will result in many data gaps and latency as well. Some screensavers will start some CPU or hard disk intensive processes such as disk cleanup, disk fragmentation, or other additional calculation. Make sure there are no processes started by the screensaver. Or even better, switch off the screensaver completely and turn off your monitor instead, if they are not used. Computer Environment Like any other 24/7 service, the availability is highly correlated to the reliability of the entire system. This includes all factors, which are considered by all other service providers as well (e.g. power supply, cooling, building security, recovery plans and many more). It depends very much on the percentage of availability you want to achieve, how much money you are willing to invest. If you are aiming for a highly reliable service please contact your local IT consultant who has expertise in the Internet Service Provider (ISP) business. In that case it might be a good option to deploy your GPS Spider installation in a proper ISP environment, which is shared with providers of other operational Internet services. NETWORK SETUP Distributed server setup GPS Spider provides flexible client-server architecture. With this architecture it is possible to install the software on different computers. It gives you a great flexibility to minimize CPU, communication or file access bottlenecks. It also provides the possibility to bring redundancy into the GPS Spider setup. The draw back of a distributed architecture is the higher complexity, higher hardware and administration costs and the increasing risk of security vulnerabilities. Bandwidth If you have a state of the art IT network infrastructure (100Mbit/sec) it will be no problem to handle the data transmitted between the GPS Spider servers even for very large reference networks. It is not possible to give general measures for the data throughput, because this depends on many different factors such as number of sites, number of RT-Products, transmitted data types, streaming rate, number of tracked satellites, GPS or/and GLONASS data and the cross-links between the servers. If you are interested in this value you can measure it in your fully operational setup with a bandwidth measurement tool. WhitePaper_GPS_Spider_IT_Technology&Security.doc Page 8 of 14

The volume of the outgoing RTK data is dependent on the type of transmitted RTK data format, the current number of Satellites, and the number of simultaneous connections. You can measure this with a bandwidth measurement tool on your operational RTK proxy server, when the RTK clients are connected. Measure the peaks of the bandwidth over one week. If the RTK proxy server is connected via an ADSL connection with the Internet, be aware that the majority of the transmitted RTK data are outgoing (upstream). The downstream data from the RTK Clients contains only of some small ASCII (NMEA) messages. Network Security The connection between Site, Network, Cluster server and UI Client is in most cases very restricted to a small group of users. These servers are most of the time installed in the same corporate Local Area Network (LAN). In addition to the integrated GPS Spider security, you can configure a closed group of computers, which are not accessible from the outside. This feature has to be configured in your underlaying network infrastructure. The access to the RTK proxy server has to be kept open from outside the trusted network, in order to keep connectivity to/from the Internet. But you should always restrict the access from the Internet to this computer only to the RTK data ports, which should be accessible from outside. Do not open any other ports, if they are not needed. The best practice is to separate the computer with an external network firewall. This is the best way to block attacks before they arrive at the computer. When you configure the authentication for the RTK clients via Rover User Management in GPS Spider you should always choose complex passwords for all rover users. If you have a high number of rover users, make use of a password generator tool that is available for free on the Internet. They generate an infinite number of passwords that are usually really hard to guess or break. GPS Spider has some built-in protection mechanisms against brute force password attacks. If you choose long passwords for all rover users and you exchange your passwords from time to time, it is highly unlikely that they will be broken. If a rover user provides invalid credentials, GPS Spider will deny access and close this connection. If the rover user does not provide any credentials at all, GPS Spider will close the connection after a timeout of one to two minutes. If you have continuously unauthorized connection coming in on your RTK proxy server you should find out the IP address of the sender (e.g. with the NetStat Tool) and add it to the black list on the firewall. The rover user credentials are not transmitted to the RTK proxy server, neither stored there. The credentials are always kept at the backend tier on the network server, where the authorization is done for the data streams. The data for the user accounting (connection logs) are also created and stored on the network server. This is another reason, why you should install the RTK Proxy server on a separate machine, if you want to provide connectivity for rover user from the Internet. De-Militarized zone (DMZ) When you install an RTK Proxy server behind a firewall protected from the Internet, you should consider isolating this computer completely in a DMZ setup, protected from your LAN. Just in case, all protection mechanisms break down, and an intruder (virus, worm or hacker) arrives on this computer, this will be a dead end for him, because it should not be possible at all to establish any connection from the DMZ to the LAN. The underlying philosophy for the DMZ is that connection should only be allowed from a higher secured area to a lower secured area. It is possible to connect from the LAN WhitePaper_GPS_Spider_IT_Technology&Security.doc Page 9 of 14

into the DMZ or the Internet, but not from the DMZ or the Internet into the LAN. The connection to the RTK proxy server in the DMZ is established from the Network server in LAN. LAN DMZ Internet RTK Proxy server Site server Cluster server Network server user data There are no user credentials or user accounting data stored on the RTK Proxy server. If the intruder corrupts the RTK Proxy server, no sensitive data can be found on this machine. In case the RTK proxy server instance is affected by any modification (e.g. by a stack overflow), the GPS Spider watchdog will restart the service and the network server will close the existing connection and reestablish it afterwards to the new instance of the RTK proxy server. It is advisable to deny the connection to all ports from the Internet, which are not needed to provide RTK data. This will make it impossible to access any other services from the Internet. From the LAN only connection to port 9880 to the RTK proxy server should be allowed. For additional security you can configure the firewall rules on the network firewall and on the personal firewall on the RTK proxy server. Reference Station Receiver Access If you want to connect a reference station to GPS Spider the most reliable and secure setup is to connect it via a corporate LAN. Unfortunately, in most of the larger installations, the reference station receivers, which are providing the input data for GPS Spider, are distributed over a large geographical area. In most of the cases you will not have access to the corporate LAN from the site where the GNSS receiver is installed. A leased line to this site is probably the most secure and reliable access, but can be very expensive. A cheaper option is to create a connection with a receiver to an Internet Service Provider (ISP) via a flat rate. If you have a static IP address or you have configured Dynamic DNS you can connect the Site server to the reference station easily via the Internet. To prevent unwanted connections to the reference station from the Internet you can configure the outgoing domain name or IP address on a firewall between the reference station receiver and the Internet. In addition to that you can restrict the access only to the ports that you want to access from the Internet. For Leica GRX 1200 Pro receivers the default NET ports are 5001, 5002 and 5003 for receiver remote configuration and GNSS data streams. To access the onboard web server you can open port 80, 443 and 21 for onboard file transfer. If you don t need a service on the receiver (eg. FTP) you can switch off the port or service on the receiver. If you want to make sure that nobody else is accessing the reference station receiver from the local network, you can restrict the IP settings on the receiver to the IP address of the router or firewall, which routes the incoming connection to the receiver. Remember, that every service (port) that you do not need to access from the Internet, should be blocked by the firewall. If you want to use other ports to provide access to the services you can always change the default configuration on the senor. Please read more about this in the GRX 1200 documentation. WhitePaper_GPS_Spider_IT_Technology&Security.doc Page 10 of 14

Access to data streams from the Internet If you want to provide RTK correction data on the Internet, you need a connection point that is unique in the Internet. You can use static IP addresses or a Dynamic DNS name. Consult your ISP to find out which of these two options best meets your budget and requirements. The next step is to plan over which ports you wish to provide the RTK correction data. Make sure you have no conflicts with other applications, which use these outgoing IP address/ports as well. Most of the state of the art rovers (like the Leica GX1230) support the RTCM Ntrip protocol. The advantage of Ntrip is that you can provide multiple data streams on one single TCP port. If you have to support incoming TCP/IP connections from your rover users you have to assign separate ports for each data stream. You can forward any connection from the WAN via network address translation (NAT) to any port of a host in your LAN or DMZ. In most of the cases you will forward WAN ports to the GPS Spider RTK proxy server. But it is also possible via NAT to forward incoming connections to different GPS Spider RTK proxy servers in the DMZ. Similar to the GPS Spider RTK proxy server the Site server can be configured to provide Real-time products also. But if you want to allow the access to the data streams from the Internet you should always use the access via RTK Proxy server. Because of security reasons the Real-time products on the site server should only be use for data access from the LAN. They do not offer security, authentication, logging and other built-in protection mechanisms. The administration of a firewall is a complex task and you should have an IT specialist, who performs this task for you. You have to provide the NAT mapping for your RTK service. For instance, if you want to provide the Real Time correction data via the Ntrip standard port 2101, the NAT mapping looks as follows: WAN_IP_ADDRESS: 2101 => RTK_PROXY_SERVER_DMZ_ADDRESS: 2101 If you plan to provide different RTK data streams to the Internet via GPS Spider TCP/IP real time products or multiple Ntrip casters you should develop a concept for NAT port mapping. It is easy to loose track in larger installations the current port mapping status without any proper documentation. If you work with dial in modems or an access router you should connect these devices only to a computer that is isolated in a DMZ setup. Because of security reasons, the local IT department in most corporate networks forbids dial in access to a computer in the LAN. Even if you need a dial in connection for the GPS Spider user interface to the network or the site server you should not break this rule. As a solution for this scenario, you can locate these server computers in the DMZ network as well. Publish GNSS data files on the Internet GPS Spider has a built-in automated FTP push functionality. Most of the files that are created by the Software can be pushed to an external FTP server. If you have a slow connection from GPS Spider to the FTP server and you are going to send big files across the network, it can cause a backlog (similar to a traffic jam). This always happens when the sum of all files being created exceeds the rate at which they are being transferred. You can identify this problem by checking the hourly FTP push status message in the GPS Spider watch view. If you recognize this, try to improve you network infrastructure between the GPS Spider and the FTP server. We recommend to use Leica SpiderWeb and Leica GNSS QC if you want to provide a commercial GNSS data file service for your customers. Leica GNSS QC provides advanced automatic quality control and checks for the completeness of the files on the target FTP server. Integrated alarming functionality allows receiving notifications, in case files are lost between your reference station re- WhitePaper_GPS_Spider_IT_Technology&Security.doc Page 11 of 14

ceiver and your target FTP. Leica SpiderWeb provides secure and convenient access to these files from the Internet. The integrated user management allows to record download activities for traceability and to enable billing to your clients. After GPS Spider has transferred the data files to the FTP server successfully, GPS Spider will take no further action. It will only keep pushing files, but GPS Spider will not perform a cleanup on the external data storage. The operator of the FTP server has to take care of this task. Instead of deleting old data manually, you should use software that will do this clean up for you automatically. Again her Leica SpiderWeb can comfortably assist with this task for you automatically without any manual user interaction. In some setups it might be possible, that you have a firewall between your GPS Spider site server and the FTP server. Some firewalls restrict the FTP data transfer only to connections via the standard FTP port 21. In these cases you should configure in the GPS Spider FTP management to transfer your data in the so called passive FTP mode (PASV-FTP). TROUBLE SHOOTING Isolate firewall problems The majority of the communication problems are caused by firewalls. The configuration for professional firewalls has a very high complexity. Therefore it is strongly recommended to consult a professional firewall administrator. When he has done the configuration on the firewall and the communication still does not work, you can perform the following simple methodology to locate the problem. Always question the whole chain of the communication link! To exclude that a configuration mistake in the GPS Spider software causes the problem proceed as follows: First close down the GPS Spider UI Client and stop all GPS Spider services at the computer that you cannot reach. Start the Windows Hyper Terminal application in a listener mode ( wait for calls ) on the TCP port that you want to access. In the second step you have to exclude if the problem is caused by a local error source. Start a second Windows Hyper Terminal on the computer in the client mode and connect to the local terminal server that you have started before. If this works locally and you can transfer data in both directions, go to a PC in same subnet (connected to the same hub or switch), start the Windows Hyper Terminal Application and connect to the remote terminal server. If this works the personal firewall on the remote server is configured correctly. If it does not work review the configuration of the personal firewall with the administrator of this computer. As last step go to the final destination client computer from where you want to establish the connection. Connect the Windows Hyper Terminal client the remote terminal server across the entire network and including the network firewall. If this connection does not work, it is a clear indication that a connection problem has to be solved by the network administrator. When the connection from the GPS Spider GUI client to the Server does not work, remember that you have to perform the check for two ports, the GPS Spider server port and the SQL server port (see table under the chapter personal firewall) WhitePaper_GPS_Spider_IT_Technology&Security.doc Page 12 of 14

REMEMBER If you increase your security you will increase the complexity of installation. Try to find the right balance to minimize the risks for you system. The architecture of GPS Spider is designed to provide a high flexibility regarding the distribution of services according to your security requirements. Choose an appropriate setup for your Installation. When your installation has a high complexity you should always find IT specialist who assists you with your computer administration, network maintenance and firewall setup. A DMZ helps to secure the setup, if you want to provide data to the Internet. Make use of the RTK proxy server concept! The availability of the service depends on the sum of the individual availabilities of all components involved in your reference station network installation. This includes the whole chain from the GNSS receiver via its communication channel through various computers finally to the connected RTK user client coming e.g. through the Internet from its surveying site. In case of malfunction you have to question always any individual part of the system and in particular the communication links involved the complete transmission chain. WhitePaper_GPS_Spider_IT_Technology&Security.doc Page 13 of 14

REFERENCES GPS Spider online help (included on the GPS Spider CD) GPS Spider installation guide (included on the GPS Spider CD) System1200 manual (http://nrs.leica-geosystems.com) SpiderWeb documentation (http://nrs.leica-geosystems.com) GNSS QC documentation (http://nrs.leica-geosystems.com) Leica Geosystems web page (http://nrs.leica-geosystems.com) SANS recommendations (http://www.sans.org) Ntrip documentation BKG (http://www.bkg.bund.de) WhitePaper_GPS_Spider_IT_Technology&Security.doc Page 14 of 14

Whether providing corrections from just a single reference station, or an extensive range of services from a nationwide RTK network innovative reference station solutions from Leica Geosystems offer tailor-made yet scalable systems, designed for minimum operator interaction whilst providing maximum user benefit. In full compliance with international standards, Leica's proven and reliable solutions are based on the latest technology. Precision, value, and service from Leica Geosystems. When it has to be right. Illustrations, descriptions and technical specifications are not binding and may change. Printed in Switzerland Copyright Leica Geosystems AG, Heerbrugg, Switzerland, 2007. XI.07 INT Leica Geosystems AG Heerbrugg, Switzerland www.leica-geosystems.com