Virtualization Adapted Adapting Business Processes for Virtual Infrastrcuture (and vice-versa)

2012/03/20

arp mac esxi vmkernel storage

Filed under: it,security,virtualization — iben @ 19:44

troubleshooting arp mac esxi vmkernel storage

The guys were getting some new storage setup and had the IP address set incorrectly. Usually a vmkping would be enough to prove the vmkernel interfaces were setup correctly but the vendor came back with “the firewall is blocking NFS” so I needed a way to see the ARP table to prove the MAC for the NAS was showing up on the correct VMK interface with no gateway in the data path.

This was tested to work on latest ESXi version 5 build 469512.

Here are the results:

~ # vmkping 10.2.150.104
PING 10.42.150.104 (10.2.150.104): 56 data bytes
64 bytes from 10.2.150.104: icmp_seq=0 ttl=64 time=0.201 ms
64 bytes from 10.2.150.104: icmp_seq=1 ttl=64 time=0.187 ms

— 10.42.150.104 ping statistics —
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.187/0.194/0.201 ms
~ # esxcfg-vmknic -l
Interface Port Group/DVPort IP Family IP Address Netmask Broadcast MAC Address MTU TSO MSS Enabled Type
vmk0 Management Network IPv4 1.2.5.158 255.255.255.248 1.2.5.159 00:25:90:52:91:21 1500 65535 true STATIC
vmk1 VMkernel-152 IPv4 10.2.152.158 255.255.255.0 10.2.152.255 00:50:56:76:23:45 1500 65535 true STATIC
vmk2 VMkernel-150 IPv4 10.2.150.158 255.255.255.0 10.2.150.255 00:50:56:70:34:56 1500 65535 true STATIC
~ # esxcli network ip neighbor list
Neighbor Mac Address Vmknic Expiry State
————– —————– —— ————– —–
10.2.150.104 00:50:56:2a:12:34 vmk2 993 sec

Reference:

Displaying the ARP and Neighbor Discovery cache for VMkernel network interfaces

2011/08/11

Virtualization Security Round Table Podcast

Filed under: cloud,it,security,virtualization — iben @ 12:08

Virtualization Security Podcast | The Virtualization Practice.

Virtualization Security Podcast

The Virtualization Security Round Table Podcast provides an open forum to discuss all things related to Virtualization, Virtual Environment, and Cloud Computing Security. The podcast is hosted by Talkshoe, with the after podcast write-ups and notes are hosted here. The podcast can also be found on iTunes. https://itunes.apple.com/us/podcast/virtualization-security-roundtable/id302845147

Use Talkshoe to join us in our discussions every other week on Thursday at 2:30 PM EST.Call in with this info:

  • Phone Number:
    (724) 444-7444
  • Call ID:
    34217

To receive email notifications when new episodes are scheduled use Talkshoe’s Follow This feature. However to use this feature you most likely need a Talkshoe account.

You can also subscribe to the Podcast RSS Feed.

This podcast addresses many Virtualization Security items and is always looking for more ideas. Please contact one of the panelists or contact myself via Twitter, the VMware Communities Forum, or by submitting a comment below.

Expand to View all Virtualization Security Podcast Episodes

Our past guest panelists have included people from Altor Networks, Catbird Security, Cisco, Citrix, EMC, HyTrust, NetApp, PCI DSS, Reflex Systems, RSA, TrendMicro, VMware as well as other industry virtualization security groups, consultants, and auditors.

The static panelists of the podcast are:

Our podcasts are equalized by Tim Pierson of DataSentry Inc, who is a contributing author to VMware vSphere and Virtual Infrastructure Security: Securing the Virtual Environment and virtualization security trainer.

Recent Posts

 

ESX vSwitch L2 Security

Filed under: it,security,virtualization — Tags: , , , , , , — iben @ 11:58

VMware vSphere ESX Host Virtual Switch Layer 2 Security Features

The virtual switch has the ability to enforce security policies to prevent virtual machines from impersonating other nodes on the network. There are three components to this feature. These should all be set to “REJECT” to enable the security feature.

•Promiscuous mode is disabled by default for all virtual machines. This prevents them from seeing unicast traffic to other nodes on the network.

