Configuring multiple av policies for off-network computers

Hello Ash,

do I understand correctly that off-network means the endpoints are unmanaged? Just curious - how would you point the clients at [a new CID]?

There are two way to create additional CIDs (which can be individually configured). Please note that you can only "multiplicate" a full CID, not just - say - the savxp subfolder.

1. add one or more shares on your server (create the necessary folders in the filesystem and share them, then add them in Configure update manager, tab Distribution)
2. add one or more subscriptions

But IMO it's better to manage the endpoints from SEC - if you indeed don't do it, what's the reason?

Christian

Hi Christian.  Yeah, the issue of redirecting existing clients was something I was going to muse on - the subset which I'd need to change all have an SCCM client on, so I should be able to either push a new version of SAV to them, leaving the bulk of the clients pointing at the current update source.

Yep, off-network being unmanaged by SEC.

Fully understand that managing endpoints from SEC would be the smart thing - when it was installed several years back the decision was taken not to do this.  Which doesn't really help me!  As I say, the parent is on one domain, all the other clients are on different domains with zero connectivity between each as far as AD goes - they're on the same WAN but that's about it.

Cheers for the pointers.

Ash

Hi Christian.  Yeah, the issue of redirecting existing clients was something I was going to muse on - the subset which I'd need to change all have an SCCM client on, so I should be able to either push a new version of SAV to them, leaving the bulk of the clients pointing at the current update source.

Yep, off-network being unmanaged by SEC.

Fully understand that managing endpoints from SEC would be the smart thing - when it was installed several years back the decision was taken not to do this.  Which doesn't really help me!  As I say, the parent is on one domain, all the other clients are on different domains with zero connectivity between each as far as AD goes - they're on the same WAN but that's about it.

Cheers for the pointers.

Ash

Hello Ash,

different domains with zero connectivity between each as far as AD goes
AD connectivity isn't needed. The management component (Remote Management System - RMS) uses ports 8192 and 8194 endpoints to server and (ideally but optionally) 8194 server to endpoint. Communication is secured so it'd be an insignificant (if at all) increase in attack surface. Usually one doesn't put the management server on the perimeter, that's one reason for the relays in the article.
The biggest problem are perhaps duplicate endpoint names but one can work around this. If installed with the management component endpoints will locate the management server and connect to it. Doesn't matter if they are in AD or not, it isn't even necessary that the server knows them before they connect.

Feel free to ask if you have any questions

Christian   

That's interesting - and potentially very useful.  So, some questions.

1. Is there enough data gleaned in the console so that it's possible to work out which location the infected machine is actually in?  A chunk of these will be on workgroups, so I imagine IP address would be the most useful for us to match against.
2. Is remote clean/disinfect still possible without any funky permissions needed? Does this just run within the existing Sophos Users installed on the box as part of the endpoint install?
3. Is there any reason - through usability or security - which would make it unwise to proceed down this path

ta

Ash

Hello Ash,

1. as you have the console ... ah, I see ... All the information in the Computer Details tab (for a managed computer - slightly larger icon, black font, green or red overlay) comes from the endpoint. As you have the means to "install things" on the endpoints you probably have put them already in their appropriate group anyway
2. Cleanup (as far as this is possible but guess you know the restrictions) is performed by SavService which gets its instruction either via the local GUI or via RMS from the console. The console has the same rights as an administrator who is member of the SophosAdministrator group. No local or AD account rights apply
3. I'm biased [:)]. It definitely means more work for the console administrator [;)]  (and, seriously, perhaps significantly more load on the management server and the database of course, and you might need message relays). I don't see a single thing which would make it unwise though

Christian

Cheers for that - all useful advice.

Have got a client with the RMS on it which has now popped up in the console which is handy, so I guess all ports are open.  I've been able to push a remote scan which ran correctly, although it's not flagging quarantined items (I dropped psexec onto the box to test) in the console, so I'm unable to test whether a remote clean will work.  Left it all overnight to see if there was some latency going on, but no change. 

Anything obvious that I'm missing?

Hello Ash,

if psexec (which belongs to Adware and PUAs) is in the local quarantine there should be a corresponding alert in the console. The local Anti-Virus log (SAV.txt) contains all detections with their details.
Just requested a Full System Scan from the console (contrary to Running a Full system scan of an endpoint from Enterprise Console it does scan for PUAs and does detect psexec). Alerts are sent almost immediately - please check the Last scan completed/name columns in the Anti-Virus Details tab. If Scan my computer is there with a proper timestamp then there was no detection. Latencies (or better: delays) are normally only observed downstream (i.e. server to endpoint - e.g. when applying policies) if the down connection (to the endpoint's 8194) is not available.

Christian