管理人のヒトリゴト -もみんぎゅぅ-

続きを読む… »

■主な機能
・Socketを使用したhttp接続のチェック（SSL非対応です）
・http接続時にGETしたソースの１行目の文字列の判定
・スクリプトの二重起動を防ぐ排他処理
・監視対象を複数設定可能
・エラー通知の宛先を複数設定可能

■設置方法

1.HttpdChkのダウンロード

→ダウンロード

2.HttpdChk.plの設定

————————————————————————
01：#!/usr/bin/perl -w
・
・
・
26：my $ScriptDir = ‘/PathTo/HttpdChk’;
28：my $SendMail = ‘/usr/lib/sendmail’;
30：my $MailFrom = ‘from@example.jp’;
32：my $Subject = ‘httpd alert’;
34：my $MaxCount = 3;
36：my $LockTimeout = 20;
38：my $ConnTimeout = 10;
————————————————————————

01行目：perlのパス
26行目：作業ディレクトリ（HttdpChkディレクトリまでのフルパス）
28行目：sendmailまでのパス
30行目：エラー通知の送信者メールアドレス
32行目：エラー通知の件名
34行目：何回エラーが出たらエラー通知を送信するか
36行目：前回の処理が終わっていない場合の待機時間（秒）
38行目：http接続が成功するまでの待機時間（秒）

3.HttpdChk.confの設定

以下のフォーマットに基づいて記述します。
[Host][:Port][/Path] [Space|Tab] [SendEmail1,2,3...] [Space|Tab] [SuccessfulMessage]

[Host]
監視対象ホスト。
[:Port]
監視対象ホストのポート（指定が無い場合は80で接続）。
[/Path]
監視対象ホストのファイル、ディレクトリ。
[Space|Tab]
設定の区切り（半角スペース若しくはタブ）。
[SendEmail1,2,3...]
エラー通知の送信先メールアドレス（複数指定する場合は「,」で区切る）。
[Space|Tab]
設定の区切り（半角スペース若しくはタブ）。
[SuccessfulMessage]
httpd接続に成功した場合にGETしたソースの1行目の文字列。
主に監視対象ホストのhttp接続以外のチェックに使用します。

例）
監視対象ホストにデータベース接続が正しくできるかチェックするスクリプト（dbcheck.cgi）を設置して
www.example.jp/dbcheck.cgi to@example.jp Database connection successful
と設定。

dbcheck.cgiは接続に成功した場合は
print “Content-Type:text/plain\n\n”;
print “Database connection successful\n”;
を出力
dbcheck.cgiは接続に失敗した場合は
print “Content-Type:text/plain\n\n”;
print “エラーメッセージ\n”;
を出力

※詳しくはHttpdChk.conf記載のサンプルをご覧ください。

4.サーバーに設置
HttpdChk.pl[700]/HttpdChk.conf[644]/HttpdChk.res[644]の入ったHttpdChkディレクトをサーバーに設置します。（※[ ]の数字はパーミッション）

最後にHttpdChk.plをcronに追加して完了です。

« 閉じる

続きを読む… »

で、たどり着いた.htaccessの記述が以下のとおりです。

[.htaccess]
-----------------------------------------------------------------------------
<FilesMatch "bbs.*\.cgi$">
        <Limit POST>
                SetEnvIf Request_URI "/hogehoge$" Accept
                SetEnvIf Request_URI "/hogehoge2$" Accept
                Order Deny,Allow
                Deny from all
                Allow from env=Accept
                Allow from 192.168.10.0/24
                #ALLOW_CIDR_LIST_____#
                #_____ALLOW_CIDR_LIST#
        </Limit>
</FilesMatch>
-----------------------------------------------------------------------------

●<FilesMatch “bbs.*\.cgi$”></FilesMatch>
制限の対象となるスクリプトファイル名を記述します。
「.*」は0文字以上の任意の文字列にマッチした場合という意味です。
「$」は最後から検索してという意味になります。
したがって上記はスクリプトファイル名の文字列を最後から検索してbbs***.cgiにマッチした場合は真という条件になります。

