Architecture and Implementation - Best practices ?

[Js Opdebeeck]

Hello

After multiple tests with Ossec agents (Windows, Unix, Linux), Ossec
server, and syslog , I'd like to go farther and start for a deployment
in 'production' on some sensitive machine.

My question is more related on the architecture to implement. I'm
focusing more one the logs/events aspect .

I've think I have 2 different approach (I put some Pro and Con) :

1. Install/configure Syslog on the Hosts servers and forward the
events to the central syslog and then analyse it with Ossec.

[Host + Syslog Agent] --> [Syslog Server] <-- [Ossec]

+ No more config on Hosts (Set and forget)
+ All logs are stored centrally then analysed
+ If Ossec server fails ... the logs continues to feed.
- No Integrity Check
- No RookitCheck
- No FileCheck
- Woks only if Syslog server is not an Appliance - ArcSight, and
the events are not stored into a database. (Ossec has to see the
events and has to be installed on the syslog server)
/ Bottleneck is the Syslog Server, but it's a robust technology,
especially with rsyslog.


2. Install Ossec agent on the Hosts servers, forward the events to
Ossec Servers then to Syslog.

[Host + Ossec Agent] --> [Ossec] --> [Syslog Server]

+ Integrity Check
+ RookitCheck
+ FileCheck
+ Ossec can be a separated and dedicated server , the logger can be
an appliance.
- Ossec agent has to be maintained on the Hosts, and sometime
upgraded.
? I don't know if ALL the events are send to the Ossec (vs Syslog)
? Only the Ossec Server events/alerts are send to Syslog.
/ Bottleneck is the Ossec Server, if it fails the events are not
stored into the centralized syslog (forensic/integrity of events).

Can you give your opinion, I can be wrong.
What is your recommendation in term of performance / usability.


Thanks.


Js Op de Beeck

[dan (ddp)]

I actually do both. I store the syslog messages on a server and have
the ossec agent installed on all systems. It's a small setup though.

[Michael Starks]

> 1. Install/configure Syslog on the Hosts servers and forward the
> events to the central syslog and then analyse it with Ossec.

I have done this. In my first environment I already had a syslog server. I
then found OSSEC and discovered that I could just point it to the local
file system where the logs were written. It worked so well I had to back
off and only add logs gradually while I worked on tuning.

> - No Integrity Check
> - No RookitCheck
> - No FileCheck

As ddpbsd noted, you can do both. Just don't have the local agent read the
logs. Keep in mind, however, that you lose the benefit of encrypted and
authenticated transport.

> - Woks only if Syslog server is not an Appliance - ArcSight, and
> the events are not stored into a database. (Ossec has to see the
> events and has to be installed on the syslog server)

You can also install OSSEC on the appliance and have the syslog daemon on
the appliance (which is usually syslog-ng anyway) read the queue:
http://www.immutablesecurity.com/index.php/2010/01/29/using-ossec-for-encrypted-log-transport/

> / Bottleneck is the Syslog Server, but it's a robust technology,
> especially with rsyslog.

OSSEC can also be your syslog server, but I have not yet benchmarked the
performance against others. But with tuning, it can certainly process in
excess of 1,000 events per second.

> 2. Install Ossec agent on the Hosts servers, forward the events to
> Ossec Servers then to Syslog.

I'm doing this in two of my environments. In one of them, the alerts are
sent to the syslog server. In the other one, all logs OSSEC receives are
sent to the syslog server.

> ? I don't know if ALL the events are send to the Ossec (vs Syslog)

Yes, all logs are sent to the manager.

> ? Only the Ossec Server events/alerts are send to Syslog.

With the syslog output, only the alerts are sent to the syslog server. But
you can get around this by reading the queue directly.

> Can you give your opinion, I can be wrong.
> What is your recommendation in term of performance / usability.

It really depends on your requirements. Keep in mind that OSSEC also has
failover capability, so you can have two or more managers in case one goes
down. One of the great things about OSSEC is that you can usually make it
do what you envision, architecture-wise. So I would say work on your design
and OSSEC can probably fit in it just fine.

--
Michael Starks
[I] Immutable Security
Information Security, Privacy and Personal Liberty
http://www.immutablesecurity.com

[Js Opdebeeck]

Any more feedback on this ¿

Kind regards

[Jeremy Rossi]

> Any more feedback on this ¿

What are you looking for ddpbsd and mstark went into detail and gave great
suggestions.

[Dave S]

One issue I've had with the first approach, is making sure ossec can
correctly differentiate the origin of the log messages.
In other words, to ossec, all the events look like they're coming from
one source - the syslog server.
To assign each log message to the correct host, you'd have to
configure these agents on the ossec server so they have an identity
and IP address, even if you never install the agent on the hosts
themselves.
It also affects the behavior of composite rules that use, for example,
<same_source_ip>.

- Dave

[Michael Starks]

On Sun, 8 Aug 2010 08:40:49 -0700 (PDT), Dave S <dst...@comcast.net>
wrote:

I'm not sure why you experienced this, but when I use OSSEC on a syslog
server, the messages (including differentiating the proper source) are all
parsed properly. OSSEC, for the most part, looks at the actual message to
determine the source. If there is an issue then you might want to look at
the configuration of the syslog daemon.

[Js Opdebeeck]

Dave;

Thanks for the reply .


My lab is actually configured with the solution 1 (Centralized syslog-
ng that split the output in some different files - the source is av.
40 hosts), and ossec makes a difference because it looks to care the
'hosts' tag in the syslog events.

Syslog File1 - Windows events (AD, Exchanges, critical servers)
Syslog File2 - Infra (Routers and Switches)
Syslog File3 - Firewalls (Firewalls)
Syslog File4 - WebFiltering
Syslog File5 - MailFiltering
Syslog File6 - LinuxHosts
Syslog File7 - VPN Access
Syslog File8 - StorageEvents
Syslog File9 - ApacheEvents

If I'm come back to my initial question, Solution 2 looks the most
relevant in term of security, but not for a complete storage of events
(Forensic), especially for some hosts that can support only syslog
(Storage, Infra, VPN, Firewall).
This will be harder if at the end I Implement a Logger Appliance ...

[Dave S]

I had configured my syslog daemon to run with the "-h" option to
forward all the logs to ossec.
ossec associated all the events with the server, not the hosts. Now,
the other hosts were not configured as ossec agents/clients because
they were applicances and were closed systems.
So ossec had no knowledge of their identity. Perhaps if I configured
them as agents on the server, even if they would never connect as
such, that would have made a difference.

Any thoughts?

- Dave

[spacekiwi]

Hello Michael,

I also have a setup with both ossec and forwarding to syslog.
But my question concerns the failover.

I have spread my clients out over 4 servers, but when one goes down it
takes 20 minutes before the agent reconnects to the next server in
line.
During the 20 minutes blackout, I have tried to trigger alerts on the
client, but those are nowhere to be found.

It seems to me that this is hard to sell to my superiors, mainly
because it can happen as part of an attack.
Furthermore, I have over 600 clients losing alerts...

Has anyone seen this behaviour too, or am i not looking at the right
places?

Ka Kit Wong