第13回 NETMARK＋iproute2＋TDEフル活用でLIDS総仕上げ
面 和毅
サイオステクノロジー株式会社
インフラストラクチャービジネスユニット
Linuxテクノロジー部
OSSテクノロジーグループ
シニアマネージャ
2006/12/20
rsync＋iproute2のテスト
以上の設定により、rsyncコマンドのみがsyslogサーバに接続でき、通常のsshコマンドなどではsyslogサーバに接続するルーティングが見つからないという状況が作れたはずですので、テストしてみましょう。
LIDS-JPサイトにシステム環境を「atmarkit_part13.tar.gz」として用意していますので、このファイルをダウンロードして、実際の動作を確認してみましょう。
ファイル内の基本的な構成は前回（第12回）とほとんど変わりありません。前回の構成に加え、rsyncの設定が追加された状態となっています。
- syslogサーバを立ち上げます。“ifconfig”コマンドで、IPアドレスを調べておきます。
- ホストOS用のip_masq.vm.shファイルのIPアドレスを修正します。筆者の環境ではvmnet1（HOST-ONLYの際に使用される）のネットワークが「192.168.164.0／24」なため、このようなシェルスクリプトになりましたので、皆さまの環境のvmnet1を調べて、適切な値に修正してください。
- ホストOS上でip_masq.vm.shファイルを実行します。
- LIDSが有効になったシステムを立ち上げます。
- rootでログインした後、“lidsadm -S -- -LIDS”コマンドでLFSを開きます。以下、6の手順はLFS中で行います。
- /root/part13以下に、
・iproute.sh
・iptables.syslogd.sh
があります。iproute.shファイル中でIPアドレスが「192.168.164.2」「192.168.164.1」となっていますので、それぞれ「vmnet1のネットワークでvmnet1以外のもの」「vmnet1のIP」に変更します。 - これで設定は終了ですので、LFS以外の端末から、
| # rsync -avz -e ssh /var/tmp/test-backup 192.168.231.135:/var/tmp/lids |
としてrsyncによるバックアップを行います。途中でTDEによるエラーは表示されますが、バックアップは成功します。
 |
| 図3 rsyncを実行しバックアップ（画像をクリックすると拡大します） |
- 今度は、syslogサーバに向けて、
| # ssh -l root 192.168.231.135 |
としてログインしてみます。sshクライアントからはルーティングが見えませんので、エラーとなります。
 |
