Re: [security-onion] Security Onion to ELSA & another syslog server

[Martin Holste]

You can do this by configuring syslog-ng to send a copy of the logs to the Kiwi server.  For instance, you can put this in the syslog-ng.conf:

destination d_kiwi { udp("ip.of.kiwi.server"); };

log { source(s_network); destination(d_kiwi); };

On Fri, Apr 19, 2013 at 12:05 PM, <insecuri...@gmail.com> wrote:

I have a new installation of Security Onion 12.04 with two sensors reporting to a server and all is working well. All of the devices are stand alone machines (no VM's) and there is not a firewall between the sensors and the server.

What I need to be able to do is have syslog data from the sensors sent to another syslog server (i.e. Kiwi and no I don't have the choice to not do this). Is it possible to forward logs from the central server or does each sensor need to be configured? What would be the best way to approach this?

Thank you in advance for your help,
Robert

--
You received this message because you are subscribed to the Google Groups "security-onion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-onio...@googlegroups.com.
To post to this group, send email to securit...@googlegroups.com.
Visit this group at http://groups.google.com/group/security-onion?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.

[Martin Holste]

If logs are making it to ELSA, then they are making it to syslog-ng.  Can you paste in the config you added (obfuscating IP's as necessary)?  I also recommend running tcpdump on the box sending the logs to see if they are being emitted.

On Mon, Apr 22, 2013 at 3:06 PM, <insecuri...@gmail.com> wrote:

Thank you for the reply. I have tried your suggestion without success. I have also disabled UFW to ensure it is not blocking anything and I have run wireshark on the syslog server to verify nothing is being received.
I have also tried logging local by modifying the snort.conf to local4 and modifying syslog-ng.conf to filter local4 with no success.
I have also tried logging local by modifying the barnyard2.conf to local4 and modifying syslog-ng.conf to filter local4 with no success.
I have also tried logging local by modifying the barnyard2.conf to send directly to syslog with no success.

Is there anything I am overlooking as to why this is unable to send to a syslog server?

[Martin Holste]

It's hard to say without seeing the entire file, but another bit of debugging is to switch from udp() to file("/tmp/out") and see if anything makes it there.

On Mon, Apr 22, 2013 at 10:06 PM, <sound...@gmail.com> wrote:

Im seeing the same problem, here is my config

syslog-ng:
source src { unix-dgram("/dev/log"); };filter f_local6 { facility(local6); };destination d_trip { udp("x.x.x.x"); };log { source(src); filter(f_local6); destination(d_trip); };

Snort / barnyard2:
output alert_syslog: LOG_LOCAL6 LOG_ALERT

netstat shows a connection, but nothing is being recieved?

[Martin Holste]

Omitting the source means all sources, so for whatever reason, the Bro logs weren't in the "src" source, which is why they started showing up.  You'll need to configure barnyard or something else to send to /dev/log or a file monitored by syslog-ng to get those logs in.

On Tue, Apr 23, 2013 at 10:51 PM, <sound...@gmail.com> wrote:

Tried the file that didnt work??

used this:
destination d_trip { udp("x.x.x.x.x");
log {destination(d_trip);};

which worked but had the source as 127.0.0.1 but at least it sent something! Which was all the Bro logs not the snort logs.

[Martin Holste]

Cool!  You may want to improve the performance of the snort match (which will scan the whole message) with a filter like this:

filter f_snort { "$PROGRAM" eq "snort" };

That's assuming, of course, that you're getting snort as the program, which is standard.

On Wed, May 8, 2013 at 11:57 AM, <insecuri...@gmail.com> wrote:

I have sorted this out and here are the modification I made to syslog-ng.conf

1. First I added a filter for snort as follows between the dashed lines:

@version: 3.2
source s_syslog { unix-dgram("/dev/log"); };
-------------------------------------------------------------------------------

filter f_snort { match("snort"); };
-------------------------------------------------------------------------------
source s_network {
        tcp();
        udp();

2. Then I created destination for the other syslog servers (between the dashed lines). One of the servers is listening on a TCP port. This may be helpful for someone else out there:

source s_ossec { file("/var/ossec/logs/archives/archives.log" program_override('ossec_archive') follow_freq(1) flags(no-parse)); };
------------------------------------------------------------------
destination d_syslog1 { tcp("XXX.XXX.XXX.XXX" port(XXXXX)); };

destination d_syslog2 { udp("XXX.XXX.XXX.XXX"); };
------------------------------------------------------------------
destination d_elsa { program("perl /opt/elsa/node/elsa.pl -c /etc/elsa_node.conf" template(t_db_parsed)); };

3. I then set up logging to the remote syslog servers using the snort filter (between the dashed lines):

log {
        source(s_bro_conn);
        source(s_bro_http);
        source(s_bro_dns);
        source(s_bro_notice);
        source(s_bro_smtp);
        source(s_bro_smtp_entities);
        source(s_bro_ssl);
        source(s_ossec);
        source(s_network);
        source(s_syslog);
        rewrite(r_host);
        rewrite(r_cisco_program);
        rewrite(r_snare);
        rewrite(r_pipes);
        parser(p_db);
        rewrite(r_extracted_host);
        destination(d_elsa);
};
---------------------------------------
log {
        source(s_network);
        filter(f_snort);
        destination(d_syslog1);

};

log {
        source(s_network);
        filter(f_snort);
        destination(d_syslog2);
--------------------------------------
};

4. I then saved the file, restarted syslog-ng and verified logs were being received at both servers.

I have attached a copy of the edited syslog-ng.conf file with the .txt extension for those using windows...

I hope this helps,

Robert

[Martin Holste]

Hm, not sure how that could be.  I've used that same filter in other places recently and it worked fine.  I wonder if it's considering the PID in brackets after the program name for some reason.

On Thu, May 9, 2013 at 3:34 PM, <insecuri...@gmail.com> wrote:

This did not work for me at all. I had to revert back to using the match function in the filter. Thank you though. I know this is not the most efficient way of doing this but it is working.

[Pietro Delsante]

Hi,

I know this is an old thread, sorry to bump it, however there's something that is still not clear to me.

What I want to do is to forward Snort's events to an external syslog server.

Robert's configuration only works when forwarding Snort's events directly from the sensors, but not from the central server, as there is no syslog flow between the sensors and the server for Snort events: they get transferred using Sguil's agent through Barnyard2.

So, supposing that I want to forward the events via syslog from the central server and not from the sensors (as they will be placed on remote networks), what would be the best way to do this? The easiest way would probably be that of duplicating the flows from sensors to server:

1. [snort -> barnyard2 -> sguil agent] -> [sguil on central server]
2. [snort -> barnyard2 -> syslog-ng] -> [syslog-ng on central server] -> [syslog on other server]

I do not like the idea of having the same events transferred from the sensors to the server twice; another option would be that of having some sort of daemon running on the central server and looking for new entries in securityonion-db, then this daemon should reconstruct the events in syslog format and send them to the final syslog server.

However, both options seem to me a stretch; does anybody have any better ideas about how to do this?

Thanks in advance,
Pietro

[Robert Campbell]

That was my original intent and I could not fond a way to do that either. I have the advantage of all my remote networks being connected through VPNs. If anyone knows how to forward them from the server I would prefer to do that as well.

J. Robert Campbell, SR.
CISSP

--
You received this message because you are subscribed to a topic in the Google Groups "security-onion" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/security-onion/KY9EHLIQiZM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to security-onio...@googlegroups.com.

To post to this group, send email to securit...@googlegroups.com.

Visit this group at http://groups.google.com/group/security-onion.