複数のスクリプトファイルを対象とする場合は
<FilesMatch “(hoge|hogehoge|hogehogehoge)\.(cgi|php)$”></FilesMatch>
というように指定することもできます。

●<Limit POST></Limit>
POSTのみを制限する指定です。

<Limit GET POST></Limit>
とすればGETとPOSTを制限することができます。

●SetEnvIf Request_URI “/hogehoge$” Accept
レンタル掲示板はPOST時に環境変数PATH_INFOを付与しているのですが、SetEnvIfは環境変数PATH_INFOを参照できないのでREQUEST_URLで代用しています。
したがって上記はREQUEST_URLの文字列を最後から検索して「/hogehoge」にマッチした場合という意味になります。

●Order Deny,Allow
これは拒否をしてから許可するという定義になります。

●Deny from all
一度すべてを拒否するという意味です。

●Allow from env=Accept
これは「SetEnvIf Request_URI “/hogehoge$” Accept」の条件にマッチした場合は許可するという意味です。

●Allow from 192.168.10.0/24
これは単純にLAN内（私用）からのPOSTは許可するという意味です。

●#ALLOW_CIDR_LIST_____#・・・・・#_____ALLOW_CIDR_LIST#
これはこの後解説する国内ホスト一覧の自動取得スクリプト（getApnicCidr2HTA.pl）が国内ホスト一覧（CIDR方式）を記述する場所をスクリプトに示すための記述です。

■上記.htaccessを制限したいディレクトリ配下に設置します。

■次に国内ホスト一覧の自動取得を行うスクリプトを用意します。
> wget http://cmf.ohtanz.com/download/getApnicCidr2HTA.txt
> mv getApnicCidr2HTA.txt getApnicCidr2HTA.pl
> chmod 755 getApnicCidr2HTA.pl

※ちなみにPostfixのcidr_tableを自動更新、FTPに対する不正なアクセスを遮断に次ぐgetApnicCidrシリーズ第3段です。

■ダウンロードしたgetApnicCidr2HTA.plの下記の部分を編集します。

[getApnicCidr2HTA.pl]
-----------------------------------------------------------------------------
1：#!/usr/bin/perl
5：my @HTACCESS_LIST = ('/home/hoge/.htaccess','/home/hogehoge/.htaccess');
-----------------------------------------------------------------------------

5行目の@HTACCESS_LISTは対象となる.htaccessまでのパスを記述します。

※このスクリプトは.htaccess内の#ALLOW_CIDR_LIST_____#・・・・・#_____ALLOW_CIDR_LIST#の間のみを更新するので、それ以外の個所は自由にカスタマイズしても問題ありません。

■編集が終わったらgetApnicCidr2HTA.plを1度手動で実行します。
> perl getApnicCidr2HTA.pl

※.htaccessを開いて#ALLOW_CIDR_LIST_____#・・・・・#_____ALLOW_CIDR_LIST#間にホスト一覧が記述されていることを確認して下さい。

後はgetApnicCidr2HTA.plをcronに追加して終了です。

« 閉じる

続きを読む… »

実害はないから別にいいんですが、このクソ暑い中そんなログを見てしまうとついついイラッ！っとなってしまうもので、こりゃ〜そろそろちゃんと対策しといたほうが精神衛生上いいんじゃなかろうかと思い、
以前作ったPostfix用のcidr_tableを自動更新するスクリプトをちょこっと改良して、iptablesで21番ポートを国内ホストからのみアクセスできるようにしてみました。

■導入方法
> wget http://cmf.ohtanz.com/download/getApnicCidr2FTP.txt
> mv getApnicCidr2FTP.txt /usr/local/bin/getApnicCidr2FTP.pl
> chmod 700 getApnicCidr2FTP.pl
> vi getApnicCidr2FTP.pl

