Team, 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 point. 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. -- Christer Edwards _______________________________________________ gnome-infrastructure mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-infrastructure
