トップレベルドメイン

　勤務先サーバー群の監視作業ってのがモチベーションの減少と共に頻度が低下しているのだけれどさすがにUTMと自作防御システムのおかげで以前よりはインシデントの発生頻度が激減しているのはとても助かる。

　しかし最近初めてお目にかかるトップレベルドメインが増えてきた気がする。
　まあ、国内からの不正なアクセスは本当に減っていると言うか最近は滅多に発生しないので逆に網にかかるとびっくりしたりする。
　驚くのはこれまで発展途上だと理解していた国やネットワーク網など普及していないのではないかと考えていた国からアクセスが発生することだ。

　今年に入ってから発生したお初の国々は、特にヨーロッパが多かった。しかし昨日Fijiから発生した。これは珍しい。ホルマリン漬けにして標本にしましょうかね。


　不正とは言ってもリアルタイムでほぼブロックされるため実害は出ないのだが、正直な気持ちはなんでこんな正常な手順を踏まないのかと疑問なのである。
　SMTPへの接続試行が典型だが、ご挨拶なしにいきなりIDをまさぐってくる。挨拶が出来ていても存在しないアカウントへ何度も接続を繰り返すのも嫌だが、やはり手順を知らない輩は腹が立つ。世界規模で決まっているルールも守れないやつはあからさまにブロックしても一切躊躇はない。


　こんないたずらや不正が一切ないネットワークに出来ないものだろうか。
　世の中から不正アクセスやウィルスが無くなって、セキュリティツールなんぞに頼らなくてもみんなが安心してネットワーク出来る世の中になって欲しいとずっと願っている。

swatchのその後

　予期せぬ不正なアクセスからネットワークを保護する目的で長年取り組んできた監視作業をいくらかでも軽減しようと監視と制御を自動化する仕組みを作り上げて約四週間。実は仕組みが完成してからなかなか本物が訪れなくて検証が十分ではなかった。

　そんなある日、稼働し始めて二週間後だった。突然予測していた行為が発生。自動化スクリプトは見事に反応し、期待通りの働きを見せてくれた。我ながら悦に入ってしまった。
　ただ、この時の相手が国内のIPだったため、プロバイダへ連絡させてもらった。もしかすると踏み台にされていて、ほかの誰かも迷惑をこうむるかも知れない。もしかすると犯罪に結びつくかも知れない。そう考えたからだ。


　その後一週間ほど経過した25日。世の中は日曜日。相方はお仕事だったため、お迎えに行って帰宅した直後の出来事だった。
　いつものようにスマートフォンをポケットから出してテーブルに置いた瞬間、メールを複数受信したようでバイブが響いた。「何だろ？」と開いてみるとサーバーから不正アクセスのアラートメールが複数届いていた。その数約300通。
　「あれ？ブロックできていないのか？」と慌ててパソコンを取り出し、従来の監視作業と同様に手動で制御作業を実施した。
　自動化システムの出力データやログを確認すると、どうやら今回は正常に機能していないことが分かった。なんでや？

　3月4日に完成してリリースした際に対象とした「不正アクセス」はサーバーのメール送信システムに対する行為を検知するものだった。実物で検証出来た際もそうだった。ところが今回はメール受信システムへの行為だったのだ。デーモンが異なる。
　しかしどちらのサービスであっても制御ができるように考えて作り上げたつもりだった。

　あ～あ、なんで期待通りになってくれないんだ。

　念のため送信システムへの制御システムを検証した。正常に動いている。
　では改めて受信システムへの試験・・・
　いつまでたってもブロックしない。

　う～ん
　これは参った。

　仕組みとしては、
　1.不正なアクセス発生
　2.不正行為の決まったキーワードがログに記録されるとswatch監視システムが発動
　3.該当ログをファイルへ吐き出す
　4.吐き出されたログから相手IPアドレスを拾い出す
　5.制御システムへこのIPアドレスを送り込む
　6.該当サービスを再起動させる

　この手順の中で、3.の「ファイルへ吐き出す」部分が動いていない。
　ログを見るとファイル吐き出し手順はスキップされているように見える。その後の手順は流れている。
　なぜここだけスキップされるのか？

　悩むこと数日、あれこれ試してみるがなかなか答えにたどり着かない。
　毎晩床に入ってもこればかり考えていた。


