VMware Cloud Community
fcoa
Contributor
Contributor
Jump to solution

Risky to allow VM access to storage network and LAN?

What sort of risk(s) might we be exposing our storage network to if we were to assign a VM with NICs on both the LAN and SAN?

Tags (3)
0 Kudos
1 Solution

Accepted Solutions
Texiwill
Leadership
Leadership
Jump to solution

Hello,

Moved to the Security forum.

The risk of exploitation is fairly minimal.

Not quite true. iSCSI and NFS protocols are in the clear! So it may be possible to do any number of things (ARP Cache poisoning comes to mind) to allow the storage data to flow to a compromised host. A colleague recently demoed just this. It is actually quite trivial to do with the proper tools.

The attack surface being lowered by limiting the number of machines that span those networks.

That is correct, the upper limit of this really should be 0 however for better security. Not only this, if the SAN is really an iSCSI Server, then this server could possibly be used to attack the service console depending on how the SC was also connected to the storage network. You have now increased the possible attack points for the SC by 1 or more.

You also want to make sure that network is not routed, so that network is not available from other machines not directly connected to the SAN network.

Absolutely.

The risk you open is that an admin would have access to the storage data. That is what you are trying to avoid.

If the host that can span both your LAN and SAN is compromised then it could be possible for ANY user on the system to actually get the storage data as it travels on the SAN network.

The best solution is that if you will have a VM or Server that bridges these networks that they actually bridge to an IP Storage device that is not being used by the ESX hosts, the one exception to this could be the VCB Proxy but you need to secure this as well if not better than your ESX hosts themselves. Make sure it is in a protected space, etc.


Best regards, Edward L. Haletky VMware Communities User Moderator, VMware vExpert 2009, DABCC Analyst[/url]
Now Available on Rough-Cuts: 'VMware vSphere(TM) and Virtual Infrastructure Security: Securing ESX and the Virtual Environment'[/url]
Also available 'VMWare ESX Server in the Enterprise'[/url]
[url=http://www.astroarch.com/wiki/index.php/Blog_Roll]SearchVMware Pro[/url]|Blue Gears[/url]|Top Virtualization Security Links[/url]|Virtualization Security Round Table Podcast[/url]

--
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
4 Replies
athlon_crazy
Virtuoso
Virtuoso
Jump to solution

Perhaps exposing your storage network to users (LAN) may endup users accidently or purposely break your storage.

VMware newbie..

Zen Systems Sdn Bhd

www.no-x.org

http://www.no-x.org
0 Kudos
fcoa
Contributor
Contributor
Jump to solution

Logins to this VM (Win2003 server) would only be accessible to admins, is there a significant risk that this path could be exploited from the LAN? If so, are there good ways to mitigate this risk (i.e. IP sec, Win Firewall)?

0 Kudos
kjb007
Immortal
Immortal
Jump to solution

The risk of exploitation is fairly minimal. The attack surface being lowered by limiting the number of machines that span those networks. You also want to make sure that network is not routed, so that network is not available from other machines not directly connected to the SAN network. The risk you open is that an admin would have access to the storage data. That is what you are trying to avoid.

-KjB

VMware vExpert

vExpert/VCP/VCAP vmwise.com / @vmwise -KjB
Texiwill
Leadership
Leadership
Jump to solution

Hello,

Moved to the Security forum.

The risk of exploitation is fairly minimal.

Not quite true. iSCSI and NFS protocols are in the clear! So it may be possible to do any number of things (ARP Cache poisoning comes to mind) to allow the storage data to flow to a compromised host. A colleague recently demoed just this. It is actually quite trivial to do with the proper tools.

The attack surface being lowered by limiting the number of machines that span those networks.

That is correct, the upper limit of this really should be 0 however for better security. Not only this, if the SAN is really an iSCSI Server, then this server could possibly be used to attack the service console depending on how the SC was also connected to the storage network. You have now increased the possible attack points for the SC by 1 or more.

You also want to make sure that network is not routed, so that network is not available from other machines not directly connected to the SAN network.

Absolutely.

The risk you open is that an admin would have access to the storage data. That is what you are trying to avoid.

If the host that can span both your LAN and SAN is compromised then it could be possible for ANY user on the system to actually get the storage data as it travels on the SAN network.

The best solution is that if you will have a VM or Server that bridges these networks that they actually bridge to an IP Storage device that is not being used by the ESX hosts, the one exception to this could be the VCB Proxy but you need to secure this as well if not better than your ESX hosts themselves. Make sure it is in a protected space, etc.


Best regards, Edward L. Haletky VMware Communities User Moderator, VMware vExpert 2009, DABCC Analyst[/url]
Now Available on Rough-Cuts: 'VMware vSphere(TM) and Virtual Infrastructure Security: Securing ESX and the Virtual Environment'[/url]
Also available 'VMWare ESX Server in the Enterprise'[/url]
[url=http://www.astroarch.com/wiki/index.php/Blog_Roll]SearchVMware Pro[/url]|Blue Gears[/url]|Top Virtualization Security Links[/url]|Virtualization Security Round Table Podcast[/url]

--
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