security-literacy

WS_FTP Pro / Certificate has expired

File Transfer Client for Windows WS_FTP Pro 8.03 日本語版にて、Xrea.com さんのサーバにSSL接続していましたが、
解説ページ:
○ エントリー「FTPS ( FTP over SSL, FTP/SSL )」
    http://shellscript.biz/archives/000054.html
○「FTPS(FTP over SSL)への対応について」
    http://sb.xrea.com/showthread.php?t=9288
2005/8/29-8/30、突然、複数のリモート(サーバ名 s7*, s1*7) とSSL接続不能となりました。通常のFTPは可能で、ログ記録は以下のようでした。

ホスト ユーザID.s**.xrea.com を探しています...
接続中 : 221.186.***.**:21
221.186.***.**:21 に 0.050000 秒で接続しました。サーバーからの応答を待っています
SSL セッションの初期化中...
220 ProFTPD
AUTH SSL
234 AUTH SSL successful
SSL 接続エラー 655362:
Connect Failed: Certificate has expired
SSL Connect Failed
Host type (1): Automatic detect

WS_FTP Proの本家サイトで、最新評価版をダウンロードしてインストール・実行しましたところ、FTP/SSLできました。クライアント用FTPソフトウェアの証明書が失効したため、
「Certificate has expired」
SSL使用不能となったようです。SSL接続を継続したいとき、バージョンアップが必要のようです。問題解決した評価版は以下のものです。
  http://www.ipswitch.com/Products/WS_FTP/

Ipswitch WS_FTP Professional 2006 - 2005.05.11
File Transfer Client for Windows [98/NT/2000/ME/XP/2003]
Copyright(c) 1992-2005 Ipswitch,Inc.
File Size: 9.7 MB

なお、「XREA SUPPORT BOARD - FTP関連フォーラム」
   http://sb.xrea.com/showthread.php?t=9988
に投稿しました。Xrea.com さんのご回答は、
「POPS、IMAPS、SMTPS、FTPSでは、正式な証明書を発行しておりませんので、証明書の確認は無視か、無条件で受け入れる設定をお願いいたします。」とのことです。

Rapidsite/Apa

ラピッドサイト は、シリコングラフィック社 Silicon Graphics, Inc. (SGI) が提供する OS IRIX (unix) をウェブホスティングサービスに利用しているそうです。webサーバには、Apache が使用されています。
  http://www.rapidsite.co.jp/www/faq/index.html#17a
検索サイトにて「IRIX Rapidsite」と入力して、ヒットするURL(主に、数年前のページ) の中に (例)

OS : IRIX
Server : Rapidsite/Apa/1.3.** (Unix) FrontPage/5.0.2.** mod_ssl/2.8.** OpenSSL/0.9.*a

があります。
ホスティンググループ NTT/VERIO 技術提供のサーバそのものであるか不明ですが、Rapidsite/Apa とは、カスタマイズ後に標準搭載された Apache のこと(のよう)です。
[追記 2005/8/26] ウェブ改ざん報告を記録したページには2003年秋頃まで、本サーバ名がときどき登場します。その後、サーバ名が Apache に変更されたためか? ヒットしません。

RFC2182 recommends at least 3 nameservers.

Xrea.com さんのサーバでは、
汎用JP、CCTLD、他社管理ドメインなど(eNomで取得したドメイン以外)の場合:

ns1.value-domain.com. [219.0.10.54] [JP]
ns2.value-domain.com. [210.153.116.18] [JP]
ns3.value-domain.com. [59.106.14.70] [JP]

COMドメインなどeNomで取得したドメインの場合:

dns1.name-services.com. [69.25.142.1] [US]
dns2.name-services.com. [216.52.184.230] [US]
dns3.name-services.com. [63.251.92.193] [US]
dns4.name-services.com. [64.74.96.242] [US]
dns5.name-services.com. [212.118.243.118] [UK]

のネームサーバを利用します。
[DNS チェックサイト]
  http://www.dnsreport.com/
  http://www.squish.net/dnscheck/
  http://www.zonecheck.fr/