　今日は考えられるあらゆるファイル出力要素を列挙し順番に試してみた。
　ここでふと気づいたことがある。
　手順の中でswatchは該当ログを標準入力で扱い他のコマンドへ引き渡している。しかしこのログがルールにマッチしているかどうかの評価の段階で、万が一ルールに不適切な文字があった場合に排除する「置き換え」がある。ここがどうも正常に機能していないと考えた。
　よく考えると以前悩んだ問題もここだった。ただし”権限”と言うテーマで前回は問題をクリアした。
　今回はログが拾えない理由をログの中身だと考えた。

　メール送信システムでは接続してきた相手先のIPアドレスを鍵括弧でくくる。[192.168.1.11]みたいに。
　しかし受信システムは普通の括弧でくくる。(192.168.1.11)みたいに。
　この括弧を犯人だとにらんだ。

　括弧は世の中の多くのプログラムや正規表現などで特殊な意味を持つ場合が多い。従ってログが正常に取得できない状態に陥る可能性はあるはずだ。

　と言う訳で、swatch本体プログラムの解析へ突入。
　本当はこんな完成品に手を加えるのはよくない話なのだが、他の方法を知らない私としてはまず試してみるべき行為と判断した。

　ログを取得し、次のステップから各コマンドへ引き渡す、と言う部分で括弧を鍵括弧へ置き換える処理を追加した。

　結果は見事に成功。

　誰かプログラムを書き換えずにこの括弧を置き換える処理をご存知でしたらぜひとも教えてください。あ、もちろん「swatchのバージョン換えろ」は無しね。。。

何となくそれらしく

　二日前に書いた swatch に関するその後である。
　問題は自動起動した際の swatch が tail で追跡したログの一行の中身を送り込む際に、相手のIPアドレスの部分だけが消えるために自動制御しようとしても出来ない事で悩んでいたのだった。

　自動起動した際には正常に取得できないのだが、 swatch を手動起動した際には何故か正常に取得できる。
　まずはこの現象から自動起動のケースと手動起動の起動スクリプトを解析することにした。
　結果、どちらのスクリプトも全く同一であることが分かった。

　そこで冷静に現状を考えてみた。
　自動起動は管理者権限で他のサービスと同様に起動する。起動順序もほぼ一番最後に上がるようになっている。通常では他のサービスが影響しているとは考えにくい。

　手順を追った。
　1.自動起動は指定した順序でサービスを次々立ち上げる。物によっては起動する権限やユーザーが異なる。
　2. swatch が起動すると、対象のログファイルが変化した瞬間を捕まえる為に tail が起動される。
　3.ポリシーと一致した部分を見つけると swatch が発動し、設定した行動を起こす。

　ここで一つの可能性を疑った。
　起動する権限が強すぎてシェルなどを置き換えする内部ルーチンが悪さしているのでは無いか。

　そこで自動起動するユーザーを管理者以外の設定に置き換えることを考えた。
　その為に施さねばならない設定はいくつかあるが、まずは通常スーパーユーザーしか閲覧できないログに他のユーザーでも閲覧できる設定を施す。
　しかしセキュリティ上全てのユーザーと言う訳にも行かない。そこで特定のグループに権限を与える。
　次に起動時の各種設定ファイルも管理者から指定ユーザーの権限へ移し、ファイル自体も全て移動する。

　自分で作ったプログラムやシェル、バッチ類も全て中身を変更しテスト開始。

　まずはコンソールから起動する。
　これは前述の”手動起動”と同じ手順なので予想通り正常に目的物を取得できた。
　次に自動起動を確認する。


　成功した。

　これで長年悩んできた一つの大きな問題が一歩前進する。

　ふぁぁ、疲れた。。。

はまるはまる

　久しぶりに書いてみたくなった（笑）
　って「久しぶり」って言うのは書く側の話で、見る分には前回からどんだけ間があいているかは関係ないのか。ってのは前にも書いたか・・・
　前置きはいいとして今回書きたくなったのは手ごわいやつを相手にしていて、なかなか問題が解けないから。

　さて物語の開始。

　ずいぶん以前から「監視作業」なるものを昼夜問わず実施している。
　これは2000年冬に実際に体験したサーバーへの不正侵入（ http://www.worldstep.net/terakoya/linux/secure.html )から高い頻度の監視作業が必要であると痛感したからである。
　完全な運用と言うのは、必要かつ十分なポリシーの策定と最適な管理手順で成立するものと信じている。これらを学んだ機会がその不正侵入だったのだ。
　その事件以来、どうやったらセキュリティレベルを向上できるのか、どうすれば不安から解放されるのかをずいぶん考えて来た。
　その第一歩はルータの設定ファイルの有効活用であったが、当時の安価なルータはフィルター設定にも限界があり、増大する不正行為すべてには対応できるものでは無かった。

