if you put a webserver up on the internet. anywhere, hosting anything, you will see "the background radiation of the internet", and it looks like this:

and what you can take away from this log is that the reason they are blasting the entire internet, every webserver with these requests - most of which are 'im gonna hit myself in the face with a brick now' level of bad from a config/dev/admin perspective - is squarely because it has worked for them enough times that they feel spraying the internet will nab them more.

look.
just look at the shit they're collecting and how easily theyre doing it.

this is because docker
this is because k8s

this is because everywhere has gone "DX" - or "optimizing for the developer experience above all else, at the cost of everyone else. "

make things as easy as possible for the devs/devops, we dont care how bad the security becomes, how many layers of abstraction get installed, how many dozen new js frameworks appear this afternoon, how public the data is, how bad the architecture is - burn the building down

just make sure the devs are comfy

@Viss I largely agree in some sense. But at the same time it kinda strikes me that this has been the case for 20-odd years, at least since apache + mod_php.

The core of it is that people are lazy, but I don't know if it's fair to pin that on tooling. I think the weight of "want to be online" versus the weight of "doing online correctly" always leads to this, and I don't think you can make "do online correctly" easier because it is really fucking hard. Plus, if anything, docker and k8s should get us closer to that.
@nepi have you ever been on a security team where either you are attacking this sort of infrastructure, or trying to harden/secure it?
@Viss I work closely with our security team at work, yes.

@nepi ask them about how they go about attacking k8s. I've been inside and out of ~30 k8s infrastructures and maybe 3-5 of them were secured. a couple were actually impressively hardened, the vast majority of the rest of them just assumed that aws or azure or whoever was hosting their cluster 'just did it for them'.

many many - i'd argue the overwhelming majority of orgs who run k8s make this assumption.

@nepi what many folks just dont seem to get is that all those apis are public, because cloud. anyone in the world can get to them. and the secrets tend to be very very poorly secured. if even at all.

so if you find one errant .env file around, or if you have a shit-tier app that lets someone from the web see the env, they just loot the secrets out, and then they hit those public apis and take over the aws account.

its rampant.

@nepi and you dont have to take my word for it - just look at the logs.

live attackers are actively probing every single open web port on earth for these files. and the reason they're doing that is because they have had enough success in doing so that its worth being THAT NOISY to find more.

@nepi further evidenced: there are currently roughly 10k public docker registries exposed to the internet.

in many cases, they wont have auth, and for the ones that dont have auth you can:
- pull down an image
- back door it with a mess of bullshit
- push it back up again

and now you own them from the inside.
and in 100% of cases you see stuff public like this, they arent logging. or they arent looking at logs. because those logs are ALREADY full of bullshit

@Viss 100% of the people who forget to secure their container registries aren't looking at their logs.

@Viss @nepi Specifically Docker registries: Let's look at the image's documentation.

tl;Dr: This confirms @Viss views regarding dev experience, and not security.

https://hub.docker.com/_/registry

It's listed as an "official image" and is even recommended in Docker's blog (https://www.docker.com/blog/how-to-use-your-own-registry-2/)

By default (both in the documentation, and in the blog):
- It is exposed publicly (-p 5000:5000 instead of -p 127.0.0.1:5000:5000)
- It has no authentication.

But luckily, there is documentation linked! Even a deployment guide: https://distribution.github.io/distribution/about/deploying/

There is a lukewarm warning at the top to look at the list of config options for security. Otherwise you have to scroll the deployment documentation a long way down down to get to the authentication section.

Docker

@varbin @nepi its not a suspicion on my part, i do security assessments and training for a living. ive .. seen.. things...
@Viss @nepi To be fair, they're doing it because they find success AND because it is piss cheap to try. Same with spam mail, if you send a million messages and get one hit, congratulations you've turned a profit.