ssh rate limiting / improved logging
- From: Christer Edwards <christer edwards gmail com>
- To: gnome-infrastructure gnome org
- Subject: ssh rate limiting / improved logging
- Date: Wed, 30 Jun 2010 08:08:30 -0600
We had a brief discussion on this topic this morning in IRC, but I
wanted to bring it up here as well. The issue is iptables rate
limiting for ssh connections, particular to lessening the noise in
logs and reports.
To be clear out of the gate, the topic at hand is not security, it is
less cluttered logs. What we have in place with key-only
authentication is about as secure as we're going to get. Whether we
add fail2ban, denyhosts, change the default port, or rate limiting,
none of these improve the security of what we have now. The only
benefit is less noise. I think we all understand and agree on this
Knowing this, I would still like to implement one of these additional
options, and my vote is for rate limiting. I prefer this option
because it requires minimal changes to the firewall configuration,
doesn't require any additional packages or services to install or
maintain and, as it is efficiently handled at the kernel, the only
cost is a small amount of additional memory.
The cost vs gain in this case, I admit, is low on both sides. Adding a
few lines to iptables is simple and can be done in a few minutes.
Cleaning up the logs simply provides us with more readable logs and
Logwatch reports. I know much of the team disregards Logwatch because
there are better solutions out there. I agree there are better
solutions out there. What stands out to me though is the "out there".
Until we implement those better solutions they may as well not even
exist. So, that leaves us with what we do have, and what we have is
daily reports littered with noise that all of us 'Mark as Read' and go
on with our day.
I do read Logwatch emails. As tedious and boring as they can be, they
still provide some useful information. I don't know the number of
times I've caught little things while they were still little by simply
reading these emails. Plus, we don't have that many machines. I bet
reading (cleaned up) Logwatch reports would take less than five
minutes for all of our boxes, and I'm willing to spend that time. Logs
are there for a reason, but they're only useful if you look at them
once in a while.
So, I would like to propose that either 1) we implement rate limiting
to cut out the noise (which I am willing to do myself) or 2) we
improve the logging system starting with a discussion, plan, roadmap.
If you have an opinion, now is the time.
][Date Next] [Thread Prev