[Sorry I haven't been keeping up.] Sylvain Beucler <[EMAIL PROTECTED]> writes:
> [Joshua (from the FSF admins team) recently mentioned they do have a > monitoring system, eg detecting that Apache was not replying yesterday > during a small DoS. I suppose it would be difficult for us to have > access there, so redundancy is not an issue :)] I could talk to him about it, if that's useful. Depending on what they're running, it may be possible to have different admin access to different services. >> Cfengine can probably help with things like directory permissions and >> cleaning up lock files etc. I'm not sure about something like >> viewcvs, but cfengine can take action depending on running or >> non-running processes. > > Ok, can we work on this kind on monitoring? How do you see things? What I've tended to do is try to automate a defence every time something goes wrong, so it's a question of what the common problems are and tackling them if it' easy. Things like directory/file permissions and cleaning up directories should be straightforward, though I don't know how well it scales for large numbers of directories. > I tried something hand-made. It cannot detect all failures without > human supervision because CVS doesn't return appropriate return codes > sometimes: > http://arch.sv.gnu.org/head/administration/infra/main/0/cvs/cvs-test-suite.sh > > Is there's a cleaner way to do it? I'll have a look later, at least from the point of automation. I'm probably no more expert with CVS. >> Don't you do rate-limiting with iptables to combat that? I did try to >> look at the firewalling, but that needs more privilege. > > No we don't, though Steven said he would search a script of his next > week that is supposed to do so :) I saw a couple interesting options > in the iptables manpages (though Sarge doesn't have connlimit) - feel > free to share your knowledge. Actually, I just realized that you probably don't want to do the straight rate-limiting with iptables because you can get rapid connexions from cvs over ssh, for instance. <URL:http://la-samhna.de/library/brutessh.html> is one summary of defences. > I think most sensible issue is that we don't actually know if we have > such abuses. I'd be surprised if you don't :-/. You're probably not vulnerable to that (apart from denial of service) since you don't allow password login as far as I know. Sorry I probably can't look much more at things until after Easter -- so much for thinking I had the spare time! I'll try to put more effort in then, though.
