dch :flantifa: :flan_hacker:
boosted
As our company hosts servers, we have a public Security Policy and a security.txt file for ethical hackers to disclose vulnerabilities responsibly: https://handbook.dude.fi/security-policy
Because of this, I receive quite a few reports, most of them ineligible. I've also run into some "security experts" getting upset about not receiving a bounty for a non-issue or putting heavy pressure on payments for valid ones. It often feels unfair, like I'm being held hostage.
That's why replies like the one I just received warm my heart so much:
"Thank you very much for the clarification and for taking quick action to remove the DNS record. I appreciate the transparency and the kind offer as well.
I'd prefer to donate the amount to a child support charity instead. You’re very welcome to donate it on my behalf to any such organization of your choice."
Donation made. Thank you, stranger. Kindness costs nothing.
nullagent
boosted
What a great and transparent analysis of the outage. No excuses, honest admission of mistakes, and even shared an internal chat. Many large corporations could learn from this.
https://blog.cloudflare.com/18-november-2025-outage/
#Cloudflare #CloudflareDown #CloudflareOutage #Outage #SysOps #Servers
What a great and transparent analysis of the outage. No excuses, honest admission of mistakes, and even shared an internal chat. Many large corporations could learn from this.
https://blog.cloudflare.com/18-november-2025-outage/
#Cloudflare #CloudflareDown #CloudflareOutage #Outage #SysOps #Servers
How does a typical DDoS on a WordPress installation happen?
- A search-based DDoS attack by bypassing the cache
- Attacker sends a large volume of unique search queries so responses never hit the cache example ?s=something-xyz
- Each request becomes a cache miss, forwarded from network edge
- WordPress runs PHP + WP_Query for every request often triggering expensive database work.
- Repeated heavy queries exhaust CPU, memory and DB capacity so the website slows and eventually crashes.
- This is an Application-layer (Layer 7) HTTP flood that mimics normal user traffic.
- Key signals to look out for: huge spikes of /?s= requests in the logs, very high query entropy, cache-hit rate collapses.
Cache-busting search queries force every request through the database, turning cheap HTTP calls into expensive backend load.
Great Sysops lightning talk by Tiia Ohtokallio!
Does anyone know what could cause the error "HTTP/2 stream 1 was not closed cleanly: INTERNAL_ERROR (err 2)" or "Stream error in the HTTP/2 framing layer" when using cURL and monitoring? In the browser, this shows up as a blank page or an HTTPS error.
I'm running Nginx and PHP-FPM with FastCGI cache. This issue is new to me, and I have no idea how to fix it. Disabling FastCGI cache completely resolves the problem, which does not solve the underlying cause and of course leads to page not having a caching mechanism like this.
alcinnz
boosted
The systemd project was and is a huge leap forward for Linux. I can't imagine doing sysops without it.
https://blog.tjll.net/the-systemd-revolution-has-been-a-success/
Update: suspected "AI" usage for the images in the post, in case you want to avoid this.
The systemd project was and is a huge leap forward for Linux. I can't imagine doing sysops without it.
https://blog.tjll.net/the-systemd-revolution-has-been-a-success/
Update: suspected "AI" usage for the images in the post, in case you want to avoid this.