Rule block issue

This is the place for you, if you got rsyslog up and running but wonder how to make it do what you want.

Moderator: rgerhards

Google Ads


Rule block issue

Postby wpope » Tue Mar 14, 2017 9:45 pm

Hello,

I'm new to the forum and Rsyslog. I'm on rsyslog 7.4.10 still.
I'm having an issue with getting Symantec 14 syslog into a SIEM via Rsyslog.
On the rsyslog box, there are 2 NICs.
one nic receives Syslog over UDP 514, at which point the log gets processed against our rule blocks in our config.
Then if the log is destined for a SIEM tool, it gets routed to the IP of a 2nd NIC over 5514 on the same rsyslog server which has the SIEM agent collecting and forwarding logs.
The problem is in the rule block I created, I'm assuming.

if $rawmsg contains_i ["ABC-DEFGH01"]
then {
action(
name="Test123"
type="omfwd"
target="10.xxx.xxx.xxx"
port="5514"
protocol="tcp"
template="raw"
)
stop
}

I'm trying to obfuscate the hostname and target IP for public sharing here in the forum, of course.

It appears the block works where it lives because when I change the prot and target IP to a different location for testing, the logs come into that other non-SIEM logging platform.
I also have other existing blocks that are working and able to route to the 2nd NIC, where the agent can send the logs to a SIEM tool.

I've also tried using "if $hostname contains_i", but no luck.
when I do a tcpdump on the second NIC, I should be seeing the traffic/Symantec log, but I do not.

I know I'm on an older version, but would definitely appreciate some assistance.

Thanks.
wpope
New
 
Posts: 3
Joined: Tue Mar 14, 2017 9:24 pm

Urgent Question?

  • Pulling out your Hair?
  • Wasting Time and Money?
  • Deadline Approaching?

Re: Rule block issue

Postby dlang » Tue Mar 14, 2017 11:01 pm

if you enable impstats it will tell you how many log messages that action has processed, which will tell you for sure if it's sending messages or if the messages are not gettting through.

It's possible that your SIEM system is not seeing or not understanding the messages that you are sending it, and therefor is misfiling them. I like to do test messages with the string 'testtest' in them and then search for that string on the destination system. Odds are that they are getting through, but just not getting interpreted the way you think they should.
dlang
Frequent Poster
 
Posts: 1001
Joined: Mon Sep 15, 2008 7:44 am

Re: Rule block issue

Postby wpope » Wed Mar 15, 2017 7:25 pm

Hey I appreciate the quick response!

I enabled impstats and confirmed that "Test123" is processing.

Wed Mar 15 18:02:30 2017: Test123: processed=103 failed=0
Wed Mar 15 18:03:30 2017: Test123: processed=109 failed=0
Wed Mar 15 18:04:30 2017: Test123: processed=109 failed=0
Wed Mar 15 18:05:30 2017: Test123: processed=109 failed=0
Wed Mar 15 18:06:31 2017: Test123: processed=109 failed=0
Wed Mar 15 18:07:31 2017: Test123: processed=109 failed=0
Wed Mar 15 18:08:31 2017: Test123: processed=109 failed=0
Wed Mar 15 18:09:31 2017: Test123: processed=109 failed=0
Wed Mar 15 18:10:31 2017: Test123: processed=109 failed=0
Wed Mar 15 18:11:31 2017: Test123: processed=173 failed=0
Wed Mar 15 18:12:31 2017: Test123: processed=173 failed=0
Wed Mar 15 18:13:31 2017: Test123: processed=177 failed=0

So, it appears it is processing.

What I'm completely confused about though is why I'm not seeing the same log on both NICs via tcpdump?
wpope
New
 
Posts: 3
Joined: Tue Mar 14, 2017 9:24 pm

Re: Rule block issue

Postby wpope » Thu Mar 16, 2017 5:21 pm

I spoke with someone else about this lack of seeing the log on the 2nd NIC.
I was told that I wouldn't see the log because the log is routed to the agent listening on the 2nd NIC and this is done internally on the stack.
wpope
New
 
Posts: 3
Joined: Tue Mar 14, 2017 9:24 pm

Google Ads



Return to Configuration

Who is online

Users browsing this forum: No registered users and 2 guests

cron