uso8000k.net

さて、世間で有力とされる有害コンテンツを禁止する為のDNSブロッキング。掻い摘んで説明すると、ドメイン名からサーバが実際通信に使用するIPアドレスに変換するのがご存知DNS(DomainNameSystem) で、アダルトサイトとかの有害コンテンツを置くサーバをブラックリスト化して、名前引き (IPアドレスへ変換) 要求があった場合には変換をせずに拒否して、接続先のIPアドレスを答えない仕組みです。

ちなみにこれはサーバ自体が無効となる仕組みではなく、あくまでドメイン名をなかった事にする対策です。HTTPを例に挙げ、IPアドレスが有効な場合には接続は可能である為、IPアドレス直指定で何かしらコンテンツを見ることとなります。一般的にHTTPサービスを行うにあたり、VirtualDomainの機能を大抵使っています。VirtualDomainはIPアドレス一つに対し、アクセス要求したドメイン名を使用して、内容を分けて表示します。つまりはDNSの結果によって、有害なコンテンツのドメインは内容が塞き止められるということ。非常に地味に遮断できているではないか。ということ。

しかしHTTPに限り言えば、いくらでもヘッダは書き加えられるわけで･･･Firefoxでは開発用の拡張ににヘッダを追加/改変できるものがあり、IPアドレスとホスト名をセットするだけで継続的に遮断された筈のVirtualDomainにアクセスが出来たりします。

さて、悪意のあるWebページにアクセスをする場合、人間としてはやはりドメイン名を使ったアクセスをします。DNSのブロッキングもその方法であるが故に止めるのでしょう。

初見のドメイン名のみ知っている場合については、ブラックリスト入りしたドメイン名のIPアドレスを受けられない為、上記の通り接続ができません。しかし

• ブロッキング未対応DNSのキャッシュサーバの扱い
• Robtex.comにてキャッシュされた情報からモヒ※られる
• 空きProxyリスト的な扱いでIPアドレスとドメイン名の有害コンテンツ対応表の流通による崩壊

ドメイン名に関してはレジストラレベルから抹消/登録の方法を難しくするのが正解な気もします。

･･･さて、これは本当に有効な方法なのだろうか。迷惑メール等の日々の雑なアクセスに対しての問題は解決しても、Webを筆頭に寧ろ簡単にコンテンツ見せず隠れてしまうぶん、何が置かれるか分からない暗黒の時代が来るのではないだろうか？とかテキトウに考えたり。少なくともWebに置かれる違法コンテンツ、自動ポルノ規制の方法としては生殺しであるぶん有効な方法とは思えない。

※モヒる = ヒャッハーの意

なんか凄いコツコツ音がするんよ･･･

これまで

• 小規模コツコツ音
• なぞのフリーズ
• バックライトの部分飛び

SSD化するべくTouchを即注文
ClassicのSSD版があったらなぁ・・・

TwitterにしてもXboxにしても届くメールがバシバシSPAM判定される
ついでにAmavisd側でもヘッダ壊れ扱いという隙の無い二段の構え
これだからHTMLメールは･･

酷いのでなんとか対策はしたいところだけれど･･･
詐称のできる仕組みである以上、ホワイトリストは最終手段

信用･･･するなよ？
セキュリティ強化の秘訣は「だれも信じないこと」

「有給取れど成すべき事が見付からず出社する･･･。人、それを『社畜』という！」

似たような事言われたり。言われてる方も喜んでるという末期。

仮面ライダー龍騎 DVD残りを全部借りて消化

つまりは妹救えないからタイムベントの繰り返しだよ！って事の模様
劇中の演出で軽くリーディングシュタイナー吹いた

ところで12時間ぶっ通して視聴してましたが･･･
いいですよね？こんな休日も

タイガかわいいよタイガ
鉄肉球

SpamAssassinの運用を行って以来パタッとTwitterのメールが来なくなったり。調べたところSpam判定の処理のスコア指定を誤って判定後に即隔離されていたり。判定後の処理についてはこちらの対応でどうにかなるのだけれど･･･ ところでこいつを見てくれ、こいつをどう思う？

X-Spam-Status: Yes,

score=13.961

tag=12 tag2=20 kill=30

