Using the Hiawatha Monitor

21 May 2015, 13:21

Although the Hiawatha Monitor is available for more than 5 years (since Hiawatha v7.0), I think not many people actually use it. I'm not sure about the exact reason for that, but it might very well be that people don't understand the purpose or usefulness of this tool. Therefor, I'll explain in this weblog post what the Hiawatha Monitor can do for you.

While the main focus of the Hiawatha webserver is security, the Monitor's focus is more than that. Of course it includes security, but it's also about performance, availability and detecting errors. Via graphs with statistical information, you can have a quick view on what's going on at your webserver and which one needs attention. The purpose of the Monitor isn't to give you detailed information about what's going, but to simply give you enough pointers to start your investigation. You will know in what logfile you should start reading. For example, if the average amount of traffic for a certain website is usually between 300 and 400 megabytes and certainly it generates 2 GB of traffic, you might want to check the access logfile for that website. The screenshot below shows that peak in traffic for a certain webserver.

By clicking on the bar, you get an overview of which website is responsible for what part of that amount of traffic, sorted by the amount. The one on top is most likely the one you should investigate.

In this example, the traffic peak was caused by my own web proxy, which I was developing at that moment. But it could also be someone downloading a large file from your website (should that file be there?) or your website was mentioned at another website (check Referer headers).

Amount of traffic is just one thing the Hiawatha Monitor shows you. It also shows you 404 errors (Not Found), which might indicate a dead link in one of your websites or 500 errors (Internal Server Error), which might indicate, for example, an error in one of your CGI scripts. CGI scripts might generate an error message or a warning, while the output was just fine. You won't see anything wrong at your website, while the error logfile grows larger and larger. The CGI errors graph at the CGI statistics section shows you that.

Hiawatha automatically reports failed logins for HTTP authentication, but failed logins for login functionality in your CGI scripts can also be monitored by printing the HTTP header X-Hiawatha-Monitor with the value 'failed_login'. The same goes for exploit attempts by using the value 'exploit_attempt'. Of course, don't forget to print detailed information about the exploit attempt to stderr for in your error logfile.

To make monitoring your Hiawatha webservers as easy as possible, the Monitor is also able to send you a daily report about the previous day. In one e-mail you get an easy overview about any significant changes in behavior and performance between yesterday and the last two weeks.

As you can see, the Hiawatha Monitor has a lot to offer in aiding you in maintaining your websites and webservers. Although I've told a lot about what I can do for you, there's much more to discover, like runtime of CGI scripts, checking if your webservers are up to date or messages from a CGI script directly to the Monitor. If you have multiple Hiawatha webservers running or just one, but with multiple websites, I'm very sure the Hiawatha Monitor will be a valuable tool.

Tags: Monitor
by Hugo Leisink

Hiawatha as a reverse proxy for Nessus

21 May 2015, 08:32

Nessus is a popular vulnerability scanner by Tenable Network Security. According to Tenable, it’s the most widely used of its kind worldwide. There are several license flavors available, including a free basic edition for home users. Unfortunately, Nessus requires root permissions to run correctly. This means that ironically, not unlike its namesake, the vulnerability scanner itself may be vulnerable to attack. Enter the security-aware Hiawatha webserver and its reverse proxy capabilities.

An article by Chris Wadge

Tags: proxy
by Hugo Leisink

The Logjam Attack

20 May 2015, 09:16

Several weaknesses have been discovered in how Diffie-Hellman key exchange is being deployed in many servers and clients. Good thing to know is that with the default settings, the Hiawatha webserver is not vulnerable. Make sure you didn't set the DHsize setting to a lower value than its default value of 2048. For future releases, I will make 2048 the minimum value.

You can use this webpage to test whether your server is vulnerable or not.

by Hugo Leisink

Hiawatha 9.13 and Monitor 1.1 have been released

10 May 2015, 15:54

Version 9.13 of the Hiawatha webserver has been released. Most important change in this release is that the term SSL has been replaced with TLS wherever possible.

Also, version 1.1 of the Hiawatha Monitor has been released. In this release, support for monitoring failed logins has been included. This requires version 9.13 of the Hiawatha webserver.

And if these two new releases are not enough, I've also released version 4.3 of the Banshee PHP framework.

by Hugo Leisink


16 April 2015, 20:45

Although there is already a patch available for the HTTP.sys vulnerability, I think it's usefull to know that Hiawatha can block requests that exploit a vulnerability. If you were required to wait for a patch, you could have used Hiawatha as a reverse proxy with the following configuration to block HTTP.sys exploits.

UrlToolkit {
  ToolkitID = httpsys
  Header Range [0-9]{6,} Ban 86400

VirtualHost {
  Hostname = www.example.com
  UseToolkit = httpsys
  ReverseProxy .* http://<webserver IP address>/
Tags: security
by Hugo Leisink