[Savannah-hackers-public] Re: monitoring

[Dave Love]

[Sorry I haven't been keeping up.]

Sylvain Beucler <address@hidden> 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.