Date: Fri, 9 Dec 2022 13:30:55 +0000
From: Steven D via rsyslog <rsyslog@lists.adiscon.com>
To: Mariusz Kruk <k...@epsilon.eu.org>,
"rsyslog@lists.adiscon.com" <rsyslog@lists.adiscon.com>
Cc: Steven D <pheerl...@hotmail.com>
Subject: Re: [rsyslog] "Global" fromhost-ip blocklist?
That explanation was very helpful and insightful. Thank you sir.
We may be at a misunderstanding of what I mean about vulnerability
scanner events. What is happening is the vulnerability scanners in
our environment are scanning all ports across my syslog servers. The
scanners connection attempts or vulnerability tests are being written
to disc as events. Which in turn end up in my logging system and are
just noise I don't need.
So yeah you're right it is a bit of an overengineering issue, but I
don't really have a choice. Either I find a way to drop traffic from
specific sources to all of my open ports for our syslog only. Or I
just use IP tables and block the scanners altogether, as you
suggested earlier.... Unfortunately that means I'd have to do manual
vulnerability checks on my servers, and I really don't want to have
to deal with that, hahaha
Regards,
Steven.
-------- Original message --------
From: Mariusz Kruk <k...@epsilon.eu.org>
Date: 12/9/22 8:19 AM (GMT-05:00)
To: Steven D <pheerl...@hotmail.com>, rsyslog@lists.adiscon.com
Subject: Re: [rsyslog] "Global" fromhost-ip blocklist?
Depends on what you means by "processed".
It is read from the main config (default or explicitly specified in
command line) and if there is any include directive, the
corresponding file(s) is getting inserted in this spot. So you end up
with an "effective config" which you can see with "-o fullconf" option.
This config is intepreted (we're still talking about reading config,
not processing events!) from the top to bottom so that for most
things if you have some dependency, it must be defined earlier (like
you must have a lookup defined earlier in the config to be able to
call that lookup later).
Then comes the part of event processing - if some operation is not
defined within a specific ruleset it's assumed to be in an implicit
"main" ruleset. And similarily - if an input is not associated with a
specific ruleset, events received by that input are processed by that
implicit main ruleset.
BTW, if you're planning on just dropping the events from the
vulnerability scanners you could just drop events on this one port
but I don't know your precise circumstances. It's just that it seems
that you're trying to overengineer something that could be much
simpler ;-)
MK
On 9.12.2022 13:15, Steven D wrote:
Thanks for all the input, ok so some answers inline
Nope - So this looks straight forward to me, but correct some
ignorance on my end. The way you've defined the "syslogtag" rulesets,
it makes me assume that the syslog config processed in a top down
manner, otherwise logically it doesn't work.
Is that true?
The way we have our syslog config set up is to group all the related
template/ruleset/input stanzas together... Just from an ease of
modification PoV it makes it easier.
Kurk Mariusz - I don't have control over the sending hosts, they are
vulnerability scanners that indiscriminately scan the environment. I
can't just iptable drop those same devices from touching the syslog
servers as that will cause other operational issues.
________________________________
From: rsyslog
<rsyslog-boun...@lists.adiscon.com><mailto:rsyslog-boun...@lists.adiscon.com>
on behalf of Mariusz Kruk via rsyslog
<rsyslog@lists.adiscon.com><mailto:rsyslog@lists.adiscon.com>
Sent: Friday, December 9, 2022 5:30 AM
To: rsyslog@lists.adiscon.com<mailto:rsyslog@lists.adiscon.com>
<rsyslog@lists.adiscon.com><mailto:rsyslog@lists.adiscon.com>
Cc: Mariusz Kruk <k...@epsilon.eu.org><mailto:k...@epsilon.eu.org>
Subject: Re: [rsyslog] "Global" fromhost-ip blocklist?
I know that it has already been answered but let me add my three
cents ;-)
Firstly, adding condition to $fromhost-ip suggests that you want to
limit based on the source IP, not on the event's content. Which raises
the question - why not simply _not_ send from that host? Or at least
filter it out on the local firewall (most probably iptables).
Secondly, expanding on nope's response - you can have multiple rulesets
chained together so that you have some common "subroutine" and then
branch to specific ruleset depending on how you want to process given
source or data type. You can use lookups or conditions to dynamically
decide to which ruleset you want to route your event to. The
possibilities are endless :-) (and you can end up creating a ruleset
loop and crashing your rsyslogd XD)
Something like.
ruleset(name="ruleset1") {
set $.destination_ruleset="dest1";
call intermediate_ruleset
}
ruleset(name="ruleset2") {
set $.destination_ruleset="dest2";
call intermediate_ruleset
}
ruleset(name="intermediate_ruleset") {
set $.this=$that;
// and other stuff
call_indirect $.destination_ruleset;
}
ruleset(name="dest1") {
...
}
ruleset(name="dest2") {
...
}
MK
On 8.12.2022 16:15, Steven D via rsyslog wrote:
Rsyslog gurus
I have a config that accepts connections from remote hosts and
steers logs to files based on port. Pretty straightforward... what
i'm looking to do is "globally" prevent certain ip addresses from
ending up in the logs. (Internal vulnerability scanners I have no
control over).
I've tried a few different ways but not coming across anything that
works globally. Adding something like "if $fromhost-ip '1.2.3.4'
then stop" works just fine on an individual ruleset.
Is there a way I can do this without having to enter duplicate lines
in every ruleset (I have like 30 rulesets) ?
Thanks,
Steven
Config snippet below: "#logname01/02#" is replaced by the relevant
product in the configuration.
module(load="imudp")
module(load="imtcp" MaxListeners="100" AddtlFrameDelimiter="000"
KeepAlive="on" KeepAlive.Probes="1" KeepAlive.Time="10")
input(type="imudp" port="24514" ruleset="#logname01#_rule")
input(type="imtcp" port="24514" ruleset="#logname01#_rule")
template(name="#logname01#_logs" type="string"
string="/data/logs/#logname01#/24514/%fromhost-ip%/syslog.log")
ruleset(name="#logname01#_rule") {
action(name="#logname01#_rule"
type="omfile"
FileCreateMode="0744"
DirCreateMode="0755"
FileOwner="SIEM"
FileGroup="SIEM"
DirOwner="SIEM"
DirGroup="SIEM"
DynaFile="#logname01#_logs"
DynaFileCacheSize = "50")
}
input(type="imudp" port="25514" ruleset="#logname02#_rule")
input(type="imtcp" port="25514" ruleset="#logname02#_rule")
template(name="#logname02#_logs" type="string"
string="/data/logs/#logname02#/25514/%fromhost-ip%/syslog.log")
ruleset(name="#logname02#_rule") {
action(name="#logname02#_rule"
type="omfile"
FileCreateMode="0744"
DirCreateMode="0755"
FileOwner="SIEM"
FileGroup="SIEM"
DirOwner="SIEM"
DirGroup="SIEM"
DynaFile="#logname02#_logs"
DynaFileCacheSize = "50")
}
_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a
myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT
POST if you DON'T LIKE THAT.
_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a
myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT
POST if you DON'T LIKE THAT.
_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a
myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT
POST if you DON'T LIKE THAT.
