Sshguard security policy

Sshguard is a security tool, written with security in mind. This document draws some considerations on security you might be interested in, and is provided for transparency with respect to users.

Development style

Modularity

Sshguard makes ample use of modularity: simpler code and well defined responsabilities. This makes bugs much easier to spot and correct.

Portability

Sshguard has portability constraints that make it use only few, widespread and mature system tools.

Simplicity

Sshguard strongly applies the KISS (Keep It Simple, Stupid) principle, or Occam's razor.

Code quality

Sshguard code distinguishes for being clean, logical and well commented. We received several recognitions for this.

Release policy

Sshguard typically passes along some beta before a stable release. Stable releases normally happen after some weeks of private testing on production servers. However, please mind that not every combination of features nor even every blocking backend can be tested, so bugs could happen notwithstanding.

When a release contains new features that are not trusted to be mature, they are typically marked as EXPERIMENTAL.

There is a mailing list to which users are solicited to submit possible bugs or deficiencies, and a bug tracker where more expertised users and developers can submit bugs.

Despite these, bear in mind that sshguard is still relatively new, so it doesn't boast a user base as large as other older tools do.

Security assumptions

Sshguard currently makes one security assumption: users with shell access are trusted. This option is shared across every log-based blocking tool. Shell users must be trusted because they can inject logs arbitrarily on the system with some code as simple as:

#include <syslog.h>

int main() {
    openlog("sshd", LOG_PID, LOG_AUTH);
    syslog(LOG_ERR, "Invalid user r00t from 1.2.3.4");
    closelog();
    return 0;
}

thus causing DoS against user-chosen addresses (in this case, 1.2.3.4).

With version 1.1, sshguard implements log message authentication making it the only log monitor overcoming this assumption. Mind that for keeping zero load on the system, a caching mechanism could fall back allowing local users to inject blocking rules if the service to authenticate gets down. This is known and accounted: by default, sshguard blocking rules are service-specific, so denying access to an unavailable service is harmless.