tests=[

ARIN=0.1,

AWL=-0.895, 

CONTENT_TYPE_PRESENT=-0.1, 

DNS_FROM_OPENWHOIS=2.431,

FAKEDWORD_ONE=0.5, 

FAKEDWORD_VERTICALLINE=0.5,

FAKEDWORD_ZERO=0.5,

HEAD_ILLEGAL_CHARS=3.729,

HTML_MESSAGE=1,

HTML_OBFUSCATE_10_20=3.196,

MIMEQENC=0.2,

MULTIPART_ALTERNATIVE=0.1,

ONLY1HOPDIRECT=1,

ONLY1HOPDIRECTARIN=1,

QENCPTR1=0.2,

QENCPTR2=0.2,

RCVD_IN_CHINA=0.1,

RCVD_IN_CHINA_KR=0.1,

RCVD_IN_TAIWAN=0.1,

UTF8=-0.1,

X_CHINESE_RELAY=0.1

] autolearn=spam

･･･凄く SPAMです。

とりあえず高スコアに至らしめる項目はこの3件。

DNS_FROM_OPENWHOIS　　RBL入り

HEAD_ILLEGAL_CHARS　　文字コード不一致

HTML_OBFUSCATE_10_20　HTML不明瞭

うん、先日のBlogの通り、ある程度の軽減措置として日本用のスコアが書かれたlocal.cfの適用していましたが･･･Twitter公式から送られるHTMLメールがこのように判定されている模様。なんとも･･･

仮面ライダー龍騎 DVDをまとめて借りるとか
こいつ･･･ 明日の有給を思いっきりエンジョイする気だな！？

森博嗣 著の異色なZシリーズ第2弾「ZOKUAM」
劇中の「ソフト的な問題」「ハード的な問題」って表現が割と好み。

問題:
山中で生活してて通販で生活用品を調達。
結果、運送用のダンボールが溢れ、片付けが大変という問題についての対処。

ハード的解決:
毎日届いたものをその日のうちに片付ける。

ソフト的解決:
ダンボールが出ないように生活環境の改善を行う。

この環境や下地にに合わせてなんとかする方法(ハード的解決)と、そうなる環境の上で何とかしようとする方法 （ソフト的解決）の考え方は割と好みであったり。ついつい、揖斐さんらしく「それはハード的に解決ができる問題だ」と言いたくなります。解決方法を大きくカテゴライズすることで、2通りの異なる考え方を持つことができ、アイディアに幅を持つことができます。自分の考えがどちらなのか、そして対する解決方法は何かとか考えてみると割と簡単に問題とされている部分の対処ができるのかもしれません。あとは状況に応じてどちらかを提案してみるも良いでしょう。

何の気なしにメール受信を試みたらサーバに繋がらないことが発覚。幾つか試行してみたところデーモンが止まっているというよりはネットワーク的に繋がらない模様。契約のLinodeの管理画面からコンソールにアクセスをしたところ、コンソールは無事である事を確認。とりあえずチェックをしても異常は無かったので、とりあえずリブートしてみた。

立ちあがらねぇorz
Bootボタン押しても立ち上がらない orz
コンソールにアクセスしてもコンソールに繋がらない orz

軽く詰み状態だったので、管理画面からの「Support」にて対処希望チケットを発行してみる。問題のカテゴリと内容を書いて発行すると担当者に届いてそこからサポートが開始されます。

01:04

Dear Linode Suppport,



Today, I could not connect my server (from japan). 

So I sign-in to my account. And connect to console.

At first, I could connect console.

I checked daemons and, server resources, and there was no problem.

So, I rebbot my server. After that, Server coiuld not boot up,

and could not connect console.. Would you please check "what's happened?"

01:09

Hello,



We're sorry to hear that you're having difficulty booting your Linode.

Our administrators are currently looking in to the issue.

We will get you back online and update this ticket as soon as we can.

01:19

Thank you for fast reply.



After I read you reply, I notice that server is up! Maybe It's ok.

If there is trouble, I hope to be fixed.

If I found a same case or other trouble, I'll contact you later.

Thank you for fixing it.



Sincerely yours.

01:23

Hello,



Glad to hear you're back online.

We believe that the issue has been resolved at this time.

You should have no further problems.

うん、サポートが凄い早い。最初のコンタクトに5分。似た経験のある身としては少し惚れてしまう。それを可能にしてる TTS (TroubleTicketSystem) ってのは便利だなぁと思う。

