PC Security Advanced Options

I've used Prevx for nigh on a decade in it's various incarnations and my only gripe is it's so d*mn reliable I forget it's there so I've no need to browse or even post here or latterly on WebRoot forum!
It's been a long time (several years) since our ever helpful Joe has had to remote in to a pathologically extreme resource constrained hardware scenario I've engineered for him, the new footprint for Px4 is so reduced that I can't even recreate that any more and now I'm reduced to "Nit picking"

I've now just bought my second 3yr license for what is now the evolved Prevx4/Webroot Secure Anywhere-Complete for the family and found the sophistication of the Management Console has now left me far behind the curve!

Now I'm fixing a colleagues PC remotely and after doing some trivial cleaning/configuration and removal of our ISP's Security and Backup software that was causing him the actual problem I'm trying to pursuade him to "buy-in" to Prevx4/Webroot (as has been my recommendation to many over the years). So after using my RAS connection (Teamviewer) I install a "trial version" and link the trial key into my Console.
Predictably the PX4/WR works superbly and within minutes (as I've already determined) it's not found any malware.

So I idly explore the PC Security Advanced options and to this screen:
http://f.cl.ly/items/352Y0p0r0C2O1J2x3S2h/Screen%20shot%202013-08-30%20at%2007.07.57.png
and subsequently COMMANDS:
http://f.cl.ly/items/3n20103022461q0O2D3O/Screen%20shot%202013-08-30%20at%2007.08.32.png
I try System Cleaner first? No indications on the target host at all!
I now get bored so 18min later I decide to try the SHUTDOWN. Again nothing happens on target. No popups, dialogue, nothing. Nothing in either the Admin machine f/w(Little Snitch Version 3.2 nightly (403build on MacbookPro 10.6. nor on target f/w (Win XP Pro SP3). Illogical to suspect a f/w anyway as surely it would also cause a problem with PX4 connectivity and/or my RAS/TV session?


The commands appear to be sent:
http://f.cl.ly/items/3N3y3j0j0p1I0A3U3j3Y/Screen%20shot%202013-08-30%20at%2007.09.22.png

Obviously "Pilot Error" on my part so I explore the various HELP files and only find this limited explanation: Using_PC_Security_Advanced_Options on how to de-activate my PX4? In fact I don't think even that explanation is correct as I'm sure while I was searching the various fora there was a mention that providing the PX4 client was still installed(with a valid key and within the total seat count limit) then a PC could be reactivated?

Clearly I'm looking at the wrong HELP files so can anybody point me to the correct HELP files and also what PX4 logs are required to analyse why the COMMANDS feature doesn't seem to work? If neccessary I'll try and recreate on local systems and run wireshark but I'm sure the answer is far simpler!

 

To simplify your long message: it seems that the commands in the WSA management console do not reach the targeted machine/installation.

So there is some sort of syncronisation problem

 

In a manner of speaking yes but only possibly due to the Message-Queueing paradigm we "think" is employed? I've also raises this on Webroot forum so here's a reciprocol link >Using-PC-Security-Advanced-Options-COMMANDS

Obviously I'm still obliged for your response & input - many thanks.

 

Could you try sending a command and click "Check for updates" on the tray icon?

 

I too have experienced a similar problem with my father-in-laws' computer. For me, there was about a 10 minute latency before the scan started on his computer.

Not sure if waiting 10-20 minutes would finally start the selected command.

 

Nope - Joe knows exactly what the perceived "problem" is and it's B.A.D (Broken As Designed) - however that's a matter of opinion so see my link to my Webroot post as I might unnecessarily offend Joe here.

 

To sum up: You want to send a command but also undo a command.
I guess more than B.A.D. it is simply F.N.A. and no ETA (Feature Not yet Available and no Estimated Time of Arrival).

 

It's a tad more than just that. Firstly to put it in perspective it's not a "show stopping" functional problem:
1. Each command requires confirmation so you can't "accidentally" queue a whole sequence "accidentally".
2. Rather the HELP doesn't (currently) elaborate on how these are queued and reliant on the (client) user "Check for Updates" to invoke them!
3. The process is therefore non-intuitive. (IMHO)

The remedy is obvious:
1. Yes the ability to edit the Queue would be the ideal but I can just imagine the security implications and disproportionate coding required…
2. Far easier(and cheaper) to simply add this elaboration to the PC Security Advanced Options (HELP) and then we all at least have a base "comfort level" to work from?

Let me emphasise as a long term PX user:
This in no way is intended to disparage the superlative overall design of PX4/WSA (and support of Joe + staff) - and thus in the overall scheme of things it really is "Nit picking"!

 

I don't think it is complete nit-picking. Even if it is not really feasible to cancel commands or edit the command queue, knowing that the commands are queue'd until the client computer 'checks-in' with the Cloud for any reason would make it quite helpful to allow the current queue to be viewed. This would help prevent the remote user from accidentally queue'ing up too many repetitive commands due to thinking the commands had not been sent.

 

The polling period of the client is not that good. In WSABE (Hmmm... Green and Hot...?), the shortest polling period configurable is 15 minutes. If something needs to be changed and the current policy has a 15-minute polling period, you still have up to a 15-minute wait for it to happen after sending the command even if the computer is online. Sure, one can click the tray icon and such, but that's sub-optimal. If the computer is currently in a stealth mode profile, that's not even an option.

Stealth mode profile and 24-hour check-in? Get the user to reboot for pretty much the only option. This is nuts, since when something needs to be done, it needs to be done now, not up to 15 minutes from now or more.

I suppose that perhaps the check-in could also occur when the agent does a standard operational check-in, such as forwarding behavioral information about an unknown file or checking an uncached object, but then it's relying on random events. That's also no good. If I knew some way to run a command-line flag on wrsa.exe and have it check in, at least I could try to use psexec as a workaround. But still not optimal.

Perhaps it's time to create the option for a more-regular heartbeat poll for remote control purposes. Perhaps it'll require a new segregated infrastructure specifically for heartbeat and command polling. I don't know if the current monolithic infrastructure would handle it gracefully. Who knows though? It doesn't take a huge amount of traffic to say "Hey, it's me!" and receive a negative response back most of the time.

Obviously scalability would have to be taken into account. Toss a TCP connection establishment in there and a minimal amount of data and hang up and you could have a burst of about 300 bytes on a check in. Say a check in every minute? Okay. 300 bytes a minute, 18k an hour, that's not too bad. Multiply that by five million customers and you're up to 90GB an hour on the server. Check in once every 10 seconds instead of every minute and you're dealing with 540GB/h, or 1.2 gigabits per second average, not flat, but likely to have bursts. And that's only if there are no commands being sent. Then get to the point where there are 50 million customers... Yeah.

Anyway... Yeah.

 

Exactly, except it's closer to 5KB for a check in, so it would end up being around one terabyte per second for our userbase just for checking in once a minute. Putting that volume into more understandable sizes, compare it to the more than 100 hours of video are uploaded to Youtube every minute. Just the act of a one-minute check in interval would make that call take up 10 times as much bandwidth as the entire uploading of Youtube. That's a lot of cat videos.

The interval for polling defaults to a 15 minute minimum because we'd end up DDoSing ourselves otherwise. There are ways of triggering a poll via commandline or through the tray icon, but we limit the background settings because of the massive costs on both our side and the customer's side (we would DDoS the customer's own internal network before our global network).

 

I believe the business console allows for viewing/de-queuing commands but I'm not as familiar with the portals (someone on the Community should be able to help out).

 

Gee - I raised this as a "nit pick" (which I believe it still is) and as fascinating as the the mutual technical explanations are I believe they're absorbing far more time than the issue deserves? Can't you or JimW just simply add a 5 line para to the HELP section and just move on to far more important issues?

I'm now feeling terribly embarrassed at raising the "anomaly" at all!

EDIT: I'll even promise not to post agin for another 2 years if it helps?

 

Anything brought up definitely deserves consideration. You having to wait 18 minutes for the commands to come down is more than it should take so I'm not dismissing the fact that that there could be something wrong here. We've changed the default intervals for the consumer vs business product a few times so it's not outside of the realm of possibility that it is waiting too long to check in.

I'll be digging into this closer and will let you know

 

I hope not! I've always enjoyed your posts over the last many years

 

The Consumer version allows you to see the past history of sent commands, but not the current queue of un-sent commands.

 

That's the current check-ins.

I was thinking of something to be developed as command-poll specific check-ins on a system developed explicitly for the purpose. Keep in mind I'm the kind of person who says "Why do these thirty checkbox values take up 120 bytes in the database?" and makes them into a bitmask in four bytes. Then people say "Why did you do that? It's not that big a deal!" They find out the big deal when they reach a hundred million entries in the database and are only using 400MB for the checkboxes instead of 12GB.

 

I agree Bitmasks are a bit more difficult to use but well worth the development effort.

 

See I said it was just a Nit and you've got this trivial issue fix planned already!

That only leaves two slightly less trivial mac client related "nits" to provision the missing "feature fluff" for parity with PC client and add mac to the Management console and I can hibernate for another 7years without pestering you for a brand new client!