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 - 0zzy

#1
@EricPerl
curios, in my configuration it works as described.
The Block Rule RFC1918     *    Block LANDMZ to internal without anything else block all traffic in my entire lan, how I test it?

ping 192.168.11.1    --> no ping allowed
traceroute 192.168.11.1 --> no tracerout possible

also:

nmap -p 22,80,443 192.168.11.1 --> says everything is filtered
nc -zv 192.168.11.1 22 --> says for all the ports its unreachable

no web interface is useable from one of the dmz hosts.

On OpNSense:

Firewall > Log Files > Live View

Filter:

Interface: LANDMZ

Action: Block

Destination: RFC1918 IPs

so why should it not working?
#2
@Patrick M. Hausen,
oh my god.... it works...
you are my hero of the day ;)
Thank you!
#3
Hey together,

I configured a DMZ in my vlan.

everything works except the firewall rule for DNS which should be the Interface Address.

I Use Unbound for everything.

I set an ACL in Outbound for it.
My Firewall Rules are:

Protocol   Source   Port   Destination   Port   Gateway   Schedule      Description
IPv4 TCP/UDP   LANDMZ net   53 (DNS)   dmz_ns    53 (DNS)   *   *      Forward DNS       
        IPv4 ICMP   LANDMZ net   *   *   *   *   *      Allow ICMP to OPNsense       
        IPv4+6 *   LANDMZ net   *   RFC1918    *   *   *      Block LANDMZ to internal       
        IPv4+6 *   LANDMZ net   *   ! RFC1918    *   *   *      Allow access to Internet and block access to all local networks       
        IPv4 *   LANDMZ net   *   FLUX_IPs    *   *   *      Allow to admin PC only       
        IPv4 *   LANDMZ net   *   *   *   *   *      Block all other

Why can't the dmz reach the DNS?
I'm confused about that.

#4
Of course:
# DO NOT EDIT THIS FILE -- OPNsense auto-generated file


# Global Options
{
log {
output net unixgram//var/run/caddy/log.sock {
}
format json {
time_format rfc3339
}
}

servers {
protocols h1 h2 h3
trusted_proxies static 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8
}

dynamic_dns {
provider cloudflare
domains {
zerot3ch.de *
zerot3ch.de remotely
}
ip_source interface igc0
update_only
}