| 図4 syslogサーバへ直接ssh接続することはできない（画像をクリックすると拡大します） |
さらにサンドボックス化
上記の設定ではrsyncとiproute2の組み合わせだけでしたので、これにTDEを併せてより強固なセキュリティを考えてみましょう。
| # lidsconf -A -s /usr/bin/rsync -o LIDS_SANDBOX -j ENABLE |
として、rsyncのプログラムをサンドボックス化します。
その後、rsyncプログラム、およびrsyncから子プロセスとして起動されるsshプログラムが必要とするファイルへのアクセス権を追加していきます。最終的にrsyncに必要とされるアクセス権を追加していったものは図5のようになります。このスクリプトは、ダウンロードしていただいたVMwareイメージ内に/root/scripts/clients/lids.rsync.sandboxed.shとして格納されていますが、このACLが反映されていない状態になっています。
| #!/bin/sh /sbin/lidsconf -A -s /usr/bin/rsync -o LIDS_SANDBOX -j ENABLE # from ldd /sbin/lidsconf -A POSTBOOT -s /usr/bin/rsync -o /lib/libpopt.so.0 -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/bin/rsync -o /lib/libresolv.so.2 -i 1 -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/bin/rsync -o /lib/libc.so.6 -i 1 -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/bin/rsync -o /lib/ld-linux.so.2 -i 1 -j READONLY # from error log /sbin/lidsconf -A POSTBOOT -s /usr/bin/rsync -o /etc/ld.so.cache -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/bin/rsync -o /lib/tls -j READONLY # For SSH protocol/program /sbin/lidsconf -A POSTBOOT -s /usr/bin/rsync -o /usr/bin/ssh -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/bin/rsync -o /usr/lib/i686/cmov -i 1 -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/bin/rsync -o /usr/lib/i686/cmov/libcrypto.so.0.9.7 -i 1 -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/bin/rsync -o /lib/libutil.so.1 -i 1 -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/bin/rsync -o /usr/lib/libz.so.1 -i 1 -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/bin/rsync -o /lib/libnsl.so.1 -i 1 -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/bin/rsync -o /lib/libcrypt.so.1 -i 1 -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/bin/rsync -o /lib/libdl.so.2 -i 1 -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/bin/rsync -o /lib/libnss_nis-2.3.2.so -i 1 -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/bin/rsync -o /usr/lib/libcrypto.so.0.9.7 -i 1 -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/bin/rsync -o /usr/lib -i 1 -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/bin/rsync -o /lib -i 1 -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/bin/rsync -o /etc/ssh/ssh_config -i 1 -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/bin/rsync -o /etc/services -i 1 -j READONLY # Reading Public/Private key file for auth /sbin/lidsconf -A POSTBOOT -s /usr/bin/rsync -o /root -j READONLY # Reading Data directories/files for Backup /sbin/lidsconf -A POSTBOOT -s /usr/bin/rsync -o /var/tmp -j READONLY |
| 図5 lids.rsync.sandboxed.shの内容 |
この中で重要なこととしては、rsyncが起動した子プロセスのsshにアクセス権を与える際には、/usr/bin/sshプログラムに直接アクセス権を与えているわけではなく、rsyncに与えた権限を第1世代のみに継承（第10回）させることによりアクセス権を与えているということです。これにより、不必要にsshプログラムすべてに対してアクセス権を与えることなく、rsyncから起動されたsshプロセスのみにアクセス権を与えることで、プログラムに対してアクセス権を無意味に与えすぎないようになっていますので、さらにセキュリティが確保されます。
図5のファイルの一番下の行は、rsyncによりバックアップを取りたいディレクトリ／ファイルを列記してあります。これは、rsyncがそのディレクトリ／ファイルをバックアップするためには、READONLYの権限が必要なためです。
このACLを有効にするためには、/root/scripts/clients/lids.rsync.sandboxed.shファイルをLFS内で実行すれば、次回再起動時に有効になります。すぐにACLを反映したい場合には、スクリプトを実行した後にLFS内で、
| # lidsadm -S -- +RELOAD_CONF |
として設定ファイルを再読み込みさせることにより、マシンを再起動せずにACLを反映することができます。
 |
2/3 |
 |
| Index | |
| NETMARK＋iproute2＋TDEフル活用でLIDS総仕上げ | |
| Page1 rsync＋iproute2でバックアップを |
|
 |
Page2 rsync＋iproute2のテスト さらにサンドボックス化 |
| Page3 VMwareとiproute2を組み合わせる |
|
 |
Security&Trust記事一覧 |
- Windows起動前後にデバイスを守る工夫、ルートキットを防ぐ （2017/7/24）
Windows 10が備える多彩なセキュリティ対策機能を丸ごと理解するには、5つのスタックに分けて順に押さえていくことが早道だ。連載第1回は、Windows起動前の「デバイスの保護」とHyper-Vを用いたセキュリティ構成について紹介する。 - WannaCryがホンダやマクドにも。中学3年生が作ったランサムウェアの正体も話題に （2017/7/11）
2017年6月のセキュリティクラスタでは、「WannaCry」の残り火にやられたホンダや亜種に感染したマクドナルドに注目が集まった他、ランサムウェアを作成して配布した中学3年生、ランサムウェアに降伏してしまった韓国のホスティング企業など、5月に引き続きランサムウェアの話題が席巻していました。 - Recruit-CSIRTがマルウェアの「培養」用に内製した動的解析環境、その目的と工夫とは （2017/7/10）
代表的なマルウェア解析方法を紹介し、自社のみに影響があるマルウェアを「培養」するために構築した動的解析環境について解説する - 侵入されることを前提に考える――内部対策はログ管理から （2017/7/5）
人員リソースや予算の限られた中堅・中小企業にとって、大企業で導入されがちな、過剰に高機能で管理負荷の高いセキュリティ対策を施すのは現実的ではない。本連載では、中堅・中小企業が目指すべきセキュリティ対策の“現実解“を、特に標的型攻撃（APT：Advanced Persistent Threat）対策の観点から考える。
 |
|
|
|
|