•MAC address change lockdown prevents virtual machines from changing their own unicast addresses. This also prevents them from seeing unicast traffic to other nodes on the network, blocking a potential security vulnerability that is similar to but narrower than promiscuous mode.

•Forged transmit blocking, when you enable it, prevents virtual machines from sending traffic that appears to come from nodes on the network other than themselves.

Cisco Nexus 1000v Switch Layer 2 Security

MAC ACLs

MAC ACLs are ACLs that filter traffic using information in the Layer 2 header of each packet.

http://www.cisco.com/en/US/docs/switches/datacenter/nexus1000/sw/4_0/security/configuration/guide/security_9mac_acls.html

Port Security

Port security lets you configure Layer 2 interfaces permitting inbound traffic from a restricted set of MAC addresses called secure MAC addresses. In addition, traffic from these MAC addresses is not allowed on another interface within the same VLAN. The number of MAC addresses that can be secured is configurable per interface.

http://www.cisco.com/en/US/docs/switches/datacenter/nexus1000/sw/4_0/security/configuration/guide/security_10port.html#wp1210839

DHCP Snooping

DHCP snooping acts like a firewall between untrusted hosts and trusted DHCP servers by doing the following:

•Validates DHCP messages received from untrusted sources and filters out invalid response messages from DHCP servers.

•Builds and maintains the DHCP snooping binding database, which contains information about untrusted hosts with leased IP addresses.

•Uses the DHCP snooping binding database to validate subsequent requests from untrusted hosts.

Dynamic ARP inspection (DAI) and IP Source Guard also use information stored in the DHCP snooping binding database.

http://www.cisco.com/en/US/docs/switches/datacenter/nexus1000/sw/4_0_4_s_v_1_2/security/configuration/guide/n1000v_security_12dhcpsnoop.html#wp1272686

Dynamic Address Resolution Protocol (ARP) Inspection (DAI)

DAI is used to validate ARP requests and responses as follows:

•Intercepts all ARP requests and responses on untrusted ports.

•Verifies that a packet has a valid IP-to-MAC address binding before updating the ARP cache or forwarding the packet.

•Drops invalid ARP packets.

DAI can determine the validity of an ARP packet based on valid IP-to-MAC address bindings stored in a Dynamic Host Configuration Protocol (DHCP) snooping binding database. This database is built by DHCP snooping when it is enabled on the VLANs and on the device. It may also contain static entries that you have created.

If an ARP packet is received on a trusted interface, the device forwards the packet without any checks. On untrusted interfaces, the device forwards the packet only if it is valid.

http://www.cisco.com/en/US/docs/switches/datacenter/nexus1000/sw/4_0_4_s_v_1_2/security/configuration/guide/n1000v_security_13arpinspect.html#wp1329252

IP Source Guard

IP Source Guard is a per-interface traffic filter that permits IP traffic only when the IP address and MAC address of each packet matches the IP and MAC address bindings of dynamic or static IP source entries in the Dynamic Host Configuration Protocol (DHCP) snooping binding table.

You can enable IP Source Guard on Layer 2 interfaces that are not trusted by DHCP snooping. IP Source Guard supports interfaces that are configured to operate in access mode and trunk mode. When you initially enable IP Source Guard, all inbound IP traffic on the interface is blocked except for the following:

•DHCP packets, which DHCP snooping inspects and then forwards or drops, depending upon the results of inspecting the packet.

•IP traffic from static IP source entries that you have configured in the Cisco Nexus 1000V.

The device permits the IP traffic when DHCP snooping adds a binding table entry for the IP address and MAC address of an IP packet or when you have configured a static IP source entry.

The device drops IP packets when the IP address and MAC address of the packet do not have a binding table entry or a static IP source entry.

http://www.cisco.com/en/US/docs/switches/datacenter/nexus1000/sw/4_0_4_s_v_1_2/security/configuration/guide/n1000v_security_14sourceguard.html#wp1096775

Reference Links

http://www.vmware.com/files/pdf/dmz-vsphere-nexus-wp.pdf

http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/vmware/VMware.html#wp696333

