> they were overwhelming a hardcoded Nginx redirect (a simple rewrite regex directive)
1. I wonder how much optimization ngx_http_rewrite_module has? Does it precompile the patterns? LLM said yes, this SO answer [1] says that a JIT config option must be on. I consider "Just in Time" to be a half measure when the config itself is static.
2. From looking at NGINX docs, it looks to me there are some pitfalls to writing these rules. Like you must manually make sure to short-circuit the rewrites to exit early?
3. The caveat of regex is that catastrophically backtracking regexes do look simple. I don't see this issue being talked about enough. See links, if you, the reader, haven't heard of it yet.
Sorry for the stress that the team had mitigating this attack. Yet I'm always excited to see signs of competence on the attacking side: a targeted application-specific and adaptive attack at L7? Wow!
Here's another guess: a DDoS to steal your attention and mask other intrusion attempts.
> Defenses need to have broader rate limits across more than just IPs (ASNs, hostnames, etc.).
The description/approach seems static and limited? Why not maintain a leaky bucket that counts each request (tickets/points) with higher cost for expensive requests (404, redirects). As the IP's reputation deteriorates (IPv4/32), it begins to spill over to a broader subnet like IPv4/31 then /30 and so on. Fight adaptivity with adaptivity. // maybe I describe something totally obvious, I'm not involved in the web ddos protection side of things.
> Attackers actively search for non-cacheable paths (e.g. dynamic redirects, search endpoints, and 404s).
To continue with my previous point. As long as individual server's resources permit (memory, socket limit) stall requests before processing them. Low reputation IPs get stalled for longer and the requests that exceed the queue get dropped. The idea is graceful degradation:
A good rep IP will not be stalled by sleep(). A poor rep IP will be stalled, but eventually receive its answer instead of some 429/403 (i.e. a user who opened many tabs at once). A bad rep IP will be slowed down by the wait times + rate-limits (queue exceeded) before getting completely banned for good. The point is to have more granularity before throwing errors at random users at the server-level.
> The description/approach seems static and limited? Why not maintain a leaky bucket that counts each request (tickets/points) with higher cost for expensive requests (404, redirects). As the IP's reputation deteriorates (IPv4/32), it begins to spill over to a broader subnet like IPv4/31 then /30 and so on. Fight adaptivity with adaptivity. // maybe I describe something totally obvious, I'm not involved in the web ddos protection side of things.
The penalty box strategy I described in the post is along these lines. It penalizes excessive expensive requests directly. Specifically, it does add those to a score and will rate limit more broadly as necessary.
You need to up your irony. The proles were reading Orwell's 1984 and thought "hey, I shouldn't mind being spied on by (smart) TVs!" because this is the statistically average behavior of the consumers.
> On the fact that centralization is bad, we agree. DNS resolver centralization is not a great thing, and it seems to be trending in the wrong direction.
It seems all too similar to the degradation of peer-to-peer networks where nodes are replaced by few supernodes. You mentioned a couple reasons yourself: consolidation and legal pressure. Add to this the technical qualification aspect and time investment (Mullvad's position), and the financial cost of sustaining such a non-profit project. Suddenly there are very few people or even organizations worldwide, who can bear the burden.
dear sockpuppet =) I think the above commenter meant illegal physical access. The jabber.ru MitM situation was likely carried out by a cybercrime unit of the German police forces with a court order... and this is the adversary most people forget about.
Lesson to learn: Let's Encrypt does not protect against MitM by a state-level actor, unless you take precautions.
*let's assume network admins won't MitM your server for personal vengeance reasons
And this is why I will continue supporting the position of "ending copyright altogether":
Average of (current maximalist copyright; ending copyright) is what you called middle ground.
Average of a sensible position like (current maximalist copyright; ending copyright divided by 2) still does not yield a sensible world where culture and art - or even human interactions - can thrive.
Allow me to put it more bluntly: if you are feeling like an artist, don't meddle with UX.
The comment above shows this type of people don't understand it. Yet they are the ones getting hired due to formal qualification. Those who do are at the intersection of design, engineering and computer science. The latter give you enough experience to understand the culture to recreate familiar _look and feel_.
Over 100 comments, zero mentions that government funds should be spent on devices with auditable open-source firmware. Anyone here? No? Then I'm the first one to say this.
SecureBoot is a funny one. It should be signed with the deployer's keys (Slovak), not the manufacturer's. Trusted boot probably wasn't a consideration here, really.
Ironically, a custom firmware can now be used thanks to the lack of a digital lock... if you still trust the hardware.
Maybe you trust the hardware and software and firmware to not be malicious or negligent (currently such assurances are extremely rare [1], so it's hard to overstate what a step up in security just this bare minimum would be), but what if it simply gets hacked by a nation-state level opponent? And there are so many ways to hack it - hardware and software supply chains, interdiction and replacement with compromised parts, attacking the software systems connected to it (maybe the camera is secure, but what about the computers it sends its signals to?), or the human systems, blackmailing an employee to insert a backdoored USB key somewhere...
Are traffic cameras worth the risk of giving away the movement of your key personnel, military and political, in the age of drone warfare and targeted strikes?
Fair. I see, you are against traffic cams in general? One approach is to take away their networking capabilities. Dump the data from them manually, physical access :) like 26 years ago in the year 2000 AD. But the police and agencies will cry about losing real time access (and surveillance) capabilities.
While you raise good arguments against wide deployment, politics will not backtrack. Despite the loopholes, despite the vulnerabilities, despite real life precedents, the juggernaut will keep moving. Much like blackouts or internet outages (Canada) that make payments, digital communication impossible, people will not rely any less on cashless payments etc. That's the blackpill.
The Navy drones article is terrifying. The easier solution is to not have wars at all (lol) then the problem is reduced to only corporate espionage.
"at all" -> I would like to believe a government tender to wield more power than just being at the mercy of commercial market offerings.
"similar price to closed source" -> Good argument. But what if the _lower price_ is only lower thanks to a vendor lock-in? Thus, over a long period of time, you don't get a better deal? Furthermore, here an expensive reverse-engineering project had to discover the backdoors? What was its cost? Why can't the government have this work done (new cameras) on a contract basis?
First step: "we want this and that, you may choose the hardware freely, but the project source code will be perpetually licensed to the government to use and extend upon." Second step: "we have this source code from the last contract, we want another 1000 of these traffic cameras with improved specs/features."
The belief, that the market will do anything right, perpetuates this system of outsourcing everything to the market. Though I don't think it can work any other way, because nobody among the government workers wants to bear responsibility and liability. It's much easier to give party B the money and then argue with them based on the paper trails. This is what they've been trained to do after all.
1. I wonder how much optimization ngx_http_rewrite_module has? Does it precompile the patterns? LLM said yes, this SO answer [1] says that a JIT config option must be on. I consider "Just in Time" to be a half measure when the config itself is static.
2. From looking at NGINX docs, it looks to me there are some pitfalls to writing these rules. Like you must manually make sure to short-circuit the rewrites to exit early?
3. The caveat of regex is that catastrophically backtracking regexes do look simple. I don't see this issue being talked about enough. See links, if you, the reader, haven't heard of it yet.
[1] https://stackoverflow.com/questions/59284921/how-much-impact...
[3.1] https://joshua.hu/nginx-directives-regex-redos-denial-of-ser...
[3.2] https://en.wikipedia.org/wiki/ReDoS
[3.3] https://infrafolks.com/blog/regex-backtracking-devops/
[3.4] https://www.regular-expressions.info/catastrophic.html
[3.5] https://gixy.io/plugins/regex_redos/
reply