VMware Cloud Community
Steve879
Contributor
Contributor
Jump to solution

ESX Console access

Hi,

Does anyone know if it is possible to tie console access down to one IP Address. I have a management laptop with a static IP and I want to grant access to that IP Only. I imagine it is a firewall command but would be grateful for any advice .

0 Kudos
1 Solution

Accepted Solutions
Texiwill
Leadership
Leadership
Jump to solution

Hello,

There are many ways to dress this penguin and none of them are wrong, there are some more elegant solutions than others but Linux provides a host of tools to use when implementing security in depth on a system:

1) Use /etc/hosts.allow, hosts.deny

2) Use pam_access.so

3) Configure SSHD

4) Use iptables augmentation

The approach you take depends solely on what you wish to secure. For 'shell' access to the system using /etc/hosts.allow, /etc/hosts.deny and pam_access.so are powerful tools. pam_access.so has many more features and can deny access based on time of day, ip address, and group participation, where TCPWrappers can only deny based on IP Address. However, these only affect shell access to the host. For completely lock down of all management to only a few hosts, you will need iptables augmentation.

But as mike.laspina says, you really have to be careful in what you do, and understand the technology behind the security measure so that you do not break anything else. Come up with a test plan for any security change to ensure things work as expected.


Best regards,

Edward L. Haletky

VMware Communities User Moderator

====

Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education. As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill

View solution in original post

0 Kudos
9 Replies
Texiwill
Leadership
Leadership
Jump to solution

Hello,

The easiest way is to implement pam_access where you can allow or deny access based on IP address, user, hour of the day etc. A simplified approach is doecumented near the end of http://www.astroarch.com/wiki/index.php/Full_Integration_of_Active_Directory. Just search on pam_access.


Best regards,

Edward L. Haletky

VMware Communities User Moderator

====

Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education. As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
Ozric
Contributor
Contributor
Jump to solution

Hi Steve,

Hope I don't get burnt here for suggesting something as heretical as turning off the shipped esxfirewall and using the iptables subsystem instead but this is the an alternative method which does a pretty good job of reducing the attack surface - in fact it's probably more tied down than most people would want! I should say that going down this road can be a bit of a can of worms, the following script will probably need heavy modification to fit your environment but it's a start, also you might want to do some reboot testing - we've had to link this into the init scripts for it to survive a reboot.

#! /bin/bash

LOOP="127.0.0.1"

HIGH_PORTS="1024:65535"

MYIPADDR=`(ifconfig vswif0 | grep inet | cut -d: -f2 | awk '{print $1}')`

VCENTER="1.1.1.1"

MANAGEMENTSRV1="1.1.1.2"

MANAGEMENTSRV2="1.1.1.3"

BUILDSERVER1="1.1.1.4"

BUILDSERVER2="1.1.1.5"

NETSVCS1="1.1.1.6"

NETSVCS2="1.1.1.7"

ESXHOST1="1.1.1.8"

ESXHOST2="1.1.1.9"

ESXHOST3="1.1.1.10"

DOMAINCONTROLLER1="1.1.1.11"

DOMAINCONTROLLER2="1.1.1.12"

  1. Flush all the rules from filter table and nat table:

iptables -F

iptables -t nat -F

iptables -X

  1. We have ip forwarding disabled (see /etc/sysctl.conf)

  2. but just for a good measure...

iptables -P FORWARD DROP

  1. Discard all traffic by default

iptables -P INPUT DROP

iptables -P OUTPUT DROP

  1. Setup dropped packet logging

iptables -N LOGDROP

iptables -F LOGDROP

iptables -A LOGDROP -j LOG --log-level info --log-prefix "Drop:"

iptables -A LOGDROP -j DROP

  1. Setup accepted packet logging

iptables -N LOGACCEPT

iptables -F LOGACCEPT

iptables -A LOGACCEPT -j LOG --log-level info --log-prefix "Accept:"

iptables -A LOGACCEPT -j ACCEPT

  1. First, allow established and related connections

iptables -A INPUT -i vswif0 -d $MYIPADDR -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A OUTPUT -o vswif0 -s $MYIPADDR -m state --state ESTABLISHED,RELATED -j ACCEPT

  1. NTP traffic

iptables -A OUTPUT -o vswif0 -p udp -s $MYIPADDR --sport $HIGH_PORTS -d $NETSVCS1 --dport 123 -m state --state NEW -j ACCEPT

iptables -A OUTPUT -o vswif0 -p udp -s $MYIPADDR --sport $HIGH_PORTS -d $NETSVCS2 --dport 123 -m state --state NEW -j ACCEPT

iptables -A OUTPUT -o vswif0 -p udp -s $MYIPADDR --sport 123 -d $NETSVCS1 --dport 123 -m state --state NEW -j ACCEPT

