％appdata％、％temp％などでプログラムの実行をブロックすることの長所と短所は何ですか？
CryptoLocker を防止する方法を調査しているときに、次の場所で実行アクセスをブロックするために Group Policy Objects （GPO）および/またはウイルス対策ソフトウェアを使用することを勧めるフォーラムの投稿を見ました：
- ％アプリデータ％
- ％localappdata％
- ％temp％
- ％UserProfile％
- 圧縮アーカイブ
明らかに、フォーラムで書かれたものはすべて注意して取られるべきです。ただし、これは主にマルウェアがこれらの場所から実行されることを好むためです。もちろん、これは正当なプログラムにも影響を与える可能性があります。
これらの場所への実行アクセスをブロックすることの欠点は何ですか？
利点は何ですか？
マルウェアがこれらの場所からの実行を好む理由は、正規のソフトウェアがこれらの場所からの実行を好むためです。これらは、ユーザーのアカウントがある程度のアクセス権を持つことを期待するべき領域です。
私のシステムの迅速なgrepと、ネットワーク上のランダムなエンドユーザーアカウントに基づいています。
%appdata%
現在、私は Dropbox 、 Adobe AIR のインストーラー、およびいくつかのMicrosoft Officeオッズを取得し、このフォルダーで終了しています。
%localappdata%
join.meと SkyDrive は、ここに住んでいるか、少なくとも最近運転しているようです。
%temp%
正当なものかどうかに関係なく、多くのプログラムがこのフォルダから実行する必要があります。圧縮されたインストーラーアーカイブでsetup.exeを実行すると、通常、インストーラーはこのサブフォルダーに解凍されます。
％UserProfile％
ユーザーが特定の要件を持たない限り、通常は安全ですが、上記のフォルダーの少なくとも一部は、ローミングプロファイルを使用するネットワーク上でこれのサブセットになる可能性があることに注意してください。
圧縮アーカイブ
コードを直接実行しないでください。代わりに、通常、%temp%に抽出してそこから実行します。
これらの領域をブロックする必要があるかどうかは、ユーザーが通常行っていることによって異なります。彼らがする必要があるすべてがOfficeドキュメントの編集である場合は、昼食時に Minesweeper を再生し、ブラウザで [〜＃〜] lob [〜＃〜] アプリにアクセスします。などの場合、これらのフォルダの少なくとも一部で実行可能ファイルをブロックするのにそれほど問題はないかもしれません。
明確に定義されたワークロードがあまりない人々にとっては、同じアプローチは明らかに機能しません。
長所：
これらの場所から実行しようとするマルウェアは実行できません。
短所：
これらの場所から実行しようとする正規のプログラムは実行できません。
これらのディレクトリで実行権限を必要とする、環境内にどのような正当なプログラムがあるかについては、あなたしか言えませんが、私は RobMが高レベルの概要で回答を投稿しただけです と表示します。これらのディレクトリからの実行をブロックすると問題が発生するため、最初にいくつかのテストを行って、どのような問題が発生するか、およびそれらを回避する方法を決定する必要があります。
これらの推奨事項は私の環境で完全に機能します。ユーザーがソフトウェアをインストールすることは許可されておらず、承認されたソフトウェアのどれもが言及された場所から実行されません。ワークステーションには、承認されたソフトウェアがワークステーションイメージにプリインストールされており、スクリプトによって更新されています。
Dropbox、Chrome、Skypeなどはすべて、インストール中に、より受け入れやすい「Program Files」インストール場所に再配置できます。
管理者またはドメイン管理者（および特定の「インストーラー」アカウント）が更新を実行し、承認されたソフトウェアを追加できることを許可している限り、私は推奨事項に同意します。
これらのフォルダだけでなく、それらから始まるツリー全体に対する実行権を拒否する必要があると思います（そうでない場合、やりたいことをする意味がありません）。
-明白な-結果は、これらにある実行可能ファイルが実行に失敗することです。
残念ながら、これにはかなり多数の正当なアプリケーションが含まれます。
％localappdata％と％appdata％は最も問題のあるものです。たとえば、Dropbox、Chrome、SkyDriveなどは機能しません。ほとんどの自動アップローダーと多くのインストーラーも機能しません。
％UserProfile％には、％localappdata％と％appdata％の両方、および他の多数のフォルダーが含まれているため、さらに悪くなります。
つまり、これらのフォルダからアプリケーションを実行できないようにすると、システムがほとんど使用できなくなる可能性があります。
％temp％は異なります。そこから合法的なプログラムが実行される場合がありますが、非常にまれであり、通常は簡単に回避できます。残念ながら、％temp％は、展開元のユーザーコンテキストに応じて異なるフォルダーに展開されます。最終的には％localappdata％\ temp（ユーザーのコンテキスト）または％SystemRoot％\ temp（のコンテキスト）システム）なので、各場所を個別に保護する必要があります。
％temp％も良い候補です。これは、ほとんどのメールプログラムが添付ファイルを開く前に保存するためです。これは、メールベースのマルウェアの多くの場合に役立ちます。
1つの良いトリックは、システムのセットアップ時にC：\ Users\Default\AppData\Local\tempおよびC：\ Users\DefaultAppPool\AppData\Local\Tempフォルダーの権限を変更することです（もちろん、％SystemRoot％）。\temp）。 Windowsは、新しいプロファイルを作成するときにこれらのフォルダーをコピーするため、新しいユーザーは安全な環境になります。
％UserProfile％\ Downloadsをリストに追加することをお勧めします。これは、ほとんどのブラウザーがユーザーのダウンロードしたファイルと同じであり、そこからの実行を拒否すると、セキュリティも向上します。
過去3か月間、メインワークステーションで同様のセットアップを実行しています。私のプライマリユーザーは、ディレクトリへの実行権限または書き込み権限を持っていますが、両方を持っていることはありません。
つまり、このアカウントでは新しい実行可能ファイルを導入できません。それはプロです、私はすでにシステム上にあるか他のアカウントによってインストールされたプログラムを実行できますが、新しいプログラムをダウンロードしてそれを実行することはできません。私のシステムでは、単純なDLL=インジェクションも機能しません。
他の人が指摘したように、主な問題は、一部の正規のソフトウェアがブロックした場所を使用することです。私の場合：
- Google Chrome-msiバージョンをインストールしました
- ポータブルアプリアプリケーション-別のユーザーで実行している
- プロセスエクスプローラー-抽出した64ビットバージョンを直接使用します
- dism.exe-adminとして実行します。これは、ほとんどの場合、とにかく行う必要があります。
つまり、基本的には3つのアカウントを使用しており、1つはログインしていて、もう1つは通常のユーザーアカウントで特定の検証済みプログラムを実行し、管理者アカウントは他の2つの新しいソフトウェアをインストールするためのものです。
VMで新しくダウンロードしたソフトウェアをテストする必要があるという事実が気に入っています。
ほとんどのプログラムはPowerShellで起動し、各アカウントに1つずつ、合計3つのシェルを使用できます。これが機能するかどうかは、使用するソフトウェアの扱い方によって異なります。
開発者のマシンでは、コードをコンパイルして実行する必要があるため、これは実際には機能しません。そのため、データドライブのコードディレクトリに例外を設けました。マルウェアはすべてのドライブをスキャンしてこれを見つけることができます。
これを実施するために、ポリシーではなくNTFS ACLを使用しています。これにより、プログラムが実行されなくなりますが、PowerShellスクリプトを作成して実行することで、十分なダメージを与えることができます。
そのため、事態は難しくなりますが、100％安全ではありませんが、最新のマルウェアから保護されます。
これらのフォルダーを調べることもできますが、ほとんどはデータであり、フォルダーの名前のとおりです。たとえば、クロムが表示されますが、実際の実行可能ファイルはc：\ programsフォルダーにあります。
プログラムフォルダーを除き、すべての実行可能ファイルがコンピューター上で実行されるのをブロックします。何かをインストールする必要がある場合にのみ一時的に許可され、問題が発生したことはありません。