sylver_dragon

If you’re relying on someone else’s computer to keep your data safe, don’t be surprised when they use that data as a hostage to demand more money. Sure, using other peoples’ computers to host your infrastructure can make a lot of sense. Just be sure you have a backup plan for when they send Guido around to demand more money.

I have it on good authority that you currently have a project idea which you can use to pick one (or more) of those paths and start learning. ;-)

For example user management in studio3T

Not sure how I missed this on my first read of your post. But, this looks like a fancy front end to making MongoDB calls. That makes life easier, MongoDB has a well documented API and a driver for C#. As an aside, if you want to get really good at PowerShell, getting a basic working knowledge of C# and .Net in general is really helpful. For the lazy (and I always like lazy), there’s even a pre-built MongoDB module on the PowerShell Galley called Mdbc. There is also the Project’s GitHub Page which has a lot of useful info.

Granted, this path likely means learning enough about MongoDB to create/delete/modify users. But you came here expecting a load of homework, right? Also, this is a good excuse to spin up a docker container running MongoDB and go hog wild breaking the fuck out of it (just call it “research” if management asks). And who doesn’t love breaking stuff?

I’d also note that you may be able to get some help along the way by capturing the network traffic to the server caused by the Studio3T GUI. WireShark can capture the traffic to/from the DB server and you can read that to reverse engineer some of the calls you care about. Just, make sure you talk to your security folks before you download/install WireShark. If they are worth their salt, they’ll understand an engineer installing/running wireshark, it just makes their day easier if they know the alert is coming first. Assuming the GUI isn’t complete shit, it may encrypt traffic. This can be dealt with by using the SSLKEYLOGFILE environmental variable. In most cases, this results in the TLS keys being saved to a file and that can be imported into WireShark.

Good luck, and have fun!

There are a few options:

1. Use AutoIT or some similar automation framework. Generally, this is pretty easy and gets the job done. Your security folks may hate you (AutoIT binary hashes are basically all assumed to be malware IoCs at this point),
2. Depending on how the GUI works, you may be able to reverse engineer the calls made by the application and just make those calls yourself. For a Web UI, you can use something like BurpeSuite or even just the FireFox developer tools to catch the web calls and then modify/replay those as desired. For a console application, it could be trickier, as you may need to either load the software’s libraries (DLLs) or figure out database calls. It all depends on how the user data is stored and updated.
3. Using P/Invoke you can load several functions from the Win32 API, specifically FindWindowEx and EnumChildWindows to locate the GUI application and any specific form items you want to manipulate (e.g. TextBoxes to fill, Buttons to click). You can then modify properties or send clicks. You’ll probably hate yourself at the end of this project, but you’ll learn a lot.

Personally, I prefer that it’s all in one place. It’s hard enough to get teams to update any sort of asset inventory in one place. Getting them to update it in two, and keep everything in sync, sounds like a disaster begging to happen. And, as a heavy consumer of my organization’s CMDB (I work in cybersecurity), I much prefer having only one place to look.

The most successful CMDB I’ve ever seen was a single, unified asset tracking system which included all relevant asset details, asset owner, technical PoC and compliance documentation. The reason it was so successful was that NAC was tied to the CMDB. If a system wasn’t in the CMDB, it got dumped in a very locked down VLAN which was really only useful for new system setup. Once a system was configured, the appropriate paperwork submitted, and the system added to the CMDB, it would then be automagically moved to the appropriate VLAN for it’s location/function. When a system owner or technical PoC left the organization, one of the required workflows was reassigning all assets in the CMDB. This all worked surprisingly, especially considering that the CMDB was a bespoke Classic ASP website written in VB6, with some newer pages being VB.Net in C#.

It’s Oracle, so I’d expect them to sue anyone who complains for infringing on Oracle’s copyright on communicating about how much Oracle sucks.

Maybe we should consider, not letting everyone setup whatever the fuck they want, whenever the they want, however they want and assuming it’s all good because, “it’s in the cloud”. And then that setup gets either dumped in IT’s lap in it’s half-assed state (if you’re lucky) or is left running, long forgotten, until an attacker finds it and informs the organization about it’s continued existence by spinning up a coin miner.

