Once you install XCP-ng, all type of management is open wide.
I need to lockdown SSH as well as you cannot disable ssh access to the root account, you cannot add any other system users without joining the server to an active directory server, you cannot use SSH keys for authentication, only for CloudInit VM deployment and installing denyhost or fail2ban to ease the spambots can destroy the system.
XenAPI and HA clustering stuff is also open wide. Just take a peek at the default iptables (Ignore Zabbix that was added by me). I didn’t even install the XOA locally on the hypervisor itself and I could access the server via Xen Orchestra running inside of Docker in my homelab (Controlling XCP-ng from a Hyper-V portainer VM, now that’s fun).
# sample configuration for iptables service # you can edit this manually or use system-config-firewall # please do not ask us to add additional ports/services to this default configuration *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :RH-Firewall-1-INPUT - [0:0] -A INPUT -j RH-Firewall-1-INPUT -A FORWARD -j RH-Firewall-1-INPUT -A RH-Firewall-1-INPUT -i lo -j ACCEPT -A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT # Zabbix -A RH-Firewall-1-INPUT -p tcp --dport 10050 -j ACCEPT # DHCP for host internal networks (CA-6996) -A RH-Firewall-1-INPUT -p udp -m udp --dport 67 --in-interface xenapi -j ACCEPT -A RH-Firewall-1-INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT # Linux HA hearbeat (CA-9394) -A RH-Firewall-1-INPUT -m conntrack --ctstate NEW -m udp -p udp --dport 694 -j ACCEPT -A RH-Firewall-1-INPUT -m conntrack --ctstate NEW -m tcp -p tcp --dport 22 -j ACCEPT -A RH-Firewall-1-INPUT -m conntrack --ctstate NEW -m tcp -p tcp --dport 80 -j ACCEPT -A RH-Firewall-1-INPUT -m conntrack --ctstate NEW -m tcp -p tcp --dport 443 -j ACCEPT # dlm -A RH-Firewall-1-INPUT -p tcp -m tcp --dport 21064 -j ACCEPT -A RH-Firewall-1-INPUT -p udp -m multiport --dports 5404,5405 -j ACCEPT -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited COMMIT
Xen Orchestra also doesn’t have all supported XCP-ng features. I need to jump between the XCP-ng Center windows client, xe CLI and XOA if I want to switch the management interface properly.
Alternatively you can do it from local console/IPMI
What my current plan is:
Since I got a static IP, pfSense and OpenVPN working, I can modify the iptables to accept access to management only from that static IP from within the local VM network.
I know I will have to make bunch of static routes routes and get them pushed via OpenVPN somehow with “force all traffic to go through VPN” option disabled.
This also gives an easy configuration rollback in case the pfSense VM decides to die. I can just comment out the new rules, uncomment the rules that allow all management to be exposed, restart iptables service and voala I’m in to fix stuff. I have no idea how I’m going to handle backups with this configuration.