さて、わざわざこの様な微妙な英語を使った事を日記に書いて何が言いたいかと言うと「稚拙でも英語は出来たほうが良いよ」ということ。「この程度でも気合で何とかなるよ」ということ。インターネットのサービス使ってると英語に触れる機会もあり、そのぶん然るべき障害報告や、サポートを受ける事もありますので･･･とりあえず高校程度の知識でもなんとかなるもので、たまには英語の事も思い出してあげてください。

ところで、今回の原因ですが、おそらくはLinodeのネットワークの上流の障害、特にリブート後ステータス等も取れていないためおそらくはDHCP機能がこけてたんだろうなぁ･･･と推測。

本日は有給なり。本日は有給なり。 ということで、今日はサーバを相手にキャッキャウフフ。コンピュータは基本的に人に尽くすとても賢くて良い子です。あははは。新参ドメインというのもありますがPostfixにS25Rを導入して未だにSPAMに悩まされた事は無いのですが、来るであろう迷惑メールを想定してSpamAssassinとClamAV、Amavisd-newを導入。

■ /etc/portage/package.use

mail-filter/amavisd-new  -ldap spamassassin

mail-filter/spamassassin -ldap

ただ、ほぼデフォルトで動かしLDAPなど噛む必要が無いのでパッケージオプションは除去。

基本はGoogleにて載っているパッケージをインストールして最低限の調整を行えば動くようになります。 が、そのまま動かすと色々とメンテ上大変になるので幾つか手を加えたものだけ抜粋。 基本部分参考サイト:「Clam AV」 + 「amavisd-new」の設定 (CrimsonSnowさん)

■ /etc/passwd

spamd:x:[pid]:[gid]::/etc/mail/spamassassin:/sbin/nologin

SpamAssassin用ユーザ作成。 (Amavisd,ClamAVはパッケージ標準で作成)

■ /etc/conf.d/spamd

#SPAMD_OPTS="-m 5 -c -H"

SPAMD_OPTS="-m 5 -c -H -u spamd"

デーモンを挙げての動作となるが、rootでの動作が標準となっている為、spamdにて立ち上げるよう変更。

■ /etc/cron.weekly/spam_prefs.cron

#! /bin/sh



FILE_NAME="user_prefs"

PREFS_NAME="local.cf"

PREFS_URL="http://www.flcl.org/~yoh/"



COMM_PREFS="uso8000k_prefs"



SPAMD_PREFIX="/etc/mail/spamassassin/"

SPAMD_SCRIPT="/etc/init.d/spamd"



cd $PREFS_PREFIX



/usr/bin/wget -qN  $PREFS_URL$FILE_NAME

cp  $PREFS_NAME  $PREFS_NAME.bak



diff $FILE_NAME $PREFS_NAME.bak > /dev/null 2>&1

if [ $? -ne 0 ]; then

   mv $FILE_NAME $PREFS_NAME

   cat $COMM_PREF  >> $PREFS_NAME

   $SPAMD_SCRIPT restart

fi

一週間に一回SPAM対策用のある程度精査されたSpamassasin用共通設定をダウンロードするスクリプト。また、こちらの設定もCatにてこっそり足している。
また、各デーモンのホームについては全てがAmavisを軸としたメールフィルタの機能となる為、メールフィルタ用のグループ (mailflt等) を作成して、各サービスのホームディレクトリに権限設定しておくと色々と連携させる事も容易。

それにしてもamavisdの設定ファイルが長いうえに実質Perlスクリプトで苦痛。死にたい。

ここ1年で本当に性格が捻じ曲がったと思う。

ひょんなことから匿名メールを送る仕組みを急造する。

準備物:

• Sendmail相当 (Postfix) SMTPサーバ
• Procmail
• Procmail同梱のFormail

.forward

"|IFS=' ' && exec /usr/bin/procmail -f- || exit 75 #[username]"

Sendmail/Postfixのユーザ環境での転送処理。ここでとりあえずProcmailに転送します。ちなみに余談で、Procmailへ渡すのは"| /usr/bin/procmail" で良いのだけれど、こう書く一昔前の慣わしだそうです。玉虫色に染まれ！さん:procmail用の.forward設定の源流を探るにて詳しい説明が。とりあえず一昔前のSMTPサーバが同じ内容の.forwardを誤解しないようにとのこと。