　そこでFirewallの自作と言う自分の知識や技量をはるかに超えたとんでもない作戦を採用し、実際に構築した。
　しかしそもそもFirewallにしてもポリシー設定（定義ファイル設定）は手動が前提である。我々には二本しかないお手々でせっせと書くしかできないのであった。
　それでも不正な試みをルータやサーバーのログから認識し、制御ポリシーを更新する作業は楽ではなかったが充実していた。

　当時から不正行為の検知目的で "swatch" と言うプログラムを利用していた。このプログラムは指定したログに設定したキーワードが記録されると警告として知らせてくれる便利なものだ。このおかげで作業の効率は格段に向上したのだが、アラートは昼夜を問わず発生するため実務的にはきついものとなっていく。

　深夜や休日の早朝に発生するアラートへの対応などを繰り返しながら二年ほど経過して、手元にパソコンが無い外出時などの対応に苦慮することになる。　特に毎年春のGWに一週間ほど田舎の祭りのお手伝いをしていたことで、その最中に発生するインシデントに対応できない問題が浮上した。
　普段の外出でもPCを持って出る習慣はあったので、当時PCに接続できるPHSを使って制御は実施出来ていたが、お手伝い作業を屋外で行っているとリアルタイムな作業はほぼ不可能だった。
　そこで監視と制御作業の自動化を検討し始めた。
　当時はPDAも持っていたので、まずはPDAでも作業ができるように検討し始めたのだが、実質屋内作業を外へ持ち出しただけだったので面白くなかった。そこで前述 "swatch" に協力を仰いで自動化検討を開始。
　ある程度うまく運用できていたとは思うが、実際には手におえないケースも続々と出てきてクラッカーたちの技術的なレベルアップの速度に対応するのが苦しい状況だったのだ。

　その後2007年になってから勤務先に投資増大を無理やりお願いし、UTMの導入となった。実はこいつは無敵ともいえるほど高機能なソリューションで、ほとんどの不安を解消できるものだった。実際に今でもその効果は大きなものがある。
　しかしながら依然としてインシデントは不定期に発生し、嫌味な奴だなと思うほど弱点を探しつついてくる。今のところは爪楊枝でつついているレベルだが、そのうち最先端のミサイルを撃ち込んで来るに違いない、と言う不安が日増しに大きくなる。
　UTMといえどもやはり設定は人間の目と手で行う。ここら辺がじれったいところだ。

　UTMの登場から一時的に停止していた "swatch" を再検討することにした。
　ただ、UTM登場前にFirewallと共に運用していた "swatch" が稼働する環境は FreeBSD だった。現時点で "swatch" を稼働させようと言うのはLinuxである。環境の差はある程度埋めることが出来ると理解していたこともあって、躊躇はなかった。

　"swatch" は期待通りに動作する前提で自動制御プログラムの開発に着手した。
　約二週間で完成し、テスト結果も好感触。これで夜中の作業が無くなるぞ。と思ったのもつかの間。実は "swatch" の動作が期待通りではなかった。


　ここからが本題である。長い前置きだ。まあ自分用の記録だからここまで読んでくれる人はいないだろう。

　"swatch" が期待通りではないというのは、実はほんの一部分だけなのだ。しかしその一部分が一番重要な部分。

　一般的な不正とまではいかないけれど、迷惑な行為はメールサーバーへの接続試行である。
　古めかしいsmtpだと、まずはご挨拶から始めていただくことになるが、挨拶なしでいきなり本題を送りつけようとする方がいらっしゃるのだ。
　こいつの制御をまず試した。
　その際のログは「ご挨拶がない方が来ました」と発生し、メールも届く。
　そのログの一行を記録させるスクリプトが自動的に動作する。

　ところが！！！
　記録されたログの中身は届いたメールと少し違った。
　肝心の相手のIPアドレス部分だけが消えるのである。
　この現象は既に約二週間ほど私のちいさな脳みそを惑わせている。

　なんでこんなことが起きるのだ？
　ネットを検索しても同様の現象が発生している報告にはたどり着かない。
　これはいささか参った。降参したいのだが先へ進みたい欲望の方が強い。
　とにかく原因を探らなきゃ。
　というわけですったもんだしているのである。

　現在 "swatch" 本体の解析を行っているところ。
　実は "swatch" を自動起動させるとこの現象が発生するが、コンソールから手動で起動するとこれが発生しない。
　そこでサーバーがスケジュール再起動した朝に手動で "swatch" を再起動させるマクロを走らせることで回避している。
　現時点では正常稼働している。

