u/sk1nT7

Once Traefik is set up with working crowdsec it's basically just a matter of configuring aquis and defining a new Traefik middleware for the WAF stuff.

You can follow the latest WAF blog here:

https://blog.lrvt.de/how-to-enable-crowdsecs-waf-bot-detection-in-traefik/

It focuses on crowdsec's new bot detection feature but the underlying way of setting up WAF and the middleware is mostly the same.

You just have to define other appsec_configs rules, which define what your WAF will do. In the blog it's just the new bot detection features with crowdsecurity/appsec-bot-* but you can add the default crowdsecurity/appsec-default or OWASP CRS or anything else.

Check WAF rule list here: https://app.crowdsec.net/hub/waf-rules

So use the blog and do a bit of transfer thinking. Hope it helps.

Security through obscurity. Bots will just hammer scripts and CVE exploits against your instance.

It does not matter.

Pair Authentik with CrowdSec and call it a day. The most important part will be patch management.

Otherwise, anything you expose to the internet is an attack surface. However, an Identity Provider is typically meant to be exposed.

Imo there is no need for host network.

You can always use bridge networking and port map the relevant container ports to the host.

CrowdSec can definitely help. Won't block everything but a lot.

https://blog.lrvt.de/how-to-enable-crowdsecs-waf-bot-detection-in-traefik/

You may also check out CloudFlare. It will challenge a lot of bots too and provide DoS protection on top.

Honeypot is optional. Rate limiting is good.

The Traefik bouncer specifically enables AppSec via its middleware declaration:

crowdsecAppsecEnabled: true
crowdsecAppsecHost: crowdsec:7422

and CrowdSec was configured via aquis.yaml to listen on that interface:

listen_addr: 0.0.0.0:7422

Just make sure that Traefik and CrowdSec are in the same Docker network. Otherwise, Traefik cannot reach CrowdSec and its internal AppSec port 7422.

Alternatively, if running bare metal, adjust the listening interface and host declaration.

Crowdsec + it's new bot detection feature

AI was used to create a SEO wallpaper. The post itself was written manually and verified on my personal homelab infrastructure.

Don't underestimate the power of AI.

The devs have access to the source code. So I would even say there is no need for a human in the loop to fix this kind of input validation issue if there are proper tests written.

Tbh, the devs could find these kind of bugs and security issues even by themselves. LLMs are well aware about OWASP, CWE, hardening, best practices and all the public CVEs of other games out there. If the devs are smart, they are already making use of it.

I mean it's not that kind of rocket science to fix improper input validation from host to clients in a P2P network. So they could just implement that and prevent excessive ressource consumption.

Like, just don't allow faking 200 drones being spawned when the max player count is 10.

No.

Devs handling it unprofessionally. Yes.

I'd also recommend staying cautious and not ignoring the allegations.

In the same time I do not get the lack of information. If there is a vulnerability, it would be quite easy to explain it and provide a technical writeup. Especially when devs are behaving strange and deleting posts, someone (the researcher) would drop the bomb.

From what I've read though, I have not seen anyone discussing or at least pointing to anything somewhat technical.

Edit: Found a technical blog post. Server often down though. https://www.unknowncheats.me/forum/4792598-post1.html

• No technical details
• No proof of concepts or any insights on how the game may be affected or vulnerable.
• A person with 'cyber security background' writing on steam and not even understanding what CloudFlare CDN is
• Fear-mongering Reddit posts, AI wallpapers and suggestions to refund and delete the game

I don't understand the trend but I call BS.

The only thing one may dislike is the response of devs. Leaving people in the dark. Honestly though, with the lack of technical information or vulnerability writeup, I would not advertise an RCE either. Who knows what information was shared with devs.

Everyone can and is building their own stuff due to AI now. Most do not fully understand what they are building and how to properly secure it.

Most stuff is likely going to be a web-based service. Like a web app, mobile app and API backends.

I'd focus on app-based pentests with focus on AI features (chat Bots, RAG systems).

Ist bei fast allen Firmen immer das gleiche:

1. Active Directory Verzeichnisdienst - nicht gehärtet
2. Jeder Nutzer im AD (Authenticated User) kommt auf alle SMB-Netzlaufwerke, wo solche Dateien abgelegt werden.
3. Kein Einsatz von Passwort-Filtern oder Fine-Grained-Passwort-Policies. Dadurch kommt es sehr häufig vor, dass schlechte Passwörter gewählt werden. Sommer25, Sonnenschein12 usw. Und diese PWs werden schön wiederverwendet.
4. Helpdesk nutzt immer das gleiche PW zum Zurücksetzen eines Accounts. Im Worst Case muss der betroffene Nutzer das PW danach nicht mal ändern. Daher kommen die schlechten PWs wie Sonnenschein12, Sonnenschein12 usw.

