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