などで頻繁にネームサーバのレスポンスをチェックしてみると、ときに

ERROR: Some of your nameservers listed at the parent nameservers did not respond. The ones that did not respond are: ****

と、１つだけ(1/5台 or 1/3台)レスポンスがないため、 [fail] と表示されることがあります。
Xrea.com さんのサーバ以外では、最大２つのネームサーバ nameserver のことが多いようですが、１台は 常に response がなく、実際にはプライマリーだけで運用しているサーバも見かけます(市役所などの公的機関を含む）。
RFC2182 section 5 recommends at least 3 nameservers.

Base64エンコードしない日本語JISメールヘッダのすり抜け

メールヘッダ「Subject:」題名、件名を 文字コード "JIS" で書きメール送信すると、大手ISP Plala さんなどのメールリジェクト・サービスの Subject設定をすり抜ける (無効化)。spam メールにとって、メールヘッダーの From: Return-Path: 詐称は当たり前であるが subject: のフィルタリングもこのような方法などで実際に簡単にすり抜けている。

ただし、spam メールの中で (スパムとしては、最近少なくなったが)、
「Subject: =?iso-2022-jp?B?bnGyRCJEskRCCYkNCQ2GyhC?=」
のように表示される Base64 エンコード (同じ、JIS 7ビットコード ISO-2022-JP ではあるが)されたものは、メールリジェクト・サービスでフィルタリングやブロックできる。
[追記 2005/8/13] ISP ぷららさんの回答の一部を転載しました。

Subject: ぷららサポートセンター
Date: **, ** Aug 2005 13:54:40 +0900
**ブログ主催者名**様の検証結果の通り、「メールリジェクト」はMIME64エンコードされていないメールは拒否されずに受信されてしまいます。これはシステム上、MIME64エンコードされていない文字列を認知しない機能となっているため、防ぎようがない状況でございます。**様にはご不便をお掛けすることとなりますが、拒否されず受信されてしまったメールは削除して頂けましたら幸いでございます。

Base64エンコードは MIMEエンコードとも言われますが、Quoted-printableもMIMEエンコードなので、下記参照ページの１つには、MIME(Base64) と書かれています。

Base64 エンコードの参照ページ:
  http://info-club.net/Usagi/memomemo/base64.html
  http://homepage1.nifty.com/glass/tom_neko/web/web_03.html#header
  http://www.kipwmi.com/fm/tips/base64.htm

ウイルスチェック結果報告メールの意義

今日も、自動送信の報告メール数通が着信し、多いときは一日あたり数十通のことがあります。ウイルスチェック結果報告メールの趣旨は理解できますが、大手ISP So-net さんに限らず、今日では、ネットワークの過大負荷となる「スパムメール」 「ジャンク・メール」の一種ではないかと思います。

ブログ主催者の質問メール:
Date: Thu, 28 Jul 2005 14:06:18 +0900

以前から、貴社のウイルスチェックサービスが作動すると、ウイルス駆除とともに結果報告メールが着信します。利用者にとって、とてもありがたいことですが、送信元アドレスは詐称されたものでしょうし、当方としては事実を確認するだけのメールです。しかも、貴社サーバにとって、この通知メールを送信すること自体が負荷でしょうし、トータルすると、ネットワーク全体に負荷をかけています。端的に言いますと、このような単なる報告メールは「不要なメール」ではないかと思います。送信元アドレスに意味のある時代ではありませんので、貴社ホームページで「サーバでウイルスを削除します」のご案内だけでよろしいのではないでしょうか。

サーポートセンター様の回答
Date: Fri, 29 Jul 2005 13:10:01 +0900

ウィルスチェック結果の報告にて、送信元のメールアドレスをお知らせさせていただいておりますのは、ウィルスに感染してしまったメールがお客様のお知り合いの方からのメール等、必要なメールである可能性もあるため、確認できるよう通知させていただいておりますのでご了承いただければ幸いと存じます・・略・・