NetBird

CrowdSec AppSec is a web app firewall that inspects every HTTP request for anything malicious.

As soon as you spin up a fresh server, you’ll have bots hammering /.𝚎𝚗𝚟 and trying every SSH password they know.

This is where CrowdSec comes in, blocking malicious IP addresses based on a community-curated blocklist. So when any server running CrowdSec catches an IP misbehaving, that IP gets blocked for everyone else too.

NetBird Proxy publishes your internal services to the internet, so on top of CIDR allowlists and country blocking, you can turn on CrowdSec for each service and set it to observe or enforce.

If you self-host NetBird with NetBird Proxy and CrowdSec, you can go a step further and put AppSec in front of the NetBird dashboard itself!

AppSec checks what the request actually asks for, which means that, for example, a probe for /.env from an IP that isn't on any blocklist will still get a 403. It covers the dashboard, its API and the sign-in endpoints, through the CrowdSec plugin for Traefik and runs on the same container as CrowdSec.

Read the full guide:
netbird.io/knowledge-hub/…

Set a different login rule for each path in the reverse proxy!

The reverse proxy lets you have private apps on a public web address without opening ports + protected by some sort of auth (SSO, password, PIN, etc)

Before, one login rule applied to the entire app.

But now path-based auth changes that.

Under the target settings for the reverse proxy, you have three optional access settings:

• Use service authentication: Apply the authentication configured on the service, default.
• Bypass authentication: Skip SSO, password, PIN, and header authentication for this path. CIDR, country, and CrowdSec restrictions will still apply
• Block access: Return 𝟺𝟶𝟹 without contacting the backend.

So now a service can require SSO on /, skip entirely auth for a webhook or health check on /𝚠𝚎𝚋𝚑𝚘𝚘𝚔𝚜/ or /𝚑𝚎𝚊𝚕𝚝𝚑𝚣, and block /𝚊𝚍𝚖𝚒𝚗/ or /𝚖𝚎𝚝𝚛𝚒𝚌𝚜 from the public domain entirely.

Docs:
docs.netbird.io/manage/reverse…

Connected should not mean trusted.

Zero trust means removing the layer of automatic trust that usually comes from being inside a network.

Instead, every connection requires a policy that explicitly allows it. This means one compromised laptop cannot move laterally throughout a network.

For example:
If you had a production orders application with web, app, and database layers, you could structure the zero trust network policies like this.

• Users → web on TCP/443
• Web → app on TCP/8443
• App → database on TCP/5432
• Monitoring to all on 9100 and 9200
• Relevant groups to DNS on UDP and TCP/53

So if a support laptop is compromised, is can still only reach the web, and not the prod database directly.

This doesn't stop the attack from happening, but it does stop the attacker from accessing any resource inside the network.

Read the full guide on implementing ZTN:
netbird.io/knowledge-hub/…

Final boss of remote access?? Nope

PHP2Shell and three other major security issues hit self hosted services last week.

PHP2Shell had a vulnerability that let attackers run code on PHP servers without logging in. If you self-host anything, there’s a good chance PHP is running on one of your containers.

Here’s what to do:

• Make sure everything is updated. Rebuild your PHP containers, including NextCloud and WordPress, on the patched base.

• If a service doesn’t need to be public, take it off the open internet.

• Assume anything old and exposed was compromised, and rotate any credentials.

Check out Brandon’s full breakdown here on YouTube: youtube.com/watch?v=ksmWCW…