————————————————————————-
1:#!/usr/bin/perl
8:my @ACPT_LIST = (’127.0.0.1′,’192.168.1.0/24′);
9:my %DROP_LIST = ();
————————————————————————-

1行目：Perlのパス
8行目：LAN内や海外の特定ホスト等からFTPアクセスを許可するためのホスト
9行目：FTP以外でアクセスを拒否したい場合に使用

例：%DROP_LIST = (’192.168.4.1′=>’25′,’192.168.3.0/24′=>’110′);
‘IP（CIDRも可）’=>’ポート’
というように記述していきます。

あとはgetApnicCidr2FTP.plをCRONに追加して終わりです。

« 閉じる

続きを読む… »

それともうひとつpostfixのスパムメール対策についてもコメントがありました。

「regexに対してpostmapは不要ですよ」

Σｒ(‘Д‘ｎ）

PostfixのページQ&Aより
————————–
Postfix は 指定されたテキストファイル (regexp:/etc/postfix/regexp-file と 指定されている場合は /etc/postfix/regexp-file.db ではなく /etc/postfix/regexp-file) を直接読みます。
————————–

いやはやお恥ずかしい限りです。
普通に考えればわかりそうなものなのに、正規表現な評価をするのになんでDBM（DB)化するんだと（ｒｙ

たぶん他のaliasesやvirtualとかをnewaliases（postmap）してた流れでなにも考えずにやっちゃってたんだと思いますorz

どんまいオレ！

それとMonkey Tracksさん曰くpostfixのスパムメール対策を参考に設定した結果Googleからのメールが弾かれてしまったそうで、どの段階で弾かれたのかはわかりませんが、もしsmtpd_client_restrictionsで引っ掛かったのであれば、client_cidrに以下を追加すればGoogleからは受取れるようになると思います。

———————–
#Google network
72.14.192.0/18 OK
64.233.160.0/19 OK
209.85.128.0/17 OK
216.239.32.0/19 OK
66.102.0.0/20 OK
66.249.64.0/19 OK
———————–

ここを見るかはわかりませんが、ご指摘頂いたお礼代わりに。（お礼というほど大したことでもありませんが）

« 閉じる

続きを読む… »

APNICのIPv4 rangesは日々変更されているので、なんとか自動化したいなぁ〜と思っていたのですが、自動化するにはＪＰＮＩＣの管理しているＩＰアドレスを捨てないといけません。
（※ＡＰＮＩＣとＪＰＮＩＣで重複しているものを最後は目視で確認しないとＷａｒｎｉｎｇがでまくって大変なことになるからです。）

そこでＡＰＮＩＣとＪＰＮＩＣそれぞれが管理している日本のＩＰアドレスはどのくらいあるのかざっと見てみたところ、9割以上は重複していたので、この際だからＪＰＮＩＣは捨てよう！と決めたわけです。

最初に私が作成したipv4Jp.zipに同封されているclient_cidrはＡＰＮＩＣとＪＰＮＩＣをまとめたものなのですが、ＡＰＮＩＣのみで作成したものとの差があまり無かったのです。

東京大学のＩＰはＪＰＮＩＣのみでしか管理されていないようですが、client_cidrの定義はＲＥＪＥＣＴではなくＯＫなので仮に漏れたホストがあっても、逆引き設定等が正しく行われていれば無問題な訳で、且つ450で再送要求しているのでまぁ〜大丈夫なんじゃなかろうかという自宅サーバーならではの強気設定です(゜Д゜)

すでに導入して2週間経っているので大丈夫でしょう！・・・たぶん・・・(゜Д゜)

で、自動更新するにあたって、私は今までaccessテーブルを更新したら毎回Postfixをreloadしていたのですが、Postfix 検索テーブルの概要を読むと、reloadすべきなのかそうでないのかが、どうもはっきりしません。

で、試しに書いてあるとおり
> postmap access.in
> mv access.in.db access.db
を実行してみたらmaillogに大量のWarningがでましたよ！？(゜Д゜;)

