I am trying to harden my ESXi servers. With NMAP, I see that the following ports are open:
Discovered open port 22/tcp on 192.168.112.176
Discovered open port 80/tcp on 192.168.112.176
Discovered open port 427/tcp on 192.168.112.176
Discovered open port 443/tcp on 192.168.112.176
Discovered open port 902/tcp on 192.168.112.176
I am trying to disable port 80, 427 (what does this port do exactly) and 443. Also, I'd like to make a script that can be run to enable/disable port 902 on the fly. I've tried disabling 'wsmand' with chkconfig, removing the script from /etc/init.d/, but I can't seem to get the (web)services to stop running. Is there a built in firewall, or is there any way to disable the (web)services from running?
You will need 443 at least for virtual centre to talk to your ESX host.
There is a good diagram here showing port requirements for Vi3.5 (and i assume it hasnt changed for 3i but i could be wrong):
http://communities.vmware.com/servlet/JiveServlet/download/834498-4910/VI3.5%20ports.jpg
And a discussion on port requirements here:
You'd want to leave 902 open for communication between ESX hosts and 427 is for the CIM client.
I'm not running a VC host for this ESXi machine, so I think I can disable 80,443 and 427. I want to disable 902, but enable it (via SSH) when I need to use the VI-client.
When looking at the image wgardiner posted, I see that I will still need 443 for VI-client access, so i'll need a way to enable/disable these ports on command, while port 80 and 427 need to be closed at all times. Is there any way to do this?
With ESXi you don't have SSH and use of the console to do this would not be supported. What are the factors driving your need to disable these? Perhaps you could accomplish your goals by putting the management port of ESXi on a private management network.
I am aware of the lack of support in this situation, but I cannot use any other method. This ESXi server will be placed in a colocation datacentre, with a public network infrastructure. Since this machine will be connected to the internet directly, I want to disable as much ports as possible. Turning on SSH is a must, since the machine will be out of my direct control, so managing it has to be done via the Internet. To gain a little bit more control, I need SSH.
If you need SSH you would have to go with ESX 3.5. I can appreciate that it may be a bit difficult to configure things in this situation, but sticking the management IP on the Internet is something you may sorely regret some day. Do you have the option to put in a VPN server or even a firewall? I realize that the co-lo may provide a firewall with you, but with a second firewall you could then stick your management port behind that. You could do inbound NAT and filter the source IP to your office location so that you'd still have "direct" acces to the host to manage it with the VI client. But in this way your host wouldn't be exposed to attack for any public IP. Your VMs would be on a seperate vSwitch so those could still have public IP addresses.
But you can access 3.5i via SSH can't you? Isnt it running a little service consol-ey mini linux distro?
I am trying to accomplish the same thing with ESX3.5, and that actually seems to get the job done in a better way. However, today I stumbled upon the unsupported CLI in ESXi, and I gave it a go. If ESXi fails to provide a good and easy way to block ports and/or disable services, I will be reverting back to testing ESX3.5 to accomplish my colocation goals.
Unfortunately, I have no means to use a firewall (either my own or ISP/co-lo provided), so I'm stuck with the whole management port directly on the internet thing, which I probably condemn as much as you do .
By pressing ALT-F1 after booting your ESXi server, and typing 'unsupported', you get access to a small busybox-based CLI/console. It provides me with just enough features to manage this server when all else (the VI-client) fails. See Run Virtual for more information on this subject.
Unfortunately, I have no means to use a firewall (either my own or ISP/co-lo provided)
Huh? Sure you can, you are running a virtualisation host, but it can't run a small firewall VM for you?
Remember you can have it autostart when your host boots and then simply use ssh forwarding to get access to the host management interface of your ESX server. Use a vSwitch with no external nic attached to set up the management network.
Under NO circumstance I would EVER want to expose my management interface to the internet, not even if it is completely "protected" by tcp wrappers and internal firewall. If you do, then there's only a single protection layer protecting your host (and indirectly all of your VMs)
--
Wil
I could indeed set up a firewall (like pfSense) in a VM, but since I can only administer this machine remotely, I'm a bit scared of having a unmanagable machine when this VM fails, forcing me to drive 2 hours to the datacentre...
Personally I would be much more afraid of having to do so with a car full of tapes with the backups from the VMs after the server is compromised.... when having the management interface tied to the internet. By shutting down all the services you intended to shut down, your server will be pretty hard to handle as well as you can no longer -for example- setup a console directly to your VMs. Use vmware converter to hotclone a VM or import one straight into your host.
So you'll pretty much have only a command line after that.... and it isn't a safe setup in my opinion as none of your VMs can be trusted after a host has been compromised. If the firewall VM is compromised then there's still another hack needed in order to control the host.
A hardwire firewall is better, but when having no other option, using an isolated VM is the way to go.
With the firewall VM you'll still be able to manage using a console etcetera as you can setup a VPN to connect to your management interface.
As for being worried that your firewall VM doesn't start.... it can happen, but in such a case, no VM would probably run.... you could safeguard for that by writing a little script to your ESX host that scans if the VM is running every 15 minutes and if it isn't, have it boot another one (a rescue firewall VM so to speak)
--
Wil
With a default install there is no SSH access, but you can modify /etc/inetd.conf to allow it (but in doing so you technically have an unsupported system). The service console is running an older version by Busybox.