メールの踏み台対策に、今回SMTP AUTHを試験的に導入してみました。

メールの踏み台対策にはいろいろな方法があり、環境や利用者によってどれがベストとは言い切れないのですが。
　

私の考える、踏み台対策の判断ポイントは、

①完全は無いにせよ、非常に高確率で踏み台接続をブロックできること。
　漏れた部分はスパムアサシンが引っ掛けてくれるでしょう。

②メール利用者に負担をかけないこと。
　設定の煩雑さや、利用時の制限が生じるなどは、極力避けたいところです。

③サーバー管理者に負担をかけない。
　管理に手間がかからなければ、もっと前向きなお仕事ができますので当然のことです。

このバランスを考えると、現状ではSMTP AUTHがベストだと判断しました。
　

試験的な導入から一週間。問題もなく快適に動作しています。
不正な接続もキッチリとブロックしているようですし、弊社で管理しているサーバーに、本格導入を前向きに検討しています。

　 　 　

お盆も明けて、通常のお仕事モードに入りました。

どんなに忙しくても、毎年のお盆の恒例行事は欠かさないようにしています。

まずはお墓参り。先日のBLOGにも書きましたね。

それからもう一つ、原爆の日と終戦記念日には、サイレンを聞きながら黙祷します。
子供の頃から、夏の恒例の行事です。

私はよく人に『右寄り思想』だといわれるのですが、本人は至って中立のつもりなんですけどね。
戦争を肯定するつもりも、美化するつもりもない。けど、国や家族のために無くなった兵隊さんに感謝し、戦争の犠牲者に哀悼の気持ちを持つのは人間として当たり前ですよね。
『靖国問題』も政治の道具に使われているようで、個人的には心苦しい限りです。
　

夏といえば甲子園。

そういえば、先日ネットでこんな話題を見かけました。

某高校の応援団の学ランが、戦争を連想させてしまうのでやめて欲しいというクレームが入り、応援団の生徒達は急遽トレーナーで応援したとの事。

なんだか変ですよね？
　

セーラー服は海軍の制服を連想させるのでダメ？
入場行進は学徒出兵を連想させるのでダメ？
応援のラッパは進軍ラッパを連想させるのでダメ？
ボールを投げるのは手榴弾を投げるのを連想させるからダメ？
花火は大砲の音を連想させるのでダメ？

って事になるんじゃないんですか？連想とかインスパイヤとか言い出したらキリがないでしょう？

物事の表面だけでなく、ちゃんと本質をみていないからこんなことになるんでしょうね。
　

そもそも

夏の甲子園大会のスポンサーである、某大新聞社さんの社旗、
旭日旗に似ていたりしませんかね？これは大丈夫なんでしょうか？

　 　 　

仕事の合間を縫って、駆け足でお墓参りに出かけてきました。

妻の実家側と私の実家側合わせて5箇所。全て県内ですので車で移動すれば半日仕事です。

仕事が忙しく、お盆休みすら取れていないのですが、お墓に立てられている盆灯篭をみるとお盆を実感します。

ちなみに、盆灯篭って浄土真宗・安芸門徒特有の風習だそうですね。
写真を載せようかとも思ったのですが、お墓の写真を撮るのと掲載するのに躊躇してしまいました・・・

　 　 　

世の中はすっかりお盆休みモードですが、インフラ周りの入替え作業は、サービスを短時間停止してもお客様の業務への影響が少ないこういう時が最適なんです。
　

さて、設置も完了し、動作確認。

と思ったら、DNSが社外から参照できない事象が発覚。昨日まで問題なく動いていたのですが・・・

ローカルマシン上でのnslookupは全く問題なし。
ということは、named.confでローカルホスト以外からの参照を規制しているんでしょうね。

ということで、named.confの設定を変更し、再度動作確認。無事動作を確認しました。
　

ここ1ヶ月でFedora7のサーバーを構築したのは5台目。用途はWEB、メール、データベース、アプリケーション用と様々ですが、なかなかのハイペースです。

個人的にはお気に入りになりそうな気がしてきました。

　 　 　

8月14、15、16日と夏期休暇をいただきます。
とはいえ、お仕事てんこもりな私は普通にお仕事しております。

夏期休業中は、会社のTELは留守電になっておりますので、
お急ぎのご用件の方は、私の携帯までご連絡くださいませ。

　 　 　

Fedora7を本番環境に導入後、数日が経過しましたが、予想通りいくつかの問題が発生しました。

・アクセスログ集計の画面で、特定の範囲条件を指定した時のみServerErrorが発生。
・携帯用サイトのサブミットが、AU端末のみエラーになる。
などなど。

いづれも、プログラムをいくら調べても全く問題は見当たらず。
プログラムを一部変更してみても改善せず。
　

こういうときは、ログを見ながらエラー要因を追跡する方法が効果的なんです。

エラーを発生させておいて、すぐに/var/log/httpd/error_logの最終行付近をチェック。
数回、何パターンか繰り返せば該当するエラーを発見することが出来ます。
　

さて、今回はFedora7から導入された、mod_securityという機能が原因でした。アンインストールしてみると、問題は全て解決。

Webサービスのセキュリティ強化の為の機能のようですが、まだ少し問題が残っているのでしょうか？要注意です。
　

しかしながら、こういったセキュリティ強化の取り組みには大賛成。ディストリビューションの姿勢は評価出来ます。
多少のリスクを覚悟しなければ、技術的な進歩は止まってしまいますからね。
それと、問題があるのであれば、利用者が使わなければ良いだけですから。
　

Fedora7では他にもセキュリティ強化の取り組みがなされているようですね。

例えばWebサービスに対して、IPアドレスではアクセスできない等。
ロボットによる無差別攻撃・荒らし対策として有効でしょう。
正直、開発環境や納品前のサーバー設定時に不自由することはありますが、本番環境では全く不自由しません。
最悪の場合は、ブラウザ側の端末のDNSやHOSTS設定をちょこっといじってやれば解決できますからね。
　

さて、明日もFedora7で構築したサーバーを2台納品予定です。
問題なく仕事を全うしてくれることを期待しています。

　 　 　

ここのところ、深夜のサーバー入替作業やトラブル対応に加え、日中の外回りのお仕事が目いっぱいで、体力の限界を感じています。

この歳になると、寝不足がこたえますね。ただでさえ疲れが抜けにくくなっているところに、追い討ちをかけられてふらふらデス。

今日の夜は（も？）外食でおいしい物でもいただいて、少しリフレッシュでもしようかと考えているところです。
　

が・・・・・

台風が接近中。停電の恐怖と戦いながら、またまた会社にお泊りコースとなりそうな予感がしてきました。