Avast Business Antivirus for Linux：avast-fss File Server Shiled

avast-fss File Server Shiled：Avast Business Antivirus for Linux

製品概要	技術資料	バージョン履歴	サポートするOS

技術概要	インストール	初期設定	avast-fss	VPS	REST API	AMaViS	scan	avast	CentOS 7	リンク集

Name 名称

avast-fss - Avast File Server Shield

Synopsis 概要

avast-fss [OPTIONS]]

Description 説明

avast-fss（FSS）は、Avastアンチウイルス for Linuxスイートの一部であり、監視対象ディレクトリに書き込まれたファイルをリアルタイムでスキャンします。
FSSは、Linuxカーネル2.6.37以降で利用可能なfanotify(7)アクセス通知システムに基づいています。

FSSで監視するディレクトリは、設定ファイルで設定する必要があります（下記参照）。

デフォルトでは、FSSはどのディレクトリも監視しません。監視は常に同じマウントポイントに限定されることに注意してください。
監視対象ディレクトリのマウントされたサブディレクトリを監視する場合は、
設定ファイルに明示的に追加してください。

FSSは書き込みイベントのみを監視します。既に感染しているファイルへのアクセスは監視されません。
監視対象ディレクトリへの書き込み操作が行われると、Avastエンジンによるスキャンがトリガーされます。感染が検出された場合、感染ファイルをチェストディレクトリに移動し、ウイルスログファイルに検出結果を報告します（「ファイル」を参照）。

Options オプション

-h

簡単な使用方法を表示して終了します。

$ avast-fss -h

Usage: avast-fss [OPTIONS]
Options:
-c FILE Use configuration file FILE
-V Print program version and exit
-v Verbose logging (debug level)
-q Do not log to stderr

-v

プログラムのバージョンを表示して終了します。

-c FILE

設定ファイルのパスをFILEに設定します。デフォルトの設定ファイルは/etc/avast/fss.confです。

-n

デーモン化しません。

設定

デフォルトの設定ファイルは/etc/avast/fss.confです。形式はavast(1)マニュアルページに記載されているINI形式です。

設定は、グローバル設定オプションと監視設定の2つの部分から構成されます。
以下の設定例は、利用可能なすべてのグローバル設定オプションとそのデフォルト値、そして監視（および監視除外）エントリの例を示しています。

; Avastファイルサーバーシールド設定ファイル

RUN_DIR = "/run/avast"
SOCKET = "/run/avast/scan.sock"
LOG_FILE = "/var/log/avast/fss.log"
CHEST = "/var/lib/avast/chest"
SCANNERS = 4
UNLIMITED_QUEUE = 0

[MONITORS]
SCAN = "/some/directory/to/monitor"
SCAN = "/another/directory/to/monitor"
EXCL = "/path/to/exclude/from/scan"

[GLOBAL PARAMETERS]
RUN_DIR	実行ディレクトリ。PIDファイルはここに保存されます。
SOCKET	AvastサービスのUNIXソケットへのパス。
LOG_FILE	ウイルスログファイルへのパス。
CHEST	チェストディレクトリへのパス。検出された悪意のあるファイルはチェストディレクトリに移動されます。チェストディレクトリが監視対象ディレクトリにある場合、起動時に自動的に除外パスに追加されます。
SCANNERS	並列実行スキャンの数。最高のパフォーマンスを得るには、このオプションをCPUコア数に設定してください。
UNLIMITED_QUEUE	1に設定すると、FSSはfanotifyイベントキューサイズの制限を無効にします。詳細については、fanotify_init(2)のFAN_UNLIMITED_QUEUEを参照してください。

[MONITORS]
SCAN	FSSが監視するパス。 ※複数のパスを指定する場合は、1行には必ず一つのパスを記述し、複数のパスを指定する場合は、必ず複数行に記述してください。
EXCL	監視対象から除外するパス。 ※複数のパスを指定する場合は、1行には必ず一つのパスを記述し、複数のパスを指定する場合は、必ず複数行に記述してください。

ファイル

/etc/avast/fss.conf
デフォルトの設定ファイル。設定を参照してください。

/var/log/avast/fss.log
デフォルトのウイルスログファイル。これは、FSSが通常のログ記録に使用するsyslogとは異なります。

/var/lib/avast/chest
隔離された感染ファイルのデフォルトディレクトリ。

注意点

バインドされたディレクトリ（mount --bind）または名前空間（unshare）を介して作成されたファイルは、最終的に監視対象ディレクトリにファイルが格納された場合でも、fanotify(7) の通知システムを回避してしまう可能性があります。
この問題を回避するには、ソースディレクトリも監視対象ディレクトリのリストに追加してください。

