AW: [logs] Secure Central Log Host

Lubomir.Nistorat_private

A nice proven system:

logserver:
    input: syslog data (or else) (write only)
    output: admins reading or being alerted (read only)
    components:
               collector, database, frontend (webserver or whatsoever)

if you don't administer machine yourself then you always have a risk of
tampering by admins,
if the system works you just need to patch the newly identified security
risks.
if you are more paranoid you can introduce filtering rules, to allow
only security ppl to look at it and only log data to flow into the
machine from specific devices.

I'm just working on such a solution, but I'm not ready to put it on my
website yet, although I have a working solution right now with tons of
data in it..

lubo

-----Ursprüngliche Nachricht-----
Von: Rainer Gerhards [mailto:rgerhardsat_private]
Gesendet: Mittwoch, 16. Oktober 2002 20:50
An: loganalysisat_private
Betreff: [logs] Secure Central Log Host

Hi all,

I am currently designing a secure central log host. Obviously, I face a
number of challenges. One thing I hold for important is the location of
the database used to store the repository. Obviously, my central log
server will be a hardened machine placed in a secure part of my network.
So I feel bad about placing the database engine on that same machine -
after all, the DB might be queried by security admins to work with it.
So I would need to open up a number of ports that I do not really like
to open....

Another approach is to have a second machine just running the database.
Then, again two options. I can allow the first machine ("collector") to
talk to the database server ("repository") via the native database
protocol. Thus the collector is a "regular" database client - I need to
open up some ports, but definitely no server ports. All events are
stored in the repository and queried by the admin from there. Fine -
BUT: now the repository can of course be compromised and it might even
compromise the collector over weaknesses in the db protocol. Bad.

Ok, next approach: the collector forwards events to the repository via
syslog protocol. No need to allow any db connectivity between the two.
But again, the repository can be tampered by the admins. Also, on second
thought, I have just introduced another relay (and point of failure).

Mmmhhh - what if we run a database on the collector AND the repository?
The one one the collector is not allowed to talk to the network so this
should be secure. Events are forwarded to the repository via syslog, so
this should again be fine. So here, we are actually back to a
collector&repository in one and the second server is more or less a
working copy for the security admins.

I finally came up with the following idea:

  Collector
  - stores incoming events in flat files inside file system --> written
to CD on a schedule
  - forwards via syslog to the repository machine

  Repository
  - stores incomign events in the database
  - this database is used for admin review. Conceptually, it is
read-only, but if in doubt (or legal investigation), the flat files from
the collector will be used

Does this sound as overkill? Are there any other (proven) approches?

Any advise or comment is highly appreciated.

Rainer Gerhards
_______________________________________________
LogAnalysis mailing list
LogAnalysisat_private
http://lists.shmoo.com/mailman/listinfo/loganalysis

*********************************************************** 
Oktober-Aktion bei STAR 21 NETWORKS 
*********************************************************** 

INTERNET ACCESS 3 und 6 Mbit/s vier Wochen gratis

STAR 21 NETWORKS bietet allen Kunden, die sich im Monat
Oktober für 3 oder 6 Mbit/s INTERNET ACCESS von
STAR 21 NETWORKS entscheiden, die ersten vier Wochen
Nutzung gratis.

Alle weiteren Infos zu dieser Aktion unter: 
www.star21networks.de <http://www.star21networks.de/> , infoat_private
<mailto:infoat_private>  oder ueber
unsere Service Hotline Tel. 0 800 - 1 00 73 40.

_______________________________________________
LogAnalysis mailing list
LogAnalysisat_private
http://lists.shmoo.com/mailman/listinfo/loganalysis