“The cloud” does need a lot of work on configuration management. But, that doesn’t mean just another fancy tool to fix the fuckups. It means policies and procedures to make the broken configs harder to implement in the first place. But that doesn’t have AI and flashy dashboards to wow the execs into spending more money. It just has users whining about waiting for an understaffed IT organization not getting things done “right now” for a project that has a deadline i tomorrow, which has been known about for three months.

It depends on the type of backup:

For a filesystem backup, restore one or more files to a secondary location. E.g. pick a few files out of the backup and try to restore them to a temporary folder. Then hash the original and restored files to verify integrity.
For a full machine backup (e.g. VM backup), restore a copy of the machine to a test location. Spin up the test machine to verify that it can boot.
For a database backup, restore a copy of the database to a test location (e.g. change the database name as part of the restore process), compare a few tables against the real database to verify integrity.

Pretty much, it’s going to be some version of “Restore X to a test location and verify integrity”. You want to both prove that the backup can be restored and that the restored copy is actually intact.

Gaming under Linux is getting better and better. With all the work Valve has put into Proton, the list of games which don’t run has been shrinking.

I’ve been using Proxmox professionally for years now, and not once did i have s problem i could not fix myself.

And how many of the environments you have left behind became an unmanageable mess when the company couldn’t hire someone with your skillset? One of the downsides to this sort of DIY infrastructure is that it creates a major dependency on a specific skillset. That isn’t always bad, but it does create a risk which business continuity planning must take into account. This is why things like OpenShift or even VMWare tend to exist (and be expensive). If your wunderkind admin leaves for greener pastures, your infrastructure isn’t at risk if you cannot hire another one. The major, paid for, options tend to have support you can reach out to and you are more likely to find admins who can maintain them. It sucks, because it means that the big products stay big, because they are big. But, the reality of a business is that continuity in the face of staff turnover is worth the licensing costs.

This line, from the OP’s post, is kind of telling as to why many businesses choose not to run Proxmox in production:

It is just KVM libvirt/qemu and corosync along with some other stuff like ZFS.

Sure, none of those technologies are magic; but, when one of them decides to fuck off for the day, if your admin isn’t really knowledgeable about all of them and how they interact, the business is looking at serious downtime. Hell, my current employer is facing this right now with a Graylog infrastructure. Someone set it up, and it worked quite well, a lot of years ago. That person left the company and no one else had the knowledge, skills or time to maintain it. Now that my team (Security) is actually asking questions about the logs its supposed to provide, we realize that the neglect is causing problems and no one knows what to do with it. Our solution? Ya, we’re moving all of that logging into Splunk. And boy howdy is that going to cost a lot. But, it means that we actually have the logs we need, when we need them (Security tends to be pissy about that sort of thing). And we’re not reliant on always having someone with Graylog knowledge. Sure, we always need someone with Splunk knowledge. But, that’s a much easier ask. Splunk admins are much more common and probably cheaper. We’re also a large enough customer that we have a dedicated rep from Splunk whom we can email with a “halp, it fell over and we can’t get it up” and have Splunk engineers on the line in short order. That alone is worth the cost.

It’s not that I don’t think that Proxmox or Open Source Software (OSS) has a place in an enterprise environment. One of my current projects is all about Linux on the desktop (IT is so not getting the test laptop back. It’s mine now, this is what I’m going to use for work.). But, using OSS often carries special risks which the business needs to take into account. And when faced with those risks, the RoI may just not be there for using OSS. Because, when the numbers get run, having software which can be maintained by those Windows admins who are “used to click their way though things” might just be cheaper in the long run.

So ya, I agree with the OP. Proxmox is a cool option. And for some businesses, it will make financial sense to take on the risks of running a special snowflake infrastructure for VMs. But, for a lot of businesses, the risks of being very reliant on that one person who “not once [had a] problem i could not fix myself”, just isn’t going to be worth taking.