Avast Business Antivirus for Linux の File Server Shield(FSS)のフォルダー設定

サーバーのパフォーマンスを維持しつつ、セキュリティを担保するための「勘所」を整理しました。

FSSの設定ファイル名は、 /etc/avast/fss.conf となります。
この中の SCAN パラメータでディレクトリを指定する際のベストプラクティスをまとめました。

設定時のアドバイス
リアルタイムスキャン（FSS）は「広く浅く」ではなく、**「入り口を絞って深く」**が基本です。

「蛇の生殺し」状態を防ぐ
すべてをリアルタイムで監視しようとすると、OS 全体のレスポンスが低下します。静的なファイルや、一度スキャンして安全だとわかっているバックアップデータなどは、FSS ではなく「週に一度のフルスキャン（オンデマンド）」に任せるのが運用上のコツです。

代表的な設定例

/etc/avast/fss.conf:

[MONITORS]
# スキャン対象をカンマ区切りで指定
SCAN = "/home"
SCAN = "/root"
SCAN = "/tmp"
SCAN = "/var/tmp"
SCAN = "/usr"
SCAN = "/srv"
SCAN = "/lib"
# 除外対象を指定（必要に応じて）
EXCL = "/proc"
EXCL = "/sys"
EXCL = "/dev"
EXCL = "/var/log"

※ SCAN、EXCL パラメータは、必ず1行に1個のディレクトリをダブルクリックで囲って記述してください。
1行に複数のディレクトリを記述すると、エラーとなってしまいます。

※ avast の status チェックだけでは、avast-fss が正常に動作しているかどうかの確認ができません。
※ 必ず avast-fss.service の status もチェックしてください。

# systemctl reload avast
# systemctl status avast
# avast-fss
avast-fss[5449]: Starting daemon.
avast-fss[5449]: Excluding '/var/log' from scanning.
avast-fss[5449]: Excluding '/dev' from scanning.
avast-fss[5449]: Excluding '/sys' from scanning.
avast-fss[5449]: Excluding '/proc' from scanning.
avast-fss[5449]: Started monitoring '/usr/lib'...
avast-fss[5449]: Started monitoring '/srv'...
avast-fss[5449]: Started monitoring '/usr'...
avast-fss[5449]: Started monitoring '/var/tmp'...
avast-fss[5449]: Started monitoring '/tmp'...
avast-fss[5449]: Started monitoring '/root'...
avast-fss[5449]: Started monitoring '/home'...
^Z
[6]+ 停止 avast-fss

# systemctl enable avast-fss.service
# systemctl start avast-fss.service

# systemctl status avast-fss.service
● avast-fss.service - Avast File Server Shield
Loaded: loaded (/usr/lib/systemd/system/avast-fss.service; enabled; vendor preset: enabled)
Active: active (running) since 日 2026-03-29 22:57:50 JST; 8s ago
Docs: man:avast-fss(1)
Main PID: 5278 (avast-fss)
Tasks: 5
CGroup: /system.slice/avast-fss.service
└─5278 /usr/bin/avast-fss -q

3月 29 22:57:50 CentOS-7.9-x86-64 avast-fss[5278]: Excluding '/sys' from scanning.
3月 29 22:57:50 CentOS-7.9-x86-64 avast-fss[5278]: Excluding '/proc' from scanning.
3月 29 22:57:50 CentOS-7.9-x86-64 avast-fss[5278]: Started monitoring '/usr/lib'...
3月 29 22:57:50 CentOS-7.9-x86-64 avast-fss[5278]: Started monitoring '/srv'...
3月 29 22:57:50 CentOS-7.9-x86-64 avast-fss[5278]: Started monitoring '/usr'...
3月 29 22:57:50 CentOS-7.9-x86-64 avast-fss[5278]: Started monitoring '/var/tmp'...
3月 29 22:57:50 CentOS-7.9-x86-64 avast-fss[5278]: Started monitoring '/tmp'...
3月 29 22:57:50 CentOS-7.9-x86-64 avast-fss[5278]: Started monitoring '/root'...
3月 29 22:57:50 CentOS-7.9-x86-64 avast-fss[5278]: Started monitoring '/home'...
3月 29 22:57:50 CentOS-7.9-x86-64 systemd[1]: Started Avast File Server Shield.

設定のコツ

迷った場合は、まずは /srv, /opt, /home, /tmp あたりから監視を始め、システムの負荷（top や htop コマンドで確認）を見ながら /usr などを追加していく「段階的導入」が最もトラブルが少ない方法です。

１. スキャンすべき「推奨」ディレクトリ

主に外部からのファイル流入がある場所、およびユーザーが操作する領域を重点的に保護します。