（postmapのマニュアルより引用）
——————————————————————————
テーブルの更新中は、シグナル配送は遅延され、検索に来たプログラムを驚 か
せないために、排他的 Advisory ロックがテーブル全体にかけられます。
——————————————————————————

ということなので、cidr_tableの自動更新スクリプトはclient_cidrのバックアップをとってそのまま上書きしてpotmapを実行しています。

cidr_tableの自動更新をしてみたいという方は既にPostfixのスパムメール対策(排除率は99.975%だった)の方も更新しているので、一度読んでみてください。

« 閉じる

続きを読む… »

なんでこんな話をしたかと言いますと、昨日の21時頃に携帯にサーバーダウン通知がきたのです。

幸い自宅にいたのでサーバーにログインしてチェックをしてみたのですが、特にサーバーに異常はなく単純に一時的なアクセス過多かな〜？っと思って放置していたのですが、再び通知が・・・

まったく原因が分からなかったので、プロバイダのWEBサーバーにTelnetでログインして手動でWgetを実行してみました。
すると「Host not found」と出たので、これはもしや！と思い、whoisでohtanz.comを調べてみたら予想通りドメインの有効期限が5月6日で切れて凍結されてましたorz

慌てて更新手続き＆振込みを済ませて、今朝方10時頃に更新完了通知が着て凍結も既に解除されてました・・・めでたしめでたし・・・(；´∀｀)

にしても更新手続き＆振込みは昨日の23時過ぎに行ったのですが、今日の10時には更新完了というドメイン管理会社の仕事に早さには驚かされました。
ohtanz.comドメインはフイズというところで管理してもらっているのですが、どうやらここはYesnic（韓国ドメインとか管理してる団体）直営のホスティング会社？？？らしく、若干日本語がおかしいもののドメインのwhoisデータベースの反映とかがやけに早いように感じます。

決して安いといえるホスティング会社ではありませんが、気になる方は使ってみてください。

で、なんでこんな自体が起こってしまったのかというと、更新期限の通知メールを自宅サーバーのメールアカウントにしていたのですが、「reject_unknown_sender_domain」に引っ掛かってしまってREJECTされてしまい、しかも私がそのログを見落としてしまっていたのです。

「reject_unknown_sender_domain」ってことはエンベロープのMAIL FROMの@以下のドメインが正引きできないわけで、ドメイン管理会社のメールがそんなんでいいのか！！と思いつつも、今回は私のログの見落としがいけないので若干(´・ω・｀) してます。

これからは気をつけますorz

« 閉じる

続きを読む… »

日本語のスパムメールもほとんどが中国、韓国だったりします。恐らく国内から来るスパムメールは全体の1%に満たないと思います。

そこでsmtpd_client_restrictions部分にcidr_tableを追加して、国内のIPだった場合は以降のsmtpd_client_restrictionsの評価はパスして、海外のIPだった場合のみ以降のsmtpd_client_restrictionsの評価を継続するという手法を取り入れてみることにしました。

現在のmain.cfの主な設定は以下のとおりです。

#strict_rfc821_envelopes = yes
disable_vrfy_command = yes

smtpd_client_restrictions =
  permit_mynetworks
  check_client_access btree:/etc/mail/dracd
  check_client_access cidr:/etc/postfix/client_cidr
  reject_unknown_client
  check_client_access regexp:/etc/postfix/client_restrictions
  reject_unlisted_recipient
  reject_unauth_destination

smtpd_helo_required = yes

smtpd_sender_restrictions =
  permit_mynetworks
  check_sender_access regexp:/etc/postfix/sender_restrictions
  reject_unknown_sender_domain
  reject_non_fqdn_sender
  reject_unverified_sender

#smtpd_helo_restrictions =
#  permit_mynetworks
#  reject_invalid_hostname
#  reject_non_fqdn_hostname
#  reject_unknown_hostname

smtpd_recipient_restrictions =
  permit_mynetworks
  check_client_access btree:/etc/mail/dracd
  reject_unauth_destination

