I have a few questions about hosting a server publicly.
Does a localhostname have to have a backend website to accompany it, or does the metaserver act as a DNS server for the listed servers' IP addresses (and resolves them to the localhostnames)?
What should I have in the way of security on a machine hosting such a server? Crossfire is not exactly well known, so I wasn't sure if and/or how much security should be present.
If I'm running a trunk server, would you recommend having a regular server maintenance (e.g. updating the revision) schedule, or should maintenance be done (if at all possible) at times of minimal traffic?
Metaserver and hosting a public server.
Moderator: Board moderators
-
SilverNexus
- Junior member
- Posts: 165
- Joined: Mon Jun 25, 2012 5:33 pm
- Location: Planet Earth
Metaserver and hosting a public server.
That SilverNexus guy? You needn't worry about him.
He is level negative 4 in oratory, and his singing is worse.
He is level negative 4 in oratory, and his singing is worse.
the localhostname is the hostname that people on the internet would use to connect to your server (which might be different than the hostname you would use if you are behind a firewall or NAT setup)
The metaserver does some sanity checks - it will look up the IP address of the provided hostname, and that must either match the IP address which is making the update, or the reverse lookup of the IP address making the request (to get its name) must match the hostname provided.
These checks are in place to provide spoofing of the metaserver (eg, I can't advertise a server I set up as crossfire.metal-forge.com for example).
The metaserver code is in SVN, so you are free to browse it/check it out.
But to answer the question simply, the host which is running the server (localhost setting) does not need to run a web server or anything else beyond the crossfire server.
Security is tougher to say - there are almost certainly bugs which might allow remote exploits, but if you compile your own copy, the likelihood of someone being able to exploit it would be very low, since they would most likely not be able to create an identical binary to test out on. For this reason, advertising specific OS and version of tools may not be a good idea, as that would make it easier.
One thing to do is certainly do not run the server as root. It does not need to run as root, so no reason to make it easy for someone. Even better would be to set up a custom user to run crossfire, so if someone does get an exploit, they have more limited access to files (eg, could remove crossfires home directory, but not that of the user of machine unless they have really whacked permissions)
Some operating systems allow running processes in jails or other restricted environment - that certainly would restrict things more, or similarly, using a virtual machine which only runs the crossfire server (and settting up firewall rules to that it can not make connections out to your private network) could mean that even if someone could get access, they can't do much. That can also be useful if you want to allow certain other people to log into the crossfire server to help on maintenance, etc - such a setup would mean that they really couldn't do much even if they tried.
The metaserver does some sanity checks - it will look up the IP address of the provided hostname, and that must either match the IP address which is making the update, or the reverse lookup of the IP address making the request (to get its name) must match the hostname provided.
These checks are in place to provide spoofing of the metaserver (eg, I can't advertise a server I set up as crossfire.metal-forge.com for example).
The metaserver code is in SVN, so you are free to browse it/check it out.
But to answer the question simply, the host which is running the server (localhost setting) does not need to run a web server or anything else beyond the crossfire server.
Security is tougher to say - there are almost certainly bugs which might allow remote exploits, but if you compile your own copy, the likelihood of someone being able to exploit it would be very low, since they would most likely not be able to create an identical binary to test out on. For this reason, advertising specific OS and version of tools may not be a good idea, as that would make it easier.
One thing to do is certainly do not run the server as root. It does not need to run as root, so no reason to make it easy for someone. Even better would be to set up a custom user to run crossfire, so if someone does get an exploit, they have more limited access to files (eg, could remove crossfires home directory, but not that of the user of machine unless they have really whacked permissions)
Some operating systems allow running processes in jails or other restricted environment - that certainly would restrict things more, or similarly, using a virtual machine which only runs the crossfire server (and settting up firewall rules to that it can not make connections out to your private network) could mean that even if someone could get access, they can't do much. That can also be useful if you want to allow certain other people to log into the crossfire server to help on maintenance, etc - such a setup would mean that they really couldn't do much even if they tried.
-
Leaf
- Forum Aficionado
- Posts: 1994
- Joined: Tue Apr 29, 2003 5:55 pm
- Location: Minnesota, USA
- Contact:
localhostname is critical, and it must resolve to the IP address from which the game originates (aka, your server IP.) This means that if you have a NAT router, it will need to resolve to the router.
If you do not have DNS setup to point a hostname (i.e., invidious2.meflin.net -> 66.250.49.19) to your server then you will need to use the server (or router, see above) IP address as your localhostname in the metaserver config file.
If you do not have DNS setup to point a hostname (i.e., invidious2.meflin.net -> 66.250.49.19) to your server then you will need to use the server (or router, see above) IP address as your localhostname in the metaserver config file.
"Put another, more succinct way: don't complain, contribute. It's more satisfying in the long run, and it's more constructive."
Eric Meyer
Eric Meyer
-
Leaf
- Forum Aficionado
- Posts: 1994
- Joined: Tue Apr 29, 2003 5:55 pm
- Location: Minnesota, USA
- Contact:
As for security.. any public facing server should have some level of firewall protection and a Crossfire server is no different.
I, personally, would recommend:
Limiting what IP addresses (or range) can remotely access the server via SSH.
Make sure you have control and trust to anyone who you allow remote access to the server.
Lock down permissions and access rights for these remote uses so that they can only control Crossfire or files/directories related to Crossfire.
NOTE: To clarify, remote access in this case is not people playing the game (aka platers) but people who have an actual login account to the server itself.
I, personally, would recommend:
Limiting what IP addresses (or range) can remotely access the server via SSH.
Make sure you have control and trust to anyone who you allow remote access to the server.
Lock down permissions and access rights for these remote uses so that they can only control Crossfire or files/directories related to Crossfire.
NOTE: To clarify, remote access in this case is not people playing the game (aka platers) but people who have an actual login account to the server itself.
"Put another, more succinct way: don't complain, contribute. It's more satisfying in the long run, and it's more constructive."
Eric Meyer
Eric Meyer
-
SilverNexus
- Junior member
- Posts: 165
- Joined: Mon Jun 25, 2012 5:33 pm
- Location: Planet Earth
As far as I've seen, the crossfire-server will terminate if it detects it is running as root.mwedel wrote:One thing to do is certainly do not run the server as root.
As for firewall, I was thinking of blocking communication on all ports not needed by Crossfire, at minimum. But for that, I would need to know what ports Crossfire uses (I know 13327 and 80 (it uses http) are used, but what others there are, I don't know)Leaf wrote:As for security.. any public facing server should have some level of firewall protection and a Crossfire server is no different.
I was going to have remote access to the server, but I could not get that to work, and instead made a couple keyboard shortcuts to update the crossfire server and shut down the computer (should I need to perform maintenance). Since I'm not using remote access, I could (if I'm thinking correctly) block all SSH remote access (no one can get to the terminal remotely, that way) except maybe 127.0.0.1 (so it could SSH itself should something else on the machine actually do that).
Thanks for the tip. I wasn't sure if the metaserver acted as its own DNS, and this answers that.Leaf wrote:localhostname is critical, and it must resolve to the IP address from which the game originates (aka, your server IP.) This means that if you have a NAT router, it will need to resolve to the router.
If you do not have DNS setup to point a hostname (i.e., invidious2.meflin.net -> 66.250.49.19) to your server then you will need to use the server (or router, see above) IP address as your localhostname in the metaserver config file.
So I guess that leaves one question, which I hadn't posed until earlier in this post (but its buried, so I will reiterate it here): what ports does Crossfire utilize?
That SilverNexus guy? You needn't worry about him.
He is level negative 4 in oratory, and his singing is worse.
He is level negative 4 in oratory, and his singing is worse.
-
Leaf
- Forum Aficionado
- Posts: 1994
- Joined: Tue Apr 29, 2003 5:55 pm
- Location: Minnesota, USA
- Contact:
Crossfire needs TCP port 13327 open.
Metaserver needs TCP port 13326 open.
Metaserver needs TCP port 13326 open.
"Put another, more succinct way: don't complain, contribute. It's more satisfying in the long run, and it's more constructive."
Eric Meyer
Eric Meyer
-
SilverNexus
- Junior member
- Posts: 165
- Joined: Mon Jun 25, 2012 5:33 pm
- Location: Planet Earth
I could have sworn I saw in the code something about an http request. Does it run that over these ports?Leaf wrote:Crossfire needs TCP port 13327 open.
Metaserver needs TCP port 13326 open.
That SilverNexus guy? You needn't worry about him.
He is level negative 4 in oratory, and his singing is worse.
He is level negative 4 in oratory, and his singing is worse.
The server makes an outgoing connection to port 80 for metaserver updates. But that is an outgoing connection, which most firewalls will just pass through without anything special. The only incoming port is 13327
For the metaserver, port 13326 is used by the clients to get the data - unless you run your own metaserver, you don't need to worry about that port.
For the metaserver, port 13326 is used by the clients to get the data - unless you run your own metaserver, you don't need to worry about that port.