.procmail

PATH=$HOME/bin:/usr/bin:/usr/local/bin

MAILDIR=$HOME/Maildir/

DEFAULT=$MAILDIR

LOGFILE=$MAILDIR/procmail.log

LOCKFILE=$MAILDIR/procmail.lock

SENDMAIL=/usr/sbin/sendmail



FROM=anonymous@example.com

FORWARD=target@example.com

MASK=[MASK]



:0

* ^Subject: Anonymous

| formail -A "X-Loop: $FROM"\

　-I "From: $FROM"\

　-I "Return-Path: $FROM"\

　-I "Reply-To: $FROM"\

　-I "To: $FORWARD"\

　-I "Received: $MASK"\

　-I "User-Agent: $MASK" \

| $SENDMAIL -i $FORWARD

条件: "Subject: Anonymous"で始まるものについて、X-Loop:ループ検知用ヘッダ追加 (-A) 後、送り主情報 (From:) を用意したアドレスへ塗り替え (-I) 、User-Agent:、Received:等、送り主を特定できる情報を可能な限りダミーで塗り替える。(-I) そしてその結果を登録された送り先へ送るといった内容。至極単純。Procmailインストール時に入るFormailですが、これが非常にお手軽なうえ強力で･･･便利です。

ところで、Procmailのレシピ中パイプ通した時に\の改行を加えると挙動が変わって配送されなかったり。それに故実際は1行で繋いでいる訳なのだがー 何故だろう。

最近、落雷がある度に色々問題が起って3涙。あと2涙でもれなく(笑)に昇華します。一発一発に焦ります。LANケーブルから来る事も稀ですが、2芯電話線(RJ-11)使用のADSLモデム等とは落雷地点から地面に逃げることなく伝ってきますので、サージをつけるなりしまして、皆様お気をつけください。

ところで電源の瞬断に弱いデスクトップPC故･･･それだけ加味してもノートで良いんじゃね？とか最近思うように。移動も楽ですし。私は買い換えたばかりなのと、HDDを冷やす仕組みも入れているのでデスクトップ生活から変えようとは思いません・・・でも考えると楽そうです。

「今までPCに拡張をした数を覚えているのか？」元ネタとは別な意味で答えられない (特に拡張をしていない) 場合には、「拡張性がある」という考えに縛られず、ノートPCを考えてみても良いのかもしれません。大抵足しませんので。あとは延命し辛いものをあえて使用することで、使いまわしの利く一般化された周辺機器の充実 (NAS等) や、PCの死期を設定した計画的な運用も出来るかと。グラフィックでCrossFire使うとか、大量のディスクを積むとか、変態拡張するなら申し分なくデスクトップなのですけれど...ノートは持ち運び、デスクは固定・拡張性アリという考えに縛られすぎている気がしてならない今日この頃。

そういえば、夕方の雷雨で寝床に雨が吹き込んでいたんだった･･･おのれ。

本日、某ML伝のコンピュータ好きが集う集まりにて、耳を疑うことを聞きました。その集まりのWebアプリケーションのセキュリティについての勉強会にて「ログを出力するのはセキュリティ上良くない」ということ。続いて「問題のトレースには必要であるので、我々はログを指定した場所に出力を啓蒙させている」という事の公言。

さも当然のように「ログの出力は良くない」とされている・・・何を言っているんだろう。これは私が藁人形論法に釣られてしまったのだろうか？ 話し手たちの立場が違うのかイマイチ話が分からない・・・是非とも教えて欲しいところです。

ログはシステムの内部が丸見えとなる理由からという良くないとの説明でしたが、ログは普通は開発側しか見れない仕組みであり、外部にログを出力する人はいるのでしょうか？見れない場所に置いても問題なのであれば外部の人間が見れているということで既にプログラム、サーバ、ネットワーク含めてアウトだと思います。開発内部向けの話としてもプロジェクトの人間の間での実装情報を隠匿するって…何か理由があるのでしょうか。大企業では製品の分担で互いの担当作業のログを隠匿する必要があるのでしょうか。敢えてログ出力をしない選択肢がイマイチ思いつきません。そもそも管理系のではなく、アプリケーションレベルの話で。なんとも消化不良だ。

故障判定で危うくRAIDのリビルドが開始されるところでした