In broad terms, what do you mean by "short lived VMs"? Are you using something
like Azure Scale Sets (or equivalent from GCP, AWS, etc), or are you
referencing a user or IT Admin creating a temporary VM based on some "golden
image" provided by Infrastructure, that may be torn down at any point? (Eg:
something like a build/test server)? If you're using scale sets, they should
all exist in the same subnet, generally speaking.
Again, I'm evidently not your IT administrator. But if you can generalize the
rules a little or better have an IT Admin enforce some level of standard
procedure when working with these VMs, it may help. In a correctly configured
environment you'd typically have several vlans (example only, obviously):
- 10.0.0.0->10.0.3.255 (User VLAN)
- 10.0.4.0->10.0.4.255 (Prod Linux VMs)
- 10.0.5.0 -> 10.0.5.255 (Dev Linux VMs)
- 10.0.6.0 -> 10.0.6.255 (Prod Windows VMs)
- 10.0.7.0 -> 10.0.7.255 (Dev Windows VMs)
- [...]
If we know we need to capture most if not all of the logs from 10.0.4.0/23 (so
10.0.4 and 10.0.5), but not the User or Windows VLAN, we say something like
this to UFW:
sudo ufw allow from 10.0.4.0/24 to any port 514
sudo ufw allow from 10.0.5.0/24 to any port 514
sudo ufw deny from any to any port 514
Limits the connections to a given VLAN and drop anything else. You may need to
remove generic services on the UFW config. In RHEL world (firewalld/iptables),
generic configurations take precedence over specified rules.
eg:
Ports (valid): 514/tcp 514/udp
Rich Rule (ignored):
rule pri=1 [..] source address=10.0.4.0/24 port port=514 [..] accept
rule pri=2 [..] source address=10.0.5.0/24 port port=514 [..] accept
rule pri=3 [..] port port=514 [..] reject
Will have firewalld accept all traffic, even though we specified in the rich
rules to drop anything to port 514 that isn't from 10.0.4 or 10.0.5.
________________________________
From: Ralph Moeritz <ralph.moer...@kradle.com>
Sent: Monday, April 7, 2025 3:30 PM
To: Redbourne,Michael <michael.redbou...@bulletproofsi.com>;
rsyslog@lists.adiscon.com <rsyslog@lists.adiscon.com>
Subject: Re: Troubleshooting DTLS
CAUTION: The Sender is located Outside The Organization. Do not click links or
open attachments unless you recognize the sender and know the content is safe.
Hi Michael,
Thanks for providing all that information. I'll try using imtcp and omtcp. I'm
not sure how to setup ufw to reject connections based on IP addresses since the
machines forwarding their logs are short-lived VMs whose IP addresses are not
known to me beforehand & allocated by our Cloud provider. I do get the point
though, there is no authentication provided by Rsyslog.
Cheers,
Ralph
________________________________
From: Redbourne,Michael
Sent: Monday, April 7, 2025 2:51 PM
To: rsyslog@lists.adiscon.com
Cc: Ralph Moeritz
Subject: Re: Troubleshooting DTLS
Hey!
I'm one of the reasons the DTLS module was written by Andre (Adiscon). The use
case of DTLS (imdtls or omdtls) is *very* niche and highly uncommon in general,
with basically no support outside of rsyslog being implemented despite being
codified in RFC6012 (written in part by none other than Rainer himself).
Accordingly, knowledge of DTLS modules is exceptionally limited. One of the use
cases for DTLS is high-throughput environments that need L4 load balancing. The
theoretical build we'd designed (ultimately went with another) was reliant on
inbound DTLS via a Layer-4 F5 LTM Load Balancer using K3605 (TLDR: Load
balancing per UDP packet, rather than a tuple on UDP. Useful for things such as
DNS, and UDP Syslog...)
To clear up a few things though:
- imdtls and omdtls are not using "certificate authentication". The
certificates they use are used to encrypt the message in transit. It is
possible as a function of certificate checks to reject invalid certificates,
that's all.
Which brings me to a larger point: Don't use DTLS. There are better options
available to you with better support from rsyslog and the community.
1. Use imtcp and omtcp. Both support encryption in the same manner as their UDP
counterparts. You could also use the GSSAPI modules, but I'd recommend sticking
to the Adiscon-built ones.
2. Don't rely on those modules to provide connection limiting. Use your
firewalls (appliance or ufw) to limit what can connection to rsyslog.
You will note that when rsyslog receives incorrect, malformed, or unencrypted
connections to an encrypted services, it will spit out a LOT of errors.
Here's a valid self-signed rsyslog imtcp (encrypted) log type:
(/etc/rsyslog.d/tls-6514.conf)
global(
DefaultNetstreamDriver="gtls"
DefaultNetstreamDriverCAFile="/etc/ssl/root_ca.pem"
DefaultNetstreamDriverCertFile="/etc/ssl/rsyslog.pem"
DefaultNetstreamDriverKeyFile="/etc/ssl/rsyslog.key"
)
# load TCP listener
module(
load="imtcp"
StreamDriver.Name="gtls"
StreamDriver.Mode="1"
StreamDriver.Authmode="anon"
)
# start up listener at port 6514
input(
type="imtcp"
port="6514"
)
Note: It is possible to run an encrypted and unencryped build side-by-side.
Rsyslog has has imptcp and omptcp (Plain TCP) modules which can be leveraged:
module(load="imptcp")
input(type="imptcp" port="514")
Cheers,
Mike
________________________________
From: rsyslog <rsyslog-boun...@lists.adiscon.com> on behalf of Ralph Moeritz
via rsyslog <rsyslog@lists.adiscon.com>
Sent: Monday, April 7, 2025 11:47 AM
To: rsyslog@lists.adiscon.com <rsyslog@lists.adiscon.com>
Cc: Ralph Moeritz <ralph.moer...@kradle.com>
Subject: [rsyslog] Troubleshooting DTLS
CAUTION: The Sender is located Outside The Organization. Do not click links or
open attachments unless you recognize the sender and know the content is safe.
Hi Rsysloggers!
I have an Rsyslog server to which I am forwarding logs from several machines,
currently using UDP via omfwd. The problem with this is that it's insecure and
I'm falling victim to spam messages being sent to my Rsyslog server.
To combat this, I'd like to restrict log forwarding via imdtls and omdtls using
client certificate authentication but am not having any luck setting it up.
Since the Ubuntu 24.04 Rsyslog package is too old to include DTLS I rolled my
own .deb package from the nightly Git sources back in February.
Below is what I've done so far & the issues I'm seeing. I'd appreciate any help
people on this list can provide. TIA🙂
1.
Created a CA PK & cert using the instructions from
https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rsyslog.com%2Fdoc%2Ftutorials%2Ftls_cert_ca.html&data=05%7C02%7Cmichael.redbourne%40bulletproofsi.com%7C9ff0a288cec647a42de508dd7576330d%7C9a63d13853ea411bbe8458b7e2570747%7C1%7C0%7C638795872742655300%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=vSlASGOj4u%2FIHEU%2BX0N2xY4J8RgZRm%2BbfBgkiAQyal0%3D&reserved=0<https://www.rsyslog.com/doc/tutorials/tls_cert_ca.html>
2.
Created server key & cert:
openssl req -newkey rsa:2048 -nodes -days 365000 \
-keyout server-key.pem \
-out server-req.pem
openssl x509 -req -days 365000 -set_serial 01 \
-in server-req.pem \
-out server-cert.pem \
-CA ca-cert.pem \
-CAkey ca-key.pem
1.
Create client key & cert:
openssl req -newkey rsa:2048 -nodes -days 365000 \
-keyout client-key.pem \
-out client-req.pem
openssl x509 -req -days 365000 -set_serial 01 \
-in client-req.pem \
-out client-cert.pem \
-CA ca-cert.pem \
-CAkey ca-key.pem
2.
Copy certs to client & server machines.
3.
Configure server:
module(load="imdtls")
input(type="imdtls"
port="4433"
tls.cacert="/usr/local/share/ca-certificates/rsyslog/ca-cert.pem"
tls.mycert="/usr/local/share/ca-certificates/rsyslog/server-cert.pem"
tls.myprivkey="/usr/local/share/ca-certificates/rsyslog/server-key.pem"
tls.authmode="certvalid"
ruleset="writeRemoteData")
4.
Configure client:
module(load="omdtls")
action(type="omdtls" target="my-server-address.domain" port="4433"
tls.cacert="/usr/local/share/ca-certificates/rsyslog/ca-cert.pem"
tls.mycert="/usr/local/share/ca-certificates/rsyslog/client-cert.pem"
tls.myprivkey="/usr/local/share/ca-certificates/rsyslog/client-key.pem"
tls.authmode="certvalid")
When I start the server (the one running imdtls) I see the following errors
logged:
Apr 07 01:41:30 influxdb-do-monitoring-test rsyslogd[10526]: [origin
software="rsyslogd" swVersion="8.2504.0.master" x-pid="10526"
x-info="https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rsyslog.com%2F&data=05%7C02%7Cmichael.redbourne%40bulletproofsi.com%7C9ff0a288cec647a42de508dd7576330d%7C9a63d13853ea411bbe8458b7e2570747%7C1%7C0%7C638795872747002429%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=VkIF4BkopehMh07g0UJ5hoOJi%2FVPhqybZLbgj43tfYg%3D&reserved=0<https://www.rsyslog.com/>"]
start
Apr 07 01:41:30 influxdb-do-monitoring-test systemd[1]: Started rsyslog.service
- System Logging Service.
Apr 07 01:41:38 influxdb-do-monitoring-test rsyslogd[10526]: rsyslogd:
SSL_ERROR_UNKNOWN Error in 'DTLSHandleSessions':
'error:00000000:lib(0)::reason(0)(0)' with ret=1, errno=0(Success),
sslapi='SSL_accept' [v8.2504.0.master]
Apr 07 01:41:38 influxdb-do-monitoring-test rsyslogd[10526]: rsyslogd:
net_ossl:remote '(null)' OpenSSL Error Stack: error:0A000418:SSL
routines::tlsv1 alert unknown ca [v8.2504.0.master]
Regards,
Ralph
Confidentiality and Privilege Notice: This e-mail is intended only to be read
or used by the addressee. It is confidential and may contain legally privileged
information. If you are not the addressee indicated in this message (or
responsible for delivery of the message to such person), you may not copy or
deliver this message to anyone, and you should destroy this message and kindly
notify the sender by reply e-mail. Confidentiality and legal privilege are not
waived or lost by reason of mistaken delivery to you.
_______________________________________________
rsyslog mailing list
https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.adiscon.net%2Fmailman%2Flistinfo%2Frsyslog&data=05%7C02%7Cmichael.redbourne%40bulletproofsi.com%7C9ff0a288cec647a42de508dd7576330d%7C9a63d13853ea411bbe8458b7e2570747%7C1%7C0%7C638795872747017015%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=awBDcZCsOKwcMVZqBFAfX9BIetoIk9o7mPpX1WoafiA%3D&reserved=0<https://lists.adiscon.net/mailman/listinfo/rsyslog>
https://can01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rsyslog.com%2Fprofessional-services%2F&data=05%7C02%7Cmichael.redbourne%40bulletproofsi.com%7C9ff0a288cec647a42de508dd7576330d%7C9a63d13853ea411bbe8458b7e2570747%7C1%7C0%7C638795872747032841%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ezj7z7xz82gbQN0FUU5cPHyea%2FZHlkLXPynxgseNVsU%3D&reserved=0<http://www.rsyslog.com/professional-services/>
What's up with rsyslog? Follow
https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Frgerhards&data=05%7C02%7Cmichael.redbourne%40bulletproofsi.com%7C9ff0a288cec647a42de508dd7576330d%7C9a63d13853ea411bbe8458b7e2570747%7C1%7C0%7C638795872747046505%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=yuU7Htz45ZrAmsB3uLw5eNEvoVpp%2BKqsC4BIvpUEMPY%3D&reserved=0<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.
________________________________________
This e-mail communication (including any or all attachments) is intended only
for the use of the person or entity to which it is addressed and may contain
confidential and/or privileged material. If you are not the intended recipient
of this e-mail, any use, review, retransmission, distribution, dissemination,
copying, printing, or other use of, or taking of any action in reliance upon
this e-mail, is strictly prohibited. If you have received this e-mail in error,
please contact the sender and delete the original and any copy of this e-mail
and any printout thereof, immediately. If you have any questions or concerns,
please contact our Customer Service Desk at 1-877-274-2349. Your co-operation
is appreciated.
Le présent courriel (y compris toute pièce jointe) s'adresse uniquement à son
destinataire, qu'il soit une personne ou un organisme, et pourrait comporter
des renseignements privilégiés ou confidentiels. Si vous n'êtes pas le
destinataire du courriel, il est interdit d'utiliser, de revoir, de
retransmettre, de distribuer, de disséminer, de copier ou d'imprimer ce
courriel, d'agir en vous y fiant ou de vous en servir de toute autre façon. Si
vous avez reçu le présent courriel par erreur, prière de communiquer avec
l'expéditeur et d'éliminer l'original du courriel, ainsi que toute copie
électronique ou imprimée de celui-ci, immédiatement. Si vous avez des questions
ou des préoccupations, veuillez contacter notre centre de service à la
clientèle au 1-877-274-2349. Nous sommes reconnaissants de votre collaboration.
________________________________________
_______________________________________________
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.
