Search results for query: hardening

What kind of connection and routing will that have? But we may give a piece of advice on this forum to have the OP e.g. run this entirely within VPN only accessed segment. :) So that this is not really a problem. I am not sure what you are attempting to achieve still. Maybe after you...

True. But the general security hardening of the average Joe's home server doesn't come anywhere near to the enterprise solutions. I must be honest here, looking at the OP's post - I'm not sure how much he knows about security hardening at all. So just setup a PBS instance on both servers, & use...

Hi all, I'm experiencing this same issue. (still new at Hypervisors so sorry if I misspeak) Running on an unprivileged container, tried with both nesting on and off, opening the console is blank until you wait like a few minutes, then the login message comes up and works perfectly fine. I've...

...systemd-logind.service files between Deb12 and Ubuntu 24.4. In both ProtectControlGroup=yes is set by default - one distribution is working and the other not. So both are applying the hardening with different results. The test containers are both running as unprivileged, unnested for isolation.

What about privileged containers though?

As a hardening measure, systemd tries to setup namespaces. In the instance of the Debian LXC template, it seems that setting ProtectControlGroups= to no in /lib/systemd/system/systemd-logind.service lets the systemd-logind.service start successfully. Another way to work around this is to enable...

Hi, Hardening, for any OS is not a trivial task. A wiki will be useful for most of the users. But it will be a dificult task, because are n situastion and use case like(only few...): - home user single PMX server - test lab(including cluster setup) - single PMX setup with remote access -...

I would say this is overly broad statement. On the opposite extreme side of the spectrum, I could state that if one truly wants mitigations, layers of separation, etc. ... just forget the whole KVM (let alone LXC) and go with Xen. So platforms-wise this part differs. Of course it impacts e.g...

...necessary. Security as applicable to a pve environment isnt really any different than any other virtualization platform, which means any hardening policies that would be best practices generically or even specifically to another platform (eg, vmware) would be just as applicable here. To make...

Well, as an example of the kind of thing I'd expect in a hardening guide for Proxmox: Use LISTEN_IP in /etc/default/pveproxy to control which interface or IP address the Proxmox web interface and spice proxy listen on Don't use the alternative approach of using ALLOW_FROM, DENY_FROM, and...

...way (apt upgrade and dist-upgrade comes to mind). And then the networking part where one might easily e.g. filter corosync traffic while "hardening" their HA cluster.... I do not think it's wrong for people to come ask here first before they are told "so this one you can follow the Debian (or...

...is part of the Hyper-V documeentation. This is the same for PVE. There are Debian forums and tutorial available that cover this and sometimes also non-distribution specific Linux tutorials. This is especially true for the hardening part, which is mostly just a "simple linux hardening problem".

As already said: Don't face them to the internet (directly)... there are plenty of technologies available ranging from VPN to TLS client certificates, that need to be deployed around your infrastructure. VLAN you stuff properly (at least this 3-layer solution): hardware mangagement interfaces...

...which host live, internet facing VMs. Thus the hosts themselves are internet facing too, or should at least be considered as such. Proper hardening isn't rocket science, but it sounds like the Proxmox testing and packaging process has enough gaps that extra care needs to be taken. Need to...

...fired for CVE fallout if they paid anything "enterprise", right? But it really does not offer anything more than best-effort SLA. Again, hardening in this sense would serve what purpose? To have it open to the internet? Something it was never designed for ... It is the right link from a...

...up in RHEL. The current Proxmox approach of "no-subscription" and "enterprise" repo seems to broadly do the same kind of thing. For a Hardening guide, it'd make sense to have a pretty prominent item about "Get a Proxmox subscription and use the Enterprise repositories". That should help...

...is always relevant , but they do not ask to get mocked. They would not be asking if it had been documented. Might that be a conscious decision too? [1] https://www.proxmox.com/en/downloads [2] https://enterprise.proxmox.com/iso/ [3] https://forum.proxmox.com/threads/security-hardening.134055/

1. This would be impossible to do, would turn into a farce. PVE is architected with the idea that it runs on a separate VLAN. 2. If you read some of the bugreports (never rotated CAs, keys, CSFR approach, etc.), how PVE team approaches security risks (CVEs) or how beta the "non-subscription"...

first hardening : do not open host to public, built-in firewall to allow only whitelisted ip or vpn.

Yes, even some overview pointing to guides would be useful. I guess there are tons of documentations for Debian security hardening out there that should also apply for PVE/PBS. Like making use of public private keys instead of passwords for SSH, fail2ban, proper monitoring, log collectors, SIEM...