[Office 2013] OPK omzeilen in antivirus policies

[Trommelrem]

De volgende policies zijn in gebruik tegen virussen:



Hier is ook al meteen een conflict te zien:

• %LOCALAPPDATA%\*\*.exe
• %LOCALAPPDATA%\Temp\SetupO365ProPlusRetail.x86*.exe

De eerste prevaleert boven de laatste. Dit is een probleem, omdat de Office OPK een .exe file vanuit de Temp probeert te uitvoeren. De enige workaround die ik weet is om de eerste tijdelijk te verwijderen, de user z'n credentials van Office 365 in te voeren, en dan de policy terug te plaatsen.

Is hier een simpele workaround voor? Het moet verboden blijven om .exe files in de betreffende folders te kunnen uitvoeren, maar deze specifieke filename moet wel toegestaan zijn.

-edit-
De exacte filename geven zorgt er wel voor dat de filename prevaleert boven de wildcard. Echter de filename is dynamisch (ProPlus, HomeStudent, etc. met een productkey erachteraan) en zal dus ook niet werken. Eigenlijk moet de waarde "SetupO365*.exe" zijn.

[ Voor 14% gewijzigd door Trommelrem op 02-01-2015 12:00 ]

[Trommelrem]

* schopje *

[Trommelrem]

* schopje *

[Trommelrem]

* schop *

[RaZ]

Leesvoer: Het algemeen beleid #verbodenhacken

[Craven]

RaZ schreef op vrijdag 02 januari 2015 @ 12:00:
Leesvoer: Het algemeen beleid #verbodenhacken

Wat heeft hacken hier nou weer mee te maken? Hij heeft policies die .exe tegengaan maar hij wil dat de executable voor office vanuit office365 wel kan draaien. Lijkt me een volledig valide vraag.

/Ontopic:
Moeten gebruikers de installatie zelf af kunnen trappen of gebeurt dit vanuit een stukje deployment software?

Edit: heb je overigens wat meer info over de omgeving waarin je dit probeert?

[ Voor 20% gewijzigd door Craven op 02-01-2015 12:07 ]

[Trommelrem]

RaZ schreef op vrijdag 02 januari 2015 @ 12:00:
Leesvoer: Het algemeen beleid #verbodenhacken

Euhm, deze policies zijn er juist om hacken tegen te gaan. Bijna alle malware installeert zich in de bovenstaande folders. Helaas probeert de Office 365 oneclick/oobe/opk zich ook te nestelen in de Temp folder (net als Spotify en Dropbox btw).

Craven schreef op vrijdag 02 januari 2015 @ 12:02:
[...]
/Ontopic:
Moeten gebruikers de installatie zelf af kunnen trappen of gebeurt dit vanuit een stukje deployment software?

Dit moeten gebruikers helaas zelf doen. Wellicht is een optie om een script te draaien dat achteraf de juiste policies importeert, als het herkent dat er een geinstalleerde Office aanwezig is.

Het gaat om niet-domeingekoppelde systemen. Een heel divers aantal. Het is gewoon een kaal image+Office 2013 OPK dat via een USB stick wordt uitgerold. Niet via SCCM of WDS.

[ Voor 42% gewijzigd door Trommelrem op 02-01-2015 12:09 ]

[Craven]

Niet in het domein... ach so. Vroeg me al af waarom het de lokale gpo editor was.

Hoe beheer je de hele rataplan nu dan? Je importeert toch ergens de policies?

[Trommelrem]

Die kun je kopieren van een bronsysteem naar een doelsysteem: %WinDir%\system32\GroupPolicy.
Gek genoeg werkt dat gewoon en je kunt ze zelfs via de $OEM$ folders uitrollen zodat je het image achteraf nog kunt aanpassen zonder de install.wim open te breken. De weinige hoeveelheid policies voor niet-domein-PC's zijn toch statisch, gelukkig

[ Voor 31% gewijzigd door Trommelrem op 02-01-2015 12:13 ]

[Craven]

Dus in short:
- IT'er deployed image door met usb stick rond te lopen
- policies worden deployed vanuit centraal punt door ze naar lokaal te kopiëren

Als dat het is zou ik jezelf persoonlijk wat meer opties geven door remote powershell te te configureren op alle systemen. Zie http://www.getautomationm.../item/setup-winrm-credssp 3e kopje. Als alternatief voor winrm kun je ook nog een opstartscript pushen met de local policies. Maar dan ben je wat meer afhankelijk van de lokale machine.

Hiermee kun je dan met een powershell script het hele zooitje een beetje beheersbaar houden. Dan kun je vanuit een centraal punt policies wegdonderen. Installatie aftrappen en de policies achteraf weer terugplaatsen.

Het geheel vereist wel wat config en script werk maar op deze manier kun je een hele berg met zaken aftrappen.

[Trommelrem]

De policies staan al op een USB stick en worden eigenlijk niet eens centraal uitgerold. In principe zullen de PC's ook niet centraal worden beheerd.

Maar bovenstaande tekst lost al een ander vraagstuk van mij op waar ik nog niet aan begonnen was, waarvoor dank. Ik wilde al Remote Powershell aanzetten, zodat er nog iets van beheer mogelijk was. Zonder domeinkoppeling zit dat iets anders in elkaar dan normaal. Dank

Ik ga het nu met een scriptje proberen die gewoon bij het opstarten detecteert of Office 2013 wel/niet is geinstalleerd. Zodra het geinstalleerd is, dan worden de juiste policies geplaatst d.m.v. PowerShell.

[ Voor 47% gewijzigd door Trommelrem op 02-01-2015 12:26 ]

[Craven]

Een stukje beheer achteraf moet toch wel kunnen. Shoot & forget door het plaatsen van een image is zooo 2014...

[Trommelrem]

Normaal ben ik het helemaal met je eens, maar dit is net die ene categorie van 1% van de systemen waarop we juist geen beheer willen doen

[Trommelrem]

Stap verder gekomen:



Uitleg:
• %APPDATA% -> Alles wat executable is in AppData en onderliggende folders wordt geblokkeerd (.exe, .vbs, .lnk, etc.)
• %HKEY...% -> Default door Windows toegevoegd
• %LOCALAPPDATA% -> Alles wat executable is in LocalAppData en onderliggende folders wordt geblokkeerd.
• %LOCALAPPDATA%\Temp\SetupO365*.exe -> Deze prevaleert wel boven bovenstaande. Echter, gebruik je de variabele %TEMP%\SetupO365*.exe dan prevaleert deze niet. Why? Geen idee.
• %PROGRAMDATA% -> Deze blokkeert executables in de ProgramData folder.
• %USERPROFILE% -> Alles in de UserProfile blokkeren (AppData is onderliggend btw, dus dat maakt bovenstaande AppData feitelijk overbodig, tenzij de UserShellFolders niet default zijn)
• %USERPROFILE%\Downloads -> Gedownloade programma's moeten natuurlijk wel kunnen worden geinstalleerd.
• %APPDATA%\Micro......\*.lnk -> In deze folder geen subfolders, alleen linkjes
• %APPDATA%\Micro......\Start Menu -> *.lnk aan het einde betekent geen subfolders, dus dan geen extensie, zodat subfolders wel worden meegenomen.


Dit lijkt op het eerste gezicht goed te functioneren. Het feit dat Dropbox geblokkeerd wordt, betekent dat 90% van de virussen ook wordt geblokkeerd, aangezien die dezelfde mechanieken hebben.

Bestaat er ergens op internet een soort van database waar je virussen kunt downloaden voor testdoeleinden?

[ Voor 7% gewijzigd door Trommelrem op 31-01-2015 01:47 ]