Messages

you can install Chrony and use NTS.

Yep. Here's a list of NTS servers:
- https://gist.github.com/jauderho/2ad0d441760fc5ed69d8d4e2d6b35f8d
- https://gitlab.com/-/snippets/2481323

I use:
time.cloudflare.com,ptbtime1.ptb.de,ptbtime2.ptb.de,ptbtime3.ptb.de,ntp2.glypnod.com,nts.sth1.ntp.se,nts.sth2.ntp.se,ntp.3eck.net,ntp.trifence.ch,ntp.zeitgitter.net,nts1.adopo.net,www.jabber-germany.de,www.masters-of-cloud.de,ntppool1.time.nl,ntppool2.time.nl,ptbtime4.ptb.de,paris.time.system76.com,ntp3.fau.de

1. Create an IP alias with a NOT ("!") setting, e.g. "!1.2.3.4".
2. Create an alias that combines your IP list and the not-IP-alias
3. Use the new combined alias.
4. Done.

No help here, but I also had some issues a few weeks back where renewals would no longer work.

I *think* it was failing the DNS challenge...?

I ended up deleting and newly creating my acme/letsencrypt config. 

That was end of February.

Re: fake i350:

https://forums.servethehome.com/index.php?threads/comparison-intel-i350-t4-genuine-vs-fake.6917/

https://www.hardwareluxx.de/index.php/news/hardware/netzwerk/58048-gefaelschte-netzwerkkarten-von-intel-bei-namhaften-deutschen-shops.html

Username should be either empty or just use the word "token". That tells ddclient to use the API token bearer mechanics. You then put your (newly generated) API token into the password field.

Note: The API token is NOT the same as your Global API Key. See https://developers.cloudflare.com/fundamentals/api/get-started/create-token/. Your token needs both DNS Read and DNS Write permissions. Lots of tutorials on the interweb.

Do NOT use any kind of individual username (such as Zone ID, account ID, email, etc.) - if you do, only your Global API Key works.

Also note this is for OPNsense 23.1 -- not sure if it already works for 22.1 legacy series.

Intel i350. Beware fake Intel cards on eBay though.

RAM - 8GB are plenty for Opnsense. More could be required only if you need a lot of additional services.  Have a look at your current RAM usage to check.

Incidentally, I'll be moving to an m720q 8500T or 9400T soon, too ;-)

Cool, thanks!

I'm spamming this advice as it was "hidden" on github:

How to enable ddclient cloudflare API token use:

username:   token           (!!)
password:   API Token

(taken from Github - just tried it on 23.1 and it works. Goodbye Global API Key!)

How to enable ddclient cloudflare API token use:

username:   token
password:   API Token

(taken from Github - just tried it on 23.1 and it works. Goodbye Global API Key!)

Cloudflare API token geht wie folgt bei ddclient:

How to enable ddclient cloudflare: EASY!
username:   token
password:   API Token

You could also block access to the Snapchat servers based on its ASN IPs.

For most of these, you shouldn't use Suricata at all but use firewall aliases and rules to block these IPs directly, as it is (said to be) a lot more performant.

In Suricata, only use the following:
   
    abuse.ch/SSL Fingerprint Blacklist


Not sure if this is a rules or IP based list:
    abuse.ch/ThreatFox
   

Is it worth a clean upgrade just to get on ZFS

Absolutely.

Being able to do snapshots and backup boot environments (bectl) prior to upgrades is a god-send.

The thing that holds me back is recreating all the "custom" stuff that isn't backed up normally e.g. I have scripts that execute speed tests against 5 servers, some custom commands for Unbound and who know how many other tweaks I have probably forgotten about. I'd be installing to a new drive so getting anything back shouldn't be too difficult, just a pain, also fully reverting will be simple.

You could try to run a "diff" (compare directories etc.) between the two filesystems to find esp. custom scripts, config files etc.

Also, is it just a case of backing up the current installation, copying that to a USB drive then pointing the installer to that file?

Basically yes. You may have issues initially e.g. having to reinstall plugins  / repos but those can usually be sorted out pretty easily.

[pls disregard]

I noticed that the standard installation of the chrony plugin may not work as an NTS server. Can't tell for sure as I am not using a clean install. So putting this out here in case (1) it helps someone and/or (2) someone can help me improve / simplify my setup.

my issues:
chrony clients could not connect because of certificate errors.
1. the chrony plugin in server mode needs read access to the certificate and key. Without it, I got the following error:

Code Select Expand

# chronyd -Q -t 3 'server [myserver] iburst nts maxsamples 1'
...
... TLS handshake with [myserver] failed : The TLS connection was non-properly terminated.
...

2. the certificate needs to be the full chain. Without it, I got

Code Select Expand

# chronyd -Q -t 3 'server [myserver] iburst nts maxsamples 1'
...
... TLS handshake with [myserver] failed : Error in the certificate verification. The certificate is NOT trusted. The certificate issuer is unknown....

3. the standard OPNsense certificate & key at /var/etc/cert.pem / ..key.pem are read root only. I did not want to grant chrony access to it or include chrony in the "wheel" group.

What did I do?

1. set up a DNS alias for time.MYDOMAIN.TLD
2. set up a separate letsencrypt certificate for time.MYDOMAIN.TLD
3. set up an automation to have the certificate (full chain + key) be copied over to /var/lib/chrony and chmod those to chronyd and restart chrony:
a) set up the following backend action (https://docs.opnsense.org/development/backend/configd.html):

Code Select Expand

[NTS_renewal]
command:cp /var/etc/acme-client/home/time.XXXXX/fullchain.cer /var/lib/chrony/chrony.fullchain.cer && cp /var/etc/acme-client/home/time.XXXXX/time.XXXXX.key /var/lib/chrony/chrony.key && cp /var/etc/acme-client/home/time.XXXXX/time.XXXXX.cer /var/lib/chrony/chrony.cer && chown chronyd /var/lib/chrony/chrony.key /var/lib/chrony/chrony.cer /var/lib/chrony/chrony.fullchain.cer && /usr/local/etc/rc.d/chronyd stop && /usr/local/etc/rc.d/chronyd start
type:script
message: copy NTS certificates into chrony directory and make them readable
description: Renew NTS certificate & restart chrony (all in one go)
b) enable it:

Code Select Expand

service configd restart
c) setup an automation using this action in the ACME client for the NTS certificate.
4. Point chrony to his certificate and key:

Code Select Expand

ntsservercert /var/lib/chrony/chrony.fullchain.cer
ntsserverkey /var/lib/chrony/chrony.key
(not sure this will persist an update of the plugin though ...)

Now it seems to work. Hooray!  :D

resources:
- https://docs.opnsense.org/development/backend/configd.html
- https://unix.stackexchange.com/questions/712784/chrony-fails-to-sync-with-nts-enabled

pinging @mimugmail in case some of this could be intregrated into the plugin itself (as it purports to create a working NTS server which it _may_ not do).

Especially, it seems that the manual edits to the config file - specifically the "ntsservercert" / "ntsserverkey" part -- seem to be over-written ...