check_client_access cidr:/etc/postfix/client_cidr部分がcidr_tableによるフィルタリングです。

予めclient_cidrを/etc/postfixに移動してpostmap /etc/postfix/client_cidrを実行しておきます。

またRFCで必須としていない逆引き設定ですが、今回海外のIPに限定できるので、reject_unknown_clientも追加しました。

それと非スパムなメールにエンベロープ内のフォーマット間違いが意外と多いので、strict_rfc821_envelopesとsmtpd_helo_restrictionsはコメントしました。

smtpd_client_restrictions部分について流れを説明すると、

permit_mynetworks#自ホストからの接続はOK
check_client_access btree:/etc/mail/dracd#pop before smtpで認証済みホストからの接続はOK
check_client_access cidr:/etc/postfix/client_cidr#国内からの接続はOK
———ここまででOKなら以下は評価しない——–
以下省略

という条件になります。

smtpd_sender_restrictions、smtpd_recipient_restrictions等は別途評価されます。

今回のフィルタリングの特徴は国内からの接続には優しく海外からの接続には厳しくってところでしょうか、言い換えるなら国内からのスパムが多いサーバーでは返って逆効果だということです。

また私が作成した国内のIPを集めたclient_cidrですが、正直すべての国内のIPを網羅しているのかわかりませんし海外のIPが混ざっているかもしれません、ただclient_cidrはマッチしたIPをOKとしているだけなので、仮に国内のIPが欠如していてもcheck_client_access cidr:/etc/postfix/client_cidr以下の評価対象となるだけですので、差ほどリスキーな状況になることはありません。（海外のIPならその逆になるだけ）

それとこれを導入するにあたり本格的に統計をとってみようと思い、WEB上から確認できるツールを作成しました。

↑はmaillogとprocmailのログを日毎に集計しているものです。1時間おきに更新しています。

上段がpostfixでのフィルタリングを通過したメールをprocmailのログから非スパムなメール数、スパム判定（bsfilterとDNSBL、URLBL）されたメール数を表示しています。
中段がpostfixでREJECTされたメールの一覧を表示しています。
下段がREJECTの内容毎の集計を表示しています。

ちなみに今日21：00現在の統計を見てみると、
現在までにREJECTした総数は833
逆引きできないIPによるREJECTが225
S25R（改）によるREJECTが188
宛先不明によるREJECTが185
FROMのアドレスの不正によるREJECTが142
FROMのドメインが不正によるREJECTが51
FROMのアドレスが存在しないことによるREJECTが21
その他のREJECTが21（設定変更後に私自身がオープンリレーテストを行った結果）

配送されたメールの総数が15
非スパム判定が7
bsfilter、DNSBL、URLBLによるスパム判定が8

いずれも誤判定は0

配送された8通のスパムはすべてが国内から送られたものです。
最初にほとんど国内からのスパムは来ないと書きましたが、唯一仕事で使用しているwebmasterメール（いわゆる同胞メール）宛てに送られてきたスパムが転送されてきたものなのです。（ヘッダーを見るとこれらも元は海外から発送されています。）

総数833から宛先不明185、その他21を差し引いて、配送されたスパム8を足した数が635、これを単純に計算するとPostfixのみのREJECT率は約98.5%、リトライによる再送もあるので実数はもう少し低いかもしれませんが実用レベルに十分達している感じです。

これで1ヶ月間の統計をとったら、postfixのスパムメール対策を更新しようと思います。
（↑の統計ツールもいっしょにアップする予定です。）

1ヵ月後が楽しみです：）

« 閉じる

続きを読む… »

国内のＩＰの場合はsmtpd_client_restrictions部分では無条件にOKにしてその他は従来のスパムフィルターを通すといった試みをしてみようかと思ったわけです。

で、作成したのがコレです。

↑には6つのスクリプトが入っています。

getApnicipv4.plはApnicに登録されている各国毎のIPを拾ってきます。