iptables -A OUTPUT -o vswif0 -p udp -s $MYIPADDR --sport 123 -d $NETSVCS2 --dport 123 -m state --state NEW -j ACCEPT

  1. DNS traffic

iptables -A OUTPUT -o vswif0 -p udp -s $MYIPADDR --sport $HIGH_PORTS -d $NETSVCS1 --dport 53 -m state --state NEW -j ACCEPT

iptables -A OUTPUT -o vswif0 -p udp -s $MYIPADDR --sport $HIGH_PORTS -d $NETSVCS2 --dport 53 -m state --state NEW -j ACCEPT

  1. Web Server traffic

iptables -A INPUT -i vswif0 -p tcp -s $VCENTER --sport $HIGH_PORTS -d $MYIPADDR --dport 80 -m state --state NEW -j ACCEPT

iptables -A INPUT -i vswif0 -p tcp -s $VCENTER --sport $HIGH_PORTS -d $MYIPADDR --dport 443 -m state --state NEW -j ACCEPT

iptables -A INPUT -i vswif0 -p tcp -s $MANAGEMENTSRV1 --sport $HIGH_PORTS -d $MYIPADDR --dport 80 -m state --state NEW -j ACCEPT

iptables -A INPUT -i vswif0 -p tcp -s $MANAGEMENTSRV1 --sport $HIGH_PORTS -d $MYIPADDR --dport 443 -m state --state NEW -j ACCEPT

iptables -A INPUT -i vswif0 -p tcp -s $MANAGEMENTSRV2 --sport $HIGH_PORTS -d $MYIPADDR --dport 80 -m state --state NEW -j ACCEPT

iptables -A INPUT -i vswif0 -p tcp -s $MANAGEMENTSRV2 --sport $HIGH_PORTS -d $MYIPADDR --dport 443 -m state --state NEW -j ACCEPT

  1. Build server traffic

iptables -A OUTPUT -o vswif0 -p tcp -s $MYIPADDR --sport $HIGH_PORTS -d $BUILDSERVER1 --dport 80 -m state --state NEW -j ACCEPT

iptables -A OUTPUT -o vswif0 -p tcp -s $MYIPADDR --sport $HIGH_PORTS -d $BUILDSERVER2 --dport 80 -m state --state NEW -j ACCEPT

  1. VMware management traffic

iptables -A INPUT -i vswif0 -p tcp -s $VCENTER --sport $HIGH_PORTS -d $MYIPADDR --dport 902 -m state --state NEW -j ACCEPT

iptables -A INPUT -i vswif0 -p tcp -s $MANAGEMENTSRV1 --sport $HIGH_PORTS -d $MYIPADDR --dport 902 -m state --state NEW -j ACCEPT

iptables -A INPUT -i vswif0 -p tcp -s $MANAGEMENTSRV2 --sport $HIGH_PORTS -d $MYIPADDR --dport 902 -m state --state NEW -j ACCEPT

  1. VMware Virtual Centre management traffic

iptables -A OUTPUT -o vswif0 -p udp -s $MYIPADDR --sport $HIGH_PORTS -d $VCENTER --dport 902 -m state --state NEW -j ACCEPT

iptables -A OUTPUT -o vswif0 -p udp -s $MYIPADDR --sport $HIGH_PORTS -d $MANAGEMENTSRV1 --dport 902 -m state --state NEW -j ACCEPT

iptables -A OUTPUT -o vswif0 -p udp -s $MYIPADDR --sport $HIGH_PORTS -d $MANAGEMENTSRV2 --dport 902 -m state --state NEW -j ACCEPT

  1. VMware license server traffic

iptables -A OUTPUT -o vswif0 -p tcp -s $MYIPADDR --sport $HIGH_PORTS -d $VCENTER --dport 27000 -m state --state NEW -j ACCEPT

iptables -A OUTPUT -o vswif0 -p tcp -s $MYIPADDR --sport $HIGH_PORTS -d $VCENTER --dport 27010 -m state --state NEW -j ACCEPT

  1. VMware Virtual Centre deployment traffic

iptables -A OUTPUT -o vswif0 -p tcp -s $MYIPADDR --sport $HIGH_PORTS -d $ESXHOST1 --dport 902 -m state --state NEW -j ACCEPT

iptables -A INPUT -i vswif0 -p tcp -s $ESXHOST1 --sport $HIGH_PORTS -d $MYIPADDR --dport 902 -m state --state NEW -j ACCEPT

iptables -A OUTPUT -o vswif0 -p tcp -s $MYIPADDR --sport $HIGH_PORTS -d $ESXHOST2 --dport 902 -m state --state NEW -j ACCEPT