email xxx@gmail.com
grace_period 10s
import /usr/local/etc/caddy/caddy.d/*.global
}

# Reverse Proxy Configuration


*.zerot3ch.de {
log {
output file /var/log/caddy/access/bb35164d-3b13-4c5c-a47e-6499b75c76da.log {
roll_keep_for 10d
}
}
tls {
issuer acme {
dns cloudflare
}
}

@258c701d-7862-4552-b894-d961cdbab7e4_zerot3chde {
not client_ip 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8
}
handle @258c701d-7862-4552-b894-d961cdbab7e4_zerot3chde {
abort
}
}

remotely.zerot3ch.de {
log {
output file /var/log/caddy/access/2b8651a0-b5db-41f6-9d3b-9a8f1109f3e1.log {
roll_keep_for 10d
}
}

@258c701d-7862-4552-b894-d961cdbab7e4_remotelyzerot3chde {
not client_ip 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8
}
handle @258c701d-7862-4552-b894-d961cdbab7e4_remotelyzerot3chde {
abort
}

handle {
reverse_proxy 192.168.11.60:5000 {
transport http {
}
}
}
}

This is the only reverse proxy entry which works.

Curiously if I remove the Access List from other entries than the remotely entry, it works.

Can someone explain why?

I use this described at https://docs.opnsense.org/manual/how-tos/caddy.html#restrict-access-to-internal-ips

Options Values
Access List Name: private_ipv4
Client IP Addresses: 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8
Description: Allow access from private IPv4 ranges

#5
Thanks guys for your comments for completeness.

Ok nevertheless, it's curious that after the newest update of opnsense and caddy,
That none of my reverseproxied entries in the caddy plugin are working except one.

If I try to, as an example invoice ninja, add it like ip/port 192.168.11.60:8035 http,
It doesn't work.
Where and that's really confusing only one entry is working (I have remotely an remote support tool configured without custom config).


So to get back to my previous question:

Why are my reverse proxy settings aren't work if I configure them over the caddy plugin in the webui?

#6
Quote from: Patrick M. Hausen on May 21, 2025, 10:23:10 AMMy Nextcloud installation is rated A+ for SSL by Qualys and A+ by the Nextcloud security scan.

I fail to see what else I could do to harden the installation. In the hosting environment we sell the entire OS and "middleware" (installed packages) is mounted read-only into the customer jail.

What else? As an operator, not a developer!

Kind regards,
Patrick


I suggest to take a look at the following sites:

First is relative easy, also with a free account
https://www.cisecurity.org/

Take a look on the security benchmarks.

Second is made by multiple guys who are working on a tool named hardn.

It simplifies the art to get a system hardened.


https://undercodetesting.com/hardn-the-linux-security-project/


Also they are working on a BSD hardn project.

With that you get a quiet good score in different benchmarks.


Also not bad to have because it's free and gives you a little deep dive what's going on in your systems is an siem/xdr tool like wazuh.  It could help you to find out more deeply off your systems.


It isn't a dev thing I think. I'm not a dev, simply a tech guy who works in the it and appreciates to share my knowledge.
#7
@meyerguru
you bring in the words I was searching for.
There isn't only one way. But many ways to reach a goal.
#8
Hey Patrick,

this is named by two technics:

1.) Client Side Security Audit
and
2.) Browser Based Security Inspection.

The Problem with sites like Qualys is, that you get an A+ also if you have misconfigurations which are used by attackers to get into.

What they check:

Qualys SSL Labs scores sites primarily on TLS configuration, not holistic web security. The main factors include:

1.) Supported TLS versions (e.g., only TLS 1.2 and 1.3 = higher score)
2.) Cipher suites (strong, forward-secret ciphers = higher score)
3.) Certificate strength (2048+ bit key, valid chain, no weak signature algos)
4.) HSTS with long duration and preload
5.) No support for insecure renegotiation, compression, or SSLv3
6.) OCSP stapling and other TLS extras

What sites like qualys don't do:

- Web app misconfigurations
- CSP or other headers
- WAF or rate limiting
- Cookie security flags
- Auth schemes / access control
- Firewall rules
- Malware / phishing risks
- Backend exposure / IP leaks

And much more.

So bringing a site ( it doesn't matter if as reverse proxy or a site server config) isn't all and of course isn't secure by default.

You mentioned next cloud, which has a good implementation of a Security Scan.
But it gives you only some of the ways to harden a System.

Its not only about caddy but that would go too far here.

I scrambled my head on how you could do it easily.

I think much easier is to use something like Mozilla HTTP Observatory https://developer.mozilla.org/en-US/observatory.

Here you can check it easier and you would see that an A+ is more an B or something.
#9
Patrick please check the dev console also with your entire browser.

A+ isn't everything as I mentioned before.
It means literally that you have a certain "better" basic protection. However, this does not mean that the bar has been reached.

And this is exactly my goal! Get it hard harder as hardest possible hardening also for my sites.

It's a decision everyone should make.
#10
as far as I understand encode zstd gzip meins the compression or I'm wrong it hasn't something to do with crypto.
#11
Monviech,
not really, the problem is that the most homelab things are insecure by default.
mandatory security mechanisms like TLS-SNI, OCSP, Input Validation & Output Escaping, CSRF Protection, Secure Headers etc. are only mediocrely implemented in caddy on opnsense.

With my configuration which I use on a standalone caddy server which is hosted by an cloudprovider, its also the same scenario.

What I like to have is to implement everything which is possible to make my sites as secure as possible.

Some fact here are, the not everything works with every application or site.

To show you what I mean I use Qualys SSL Labs,
one of my sites getting an A+ rating (which is almost okay but not perfect), some getting a T Rating and some getting B rating:

In order A to T:

https://imgur.com/27TaXTm

I work especially at tls /ssl cuipher suites to activate the highest algorithm which is possible:
This isn't what I expect!
https://imgur.com/jUy9oVy

And something like this is worst in my opinion:

https://imgur.com/358tipMor

https://imgur.com/KZEts5Y
#12
No Problem Mate,
I was simply wondered what was going wrong.
and this kind of support is really enough ;)
I would test this out and let a post in the forum if it works.

At the moment I I created every site as a custom config, because there are many options especially for security reasons which I suggest to use in the webui.
But there's not so much as you could define via custom configs.

At least im happy because now it working, not as usual but it works.
#13
I tested out both:
1.) recreate the entries for my sites --> not working
2.) delete the sites (Reverse Proxy & Handlers) and use my own config --> not working also

What I'm doing wrong?

I simply use the Documentation of caddy in the OPNSense Documentation
#14
Hello together,
since I updated today morning to the newest version of opnsense, caddy doesn't recognise my config.
Caddyfile in /usr/local/etc/caddy/

# DO NOT EDIT THIS FILE -- OPNsense auto-generated file


# caddy_user=root

# Global Options
{
log {
output net unixgram//var/run/caddy/log.sock {
}
format json {
time_format rfc3339
}
}

servers {
protocols h1 h2
trusted_proxies static 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8
}

dynamic_dns {
provider cloudflare LrY7LW4tqarzszMUvTJgXQy4dsC_Q7o97T5HAdL9
domains {
domain.de *
xxxx xxxx
xxxx xxxx
this one works remotely
xxxx xxxx
xxxx xxxx
xxxx xxxx
xxxx xxxx
}
ip_source interface igc0
update_only
}

email xxxx
grace_period 10s
import /usr/local/etc/caddy/caddy.d/*.global
}

# Reverse Proxy Configuration


*.xxxx {
log {
output file /var/log/caddy/access/bb35164d-3b13-4c5c-a47e-6499b75c76da.log {
roll_keep_for 10d
}
}
tls {
issuer acme {
dns cloudflare xxxx
}
}

@258c701d-7862-4552-b894-d961cdbab7e4_zerot3chde {
not client_ip 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8
}
handle @258c701d-7862-4552-b894-d961cdbab7e4_zerot3chde {
abort
}
}

xxxx {
log {
output file /var/log/caddy/access/3d8d56e7-f7e5-49a9-9229-789c65baf88c.log {
roll_keep_for 10d
}
}

@258c701d-7862-4552-b894-d961cdbab7e4_giteazerot3chde {
not client_ip 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8
}
handle @258c701d-7862-4552-b894-d961cdbab7e4_giteazerot3chde {
abort
}

handle {
reverse_proxy xxxx:3000 {
transport http {
}
}
}
}

xxxx {
log {
output file /var/log/caddy/access/d9431ba8-f607-43f7-a888-131e861fe5e6.log {
roll_keep_for 10d
}
}

@258c701d-7862-4552-b894-d961cdbab7e4_str1ctzerot3chde {
not client_ip 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8
}
handle @258c701d-7862-4552-b894-d961cdbab7e4_str1ctzerot3chde {
abort
}

handle {
reverse_proxy xxxx:8000 {
transport http {
}
}
}
}

xxxx (this one works) {
log {
output file /var/log/caddy/access/2b8651a0-b5db-41f6-9d3b-9a8f1109f3e1.log {
roll_keep_for 10d
}
}

@258c701d-7862-4552-b894-d961cdbab7e4_remotelyzerot3chde {
not client_ip 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8
}
handle @258c701d-7862-4552-b894-d961cdbab7e4_remotelyzerot3chde {
abort
}

handle {
reverse_proxy xxxx:5000 {
transport http {
}
}
}
}

xxxx {
log {
output file /var/log/caddy/access/c7f68fcb-0ec2-48f2-a3d0-790c7677b365.log {
roll_keep_for 10d
}
}

@258c701d-7862-4552-b894-d961cdbab7e4_invoicezerot3chde {
not client_ip 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8
}
handle @258c701d-7862-4552-b894-d961cdbab7e4_invoicezerot3chde {
abort
}

handle {
reverse_proxy xxxx:8035 {
}
}
}

xxxx {
log {
output file /var/log/caddy/access/4033eaa0-263f-470f-8e2d-9cd6f42788c5.log {
roll_keep_for 10d
}
}

@258c701d-7862-4552-b894-d961cdbab7e4_jellyfinzerot3chde {
not client_ip 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8
}
handle @258c701d-7862-4552-b894-d961cdbab7e4_jellyfinzerot3chde {
abort
}

handle {
reverse_proxy xxxx:8096 {
}
}
}

xxxx {
log {
output file /var/log/caddy/access/a3475101-3588-49e2-9e20-17143ad58ba9.log {
roll_keep_for 10d
}
}

@258c701d-7862-4552-b894-d961cdbab7e4_librenmszerot3chde {
not client_ip 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8
}
handle @258c701d-7862-4552-b894-d961cdbab7e4_librenmszerot3chde {
abort
}

handle {
reverse_proxy xxxx:80 {
transport http {
}
}
}
}

xxxx {
log {
output file /var/log/caddy/access/d273108a-38a7-432f-a88f-2cba3ee196b6.log {
roll_keep_for 10d
}
}

@258c701d-7862-4552-b894-d961cdbab7e4_authentikzerot3chde {
not client_ip 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8
}
handle @258c701d-7862-4552-b894-d961cdbab7e4_authentikzerot3chde {
abort
}

handle {
reverse_proxy https://xxxx:9443 {
transport http {
tls_insecure_skip_verify
tls_trust_pool file /var/db/caddy/data/caddy/certificates/temp/6694f83be85a0.pem
tls_server_name authentik
}
}
}
}

import /usr/local/etc/caddy/caddy.d/*.conf

the interesting part is, in the last version I put some own configs and a snippet.global in /usr/local/etc/caddy/caddy.d/
like this custom config:
test.domain.de {
    reverse_proxy any:anyport
    import encodingOptions
    tls {
        import tlsOptions
    }
    header {
        import HardeningConfig cors ratelimiterOptions reffererConfig https://invoice.zerot3ch.de
    }
    log {
        output file /var/log/caddy/test.log {
            import logOptions
        }
        format json
    }
}

the snippet.global was:
(encodingOptions) {
    encode zstd gzip
}

(tlsOptions) {
    protocols tls1.2 tls1.3
    curves x25519 secp384r1
    ciphers TLS_AES_128_GCM_SHA256 TLS_AES_256_GCM_SHA384
}

(HardeningConfig) {
    header Permissions-Policy "interest-cohort=()"
    header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
    header X-Content-Type-Options "nosniff"
    header X-Frame-Options "SAMEORIGIN"
    header Server-Timing "*"
    header X-XSS-Protection "1; mode=block"
    header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; object-src 'none'; frame-src 'none';"
    header Set-Cookie "my_cookie=value; Path=/; HttpOnly; SameSite=Lax"
}

(cors) {


root@OPNsense:/home/ozzy/caddy # cat snippets.global
(encodingOptions) {
    encode zstd gzip
}

(tlsOptions) {
    protocols tls1.2 tls1.3
    curves x25519 secp384r1
    ciphers TLS_AES_128_GCM_SHA256 TLS_AES_256_GCM_SHA384
}

(HardeningConfig) {
    header Permissions-Policy "interest-cohort=()"
    header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
    header X-Content-Type-Options "nosniff"
    header X-Frame-Options "SAMEORIGIN"
    header Server-Timing "*"
    header X-XSS-Protection "1; mode=block"
    header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; object-src 'none'; frame-src 'none';"
    header Set-Cookie "my_cookie=value; Path=/; HttpOnly; SameSite=Lax"
}

(cors) {
    @origin header Origin *
    header @origin Access-Control-Allow-Origin "*"
    header @origin Vary Origin
}

(logOptions) {
    roll_size 100MiB
    roll_keep 5
    roll_keep_for 168h
}

(reffererConfig) {
    header Referrer-Policy "strict-origin-when-cross-origin"
}

(ratelimiterOptions) {
    rate_limit {
        zone dynamic {
            key {remote_host}
            rate 10r/m
        }
        zone static {
            key {remote_host}
            rate 20r/m
            window 1m
        }
        zone api {
            key {remote_host}
            rate 5r/m
        }
    }
}

But also after upgrade these settings not working.
I get the following errors:

1.) Error: adapting config using caddyfile: ambiguous site definition:
2.) adapting config using caddyfile: File to import not found: encodingOptions, at /usr/local/etc/caddy/caddy.d/custom.conf:3 import chain ['/usr/local/etc/caddy/Caddyfile:216 (import)'] (but the options are set in snippets.global)
Also may I as why only
import /usr/local/etc/caddy/caddy.d/*.conf
is in the caddyfile but
import /usr/local/etc/caddy/caddy.d/*.global
before doesn't work?

any help is very important, I need my git and some other things back ;(
@Monviech could you help?
#15
24.7, 24.10 Legacy Series / Re: PHP Errors
September 15, 2024, 09:51:20 AM
Hi @Franco
this makes absolutely sense, I forget it after test something with home assistant.
It works for a while, now after you explain the situation, I check my home assistant config and there are also errors, which I fixed today.

I use it also for checking on updates, not only for opnsense (there is much more ;) ).
for me it's not necessary more a nice to have.

So thank you for the explaination, it would help me to sort such issues on opnsense.

Cheers and have a nice weekend.

0zzy