351–360 of 422 posts
I wonder in a case like this how hard it would be to "steal" the crypto that you've paid to mine. But I assume these people are probably smart enough to where everything is instantly forwarded to their C&C server to prevent that.
Earlier quoted context omitted.
So $40 a year? Does that imply all monero is mined like this because it's clearly not cost effective at all to mine legitimately?
I think so, but it is hard to say. Could be a lot of people with extra power (or stolen power), but their own equipment. I mine myself with waste solar power
Deliberate heat generation.
If it's cold and you're going to be running a heater anyways, then if your heat is resistive, then running a cryptominer is just as efficient and returns a couple dollars back to you. It effectively becomes "free" relative to running the heater.
If you use a heat pump, or you rely on burning something (natural gas, wood, whatever) to generate heat, then the math changes.
This Monero mining also happened with one of my VPS over at interserv.net, when I forgot to log out of the root console in web-based terminal console to one of my VPS and closed its browser tab instead. It has since been fixed: Lesson learned.
This should not enable the compromise of your session, i.e. either there was some additional vulnerability (and not logging out widened the window during which it could be exploited), or the attack was totally unrelated. Either way, you should find out the real cause.
The world will be a better place when all crypto just disappears
a) containers don't contain b) if you want to limit your hosting environment to only the language/program you expect to run you should provision with unikernels which enforce it
Except it seems to have done so in this case?
Earlier quoted context omitted.
Absolutely not.
nearly half of all emails are spam https://www.statista.com/statistics/420400/spam-email-traffi...
> I also enabled UFW (which I should have done ages ago) I disrecommend UFW. firewalld is a much better pick in current year and will not grow unmaintainable the way UFW rules can. firewall-cmd --persistent --set-default-zone=block firewall-cmd --persistent --zone=block --add-service=ssh firewall-cmd --persistent --zone=block --add-service=https firewall-cmd --persistent --zone=block --add-port=80/tcp firewall-cmd --…
On ufw systems, I know what to do: if a port I need open is blocked, I run 'ufw allow'. It's dead simple, even I can remember it. And if I don't, I run 'ufw --help' and it tells me to run 'ufw allow'.
Firewall-cmd though? Any time I need to punch a hole in the firewall on a Fedora system, I spend way too long reading the extremely over-complicated output of 'firewall-cmd --help' and the monstrous man page, before I eventually give up and run 'sudo systemctl disable --now firewalld'. This has happened multiple times.
If firewalld/firewall-cmd works for you, great. But I think it's an absolutely terrible solution for anyone whose needs are, "default deny all incoming traffic, open these specific ports, on this computer". And it's wild that it's the default firewall on Fedora Workstation.
> I also enabled UFW (which I should have done ages ago) I disrecommend UFW. firewalld is a much better pick in current year and will not grow unmaintainable the way UFW rules can. firewall-cmd --persistent --set-default-zone=block firewall-cmd --persistent --zone=block --add-service=ssh firewall-cmd --persistent --zone=block --add-service=https firewall-cmd --persistent --zone=block --add-port=80/tcp firewall-cmd --…
> I also enabled UFW (which I should have done ages ago) I disrecommend UFW. firewalld is a much better pick in current year and will not grow unmaintainable the way UFW rules can. firewall-cmd --persistent --set-default-zone=block firewall-cmd --persistent --zone=block --add-service=ssh firewall-cmd --persistent --zone=block --add-service=https firewall-cmd --persistent --zone=block --add-port=80/tcp firewall-cmd --…
> Specifically for docker it is a very common gotcha that the container runtime can and will bypass firewall rules and open ports anyway. Like I said in another comment, drop Docker, install podman.
Earlier quoted context omitted.
> Not if you run it in rootless mode. Same as for docker, yes? https://docs.docker.com/engine/security/rootless/
Rootless exists in Docker, yes, but as OP said, it's not first-class. The setup process is clunky, things break more often. In podman it just works, and podman is leading with features like quadlets, which make docker services just services like any other.