This seems suspiciously similar to the Parable of the broken window. Sure, overall security has increased, but it has costs. That said, since we will invariably have criminals, it has been a good thing that companies and individuals have gotten more aware of the risks and are taking actions to protect themselves.

As much “doom and gloom” as the article pushes, I kinda feel that the compromised keys being well known makes detection easier. The malicious binary needs to be signed with one of these keys, this means that there will be very specific structures (e.g. the public key) at well known locations in the file. This is exactly the type of threat which anti-virus is good at detecting. Assuming a network’s security folks aren’t completely asleep at the switch, these attacks should get picked up and blocked pretty fast.

There is a reason attackers spend so much time and effort obfuscating code and keeping files off the disk. While A/V may be a pretty terrible security control and easily bypassed in many cases, watching for files with well known patterns is one of the few things A/V tends to do well.

Somebody forgot about No Changes Friday.

While it’s true that “It depends on your business needs”, most often I’ve seen backup schemes which work on a minimum of a daily backup of most data. For example, on a larger, busier system, it might have a full backup done over the weekend when the system isn’t as busy and therefore has a lower business impact. Then daily differential backups are done each night. For smaller systems, it might just be a full backup of critical data every night.

For highly active, critical SQL databases, I’ve also seen this extended where the a full backup was done of the database weekly, with differential backups done nightly and transaction log backups done every 15 minutes. This obviously had full transactional logging turned on for the critical databases.

As a concrete example, on my home “server” (desktop with delusions of grandeur), the main data partition is running on ZFS with snapshots taken every 15 minutes, hourly, daily, weekly and monthly. The 15 min. snapshots are kept for an hour. Hourly snapshots are kept for 24 hours. Daily snapshots are kept for 31 days. Weekly snapshots are kept for 8 weeks. Monthly snapshots are kept for 12 months. There’s a bit of overlap in the daily and weekly schedules, as those are most likely to cover my arse from an “oops” factor.

The downside of the snapshot setup is that it doesn’t provide disaster recovery. And, I’ll admit, for my home stuff I haven’t gotten around to sorting this out. Ideally, I should be taking a weekly backup, compressing and encrypting it and pushing it to a cloud service somewhere. Laziness has meant that hasn’t been done yet.

While this seems like something that absolutely should not have happened, it’s also a good reminder that “it’s in the cloud” does not mitigate the need for a good backup strategy. Maybe not the same level of on-site tape library backup solution many of us used to have; but, dumping the data onto a cold storage location on a different cloud on a regular basis would be a reasonable precaution.

It comes down to the risk appetite of the business. You mention a “secure” network, but you already have internet access. So, it seems that some access to resources on the internet is already an accepted risk. Beyond the possibility that a random attacker might leverage the gstatic CDN to attack your network, do you have any other specific threats which make you hesitant to whitelist it? Are those threats large enough that the business would consider them to great a risk to that network? Do you have other mitigating controls in place? Would something like traffic inspection or endpoint protection be a sufficient mitigating control? Can the systems with the offending app be firewalled off from the rest of the network? Could the specific assets needed by cached internally and requests for gstatic redirected? What other compensating controls can be put in place to mitigate the risk?

All that said, have you brought the issued to your management and gotten their input on the risk? In the end, it’s a business decision and should be decided on by the business leaders. If they want to take the risk of allowing that network to access gstatic, that’s on them.

But how will you manage your internal LAN from “the cloud” if your configuration isn’t created, stored and managed from “the cloud”? Surely, you aren’t some heathen who would rather not create the extra attack surface of having all that exposed to the internet? No, this is The Way. Cloudify ALL THE THINGS! No local configs. Trust “the cloud” to always be there. There has never been any example of service providers turning off cloud services and leaving users with expensive door stops. Nope, never. There is no Nest of products for which this had happened.

Sarcasm aside, never buy hardware which can’t be used without a proprietary cloud service. If you can’t turn those requirements off, then you don’t really own the device. You’re just renting it with a high, up-front activation fee and the requirement to handle disposal. Even worse, you get to go through all those costs again when the company decides you need to buy a new version.