It probably has a large database of exploits it can use. The article claims 20k, but this seems to high for me.
It probably has a large database of exploits it can use. The article claims 20k, but this seems to high for me.
Yes, but they replace common tools like top or lsof with manipulated versions. This might at least trick less experienced sysadmins.
Edit: Some found out about the vulnerability by ressource alerts. Probably very easy in a virtualized environment. The malware can’t fool the hypervisor ;)
I agree, but I understood this question in the context of a homelab.
And for me, a homelab is not the right place for a public website, for the reasons I mentioned.
No, with these reasons:
I have a VPS for these tasks, and I host a few sites for friends amd family.
Just one open source example … freeradius has an option to log passwords:
log {
destination = files
auth = no
auth_badpass = no
auth_goodpass = no
}
Or another example: The apache web server has a module that dumps all POST data, with passwords, in plain text:
mod_dumpio
allows for the logging of all input received by Apache and/or all output sent by Apache to be logged (dumped) to the error.log file. The data logging is done right after SSL decoding (for input) and right before SSL encoding (for output). As can be expected, this can produce extreme volumes of data, and should only be used when debugging problems.
I don’t agree that this is “absolutely malice”, it could also be stupidity and forgetfulness.
This is not about facebook not hashing credentials, it is that they appeared in internal logs.
Facebook is probing a series of security failures in which employees built applications that logged unencrypted password data for Facebook users and stored it in plain text on internal company servers.
Source: Krebs on Security
Yes, that is why many big tech companies have their european hq there.
You’re right, Google released their vision in 2023, here is what it says regarding lifespan:
a reduction of TLS server authentication subscriber certificate maximum validity from 398 days to 90 days. Reducing certificate lifetime encourages automation and the adoption of practices that will drive the ecosystem away from baroque, time-consuming, and error-prone issuance processes. These changes will allow for faster adoption of emerging security capabilities and best practices, and promote the agility required to transition the ecosystem to quantum-resistant algorithms quickly. Decreasing certificate lifetime will also reduce ecosystem reliance on “broken” revocation checking solutions that cannot fail-closed and, in turn, offer incomplete protection. Additionally, shorter-lived certificates will decrease the impact of unexpected Certificate Transparency Log disqualifications.
Sorry, I understood you wrong. You’re right!
Nothing of value was lost when EV certificates disappeared.
even more secure with the 90 days policy.
Yes, if you do this manually it will work.
I meant certbot with nginx plugin and http-01 challenge.
You’re right, ssl.com offers this, too.
IMO, sticking to manual processes that are error-prone is a waste of money and not a sign of a honest business.
Yes, it can be easier. But not every DNS provider allows API access, so you might need to change the provider.
(good luck with that in many enterprise scenarios).
I’ve set it up fully automated with traefik and dns challenges.
Letsencrypt issues wildcard certificates. This is however more complicated to setup.
AFAIK, the only reason not to use Letsencrypt are when you are not able to automate the process to change the certificate.
As the paid certificates are valid for 12 month, you have to change them less often than a letsencrypt certificate.
At work, we pay something like 30-50€ for a certificate for a year. As changing certificates costs, it is more economical to buy a certificate.
But generally, it is best to use letsencrypt when you can automate the process (e.g. with nginx).
As for the question of trust: The process of issuing certificates is done in a way that the certificate authority never has access to your private key. You don’t trust the CA with anything (except your payment data maybe).
ssh with an easy to guess root password?