NetBeansを利用する機会があったので、メモを取っておきます。
FreeのIDEとしては、Eclipseが有名ですが、昨今、NetBeansが注目を集めています。
また、J2EEにおいては、NetBeansが統合されたパッケージが配布されていることから、
簡単に調査したので、メモを残します。
（さらに、NetBeansには、JUnitのスタブを自動生成する機能があります。）
詳細な情報は、都度、本家のページを参照するようにしてください。
2007/12/04 時点で日本語化用のアーカイブがリリースされています。
（日本語版は 2008 年 1 月末にリリースされる予定です）
## デモ
http://www.netbeans.org/kb/60/java/editor-screencast.html
動画でNetBeanのデモを見ることができます。
Java6に対応している
JavaDBをサポートしている
アプリケーションサーバーが付属
## リンク：
# NetBeansのホームページ
http://www.netbeans.org/index_ja.html
# パッケージ一覧
NetBeansの各パッケージと、機能の一覧が参照可能
http://sunmicro.vo.llnwd.net/c1/netbeans/6.0/final/
# ダウンロードページ
http://www.netbeans.info/downloads/index.php
日本語版ダンウンロードのページ
http://ja.netbeans.org/downloads/60/index.html
* 6.0 英語版と使用可能な日本語化 zip ファイル がリリースされました。
--
関連リンク
# 日本語のページ
http://ja.netbeans.org/index.html
# ユーザーズページ
http://www.netbeans.jp/index.nsp
2007年12月7日金曜日
2007年10月30日火曜日
Apache2 で PHP4.0 を 実行するために必要な SELinux の設定。
Apache2 で PHP4.0 を 実行するために必要な SELinux の設定について PHPが動作できるまでの設定方法を調べたので、まとめたいと思います。
PHP4.0 は、インストールすれば、Apache で勝手に動くものだと思ってました・・・
が、Fedora Core 6 で動かそうと思ったら、なにやらエラーが発生していて動きませんでした。。
いろいろ調べたのですが、詳しい資料もなかったので、とりあえず覚書程度に書いておきます。
そもそも、SELinuxは、RBAC（Role-Based Access Control）という、仕様に基づいて、ユーザーに割り当てたロールによってアクセス権限を制限するための仕組みです。
このロールは、Rootを含むすべてのユーザーに同様に割り当てられます。
つまり、適切な権限のロールをプロセスを実行するユーザーに付与しないとたとえRootでもアクセスを制限されることがあります。
さらに、TE（Type Enforcement）によって、プロセスごとに細かくアクセス制御を提供します。
このプロセスはドメイン遷移という機能によって、ドメインごとに割り当てられ親から子に継承されます。
よって、なにも設定しない状態では、 init プロセスと同じドメインになってしまい、プロセスの実行権限が制限されるというわけです。
【環境】
OS：Linux(Fedora Core 6)
SELinux
Apache 2.0
PHP 4.0
【インストールするパッケージ】
checkpolicy ：TEファイルをコンパイルする際に、checkmodule を使用するために必要になります。（必須）
audit：SELinuxの監査ログを管理します。（推奨）
* 作業の後半で必要になるので、以下のコマンドでインストールしておくと、作業効率が上がります。
# yum install checkpolicy audit
1.PHP のインストールと設定
PHPをコンパイルして、httpd.conf に以下を追記します。
LoadModule php4_module modules/libphp4.so
# /etc/rc.d/init.d/httpd start
エラーが表示されています。
httpd: Syntax error on line 206 of /etc/httpd/conf/httpd.conf: Cannot load /etc/httpd/modules/libphp4.so into server: /etc/httpd/modules/libphp4.so: cannot restore segment prot after reloc: Permission denied
本来ならこれで動くはずですが・・・
2.セキュリティレベルの確認
まず、SELinuxの実行モードを確認します。
# getenforce
Encforcing
SELinuxが、Enforcing モードで実行されています。
setenforce 0 ： Permissive モード （アクセス制御は行わない、警告メッセージをログに出力）
setenforce 1 ： Enforcing モード （SELinux による強制アクセス制御モード）
* Permissive モード で運用するとセキュリティレベルが落ちますので、あくまで検証用に使うようにしてください。（運用時は、Enforcing モードで運用する。）
-v 詳細を確認する
# sestatus -v
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: enforcing
Policy version: 21
Policy from config file: targeted
以降、SELinuxの設定を行います。
3.セキュリティコンテキストの確認
プロセスのセキュリティコンテキストを確認する。
* 通常起動できない状態のため、SELinuxを一時無効にする。
# setenforce 0
# /etc/rc.d/init.d/httpd start
# ps -AZ | grep httpd
user_u:system_r:httpd_t 7636 ? 00:00:00 httpd
user_u:system_r:httpd_t 7638 ? 00:00:00 httpd
user_u:system_r:httpd_t 7639 ? 00:00:00 httpd
user_u:system_r:httpd_t 7640 ? 00:00:00 httpd
user_u:system_r:httpd_t 7641 ? 00:00:00 httpd
user_u:system_r:httpd_t 7642 ? 00:00:00 httpd
user_u:system_r:httpd_t 7643 ? 00:00:00 httpd
user_u:system_r:httpd_t 7644 ? 00:00:00 httpd
user_u:system_r:httpd_t 7645 ? 00:00:00 httpd
# setenforce 1
プロセスを起動したユーザー：user_u
起動元のロール：system_r
ドメイン：httpd_t
ファイルリソースのセキュリティコンテキストを確認する。
# ls -Z /var/www
drwxr-xr-x root root system_u:object_r:httpd_sys_script_exec_t cgi-bin
drwxr-xr-x root root system_u:object_r:httpd_sys_content_t data
drwxr-xr-x root root system_u:object_r:httpd_sys_content_t error
drwxr-xr-x root root system_u:object_r:httpd_sys_content_t html
drwxr-xr-x root root system_u:object_r:icons
# ls -Z /etc/httpd/modules/libphp4.so
drwxr-xr-x root root user_u:object_r:httpd_sys_content_t libphp4.so
これで、ユーザーと、ドメインに実行権限がないことを確認することができました。
4.セキュリティコンテキストの設定
まず、libphp4.so に対して、適切なユーザー、ロール、ドメインを設定を設定します。
# chcon -c -v -R -u system_u -r object_r -t httpd_php_exec_t /etc/httpd/modules/libphp4.so
# ls --context /etc/httpd/modules/libphp4.so
-rwxr-xr-x root root system_u:object_r:httpd_php_exec_t /etc/httpd/modules/libphp4.so
これで、適切なファイルファイルリソースのセキュリティコンテキストを設定することができました。
5.auditd デーモンの設定（推奨）とcheckpolicy のインストール（必須）
SELinuxの監査ログのために、auditdデーモンをインストールします。
これによって、SELinuxの監査ログが /var/log/audit/audit.log に出力されるようになります。
* auditdをインストールしない場合は、その他のログと同様に /var/log/messages に出力されることになります。
また、次の項で、SELinux の ポリシーモジュールパッケージを生成する際、TEファイルをコンパイルするために、、checkmoduleを使用します。checkmoduleは、checkpolicy パッケージに含まれているため、これとインストールします。
# yum install checkpolicy audit
あとは、自動でインストールされるます。
auditの起動
# /etc/rc.d/init.d/auditd start
auditの起動確認
# /etc/rc.d/init.d/auditd status
auditd (pid 8112 7569) is running...
apache を起動する
# /etc/rc.d/init.d/httpd start
Starting httpd:
[FAILED]
起動に失敗し、エラーメッセージが/var/log/audit/audit.log に出力されることを確認する。
6.モジュールの作成
auditをインストールしたことで、監査ログからSELinux ポリシーモジュールを生成することができます。
手順の概要は以下のとおりです。
1.Permissive モードに切り替える
* この操作を忘れると、うまく動作しないことがあります。
2.TEファイルの作成
3.TEファイルをコンパイルする
4.ポリシーモジュールパッケージを作成する
5.ポリシーモジュールパッケージをカーネルにロードする。
6.Encforcing モードに戻します。
6-1.SELinux を Permissive モードに切り替えます。
# setenforce 0
6-2.TEファイルの作成
audit を利用して監査ログから TEファイルを自動生成します。
* 作業ディレクトリは任意の場所で大丈夫です。
# cat /var/log/audit/audit.log | audit2allow -m local > local.te
これで、ローカル用のポリシーモジュールが生成されます。
local.teの内容を確認します。
# less local.te
module local 1.0;
require {
type httpd_t;
type httpd_php_exec_t;
class file execmod;
}
#============= httpd_t ==============
allow httpd_t httpd_php_exec_t:file execmod;
---
ここまで
6-3.TEファイルをコンパイルする
checkmodule コマンドでTEファイルをコンパイルします。
# checkmodule -M -m -o local.mod local.te
checkmodule: loading policy configuration from local.te
checkmodule: policy configuration loaded
checkmodule: writing binary representation (version 6) to local.mod
6-4.ポリシーモジュールパッケージを作成する
# semodule_package -o local.pp -m local.mod
6-5.ポリシーモジュールパッケージをカーネルにロードする。
# semodule -i local.pp
登録されている SELinux ポリシーモジュール を確認する。
# semodule -l
amavis 1.1.0
apcupsd 1.0.0
ccs 1.0.0
clamav 1.1.0
・
・
local 1.0
・
・
6-6.Encforcing モードに戻します。
# setenforce 1
7.apacheを起動します。
設定が反映されているかを確認する。
# /etc/rc.d/init.d/httpd configtest
Syntax OK [ OK ]
apacheを起動します。
# /etc/rc.d/init.d/httpd start
Starting httpd: [ OK ]
お疲れ様でした。
慣れればどうってことない作業ですが、SELinuxは、ドキュメントを読んで仕組みを理解するのに時間がかかります。ユーザー、ロール、ドメインによる、セキュリティポリシーの思想は、理にかなったもので、セキュリティの面からみれば大変有効なものに思えますが、SELinux自体にセキュリティホールがあった場合等を考えると、不安を感じることもあります。
そういった意味でも、サーバーを運用する際は、複数の防御策をうまく組み合わせて、それぞれの技術はあくまでツールとして利用し、管理者のログ監視や、進入検地等も大切だと考えます。
## おまけ：
今回の設定で、audit2why というコマンドを発見しました。
使い方は、audit2why [-p policy] < /var/log/messages
なぜだか SELinux 関係で動かないというときは、以下のコマンドを実行することで、原因が分かるようです。
出力例）
# audit2why < /var/log/messages
Oct 30 06:42:52 office kernel: audit(1193694172.391:49): avc: denied { execmod } for pid=7235 comm="httpd" name="libphp4.so" dev=dm-0 ino=1376787 scontext=user_u:system_r:initrc_t:s0 tcontext=system_u:object_r:httpd_php_exec_t:s0 tclass=file
Was caused by:
Missing or disabled TE allow rule.
Allow rules may exist but be disabled by boolean settings; check boolean settings.
You can see the necessary allow rules by running audit2allow with this audit message as input.
【一発コマンド（コピペ用）】
エラーがなければ、このまま流せば、設定できるはずです。
4つめのコマンドは、必ず[FAILED]になるはずですが、そのまま進みます。
（エラーログを/var/log/audit/audit.logに出力するためにエラーを発生させている。）
chcon -c -v -R -u system_u -r object_r -t httpd_php_exec_t /etc/httpd/modules/libphp4.so
yum install checkpolicy audit
/etc/rc.d/init.d/auditd start
/etc/rc.d/init.d/httpd start
setenforce 0
cat /var/log/audit/audit.log | audit2allow -m local > local.te
checkmodule -M -m -o local.mod local.te
semodule_package -o local.pp -m local.mod
semodule -i local.pp
semodule -l
setenforce 1
/etc/rc.d/init.d/httpd start
PHP4.0 は、インストールすれば、Apache で勝手に動くものだと思ってました・・・
が、Fedora Core 6 で動かそうと思ったら、なにやらエラーが発生していて動きませんでした。。
いろいろ調べたのですが、詳しい資料もなかったので、とりあえず覚書程度に書いておきます。
そもそも、SELinuxは、RBAC（Role-Based Access Control）という、仕様に基づいて、ユーザーに割り当てたロールによってアクセス権限を制限するための仕組みです。
このロールは、Rootを含むすべてのユーザーに同様に割り当てられます。
つまり、適切な権限のロールをプロセスを実行するユーザーに付与しないとたとえRootでもアクセスを制限されることがあります。
さらに、TE（Type Enforcement）によって、プロセスごとに細かくアクセス制御を提供します。
このプロセスはドメイン遷移という機能によって、ドメインごとに割り当てられ親から子に継承されます。
よって、なにも設定しない状態では、 init プロセスと同じドメインになってしまい、プロセスの実行権限が制限されるというわけです。
【環境】
OS：Linux(Fedora Core 6)
SELinux
Apache 2.0
PHP 4.0
【インストールするパッケージ】
checkpolicy ：TEファイルをコンパイルする際に、checkmodule を使用するために必要になります。（必須）
audit：SELinuxの監査ログを管理します。（推奨）
* 作業の後半で必要になるので、以下のコマンドでインストールしておくと、作業効率が上がります。
# yum install checkpolicy audit
1.PHP のインストールと設定
PHPをコンパイルして、httpd.conf に以下を追記します。
LoadModule php4_module modules/libphp4.so
# /etc/rc.d/init.d/httpd start
エラーが表示されています。
httpd: Syntax error on line 206 of /etc/httpd/conf/httpd.conf: Cannot load /etc/httpd/modules/libphp4.so into server: /etc/httpd/modules/libphp4.so: cannot restore segment prot after reloc: Permission denied
本来ならこれで動くはずですが・・・
2.セキュリティレベルの確認
まず、SELinuxの実行モードを確認します。
# getenforce
Encforcing
SELinuxが、Enforcing モードで実行されています。
setenforce 0 ： Permissive モード （アクセス制御は行わない、警告メッセージをログに出力）
setenforce 1 ： Enforcing モード （SELinux による強制アクセス制御モード）
* Permissive モード で運用するとセキュリティレベルが落ちますので、あくまで検証用に使うようにしてください。（運用時は、Enforcing モードで運用する。）
-v 詳細を確認する
# sestatus -v
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: enforcing
Policy version: 21
Policy from config file: targeted
以降、SELinuxの設定を行います。
3.セキュリティコンテキストの確認
プロセスのセキュリティコンテキストを確認する。
* 通常起動できない状態のため、SELinuxを一時無効にする。
# setenforce 0
# /etc/rc.d/init.d/httpd start
# ps -AZ | grep httpd
user_u:system_r:httpd_t 7636 ? 00:00:00 httpd
user_u:system_r:httpd_t 7638 ? 00:00:00 httpd
user_u:system_r:httpd_t 7639 ? 00:00:00 httpd
user_u:system_r:httpd_t 7640 ? 00:00:00 httpd
user_u:system_r:httpd_t 7641 ? 00:00:00 httpd
user_u:system_r:httpd_t 7642 ? 00:00:00 httpd
user_u:system_r:httpd_t 7643 ? 00:00:00 httpd
user_u:system_r:httpd_t 7644 ? 00:00:00 httpd
user_u:system_r:httpd_t 7645 ? 00:00:00 httpd
# setenforce 1
プロセスを起動したユーザー：user_u
起動元のロール：system_r
ドメイン：httpd_t
ファイルリソースのセキュリティコンテキストを確認する。
# ls -Z /var/www
drwxr-xr-x root root system_u:object_r:httpd_sys_script_exec_t cgi-bin
drwxr-xr-x root root system_u:object_r:httpd_sys_content_t data
drwxr-xr-x root root system_u:object_r:httpd_sys_content_t error
drwxr-xr-x root root system_u:object_r:httpd_sys_content_t html
drwxr-xr-x root root system_u:object_r:icons
# ls -Z /etc/httpd/modules/libphp4.so
drwxr-xr-x root root user_u:object_r:httpd_sys_content_t libphp4.so
これで、ユーザーと、ドメインに実行権限がないことを確認することができました。
4.セキュリティコンテキストの設定
まず、libphp4.so に対して、適切なユーザー、ロール、ドメインを設定を設定します。
# chcon -c -v -R -u system_u -r object_r -t httpd_php_exec_t /etc/httpd/modules/libphp4.so
# ls --context /etc/httpd/modules/libphp4.so
-rwxr-xr-x root root system_u:object_r:httpd_php_exec_t /etc/httpd/modules/libphp4.so
これで、適切なファイルファイルリソースのセキュリティコンテキストを設定することができました。
5.auditd デーモンの設定（推奨）とcheckpolicy のインストール（必須）
SELinuxの監査ログのために、auditdデーモンをインストールします。
これによって、SELinuxの監査ログが /var/log/audit/audit.log に出力されるようになります。
* auditdをインストールしない場合は、その他のログと同様に /var/log/messages に出力されることになります。
また、次の項で、SELinux の ポリシーモジュールパッケージを生成する際、TEファイルをコンパイルするために、、checkmoduleを使用します。checkmoduleは、checkpolicy パッケージに含まれているため、これとインストールします。
# yum install checkpolicy audit
あとは、自動でインストールされるます。
auditの起動
# /etc/rc.d/init.d/auditd start
auditの起動確認
# /etc/rc.d/init.d/auditd status
auditd (pid 8112 7569) is running...
apache を起動する
# /etc/rc.d/init.d/httpd start
Starting httpd:
[FAILED]
起動に失敗し、エラーメッセージが/var/log/audit/audit.log に出力されることを確認する。
6.モジュールの作成
auditをインストールしたことで、監査ログからSELinux ポリシーモジュールを生成することができます。
手順の概要は以下のとおりです。
1.Permissive モードに切り替える
* この操作を忘れると、うまく動作しないことがあります。
2.TEファイルの作成
3.TEファイルをコンパイルする
4.ポリシーモジュールパッケージを作成する
5.ポリシーモジュールパッケージをカーネルにロードする。
6.Encforcing モードに戻します。
6-1.SELinux を Permissive モードに切り替えます。
# setenforce 0
6-2.TEファイルの作成
audit を利用して監査ログから TEファイルを自動生成します。
* 作業ディレクトリは任意の場所で大丈夫です。
# cat /var/log/audit/audit.log | audit2allow -m local > local.te
これで、ローカル用のポリシーモジュールが生成されます。
local.teの内容を確認します。
# less local.te
module local 1.0;
require {
type httpd_t;
type httpd_php_exec_t;
class file execmod;
}
#============= httpd_t ==============
allow httpd_t httpd_php_exec_t:file execmod;
---
ここまで
6-3.TEファイルをコンパイルする
checkmodule コマンドでTEファイルをコンパイルします。
# checkmodule -M -m -o local.mod local.te
checkmodule: loading policy configuration from local.te
checkmodule: policy configuration loaded
checkmodule: writing binary representation (version 6) to local.mod
6-4.ポリシーモジュールパッケージを作成する
# semodule_package -o local.pp -m local.mod
6-5.ポリシーモジュールパッケージをカーネルにロードする。
# semodule -i local.pp
登録されている SELinux ポリシーモジュール を確認する。
# semodule -l
amavis 1.1.0
apcupsd 1.0.0
ccs 1.0.0
clamav 1.1.0
・
・
local 1.0
・
・
6-6.Encforcing モードに戻します。
# setenforce 1
7.apacheを起動します。
設定が反映されているかを確認する。
# /etc/rc.d/init.d/httpd configtest
Syntax OK [ OK ]
apacheを起動します。
# /etc/rc.d/init.d/httpd start
Starting httpd: [ OK ]
お疲れ様でした。
慣れればどうってことない作業ですが、SELinuxは、ドキュメントを読んで仕組みを理解するのに時間がかかります。ユーザー、ロール、ドメインによる、セキュリティポリシーの思想は、理にかなったもので、セキュリティの面からみれば大変有効なものに思えますが、SELinux自体にセキュリティホールがあった場合等を考えると、不安を感じることもあります。
そういった意味でも、サーバーを運用する際は、複数の防御策をうまく組み合わせて、それぞれの技術はあくまでツールとして利用し、管理者のログ監視や、進入検地等も大切だと考えます。
## おまけ：
今回の設定で、audit2why というコマンドを発見しました。
使い方は、audit2why [-p policy] < /var/log/messages
なぜだか SELinux 関係で動かないというときは、以下のコマンドを実行することで、原因が分かるようです。
出力例）
# audit2why < /var/log/messages
Oct 30 06:42:52 office kernel: audit(1193694172.391:49): avc: denied { execmod } for pid=7235 comm="httpd" name="libphp4.so" dev=dm-0 ino=1376787 scontext=user_u:system_r:initrc_t:s0 tcontext=system_u:object_r:httpd_php_exec_t:s0 tclass=file
Was caused by:
Missing or disabled TE allow rule.
Allow rules may exist but be disabled by boolean settings; check boolean settings.
You can see the necessary allow rules by running audit2allow with this audit message as input.
【一発コマンド（コピペ用）】
エラーがなければ、このまま流せば、設定できるはずです。
4つめのコマンドは、必ず[FAILED]になるはずですが、そのまま進みます。
（エラーログを/var/log/audit/audit.logに出力するためにエラーを発生させている。）
chcon -c -v -R -u system_u -r object_r -t httpd_php_exec_t /etc/httpd/modules/libphp4.so
yum install checkpolicy audit
/etc/rc.d/init.d/auditd start
/etc/rc.d/init.d/httpd start
setenforce 0
cat /var/log/audit/audit.log | audit2allow -m local > local.te
checkmodule -M -m -o local.mod local.te
semodule_package -o local.pp -m local.mod
semodule -i local.pp
semodule -l
setenforce 1
/etc/rc.d/init.d/httpd start
2007年10月26日金曜日
J2SE 1.4 サポートの終了 （EOL）
J2SE1.4.2 の サポートがEOLによって、終了することになりしました。
EOLの移行期間は、2006 年 12 月 11 日から次のバージョンである Java SE 7 の提供開始 (現時点では 2008 年 夏の予定)までです。
EOL：End of Life
つまり、現状で新規にJavaシステムを導入する場合、Java5以上（Java6移行が望ましい）ということになります。
Java SE6 のページ：
http://java.sun.com/javase/6/index.jsp
ピクシディス社員は、新規案件等でJava 実行環境を検討する際に、十分注意してください。
また、当該バージョンを進めない理由として、以下を念頭にお客様にご提案するようにしてください。
・当該バージョンで開発したシステムが近い将来、運用できなくなる。
・サポート終了後のバージョンアップのために余計なコストが必要となる。
・すでにJava 6 SE によるアプリケーションが安定して稼動可能である。
* その他、お客様にとってのベストプラクティスを十分に検討すること
詳細は、書きサイトで・・・
http://java.sun.com/j2se/1.4.2/ja/
また、過去の案件等で、以前のリリースバージョンのJRE、JDK等が必要な際は、
下記のサイトより取得可能です。
http://java.sun.com/products/archive/index.html
PHP４のサポートも今年いっぱいになりますので、いろいろな案件で、
バージョンアップのための修正等が必要になる場合もあるのでしょうか。
気になったので、少しピクシディス フレームワークを見てみましたが、
弊社のフレームワークにおいては、基本的に修正が必要なところはなさそうですね。
* 実行環境の環境変数やVMのチューニング等細かい設定レベルの修正は必要になるかもしれませんが・・・
移行の際に、留意する注意点等が見つかった場合は、別途アナウンスします。
EOLの移行期間は、2006 年 12 月 11 日から次のバージョンである Java SE 7 の提供開始 (現時点では 2008 年 夏の予定)までです。
EOL：End of Life
つまり、現状で新規にJavaシステムを導入する場合、Java5以上（Java6移行が望ましい）ということになります。
Java SE6 のページ：
http://java.sun.com/javase/6/index.jsp
ピクシディス社員は、新規案件等でJava 実行環境を検討する際に、十分注意してください。
また、当該バージョンを進めない理由として、以下を念頭にお客様にご提案するようにしてください。
・当該バージョンで開発したシステムが近い将来、運用できなくなる。
・サポート終了後のバージョンアップのために余計なコストが必要となる。
・すでにJava 6 SE によるアプリケーションが安定して稼動可能である。
* その他、お客様にとってのベストプラクティスを十分に検討すること
詳細は、書きサイトで・・・
http://java.sun.com/j2se/1.4.2/ja/
また、過去の案件等で、以前のリリースバージョンのJRE、JDK等が必要な際は、
下記のサイトより取得可能です。
http://java.sun.com/products/archive/index.html
PHP４のサポートも今年いっぱいになりますので、いろいろな案件で、
バージョンアップのための修正等が必要になる場合もあるのでしょうか。
気になったので、少しピクシディス フレームワークを見てみましたが、
弊社のフレームワークにおいては、基本的に修正が必要なところはなさそうですね。
* 実行環境の環境変数やVMのチューニング等細かい設定レベルの修正は必要になるかもしれませんが・・・
移行の際に、留意する注意点等が見つかった場合は、別途アナウンスします。
2007年10月25日木曜日
syslog サーバーの設定
syslog サーバーの設定
環境：Linux（Fedora Core）
対象：syslog サービス
最近、韓国からのサーバーアタックが尋常じゃないほど多い（1日平均、30件ぐらい。）ので、韓国経由のパケットはDROP（応答も返さない）する設定にしました。。
それでも、フィイアーウォールには、アタックの検出が発生しています。
そこで、syslog サーバーにlogを保存して、攻撃元を管理することにしました。
1.syslogサービスの設定ファイアーウォール側の設定は、サーバーを指定するだけなので・・・
ここでは、syslogサーバーの設定を記述します。
受けとるだけなら簡単で、以下のコマンドでOKなのですが。# /sbin/syslogd -r設定ファイルに設定する方法を記載しておきます。
これだとsyslog のサービスを毎回再起動しなきゃいけないので、
syslogの設定は、以下のファイルに保存されています。
/etc/sysconfig/syslog
おそらく、インストールした状態の設定が記載されているはずです。
また、サービスはデフォルトで起動状態のはずですので、
このファイルに必要な設定を追記して、再起動すればOKなはずです。
早速、viで開いてみると・・・
# vi /etc/sysconfig/syslog
==========
/etc/sysconfig/syslog 更新前の内容
----------
# Options to syslogd
# -m 0 disables 'MARK' messages.
# -r enables logging from remote machines
# -x disables DNS lookups on messages recieved with -r
# See syslogd(8) for more details
SYSLOGD_OPTIONS="-m 0"
# Options to klogd
# -2 prints all kernel oops messages twice; once for klogd to decode, and
# once for processing with 'ksymoops'
# -x disables all klogd processing of oops messages entirely
# See klogd(8) for more details
KLOGD_OPTIONS="-x"
#
SYSLOG_UMASK=077
# set this to a umask value to use for all log files as in umask(1).
# By default, all permissions are removed for "group" and "other".
==========
となっていました。
で、6行目をコメントアウトして、以下のように修正します。SYSLOGD_OPTIONS="-m 0 -r"
後で見たときに、なんで変更したのかがよく分かるように、
コメント追記するのを忘れずに保存してください。
==========
/etc/sysconfig/syslog 更新済みの内容
----------
# Options to syslogd
# -m 0 disables 'MARK' messages.
# -r enables logging from remote machines
# -x disables DNS lookups on messages recieved with -r
# See syslogd(8) for more details
## デフォルトの状態
##SYSLOGD_OPTIONS="-m 0"
## 起動時の設定をlogサーバーとして設定します。SYSLOGD_OPTIONS="-m 0 -r"
# Options to klogd
# -2 prints all kernel oops messages twice; once for klogd to decode, and
# once for processing with 'ksymoops'
# -x disables all klogd processing of oops messages entirely
# See klogd(8) for more details
KLOGD_OPTIONS="-x"
#
SYSLOG_UMASK=077
# set this to a umask value to use for all log files as in umask(1).
# By default, all permissions are removed for "group" and "other".
==========
これで、OKです。
あとは、以下のコマンドを実行して、syslogサービスを再起動します。
/etc/rc.d/init.d/syslog restart
2.ネットワークの設定
対象となるサーバーにiptablesを設定しているので、
次に、ネットワークの設定が必要になります。
ファイアーウォール等を設定していなければ、以下の設定は必要ありません。
syslog サーバーがlogを受け取るには、UDPの514ポートを使用しますので、
iptables で、対象となるネットワークサーバー、ネットワーク機器からの
UDP経由でのアクセスを許可する必要があります。
iptables の設定は、以下のファイルに記述します。
/etc/sysconfig/iptables
設定内容は、サーバーの設定にあわせたほうがいいと思います。
ここでは、記述例として参考にしてください。
-A Firewall-INPUT -p udp -m udp --dport 512 -j ACCEPT
それぞれのオプションの意味は、iptables --helpを参照してください。
-A [chain] : どのチェインに追加するかを指定します。
-p [proto] : 対象となるプロトコルを設定します。
-m [match] : extension を設定
--dport [num] ： ポート番号の設定
-j [target] : 適用するルールを設定
と、こんな感じです。
これで、iptables を再起動すれば、設定内容を読み込んでくれるはずです。
/etc/rc.d/init.d/iptables restart
## 端末からの確認
以下のコマンドで確認することができますlogger -p info "TEST MESSAGE."
登録:
投稿 (Atom)