iptables -A INPUT -i vswif0 -p tcp -s $ESXHOST2 --sport $HIGH_PORTS -d $MYIPADDR --dport 902 -m state --state NEW -j ACCEPT

iptables -A OUTPUT -o vswif0 -p tcp -s $MYIPADDR --sport $HIGH_PORTS -d $ESXHOST3 --dport 902 -m state --state NEW -j ACCEPT

iptables -A INPUT -i vswif0 -p tcp -s $ESXHOST3 --sport $HIGH_PORTS -d $MYIPADDR --dport 902 -m state --state NEW -j ACCEPT

#Active Directory authentication traffic

iptables -A OUTPUT -o vswif0 -p tcp -s $MYIPADDR --sport $HIGH_PORTS -d $DOMAINCONTROLLER1 --dport 88 -m state --state NEW -j ACCEPT

iptables -A OUTPUT -o vswif0 -p udp -s $MYIPADDR --sport $HIGH_PORTS -d $DOMAINCONTROLLER1 --dport 88 -m state --state NEW -j ACCEPT

iptables -A OUTPUT -o vswif0 -p tcp -s $MYIPADDR --sport $HIGH_PORTS -d $DOMAINCONTROLLER2 --dport 88 -m state --state NEW -j ACCEPT

iptables -A OUTPUT -o vswif0 -p udp -s $MYIPADDR --sport $HIGH_PORTS -d $DOMAINCONTROLLER2 --dport 88 -m state --state NEW -j ACCEPT

  1. SSH traffic (ISManagement Servers)

iptables -A INPUT -i vswif0 -p tcp -s $VCENTER --sport $HIGH_PORTS -d $MYIPADDR --dport 22 -m state --state NEW -j ACCEPT

iptables -A INPUT -i vswif0 -p tcp -s $MANAGEMENTSRV1 --sport $HIGH_PORTS -d $MYIPADDR --dport 22 -m state --state NEW -j ACCEPT

iptables -A INPUT -i vswif0 -p tcp -s $MANAGEMENTSRV2 --sport $HIGH_PORTS -d $MYIPADDR --dport 22 -m state --state NEW -j ACCEPT

  1. SSH traffic (Secure File Copying)

iptables -A INPUT -i vswif0 -p tcp -s $ESXHOST1 --sport $HIGH_PORTS -d $MYIPADDR --dport 22 -m state --state NEW -j ACCEPT

iptables -A OUTPUT -o vswif0 -p tcp -s $MYIPADDR --sport $HIGH_PORTS -d $ESXHOST1 --dport 22 -m state --state NEW -j ACCEPT

iptables -A INPUT -i vswif0 -p tcp -s $ESXHOST2 --sport $HIGH_PORTS -d $MYIPADDR --dport 22 -m state --state NEW -j ACCEPT

iptables -A OUTPUT -o vswif0 -p tcp -s $MYIPADDR --sport $HIGH_PORTS -d $ESXHOST2 --dport 22 -m state --state NEW -j ACCEPT

iptables -A INPUT -i vswif0 -p tcp -s $ESXHOST3 --sport $HIGH_PORTS -d $MYIPADDR --dport 22 -m state --state NEW -j ACCEPT

iptables -A OUTPUT -o vswif0 -p tcp -s $MYIPADDR --sport $HIGH_PORTS -d $ESXHOST3 --dport 22 -m state --state NEW -j ACCEPT

  1. Allow all traffic on loopback interface.

iptables -A INPUT -i lo -s $LOOP -d $LOOP -j ACCEPT

iptables -A OUTPUT -o lo -s $LOOP -d $LOOP -j ACCEPT

  1. Allow "good" ICMP messages

iptables -A INPUT -i vswif0 -d $MYIPADDR -p icmp --icmp-type destination-unreachable -j ACCEPT

iptables -A INPUT -i vswif0 -d $MYIPADDR -p icmp --icmp-type time-exceeded -j ACCEPT

iptables -A INPUT -i vswif0 -d $MYIPADDR -p icmp --icmp-type parameter-problem -j ACCEPT

  1. Reduce Log Noise

iptables -A INPUT -i vswif0 -p udp -d $MYIPADDR --dport 137 -m state --state NEW -j DROP

iptables -A INPUT -i vswif0 -p udp -d $MYIPADDR --dport 138 -m state --state NEW -j DROP

  1. Add logging in the end of INPUT, OUTPUT and FORWARD chains

iptables -A INPUT -j LOGDROP

iptables -A OUTPUT -j LOGDROP

iptables -A FORWARD -j LOGDROP

  1. Write changes

service iptables save

service iptables restart

chkconfig iptables on

0 Kudos
Texiwill
Leadership
Leadership
Jump to solution

Hello,

While the route of using your own IPTABLES based script is possible, you run into several issues...

1) It is not supported and you could get into grey areas with VMware Support.