Labels:


2011/05/28

Fake path ie8 Dell drac

Filed under: it,security — Tags: , , , , , , , — iben @ 12:11

If you want to use Dell DRAC 5 with IE 8 you need to change this setting or the Virtual Media won’t work.

Microsoft made this change to conform with HTML5.

http://acidmartin.wordpress.com/2009/06/09/the-mystery-of-cfakepath-unveiled/

http://codingforums.com/showthread.php?p=817890

http://blogs.msdn.com/ie/archive/2009/03/20/rtm-platform-changes.aspx

http://forum.maxthon.com/redirect.php?tid=75307&goto=lastpost

http://www.marc-antho-etc.net/blog/post/Two-IE8-behavioral-changes-worth-mentioninge280a6.aspx

So in order to prevent information disclosure (the path to a file may include the user name if the file reside under the user ‘profile), there are actually two changes combined to achieve that:

  • The IE security setting “include local directory path when uploading files to a server” (already present in IE7) is set to “Disable” instead of “Enabled” as it was with IE7 for the “Internet Zone”

2009/05/20

Spelling – VMware or VMWare or VMWARE or vmware

Filed under: cloud,Education,it,security,virtualization — Tags: , , , , , , — iben @ 11:20

[NMAP has been corrected! see email replies from Fydor and IEEE at end]

Here are a couple emails I sent off today requesting (suggesting) that the OUI information be corrected for VMware’s MAC addresses.  I first noticed the issue when my friend ran the latest NMAP on his MacBook against our internal work net. So I was all set to submit a bug to the NMAP developers when I realized they just get their information on this from the I triple E standards body and they just get their info from whomever happened to be on duty that day and made the request.

It’s the OCD part of me that can’t stand to see VMware spelled wrong (VMWare).

I’m sure other companies like McAfee and McDonald’s have entire teams dedicated to protecting this sort of brand identity.

All lower case would have been fine (vmware) like Unix style.

So would have all UPPERCASE  (VMWARE) as it adds emphasis or might be a convention for a proper noun in certain types of databases or programming languages.

But if you are going to make the effort to use the shift key for just part of the word the least you could do is learn which letters are supposed to be upper case and which ones are not.

To: ieee-registration-authority@ieee.org

Subject: typo in spelling of company name…

Dear Registration Team,

I noticed a minor typo in the list here: https://standards-oui.ieee.org/oui/oui.txt

The word “VMware” is spelled wrong when reporting the company for an OUI. The “w” should be lower case – not upper case.

Also, the company has moved and is no longer located on Porter Drive but around the corner now on Hillview Ave.

Please see the corporate web site for the accurate information and correct the list output.

http://www.vmware.com/company/contact.html

VMware, Inc.
3401 Hillview Ave
Palo Alto, CA 94304 USA

For example: Here is the current output…

00-05-69   (hex)        VMWARE, Inc.
000569     (base 16)        VMWARE, Inc.
3145 Porter Dr., Bldg. F
Palo Alto CA 94304
UNITED STATES

00-0C-29   (hex)        VMware, Inc.
000C29     (base 16)        VMware, Inc.
3145 Porter Dr.
Palo Alto CA 94304
UNITED STATES

00-1C-14   (hex)        VMware, Inc
001C14     (base 16)        VMware, Inc
3145 Porter Drive
Palo Alto CA 94304
UNITED STATES

00-50-56   (hex)        VMWare, Inc.
005056     (base 16)        VMWare, Inc.
44 ENCINA AVENUE
PALO ALTO CA 94301
UNITED STATES

Reference Info:

http://communities.vmware.com/thread/108426

To: nmap-dev@insecure.org

Subject: spelling of company name “VMware” for a given mac address

Dear NMAP Developer Team,

I noticed a minor typo in the OS Detection Output.

The word “VMware” is spelled wrong when reporting the company for an OUI. The “w” should be lower case – not upper case.

For example: Here is the current output…

MAC Address: 00:50:56:01:11:00 (VMWare)

And this is the corrected version…

MAC Address: 00:50:56:01:11:00 (VMware)

Reference Info:

http://communities.vmware.com/thread/108426

