Forum

I'm currently testing hiawatha and I'm very happy with it. At the moment there is only one thing, I don't know how to do: I would like to Log the UrlToolkitID in the system.log and the error.log, such that I can quickly see which Rule caused a Ban or DenyAccess etc.

Hiawatha version: 9.12
Operating System: debian

Thank you
curious

That is not possible. I have no intention to implement this as it requires some ugly code to do so. Why do you want to know this by the way?

Because now I (or some scripts runnning regularly) always have to look into the error.log/system.log AND into the access.log to distinguish different url matches. If I could log the toolkit-id it would be sufficient to look into, say, the error.log to see whether it was an attempt to exploit shell shock, or some other case which might be of less interest to me.

Another idea would be, to have a toolkit action, with which I could write custom messages into a (custom ?) logfile. As far as I see this is currently not possible either but it would be equally helpful for the my use case, I think (and perhaps would not require to write ugly code).

May I ask why you want to know all that? In my experience, the things you describe are not really relevant to know. If you plan your ban rules carefully, not much can go wrong. It also takes a lot of your time to keep track of which clients are banned. There are better ways to spend that time.

I want to know, if somebody tries to exploit shell shock against me, because I want to block those IPs entirely on my server (not just the webserver). Yes, I can do that with the access.log, it's just, that I thought, I could make use of those nice smaller logfiles with formats that are easier to parse. Without that extra bit of information those logfiles are indeed rather not relevant for me. But don't worry anymore I will just forget about all that.

Thank you

I've patched it myself ;-). Just two simple modifications in workers.c, since the toolkitID is already known when the system-/error-log functions are called:

649c649
< log_system(session, "Client banned because of URL match in UrlToolkit rule");
---
> log_system(session, "Client banned because of URL match in UrlToolkit rule: %s", session->host->toolkit_rules.item[i]);
679c679
< log_error(session, "access denied via URL toolkit rule");
---
> log_file_error(session, session->file_on_disk, "access denied via URL toolkit rule: %s", session->host->toolkit_rules.item[i]);

Thanks

It's very likely that once an attacker that your server is not vulnerable for shellshock, it will simply move on. Banning them is useless.

Your patch will not work when the banning is done by a UrlToolkit rule called from the one specified via UseToolkit.

Phew, I understood that you won't change the code. And that's perfectly ok, I respect your work and I don't want to waste your precious time. Nevertheless, I will waste mine a little bit more, no matter what you think about that.

Also, I don't ban those ips, I've made a toolkit rule that denies access from them, but that's not relevant at all, since this event is logged into error.log in a similar way as the banning event into the system.log (this is about the logging and not about the banning etc..).

Thank you for the advice regarding the case when toolkit rules call other toolkit rules. While I currently don't see why I should use this feature, I still made a new patch in which I modified the function use_toolkit such that it now sets the effective toolkit_id, too.

Thank you