/home	ユーザーの個人ディレクトリ。ダウンロードしたファイルやスクリプトが置かれるため、最もリスクが高い場所です。
/root	管理者が直接操作する場合｡ダウンロード・メール添付・USBコピーなど、マルウェア侵入の主要経路となる可能性があります。
/tmp /var/tmp	実行ファイルや一時ファイルが置かれる場所で、マルウェアが足場として利用する定番のディレクトリです。しかしながら、ファイルの生成・削除が激しい場合、パフォーマンス劣化の原因となる可能性があります。 ※ただしセキュリティ重視ならスキャン対象にする場合もあり（負荷とトレードオフ）
/var/www /var/ftp /srv	Web / ftp サーバーを運用している場合、アップロード機能などを通じて不正ファイルが混入する可能性があるため必須です。
共有ディレクトリ (Samba / NFS)	File Server Shield の本領発揮ポイントです。Windows クライアントなどが接続する共有フォルダは必ずスキャン対象に含めてください。
/opt	サードパーティ製のアプリケーションがインストールされます。独自のバイナリが置かれるため、スキャン対象に含めるのが安全です。インストール直後の初期状態では、通常は存在しないディレクトリです。
/usr	システムの実行ファイルやライブラリ（/usr/bin など）が大半を占めます。通常は書き換えられませんが、改ざん検知の意味で含める価値があります。
/lib	/usr/lib へのシンボリックリンクであることも多いですが、重要なシステムライブラリ群です。ここへの不正な書き込みを監視するのはセキュリティ上有効です。
/var/www/html/uploads /var/lib/app/uploads	Webアプリのアップロードフォルダ Web経由の攻撃（Webshellなど）対策として非常に重要
/var/mail /var/spool/mail /var/spool/postfix	メール関連（該当する場合）添付ファイル経由の感染対策

２. スキャンから「除外」すべきディレクトリ

ここをスキャンしてしまうと、システムの動作が極端に重くなったり、最悪の場合システムがハングアップしたりするため注意が必要です。

ディレクトリの例	カテゴリ	理由
/proc /sys /dev	仮想ファイルシステム	仮想ファイルシステム（絶対除外）これらは実ファイルではなくカーネルの情報です。スキャンしても意味がなく、エラー、無限ループの原因になります。
/var/log	ログファイル	テキスト中心で感染リスクが低いフォルダーです。常に書き込みが発生するため、スキャンがループ（書き込み→検出→スキャン）して CPU を使い果たします。
/var/lib/mysql, /var/lib/postgresql /var/lib/docker /var/lib/libvirt	データベース	DB のデータファイルは頻繁に更新されるため、リアルタイムスキャンをかけると DB のパフォーマンスが激減し、データ破損のリスクも生じます。
/backup など	バックアップ先	数 GB 単位の大きなファイルを扱う際、スキャンが終わらずに IO 負荷が爆発します。
/run	システム実行時の動的な一時ファイル（PIDファイルやソケットなど）	非常に頻繁に更新されるため、リアルタイムスキャンを行うとシステム全体のパフォーマンスを著しく下げます。これらのディレクトリはファイル数が非常に多いため、OS 起動直後やアプリケーションの大量読み込み時に、少しだけ CPU 負荷が上がることがあります。一度スキャンされ「安全」とキャッシュされれば負荷は下がりますが、もし古いサーバーでスペックが厳しい場合は、これらを除外して /home や /srv に絞るという選択肢もあります。
/etc	設定ファイル群	ここを書き換えられるのは既に root 権限を取られた後であることが多く、また実行ファイルではないため、FSS よりも「オンデマンドスキャン」や「改ざん検知ツール」で守るのが一般的です。
/var/cache /var/lib/yum /var/lib/dnf	パッケージ管理・キャッシュ	正規パッケージであることが前提スキャンしてもメリットが薄い
/bin /sbin /usr/bin /usr/sbin /lib /usr/lib	システムバイナリ領域	頻繁にアクセスされるリアルタイム監視するとI/O遅延の原因定期スキャン（SCANコマンド）で対応するのが一般的

３. スキャン設定は可能だが、あまり意味のないディレクトリ

/boot

ブート

対象に含めることは、**「技術的には問題ありませんが、リアルタイムで監視するメリットは極めて少ない」**というのが結論です。

1. なぜ「含めても問題ない」のか
/boot にはカーネルイメージ（vmlinuz）や初期 RAM ディスク（initrd）、ブートローダー（GRUB）の設定などが格納されています。
低負荷: これらのファイルは、システムのアップデート時以外には書き換えや読み込みが発生しません。そのため、FSS の対象に含めていても、普段の動作で CPU や I/O を圧迫することはまずありません。

