Які плюси / мінуси блокування запуску програми у% appdata%,% temp% тощо?

Досліджуючи способи запобігання CryptoLocker , я побачив допис на форумі, який радив використовувати об’єкти групової політики (GPO) та / або антивірусне програмне забезпечення для блокування запущеного доступу в таких місцях:

1. %дані програми%
2. % localappdata%
3. % темп.%
4. %Профіль користувача%
5. Стислі архіви

Очевидно, що все, що написано на форумі, слід сприймати обережно. Я бачу переваги для цього, хоча насамперед тому, що зловмисне програмне забезпечення любить виконувати з цих місць. Звичайно, це може вплинути і на законні програми.

Які недоліки блокують доступ до цих місць?

Які переваги?

Причина, яку зловмисне програмне забезпечення любить виконувати з цих місць, полягає в тому, що законне програмне забезпечення любить виконувати з цих місць. Вони є областями, до яких обліковий запис користувача повинен мати певний рівень доступу.

На основі швидкої перевірки власної системи та випадкового облікового запису кінцевого користувача в нашій мережі:

%appdata%

Зараз у мене є Dropbox , інсталятор Adobe AIR та кілька шансів і закінчень Microsoft Office у цій папці.

%localappdata%

Тут, мабуть, живуть join.me та SkyDrive або, принаймні, проїхали останнім часом.

%temp%

Багато програм, законних чи інших способів, захочуть виконати з цієї папки. Запуск установки, як правило, розпаковується до папки цього під час запуску setup.exeв архіві стислих програм.

%Профіль користувача%

Зазвичай це буде безпечно, якщо користувач не має особливих вимог, хоча зауважте, що принаймні деякі з перерахованих вище папок можуть бути підмножинами цієї мережі в мережі з роумінговими профілями.

Стислі архіви

Не запускайте код безпосередньо, замість цього, як правило, витягайте %temp%та запускайте звідти.

Від того, чи слід блокувати ці області, чи ні, це залежить від того, що зазвичай роблять ваші користувачі. Якщо все, що їм потрібно зробити, - це редагувати документи Office, грати на Мінську під час обіду та, можливо, отримувати доступ до програми LOB через браузер тощо.

Очевидно, що той самий підхід не буде працювати для людей з менш чіткими навантаженнями.

Плюси:

Зловмисне програмне забезпечення, яке намагається виконати з цих локацій, не вдасться запустити.

Мінуси:

Законні програми, які намагаються виконати з цих місць, не зможуть запускатися.

Щодо законних програм у вашому оточенні, яким потрібні права на виконання у цих каталогах, ви тільки можете сказати, але я бачу, що RobM тільки що опублікував відповідь з оглядом високого рівня . Блокування виконання цих каталогів викличе у вас проблеми, тож спочатку потрібно пройти тестування, щоб визначити, які проблеми у вас виникнуть та як їх вирішити.

Ці рекомендації чудово працювали б у моєму середовищі. Користувачам НЕ дозволяється встановлювати програмне забезпечення, і НІКОЛІ затвердженого програмного забезпечення не виконує згаданих місць. Робочі станції мають затверджене програмне забезпечення, попередньо встановлене у зображенні робочої станції та оновлене сценарієм.

Dropbox, Chrome, Skype тощо можуть бути переміщені під час встановлення до більш прийнятного місця установки "Файли програм".

Поки у вас є доступ до адміністраторів або адміністраторів домену (а може бути, конкретного облікового запису "Інсталятор"), щоб мати змогу запускати оновлення та додавати затверджене програмне забезпечення, я погоджуюся з рекомендаціями.

Я припускаю, що ви хочете відмовити у виконанні права не лише цим папкам, а й цілому дереву, починаючи з них (інакше немає сенсу робити те, що ви хочете робити).

Очевидним наслідком буде те, що будь-який виконуваний у них файл не може працювати.

На жаль, це стосуватиметься досить великої кількості законних додатків.

% localappdata% та% appdata% - найбільш проблемні: Dropbox, Chrome, SkyDrive, наприклад, не спрацюють. Більшість автоматичних завантажувачів та багато інсталяторів також не працюватимуть.

% UserProfile% ще гірше, оскільки він включає як% localappdata% і% appdata%, так і ряд інших папок.

