That is a correct assessment of the flow. There is no impstats output. The line in the conf is: module (load="impstats" log.file="/var/spool/rsyslog/stats.log")
There is no file created whether on 514 or 10000. ________________________________________ From: [email protected] [[email protected]] on behalf of Dave Caplinger [[email protected]] Sent: Thursday, October 08, 2015 2:28 PM To: rsyslog-users Subject: Re: [rsyslog] Complex forwarding and spoofing question I'm not sure I follow... here's what I think you've built based on the thread so far: Your entire log forwarding path looks like: Source --> Loghost --{VPN}--> Collector --> SEIM A B C D E (This is entirely reasonable; we do something similar. So similar, I want to make sure I'm not reading too much into what you've described!) 1) Within a single Site 'N', log sources (A) send their logs to an rsyslog box I've called "loghost" (B) via either udp/514 or tcp/514 Sources ----[ udp/tcp 514 ]---> loghost A B 2) There is some kind of VPN connection between each Site 'N' and a central site { Site n } ----[ VPN Tunnel ]---> { Central Site } 3) Rsyslog on the site loghost (B) forwards logs to: a) legacy syslog on localhost (B) [for backwards compatibility?] via udp/515 w/ spoofing b) a remote centralized "collector" (D) via stream-compressed tcp/514 loghost ----[ tcp/514 + compress ]---> collector B D 4) The central "collector" accepts log feeds from multiple sites and forwards them to one of several TCP ports on a SEIM (E) based on IP address of the sending loghost (which is unique per Site) collector ----[ tcp/1000x ]---> SEIM D E So if I understand correctly, we've gone through the configs for points (B) and (D) and everything is working up to the "collector" (D) and you're having trouble getting it to talk to the SEIM (E). Therefore, the problem lies somewhere in the connection from point (D) to point (E). You've looked at whether (E) is really listening on port 1000x; and whether you can telnet from (D) to (E) on tcp port 1000x; so next: find out if (D) really has any data to send. Look at the impstats output from the queues at point (D). Are the queues that send to the SEIM getting any messages at all, or is size=0 still? If those queues are non-empty (and growing), the next thing I'd suspect is that the receiving SEIM doesn't recognize the traffic as syslog. It may require a different output template at (D) to convert the logs into something the SEIM will understand. -- Dave Caplinger, Director, Technical Product Management Solutionary — An NTT Group Security Company > On Oct 8, 2015, at 3:07 PM, Randy Baca <[email protected]> wrote: > > That rule works better, but I still cannot get rsyslog to forward on port > 10000. I turned off iptables, I can make a telnet connection to the remote > host on 10000, but rsyslog will not even attempt to connect to the remote > host on 10000. It works just fine if the omfwd port="514" and protocol="tcp". > > Regards, > > > > Randy Baca > > ________________________________________ > From: [email protected] [[email protected]] > on behalf of Dave Caplinger [[email protected]] > Sent: Thursday, October 08, 2015 9:07 AM > To: rsyslog-users > Subject: Re: [rsyslog] Complex forwarding and spoofing question > > Regarding the config: > > We do something very similar; using your example it would look like: > > > ruleset(name="ruleset_eth0_514" > queue.type="LinkedList") { > if $fromhost-ip == ["1.2.3.4"] then { call action.fwd.remote10000 } > if $fromhost-ip == ["2.3.4.5"] then { call action.fwd.remote10001 } > if $fromhost-ip == ["3.4.5.6"] then { call action.fwd.remote10002 } > if $fromhost-ip == ["4.5.6.7"] then { call action.fwd.remote10003 } > stop > } > > We use [] because we often have more than one IP address to match there; in > that case just separate them with commas like: > > if $fromhost-ip == ["1.1.1.1", "2.2.2.2"] then { > call action.whatever > stop > } > > If you literally only have the one IP to match, you don't need the [] of > course. Also, we put the stop inside the 'then' clause to be explicit about > our intent that logs go to this one destination and nowhere else; in your > given example a single $fromhost-ip address can't match more than one of > these cases, but if you (or someone else) later add a different filter on > something else like message content, you may be surprised and wind up > duplicating some 'site A' logs into the 'site B' log feed on your SEIM. > > > As for TCP connectivity to the SEIM: > > What does impstats say is happening to the omfwd.remote10000, etc. queues? > Are the queue sizes growing? It's possible that rsyslog is not connecting to > tcp 10.2.2.2:10000 because nothing is matching your filter, so there's > nothing in-queue to deliver there. > > -- > Dave Caplinger, Director, Technical Product Management > Solutionary — An NTT Group Security Company > >> On Oct 8, 2015, at 10:40 AM, Randy Baca <[email protected]> wrote: >> >> Is this a viable configuration? Why will rsyslog not attempt connection to >> the remote host on tcp/10000? We have not attempted connections other than >> the first port, 10000. >> >> Regards, >> >> >> >> Randy Baca >> >> ________________________________________ >> From: [email protected] [[email protected]] >> on behalf of Randy Baca [[email protected]] >> Sent: Wednesday, October 07, 2015 3:03 PM >> To: rsyslog-users >> Subject: [Suspected SPAM] Re: [rsyslog] [Suspected SPAM] Re: >> [Suspected SPAM] Re: Complex forwarding and spoofing question >> >> Since multiple sites can have the same IP address range we need to send to >> different ports depending on the from-IP (the rsyslog sender NAT IP which >> will always be a public IP). I am not sure about the conditional syntax, >> but it will end up looking something like the below. All sites will have an >> assigned port so the SEIM can differentiate between them. >> >> module (load="imklog") >> module (load="imuxsock") >> module (load="imptcp") >> module (load="impstats" >> log.file="/var/spool/rsyslog_tcp/stats.log") >> >> # In >> input(type="imptcp" >> address="10.1.1.1" >> port="514" >> compression.mode="stream:always" >> ruleset="ruleset_eth0_514") >> >> # Out >> ruleset(name="ruleset_eth0_514" >> queue.type="LinkedList") { >> if %fromhost-ip% == "1.2.3.4" call action.fwd.remote10000 >> if %fromhost-ip% == "2.3.4.5" call action.fwd.remote10001 >> if %fromhost-ip% == "3.4.5.6" call action.fwd.remote10002 >> if %fromhost-ip% == "4.5.6.7" call action.fwd.remote10003 >> stop >> } >> >> # Fwd to 10000 >> ruleset(name="action.fwd.remote10000") { >> action(type="omfwd" >> name="omfwd.remote10000" >> queue.type="LinkedList" >> queue.filename="omfwd_remote10000" >> queue.size="10000" >> queue.maxdiskspace="2G" >> queue.saveonshutdown="on" >> action.resumeretrycount="-1" >> target="10.2.2.2" >> port="10000" >> protocol="tcp" >> compression.mode="none") >> } >> # Fwd to 10001 >> ruleset(name="action.fwd.remote10001") { >> action(type="omfwd" >> name="omfwd.remote10001" >> queue.type="LinkedList" >> queue.filename="omfwd_remote10001" >> queue.size="10000" >> queue.maxdiskspace="2G" >> queue.saveonshutdown="on" >> action.resumeretrycount="-1" >> target="10.2.2.2" >> port="10001" >> protocol="tcp" >> compression.mode="none") >> } >> # Fwd to 10002 >> ruleset(name="action.fwd.remote10002") { >> action(type="omfwd" >> name="omfwd.remote10002" >> queue.type="LinkedList" >> queue.filename="omfwd_remote10002" >> queue.size="10000" >> queue.maxdiskspace="2G" >> queue.saveonshutdown="on" >> action.resumeretrycount="-1" >> target="10.2.2.2" >> port="10002" >> protocol="tcp" >> compression.mode="none") >> } >> # Fwd to 10003 >> ruleset(name="action.fwd.remote10003") { >> action(type="omfwd" >> name="omfwd.remote100003" >> queue.type="LinkedList" >> queue.filename="omfwd_remote10003" >> queue.size="10000" >> queue.maxdiskspace="2G" >> queue.saveonshutdown="on" >> action.resumeretrycount="-1" >> target="10.2.2.2" >> port="10003" >> protocol="tcp" >> compression.mode="none") >> } >> >> ________________________________________ >> From: [email protected] [[email protected]] >> on behalf of David Lang [[email protected]] >> Sent: Wednesday, October 07, 2015 2:43 PM >> To: rsyslog-users >> Subject: [Suspected SPAM] Re: [rsyslog] [Suspected SPAM] Re: Complex >> forwarding and spoofing question >> >> On Wed, 7 Oct 2015, Randy Baca wrote: >> >>> The reason for the nested rules is eventually we will have to identify the >>> remote sites by the VPN tunnel IP of the sending host. The remote sites >>> have >>> overlapping IP spaces so we don't know which site it is based solely on the >>> originating IP. The SEIM can separate the sites by listener port so we were >>> going to add conditional rules to separate the sites by port when sending to >>> the SEIM. If you have any ideas about how to do this better then I am all >>> ears. >> >> I'm still not understanding how nested rulesets help If the data is going out >> one connection, what's the difference between: >> >>>> # Out >>>> ruleset(name="ruleset_eth0_10000" >>>> queue.type="LinkedList") { >>>> call action.fwd.remotebox >>>> stop >>>> } >>>> >>>> # Fwd to remotebox w/ compression and local disk queueing >>>> ruleset(name="action.fwd.remotebox") { >>>> action(type="omfwd" >>>> name="omfwd.remotebox" >>>> queue.type="LinkedList" >>>> queue.filename="omfwd_remotebox" >>>> queue.size="10000" >>>> queue.maxdiskspace="30G" >>>> queue.saveonshutdown="on" >>>> action.resumeretrycount="-1" >>>> target="10.2.2.2" >>>> port="10000" >>>> protocol="tcp") >>>> compression.mode="none") >>>> } >> >> and >> >>>> # Out >>>> ruleset(name="ruleset_eth0_10000" >>>> queue.type="LinkedList") { >>>> action(type="omfwd" >>>> name="omfwd.remotebox" >>>> queue.type="LinkedList" >>>> queue.filename="omfwd_remotebox" >>>> queue.size="10000" >>>> queue.maxdiskspace="30G" >>>> queue.saveonshutdown="on" >>>> action.resumeretrycount="-1" >>>> target="10.2.2.2" >>>> port="10000" >>>> protocol="tcp") >>>> compression.mode="none") >>>> stop >>>> } >> >> ? >> >> Also, if the senders have overlapping IP addresses, you are going to have fun >> receiving from them. But if you can, then you have the $inputname that you >> can >> use to tell them apart, and if your SIEM supports it, you can put that in the >> message to the SIEM. >> >> David Lang >> >>> Regards, >>> >>> >>> >>> Randy Baca >>> >>> ________________________________________ >>> From: [email protected] [[email protected]] >>> on behalf of David Lang [[email protected]] >>> Sent: Wednesday, October 07, 2015 2:01 PM >>> To: rsyslog-users >>> Subject: [Suspected SPAM] Re: [rsyslog] Complex forwarding and >>> spoofing question >>> >>> rsyslog is not going to try to connect until it has a message to deliver to >>> that >>> destination. >>> >>> why are you nesting rulesets like this? I think you are just confusing >>> yourself >>> here. >>> >>> David Lang >>> >>> On Wed, 7 Oct 2015, Randy Baca wrote: >>> >>>> Date: Wed, 7 Oct 2015 20:56:50 +0000 >>>> From: Randy Baca <[email protected]> >>>> Reply-To: rsyslog-users <[email protected]> >>>> To: rsyslog-users <[email protected]> >>>> Subject: Re: [rsyslog] Complex forwarding and spoofing question >>>> >>>> That resolved the compression issue. Thank you. >>>> >>>> It works great if we forward to tcp/514, but we can't change the port from >>>> 514 to the actual listening port of the SEIM on tcp/10000. I can telnet >>>> to the SEIM on port tcp/10000 from the rsyslog server so I know it is >>>> listening. Tcpdump shows my connection attempts, but rsyslog appears to >>>> not even attempt the connection. >>>> >>>> This is the config for the forwarder. >>>> >>>> # Out >>>> ruleset(name="ruleset_eth0_10000" >>>> queue.type="LinkedList") { >>>> call action.fwd.remotebox >>>> stop >>>> } >>>> >>>> # Fwd to remotebox w/ compression and local disk queueing >>>> ruleset(name="action.fwd.remotebox") { >>>> action(type="omfwd" >>>> name="omfwd.remotebox" >>>> queue.type="LinkedList" >>>> queue.filename="omfwd_remotebox" >>>> queue.size="10000" >>>> queue.maxdiskspace="30G" >>>> queue.saveonshutdown="on" >>>> action.resumeretrycount="-1" >>>> target="10.2.2.2" >>>> port="10000" >>>> protocol="tcp") >>>> compression.mode="none") >>>> } >>>> >>>> >>>> ________________________________________ >>>> From: [email protected] >>>> [[email protected]] on behalf of Dave Caplinger >>>> [[email protected]] >>>> Sent: Wednesday, October 07, 2015 11:36 AM >>>> To: rsyslog-users >>>> Subject: [Suspected SPAM] Re: [rsyslog] Complex forwarding and >>>> spoofing question >>>> >>>> For example: >>>> >>>> # In: 514/TCP >>>> input(type="imptcp" >>>> address="10.1.1.1" >>>> port="514" >>>> compression.mode="stream:always" >>>> ruleset="ruleset_eth0_514") >>>> >>>> ( see >>>> http://www.rsyslog.com/doc/v8-stable/configuration/modules/imptcp.html ) >>>> >>>> Remember that once you do this, EVERYTHING sending to 10.1.1.1 on tcp/514 >>>> must use compression. >>>> >>>> -- >>>> Dave Caplinger, Director, Technical Product Management >>>> Solutionary — An NTT Group Security Company >>>> >>>>> On Oct 7, 2015, at 1:21 PM, David Lang <[email protected]> wrote: >>>>> >>>>> On Wed, 7 Oct 2015, Randy Baca wrote: >>>>> >>>>>> Changed the module and input type to imptcp. Still forwarding garbled >>>>>> messages. >>>>> >>>>> did you enable compression.mode = always on the imptcp input? >>>>> >>>>> David Lang >>>>> >>>>>> Regards, >>>>>> >>>>>> >>>>>> >>>>>> Randy Baca >>>>>> >>>>>> ________________________________________ >>>>>> From: [email protected] >>>>>> [[email protected]] on behalf of David Lang >>>>>> [[email protected]] >>>>>> Sent: Wednesday, October 07, 2015 10:49 AM >>>>>> To: rsyslog-users >>>>>> Subject: Re: [rsyslog] Complex forwarding and spoofing question >>>>>> >>>>>> On Wed, 7 Oct 2015, Randy Baca wrote: >>>>>> >>>>>>> The sender is using default compression with stream:always. The >>>>>>> receiver is >>>>>>> configured like this: >>>>>> >>>>>> if the sender is doing compression stream:always, then the receiver >>>>>> needs to do >>>>>> the same thing (which means you need to use imptcp, not imtcp) >>>>>> >>>>>> David Lang >>>>>> >>>>>>> module (load="imklog") >>>>>>> module (load="imuxsock") >>>>>>> module (load="imtcp") >>>>>>> module (load="impstats" >>>>>>> log.file="/var/spool/rsyslog/stats.log") >>>>>>> >>>>>>> # In: 514/TCP >>>>>>> input(type="imtcp" >>>>>>> address="10.1.1.1" >>>>>>> port="514" >>>>>>> ruleset="ruleset_eth0_514") >>>>>>> >>>>>>> # Out: SEIM >>>>>>> ruleset(name="ruleset_eth0_514" >>>>>>> queue.type="LinkedList") { >>>>>>> call action.fwd.remotebox >>>>>>> stop >>>>>>> } >>>>>>> >>>>>>> # Fwd to remotebox >>>>>>> ruleset(name="action.fwd.remotebox") { >>>>>>> action(type="omfwd" >>>>>>> name="omfwd.remotebox" >>>>>>> queue.type="LinkedList" >>>>>>> queue.filename="omfwd_remotebox" >>>>>>> queue.size="10000" >>>>>>> queue.maxdiskspace="30G" >>>>>>> queue.saveonshutdown="on" >>>>>>> action.resumeretrycount="-1" >>>>>>> target="10.2.2.2" >>>>>>> port="514" >>>>>>> protocol="tcp" >>>>>>> compression.mode="none") >>>>>>> } >>>>>>> >>>>>>> ________________________________________ >>>>>>> From: [email protected] >>>>>>> [[email protected]] on behalf of David Lang >>>>>>> [[email protected]] >>>>>>> Sent: Wednesday, October 07, 2015 10:34 AM >>>>>>> To: rsyslog-users >>>>>>> Subject: Re: [rsyslog] Complex forwarding and spoofing question >>>>>>> >>>>>>> On Wed, 7 Oct 2015, Randy Baca wrote: >>>>>>> >>>>>>>> We were able to get the stream working but now we have new issues. >>>>>>>> For one, >>>>>>>> the streams are coming across garbled due to the compression, which is >>>>>>>> expected. How do we decompress the streams prior to forwarding them >>>>>>>> again? >>>>>>>> Some of the events will be forwarded to our long term storage and some >>>>>>>> to our >>>>>>>> SEIM but they are not being recognized. >>>>>>> >>>>>>> you have to set the compression mode on the receiver as well as on the >>>>>>> sender. >>>>>>> >>>>>>> David Lang >>>>>>> >>>>>>>> ________________________________________ >>>>>>>> From: [email protected] >>>>>>>> [[email protected]] on behalf of David Lang >>>>>>>> [[email protected]] >>>>>>>> Sent: Wednesday, October 07, 2015 7:07 AM >>>>>>>> To: rsyslog-users >>>>>>>> Subject: Re: [rsyslog] Complex forwarding and spoofing question >>>>>>>> >>>>>>>> On Wed, 7 Oct 2015, Dave Caplinger wrote: >>>>>>>> >>>>>>>>> A couple of things come to mind: >>>>>>>>> >>>>>>>>> 1) enable pstats: >>>>>>>>> >>>>>>>>> module(load="impstats" interval="600") >>>>>>>>> >>>>>>>>> (you may want a smaller interval such as 60 seconds instead) >>>>>>>>> >>>>>>>>> 2) modify your output ruleset to send the pstats logs to their own >>>>>>>>> file; this is one way: >>>>>>>> >>>>>>>> you can give a ruleset in the module load line rather than having to >>>>>>>> use a >>>>>>>> filter. >>>>>>>> >>>>>>>> David Lang >>>>>>>> >>>>>>>>> # Out: UDP-spoof to the local and also forward to remote rsyslog >>>>>>>>> ruleset(name="ruleset_eth0_514" >>>>>>>>> queue.type="LinkedList") { >>>>>>>>> if $syslogtag contains 'rsyslogd-pstats' then { >>>>>>>>> action(type="omfile" >>>>>>>>> queue.type="LinkedList" >>>>>>>>> name="pstats" >>>>>>>>> file="/var/log/pstats" >>>>>>>>> ) >>>>>>>>> stop >>>>>>>>> } >>>>>>>>> call action.local.udp515 >>>>>>>>> call action.fwd.remotebox >>>>>>>>> stop >>>>>>>>> } >>>>>>>>> >>>>>>>>> (This prevents the rsyslog-pstats lines from being sent to your other >>>>>>>>> local UDP syslog or to the remote server.) >>>>>>>>> >>>>>>>>> 3) Fire up rsyslog and watch /var/log/pstats. >>>>>>>>> >>>>>>>>> Most likely you'll see the output queue (omfwd.remotebox) grow until >>>>>>>>> it hits the highwatermark (default 90% of queue.size) which triggers >>>>>>>>> disk-assist mode, which it sounds like you never leave since it >>>>>>>>> doesn't drop to the lowwatermark (default 70% of queue.size). >>>>>>>>> >>>>>>>>> Since your issue seems to be with sending to the remote; make sure >>>>>>>>> that remote rsyslog receiver is also configured for >>>>>>>>> compression.mode="stream:always" like this sender. This setting is >>>>>>>>> all-or-nothing; rsyslog cannot dynamically determine if the sender is >>>>>>>>> using stream compression or not. So if you have multiple senders all >>>>>>>>> shipping logs to a receiver that is configured for stream >>>>>>>>> compression, they all must use stream compression. (You could >>>>>>>>> support compressed and non-compressed inputs on different ports or >>>>>>>>> interfaces if necessary.) >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Dave Caplinger, Director, Technical Product Management >>>>>>>>> Solutionary — An NTT Group Security Company >>>>>>>>> >>>>>>>>>> On Oct 6, 2015, at 3:35 PM, Randy Baca <[email protected]> wrote: >>>>>>>>>> >>>>>>>>>> OK, I got everything updated and we are up and running. >>>>>>>>>> >>>>>>>>>> However, there appears to be an issue with disk queuing. When we >>>>>>>>>> fire up rsyslog the remotebox is only receiving a short burst of >>>>>>>>>> events for a few seconds and then about 1 or 2 events per second >>>>>>>>>> after that. After the few seconds when the burst is over the disk >>>>>>>>>> queue on the local system then starts creating spool files. They >>>>>>>>>> don't appear to be flushing. The local system receives about 1k >>>>>>>>>> events per second. They are all making it to the local UDP spoof >>>>>>>>>> but not the remotebox, even after playing around with the queue >>>>>>>>>> settings. >>>>>>>>>> >>>>>>>>>> Here is the current conf: >>>>>>>>>> >>>>>>>>>> module (load="imklog") >>>>>>>>>> module (load="imuxsock") >>>>>>>>>> module (load="imudp") >>>>>>>>>> module (load="imtcp") >>>>>>>>>> module (load="omudpspoof") >>>>>>>>>> >>>>>>>>>> # Global Configuration >>>>>>>>>> global ( >>>>>>>>>> parser.escapeControlCharactersCStyle="on" >>>>>>>>>> workDirectory="/var/spool/rsyslog" >>>>>>>>>> localHostname="hostname" >>>>>>>>>> ) >>>>>>>>>> >>>>>>>>>> # In: 514/TCP (uses the same queue as UDP) >>>>>>>>>> input(type="imtcp" >>>>>>>>>> address="10.1.2.3" >>>>>>>>>> port="514" >>>>>>>>>> ruleset="ruleset_eth0_514") >>>>>>>>>> >>>>>>>>>> # In: 514/UDP (uses the same queue as TCP) >>>>>>>>>> input(type="imudp" >>>>>>>>>> address="10.1.2.3" >>>>>>>>>> port="514" >>>>>>>>>> ruleset="ruleset_eth0_514") >>>>>>>>>> >>>>>>>>>> # Out: UDP-spoof to the local and also forward to remote rsyslog >>>>>>>>>> ruleset(name="ruleset_eth0_514" >>>>>>>>>> queue.type="LinkedList") { >>>>>>>>>> call action.local.udp515 >>>>>>>>>> call action.fwd.remotebox >>>>>>>>>> stop >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> # Fwd to localhost:udp/515 >>>>>>>>>> ruleset(name="action.local.udp515") { >>>>>>>>>> action(type="omudpspoof" >>>>>>>>>> name="omudpspoof.udp515" >>>>>>>>>> target="127.0.0.1" >>>>>>>>>> port="515") >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> # Fwd to remotebox w/ compression and local disk queueing >>>>>>>>>> ruleset(name="action.fwd.remotebox") { >>>>>>>>>> action(type="omfwd" >>>>>>>>>> name="omfwd.remotebox" >>>>>>>>>> queue.spoolDirectory="/var/spool/rsyslog_tcp" >>>>>>>>>> # queue.lowwatermark="2000" >>>>>>>>>> # queue.highwatermark="1000000" >>>>>>>>>> queue.workerthreads="2" >>>>>>>>>> # queue.type="Disk" >>>>>>>>>> queue.type="LinkedList" >>>>>>>>>> # queue.filename="omfwd_remotebox" >>>>>>>>>> # queue.size="100000" >>>>>>>>>> queue.maxdiskspace="20G" >>>>>>>>>> queue.saveonshutdown="on" >>>>>>>>>> action.resumeretrycount="-1" >>>>>>>>>> target="172.22.22.22" >>>>>>>>>> port="514" >>>>>>>>>> protocol="tcp" >>>>>>>>>> compression.mode="stream:always") >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ________________________________________ >>>>>>>>>> From: [email protected] >>>>>>>>>> [[email protected]] on behalf of Dave Caplinger >>>>>>>>>> [[email protected]] >>>>>>>>>> Sent: Monday, October 05, 2015 5:40 AM >>>>>>>>>> To: rsyslog-users >>>>>>>>>> Subject: Re: [rsyslog] Complex forwarding and spoofing question >>>>>>>>>> >>>>>>>>>> David's right, it's a separate package. Sorry about that. Here's a >>>>>>>>>> list of all the 64-bit rsyslog packages (from 'yum search rsyslog') >>>>>>>>>> from a system I have access to; please verify you see something >>>>>>>>>> similar from yours. >>>>>>>>>> >>>>>>>>>> rsyslog-gnutls.x86_64 : TLS protocol support for rsyslog >>>>>>>>>> rsyslog-gssapi.x86_64 : GSSAPI authentication and encryption support >>>>>>>>>> for rsyslog >>>>>>>>>> rsyslog-mysql.x86_64 : MySQL support for rsyslog >>>>>>>>>> rsyslog-pgsql.x86_64 : PostgresSQL support for rsyslog >>>>>>>>>> rsyslog-relp.x86_64 : RELP protocol support for rsyslog >>>>>>>>>> rsyslog-snmp.x86_64 : SNMP protocol support for rsyslog >>>>>>>>>> rsyslog.x86_64 : Enhanced system logging and kernel message trapping >>>>>>>>>> daemons >>>>>>>>>> rsyslog-elasticsearch.x86_64 : Provides the omelasticsearch module >>>>>>>>>> rsyslog-mmjsonparse.x86_64 : mmjsonparse support >>>>>>>>>> rsyslog-mmutf8fix.x86_64 : mmutf8fix support >>>>>>>>>> rsyslog-udpspoof.x86_64 : Provides the omudpspoof module >>>>>>>>>> >>>>>>>>>> Then, of course: 'yum install rsyslog-udpspoof'. >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Dave Caplinger, Director, Technical Product Management | >>>>>>>>>> 402.361.3063 | Solutionary — An NTT Group Security Company >>>>>>>>>> >>>>>>>>>>> On Oct 3, 2015, at 1:02 AM, David Lang <[email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>> It may be a separate package (I don't know how to query this >>>>>>>>>>> through yum) >>>>>>>>>>> >>>>>>>>>>> in the meantime, try addding the following >>>>>>>>>>> >>>>>>>>>>> $template raw,"%rawmsg%" >>>>>>>>>>> >>>>>>>>>>> and then change the forwarding via localhost from omudpspoof to udp >>>>>>>>>>> with the template raw. >>>>>>>>>>> >>>>>>>>>>> David Lang >>>>>>>>>>> >>>>>>>>>>> On Fri, 2 Oct 2015, Randy Baca wrote: >>>>>>>>>>> >>>>>>>>>>>> Date: Fri, 2 Oct 2015 23:46:27 +0000 >>>>>>>>>>>> From: Randy Baca <[email protected]> >>>>>>>>>>>> Reply-To: rsyslog-users <[email protected]> >>>>>>>>>>>> To: rsyslog-users <[email protected]> >>>>>>>>>>>> Subject: Re: [rsyslog] Complex forwarding and spoofing question >>>>>>>>>>>> Upgraded to 8.13. Looks like now the omudpspoof.so file is >>>>>>>>>>>> missing. Does it not get installed automatically with the >>>>>>>>>>>> upgrade? I checked in /lib64/rsyslog/ and it is not there. It >>>>>>>>>>>> also didn't like the number I had set for the highwatermark so I >>>>>>>>>>>> removed it, and now this is the only error left. >>>>>>>>>>>> >>>>>>>>>>>> [root@host etc]# /sbin/rsyslogd -N2 >>>>>>>>>>>> rsyslogd: version 8.13.0, config validation run (level 2), master >>>>>>>>>>>> config /etc/rsyslog.conf >>>>>>>>>>>> rsyslogd: could not load module '/lib64/rsyslog/omudpspoof.so', >>>>>>>>>>>> dlopen: /lib64/rsyslog/omudpspoof.so: cannot open shared object >>>>>>>>>>>> file: No such file or directory [v8.13.0 try >>>>>>>>>>>> http://www.rsyslog.com/e/2066 ] >>>>>>>>>>>> rsyslogd: module name 'omudpspoof' is unknown [v8.13.0 try >>>>>>>>>>>> http://www.rsyslog.com/e/2209 ] >>>>>>>>>>>> rsyslogd: error during parsing file /etc/rsyslog.conf, on or >>>>>>>>>>>> before line 32: errors occured in file '/etc/rsyslog.conf' around >>>>>>>>>>>> line 32 [v8.13.0 try http://www.rsyslog.com/e/2207 ] >>>>>>>>>>>> >>>>>>>>>>>> module (load="imklog") >>>>>>>>>>>> module (load="imuxsock") >>>>>>>>>>>> module (load="imudp") >>>>>>>>>>>> module (load="imtcp") >>>>>>>>>>>> Module (load="omudpspoof") >>>>>>>>>>>> # In: 514/TCP (uses the same queue as UDP) >>>>>>>>>>>> input(type="imtcp" >>>>>>>>>>>> address="10.1.2.3" >>>>>>>>>>>> port="514" >>>>>>>>>>>> ruleset="ruleset_eth0_514") >>>>>>>>>>>> # In: 514/UDP (uses the same queue as TCP) >>>>>>>>>>>> input(type="imudp" >>>>>>>>>>>> address="10.1.2.3" >>>>>>>>>>>> port="514" >>>>>>>>>>>> ruleset="ruleset_eth0_514") >>>>>>>>>>>> # Out: UDP-spoof to the local and also forward to remote rsyslog >>>>>>>>>>>> ruleset(name="ruleset_eth0_514" >>>>>>>>>>>> queue.type="LinkedList") { >>>>>>>>>>>> call action.local.udp515 >>>>>>>>>>>> call action.fwd.remotebox >>>>>>>>>>>> stop >>>>>>>>>>>> } >>>>>>>>>>>> # Fwd to localhost:udp/515 >>>>>>>>>>>> ruleset(name="action.local.udp515") { >>>>>>>>>>>> action(type="omudpspoof" >>>>>>>>>>>> name="omudpspoof.udp515" >>>>>>>>>>>> target="127.0.0.1" >>>>>>>>>>>> port="515") >>>>>>>>>>>> } >>>>>>>>>>>> # Fwd to remotebox w/ compression and local disk queueing >>>>>>>>>>>> ruleset(name="action.fwd.remotebox") { >>>>>>>>>>>> action(type="omfwd" >>>>>>>>>>>> name="omfwd.remotebox" >>>>>>>>>>>> queue.type="LinkedList" >>>>>>>>>>>> queue.filename="omfwd_remotebox" >>>>>>>>>>>> queue.size="10000" >>>>>>>>>>>> queue.maxdiskspace="2G" >>>>>>>>>>>> queue.saveonshutdown="on" >>>>>>>>>>>> action.resumeretrycount="-1" >>>>>>>>>>>> target="172.22.22.22" >>>>>>>>>>>> port="514" >>>>>>>>>>>> protocol="tcp" >>>>>>>>>>>> compression.mode="stream:always") >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ________________________________________ >>>>>>>>>>>> From: [email protected] >>>>>>>>>>>> [[email protected]] on behalf of Dave Caplinger >>>>>>>>>>>> [[email protected]] >>>>>>>>>>>> Sent: Friday, October 02, 2015 2:40 PM >>>>>>>>>>>> To: rsyslog-users >>>>>>>>>>>> Subject: Re: [rsyslog] Complex forwarding and spoofing question >>>>>>>>>>>> >>>>>>>>>>>> I think stream compression was added to rsyslog around version 7.2 >>>>>>>>>>>> or so. If i recall correctly, CentOS 6 includes rsyslog v5.8, so >>>>>>>>>>>> you'll definitely want to upgrade your rsyslog version. >>>>>>>>>>>> >>>>>>>>>>>> See http://www.rsyslog.com/rhelcentos-rpms/ for instructions on >>>>>>>>>>>> how to add the v8-stable repo to your /etc/yum.repos.d/ directory. >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Dave Caplinger, Director, Technical Product Management | >>>>>>>>>>>> 402.361.3063 | Solutionary — An NTT Group Security Company >>>>>>>>>>>> >>>>>>>>>>>>> On Oct 2, 2015, at 12:35 PM, Randy Baca <[email protected]> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks for the conf validation switch. Looks like we have a >>>>>>>>>>>>> compatibility issue. Most of our existing syslog servers are >>>>>>>>>>>>> running on CentOS 6. Will an upgrade of rsyslog resolve this, or >>>>>>>>>>>>> do we need to convert the conf to legacy? >>>>>>>>>>>>> >>>>>>>>>>>>> module(load="imklog") >>>>>>>>>>>>> module(load="imuxsock") >>>>>>>>>>>>> module(load="imudp") >>>>>>>>>>>>> module(load="imtcp") >>>>>>>>>>>>> # In: 514/TCP (uses the same queue as UDP) >>>>>>>>>>>>> input(type="imtcp" >>>>>>>>>>>>> address="10.1.2.3" >>>>>>>>>>>>> port="514" >>>>>>>>>>>>> ruleset="ruleset_eth0_514") >>>>>>>>>>>>> # In: 514/UDP (uses the same queue as TCP) >>>>>>>>>>>>> input(type="imudp" >>>>>>>>>>>>> address="10.1.2.3" >>>>>>>>>>>>> port="514" >>>>>>>>>>>>> ruleset="ruleset_eth0_514") >>>>>>>>>>>>> # Out: UDP-spoof to the local and also forward to remote rsyslog >>>>>>>>>>>>> ruleset(name="ruleset_eth0_514" >>>>>>>>>>>>> queue.highwatermark 50000 >>>>>>>>>>>>> queue.fulldelaymark 20000 >>>>>>>>>>>>> queue.lowwatermark 2000 >>>>>>>>>>>>> queue.type="LinkedList") { >>>>>>>>>>>>> call action.local.udp515 >>>>>>>>>>>>> call action.fwd.remotebox >>>>>>>>>>>>> stop >>>>>>>>>>>>> } >>>>>>>>>>>>> # Fwd to localhost:udp/515 >>>>>>>>>>>>> ruleset(name="action.local.udp515") { >>>>>>>>>>>>> action(type="omudpspoof" >>>>>>>>>>>>> name="omudpspoof.local515" >>>>>>>>>>>>> target="127.0.0.1" >>>>>>>>>>>>> port="515") >>>>>>>>>>>>> } >>>>>>>>>>>>> # Fwd to remotebox w/ compression and local disk queueing >>>>>>>>>>>>> ruleset(name="action.fwd.remotebox") { >>>>>>>>>>>>> action(type="omfwd" >>>>>>>>>>>>> name="omfwd.remotebox" >>>>>>>>>>>>> queue.type="LinkedList" >>>>>>>>>>>>> queue.filename="omfwd_remotebox" >>>>>>>>>>>>> queue.size="10000" >>>>>>>>>>>>> queue.maxdiskspace="2G" >>>>>>>>>>>>> queue.saveonshutdown="on" >>>>>>>>>>>>> action.resumeretrycount="-1" >>>>>>>>>>>>> target="172.22.22.22" >>>>>>>>>>>>> port="514" >>>>>>>>>>>>> protocol="tcp" >>>>>>>>>>>>> compression.mode="stream:always") >>>>>>>>>>>>> } >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Randy Baca >>>>>>>>>>>>> >>>>>>>>>>>>> ________________________________________ >>>>>>>>>>>>> From: [email protected] >>>>>>>>>>>>> [[email protected]] on behalf of David Lang >>>>>>>>>>>>> [[email protected]] >>>>>>>>>>>>> Sent: Thursday, October 01, 2015 7:53 PM >>>>>>>>>>>>> To: rsyslog-users >>>>>>>>>>>>> Subject: Re: [rsyslog] Complex forwarding and spoofing question >>>>>>>>>>>>> >>>>>>>>>>>>> I'm not seeing anything obviously wrong, but you left out part of >>>>>>>>>>>>> the config >>>>>>>>>>>>> (the module loading if nothing else) >>>>>>>>>>>>> >>>>>>>>>>>>> do >>>>>>>>>>>>> rsyslogd -N2 >>>>>>>>>>>>> to have rsyslog do a syntax check of the config and see if it's >>>>>>>>>>>>> happy. >>>>>>>>>>>>> >>>>>>>>>>>>> David Lang >>>>>>>>>>>>> >>>>>>>>>>>>> On Fri, 2 Oct 2015, Randy Baca wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Date: Fri, 2 Oct 2015 00:26:11 +0000 >>>>>>>>>>>>>> From: Randy Baca <[email protected]> >>>>>>>>>>>>>> Reply-To: rsyslog-users <[email protected]> >>>>>>>>>>>>>> To: rsyslog-users <[email protected]> >>>>>>>>>>>>>> Subject: Re: [rsyslog] Complex forwarding and spoofing question >>>>>>>>>>>>>> >>>>>>>>>>>>>> This is what I am using but nothing in a tcpdump going to local >>>>>>>>>>>>>> on port 515 or remote on port 514. >>>>>>>>>>>>>> >>>>>>>>>>>>>> # In: 514/TCP (uses the same queue as UDP) >>>>>>>>>>>>>> input(type="imtcp" >>>>>>>>>>>>>> address="10.1.2.3" >>>>>>>>>>>>>> port="514" >>>>>>>>>>>>>> ruleset="ruleset_eth0_514") >>>>>>>>>>>>>> >>>>>>>>>>>>>> # In: 514/UDP (uses the same queue as TCP) >>>>>>>>>>>>>> input(type="imudp" >>>>>>>>>>>>>> address="10.1.2.3" >>>>>>>>>>>>>> port="514" >>>>>>>>>>>>>> ruleset="ruleset_eth0_514") >>>>>>>>>>>>>> >>>>>>>>>>>>>> # Queue: UDP-spoof to the local and also forward to remote >>>>>>>>>>>>>> rsyslog >>>>>>>>>>>>>> ruleset(name="ruleset_eth0_514" >>>>>>>>>>>>>> queue.highwatermark 50000 >>>>>>>>>>>>>> queue.fulldelaymark 20000 >>>>>>>>>>>>>> queue.lowwatermark 2000 >>>>>>>>>>>>>> queue.type="LinkedList") { >>>>>>>>>>>>>> call action.local.udp515 >>>>>>>>>>>>>> call action.fwd.remotebox >>>>>>>>>>>>>> stop >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> # Fwd to localhost:udp/515 >>>>>>>>>>>>>> ruleset(name="action.local.udp515") { >>>>>>>>>>>>>> action(type="omudpspoof" >>>>>>>>>>>>>> name="omudpspoof.local515" >>>>>>>>>>>>>> target="127.0.0.1" >>>>>>>>>>>>>> port="515") >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> # Fwd to remotebox w/ compression and local disk queueing >>>>>>>>>>>>>> ruleset(name="action.fwd.remotebox") { >>>>>>>>>>>>>> action(type="omfwd" >>>>>>>>>>>>>> name="omfwd.remotebox" >>>>>>>>>>>>>> queue.type="LinkedList" >>>>>>>>>>>>>> queue.filename="omfwd_remotebox" >>>>>>>>>>>>>> queue.size="10000" >>>>>>>>>>>>>> queue.maxdiskspace="2G" >>>>>>>>>>>>>> queue.saveonshutdown="on" >>>>>>>>>>>>>> action.resumeretrycount="-1" >>>>>>>>>>>>>> target="172.22.22.22" >>>>>>>>>>>>>> port="514" >>>>>>>>>>>>>> protocol="tcp" >>>>>>>>>>>>>> compression.mode="stream:always") >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> ________________________________________ >>>>>>>>>>>>>> From: [email protected] >>>>>>>>>>>>>> [[email protected]] on behalf of Dave Caplinger >>>>>>>>>>>>>> [[email protected]] >>>>>>>>>>>>>> Sent: Thursday, October 01, 2015 2:09 PM >>>>>>>>>>>>>> To: rsyslog-users >>>>>>>>>>>>>> Subject: Re: [rsyslog] Complex forwarding and spoofing question >>>>>>>>>>>>>> >>>>>>>>>>>>>> Looks like it's "queue.fulldelaymark" (and I presume >>>>>>>>>>>>>> "queue.lightdelaymark" may be related, but there's no >>>>>>>>>>>>>> description at >>>>>>>>>>>>>> http://www.rsyslog.com/doc/master/rainerscript/queue_parameters.html >>>>>>>>>>>>>> so I'm not sure yet what it does...) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Dave Caplinger, Director, Technical Product Management | >>>>>>>>>>>>>> 402.361.3063 | Solutionary — An NTT Group Security Company >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Oct 1, 2015, at 4:03 PM, David Lang <[email protected]> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> There is a queue parameter that tells rsyslog that if the queue >>>>>>>>>>>>>>> is larger than X, stop accepting inputs that can be delayed >>>>>>>>>>>>>>> (like TCP) so that there is space left for a burst of traffic >>>>>>>>>>>>>>> from inputs that can't be delayed (like UDP) >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> rsyslog mailing list >>>>>>>>>>>>>> http://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 >>>>>>>>>>>>>> http://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 >>>>>>>>>>>>> http://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 >>>>>>>>>>>> http://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 >>>>>>>>>>>> http://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 >>>>>>>>>>> http://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 >>>>>>>>>> http://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 >>>>>>>>>> http://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 >>>>>>>>> http://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 >>>>>>>> http://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 >>>>>>> http://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 >>>>>> http://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 >>>>> http://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 >>>> http://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 >>>> http://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 >>> http://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 >> http://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 >> http://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 > http://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 > http://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 http://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 http://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.
