Re: [SSHGuard-users] Log human-readable service IDs instead of numbers?

[Alan A. <al...@an...>]

On 02 Nov 2018, at 07:12, ssh...@li... wrote:

[snip]
> From: Christopher Engelhard <ce...@lc...>
> To: ssh...@li...
> Subject: [SSHGuard-users] Log human-readable service IDs instead of
> 	numbers?
> Message-ID: <ba3...@lc...>
[snip]
> Is there a technical reason for mapping SERVICE_<NAME> to numbers
> instead of a name? I'd be happy to attempt a patch to change this, but
> of course only if it actually makes sense to do so.

TL;DR:  Probably no real reason to not do it other than it's going to require some work to integrate the change.

The only reasons that come to mind for not doing so relate to something you brought up later in this thread, i.e., "where one program handles multiple
standard services" (from your message dated Sat, 3 Nov 2018 00:55:00 +0100) seem minor to me.  The numeric code is a nice, fixed-width token that can make automated log parsing of SSHGuard's output simpler, but a well defined log format that's easily tokenized can mitigate that problem pretty easily.  There's also the matter of what to do if/when a program/package gets renamed, e.g., if Postfix gets renamed to "s00per 3mail deliberator!" then tracking name changes is possibly a problem.

A potentially more serious problem are any assumptions about the enumerated type "service" in attack.h, i.e., if something else in SSHGuard expects the token to be a specific size.  What might be the easiest way to do this is have a separate lookup for the service token and simply insert it into or append it to the current message, e.g.,

	Attack from "192.0.2.1" on service 210 (dovecot) with danger 10.


Like I said, I think these are very minor problems.  I think they could be overcome pretty easily.

There may be reasons for separating things by port number, too, e.g., it could be nice to know that a specific Postfix listener on 587/tcp is being attacked instead of just Postfix in general, but a quick perusal of logs suggests that's more problematic.  Postfix, for example can have its submission port listener log with a different name than its SMTP port listener (e.g., by setting syslog_name in master.cf), but that doesn't directly report a port number. Also, since there's no standard on service naming, I think trying to account for all possible names is a pointless endeavor.  There is no standard for such naming in logs (or, at least [citation needed]), and I can't think of another way for SSHGuard to track port numbers that's easily portable and lightweight.  Port number reporting might be useful for people who run services on unusual ports, e.g., like SSHd on port 2222/tcp.  However, I don't see why SSHGuard needs to do this.  Anyone running SSHd on a non-standard port should be able to get any needed port information directly from the log, i.e., from messages like

	Nov 2 20:29:17 somehost sshd[59351]: Connection from 192.0.2.2 port 19654 on 192.0.2.201 port 22


For what it's worth, I think human-readable service identifiers are a good idea.


-- 
Alan