Якщо коротко: якщо ви не дозволяєте програмам запускатися з цих папок, ваша система може стати майже непридатною.

% temp% відрізняється. Хоча час від часу у вас можуть працювати законні програми, це досить рідко і зазвичай легко обійтися. На жаль,% temp% розширюється до різних папок залежно від контексту користувача, з якого ви його розширюєте: він може опинитися у% localappdata% \ temp (у контексті користувача) або% SystemRoot% \ temp (у контексті система), тож вам доведеться захистити кожну локацію окремо.

% temp% також є хорошим кандидатом, оскільки саме там більшість поштових програм збереже вкладення перед відкриттям: це допоможе у багатьох випадках програмного забезпечення на основі пошти.

Один хороший трюк - змінити передумови в папках C: \ Users \ Default \ AppData \ Local \ temp і C: \ Users \ DefaultAppPool \ AppData \ Local \ Temp під час налаштування системи (і, звичайно,% SystemRoot% \ temp). Windows буде копіювати ці папки, коли створює нові профілі, і таким чином нові користувачі матимуть захищене середовище.

Ви можете додати% UserProfile% \ Downloads до свого списку: саме тут більшість браузерів завантажуватимуть файли користувача, і відмова від його виконання також підвищить безпеку.

Останні три місяці я працюю з подібним налаштуванням на своїй головній робочій станції. Мій основний користувач або виконує дозволи до каталогу, або дозволи на запис, але ніколи і те й інше.

Це означає, що за допомогою цього облікового запису не можна вводити нові виконувані файли. Це профі, я можу виконувати програми вже в системі або встановлені іншими обліковими записами, але я не можу завантажувати будь-яку нову програму і запускати її, це означає, що будь-яке зловмисне програмне забезпечення, яке надходить через браузер чи інші засоби, має набагато важчий час для запуску у моїй системі просте введення DLL також не працює.

Як зазначали інші, головна проблема полягає в тому, що деяке законне програмне забезпечення використовує локації, які я заблокував. У моєму випадку:

• Google Chrome - я встановив версію msi
• будь-яке додаток Portable Apps - яке я зараз запускаю під іншим користувачем
• Провідник процесів - я безпосередньо використовую витягнуту 64-бітну версію
• dism.exe - запускати як адміністратор, що мені доводиться робити більшу частину часу.

Таким чином, я в основному використовую три облікові записи, один з яких я входив, інший звичайний обліковий запис користувача для виконання певних перевірених програм як, а обліковий запис адміністратора для встановлення нового програмного забезпечення для двох інших.

Мені подобається те, що він змушує мене перевірити будь-яке нещодавно завантажене програмне забезпечення у віртуальній машині.

Я запускаю більшість своїх програм через PowerShell і маю три оболонки, по одній для кожного облікового запису мені добре. Чи справді це працює для вас насправді, залежить від того, скільки програмного забезпечення ви використовуєте, до якого потрібно поводитися по-різному.

На машині розробника це насправді не працює, тому що я повинен скласти свій код і потім виконати його. Тому я зробив виняток для свого каталогу коду на накопичувачі даних, зловмисне програмне забезпечення могло просканувати всі диски та знайти це.

Я використовую ACL-файли NTFS, а не політику для цього. Це заважає запускати будь-які програми, але я все одно можу створити сценарій PowerShell, а потім запустити це, і це може завдати достатньої шкоди.

Тож, хоча це ускладнює справи, він не є на 100% захищеним, але все одно захистить вас від більшості поточних шкідливих програм.

Ви можете шукати в цих папках, але більшість - це дані, саме так і названа папка. Наприклад, ви побачите хром, але власне виконуваний файл знаходиться в папці c: \ programs.

Я блокую всі виконувані файли не працювати будь-де на комп'ютері, крім папок програми. Дозволено лише тимчасово, коли мені потрібно щось встановити, і я ніколи не мав жодних проблем.

Я рекомендую швидкий пошук каталогів, щоб побачити, що у вас є в кожному з них. Якщо з них нічого не виконується, дотримуйтесь вказівок на форумі. Якщо у майбутньому ви зіткнетеся з проблемою, просто оцініть свої варіанти. Більшість із них не повинні мати виконуваних файлів у них.