|
Thanks Ants posted:There's no good reason not to install the vCenter plugins that your storage vendor provides I agree. I don't get to make all the decisions yet.
|
#
?
Jan 18, 2019 21:16
|
|
|
|
| # ? Apr 23, 2024 07:33 |
|
|
I have vmware set up on my old old gaming rig where it's been fun to play around with it for the last couple of years and make mistakes where it won't get me fired from a job. What's a feasible in-home setup if I wanted to try setting it up with actual supported hardware? That includes all the caveats of a home lab: not a huge footprint, relatively quiet, won't make my power bill soar, etc.
|
|
#
?
Jan 18, 2019 21:27
|
|
|
Zapf Dingbat posted:I have vmware set up on my old old gaming rig where it's been fun to play around with it for the last couple of years and make mistakes where it won't get me fired from a job. You need Virtually Ghetto, my man. https://www.virtuallyghetto.com/
|
|
#
?
Jan 19, 2019 00:55
|
|
|
Thanks Ants posted:There's no good reason not to install the vCenter plugins that your storage vendor provides
|
|
#
?
Jan 19, 2019 18:20
|
|
|
Schadenboner posted:You need Virtually Ghetto, my man.
|
|
#
?
Jan 21, 2019 18:40
|
|
|
Virtually ghetto is cool. Just what I was looking for. I knew there was a reason I ask the forums for all my important life advice.
|
|
#
?
Jan 21, 2019 18:49
|
|
|
I have a couple VMs under vmware 6.7 that need to be deleted. The datastore for these is on a SAN along with a bunch of other VMs we want to keep but someone said we should DoD wipe them. It looks like VMware has a write zeroes function but I don't think that qualifies. Does booting the VM to a usb and wiping from there accomplish the same thing?
|
|
#
?
Jan 28, 2019 02:03
|
|
|
CampingCarl posted:I have a couple VMs under vmware 6.7 that need to be deleted. The datastore for these is on a SAN along with a bunch of other VMs we want to keep but someone said we should DoD wipe them. It looks like VMware has a write zeroes function but I don't think that qualifies. Does booting the VM to a usb and wiping from there accomplish the same thing? You want to obliterate the OS and any data on the particular VM?
|
|
#
?
Jan 28, 2019 02:36
|
|
|
CampingCarl posted:I have a couple VMs under vmware 6.7 that need to be deleted. The datastore for these is on a SAN along with a bunch of other VMs we want to keep but someone said we should DoD wipe them. It looks like VMware has a write zeroes function but I don't think that qualifies. Does booting the VM to a usb and wiping from there accomplish the same thing? Are you required for regulatory reasons to wipe them? Given that VSAN data may be re-distributed across disk groups for a number of reasons there’s no way to guarantee that you’ve actually cleared all data related to the VM from the drives without wiping the drives themselves at the bit level. If you actually require the capability to securely wipe data from VMs from the drives without destroying the drives then you’d need to look at per-VM encryption where you could then encrypt the VM and shred the keys after deletion.
|
|
#
?
Jan 28, 2019 02:39
|
|
|
YOLOsubmarine posted:Are you required for regulatory reasons to wipe them? Given that VSAN data may be re-distributed across disk groups for a number of reasons there’s no way to guarantee that you’ve actually cleared all data related to the VM from the drives without wiping the drives themselves at the bit level. Since this was a system setup before I started is that something we can migrate VMs to or has to be done at creation? That doesn't sound like something that would comply with regulatory compliance though. I think that would have to be something like separate sets of disk for each set of VMs.
|
|
#
?
Jan 28, 2019 03:23
|
|
|
CampingCarl posted:I have a couple VMs under vmware 6.7 that need to be deleted. The datastore for these is on a SAN along with a bunch of other VMs we want to keep but someone said we should DoD wipe them. It looks like VMware has a write zeroes function but I don't think that qualifies. Does booting the VM to a usb and wiping from there accomplish the same thing?
|
|
#
?
Jan 28, 2019 05:48
|
|
|
CampingCarl posted:I have a couple VMs under vmware 6.7 that need to be deleted. The datastore for these is on a SAN along with a bunch of other VMs we want to keep but someone said we should DoD wipe them. It looks like VMware has a write zeroes function but I don't think that qualifies. Does booting the VM to a usb and wiping from there accomplish the same thing?
|
|
#
?
Jan 28, 2019 15:32
|
|
|
If you need to truly sanitize LOCAL hba storage, boot each esxi host with a live wiper image and wipe the vmfs/vsan extent media.
Potato Salad fucked around with this message at 17:03 on Jan 28, 2019 |
|
#
?
Jan 28, 2019 16:51
|
|
|
Note that deleting the logical objects associated with what you want destroyed, popping each node of a vsan cluster out one at a time, running ATA Secure Erase commands on each drive with a drive dock, and reconnecting the node with the assurance that (1) the datacenter is adequately physically secured (2) you will certify media destruction upon disposal or inter-org transfer ... ...may satisfy a wide gamut of moderate-grade federal and defense data governance standards, if that's what the co-worker has in mind. It may also take less time than doing a 22-M wipe on all the media and, depending on the manufacturer, may work on ssds. Of course, said coworker may just be "hurr do a DoD wipe," which technically isn't actually a thing sanctioned by the DoD for use on non-DoD systems and is more correctly referred to as a three-pass wipe, AND really only works on magnetic media. Potato Salad fucked around with this message at 17:06 on Jan 28, 2019 |
|
#
?
Jan 28, 2019 16:59
|
|
|
Read nist sp 800-88, even if the gobermint isn't a client of yours
|
|
#
?
Jan 28, 2019 17:00
|
|
|
evil_bunnY posted:What’s the underlying storage. Trying to wipe a CoW-backed volume is only gonna end in tears I know getting iso27001 is a stated goal too so even if this is fine I may have to change the current system anyway.
|
|
#
?
Jan 28, 2019 19:48
|
|
|
CampingCarl posted:Dell scv3000, don't see anything about cow in the manual but it is a concern and I would rather just assume it does. You’d have to wipe every drive in the array. Neither the storage not the hypervisor have a complete picture of which blocks may have belonged to a particular VM at some point and have not yet been overwritten so there’s no facility for wiping only those blocks. The correct question to ask is what are you trying to protect against? This currently sounds like a solution in search of a problem. Identify the actual problem and then work out a technically feasible solution.
|
|
#
?
Jan 29, 2019 00:37
|
|
|
If this is something you need to do more of in the future then would VM encryption provide some assurances that the data inside the VM was gone when it was deleted?
|
|
#
?
Jan 29, 2019 00:40
|
|
|
YOLOsubmarine posted:You’d have to wipe every drive in the array. Neither the storage not the hypervisor have a complete picture of which blocks may have belonged to a particular VM at some point and have not yet been overwritten so there’s no facility for wiping only those blocks. Long term problem: I know we have upcoming projects(some govt) that will require us to certify media is sanitized, overwrite three times before reuse or degauss/destroy, which as pointed out is hard to do when that could apply to every disk on the SAN. I think my worry is most of these refer to 'sanitizing before reuse' of the drive and I am not sure if that means at the end of the project or just when the drive leaves IT's possession. VM encryption seems like a practical solution we should use but I am unsure if that qualifies for sanitizing in these policies that say overwrite three times etc. I could just be overthinking this but also don't want our process to end up being 'we swear we will destroy the disk later' for compliance.
|
|
#
?
Jan 29, 2019 02:59
|
|
|
CampingCarl posted:Short term problem: wipe out the data as much as we can without impacting other projects with data on the SAN, from above I'm told this realistically means delete the VM and wipe/destroy the drives when they are no longer in use. You’re overthinking it. Re-use means before the physical drives leave your possession, such as when you retire the array or when a drive is replaced and the old drive must be returned or disposed of. There are no explicit government standards for media sanitization so what is acceptable or not comes down to the determination of the government security officer in charge of making sure you’re compliant. The three wipe pass was never a standard and hasn’t been recommended for quite a while, but you still see people saying it’s required. NIST guidelines recommend a single pass as sufficient for magnetic media. Overwriting passes may not be effective at all on other types of media, such as flash, that have a controller interposed that virtualizes the SCSI interface. If the goal here is merely to meet regulatory requirements for protecting sensitive government data then you need to identify the government responsible for determining if you are meeting your obligations and ask them how to handle various scenarios. If the goal is to actually secure the data against drive level tampering then implement encryption at rest for all covered data, use industry best practices around key rotation, management, and security, and physically destroy drives when they are retired.
|
|
#
?
Jan 29, 2019 06:32
|
|
|
CampingCarl posted:I could just be overthinking this but also don't want our process to end up being 'we swear we will destroy the disk later' for compliance. Go. Read. 800-88. If this is the USA. There is a flowchart for low, moderate, and high risk data, what action you are dealing with the media, and whether you need to clear, wipe, or destroy media in each case, plus required verification for each case (like drive destruction certification). Guaranteeing destruction of media isn't just a "we promise" sort of thing, you need to specify how you do it as applied to an environment for 27001, 800-171, 800-53r4 Moderate, etc and there's actually some structure to it. As a concrere example, for most categories of non-specified CUI under 800-171 (thus moderate), it is adequate to clear a drive before intradepartmental reuse. Should the drive later need to be thrown away, you'd look at the same flowchart and determine that destruction is necessary (I think). You need to read up on this instead of following your feelings. Potato Salad fucked around with this message at 16:39 on Jan 31, 2019 |
|
#
?
Jan 31, 2019 16:28
|
|
|
"I'll just destroy drives always" doesn't fly, either, in a world with BGA SSDs in expensive laptops. Your policy needs nuance.
|
|
#
?
Jan 31, 2019 16:40
|
|
|
Potato Salad posted:"I'll just destroy drives always" doesn't fly, either, in a world with BGA SSDs in expensive laptops. Your policy needs nuance. If your policy requires destruction of the drives or is easiest to implement through destruction, you could just not buy ultra-thin laptops. Unless your use case also requires Macs you have plenty of options that will continue to use standard 2.5" and M.2 format drives, and you'll get better machines anyways.
|
|
#
?
Jan 31, 2019 19:31
|
|
|
wolrah posted:If your policy requires destruction of the drives or is easiest to implement through destruction, you could just not buy ultra-thin laptops. Unless your use case also requires Macs you have plenty of options that will continue to use standard 2.5" and M.2 format drives, and you'll get better machines anyways. Blasphemy, buying hardware to accommodate security needs is heresy. High level flow FYI. Fairly common sense, buy policy needs to actually flesh out how you interpret and implement this flow.
|
|
#
?
Jan 31, 2019 19:45
|
|
|
My company is even paranoid about theoretical memory retrieval which likely couldn't even be a thing outside of lab conditions. So the machines go into the shredder, whole thing. Add a new contractor and they don't work out after two weeks? Hardware is trashed. At least, this is the impression I have from discussions with the team involved.
|
|
#
?
Jan 31, 2019 20:00
|
|
|
bull3964 posted:My company is even paranoid about theoretical memory retrieval which likely couldn't even be a thing outside of lab conditions. drat what type of super secret poo poo are you all working on?!
|
|
#
?
Jan 31, 2019 21:12
|
|
|
TheFace posted:drat what type of super secret poo poo are you all working on?! He could tell you, but then he would have to kill you. 
|
|
#
?
Jan 31, 2019 21:15
|
|
|
bull3964 posted:At least, this is the impression I have from discussions with the team involved.
|
|
#
?
Jan 31, 2019 22:15
|
|
|
For the paranoid, you can 22-m RAM 
|
|
#
?
Jan 31, 2019 22:53
|
|
|
Vulture Culture posted:the team involved is stealing every computer Thank them for helping keep ebay prices low.
|
|
#
?
Jan 31, 2019 22:55
|
|
|
can I have your totally-legal $3.89 win7 enterprise mak keys?
|
|
#
?
Jan 31, 2019 23:21
|
|
|
Potato Salad posted:Blasphemy, buying hardware to accommodate security needs is heresy. That said there are a lot of other good reasons one might choose laptop hardware in particular based on security policy needs. TPMs, built in fingerprint readers, smartcard readers, facial recognition cameras, lack of cameras, USB ports for required dongles, USB port manageability, vPro/AMD equiv presence/lack, etc. All things that will validly limit your hardware choice a lot more than just avoiding a few machines that only exist for their looks. quote:High level flow FYI. Fairly common sense, buy policy needs to actually flesh out how you interpret and implement this flow.
|
|
#
?
Jan 31, 2019 23:39
|
|
|
TheFace posted:drat what type of super secret poo poo are you all working on?! Just the potential for PHI. I think the bigger issue is they pretty much gutted the desktop team down to a skeleton crew and outsourced imaging to a 3rd party that drop ships computers for new hires. So, they don't really have the manpower to remove drives and properly track and dispose of the pieces. So, it's easier and cheaper to err on the side of caution. bull3964 fucked around with this message at 04:03 on Feb 1, 2019 |
|
#
?
Feb 1, 2019 03:56
|
|
|
Can anyone recommend a good book on PowerCLI for someone who's done fair bit of UNIX scripting, but is fairly new to VMWare?
|
|
#
?
Feb 3, 2019 08:31
|
|
|
Powercli is strictly a Powershell module, so you'll need to both install PS on Linux (easy) and learn a little Powershell (honestly, also pretty easy). There's a YouTube series called Learn Powershell In A Month of Lunches or something like that. It's fantastic, it's hands on, go dip your feet in. The cool thing about powercli is that most everything you want to do has been tried before at least in parts, so it isn't hard to get an idea of which objects and methods you'll need to use with a few cursory searches before a project. I'm autodeploying tenants, auditing configuration, consuming events/syslogs and alarming on bullshit in siem, etc all with or assisted by powercli and I've not cracked open a book. Just toss yourself at it one specific project at a time. Fun learning experience: next time you need to reboot a server or hand deploy something, don't use vcenter. Potato Salad fucked around with this message at 17:55 on Feb 3, 2019 |
|
#
?
Feb 3, 2019 17:50
|
|
|
Zorak of Michigan posted:Can anyone recommend a good book on PowerCLI for someone who's done fair bit of UNIX scripting, but is fairly new to VMWare? You can also script with python https://github.com/vmware/pyvmomi but you can tell its not as polished as powercli.
|
|
#
?
Feb 4, 2019 16:56
|
|
|
Has anyone else noticed just how bad VMware support has gone to poo poo? We’ve been going on a week and a half of “escalations” for a ticket, and we’re having to beat up on the ticket holder and his manager just to even get a response/update.
|
|
#
?
Feb 6, 2019 13:25
|
|
|
Ah come on, cone on, if you were dissatisfied you should have just notified the manager, come on!
|
|
#
?
Feb 6, 2019 14:19
|
|
|
I have had more success with Microsoft support lately, in that they Potato Salad fucked around with this message at 12:09 on Feb 7, 2019 |
|
#
?
Feb 6, 2019 14:21
|
|
|
|
| # ? Apr 23, 2024 07:33 |
|
|
devmd01 posted:Has anyone else noticed just how bad VMware support has gone to poo poo? We’ve been going on a week and a half of “escalations” for a ticket, and we’re having to beat up on the ticket holder and his manager just to even get a response/update. Well, what do you expect when the company has gutted global support services? Michael Dell needs more money, and he isn't going to get it by paying for support engineers.
|
|
#
?
Feb 6, 2019 17:06
|
|
