@openwrt routers often run on tiny hardware with limited storage, which makes adding intrusion prevention such as @CrowdSec tricky.

I managed to set up only the lightweight firewall bouncer on #OpenWrt, and forward its logs via Syslog to the Security Engine in #Docker (server).

Result: community-powered IPS on tiny hardware. 🚀

Here's how to set this up yourself: https://kroon.email/site/en/posts/openwrt-crowdsec/

#OpenWrt #CrowdSec #SelfHosting #Security

For more than four days, a server at the very core of the Internet’s domain name system was out of sync with its 12 root server peers due to an unexplained glitch that could have caused stability and security problems worldwide. This server, maintained by Internet carrier Cogent Communications, is one of the 13 root servers that provision the Internet’s root zone, which sits at the top of the hierarchical distributed database known as the domain name system, or DNS.

Given the crucial role a root server provides in ensuring one device can find any other device on the Internet, there are 13 of root servers geographically dispersed all over the world. Normally, the 13 root servers—each operated by a different entity—march in lockstep. When a change is made to the contents they host, it generally occurs on all of them within a few seconds or minutes at most.
Strange events at the C-root name server

This tight synchronization is crucial for ensuring stability. If one root server directs traffic lookups to one intermediate server and another root server sends lookups to a different intermediate server, the Internet as we know it could collapse. More important still, root servers store the cryptographic keys necessary to authenticate some of intermediate servers under a mechanism known as DNSSEC. If keys aren’t identical across all 13 root servers, there’s an increased risk of attacks such as DNS cache poisoning.

For reasons that remain unclear outside of Cogent—which declined to comment for this post—the c-root it’s responsible for maintaining suddenly stopped updating on Saturday. Stéphane Bortzmeyer, a French engineer who was among the first to flag the problem in a Tuesday post, noted then that the c-root was three days behind the rest of the root servers.

https://arstechnica.com/security/2024/05/dns-glitch-that-threatened-internet-stability-fixed-cause-remains-unclear/

Digging a little bit in the some ICC profiles added in signal-app, I updated the original issue and there is clearly an issue where new ICC profiles are created from the Google skia library.

https://github.com/signalapp/Signal-Desktop/issues/6031#issuecomment-1702432836

This issue only appears when the media-quality is to high. Maybe an allow-list strategy like the mat2 tool written by @jvoisin would be better to be sure that new metadata created are discarded by default.

@signalapp

#privacy #signal #signalapp #metadata