<h1>Security Hints and Practices<aclass="headerlink"href="#security-hints-and-practices"title="Permalink to this headline">¶</a></h1>
<p>Hackers these days aren’t discriminating, and their backgrounds range from bored teenagers to international intelligence agencies. Their scripts and bots endlessly crawl the web, looking for vulnerable systems they can break into. Who owns the system is irrelevant– it doesn’t matter if it belongs to you or the Pentagon, the goal is to take advantage of poorly-secured systems and see what resources can be controlled or stolen from them.</p>
<p>If you’re considering deploying to a cloud-based host, you have a vested interest in securing your applications– you likely have a credit card on file that your host can freely bill. Hackers pegging your CPU to mine cryptocurrency or saturating your network connection to participate in a botnet or send spam can run up your hosting bill, get your service suspended or get your address/site
blacklisted by ISPs. It can be a difficult legal or political battle to undo this damage after the
fact.</p>
<p>As a developer about to expose a web application to the threat landscape of the modern internet,
here are a few tips to consider to increase the security of your Evennia install.</p>
<sectionid="know-your-logs">
<h2>Know your logs<aclass="headerlink"href="#know-your-logs"title="Permalink to this headline">¶</a></h2>
<p>In case of emergency, check your logs! By default they are located in the <codeclass="docutils literal notranslate"><spanclass="pre">server/logs/</span></code> folder.
Here are some of the more important ones and why you should care:</p>
<li><p><codeclass="docutils literal notranslate"><spanclass="pre">http_requests.log</span></code> will show you what HTTP requests have been made against Evennia’s built-in webserver (TwistedWeb). This is a good way to see if people are innocuously browsing your site or trying to break it through code injection.</p></li>
<li><p><codeclass="docutils literal notranslate"><spanclass="pre">portal.log</span></code> will show you various networking-related information. This is a good place to check for odd or unusual types or amounts of connections to your game, or other networking-related issues– like when users are reporting an inability to connect.</p></li>
<li><p><codeclass="docutils literal notranslate"><spanclass="pre">server.log</span></code> is the MUX administrator’s best friend. Here is where you’ll find information pertaining to who’s trying to break into your system by guessing at passwords, who created what objects, and more. If your game fails to start or crashes and you can’t tell why, this is the first place you should look for answers. Security-related events are prefixed with an <codeclass="docutils literal notranslate"><spanclass="pre">[SS]</span></code> so when there’s a problem you might want to pay special attention to those.</p></li>
<h2>Disable development/debugging options<aclass="headerlink"href="#disable-development-debugging-options"title="Permalink to this headline">¶</a></h2>
<p>There are a few Evennia/Django options that are set when you first create your game to make it more obvious to you where problems arise. These options should be disabled before you push your game into production– leaving them on can expose variables or code someone with malicious intent can easily abuse to compromise your environment.</p>
<h2>Handle user-uploaded images with care<aclass="headerlink"href="#handle-user-uploaded-images-with-care"title="Permalink to this headline">¶</a></h2>
<p>If you decide to allow users to upload their own images to be served from your site, special care must be taken. Django will read the file headers to confirm it’s an image (as opposed to a document or zip archive), but <aclass="reference external"href="https://insinuator.net/2014/05/django-image-validation-vulnerability/">code can be injected into an image file</a><em>after</em> the headers that can be interpreted as HTML and/or give an attacker a web shell through which they can access
<p><aclass="reference external"href="https://docs.djangoproject.com/en/4.1/topics/security/#user-uploaded-content-security">Django has a more comprehensive overview of how to handle user-uploaded files</a>, but
<li><p>Serve all user-uploaded assets from a <em>separate</em> domain or CDN (<em>not</em> a subdomain of the one you already have!). For example, you may be browsing <codeclass="docutils literal notranslate"><spanclass="pre">reddit.com</span></code> but note that all the user-submitted images are being served from the <codeclass="docutils literal notranslate"><spanclass="pre">redd.it</span></code> domain. There are both security and performance benefits to this (webservers tend to load local resources one-by-one, whereas they will request external resources in bulk).</p></li>
<li><p>If you don’t want to pay for a second domain, don’t understand what any of this means or can’t be bothered with additional infrastructure, then simply reprocess user images upon receipt using an image library. Convert them to a different format, for example. <em>Destroy the originals!</em></p></li>
<h2>Disable the web interface (if you only want telnet)<aclass="headerlink"href="#disable-the-web-interface-if-you-only-want-telnet"title="Permalink to this headline">¶</a></h2>
<p>The web interface allows visitors to see an informational page as well as log into a browser-based telnet client with which to access Evennia. It also provides authentication endpoints against which an attacker can attempt to validate stolen lists of credentials to see which ones might be shared by your users. Django’s security is robust, but if you don’t want/need these features and fully intend
<p>Automated attacks will often target port 22 seeing as how it’s the standard port for SSH traffic. Also, many public wifi hotspots block ssh traffic over port 22 so you might not be able to access your server from these locations if you like to work remotely or don’t have a home internet connection.</p>
<p>If you don’t intend on running a website or securing it with TLS, you can mitigate both problems by changing the port used for ssh to 443, which most/all hotspot providers assume is HTTPS traffic and allows through.</p>
<h2>Use an external webserver / proxy<aclass="headerlink"href="#use-an-external-webserver-proxy"title="Permalink to this headline">¶</a></h2>
<p>There are some benefits to deploying a <em>proxy</em> in front of your Evennia server; notably it means you can serve Evennia website and webclient data from an HTTPS: url (with encryption). Any proxy can be used, for example:</p>