> perl getApnicipv4 jp > apnicJp.lst

のように実行すると日本のIP一覧をwgetしてきてapnicJp.lstに標準出力します。

中国のIP一覧なら

> perl getApnicipv4 cn > apnicCn.lst

といった感じ。

getJpnicipv4.plはJPNICが管理しているIP一覧を取ってきます。

> perl getJpnicipv4.pl > jpnic.lst

といった感じ。

で、makeCidr.plが↑で取ってきたIP一覧からCIDRを生成するスクリプト。

> perl makeCidr.pl < apnicJp.lst > cidr.tmp
> perl makeCidr.pl < jpnic.lst >> cidr.tmp

といった感じ。

> echo ‘192.168.0.0-192.168.255.255′ | perl makeCidr.pl

というように単体でも使用できます。

dupRemove.plはmakeCidr.plで作成した一覧から重複しているものを削除するためのスクリプト。

> perl dupRemove.pl < cidr.tmp > cidr.lst

という感じ。

clientCidr.plですが、これはPostfixのsmtpd_client_restrictionsで使用するためのcidr_tableを生成するためのスクリプト

> perl clientCidr.pl OK < cidr.lst > client_cidr

といった感じ。
引数（OK）はRESULTを指定します。

拒否するならば

> perl clientCidr.pl REJECT < cidr.lst > client_cidr

といった感じ。

dupCheck.plはclientCidr.plで作成した一覧から重複しているものを標準出力します。

> perl dupCheck.pl < client_cidr

最後はこれで目視して重複したものを削除してやる必要があります。

添付されているclient_cidrは私が上記を実行して作成したcidr_tableです。

まだアドレスの範囲的に重複しているものが多数ありますが、キリがないので放置です：）

« 閉じる

続きを読む… »

IPアドレスを最近傍識別する新型スパムメールフィルタ「NNIPF」

文系出身の古典が得意だった私には↑の記事を読んでもサッパリわかりません∩(・∀・)∩

と、とりあえず個人的メモということで・・・

« 閉じる

続きを読む… »

なにが曲者なのかと言いますと、Windows 2003 ServerのActiveDirectory（Windowsすべての日付がそうなのかは不明ですが）上の日付というのは1601年1月1日から100ナノ秒（10000000分の1秒？）間隔というワケのワカラン仕様なのです・・・詳細はコチラ

（´A`）.。ｏO（1601年から起算していったい何がしたいんだろう）

つまりPHPでこれを正しい日付で表示するにはtime()関数の1970年1月1日からの秒（SEC）に変換すればよいので、
・取得した日付を秒（SEC）に変換
・秒（SEC）に変換した日付から1601年1月1日から1969年12月31日までの秒（SEC）を引く
という処理が必要なのです。

●取得した日付を秒（SEC）に変換
$lastLogon = $ATTRS["lastLogon"][0]; //ActiveDirectoryからlastLogonを取得
$lastLogon = floor($lastLogon / 10000000); //lastLogonを秒（SEC）に変換して小数点以下を切り捨て

●秒（SEC）になった$lastLogonから1601年1月1日から1969年12月31日までの秒（SEC）を引く
$lastLogon = $lastLogon - 11644473600;

11644473600という数字が1601年1月1日から1969年12月31日までの秒（SEC）です。
これの算出方法は過去にCmfDiaryのカレンダー機能でその年が閏年かどうかを判定する手法を取り入れたことがあったので、これを応用しました。

閏年は
・4で割り切れて100で割り切れない
・400で割り切れる
というのが条件です。

PHPで書くとこんな感じ
for($SEC = 0,$C = 1601; $C < 1970; $C++) {
　　$SEC += 60 * 60 * 24 * (365 + (($C % 4 == 0 and $C % 100 != 0) or $C % 400 == 0));
}

で最後に

$lastLogon = date("Y/m/d H:i:s",$lastLogon);

とすれば正しい日付に変換することができます。

面倒くさい仕様だな〜もう・・・（A`）

« 閉じる