2007/01/15(月)FreeBSD 6.2R ようやく....
2017/10/11 9:30
３～４回延期（ま、いつものことだが）された上でのリリースで、一応それなりに満を持してという感じでしょうか。
リリース直前にもセキュリティ問題が発覚して、一応対処は入ったようだし。
2007/01/10(水)spam メール対策
2017/10/11 9:33
某所から、「あんたのとこのＷｅｂサーバから spam メールが発信されてると報告受けたから至急(撲滅の)対処するよーに」と業務命令が下ったからです。
一時はどうして良いものか見当がつかず、原因追及に雲を掴むような雰囲気が....
結局、左記のメールフォームが悪用されていたのでした。1999年頃に自作した CGIです。これは、実際に悪用されていたメールフォーム。これが spam 発信の拠点になってしまう訳です。
直接このメールフォームから spam を発信しているわけでなく、HTTP プロトコルを直接操作して,本来であればこのメールフォームから起動される CGI を直接アクセスしているのだと思います。
親切機能で、誰もが閲覧できる部分にメールフォームを安易に設置するのは危険だという訳です。
某所のテクニカルサポートに聞いてみたら、この手の spam 発信は常套手段の一つのようです。なので、Ｗｅｂサイトを運営している全ての善良な運営者は、spam 発信基地にならないように意識を高めていか ないといけません。
ですが、全てのメールフォームが危険という訳ではありません。
左記のメールフォームのように入力項目が複数あるものが危険度が高いです。
入力項目が本文しかないようなものは、spam 発信の道具にはされますが、大量発信の道具にはなりにくいです。
＃但し、集中攻撃を受ける可能性がある
電子メールは、最初の空行１行にてメールヘッダ部分と本文部分に区別され、メールヘッダが実際の配送記録や制御に使われます。
結果的にメールフォームから、メールヘッダに情報を埋め込む仕組みが備わっているものが危険です。
今回は、左記の「題名」の部分に、メールヘッダを埋め込まれたために、spam 発信の拠点になってしまった、
という状態でした。
今日(1/10) の AM 3:30頃にこのメールフォームは機能しないようにしました。
上記の例の場合、
-----
From: フォームで入力したメールアドレス
Subject: フォームで入力した題名
以下本文
-----
と電子メールデータを作成してメール送信処理していたため、Subject の部分にメールヘッダを埋め込めば
自由自在の場所に送ることが出来てしまいます。これが脆弱性だった訳です。
これは、
-----
From: CGI 固定のメールアドレス
Subject: CGI 固定の題名
以下本文
メールアドレス：フォームで入力したメールアドレス
題名：フォームで入力した題名
本文の続き
-----
のようにCGI の電子メールデータ生成処理をすることで、spam メール拠点になることが防止できた訳です。
つまり、メールヘッダ部分にフォームデータの内容をそのまま差し込まない が鉄則になります。
現在お使いのメールフォームがそのような脆弱性を有しているか否かは、CGI を見ないと判りません。
メールフォームCGI の作者に聞くか、実際に実験して確認するかしてみる事をお願いします。
2006/12/29(金)FreeBSD 6.2 RC2
2017/10/11 9:34
年内のリリースは絶望的と相成りました。
今までの工程眺めてると、RC1やRC2 からは、最低でも１週間（大抵は２週間）は期間を置きますので。
毎度のように、２ヶ月から３ヶ月遅れてのリリースになりそうです。
今回は、結構重篤なセキュリティアラートとか、LANカードインタフェース回りでいろいろあったようなので、そのあたりの対策なのかなと。
＃勝手な予測なので、信用しないよーに ＞ ＡＬＬ
2006/11/18(土)FreeBSD 6.2R
2017/10/11 9:35
順調にいけば、２週間後(2006/12/01)くらいに RC2、その後２週間くらいの期間を置いて 6.2R のリリース。
なので、ずべて順調に行っても 12/15あたり。
なにかあれば、順調にリリースは遅れるので、クリスマスあたりか、年を越して１月前半とかになる可能性もあります。
2006/06/17(土)結局、欲しいものに合致したものは無い... ＞ rtsp 接続で mp3 対応ストリーミング
2017/10/11 10:09
結果的に、求めているものとはちょっと違っていましたね。。
以下、個人的な評価です。
○悪い（気に入らない）点
・Real Player で rtsp なストリーミングが出来ない（強引に mms:// だよ...orz）
・WINAMP では ポート番号 554 を強制的に付与しないとストリーミングが出来ない。
・オンデマンド配信が出来ない。
・時々ストリーミングが途切れる事がある。サーバ負荷などの問題では無さそう。
・有償版の Quicktime が無いと、mp3 コンテンツ配信情報(SDPファイル)の作成が出来ず、Quicktime でのストリーミングは手軽には不可。
・iTunes では、http プロトコルでないとストリーミングできない.
○良い点
・SHOUTcast + sc_trans よりもサーバ負荷が非常に軽い
・複数チャンネルのストリーミングが同時に出来る。
・SHOUTcast/Icecast 互換なので、WINAMP を使ったライブ放送が出来る。
・営利使用が出来る
コンテンツを mp3 形式に変換するのはいいとして、Helix Realserver の代替を求めていた立場としては、
rtsp がまともに機能していないのは不満なのでした。
断片的な技術情報を斜め読みすると、どうも生の rtsp ではなく、http でカプセル化した「変な rtsp 」らしく。
SHOUTcast/ICEcast と互換性持たせる為にそうしたのかな。
それは求めていることでは無かったので、残念。
ストリーミングに http:// は明示的に使いたくないので、仕方なくあがきで mms:// を。
昔の自分だったら、rtsp:// ネイティブなサーバ自作に取り掛かるところですが、今はその余裕が無く。。orz
＃多額の寄付でもあれば、やるところですが。。事情は察していただければ...（爆）
2006/06/15(木)rtsp で接続可能な mp3形式対応ストリームサーバ
2017/10/11 10:10
・起動が重い → Realplayer の潮時
・脱 Windows に不都合 → WMV とか rm 形式は Windows 寄りなので ×
ということで、現在使用中の Helex Real Server に代わるもの探してみたです。
とりあえず ここ 参考に Apple 社なサーバでも突っ込んでみるか・・・
rtsp にこだわるのは、ここにはちょっと書けませんが大きな理由があります。
＃これはメモ書き代わりです（爆）
あと、ここも → http://sprite.eng-scl.setsunan.ac.jp/stream-memo.html#mt-daapd
2006/05/24(水)FreeBSD 5.5R
2017/10/11 10:12
＃結局、アナウンスがあったのは 5/26 の朝でした...
2006/05/13(土)FreeBSD 今後のリリース日程
2017/10/11 10:13
まぁ、今までの状況からみて、予定通りということは無いと思うですが、、、（数時間前に変更日程公表らしい）
FreeBSD 5.5 2006/05/22
FreeBSD 6.2 2006/09/11
FreeBSD 6.3 2007/01/08
次期バージョン 7.0 の提供作業開始は 来年６月以後のようです。これだけはたぶん、予定通りかも。
2006/05/09(火)FreeBSD 6.1R
2017/10/11 10:14
（日本時間で）今日の昼過ぎにアナウンス入りました。
2006/04/14(金)謎のメッセージ（やっと解決）
2017/10/11 10:15
Apr 14 17:40:34 server kernel: arp: aaa.bbb.ccc.ddd moved from xx:xx:xx:xx:xx:xx to yy:yy:yy:yy:yy:yy on zzz0
のようなメッセージが間欠的に出るようになり、原因が判らなかった（通信は普通にできる）のがやっと判明。
ＬＡＮカードか、ルータかどちらかであることは判っていたのだが、どっちなのか探る情報が無い。
結局一番あやしそうなＬＡＮカードを交換しても同じ現象になるので、これはルータだ、ということになり、
先ずは故障か設定かを見極めるために、各種設定をチェック。
arp -a
なんかをサーバのコマンドラインでやってみると、別々のＩＰに同じ MACアドレス返しているし、、＃ProxyARP な状態になる故障かと思ったです、、
そうしたら、サブネットマスクの設定間違いを発見しましたorz
それを直したら、今のところ、上記メッセージは全く出なくなっています。
ルータが telnet を受け付けてくれないのがまだ不明ですが、、