@scottalanmiller said in PCs Backup software that can isolate backup destination to protect from Ransomware virus.:

@openit said in PCs Backup software that can isolate backup destination to protect from Ransomware virus.:

The backup destination will be NAS box and we got around 100 PCs.

You must have a backup server in place between the PCs and the NAS in order to have any protection against ransomware, otherwise the ransomware can attack the NAS directly using the same permissions as the backup mechanism on the PCs.

NAS snapshots could mitigate this risk. Just like Exablox advertises Continuous Data Protection (CDP) as a remedy to ransomware - you can go back to any snapshot in 10 second intervals out until your retention policy limit (file level or share level).

Even basic QNAP and Synology boxes offer scheduled snapshots. Not necessarily a replacement for an intermediate backup server, just an option to consider.

@scottalanmiller all the software I have used accesses remote storage using credentials supplied within the application. In Veeam, for instance, you can choose unique credentials when adding the backup repository:

You could be running Domain Admin on the backup host machine, but Domain Admin has no permissions on the NAS share.

A cryptolocker ran on the Domain Admin account on that machine would encrypt all the local files and share-accessible files, but since the Domain Admin has no permissions on the NAS, it's safe.

@scottalanmiller If CryptoLocker exists that can manipulate the binaries of backup software, we're all !@&ed

Fast forward a few years and the next wave of IT pro's will be lamenting how the "old guys" can't tell the difference between a container, an application and a VM.

Windows file and object audit policies.

• https://blogs.technet.microsoft.com/mspfe/2013/08/26/auditing-file-access-on-file-servers/

• https://technet.microsoft.com/en-us/library/dd277403.aspx

• https://community.spiceworks.com/how_to/122828-how-to-enable-file-and-folder-access-auditing-on-windows-server-2008-and-2008-r2

@gjacobse said in Android Apps:

One thing I am missing I know of is a Document app. I was using SmartOffice, but this requires you to have access to the internet. I would rather not have to be on the internet all the time. And on occasion, it's not possible (middle part of West Virginia.

Google Docs for Android allows offline document creation and editing. You can sync your existing cloud files offline if/as needed.

@wrx7m said in Moving Away From LAN-Centric Security:

What else should I be considering to secure and manage an ever-increasing distributed workforce?

Look into products like BeyondTrust PowerBroker, which is basically an endpoint privilege manager. It allows you to exercise really fine-grained policy based controls over endpoints. Think Group Policy on steroids (in fact, its UI is a GP snap-in clone). You can allow users to self-escalate for specific admin tasks like installing or updating whitelisted software, as an example, while preventing any other task from running. And all kinds of other stuff like controlling peripherals, executing tasks based on policy conditions (AV & Windows Updates, etc), performing file integrity monitoring, etc... It lets you do some pretty slick stuff at a very low permissions-based level to shut down malware before it can even start, and severely restrict what any executing malware can actually achieve. Plus there's all kinds of session monitoring, auto screencapping, behavior analysis, auditing, and so on. You can do a LOT with this tool, if you are comfortable with policy based control.

They have a companion product called Retina which is basically a vulnerability manager & network scanner that integrates tightly with it, but PowerBroker is what has the real teeth for endpoint security.

@dashrender said in Moving Away From LAN-Centric Security:

/sigh, this says it's to expensive for me!

We were quoted $30/seat for 300 seats, plus $6/seat for 1-year maintenance. We ended up buying it for less than that after "negotiations".

Not self-hosted, but look at (1) Teamwork and (2) MeisterTask.

• SHI (consistently good pricing and very responsive rep, easiest MS licensing procurement experience I've encountered)
• SCW (Southern Computer Warehouse -- a small company but they offer excellent service and pricing, I like giving business to them whenever I can)
• CDW (past reps were outstanding and provided years of good service; current rep single-handedly lost all our business)

Sad to say parts and accessories often come from Amazon. We are also getting a fair amount of stuff from B&H Photo Video nowadays. Finally we have MicroCenter locally and often use them for emergency parts or the occasional smokin' deals on desktops/laptops, displays, TVs, and the like.

@scottalanmiller LOL, SAM.

OK still not sure why that "other" access switch on the LAN is getting starved for BPDU packets, but as a band-aid I enabled "tcn-guard" on its upstream port, to prevent it's topology change notifications from flooding the network and goofing the remote fiber switch. So far, so good.

I wonder if this is some odd interop issue from the fact that our old 3750 is still on the LAN running its default flavor of PVST. Our Aruba is doing MSTP and has been interop'ing fine alongside the 3750 until now. The plot thickens!

If nothing else this will motivate me to finish pulling the plug on that old 3750. Got some work to do yet...

Welp, got it figured out, and it had nothing to do with any of my theories

The "other" access switch that was generating all the BPDU starvation errors was also a remote switch at a completely different site (unrelated to this fiber replacement), connected via PTP Ubiquiti NanoBeam radio. The head-end radio, even though it was set for simple bridge mode, had STP toggled on for some [mistaken] reason. Of course Ubiquiti NanoBeams don't speak HPE MSTP, so it was borking the BPDUs to that remote switch. Since that switch was getting starved for BPDUs, it was self-promoting to root bridge. Of course on the upstream switch I had root-guard enabled to prevent the remote switch from actually becoming root, but the TCNs still propagated out and somehow kept crippling the original problem switch on the new fiber. I'm not sure why it was only causing problems on these remote switches on the new fiber, and no other switches/links, but hey.

Final solution: Disable STP on the Ubiquiti radio. BPDU starvation resolved immediately, remote fiber switches management VLAN connectivity restored also. Problem solved.

Thanks very much to all for being a sounding board and the great suggestions. Special thanks to @notverypunny for pointing me in the right direction with STP. Teaches me to step back and look at the patterns.