Up to Main Index                          Up to Journal for February, 2019

                   JOURNAL FOR SATURDAY 23RD FEBRUARY, 2019
______________________________________________________________________________

SUBJECT: Some minor updates and a new feature in progress
   DATE: Sat 23 Feb 20:39:55 GMT 2019

Isn’t it amazing how life can go from being peachy and smelling of roses to a
steaming, fetid dung pile fraught with stress and anxiety in the blink of an
eye — through no fault of your own whatsoever? I’m in that situation right
now, and it isn’t good :( I can’t say any more at the moment, besides it has
nothing to do with WolfMUD — although things could effect it indirectly, like
fewer journal entries for a while and a possible disruption to the hosting of
the site and WolfMUD code.

For now, let’s just get back to WolfMUD and ignore real life for a while…

What have I been up to them?

After the latest security issue I’ve been carefully going over the client code
for WolfMUD. I cleaned up the code in places. I’ve also fixed an issue with
writes to client connections timing out. In the configuration file there is a
setting for idle client timeouts:


  Server.Host:        127.0.0.1
  Server.Port:        4001
  Server.IdleTimeout: 10m
  Server.MaxPlayers:  1024
  Server.LogClient:   false
  Server.BanPeriod:   15s
  Server.BanTimeout:  30m


That is a snippet from the default configuration file. The value in question
is Server.IdleTimeout which is set to 10 minutes. The problem is the value was
being used to timeout reads and writes. We don’t want to wait 10 minutes for a
write to fail, we want it to fail quickly if there is an issue.

I have therefore set writes to timeout after 10 seconds. This allows plenty of
time for a complete 80x24 screen of ASCII — or multi-byte Unicode and escape
codes for colour — to be sent, even on a very slow connection. In fact, if the
connection is so slow as to timeout then WolfMUD would be unplayable at that
speed anyway.

Keen eyed readers may have spotted that there are two new configuration values
in the above snippet: Server.BanPeriod and Server.BanTimeout

This is something I am currently working on. The short story is that a denial
of service attack on a WolfMUD server, exposed to the internet “as it”, is
trivial:


  seq 1 1000000 | xargs -n1 bash -c 'netcat -z 172.16.1.1 4001'


This one-liner connects to the server, sends zero data and disconnects one
million times very rapidly, spamming the log file with repeated messages.

In the past I have said that the server should be protected using a firewall,
like iptables, and rate limiting connections. Possibly using it to also limit
data rates.

This hasn’t sat well with some users who cannot use, or do not know how to
setup and configure iptables or other firewalls. They just want to run a
WolfMUD server. I have therefore been spending time working on a mechanism for
the server itself to ban IP addresses that repeatedly connect and disconnect.
It’s still a work in progress, details will be available soon. I still suggest
using a proper firewall though…

Another recent change has been fixing the file and line number being logged.
Since the new connection logger was added all log lines were reporting the
connection logger itself:


  connection.go:23: [0] connection from 127.0.0.1:52776


Oops, not very helpful. This has now been fixed:


  client.go:80: [0] connection from 127.0.0.1:52778


Another fix has been to make sure any final messages are always flushed to the
client. I don’t believe this was actually a problem, but it could be and now
it’s definitely fixed.

Fixes for the write timeout, logging, message delivery and a few clean ups
have now been pushed out to the public dev branch.

--
Diddymus


  Up to Main Index                          Up to Journal for February, 2019