2) Many updates will re-enable the ESX controlled firewall. And then you have to disable and restart yours, it can be a forgotten step.

However, if you understand iptables and know what the script does, there should be no issues. I actually take a different approach in my Book. I show how to add new rules after the VMware Provided firewall script runs. These rules will lock down access by IP even further but work with the VMware provided tools so that #2 above is not an issue.

However, for just shell access concerns, the pam_access module is a slightly cleaner approach.


Best regards,

Edward L. Haletky

VMware Communities User Moderator

====

Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education. As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
0 Kudos
rossb2b
Hot Shot
Hot Shot
Jump to solution

I belive the recommended aproach is the use of TCP wrappers.

/etc/hosts.allow

and

/etc/hosts.deny

If you wanted to allow one system to access the esx server but block everyone else the hosts.allow would contain the line:

"sshd:192.168.1.1" and the hosts.deny would contain the line"

"sshd:ALL"

If no matching rules are found the default behavior is to allow accesss to you will need to test.

mike_laspina
Champion
Champion
Jump to solution

Hello,

You need to be careful with this. The console is more that just remote access. It performs many other tasks. I think you really just need to setup the sshd security for that.

Here is a site which will help.

http://blog.laspina.ca/ vExpert 2009
0 Kudos
Texiwill
Leadership
Leadership
Jump to solution

Hello,

There are many ways to dress this penguin and none of them are wrong, there are some more elegant solutions than others but Linux provides a host of tools to use when implementing security in depth on a system:

1) Use /etc/hosts.allow, hosts.deny

2) Use pam_access.so

3) Configure SSHD

4) Use iptables augmentation

The approach you take depends solely on what you wish to secure. For 'shell' access to the system using /etc/hosts.allow, /etc/hosts.deny and pam_access.so are powerful tools. pam_access.so has many more features and can deny access based on time of day, ip address, and group participation, where TCPWrappers can only deny based on IP Address. However, these only affect shell access to the host. For completely lock down of all management to only a few hosts, you will need iptables augmentation.

But as mike.laspina says, you really have to be careful in what you do, and understand the technology behind the security measure so that you do not break anything else. Come up with a test plan for any security change to ensure things work as expected.


Best regards,

Edward L. Haletky

VMware Communities User Moderator

====

Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education. As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
0 Kudos
Yvo
Contributor
Contributor
Jump to solution

Hi Steve,

The quickest and most secure way of doing this on the ESX Console is indeed by firewall command iptables. You can add a custom firewall rule for instance by using a script.

I assume for now that you're not using Virtual Center and only your laptop to manage a single ESX.

You must be aware though that using the default methods of configuring the firewall for ESX (for example esxcfg-firewall) doesn't provide you with that mechanism and could break your custom firewall rule. The same goes for updates to the system after new releases or patches. If you locking down the system this way is part the company policy, you have to test if this works after every applied patch or update.

In an enterprise environment I would suggest taking the restriction to a seperate firewall or ACL on a router.

For smaller environments the technical solution could be as follows:

Edit /etc/rc.d/rc.local and add the following lines or create a seperate script for it to be initiated from /etc/rc.d/rc.local

iptables -I INPUT -s ! <your mgt Laptop IP> -p tcp --dport 902 -i vswif0 -j DROP

iptables -I INPUT -s ! <your mgt Laptop IP> -p tcp --dport 80 -i vswif0 -j DROP

iptables -I INPUT -s ! <your mgt Laptop IP> -p tcp --dport 443 -i vswif0 -j DROP

Please not that the vswif0 must correspond with your Service Console interface. If multiple vswif interfaces exist that are used for iSCSI discovery, be carefull as you might break any iSCSI discovery or still have those interfaces open to management traffic.

I hope this helps.

Cheers,

Yvo

0 Kudos
Texiwill
Leadership
Leadership
Jump to solution

Hello,

It is important to realize that when you such iptables commands that where you Insert the rule makes a difference. What Yvo points out is a good approach as the -I option without a rule number specified places the rule at the beginning of the specified chain. However, if multiple chains are used, like the ESX firewall uses, you may want to make sure you insert things differently. Your mileage may vary on this however. There are many ways to dress the penguin when it comes to security and these work just as well as the others. I tend to implement all the options for a defense in depth just in case one option is not currently working. But please note that if you do not understand iptables or how security works within Linux you will want to read up on it first, and learn more about Linux. A simple command if done incorrectly can disable all access.

If you know Linux and Linux security go for it!


Best regards,

Edward L. Haletky

VMware Communities User Moderator

====

Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education. As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
0 Kudos
Steve879
Contributor
Contributor
Jump to solution

I have gone down the TCP Wrappers route to achive my aim although I am still interested in using PAM_Access to further tie access down.

0 Kudos