[syslog-ng] Regex Solaris from Linux hosts in Syslog-ng config file

[PÁSZTOR György]

Hello vijay,

"Evan Rempel" <erempel at uvic.ca> írta 2015-10-29 17:54-kor:
> Before I get too deep into how this is done, can I ask why you want to
> separate your logs for solaris and linux?
> 
> 
> On 10/29/2015 01:06 PM, vijay amruth wrote:
> >Thank you Evan.
> >
> >Right now, we add a solaris server everytime we spin one,
> >
> >its like this,
> >
> >filter f_solaris {
> >        host('x.x.x.x') or host('x.x.x.2') or
> >        host('x.x.x.3') or host('x.x.x.4') or
> >        host('hostname1) or (hostname2)
> >        }
> >
> >So everytime we spin a server we just go and add it manually to the 
> >config file, either with its host name or the ip.
> >I want to be able to automate with filter functions and or regex so 
> >that I don't have to add manually to the config file on the server 
> >everytime.
> >There is a similar config for linux hosts too
> >
> >Hope I am clear. Appreciate you taking your time out for this.

Yes. It was clear.
In that case you know the solution.
You can analyze the log messages, but you will not find anything usuful,
which will give you a usable distinction between the client's OS type.
So let's keep on the ground: using regex is a dead idea.

The OS macro, what Róbert mentioned, is...
They will need to upgrade all of your clients, change all of their
configuration template, to send in this information into all of the log
events. Which will enlarge all logmessage with this extra information.
I think, it is not an easily maintanable idea.
If that is an option, to modify all of your client, then I would use Evan's
idea: listen on two or more different port.
Let's say 1001, 1002, and 1003.
Let 1001 substitute the "original" bad solution.
Let 1002 be kept for the linux senders
and let 1003 be kept for your solaris senders.
You can tag the three different socket as it was already shown.
And step by step you can deploy the new aproach to your clients:
change linux clients to send their logs to port 1002 instead of 1001.
change solaris clients to send their logs to port 1003 instead of 1001.
And you can reach step by step an organized state, where all of your
clients do this.

Another Idea, if client setting is also a solution:
You put manually this info into an sdata field, and later you do the filter
based on this.
This needs that, the logs should be transferred through the ietf syslog
protocol instead of the legacy syslog protocol.

I can not imagine a solution, why should linux and solaris clients have the
same config.
But if we assume this ridiculous idea, and the only distinction you have
the IP address list, you still have an option to handle this situation
well:
If the receiving machine is a linuxbox, then you can create an iptables
rule, and match for linux clients, and DNAT the logs, which would come to
this imaginary 1001 port, and redirect them to port 1002.
and do another dnat rule, which would match for solaris client and would
redirect trafic which would come to port 1001 to reach port 1003.
A simple example:
iptables -t nat -I PREROUTING -s 1.2.3.4 -m tcp -p tcp --dport 1001 -j REDIRECT --to-port 1002

A better solution, if you do not match the linux clients based on this kind
of single IP address. Use an ipset match rule instead of this.
In that case you need only two iptables rule, and some ipset maintenance.
eg. the mentioned iptables rule would be this:
iptables -t nat -I PREROUTIGN -m set --match-set linux src -m tcp -p tcp --dport 1001 -j REDIRECT --to-port 1002

And the set creation:
ipset create linux hash:ip
ipset add linux 1.2.3.4
ipset add linux 1.2.3.5
...

Once you are done with that you can save the rules, and restore them on
boot time.
Saving:
ipset save >/etc/myipset
Restoring:
ipset restore </etc/myipset
Some thing, you need to care about:
Do first the restore, and then to load the iptables rule!
The iptables rule need the ipset to be already created. It does not matter
if you did not load any entry into it. But it will not allow your iptables
rule regarding a set, until the set not exists.

I hope you have enough lego blocks in your hand now to solve the problem in
an effective way! ;-)

Kind regards,
Gyu