Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - JohnDoe17

#1
Greetings fellow OPNsense enthusiasts!

I regularly use (daily, in fact) the testmynids.org script from 3CORESec to validate that my IDS/IPS detection and alerting pipeline (using OPNsense and Graylog) are working correctly.

Starting around 27 March 2024, the "Bad Certificate Authorities" (Option 4) started failing to be detected.

1) Does anyone else use testmynids to verify the proper configuration and operations of the IDS/IPS on their OPNsense?

2) Does anyone know if this is this a known issue with current Suricata rules?

3) Can anyone else replicate my experience (i.e., the non-detection of the bad certificate authorities) with their setup?

NOTE: I have had intermittent failures in the past where some of the testmynids tests failed for a day or two, but those seemed to fixed in short order after a new IDS/IPS signature download.  Nothing that's lasted this long - nearly two months!
#2
Hi, benyamin.

Thank you for your response.

No, the configuration doesn't use --redirect-gateway def1 or similar.

I'm not being pushed anything like that either.  (I control both ends of the OpenVPN tunnel, and nothing has changed on the server side.)

Don't pull routes and Don't add/remove routes are both unchecked.

Can you tell me more about
QuoteOpenVPN gateway behaviour has changed, but if anything, it is arguable that it is now working as intended.
?
#3
I've got the firewall configured as an OpenVPN *client* to connect to an OpenVPN server that I can then selectively route traffic outbound through the firewall to.

This is working great on my 22.7.11_1 firewall.

But on the firewall that I upgraded to 23.1.7_3, the OpenVPN client doesn't seem to be getting a gateway address from the OpenVPN server like it should (and like my other one does).

I didn't see anything obviously related in the OpenVPN log files...

Any ideas?

#4
I'm wondering if anything more came from this?  I'm seeing the same errors in my Suricata logs.
#5
Just wanted to tag on to this.  I'm having the same problem: "KDF_PRF with PRF_UNDEFINED not supported" with my IPsec configuration.

The strongwan-kdf.pkg fixed it for me also.
#6
Current set up:
o IDS/IPS (Suricata) is configured with "Enable eve syslog output."
o The firewall is configured to send syslog to a remote syslog server.
o The syslog server (Graylog in our case) is configured to email the admins when certain alerts meet certain conditions.

What I want to do:
o Setup up a cron job on a machine behind the firewall that occasionally does _something_ that triggers a Suricata alert that Graylog can match on to satisfy a "proof of life" condition.  If that condition is not met, Graylog can send an email to alert the admins that they may not be receiving IDS/IPS alerts like they are expecting.  (And/or have Graylog email the admins occasionally saying the condition is being met.)

So... is there a standard, innocuous event I can trigger that would cause Suricata to alert?  I was thinking something like trying to download EICAR or something.  (If I go with EICAR, what ET list would that event be in?  Malware?)

I'm open to feedback on further improving the whole system too if people have thoughts.  Thanks.
#7
Anyone have any thoughts on this?

Specifically, what OpenVPN options does OPNsense's "No Preference" translate to?

Is there a way I can turn on debugging or look at log files or something to figure this out?

Thanks.

JD17
#8
Can someone verify my understanding, please?  (I'm trying to implement mitigations against VORACLE attack.)

Setting "Compression" to "No Preference" actually *disables* compression in OpenVPN, correct?  I.e., it omits both the legacy "comp-lzo" and the newer-but-still-not-recommended "compress" options, right?

I wish the terminology used for this setting was a bit clearer, but apparently this is a complaint I should take up with OpenVPN not OPNsense  ;) as it seems to be their definition.

JD17
#9
21.7 Legacy Series / Re: OpenVPN routes on 21.7.2_1
October 12, 2021, 10:56:14 PM
This post deserves a thousand "likes!"

I just upgraded from 21.1.x and ran into this issue.  Thank you so much for the solution!

It does seem like something the upgrade process ought to 1) fix or 2) not introduce - it's unclear to me where exactly the issue lies.

JD17
#10
Perhaps this has been resolved too...?  I did get an updated set of rules on Monday - finally.
#11
Well... the heartbeats work as I reported a few days ago, but the ET Pro Telemetry rules have *NOT* been updated since September 18th.

Neither the "Services > Intrusion Detection > Log File" nor the "System > Log Files > General" indicate there is any error downloading new rules.  Frankly it just looks like they haven't updated them for a few days.

Is Proofpoint still supporting the "ET Pro Telemetry" edition rules?

Thanks.

JD17

Edit: Added the missing word "*NOT*" in the first sentence.  It was kind of important, lol.
#12
Yes, the issues seem to be resolved for me - at least, the heartbeats are going through now apparently.  Not sure how often the ET Pro Telemetry edition rules themselves are revved from Proofpoint's side, but the last set of rules the firewall downloaded were going on 16 hours old when I just checked (I have the firewall configured to download fresh rule sets every 6 hours).

Thanks for the help!
#13
Thanks, Franco and OPNsense team for passing this on to Proofpoint.

Like @joeyboon said, the "connection error sending heartbeat to https://opnsense.emergingthreats.net/api/v1/telemetry" issue appears to be back.

Edit:  Anxious to hear about a resolution.

JD17
#14
I am running 21.1.9, and I've had the ET Telemetry Edition working fine for several months.  But in the last couple of days, the Dashboard widget is just spinning when it is trying to get status from proofpoint.

When I look in the Intrusion Detection > Download tab, my Abuse.ch rule sets are downloading and updating fine.  Only the ET rule sets are not downloading on schedule.

At first I chalked this up to a temporary issue on proofpoint's side (and maybe it still is), but it's dragged on for a couple of days now and I though it was time to ask if any others are seeing this...

Thanks.
#15
I am experiencing the same behavior.  After upgrade from 21.1.5 straight to 21.1.7_1, when I click on "Check for updates" from the Dashboard, it takes me to the "Updates" tab and just spins.