　どうしたものかねぇ。


　そういえば世界的なクラッカー集団 Anonymous はこの3月31日にインターネットをダウンさせると犯行予告しているとか。ルートサーバーをダウンさせる手口をもくろんでいるようだ。現実的ではないと感じてはいるが、本当に止まったらどうなっちゃうんだろうね。

2012年

　明けましておめでとうございます。
　なかなか更新しない（と書いても、頻繁にチェックしていない側からすると関係ないか・・・）ブログですが、今年もよろしくお願いいたします。


　私の誕生日は12月7日なのです。この日は歴史上でとても重い日です。
　日本時間は12月8日ですが、米国からすると1941年のこの日予想外の出来事がありました。
　真珠湾攻撃です。

　私は戦争というか争いを好みません。そんな人はいないと信じます。
　しかしこの日を境に米国は戦力を強め、結果的に日本は敗戦国となったのでした。

　この攻撃で日本は数十名の戦死者。米国は数千人の戦死者を出すこととなったそうです。


　1986年春、慰安旅行で真珠湾へ出かけました。
　真珠湾攻撃の物語など何も知らない頃です。
　しかしアリゾナ記念艦へ渡る船に乗る前の説明を聞いていて背筋が寒くなったのを今でも覚えています。
　このまま船に乗ったら、殴られるのか、罵倒されるのか、どんな目で見られるのだろう。
　そんな不安はすぐに消えましたが、約一千名の戦士たちと沈むアリゾナ・メモリアルの上に立ち戦死した戦士たちの名を刻んだ石を眺めているうちに涙が止まらなくなりました。


　今相方がハワイへ行く計画をしています。実家の家族と共に出かけるようです。
　「アリゾナ行ってきてくれんか」
　「本土へは行かないよ」
　「真珠湾だよ」
　そんな会話を交わした後で、「自分で行かなきゃ」そう強く感じた。


　2011年は思いもよらない災害が日本国土を襲い、いろんな方面へ大きく影響を及ぼした。
　だけど、戦争の影響に比べたら。いけないことかも知れないけどそう感じた。

　どうか2012年は幸せを感じる人が増えてほしい。
　あちこちに平和を感じる人に増えてほしい。
　そう願うばかりです。

　多くの皆様にとって、平和で幸多い年になることを心から願います。


　

カレーなる日々

　思いつきで始った「カレーを何日食べ続けられるか」

　小休止が入ったものの、まずは約三か月間続いた。
　ただし夕食限定。

　偏りも問題ありだと思うけど、気が向いたらシチューや鍋や外食を取り入れていたので健康的には問題ないと思う。



　そしてまた再開。

　今度はどれくらい続くのでしょう。



　正直カレーは大好きなので結構うれしかったりする。

　これから寒くなる季節なので身体も温まっていいとも思う。




　唯一の不安は、身体がカレー色になるんじゃないかってことだけ。。。

9月19日〜9月25日に投稿したなう

yeuxさんの投稿したなう

「再起動」 http://ameblo.jp/des-yeux/entry-11028925116.html

9/25 13:36

>>もっと見る

再起動

　0311から半年が過ぎた。あれから気持ちを文字に表すことがうまく出来なくなってブログの更新も中断していたが、そろそろ再開しようかと考えている。
　まあ、話題はもっぱら仕事関連になるか。

　とりあえず再起動第一弾。

　実は５月の青柏祭の写真も放置状態だったが先日ようやく整理した。
　http://dekayama.worldstep.net/


　最近の出来事と言えば、やはりサーバー絡みかな（ってやっぱ仕事かい！

　Linuxサーバーだけど、アプリケーションをバージョンアップする作業が予定されていて、データベースのバックアップを実施する必要が出た。
　ところがこのサーバーのディスクはあまり余裕が無く、大きなバックアップは某か技を使わないと不可能。残念な事にバックアップ用のデバイスも搭載していないのだ。
　ここで考えたのがネットワークドライブの割り当て。
　Windowsなどでは比較的メジャーな方法だが、PC-UNIXがもともとベースになって作られたものだったはず。
　と言うわけで早速ネットワーク上で余裕のあるサーバーの共有エリアへ接続し領域としてマウントする。
　試しに一つのデータベースだけDumpを作ってみる。成功。
　中には巨大なデータベースも存在するため夜中に自動処理してもらうように設定してスキップしながら帰宅した。