Das sind alles 0815 Findings, die bei jedem internen Penetrationstest rauskommen. Technisch super einfach zu beheben - hängt meistens nur an der internen Politik.

Ask a senior. Ask whether you are allowed to use an LLM to assist and understand the code base. Ask what providers and models the company uses and offers.

You are an intern. It's normal to ask and not know.

Quick intro:

1. A Dockerfile defines how a Docker image is built.
2. A workflow file often defines when the image build process is triggered and where the resulting image is stored (GHCR, Dockerhub, custom registry). Check for github/gitea/forgejo/gitlab files/folders.
3. A compose file defines the stack of services that are needed to run the project. It often contains more than 1 service and lists the images, build args, envs and many more things. Many devs provide an env.example to understand what must be set and passed/interpolated into container runtimes.

Ippsec on YouTube.

You can also check out https://ippsec.rocks and search for active directory and related attacks/topics.

Laut Microsoft benötigen Angreifer dafür lediglich grundlegende Zugriffsrechte auf dem Zielserver, der Angriff selbst gilt als wenig komplex, erfordert aber eine Interaktion des Nutzers.

Hört sich jetzt weniger gefährlich an. EPSS von 1% bestätigt das auch.

You can add it there too, but TCP/80 should typically just redirect to your TCP/443 entrypoint, which itself already has aliasHeadersStrategy active.

If it redirects, the aliasHeadersStrategy must not be added as it would be duplicate. If it is not redirecting, definitely add aliasHeadersStrategy.

No v1.8.0 Tag yet on dockerhub? I only see v1.8.0-debian.

Man wird nicht zum „kritischen Dienstleister“ im Sinne von NIS2, weil man sensible personenbezogene Daten oder Bankdaten verarbeitet. Die Art der gespeicherten Daten ist nicht das Kriterium dafür, ob ein Unternehmen unter NIS2 fällt.

Das BSIG definiert relativ konkret, welche Unternehmen als wichtige bzw. besonders wichtige Einrichtungen gelten. Dazu gehören z.B. bestimmte Unternehmen aus Energie, Gesundheit, Verkehr und digitaler Infrastruktur sowie Cloud-, Rechenzentrums- und Managed-Service-Anbieter. Zusätzlich gelten grundsätzlich entsprechende Unternehmensgrößen.

Eine normale HR-SaaS wird also nicht automatisch NIS2-pflichtig, nur weil dort sensible Mitarbeiterdaten verarbeitet werden.

Auch wenn der Kunde selbst NIS2-pflichtig wäre, macht dich das selbst als Unternehmen nicht automatisch ebenfalls NIS2-pflichtig. Natürlich muss der Kunde seine Lieferkette berücksichtigen und kann deshalb entsprechende Security-Anforderungen an dich stellen. Das ist aber etwas anderes als eine eigene gesetzliche NIS2-Pflicht.

Ich glaube, da werden NIS2 und DSGVO gerade etwas durcheinandergeworfen.

Nur weil die Software online läuft und personenbezogene Daten verarbeitet, braucht man nicht automatisch irgendeine „NIS2-Zertifizierung“. So funktioniert NIS2 nicht.

NIS2 gilt auch nicht einfach für jeden SaaS-Anbieter, sondern nur für bestimmte Unternehmen und Branchen, teilweise auch abhängig von der Unternehmensgröße. Es geht dabei vor allem um Anforderungen an die Cybersicherheit von bestimmten Unternehmen, nicht darum, ob man personenbezogene Daten verarbeiten darf.

Für eine HR-Software ist viel eher die DSGVO das relevante Thema. Gerade bei Krankmeldungen bzw. Gesundheitsdaten muss man sauber arbeiten: AV-Vertrag, Zugriffsrechte, Verschlüsselung, Löschkonzept, Backups, Hosting, Unterauftragnehmer usw.

Der Punkt mit Haftung, Datenschutz und laufenden Betriebskosten ist aber völlig berechtigt. Für 250 € im Monat kann man sich da durchaus mehr Verantwortung einkaufen, als man zuerst denkt.

You basically add the aliasHeadersStrategy field in a preferred configuration (e.g. reject) to your Traefik HTTPS entrypoint. That's basically it. It will typically not interfere with your forward-auth configuration - except your application relies on weird HTTP headers with special characters (most do not).

I use Traefik + Authentik with various proxied application stacks behind. No issues at all so far.