Hi Kai, On Sun, Mar 14, 2010 at 09:31:35AM +0000, Kai Hendry wrote: OK, thanks. I hear things like Splunk are good but really expensive. I'd be hoping for several things: - Provide a means for the customer to investigate the compromise with known-good logs, without them having to have an additional VPS at BitFolk or elsewhere to send logs to - Give me additional options when I have to decide what to do about turning the customer's network back on - Provide a value-add service that will set BitFolk apart from competitors If the customer can't work out how the attack happened then I'm in a difficult position with regard to turning their service back on, because there's no reason why it won't happen again almost immediately. Sometimes it means I have to make the decision not to turn it back on, and refund them. In cases of compromise by SSH scanning alone, it will appear in the logs because there'll be an SSH log in from somewhere unexpected. If they get in as root they can remove that evidence after the fact, but they can't remove it from a server they don't have access to. So in that case, yes, it's useful. In other cases where some other service has been compromised, sometimes not so much. But this is rare. It also gives me more options; maybe I insist that customer makes use of remote syslog before turning the network back on. Maybe I decide to use the remote syslogs to investigate it myself (though I usually can't spare the time to provide such free consultancy). Those are my thoughts on it at the moment anyway. Cheers, Andy

On 14 March 2010 10:36, Andy Smith <andy(a)bitfolk.com> wrote: I tried Splunk, though IIUC it runs locally. It's just a bunch of python scripts. It also uses Flash all over the place so the Web app feels clunky and of course would never be useful from a mobile Web browser. So I went off and tried https://landscape.canonical.com/ http://www.flickr.com/photos/hendry/4428825253/ However the Landscape service also does not collate logs and I wrote to Canonical asking why. They replied: """ We currently don't capture any logs by default. The reason for this is simply data volume: we would use a lot of bandwidth collecting the logs that would be interesting to a lot of people and, for the most part, that would end up being a waste of resources. Instead, we recommend you use script execution to fetch logs from one or more computers at a time when you need to view them.""" I can't help but wonder, what the future for logging holds. Right now it's a pretty shoddy state of affairs.

Hello, On Mon, Mar 15, 2010 at 09:08:57PM +0000, Andy Loughran wrote: Just to be clear, there's no way I can write any sort of interface for parsing log files. I'm talking about putting a copy of your log files somewhere else, where you can't write to them but can read them. Then you use whatever sort of tools you like on them. Cheers, Andy -- http://bitfolk.com/ -- No-nonsense VPS hosting

Howdy, folks, Good idea! I like phpLogCon for centralized syslog data viewing. It's not simple, but it's effective (and open-source). http://www.phplogcon.org/ Graham