Apacheのconf設定でIPアドレスによるアクセス制限を行うとステータス403が返ります。これをURLの存在を分からなくする為に404として返す必要があったのですが少し難しかったのでメモを残しておきます。
<Directory "/var/www/html">
AllowOverride All
Options -Indexes FollowSymLinks
Order deny,allow
deny from all
allow from ***.***.***.***
</Directory>
#上記で拒否された403を404に書き換え
ErrorDocument 403 /403.html #実態は不要
ErrorDocument 404 /404.html #Not Foundページを用意
<Location ~ "/40(3|4).html">
Order allow,deny
allow from all
</Location>
RewriteEngine on
RewriteRule /403.html - [R=404,L]
ちなみに最近は.htaccessファイルを使用してカジュアルにアクセス制限やURLの書き換えを行うことが多いのですが、FTPアカウントなどで簡単に変更ができてしまうので、セキュリティに関わる設定は静的なconfファイルに記述することをお勧めします。
カテゴリ: 技術メモ
Postfixメールサーバーによる標的型メール攻撃対策
年金機構は当然セキュリティ対策としてウィルスチェックソフトを運用していたと思われますが、標的型メールは独自にカスタマイズされていることが多いのでウィルスパターンをすり抜けて検知されないことがあるようです。
今回のようにウィルスチェックを通過してしまう可能性のある標的型メールを水際で防ぐために、Postfixメールサーバーの設定だけで比較的簡単にできる対策を4つまとめました。
(1) 送・受信容量制限を行う
(2) 偽証の元になる差出人名をフィルタして元のメアドのみ表示させる
(3) 本文内のURLをフィルタリングして非リンク化
(4) 添付ファイルの送・受信を禁止する
具体的な設定方法はこちらになりますが、実用レベルでは未検証ですので各自の責任においてお試しください。
(1) 送・受信容量制限を行う
ウィルスソフトを送りつけられるリスクを軽減するために必要最小限の容量に制限します。また盗まれた情報を外部に大量送信することを防ぐ効果もあります。
a. /etc/postfix/main.cfを編集
以下の設定を追加
------------------------------------------
message_size_limit = 102400 ※
------------------------------------------
※単位はバイト数になりますが、通常のテキストメールのやり取りであれば100k程度で済むのでは?デフォルトでは10MByteに設定されています。
b. サービスの再起動
# service postfix reload
(2) 成りすました差出人名をフィルタして元のメアドのみ表示させる
差出人名は容易に成りすましが可能で気が付きにくいので、メールソフトがメールアドレスを直接表示するようにフィルタリング処理を行います。
From: 藤本 信 <jt85do34903h7@yahoo.com>
↓
From: jt85do34903h7@yahoo.com
a. /etc/postfix/main.cfを編集
メールのヘッダ部分をチェックする設定ファイルを記述
------------------------------------------
header_checks = regexp:/etc/postfix/header_checks.regexp
------------------------------------------
b. /etc/postfix/header_checks.regexpを編集
------------------------------------------
/(^From: ).*<(.*)>/ REPLACE $1$2
------------------------------------------
c. サービスの再起動
# service postfix reload
(3) 本文内のURLをフィルタリングして非リンク化
メール本文内にあるURLをうかつにクリックしないように非リンク化させます。
http://www.yahoo.jp → ttp://www.yahoo.co.jp
https://www.yahoo.jp → ttps://www.yahoo.co.jp
また注意を促す文字列を挿入することもできます。
https://www.yahoo.jp → [クリック注意]https://www.yahoo.co.jp
a. /etc/postfix/main.cfを編集
メールの本文をチェックする設定ファイルを記述
------------------------------------------
body_checks = regexp:/etc/postfix/body_checks.regexp
------------------------------------------
b. /etc/postfix/body_checks.regexpを編集
------------------------------------------
/^(.*)http:(.*)/ REPLACE ${1}ttp:${2}
/^(.*)https:(.*)/ REPLACE ${1}ttps:${2}
------------------------------------------
※やや甘いので改良の余地ありです
c. サービスの再起動
# service postfix reload
(4) 添付ファイルの送・受信を禁止する
業務やサービス運営に支障が無ければ特定の添付ファイルを除外することも可能です。
拡張子のタイプを判別して除外する場合
a. /etc/postfix/header_checks.regexpを編集(複数行の設定も可能)
------------------------------------------
/name=\".*\.(exe|vbs|pif|sh|com|bat|scr|dll|wsh|cab|inf|ins|hlp|hta|js|vb|lnk|cmd|chm|cpl|msi|wsf|reg|vbe|wsc )"/ REJECT
------------------------------------------
※ファイル名に日本語が含まれていた場合に検知できるか未確認です
b. サービスの再起動
# service postfix reload
ロードバランサの導入メリットについて
最近いわゆるクラウドサービスで標準で使えるロードバランサの仕様を調べたら、ちょっとビジネス要件を満たせない仕様だったので、あらためて一般的なロードバランサ製品が実装している機能を整理してみました。
(1) 様々な指標でサーバの重みづけが設定できる
トラフィック、コネクション数、ロードアベレージなどを検知し動的に任意の配分が可能です。負荷以外にもラウンドロビン形式(巡回)での分散も可能です。
(2) サーバのヘルスチェック機能
サーバの様々な障害を検知して故障と判断したら自動的にトラフィックを流さないようにします。また一方のサーバの障害検知をトリガーとして待機サーバにトラフィックを切り替えるホットスペア機能などもあります。
(3) セッション維持機能
cookieやアクセス元のIPアドレスを使用してショッピングカートやユーザ認証状態が維持されるように通信中のサーバを保持し続ける機能があります。
(4) L7機能によってURL判別などができる
通信内容を判別してサーバの振り分けなどを行う機能です。例えばURLに/shop/という文字列があったらショップ専用のサーバにトラフィックを振り分けたりできます。
(5) HTTPS通信の際にアクセス元のソースIPアドレスが判別出来る
Spoof機能がないロードバランサではHTTPS通信時のソースIPアドレスが検知できず、ロードバランサのIPとなってしますので、アクセス元制限やログ解析、調査などに支障があります。
BIND9によるダイナミックDNS構築メモ
ダイナミックDNS(以下DDNS)とは動的にゾーン情報のIPアドレス等を書き換えることが出来るDNSの仕組みです。例えば固定IPアドレスを持たない家庭用ネットワークに一時的にホスト名を割り当てて外部との通信を手助けしたり、CDNサービスの負荷分散に利用されています。
また機器障害が発生した際の可用性を担保する仕組みとして、通常はロードバランサー等のヘルスチェック機能&切替機能を利用しますが、構成が複雑になり費用もかかるため、DDNSと監視システム等を組み合わせて障害発生時速やかに機器を切り替えてクライアントへの影響を最小限にするなどの応用も可能です。
BIND9にはDDNSの機能が組み込まれていますので、比較的簡単な設定で利用できます。
以下に設定方法を説明します(既に通常のDNS設定が済んでいることを前提としてます)。
- named.confの設定
allow-update{}にゾーン情報の更新を許可するクライアント(ネットワーク)を設定します。
allow-updateはDDNSを使用するゾーンのみゾーン宣言の中に記述します。
プライマリDNSのゾーン宣言部に
allow-update{ [更新許可クライアント]; };
notify yes;
also-notify { [セカンダリDNS]; };
allow-transfer { [セカンダリDNS]; };
を追加します。
セカンダリDNSのゾーン宣言部には
allow-update{ [プライマリDNS]; };
を追加します。
これでプライマリDNSで更新されたゾーン情報がセカンダリDNSに同期されます。
プライマリDNS named.conf 修正箇所
ゾーン情報
zone "ddzone.shinkaku" {
type master;
file "ddzone.shinkaku.zone";
allow-update{ [更新許可クライアント]; }; #ゾーン情報の更新許可クライアント
notify yes; #ゾーン情報の更新通知を送る
also-notify { [セカンダリDNS]; }; #ゾーン情報の更新通知先
allow-transfer { [セカンダリDNS]; }; #ゾーン転送を許可
};
セカンダリDNS named.conf 修正箇所
#ゾーン情報
zone "ddzone.shinkaku" {
type slave;
masters { [プライマリDNS]; };
file "slaves/ddzone.shinkaku.zone";
allow-update{ [プライマリDNS]; }; #ゾーン情報の更新を許可
}; - ゾーン情報ファイル、ディレクトリのパーミッション設定
ゾーン情報ファイルは、namedユーザーが書込みができるようにパーミッションを変更します。また差分更新のための *.jnlファイル が生成されるので、ディレクトリも同様にパーミッションを変更します。 - ゾーン情報ファイルを手修正する場合の注意点
DDNSはゾーン情報ファイルと *.jnlファイルの組で構成されています。したがって、ゾーン情報ファイルを手書き更新してnamedを再起動しただけではエラーが発生しますので、必ず *.jnlファイルを削除してからnamedを再起動します。 - セカンダリDNSへの変更情報の即時反映について補足
プライマリDNSが変更されてもセカンダリDNSへの反映が遅れると不都合がありますので
セカンダリDNSのゾーン宣言部にも必ず
allow-update{ [プライマリDNS]; };
を設定します。
設定していない場合はプライマリDNSからのゾーン情報更新通知(notify)が送られてもゾーン情報は即時に更新されません。 - 動作確認方法
ゾーン情報の更新にはnspdateコマンドを使用します。
以下が実行例になります。
-----------------------------------------------------------
[root]# nsupdate
> server ns.ddzone.shinkaku
DNSレコードの登録
> update add dev.ddzone.shinkaku 3600 IN A 192.168.1.101
> send
DNSレコードの削除
> update delete dev.ddzone.shinkaku In A 192.168.1.101
> send
デバッグ時は-dオプションを使用します。
nsupdateで更新したゾーン情報は即座にDNSに反映されますが、更新情報は *.jnl ファイルに差分として保存され、時間を置いてからゾーン情報ファイルに反映されます。
この時、シリアルは自動的にカウントアップされます。 - クライアントのリゾルバキャッシュについて
DNSのゾーン情報が更新されても一般的なクライアントPCにはホスト名とIPアドレスの情報を一定時間キャッシュする機能があることを意識する必要があります。したがって、閉じたネットワークシステムを構成する場合はこの設定も最適化することをお勧めします。
検証はWindows7でしか行っておりませんが、Microsoftのサポートに新しい情報はありませんので、おそらくWindows8でも大丈夫かと思います。なおCentOS等のUNIX系OSにも同様のキャッシュ機能があります。
Windows7のDNSリゾルバキャッシュについて
-------------------------------------------------------------------------------
Windows7ではDNSへの問い合わせ結果がキャッシュされ、頻繁にDNSへ問合せしないしくみになっています。DNSのゾーン情報を更新しても、クライアントPCに反映されない場合は、DNSリゾルバキャッシュのエントリを消去します。一度問い合わせたDNS情報を、再度問い合わせるまでのDNSリゾルバキャッシュの有効時間は、DNSのゾーン情報におけるいわゆるTTLが設定時間になります。
-------------------------------------------------------------------------------
【DNSリゾルバキャッシュを確認する】
DNSリゾルバキャッシュの内容を確認したい場合は、
コマンド プロンプトで
ipconfig /displaydns
と入力する。
【DNSリゾルバキャッシュのエントリを消去する】
一時的にDNSリゾルバキャッシュを消去したい場合は、
コマンド プロンプトで
ipconfig /flushdns
と入力する。
【DNSリゾルバキャッシュ機能自体を無効にする方法】
「コントロールパネル」⇒「管理ツール」⇒「サービス」からDNS Client(DNS クライアント サービス)を停止します。
【DNSリゾルバキャッシュの有効時間を任意に設定する】
レジストリキー(MaxCacheTtl と MaxNegativeCacheTtl) を設定すれば、DNSリゾルバキャッシュの有効時間は MaxCacheTtl に設定した秒数になります。
レジストリ
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNSCache\Parameters
MaxCacheTtl → リゾルバキャッシュ(秒)
MaxNegativeCacheTtl → 否定応答のキャッシュ(秒)
(参考)
Windows XP および Windows Server 2003 でクライアント側の DNS リゾルバ
キャッシュ を無効にする方法
http://support.microsoft.com/kb/318803/ja
※WindowsXP での設定方法ですが、Windows7 でも有効です。
.htaccessで機種判別する方法
マルチプラットホームのサイトを構築する場合、PC版とスマホ版あるいはガラケー版のコンテンツを自動判別する必要があります。
機種の判別にはブラウザの情報すなわちユーザエージェント(User_agent)を用いるのが一般的です。PHPなどのプログラムでユーザエージェントと文字列をマッチングさせ、機種に適したディレクトリに遷移させたり、コンテンツを読み込んだりします。
プログラムで機種判別する以外にはApacheのmod_rewriteモジュールを用いる方法があります。mod_rewriteはApache設定の一部として.htaccessファイルに記述することが可能で、格納したディレクトリ配下にすべて適用されますので、機種判別用プログラムをインクルードする必要がなく、静的なHTMLコンテンツなどでも有効です。
以下に設定例を示します。
-----------------------------------
## mod_rewriteを使用することを宣言
RewriteEngine On
## ユーザエージェントに含まれる文字列を判別して変数にタイプをセットします
# ガラケーと判断
SetEnvIf User-Agent "DoCoMo" TYPE=m
SetEnvIf User-Agent "UP.Brower" TYPE=m
SetEnvIf User-Agent "KDDI-" TYPE=m
SetEnvIf User-Agent "J-PHONE" TYPE=m
SetEnvIf User-Agent "Vodafone" TYPE=m
SetEnvIf User-Agent "SoftBank" TYPE=m
SetEnvIf User-Agent "emobile" TYPE=m
SetEnvIf User-Agent "WILLCOM" TYPE=m
SetEnvIf User-Agent "DDIPOCKET" TYPE=m
# スマートフォンと判断
SetEnvIf User-Agent "BlackBerry" TYPE=s
SetEnvIf User-Agent "Windows Phone" TYPE=s
SetEnvIf User-Agent "iPhone" TYPE=s
SetEnvIf User-Agent "iPod" TYPE=s
SetEnvIf User-Agent "iPad" TYPE=s
SetEnvIf User-Agent "Android" TYPE=s
# マッチしなかった場合はリダイレクトせずPCとして扱うことにします
## リダイレクト処理
# ガラケー版
# 条件1:リダイレクト先は除外 かつ
# 条件2:TYPE変数がmだったら
# /m/にリダイレクト
RewriteCond %{REQUEST_URI} !^/m/*
RewriteCond %{ENV:TYPE} ^m$
RewriteRule ^(.*)$ /m/ [R,L]
# スマホ版その1
# 条件1:リダイレクト先は除外 かつ
# 条件2:TYPE変数がsだったら
# /s/にリダイレクト
RewriteCond %{REQUEST_URI} !^/s/*
RewriteCond %{ENV:TYPE} ^s$
RewriteRule ^(.*)$ /s/ [R,L]
# スマホ版その2
# 条件1:リダイレクト先は除外 かつ
# 条件2:TYPE変数がsだったら
# URLはそのままで/s/にリダイレクト
RewriteCond %{REQUEST_URI} !^/s/*
RewriteCond %{ENV:TYPE} ^s$
RewriteRule ^(.*)$ /s/ [L]
#スマホ版その3
# 条件1:リダイレクト先は除外 かつ
# 条件2:TYPE変数がsだったら
# /s/"元の/以下"にリダイレクト
RewriteCond %{REQUEST_URI} !^/s/*
RewriteCond %{ENV:TYPE} ^s$
RewriteRule ^(.*)$ /s/$1 [R,L]
-----------------------------------
ApacheのアクセスログにユーザIDを記録する方法
(当社メンバーの検証記事です)
Apacheのアクセスログフォーマットを改良することで会員サイトのユーザIDをログに記録することが可能です。アクセスログにユーザIDが記録されていればCookieベースより安定的にユーザ単位でアクセス履歴が追跡しやすくなります。
(1)Apache のアクセスログの設定を変更
/etc/httpd/conf/http.conf
----------------------------------------
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
----------------------------------------
↓↓↓
----------------------------------------
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %{MEMBER_ID}e" combined
----------------------------------------
※変更後にApacheを再起動します。
(2)ユーザIDを記録したいページで環境変数にユーザIDを代入
phpの場合、以下の記述を追加します。
----------------------------------------
<?php
// 環境変数に値を書き込み
apache_setenv("MEMBER_ID","MyID012345");
?>
----------------------------------------
※ここではユーザIDを直接書いていますが、実際に導入する場合は、セッション変数などに格納したユーザIDを代入します。
アクセスログの末尾にユーザIDが追加されます。
-- 変更前 --------------------------------------
192.168.1.32 - - [18/Jun/2014:14:26:42 +0900] "GET / HTTP/1.1" 200 33215
"-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like
Gecko) Chrome/35.0.1916.153 Safari/537.36"
----------------------------------------
↓↓↓
-- 変更後 --------------------------------------
192.168.1.32 - - [18/Jun/2014:14:26:42 +0900] "GET / HTTP/1.1" 200 33215
"-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like
Gecko) Chrome/35.0.1916.153 Safari/537.36" MyID012345
----------------------------------------
ロードバランサ配下のサーバ間通信についてメモ(追記あり)
例
--FW---LB---SW--+--WebServer1(192.168.150.11) ↑
+--WebServer2(192.168.150.12) この間でFQDNによる
+--WebServer3(192.168.150.13) 通信が出来ない
+--WebServer4(192.168.150.14) ↓
LB
ext: 210.*.*.123
lan: 192.168.150.1
FQDN
www.shinkaku.jp 210.*.*.123
WebServer間でFQDNによるHTTPリクエストを送る場合、宛先が一旦名前解決されてグローバルIPアドレスとなりますので直近のスイッチ経由でパケットは送られません。そしてロードバランサはExternalのインターフェースからWANに向かってしかパケットを送りませんのでLAN側からのリクエストには応答できません。
そこでサーバサイドから見たネットワークに少しおまじないを加えてあげます。
(1) まずhostsにローカルIPアドレスのFQDNを記載します
# vi /etc/hosts
------------------------
192.168.150.11 www.shinkaku.jp
192.168.150.12 www.shinkaku.jp
192.168.150.13 www.shinkaku.jp
192.168.150.14 www.shinkaku.jp
------------------------
これだけではまだhostsが使用されません
(2) 名前解決ルールを設定
# vi /etc/host.conf
------------------------
order hosts,bind
multi on
------------------------
1行目:名前解決にhostsファイルが優先されます。
2行目:同じFQDNが複数あった場合、複数のIPアドレスを返す設定です。
これらの設定でLBを介さずにサーバ間通信が出来るようになりますが、LBが持つ高度なヘルスチェックやフェイルオーバーならびにL7機能の恩恵を受けることはできません。
(追記:2014.4.30)
よく考えたらサーバでbind(named)を動かしてリゾルバDNSとしてローカルを参照するようにすれば同じようなことが出来そうですね。何と言ってもDNSラウンドロビンが使えるのである程度の負荷分散にもなります。
ローカルサーバからプロバイダのSMTP経由でメールを送る方法メモ
そのような場合はプロバイダから割与えられているアカウントを使用し、サブミッションポート(587)でSMTP認証を行った上で送信する方法があります。これはパソコンのメーラーからメールを送るプロセスと基本的に同じです。
以下はCentOSのPostfixにて設定を行った際の手順メモです。
# cd /etc/postfix
# vi main.cf
変更
#mydomain = domain.tld
mydomain = shinkaku.jp
変更
#myorigin = $mydomain
myorigin = $mydomain
変更
inet_interfaces = localhost
inet_interfaces = all
追加
# リレーホストのための設定
relayhost = [bzmail.plala.or.jp]:587
# リレーホスト先のbzmail.plala.or.jpのSMTP-AUTHのための設定
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/smtp_auth_conf
smtp_sasl_mechanism_filter = CRAM-MD5
sasl認証ファイルの作成
# vi smtp_auth_conf
bzmail.plala.or.jp UserID:password
sasl認証ファイルのハッシュ化
# postmap smtp_auth_conf
パッケージの追加
# yum install cyrus-sasl-md5
postfixの再起動
# service postfix restart
送信テスト
# /usr/lib/sendmail -t email
Subject: test
test
[Ctrl+d]
これでメールが届けば完了ですが、いくつかのドメインや端末宛てに送信テストすることをおススメします。
ポリシーベースルーティングの設定について
以下のようなネットワーク構成を例にCentOSの設定方法を説明します。
それぞれのNICには異なるサブネットの固定IPアドレスが設定されていて、デフォルトゲートウェイが未設定になっていることを前提とします。またL3スイッチにより各VLAN間のルーティングが設定されていることも前提とします。
1. HOST Aにスタティックルーティングを追加
# vi /etc/sysconfig/network-scripts/route-eth0
192.168.102.0/24 via 192.168.101.1 dev eth0
192.168.103.0/24 via 192.168.101.1 dev eth0
# service network restart
# route
------------
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.102.0 192.168.101.1 255.255.255.0 UG 0 0 0 eth0
192.168.101.0 * 255.255.255.0 U 0 0 0 eth0
192.168.103.0 192.168.101.1 255.255.255.0 UG 0 0 0 eth0
ink-local * 255.255.0.0 U 1002 0 0 eth0
------------
2. HOST BにHOST Aへの経路(スタティックルーティング)を追加
# vi /etc/sysconfig/network-scripts/route-eth0
192.168.101.0/24 via 192.168.102.1 dev eth0
# vi /etc/sysconfig/network-scripts/route-eth1
192.168.101.0/24 via 192.168.103.1 dev eth1
# service network restart
経路に問題がある旨のメッセージが出ます。宛先のネットワークが重複しているので一方の経路定義しか有効になりません。
ping結果
HOST A → HOST B (192.168.102.20) OK
HOST A → HOST B (192.168.103.20) NG
3. ルーティングルールの設定
いろいろ調べた結果、ルーティングに条件設定を行う方法が分かりましたので、以下にHOST Bへの設定手順を説明します。
経路テーブルIDの登録
# vi /etc/iproute2/rt_tables
以下の行を追加
200 rule102
201 rule103
ルールファイルの作成
# vi /etc/sysconfig/network-scripts/rule-eth0
from 192.168.102.20 table rule102
「192.168.102.20からの要求があったらrule102に従いなさい」というルールを定義
# vi /etc/sysconfig/network-scripts/rule-eth1
from 192.168.103.20 table rule103
「192.168.103.20からの要求があったらrule103に従いなさい」というルールを定義
ルーティングファイルの修正
# vi /etc/sysconfig/network-scripts/route-eth0
192.168.101.0/24 dev eth0 src 192.168.102.20 table rule102 ...(1)
default via 192.168.102.1 table rule102 ...(2)
(1) 「192.168.101.0/24ゾーンを参照する元ホストがeth0の192.168.102.20だったらrule102に従いなさい」というポリシーを定義
(2) 「rule102のデフォルトゲートウェイは192.168.102.1ですよ」という意味
# vi /etc/sysconfig/network-scripts/route-eth1
192.168.101.0/24 dev eth1 src 192.168.103.20 table rule103
default via 192.168.103.1 table rule103
ネットワークの再起動
# service network restart
エラーが出なければ矛盾は解消されたはずです。
双方のサーバからそれぞれのIPアドレスに対してpingが通れば完了です。
4. まとめ
通常のルーティングテーブルにはルール設定情報は反映されません
# route
------------
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.102.0 * 255.255.255.0 U 0 0 0 eth0
192.168.103.0 * 255.255.255.0 U 0 0 0 eth1
ink-local * 255.255.0.0 U 1002 0 0 eth0
ink-local * 255.255.0.0 U 1003 0 0 eth1
------------
ルーティングルールの確認方法はこちらになります
# ip rule
0: from all lookup local
32764: from 192.168.102.31 lookup rule102
32765: from 192.168.103.31 lookup rule103
32766: from all lookup main
32767: from all lookup default
# ip route show rule102
192.168.101.0/24 dev eth0 scope link src 192.168.102.20
default via 192.168.102.1 dev eth0
# ip route show rule103
192.168.101.0/24 dev eth1 scope link src 192.168.103.20
default via 192.168.103.1 dev eth1
HDE Anti-Virus Realtime Scanインストールメモ
最近はLinux系サーバ自身にもセキュリティソフト導入が要件になっている案件が増えています。以下はサーバに送信されるファイルをリアルタイムにスキャンを行うHDE社のAnti-Virus Realtime ScanというLinux系サーバソフトのインストール時のメモとなります。
【要注意2014.1.29】
現在CentOSの最新カーネルでこのソフトを使用するとOSがクラッシュする不具合が発生しているようです。したがってカーネルをアップデートしないようにするか/etc/grub.confの設定でデフォルトで古いカーネルを立ち上げるようにしておく必要があります(CentOS 2.6.32-358.el6.x86_64を起動するようにする)
CentOS 6.5相当のカーネルでご利用の場合、システム動作に問題が起る問題について(2014/1/21)
- 評価版のダウンロード
http://www.hde.co.jp/hav/demo/ - フォームに必要情報を入力
- 届いたメールのURLをクリック
- ダウンロード(PCローカルに保存)
- パッケージをサーバに転送(自分のhomeなど)
- マニュアルを入手
http://www.hde.co.jp/hav/demo/ - 中身の確認
$ tar tvf HDE_Anti-Virus_10.0-3R10_20130108180758.tar - 展開
$ tar xvf HDE_Anti-Virus_10.0-3R10_20130108180758.tar - とりあえずインストーラを起動してみる
$ su
# cd HDE_Anti-Virus_10.0
# ./av-install
エラー: gd は lcserver-php53 に必要とされています。
エラー: libpng は lcserver-php53 に必要とされています。
エラー: libxslt は lcserver-php53 に必要とされています。
エラー: apr は lcserver-php53 に必要とされています。
エラー: apr-util は lcserver-php53 に必要とされています。
エラー: perl は HDE Anti-Virus に必要とされています。
エラー: wget は HDE Anti-Virus に必要とされています。
エラー: gcc は HDE Anti-Virus に必要とされています。
エラー: patch は HDE Anti-Virus に必要とされています。
エラー: libgcc.i686 は HDE Anti-Virus に必要とされています。
エラー: glibc.i686 は HDE Anti-Virus に必要とされています。
エラー: pam.i686 は HDE Anti-Virus に必要とされています。
エラー: zlib.i686 は HDE Anti-Virus に必要とされています。
ここで要求されるパッケージはOSインストール時に選択した条件により異なります。 - 不足パッケージの追加(OSのインストール方法で不足パッケージが異なります)
yum install gd
yum install libpng (上のパッケージに含む?)
yum install libxslt
yum install apr
yum install apr-util
yum install perl
yum install wget
yum install gcc
yum install patch
yum install libgcc.i686
yum install glibc.i686
yum install pam.i686
yum install zlib.i686 - 再度インストーラ実行
# ./av-install
エラー: kernel-devel-2.6.32-358.el6.x86_64 または kernel-source-2.6.32-358.el6.x86_64 は HDE Anti-Virus に必要とされています。
まだkernel系パッケージが不足している - 不足パッケージの再追加
# yum install kernel-devel-2.6.32-358.el6.x86_64
No package kernel-devel-2.6.32-358.el6.x86_64 available.
Error: Nothing to do
パッケージが無いと言われる - 手動によるrpmの取得(他のMirrorサイトでもOK)
# wget ftp://mirror.switch.ch/pool/1/mirror/scientificlinux/6.4/x86_64/os/Packages/kernel-devel-2.6.32-358.el6.x86_64.rpm - rpmのインストール
# rpm -ivh kernel-devel-2.6.32-358.el6.x86_64.rpm - ホスト名の再定義(ドットが2つ以上含むFQDNにする)
# hostname server1.hoge.local - インストーラの起動(CUIで可能)
# ./av-install
確認[1/4]OK
確認[2/4]
ホスト名 server1.hoge.local (←hostnameと同じもの)
lcadminパスワード *******
言語 ja_JP - 日本語
OK
確認[3/4]OK
完了[4/4]OK - iptable(FW)の設定
16590ポートを解放する(セキュリティ的に限定した方が良い) - HDE管理画面の確認
操作を行うPCのhostsファイルを設定
--------------------------------------------------
123.123.123.123 server1.hoge.local
--------------------------------------------------
以下管理画面URL
https://server1.hoge.local:16590/
ID: lcadmin
PW: ******* - postfixの設定(HDEのメール送信機能を使用する場合)
/etc/postfix/main.cfに以下記述追加
canonical_maps = hash:/etc/postfix/canonical
/etc/postfix/canonicalに以下記述追加(エンベロープFROMを存在しているドメインに書き換え)
root@server1.hoge.local root@hoge.jp
# postmap /etc/postfix/canonical
# service postfix reload - postfixのテスト
# /usr/lib/sendmail fujimoto@hoge.jp
test
test
Ctrl+D
#
メールが届けばOK - 後はマニュアルをご覧ください:-)