2. なぜ「メリットが少ない」のか
リアルタイムスキャンは「今、まさにファイルが作られたり実行されたりする瞬間」を捕まえるためのものです。
実行されない: /boot 内のファイルは、OS の起動プロセス中に読み込まれますが、OS が起動した後は「実行ファイル」として頻繁に動くことはありません。
事後検知になる: 万が一、攻撃者が /boot 内のファイルを改ざんした場合、FSS がそれを検知できるのは「書き込まれた瞬間」です。しかし、ブートキットなどの高度な脅威は、OS が起動してアンチウイルスが動き出す前に動作するため、FSS だけでは防げない領域があります。

3. おすすめの運用方法
/boot の保護に関しては、FSS よりも以下の運用の方が効果的です。
定期スキャン（オンデマンド）でカバー:
リアルタイムで常に監視するのではなく、1日1回や週1回の「フルスキャン」の対象に含めるだけで十分です。

読み取り専用（Read-Only）マウント:
セキュリティを重視する場合、/etc/fstab で /boot を通常は ro (Read-Only) でマウントしておき、アップデート時だけ rw に書き換える手法が Linux サーバーでは一般的です。これが最強の防御になります。

4. 注意を要するディレクトリ /mnt と /media

/mnt と /media の使い分け方は、一般的に以下のようになります。

/mnt は「管理者が手動でマウントする恒久的なドライブ」用、
/media は「ユーザーが抜き差しする一時的なドライブ」用という違いがあります。

どちらも外部データが入る場所なので、物理的な接触があるマシンなら両方入れておくのが最も安全です。

/mnt	マウントボイント	ネットワークマウント（NFS/Samba）の場合、要注意です。ネットワーク経由でスキャンが走ると、I/O待ちが発生してシステムが極端に重くなることがあります。ローカルHDDであれば含めてもOKです。 /mnt の「二重スキャン」問題もし /mnt に別のファイルサーバーをマウントしている場合、その接続先（ファイルサーバー側）でもアンチウイルスが動いているなら、あえてこの Linux 側で FSS をかける必要はありません。ネットワーク帯域を無駄に消費するだけになるからです。
/media		/media ディレクトリについても、設定に含めるべきか気になりますよね。結論から言うと、/media は「セキュリティ上の重要度は非常に高いが、パフォーマンスへの影響に注意が必要な場所」です。 /media の特性に合わせた判断基準をまとめました。 /media を設定に含めるべき理由（推奨：高） Linux システムにおいて、/media は USB メモリ、外付け HDD、SD カードなどの「外部メディア」が自動マウントされる標準的な場所です。マルウェアの侵入経路: 外部から持ち込まれたデバイスは、インターネット経由のダウンロードと同様にウイルス混入のリスクが高い「玄関口」です。動的な保護: FSS に設定しておけば、USB メモリを挿してファイルを開こうとした瞬間にスキャンが走るため、物理的なウイルス持ち込みに対して非常に有効です。注意点：パフォーマンスと挙動一方で、以下の点には留意しておく必要があります。低速なメディアでの遅延: 古い USB 2.0 メモリや低速な SD カードを接続した場合、ファイルへのアクセス（読み書き）のたびにスキャンが走るため、動作が非常に重く感じることがあります。大容量データのコピー: 外付け HDD から数 GB 単位のデータをコピーする際、コピー速度が著しく低下する可能性があります（コピー元をスキャンしてからコピー先に書き込むため）。マウントされていない時: 何も接続されていない時は単なる空のディレクトリなので、システム負荷への影響はゼロです。

■ 実用的な推奨設定例

◎ バランス型（一般的なサーバ）
SCAN = /home, /srv, /var/www, /var/ftp, /mnt
※実際にfss.conf に記述する時は1行に1個のディレクトリだけダブルクォーテーションで囲んで記述してください。

◎ セキュリティ重視（負荷増）
SCAN = /home, /srv, /var/www, /var/ftp, /var/mail, /tmp

◎ 高負荷回避（業務サーバ）
SCAN = /home, /srv

■ 重要な考え方（実務ポイント）

● リアルタイム監視は「入口対策」
○ユーザーファイル・アップロード領域を優先

● OS領域は「定期スキャン」で十分
○cron + scan コマンドで補完

● 除外設定もセットで考える
○EXCL (Exclud) パラメータで細かく調整可能

■ まとめ

○監視すべき
・/home, /srv, /var/www など「外部入力がある場所」

○除外すべき
・/proc, /sys, /dev（必須）
・/tmp, /var/log, /var/cache（推奨）

○慎重に扱う
/usr, /bin, /var/lib（原則は定期スキャン）