http://standards.ieee.org/regauth/oui/oui.txt

00-05-69   (hex)                VMWARE, Inc.
000569     (base 16)            VMWARE, Inc.
3145 Porter Dr., Bldg. F
Palo Alto CA 94304
UNITED STATES

00-0C-29   (hex)                VMware, Inc.
000C29     (base 16)            VMware, Inc.
3145 Porter Dr.
Palo Alto CA 94304
UNITED STATES

00-1C-14   (hex)                VMware, Inc
001C14     (base 16)            VMware, Inc
3145 Porter Drive
Palo Alto CA 94304
UNITED STATES

00-50-56   (hex)                VMWare, Inc.
005056     (base 16)            VMWare, Inc.
44 ENCINA AVENUE
PALO ALTO CA 94301
UNITED STATES

On May 20, 2009, at 5:52 PM, Fyodor wrote:

Hi Iben.  Unfortunately, that is wrong in the official document at
http://standards.ieee.org/regauth/oui/oui.txt.  VMware should really
contact the IEEE and canonicalize their name and addresses in that
file.  As you show in your email, it is even all caps in one case.

So while there is little I can do about the varying VMware
capitalization until they fix it upstream, I took the opportunity to
update the data to correspond with the latest version of
http://standards.ieee.org/regauth/oui/oui.txt.  Looking at the changes
in r13359, it is clear that companies often get minor capitalization
changes put through, so VMware just needs to do that as well.
Instructions are at http://standards.ieee.org/regauth/oui/index.shtml.

Cheers,
-F

From: ieee-registration-authority@ieee.org

Sent: Thursday, May 21, 2009 11:24 AM
To: Iben Rodriguez
Subject: Re: typo in spelling of company name…

Mr. Rodriguez,

The changes have been completed and will reflect on our website within 24 hours.
Please let me know if you have additional questions.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
IEEE Registration Authority
IEEE Standards Department
445 Hoes Lane
Piscataway, NJ 08854 USA
Phone:  +1 732-465-6481
Fax:  +1 732-562-1571
E-mail:  ieee-registration-authority@ieee.org
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://standards.ieee.org/regauth/index.html

IEEE.  Fostering technological innovation and excellence for the benefit of humanity.

Celebrating 125 Years of Engineering the Future.  www.ieee125.org

—end of email–

Success!

5/25/2009 shows corrected updates.  Still waiting to find out if NMAP will dynamically reflect these changes or if a code rev is needed.

Here are the results of your search through the public section of the IEEE Standards OUI database report for vmware:

00-05-69   (hex)		VMware, Inc.
000569     (base 16)		VMware, Inc.
				3401 Hillview Avenue
				Palo Alto CA 94304
				UNITED STATES
00-0C-29   (hex)		VMware, Inc.
000C29     (base 16)		VMware, Inc.
				3401 Hillview Avenue
				Palo Alto CA 94304
				UNITED STATES
00-1C-14   (hex)		VMware, Inc
001C14     (base 16)		VMware, Inc
				3401 Hillview Avenue
				Palo Alto CA 94304
				UNITED STATES
00-50-56   (hex)		VMware, Inc.
005056     (base 16)		VMware, Inc.
				3401 Hillview Avenue
				PALO ALTO CA 94304
				UNITED STATES

Now – need to fix NMAP

Nmap 4.85BETA9

MAC Address: 00:0C:29:11:00:11 (VMware) <– virtual machine guest – correct

MAC Address: 00:50:56:00:11:00 (VMWare) <– ESX host – wrong

As you can see a scan with the latest version of NMAP still shows the wrong spelling.  Now that the OUI is corrected on the public IEEE web site we’ll need to wait for NMAP to get updated.

I’ve emailed Fydor and hopefully he can fix it next week…?

I b e n

Nmap Changelog – fixed

# Nmap Changelog ($Id: CHANGELOG 13432 2009-05-28 

o Updated nmap-mac-prefixes with the latest MAC address prefix data
  from http://standards.ieee.org/regauth/oui/oui.txt as of
  5/20/09. [Fyodor]
Reference: http://nmap.org/changelog.html

Powered by WordPress