　ちょっと心配になって休日の翌日出社して確認するとバックアップされていない。
　ふむ。。。
　まあ、シェルスクリプトの権限を誤ったようで再度やり直し。
　今度は試しじゃなくて目の前で本番やっちゃえ、って事で自動処理設定。10分もすると動き出すはず。
　動き出してしばらく様子を見ていたが、途中で止まった。

　ん？

　調べるとLinux側からマウントしたネットワークドライブは2GB以上のファイルは転送できないと言う制限があるそうだ。
　そんなの聞いて無いぞ！！！
　今回は相手もLinux。
　sambaを確認すると2.0でこの現象が話題になってToDoへはリストインしているようだ。
　しかし今回触っているサーバーたちは3.0だ。って事はまだFIXされていないのね。。。
　どうやって回避すればいいのか？smbmountしなければ、smbfsを使わなければいいのかな。
　と迷っていても仕方ないのでPostgreSQLのデータベース一つずつDumpするようにスクリプトを変更。
　とりあえず全て1GB以内に収まったので当面はよしとしよう。

　という相変わらずの日々を送るのであった。

3月14日〜3月20日に投稿したなう

yeuxさんの投稿したなう

牡鹿半島周辺の離島の捜索はどうなっているのだろう。。。

3/17 16:38

上海万博で壁を登っていたロボット君は福島原発の壁は登れないのか・・・

3/17 16:39

もうちょっと最新兵器に登場して欲しい。がれきの下の捜索とか出来るロボットなんてテレビで紹介されていなかったか？

3/17 16:40

うむ・・・省エネ省エネ・・・

3/17 16:41

>>もっと見る

歩留まりと悪循環

　よく仲間と効率をテーマに会話する。多くは雑談だけど。
　勤務先には生産現場が無いから社内全体で意識が薄いのは仕方が無いかも知れないけれど、流れ作業や分担作業で構造が出来上がっている現場ではどこかの歩留まりが全体に影響する事はよく知られている。
　”かいぜん”の要はこの部分がかなり多くを占めていて、一つずつ片づける事で次の歩留まりを発見出来るようになる。
　”なぜなぜ”で精度を高めると各工程の効率がぐっと向上する。

　でも部分的な改善で満足してしまうと全体効率がちっとも向上しない事に気づかない。
　これが実は大きな問題なのだな。

　一般的な企業ではサービス部門がほぼ確実に存在する。
　人事や経理などに携わる部門。
　会社が小さな間はコミュニケーションも問題視されず、声を上げればみんなに響くから緊急時も対応しやすい。
　このサービス部門が大きくなるにつれて問題は深刻化してくる。
　まさにドラッガーのマネジメントに出て来るシーンだな。

　勤務先が直面している問題がまさにこれだと感じている。
　これを打開するには大局的な見地で対応できる役職に期待するだけでは難しい。
　全員の意識が重要なはず。



　昨晩、23ある拠点の一つの事務社員からメッセージが入った。
　「○○部の□□さんってどういう人ですか」
　なんでおいらに聞いてくるのか疑問だったがとりあえず電話で尋ねてみる事にした。

　現場は日々お客様だけでなく、膨大な商品や現金、社員より多いパートさんたちと格闘している。まさに「タイム・イズ・マネー」の世界で時間価値＝付加価値の世界だ。
　実績のエントリや顧客対応で繁忙な午前、○○部から電話が入った。

　「△△の件ですが、こちらの集計と一致しません。どこに誤りがあるか大至急調査確認して下さい」
　「今、実績エントリと商品注文を実施していますのでしばらくお待ちいただけますか」
　「あなた方の作業は待ってくれるかも知れませんが、こちらは銀行へ資金移動を依頼するのに期限があるので待ってくれないのですよ。急いで下さい」


　特に違和感の無い会話のように見えるが、作業スケジュールが詰まっている現場事務からすると、このような突発的な依頼は歩留まりを起こす。
　ここで仮に一時間を要してしまうと、最終作業が確実に一時間以上遅れる。
　現場の事務担当はそんな事を十分理解している。


　サービス部門から現場はどのように見えているのか。
　現場の収益でサービス部門が運営されていて、現場が物や人を動かさない限りサービス担当の仕事は無い。

　”彼ら、彼女らのおかげで仕事をさせて頂いている”としっかり理解できれば上のような会話は出てこない。

　この些細に見える”歩留まり”が企業の屋台骨まで揺らす。
　忘れてはいけない。



　電話した事務社員。
　途中で何度か涙声になった。つらかった、悔しかったのだろう。
　しかしこのような問題を改善しない限り全社員が明るく楽しく前向きに仕事なんか出来ない。

　つくづくそう感じた夜だった。