everywhere.fraudulent.link is a Fediverse instance that uses the ActivityPub protocol. In other words, users at this host can communicate with people that use software like Mastodon, Pleroma, Friendica, etc. all around the world.
This server runs the snac software and there is no automatic sign-up process.
I'm removing the Availability part of the security triad. If availability is important to you, then setup a HA cluster and monitor it closely. Or better yet, setup some open-source contribution department, or a development fund and fix these issues yourself. Too many critical security alerts are clogged up by theoretical DOS methods that already require someone to be in the network. It simply doesn't deserve to be the same.
Uptime is simply not as important as integrity or confidentiality.
DOS does not deserve to be considered a Major Cyber Risk, it should never receive a CVE above 2.
By the existing logic, GET requests remain the single-most critical widely used DDOS exploit that has prevailed for 50 years with regular news headline coverage.
I do wonder, has there been any app so far that implemented #Telemetry with an "on-demand" basis? Meaning that users can report bugs through the app itself and optionally allow for telemetry to be turned on temporarily until the bug has been identified and fixed? If there's no contact info attached to the report it would still be anonymized.
I think this could really be a good compromise, as long as it's implemented correctly and transparently. π€
#programming #privacy #security
The way Gitlab, Forgejo, Gitea etc. use the server-side SSH server to accept pushed data over SSH relies on a system user called Access is granted by the standard I really hate this, this means that any user of Forgejo is only inches away from having full shell access. The default shell of the git
having SSH access. (or forgejo
in their case).authorized_keys
inside ~/.ssh, which for forgejo means /var/lib/forgejo/.ssh/authorized_keys
. When a user adds an SSH key to their account, it's added to this authorized_keys file.forgejo
user is /bin/bash
, it exists inside of /etc/passwd
:
forgejo:x:122:130:Forgejo (Beyond coding. We forge.):/var/lib/forgejo:/bin/bash
I really really hate this. The only thing preventing random users of Forgejo having shell access is the default command of the SSH session as stipulated by the authorized_keys
entry, this is what it looks like:command="/usr/bin/forgejo --config=/etc/forgejo/app.ini serv key-1",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,no-user-rc,restrict ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOgnZeNC4fMCXYuWxir7NlKts9Zj4sYZZJzzHh4IyTm2 Baa-New
forgejo
user. It will immediately disconnect you, and if you try submitting any specific command you'll receive Disallowed command
.But still, I really really really hate this. We're just one tiny misconfiguration, one minuscule exploit away from granting all forgejo users shell access into the server
βImagine for example, you were hosting a Minecraft server on Windows. And to grant a user access to it, you had to create them a Windows User inside
control userpasswords2
and then explicitly disallow them RDP access. That RDP config is the only thing preventing them for remoting straight into your server. This si what it feels like, I can't help but wish SSH was entirely separate from everything else going on here.Which is exactly what Forgejo's own built-in SSH server does, I'll enable that and move it to a different port, because I'm too scared otherwise, and my server's not even public, and I haven't even started with Runners yet, those scare me even more
βFeel free to correct me if I'm wrong, or add your own insights I'd like to know more about this mentality
#ssh #git #forgejo #linux #security #gitlab