Table of Contents
Security has been of paramount importance in the design and implementation of all parts of BigWorld.
The basic philosophy is to always handle with care any client-initiated actions or messages. This should be accomplished in a way that does not unduly limit potential game designs.
For more details, see the document Server Programming Guide, chapter Security.
The internal network is assumed to be secure — BigWorld does not implement security measures to safeguard processes against an attacker gaining access to the cluster's internal LAN. Operators should ensure that the usual protections for an internal network are in place. Remote access should be very strictly controlled.
The external points of contact are the area of most concern when running an exposed server. For BigWorld, these are LoginApp and BaseApp, as illustrated below:
BigWorld Server components
Due to the bandwidth needs of a massively multiplayer online game, LoginApp and BaseApp are intended to be run on machines with external access. In some sense they are the firewall. For more details, see Blocking Ports and Related Security Considerations.
LoginApp receives only fixed-length queries, making it easy and transparent to secure. This process is expected to be tailored by customers to suit their game, but care should be taken when doing so.
BaseApp receives more complex data, including script method calls, and is the gateway to the rest of the BigWorld Server. It has many checks in place to ensure the integrity of received data, and to discard (and warn about) corrupted data and hacking attempts. The string CHEAT is used in the log messages when BigWorld receives potentially malicious data that does not conform to its protocols (the CellApp may also use this indicator). It is advised that MessageLogger logs be monitored for messages containing that string. For details on MessageLogger, see Message Logger.
The security of the game-level logic rests to a certain extent with the Python scripts that implement it. For example, an entity should not be able to stab another entity that is 100 metres away. For more details on this topic and on server features such as physics checking, see the Server Programming Guide's chapter Proxies and Players, section Physics Correction.
The list below describes the ports used by BigWorld server:
-
20013 (Protocol: UDP, Access: External)
The default port used by LoginApp. This port can be overridden in
<res>/server/bw.xml -
20018 and 20019 (Protocol: UDP, Access: Internal)
Used by BWMachined.
-
40001-49999 (Protocol: TCP, Access: Internal)
The Python server on BaseApp.
All BaseApps have a Python server that can be telnetted to. If no baseApp/pythonPort is specified in
<res>/server/bw.xmlBaseApp ID numbers start at 1, so to talk to the third started BaseApp, telnet to 40003.
-
50001-59999 (Protocol: TCP, Access: Internal)
The Python server on CellApp.
All CellApps have a Python server that can be telnetted to. If no cellApp/pythonPort is specified in
<res>/server/bw.xmlCellApp ID numbers start at 1, so to talk to the third started CellApp, telnet to 50003.
-
32768-61000 (Protocol: TCP, Access: Internal)
Used by CellAppMgr and CellApp for viewer applications such as Space Viewer. Automatically assigned by the kernel (see UDP entry).
-
32768-61000 (Protocol: UDP, Access: Internal [External for BaseApp])
Used by the server components: CellApp, CellAppMgr, BaseApp, BaseAppMgr, DBMgr, MessageLogger and StatLogger. Only the BaseApp has an external port.
Automatically assigned by the kernel, in the range of the kernel setting
/proc/sys/net/ipv4/ip_local_port_range, which defaults to 32768-61000.The BaseApp external port may be exempted from random assignment, by specifying it in the
<res>/server/bw.xmlThe port chosen can be displayed via the Watcher interface under:
-
nub/address for internal interfaces.
-
nubExternal/address for the external interfaces on BaseApp and LoginApp.
-
Since TCP/IP is not used externally, you can block all TCP traffic.
Leave all UDP/IP ports 32768 and above open, as well as the login port
(20013 by default). This range can be reduced if you specify possible
ports in baseApp/externalPorts/port settings in
bw.xml.
Use of a separate firewall machine is discouraged. The BaseApp machines are designed to be the firewalls themselves, and perform a very similar proxying function for clients. Their amount of processing is small enough so that they can handle a whole network adapter's worth of Internet traffic. Adding another machine would only be a waste of hardware, maintenance time, and latency. BaseApps only listen on one UDP port — and so the whole TCP stack can be disabled on the external interface. The use of standard firewall software such as iptables may be an appropriate way to accomplish this.
See chapter Cluster Configuration in the Server Installation Guide for examples of using
iptables.
Network tools such as lsof and netstat should be consulted, to ensure that you are not running any daemons listening on the external (or common) interface. Apart from BWMachined, you should not need to run any daemons with BigWorld, but if you wish to, then you should ensure that their ports are blocked. BWMachined should not listen on the external interface, only the internal interface.
Barring all TCP packets greatly improves the security of a BaseApp machine. TCP is a complicated protocol, and requires many tables and buffers to implement or firewall. By this rationale, the security of a BaseApp machine may be considered even better than that of an ordinary firewall, which must conditionally pass TCP packets.
To reduce exposure to DDOS attacks, it is recommended that the BaseApp be left to choose, within the range allocated by the operating system, a random port. This way, if an attacker discovers the IP and port of one of the BaseApp machines, then it does not mean he will automatically know those details for the other BaseApp machines.