1999年06月05日()<< 前の日記 | 次の日記 >>
この日の詳細

■1不正中継対策サービス このエントリーをはてなブックマークに追加

ちょっとトホホなセールスの電話が掛かって来ました。
セールスと言いますと、お金を貸しますとか、有利な投資がとか、まぁそういったものが多いんですが、こちらがプロバイダだと知っていて「アセンドのほげほげをお安く」とか「シスコのほげほげをお安く」とか、「比較的対象を選んだ」案内もあります。
そういう案内は、郵政省メールで送ってくれた方がファイリングには便利だし、第一、電話でこちらの都合に関係無いタイミングで売りこまれても「じゃぁ下さい」といえる類の製品ではないだけに、果たして効果あるのかなと思ったりもします。比較的暇な時には、製品の相場を知る上で役に立つことも有るのですが、忙しいときにはやっぱり迷惑です。
件のトホホなセールスは、触っていたソース類をまとめてコミットしている最中の、ちょっと手持ち無沙汰になったタイミングを狙った様に掛かってきました。
「ネットワークのセキュリティのことで」という話だったので、セキュリティがらみのページを上げている以上、私の趣味として時間が避ける範囲だったら、ある程度の相談には応じようと言う考えもありますので、比較的親切に話を聞くモードに入った訳です。
「御社はプロバイダーをされているということでご案内させて頂いているのですが、インターネットでのセキュリティに関心をお持ちでしょうか?」
「はいもちろん」(あちゃーセールスだったぁ・・・)
「実はですね。この度弊社ではプロバイダ様のセキュリティ対策を、アウトソーシングという形でお引き受けするサービスの提供を行っておりまして・・・」
ところで、ウチにネットワーク系のセールスで電話が掛かってきた場合、会社名からすかさず検索を掛けていまして、この頃までにはその会社のページを見つけ出してあります。したがって、この後展開されるセールスの内容も大体分かってはいるわけですが、時間掛かるmakeも走っていることだし、まぁ話を聞いてみようかなぁと思いました。
「最近、SPAMとかポートスキャンとか問題になっていますよね」などと水を向けてみますと、
「ハイ、弊社ではそういったプロバイダ様のセキュリティ問題の調査をですね・・・」と、予想どおりのメニューをしゃべり出したので、端末から dnswalk[http://www.nanet.co.jp/~kei/diary/glossary.html#dnswalk] 掛けてみたり、MXの設定なんか見てみると、あんまりレベル高そうに思えない。
後ろで作業をしながら生返事をしていたら、「・・・最近、不正中継が問題になっているんですが、ご存知ですか?」ウチの会社のページを読んでいたら、ちょっと尋ねそうにない質問が出ました。腹が立つというよりも、実は内心嬉しかったです。どういう順序で指摘すると面白いかなぁと思って。
「ウチの会社ではきちんと対策してると思うんですけど。」と若干控えめに答えると、「実は皆さん被害に遭われてから、対策していたとおっしゃるんですが、不充分な対策が多いんですよね。弊社では信頼できるテスト方法を用いて、テストを行なっておりますし万が一問題がございましたら、弊社の方でセットアップをお受けするということも可能になっておりますので、ぜひ一度検査だけでもお申しつけ下されば。」とおっしゃる。
料金掛かるんですか?って聞いてみたら、掛かるという。
なんか、マニュアル読まされてるみたいで、こっちの話題に乗ってくれないんで、気が向いたらメールを送りますってメールアドレスを聞き出して、さっき探したドメインで間違い無いことだけ確認しときました。
ちなみに、料金を聞いたら、検査のみでサーバー1台あたり3万円。インストール料金は別途見積もりとのことでした。
営業で電話掛けて書類作ってっていう費用を考えると、ボッタクリという訳じゃないと思います。そういう商売もあるでしょう。
お金を払ってやってもらった方が良い方は、安心をお金で買ったと思って頂いても良いんですが、自分とこのサーバの設定を見る限り、技術力そんなに高そうじゃなかったのも気がかりです。
もう一つ気がかりなのが、この会社、やたらとウチの不正中継検査サービス使ってるんですよね。ひょっとして、自分とこの診断に自信ないのか知らん。
ウチの立場を名乗って、相手を赤面させる計画が不発に終わったんで、腹いせにその会社名書いちゃおうかと思ったんですが(最初の原稿では、推察できる情報が十分あったんですが)、気になって調べてみたら、以前、ウチにちゃんとことわりのメールをくれてたんですよね。
「弊社のお客様に、御社の不正中継診断の結果を紹介させてもらっても良いでしょうか」っていうんで、「もちろんOK」って返事してありました。
まぁ嘘付いてる訳じゃぁないから仕方ないです。ということで、道義上、会社名出すのは止めておきます。
但し、もしこれを読んでいたらお願いです。そういう営業やってもらうのは構いませんが、先に自社の設定はきちんとした方が良いと思います。

■ 関連記事

詳細はこの日の詳細から

1999年06月18日(金)<< 前の日記 | 次の日記 >>
この日の詳細

■1ディスククラッシュとクラッシュダンプ次の記事 >> このエントリーをはてなブックマークに追加

サーバーのディスクが壊れました。非常に運が良いパターンで「変な音がするなぁ」という前兆があり、「さすがに弱いマシンだから(Cylixの166M)移設しよう」と決意して、新しいマシンにミラーリングを済ませ、設定を変更して再起動した直後の出来事でした。
ミラーしたサーバの起動と設定を確認しただけで、問題解決。長いことがんばってくれた上に、これ以上はないという美しい引き際を見せてくれたサーバーさんに感謝しました。
恐らく実際のところ、危険な状態でかろうじて動いていたところに、ミラーリングで全領域を読みとって負荷を掛け、さらに電源断を経験させたので一気に問題が発生したというシナリオであると思われます。
ある程度のバックアップは取ってありますが、ローテーションの中から順番に差分を当てていくのもそれなりにうんざりする作業なので、本当に助かりました。
久しぶりにカーネルパニックを経験したんで、ちょっとだけクラッシュダンプを解析してみることにしました。
クラッシュダンプとは、UNIXマシンが落ちる(こと自体まれですが)時に、それなりの設定がしてあって、少々運が良ければ手に入る検死資料です。
これを入手するためには、それなりの前準備が必要です。こういう準備をしてなくてクラッシュした場合は、現場に残されたごくわずかな痕跡(ファンに埃がたまっていたとか)と(もしいれば)目撃者から死因を推定することしかできません。
今回の場合、もはやこのディスクでブートすることをあきらめないといけませんから、coreの保存に一工夫必要です。
他のマシンに持っていって、同じカーネルを用意して、savecoreを手作業で掛けてやることになります。
入手したcoreダンプから何が分かるかといえば、ものすごく奥が深いウィザードの森の住人たちは全てが分かるようです。
kgdbによるカーネルのクラッシュダンプのデバッグ[http://www.jp.freebsd.org/www.freebsd.org/ja/handbook/kerneldebug.html] を読んでいただくと良いかと思いますが、ある程度の知識があれば、なんたらいうOSとは違って、「何が起きたのか」程度は確実に知ることができます(もちろん直す事もできます!)。
そこまで行かなくとも、stringsを使って、表示し切れなかったpanicメッセージを読むだけでも、大体の原因をつかむことができるでしょう。

■ 関連記事

■2おまけ - クラッシュダンプを得る方法(FreeBSDの場合)<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

まずswapのサイズが物理メモリよりある程度(64KBytes)大きい必要があります。最近では以前の様に物理メモリの倍等というswapを取らないケースも多いですが、クラッシュダンプを取りたい場合は、ある程度のswapを確保しておく必要があります。
なおダンプ先をswapに用いるファイルシステム以外に設定することはお勧めできません。
次に、そのデバイス名を/etc/rc.confのdumpdevに指定します。再起動しない場合は、dumpon -v [デバイス名]を実行します。
標準のスワップ先以外のファイルシステムを指定した場合には、うまく行かないかも知れません。
さらに、/var/crashというディレクトリがあり、クラッシュダンプを格納するのに十分な容量が必要です。
以上の条件が整っていれば、カーネルがクラッシュした時に、ディスクを低レベルにアクセスするだけの余力が残っていれば(大抵は残っているので)、全メモリイメージをdumponで指定したデバイスに書き出します。
次回起動時に、savecoreが/var/crashにコアダンプを保存してくれるという仕掛けです。

■ 関連記事

■3追補<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

8.4GB以上のIDEドライブを繋いでいる場合、FreeBSDのバージョンによっては、間違った位置にカーネルダンプが書きこまれてえらい目に会う・・・といった問題があったように思います。ポインタ載せようと思ったのですが見つけ出せませんでした。8.4GB以上のIDEディスクを繋いでる人は注意。2.2.8は多分大丈夫。3.0Rは確か被害者が出てた。

■ 関連記事

■4NT+IIS4.0に対する侵入コードの公開<< 前の記事 このエントリーをはてなブックマークに追加

今回は二本立てでお送りします。
既に色々なところで報道されていますので、ご存知の方も多いかと思いますが、 「NTのセキュリティホールを指摘,侵入コードを公開したeEye(ZDNN)」[http://www.zdnet.co.jp/news/9906/17/nt.html] という問題が指摘されています。
NT+IIS4.0が導入されていて一般に公開されているWebサーバーであれば、侵入者が任意のプログラムを送りこんで実行させることができるというとてつもない問題です。
侵入には、httpを使いますので、ほとんどのファイヤウォールを透過的に通過してしまうわけで、これを何とかしようと思ったらアプリケーションレベルのプロクシーを動作させて、危ないURLの書き換えをやらせる必要があります。
例えばApacheにmod_rewriteでも仕込んで、送られてくるURLをチェックした上で変換してNTのIISに渡してやるような仕掛けになります。もちろん、ここまでやるんだったらWebサーバーごとApacheに引っ越す方が頭の良いやり方に思えます。
上記のプログラム(iishack)はソースコードも公開されていますので、この週末あたりからスキャンを含めたアタックが活発化するものと思われます。実際、弊社が管理しているサーバでも、エージェントが怪しいHEADのスキャンを見つけました。NT+IISをアドレス空間全検索で探している様に思われます。どういう攻撃を仕掛けてくるか、IISを名乗ってみようか知らん。
NT+IISを導入しているサイトでは、ここしばらくは運用を停止するか十分な監視をしないといけないでしょうね。

■ 関連記事

詳細はこの日の詳細から

以上、2 日分です。

指定日の日記を表示

前月 1999年06月 翌月
1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30

最近の日記

2019年04月01日

新元号「令和」について

2019年03月23日

DXアンテナ ワイヤレスチューナー メディアコンセント DMC10F1

2019年02月17日

#例のグラボを活用する

2019年01月03日

シリーズ5・myHomeAlexaで自分のCDをかける

2018年12月25日

シリーズ4・英語の楽曲・アルバム・アーティスト名をカタカナに直す

2018年12月23日

シリーズ3: Echo Dotがやってきた

2018年12月19日

続・Echo Dotがやってきた

分野別タイトル一覧


全て
CLIP
SYA!nikki
book
freebsd
hns
magic
おさけ
おしごと
お買いもの
ぐる
ごはん
アクセシビリティ
オープンソース
セキュリティ
音楽
地域情報化
電子自治体
日記

keikuma on Twitter

keikuma Name:前田勝之
Location:長崎市
Web:http://www.nantok...
Bio:前田勝之(まえだかつゆき)。長崎在住。コンサル、SE、プログラマー、 なんとか株式会社代表、非常勤講師(情報セキュリティ)。 セキュアド、テクニカルエンジニア(SV,NW)。サーバ管理とWeb日記を10年ほど。 ネットとリアルの接点に関心あり。食べること・歌うこと・愛すること・作ること・飲むこと。おいしいものがぜんぶすき。

サイト内検索

Google AdSense

Powered by hns-2.19.9, HyperNikkiSystem Project