loggint through syslog

[Ryan Malayter]

On Friday, December 18, 2009, merlin corey <merlincorey at dc949.org> wrote:
> At any rate, if integrity of data is your concern, then implementing
> integrity checking on multiple fronts - including within your hardened
> server(s) - is certainly a good idea, and I stand by it.  Do you care
> to respond directly to this statement?

I believe I did, and you're being pendantic. But I will answer again
in another way. I agree that integrity should be verified and inputs
validated  at every possible layer, but that doesn't help on a rooted
box. it is impossible to trust log files (or anything else) on a
system that is compromised. logs can be overwritten.. Even if you use
hmac or signatures or whatever... The keys for such schemes are by
necessity on the same server. Maybe if WORM hardware were present...

This is why I and most other security folks prefer off-system logs.
And simply copying them elsewhere from the nginx box isn't enough, you
need a write-once protocol like syslog. If the web server box has
write access to the off-server logs, you can't trust them either.

> No, it certainly is not a good idea to have your only logs on the web
> server, but I never suggested any such silly thing anyway (nice one).
> At least we clearly agree here ;).

But you can't just copy them off-server with a script. The first thing
a successful attacker does is attempt to cover his tracks. So copying
logs even every 60 seconds leaves a big window. Secondly, almost all
protocols besides syslog would enable an attacker with root to
overwrite the or at least truncate the logs on the destination via the
same mechanism. Rsync, FTP, nfs, take your pick.

A "pull" script from another system might provide improved confidence
in the log integrity, but still suffers from the timing issue. Syslog
gets log data off-server in less than a milisecond usually.

Compromising a separate server that exposes only syslog as an
interface is a difficult hurdle to overcome. Precisely because the
system is simple and has little functionality, and uses established
protocols and code.

>
>> Are you being serious here, or just contrarian?
>
> I'm extremely serious.
>
> This conversation started because someone else wanted to use syslog
> for log analysis, which I explained is unnecessary.
>
> You are concerned about conforming to PCI, HIPPA, and SOX - that's
> great, your reasons for wanting to use syslog are based in industry
> standard practices for meeting these needs.
>
> That's not what the other guy needed, and it's apparently not what
> most people need, because we don't have a large group of users with
> money clamoring to have Igor add in syslog officially.

Frankly, my employer might be willing to sponsor such work. But the
mechanism for such sponsored development is unclear from my reading of
the nginx site (perhaps because I can't read Russian). Is there a
bounty program in place? Can maintenance be purchaed?

> As a final point, I don't mean to put it as if you were selling the
> security blanket, because I would like to point out to you (and
> everyone else) that I did note and appreciate your use of the term
> "tamper resistant" logs, rather than "tamper proof" ;)...  I just made
> an offhand comment and look at us now XD

I guess I reacted to the term "security blanket",  which implies
ineffective security theater. Syslog is very effective at improving
the security of log files when implemented properly. Which is whiy it
is a critical part of almost all high-security architectures.


-- 
RPM