yu_raku 曰く，"WindowsNTのIISをターゲットにした、Code Redの話題は多くありますが、
ZDNetによると、UNIXでもtelnetdを狙って、似たような手口を使って感染するワーム「X.C」というものが出回っているようです。現在のバージョンでは感染力は弱いようですが、どんな変種がでてくるかわからないので、注意が必要でしょう。しかし、そもそもtelnetdを動かしている時点で、セキュリティなんぞ考えていない？"
「ほれみたことか、UNIX／Linuxだから」といわれないように、日ごろから兜の緒を締めておくべし。
おおっと (スコア:3, 参考になる)
http://www.jpcert.or.jp/at/2001/at010021.txt
http://www.jpcert.or.jp/at/2001/at010016.txt
http://www.debian.org/security/2001/dsa-070
ここら辺の話かな。
うちのでびあんは週に一度は aptitude で upgrade してるので問題なかったみたい。
＃しかし、Solaris マシンも管理してるんだけど…
＃ こっちの in.telnetd は大丈夫なの？
＃SUN は調査中としか書いてないし。
# mishimaは本田透先生を熱烈に応援しています
僕がよく見るのは（Re:先週聞いて） (スコア:3, 参考になる)
- 常時接続の宴
- JPCERT/CC
- CERT Coordination Center
あたりですかね。 （JPCERT は情報出したら出しっぱなしな気がする。 本家とのタイムラグ結構あるし。） あと、各ソフトの公式ページとファンページ（？）。例えば、apache なら、 The Apache Software Foundation とか、JAPAN APACHE USERS GROUP とかですかね。
僕は debian 使ってるんですが、 日本の Linux 情報や Debian GNU/Linux -- ユニバーサルオペレーティングシステム を見てると関係しそうなセキュリティ問題の情報は トップページにだいたい出てますね。
また、debian-ML に入ってると、 debian で用意されてるパッケージにセキュリティ問題が 見つかった時は情報が送られてきます。 （翻訳してくださってる方に感謝）
Kiyotan
inetdのセキュリティホール (スコア:2)
JPCERTの警告
綱引き (スコア:2, 興味深い)
いつも、これが言えたら幸せです。
哀しいかな、経済性、利便性、安全性（+天の一声）の綱引きによっちゃぁ telnetd も動かさにゃならんことも。
もちろん、TCPWrapper やフィルタ必須ですけど。
--gao
Re:綱引き (スコア:2, 興味深い)
telnet を ON/OFF することのよしあしよりも前に，telnetが脆弱なのがこと自体が問題なのでは？
こいつがはじめからセキュアな手段ならよいわけでしょ？ 結局。
Windowsも(あえて)UNIXも，そんなものじゃないですか？
「IISはOSの一部だよ」「telnetはOSの一部だよ」ってどっちがどれくらい間違ってるのかなあ。
-- LightSpeed-J
先週聞いて (スコア:2)
ワームの拡散速度はとんでもないからねぇ。
週末に tcpwrapper 入れないと（まだ入れてないのかってのは許して^^;）。
でもこの x.c って情報が全然無くて分からないのです。
今は落ちているどこかのサイトに依存しているようで、現在は活動できないらしいけれど。
tripwire や netstat で変なものは無いので大丈夫だとは思うけれど。
感染したらどういうことやるのか情報無くて、感染していないという確証が持てない。
どなたか知ってます？
-- wanna be the biggest dreamer
Solarisも怪しい (スコア:2, 参考になる)
FreeBSDで穴を塞いだ時のdiffとSolaris8 Foundation Sourceのosnet_volume/usr/src/cmd/cmd-inet/usr.sbin/in.telnetd.cを比べてみたのですが、Solaris8でも同様の問題はありそうです。
もっとも、diff自体は何とかすれば当たるでしょう。Foundation SourceおよびBuild Environmentを持っているのであれば作り直してしまうのも手です。gccで作れるかどうかは知りません。
Re:綱引き (スコア:2, 参考になる)
これに関しては、Y2Kと同じで一概に当時の人を責めることは難しいです。telnetの実装は4.2BSD(1983)にまで遡ります。
また、今回の問題はあくまで実装にあります。protocolそのものに直接関係はありません。protocolに問題があったらRFC書き直しですな。
Re:先週聞いて (スコア:2)
もちろん僕は使ってるけれど、素人さんに SSH 説明するの面倒でさ(^^;
＞亜種が出てきたらまた何するか予想もつかないんじゃないのかな。
これからの感染は、もう防御したから大丈夫。
今、感染してないか知りたいのだ。
バッファオーバーフローの脆弱性、じゃ感染後に何するのかは全然分からん。
-- wanna be the biggest dreamer
Re:先週聞いて (スコア:2)
たとえば新米のネットワーク管理者や、セキュリティ情報になかなかたどり着けない管理者に対して、セキュリティに関する有用なサイトを示すなど、ある程度誘導するというのも、被害を拡大させないことにつながるかもしれないとも思うです。
# ＳＳＨなども含め、網羅しているサイトであるとか、ここは見ておくと良いというところであるとか、かな？
どなたか心強い先輩が近くにいれば、あまり問題にならないのかもしれないですが……。
-------- SORAMINE Yukino
ふしぎふしぎ (スコア:2, 興味深い)
このtelnetの問題自体についてはだいぶ前からwww.FreeBSD.orgのTopページに掲載されていますし, 今月発売のUnixUserでもバックドアを設けるところまで確認できたと記述されているぐらいですから, 既に知れ渡っている物だと思っていました.
それより不思議なのは, 別スレッドにも有るように, システム上の要件で外部に対してtelnetサービスを提供しなければならないのでもないのに, ポートが開きっぱなしというのはちょっと信じられない無防備さだと思います. 私も内部ネットワーク間ではまだtelnetを使っていますが(sshに移行中です), 少なくとも外部からのアクセスについてはフィルタリングするようにしています.
ところでFreeBSDでもOpenBSDにならってか, inetd.confでデフォルトで開いているサービスがついに4.4からは無くなるみたいですね.
Re:inetdのセキュリティホール (スコア:2)
Re:ふしぎふしぎ (スコア:2)
FreeBSD 4.3R で open だったので驚いてました。
ま、入れてすぐ塞ぎましたが。
おふとぴですが・・・ (スコア:1)
やはり、書き方は重要ですね。
えっ? まだ telnet ポートって開けてるもんなの? (スコア:1)
# telnet コマンドは便利だから使ってるけどね.
自分のトコだけ良ければ,後は知らんというのはイケナイのかも,とちょっと反省しました.
まぁ telnetd に限らず,余計なポートは開けないということで,自分にポートスキャンかけてチェックするようにしましょう.
(ここらへん参考になる?)
masashi
私も拒否されました (スコア:1)
2001-09-11 12:07:08 狂牛病が日本に上陸か (articles,news) (拒否)
同日の 10:38PM のマクドナルドが狂牛病に安全宣言の投稿が採用されるというのが良く理解できない。
さすがに、拒否された内容を、こちらの方に書く気はしなかった。
Slashdot の採用・拒否の判断基準が解らないなぁ、、、
Re:inetdのセキュリティホール (スコア:1)
# xinetd にも最近安全保障穴が見つかったはずですけど
うちの箱は 8/25 頃に chmod -x しました (外には tcp/23 開けてませんけど ssh した後、 local から破られる可能性を否定できないので)。
# telnetd は今週末に入れ替えます。
# procmail も入れ替えないと...
stack-smashing protector (スコア:1)
あいかわらずbuffer overflowが原因のセキュリティホールは多いですね。 これからInternetに公開するサーバ等の用途でUNIXなマシンをセットアップするなら、 stack-smashing protector patch(ProPolice)など、 buffer overflow対策ツールを導入しておくのも検討に値するでしょう。
http://www.trl.ibm.com/projects/security/ssp/
もちろん、このパッチだけに頼りきって本来buffer overflowがあるプログラムを放置する、という運用はあまり感心できませんが(この実装にも穴が見つかったらどうする?)、少なくとも「buffer overflowが原因のセキュリティホールが見つかった」時に、「根本的な対策を施すまでの間、時間を稼ぐ」事はできますね。
NIPCのX.Cワーム警報 (スコア:1)
ただし、このページ自体にはあまり詳しい事は書かれていません。
ポーランドのサーバ (スコア:1)
Telnetdシステムのバッファオーバーフローの問題を悪用して，「x.c.」と呼ばれる同ワームのプログラムのソースコードを，ポーランドのサーバから呼び出して感染したホスト上に複製しようとする。
」の中の、 ポーランドのサーバというのはhttp://mri.am.lublin.pl/ のようです。参照： [NEWSBYTES] Polish Worm Provides Jolt To Unix Operators
Re:inetdのセキュリティホール (スコア:1)
Re:先週聞いて (スコア:0)
どうせなら SSH にすれば？
>感染したらどういうことやるのか情報無くて
確かに。
でも x.c ワームはやること決まってるんだろうけど、穴はバッファオーバーフローだからねえ。亜種が出てきたらまた何するか予想もつかないんじゃないのかな。
それより (スコア:0)
ついでだが (スコア:0)
ついでだが、telnetdだけじゃなくてSSHはバージョンによっては致命的なセキュリティホールがある、っていうことなので、SSH入れてるから大丈夫、なんて思わないようにね。