クロスサイトスクリプティングの脆弱性
ここ wikiroom でも添付ファイルの規制が始まっているようだ。
中東の武装勢力がファイルを送りつける先にもなっているという話なので、
画像といえども誰もが添付ファイルを置けるようにするのは問題があるのは
時代の流れであきらめるしかないのかもしれない。
お家サーバーは、書き込めるのは管理者が許可した（書き込みパスワードを発行した）人
だけに限るようにしたので、対策の必要は無いようだが説明ぐらいは
書いておかないと不安になる人が現れるかもしれない。
php 4.3.11
今日は外からお家サーバーにアクセスしにくかった。
ADSLが頻繁に切れるか何かで、IPがころころ変わるためだと思われるが、
詳細は不明。ADSLモデム(12Mbps)の回線状態でのリンク速度は、
下り9824kbps 上り1024kbpsとの表示で問題無さそう。
php-4.3.11 に更新。
real 45m37.243s
user 35m5.840s
sys 11m8.240s
[23:50] apachectl restart
辞書攻撃その後
『お家サーバー日記/2005-01-27』でsshを使って手当たり次第の
ユーザー名やパスワードを試す行為があると書いたが、
ログを調べてみたら、
grep sshd /var/log/messages.0 | grep Invalid | wc
307 3070 22489
zgrep sshd /var/log/messages.{1,2,3,4,5}.gz | grep Invalid | wc
1727 17270 165919
とまあ、2月の頭から現在まで2000回ほどアタックを受けていることが分かった。
試しているユーザー名は admin や guest、test などが多いが、jane とか frank なんて
のもある。
日本人らしい名前も狙われるようになるのは時間の問題だろう。
JPCERT/CC が『OpenSSH の脆弱性を使ったシステム侵入に注意喚起』を出しているくらいなので、
実際に侵入されてしまったサーバーもかなり出ているのだろう。
以前は、ログインできるユーザーを制限しただけだったが、
今度はさらに特定のIPアドレス(aaa.bbb.ccc.ddd)以外を叩き落すことにする。
su -
cat <<EOD >/usr/local/etc/rc.d/iptables
#!/bin/sh
case "$1" in
start)
# Enable iptables
/sbin/iptables -F
/sbin/iptables -A INPUT -p tcp -s aaa.bbb.ccc.ddd --dport 22 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 22 -j REJECT
;;
stop)
# Disable iptables
/sbin/iptables -F
;;
*)
echo "Usage: S99iptables {start|stop}"
exit 1
esac
exit 0
EOD
chmod ugo+x /usr/local/etc/rc.d/iptables
/usr/local/etc/rc.d/iptables start
これを遠隔から実行するときは、十分注意しないと実行した途端音信不通となる。
まあ、自宅に帰ってから直せばそれでいいのだけれど。
私の場合、幸い遠隔から入る場合はIPが固定されているので、
IPフィルタで良いが、出先でPHS等のインターネット接続から自宅に
接続するような場合はこの手が使えない。
あるポートをtelnet等でノックするとssh等のポートが開いて入れるようになる、
というようなセキュリティ機構を聞いたことがある。なかなかいい手だと思った。
そのうち試してみよう。
suspended.page
2/22以来、ここ wikiroom.com をアクセスしても
suspended.page というサイトにリダイレクトされてしまっていたので、
もう復活しないのかと思った。やれやれ。
最後の書き込みのバックアップが無くて、ブラウザのキャッシュとか
サーチエンジンのキャッシュとか探しまくったけど、なかなか
見つからなかった。googleのキャッシュは 2/3、
Web Archiveは 2004/2/22までのものしか無いようだった。
今のうちにバックアップをちゃんと取ろう。
コメントspam
お家サーバーのPukiWikiは、パスワードを知っている人だけしか
書き換えられないようにしているのだが、コメント欄だけは
誰でも追加できるようにしてある。そこに spam がやって来たようだ。
69.31.84.187 - - [21/Feb/2005:10:00:01 +0900] "POST http://example.jp/example/
pukiwiki.php HTTP/1.1" 200 21453 "http://example.jp/example/pukiwiki.php?
Jurnal%2F2005-02-21" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; Win 9x 4.90)"
$ dig -x 69.31.84.187
(途中省略)
;; ANSWER SECTION:
187.84.31.69.in-addr.arpa. 86400 IN PTR newlan.named1.com.
http://whois.ansi.co.jp/?key=named1.com
によると、USAの組織のようだが詳細不明。
怪しいサイトへのリンクをポストしていっただけなので、
怪しい組織であることには間違いないようだ。
pukiwiki.dev:BugTrack/772 にあるように、
コメント spam 対策 を
検討しないといけない。
具体的には、『米Google、リンク属性を利用したコメントスパム対策機能』にあるように、
spammer のリンクが Google 等のサーチエンジンに影響しないようにしてしまう機能
なのだが、PukiWikiでどのように実現するかは検討中のようだ。
辞書攻撃
ありがちなパスワードを総当りで調べる攻撃が流行っているようだ。
お家サーバーも ssh を空けているので気になる。
とりあえずは、私しか使わないのだから /etc/ssh/sshd_config に
AllowUsers otsuka
を加えて、sudo kill -HUP `cat /var/run/sshd.pid` しておいた。
PermitRootLogin? や、PermitRootLogin?、PasswordAuthentication? の
パラメータを調整してもできそうだが、PAMを使うように構成されているので、
/etc/pam.conf の設定が優先してしまってるようだ。
遠隔からrootで入ろうとする*1と /var/log/messages に、
minig sshd[68]: User root not allowed because not listed in AllowUsers
と記録されたので、目的は果たしているものと思われる。
しかし、こんな大事なことを検証するのがこんなに難しいのは問題だ。
robots.txt
魔除けのおふだの効果は絶大だ。
MSNBot も Yahoo! Slurp も律儀に従ってくれるようだ。
しかし1ページ2分だと可哀そうに思えてきたので1分に変更した。
魔除けのおふだ
昨日今日と立て続けにサーチエンジンのクローラがやってきて、
公開しているページや画像を根こそぎ持って行くので、重くてしょうがない。
特に目立つのが、MSNBot と Yahoo! Slurp だ。
クローラに対していろいろ注文を付ける方法が規約*2で決まっている。
サイトのトップに robots.txt というファイルを置いて、この中に
いろいろ書けば、まともな相手なら従ってくれるというものだ。
これによると、
User-agent: Slurp
Crawl-delay: 60
と書いておけば、アクセスの間隔を1分とってくれるらしい。
MSNの場合も同様だ。
*3
とりあえず、
User-agent: *
Crawl-delay: 120
とでも書いて貼っておくか。人間の言葉に直すと、
このサイトを訪れるボットさん各位
アクセスの間隔を最低でも2分とってください。
効果あるかな？効きすぎて Google で検索できなくなったらとても困る。
そういえば Google bot と最近あまり遭遇しないのだが、最近の更新は
しっかり捕捉されてたりするので、クローラの優秀さがわかる。
と、ここまで書いて負荷が高い原因が別にあることに
気が付いた。spamの踏み台にされて恐ろしい状態になっているではないか。
以後詳しい経緯は『Double Bounce攻撃』に
書くことにする。
- カテゴリ/インターネット
- カテゴリ/セキュリティ
- カテゴリ/OpenBlockS
- カテゴリ/トラブル
Sandbox spam
ついにPukiwikiもspamの対象にされ始めた模様。ここの sandbox も荒らされていたので、
とりあえず凍結処理しておいた。お家サーバーで動いているPukiwikiページの
書き込みはパスワードが必要なので、今のところ対策は必要無さそう。
Santyワーム
少し前にMozillaの翻訳サイトなどで問題になってたやつかもしれない。
PukiWikiなんかもそのうち狙われたりするのかな。
サイトに下のほうに使っているサーバーソフトのバージョンを書いてたりするけど、
止めたほうがいいんだろうか（そのようなことは配布者に無断で出来ないかもしれない）。
そもそもGoogleがそんな情報をワームに提供するから悪い、とは言い切れないし、
困った世の中になってきたものだ。
Symantecのサイトの説明によると、URLに含まれる "viewtopic.php" という部分を
検索するようだ。pukiwiki.php も露出していると危ないということか。
タイムリミット
PukiWikiとPHPのバージョンを同時に上げたら、cmd=linksという
時間のかかる処理がうまくいかなくなった。
/usr/local/lib/php.ini にある、max_execution_time がデフォルトでは30秒
なのだが、いつの間にかページが増えて時間がかかりすぎていたようだ。
しかし、時間のかかる処理では、PukiWikiの処理であらかじめ set_time_limit(0)
という関数を実行しているので問題ないはずなのだが効果がないようだ。
確かに、マニュアル
には、php.ini の記述に従うと書かれている。以前のバージョンでは、
例外的に処理時間のリミットを外す目的で使えていたように思うのだが。
結局、php.iniの max_execution_time を120秒にセットして事なきを得たが、
もっとすっきりした解決方法があるかもしれない。
php 4.3.10
スラッシュドット ジャパン | PHP 4.3.10, 5.0.3リリースとのことなので、
php-4.3.10 に更新。
real 45m48.314s
user 34m5.950s
sys 10m32.490s
オブジェクトのサイズが30%も小さくなっている。ssdlinuxを更新したので
gccを含めライブラリが新しくなっているためだと思われるが詳細は不明。
ls -l php-4.3.9-minig-1.tgz php-4.3.10-minig-1.tgz
-rw-r--r-- 1 otsuka users 6341466 Dec 17 11:48 php-4.3.10-minig-1.tgz
-rw-r--r-- 1 otsuka users 8819120 Oct 12 14:26 php-4.3.9-minig-1.tgz
[13:42] apachectl restart
RealVNC
OpenBlockS/VNC - VNC server 4.0 の build でかいとはいえ時間かかりすぎ。
$ configure --with-installed-zlib
$ time make
real 9m50.768s
user 8m43.230s
sys 0m52.040s
$ debian/buildX.sh
real 162m1.782s
user 134m44.500s
sys 21m36.460s
apache 1.3.33
お家サーバー日記/2004-10-26で、apache 1.3.32 に上げたばかりだが、
このバージョンは正式にはリリースされなかったようだ。
珍しいバージョンを取って来てしまった。先日のサーバー・クラッシュ
が、apache のバグのせいではないかと疑われるが、サーバーが
不調なときでも、LANから http での応答はあったらしいので、
それは無いと思う。
コンパイル時間
real 3m46.639s
user 2m58.530s
sys 0m41.610s
[11:40] apachectl start
ファーム更新
昨日のクラッシュを受けて、
放置していた OpenBlockS の ssdlinux のセキュリティ更新を行うことにした。
plathomeのサイトには、RELEASE-20040828 というバージョンがあがっているようだ。
更新手順は、お家サーバー日記/2003-11-01とほぼ同じ。
1年間更新をサボっていたことになる。反省せねば。
RELEASE-20040828にバージョンを上げると、以下のような問題が発生した。
- loginのたびにシリアル・コンソールやsyslogに、
configuration error - unknown item 'DIALUPS_CHECK_ENAB' (notify administrator)
が、記録される。
- sshdが自動で起動していない。
手動で sshd と打って起動しようとしても、
sshd re-exec requires execution with an absolute path
というエラーになる。
- vncserverが起動できない
1.は、/etc/login.defs のバージョンを最新にしてやると解決した。
2.は、sshd を full-path で指定しないと起動しなくなったようだ。
/etc/rc に自動起動する箇所があるので、full-path に直した。
3.は、c++のライブラリのバージョン不整合に起因するエラーのようだ。
ソースを取り寄せてコンパイルしなおしたら起動するようになった。
- カテゴリ/OpenBlockS
- カテゴリ/トラブル
オフライン
[16:00] 外から ssh で入ろうとすると、
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: POSSIBLE DNS SPOOFING DETECTED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The RSA host key for example.jp has changed,
and the key for the according IP address ***.***.**.**
is unknown. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff:00.
Please contact your system administrator.
というすごいメッセージ(一部伏字)が表示された。
どうもお家サーバーが不調で Dynamic DNS の更新をしていないので、
ddo.jp 側でオフライン用のリダイレクト・サーバーに切り替えて
くれているようなのだが、そのホスト鍵と覚えているホスト鍵が
違うから、偽の DNS 情報とすり替えられている、と警告してくれているようだ。
sshは、Dynamic DNS を使っていることなど考えもしないで設計されているのだろう。
まあ、それはいいとして ddo.jp の最新更新時刻を見ると、
2004/10/29 05:45 となっている。朝から不調だったようだ。
今、出先なので回線がおかしいのかサーバーがおかしいのか判断できない。
ddo.jp のオフライン時のリダイレクト先が変だったので、
プロバイダに付属のホームページの領域で、「障害発生中」という専用
のページを用意して、そこへ飛ばすようにした。
[21:30] 帰宅してからサーバーの様子を見たところ、ps ax とすると
Dynamic DNS を更新するための cron プロセスが 100 近く溜まっていた。
su しようとしてもハングアップしてしまうようだ。本体のシリアル・ポートから
の login もプロンプトは出るものの、途中でハングアップするようだ。
仕方がないので恐る恐る電源を強制切断。再起動すると、fsck が必要と出た。
file system が ext2 なので仕方がない。ext3 に対応しているのだから、
変えておけばよかったが、後の祭りである。
telinit 1 として single user に落としてから fsck /dev/hda1 とした。
多くの修正確認が出て、よく分からないまま全て yes とした。
昔の SunOS で補修作業をしていたのを思い出す。
既存のファイルが消えたりはしていないようだ。
とりあえず立ち上がるようにはなった。
クラッキングされた可能性もあるので、sshd を止めておいて、
明日にでも HDD 内の OS 関連のファイルを更新することにする。
apache 1.3.32
セキュリティホール memo - Apache <= 1.3.32 mod_include local buffer overflow Exploit
proxyとSSIのセキュリティ修正。
どっちも使っていないので関係ないと思われるが、
一応バージョンを上げておくことにする。
コンパイル時間
real 3m50.996s
user 2m59.790s
sys 0m42.400s
php 4.3.9
セキュリティホール memo - PHP 4.3.9 / 5.0.2 releasedとのことなので、
php-4.3.9 に更新。
real 46m6.922s
user 33m11.240s
sys 10m39.770s
たぶん問題ないと思う。
無停電電源
160Wぐらいのテーブル・タップ型の無停電電源を買ってきて取り付けた。
お家サーバーとADSLモデム、8ポートハブとついでにFAX兼用電話機を無停電化した。
充電がまだできてなさそうなので、明日プラグを引っこ抜いてちゃんと動くか見てみる
ことにする。[23:30]
停電
15:00ごろの雷で再起動した。
vncserver が立ち上がっていないのにしばらく気が付かずに、
sshはつながるけど vnc だけ接続できなくなる現象でしばらく悩んだ。
'お家サーバー日記/2004-08-10' にあった再起動時にやらねばならない
リストに従って復旧。
もう夏も終わりだから来年にしようと思ってたけど、やっぱり無停電電源必要かも。
- カテゴリ/OpenBlockS
- カテゴリ/トラブル
メンテナンス日記
[2003/7/23] vncserver と WindowMaker? を入れて、Windows 機から Vnc でメンテナンスできるようにした。
[2003/6/23] qmail の alias メールボックスに、cron 経由で newsyslog から newsyslog: preposterous process number: 32055 というようなメールが１時間に１通届いていることが判明。同じような設定の OpenBlockS 266 では、このようなメールは届いていないようだ。
どうも newsyslog のコンパイルで PID_MAX の値を間違っているようだ。おそらく 30000 以上の pid だとこのような警告になるようだ。以前、syslogd のオプションを変えたかったので、手で syslogd の再起動を行ったのだが、このとき 30000 以上の pid となってしまい、以後ずっと cron 経由で警告を受けていた模様。もう一度 syslogd を再起動して 30000 以下の pid にした。
newsyslogd を作り直せばいいのだが、通常の再起動では、問題が出ないはずなので、このままにしておく。
[2003/6/4] qmail が動き出した。
[2003/5/26] XFree86 のインストールに成功。
[2003/4/25] samba が動き出した。
[2003/4/23] 時刻合わせを自動で行うようにする。
[2003/4/21] http.conf を修正したところ、WebDAV （@ITの記事に詳しい）でアクセスできるようになった。Alias /test/ /home/dav/test/ ではだめで、Alias /test /home/dav/test/ （testの次のスラッシュを取る）にしないといけないなんて、困ったものだ。とりあえず、Webサーバーとか掲示板の遠隔メンテナンスはできそうだ。samba は相変わらず原因不明。
カレンダー
引越しのお知らせ
目次
最新の20件
2005-05-16
2005-03-21
2005-05-19
2016-09-22
2016-01-25
2012-03-11
2011-08-22
2010-03-16
2010-03-10
2009-12-05
2009-09-26
2009-07-09
2009-05-04
2005-05-30
2005-05-26
人気の10件
- counter: 6268
- today: 1
- yesterday: 0
- online: 1
編集:MenuBar
