感じのページ作ってみました。 @shien_R氏との共同作業。 Colorful SHARP 作っていて、phpのデバッグにしにくさと、入力の判定の大変さを感じたことがでかいです。 あと、これまであまりプログラミングしてこなかったので作るのに時間かかりました。 ちなみに#以外の記号でもできます。 まだ問題アリなのと、追加したい機能があるので、時々アップデートしていきます。 「こういう風にしてほしい」 とかいう意見は歓迎なのでアイディアください。 お願いします。 追記 そういえば、今週土曜日はオープンキャンパスです。 どうやらストーキングツール組が発表するという話を聞きました。 「発表中に攻撃してみるなんて面白いのでは」という電波も同時にキャッチしました。 どうなることやら。

「学科ではネットワークに繋がるために必要なIPアドレスやゲートウェイなどの情報を自動で割り当てるためのプロトコルであるDHCPを使ってネットに繋ぐために、MACアドレスをシステムに登録します。DHCPではなるべく一度繋がった機器に対して同じIPを振るようになっていますがIPが変わってしまうこともあります。それは再起動を行ってキャッシュがクリアされた時やDHCPが持っているIPアドレスの範囲がいっぱいになってしまった時に使われていないIPが振られるといったときです。IPが変わるとサーバ用途で使いにくい、などの理由からMACアドレスを登録することによってMACアドレスに対して同じIPアドレスを振り続けられるようにし、サーバ用途なPCでも安定的な利用ができるようになっているわけです。IPアドレスが変わるとなぜサーバ用途で使いにくいのか、というと話が若干それてしまいますが、DNSとの連携が理由として挙げられます。定期的にIPが変わってしまうようになると一度設定したホストに対してIPアドレスを変更する必要がある上に、DNSレコードが伝搬されるのには時間がかかります。DNSレコードの伝搬に時間がかかる、というのは学科を例に挙げると、VM申請をしてホスト名も登録したのにsshでそのホスト名でログインできないということを経験したことがある人も居ると思います。それはDNSのレコードの伝搬に時間がかかっているためです。IPアドレスでsshアクセスするとしっかり通信する、というのはホスト名を貴方が参照しているDNSサーバが知らないためです。話はそれましたが、そのため、サーバ用途で機器を使用する際にはIPアドレスを固定するのが一般です。逆にサーバ用途でもないのにグローバルIPをstaticな状態にしている学科はセキュリティやらの観点的に言えばかなり問題があるとは思いますがそれはさておき、MACアドレスは世界で一意なアドレスであるためにIPアドレスが被るということは基本的には発生しません。ちなみにMACアドレスの最初の3オクテットはベンダIDを、後半の3オクテットは機器IDを指しています。なので最初の3オクテットで調べるとそのMACアドレスがどこのベンダのものなのかがすぐに分かります。安定したIPアドレスの供給をDHCPで使うために登録されたMACアドレスはMACアドレスを登録したユーザ名と一緒に学科のDB(データベース)に保存されています。DHCPが振るIPを固定化したい場合はleaseファイルというファイルに直接書き込みますが、学科ではそのときにDBにもそのMACアドレスを保存しています。なぜDBに保存しているのか、というと実はよく分かってません。DBを使っているのはDNSとデータベースの連携をしているためで、そのために必要な情報といえばIPとホスト名くらいなものなわけでとか考えていましたけど実はDNSには結構なレコードの種類があって、で、その種類とか諸々を挿入・変更・削除しやすいDBを使って管理しているってことなんだろうか、と書いていて思いました。でも結局DBにMACアドレスを保存するのは謎で、DNSに必要なIPアドレスとホスト名とレコードのタイプがあればいいじゃん、ホスト名って言ったけどレコードのデータじゃん、とかって思いましたけど学科ではそういうの全部webで管理してましたし一台一台をしっかり把握するっていう意味ではMACアドレスを使うってのは理に叶ってるな、と思いました。実際上述した通りMACアドレスってのは世界中でただ一つのアドレスな分けですからね。そんなこんなで話それまくりなんですけれど、矛側は、このDBにアクセスするという権限が与えられています。DBといっても結局テーブルで分けられているわけで、ストーキングツール側がこのDBの全ての情報にアクセスできる、っていうわけではないはずです。今現在は、ですけれど。ちなみにストーキングツール側が取得している情報はMACアドレスとユーザ名と更新日くらいなもののはずです。これも今現在は、という制限つきなんですけれど。怖いところはこれから仕様が変更される可能性があるってことなんですけれど、その辺はお得意のソーシャルエンジニアリングでどうにかしたいと思いますｷﾘｯ。で、ストーキングツールはこれだけに飽き足らず、というかこれだけでどうやって個人特定するんですか、っていう話でもあるんですけど、各部屋のスイッチから定期的に情報を取得することもしています。これを実現するプロトコルはSNMP(Simple Network Management Protocol)といって、IPネットワーク上のネットワーク機器のマネジメントや制御を行う方法を定めたプロトコルです。このプロトコルを用いてストーキングツールでは定期的にスイッチに繋がっているネットワーク機器のMACアドレスをSNMPのクライアントに送信するように設定しています。またもやちなみに、SNMPっていうプロトコルはそもそも、トラブルの早期発見とかシステム運用の効率化ってのを実現するためのものです。あと、SNMPで情報取得するのって、結構機器に負荷をかけるとかって先生からは聞きました。ストーキングツール負荷かけてる割に運用に関係してねえじゃん！！！ってのが僕個人の感想だったりします。ストーキングツールはそんな持ってる情報を送るだけで負荷がかかるとか言われる弱弱しいネットワーク機器にSNMPによる負荷をかけながらスイッチから得たMACアドレスと、DBのMACアドレスを比較することにより、個人と居場所の特定をしているのです。悪です。とは言ってもスイッチのポートに繋がってるネットワーク機器のMACアドレスを取得する程度ではそんなに負荷があるとは思えませんが。SNMPはツリー構造で欲しい情報を指定します。ルートに近い値を指定すると、その分スイッチの持っている情報の多くを取得できるっていうことです。得たい情報を調査するのに何度も短時間でルートに近い部分から調査していくっていうことで負荷がかかるのでしょうかね。その辺はよくわかりません。けど、重要な有限の資源であるネットワーク帯域の一部がそういうことに使われてるんですよっていうことですね。」 戻る ちゃんと読んでみるといかに適当に書いたかが分かる。

合格してました 以前、午前が47点で1点足りなくて落ちたー とかってブログ書いたんですが ちなみに -> 当時の日記はこちら そんなわけで、一安心。ラッキー。棚からぼたもち。棚から応用情報。 　と、いうわけで 受かったので何でも言えますね。 結局たいして勉強もせずに受かりましたが、 「大学でやることをしっかりとやる」 ことで合格できたんだと思います。 僕の場合はシスカンと研究。 人によっては普通に授業だったり、実験だったり、いろいろ選択肢はあるんでしょうけど。 大学でやることやって評価される + ついでに試験も受かっちゃう なんて最高だと思います。副産物で資格ゲット的な。 そんなわけなので、試験対策とかも大事なのかもしれないけど、まずは大学でのことを頑張った方が良いんじゃないかな〜、なんて思ったり。 試験はあくまで試験なので。技術力がつくわけでもないし。 というわけでこれからも大学で頑張ります。 　OSCも終わったみたいだし 　そろそろ「ほこ×たて@ie」の季節ですねぇ… 盾側人員増えないかな… DDoS要員とか。

001[偵察編] < - 003[対策編]　005 作成中-> 　今回はストーキングツールの中身について書きます。 番外編です。 ストーキングツールの軽い説明をしますが、結局「なぜ」MACアドレスを変えたのに特定されたかの説明はしません。 あと、すこ〜し、技術の解説的なことも書きましたのでお勉強にはもってこいかも？ 　\ 前回 それにしても、前回は清々しいほどにやられました。 完全に「これで特定されんだろ！ﾄﾞﾔ」みたいな感じでキーボードカチャカチャやってたんですけど。 ッターン！ってやってたんですけど。 まあ、こんなに簡単に上手くいかないよな、ってことで一つ…。 　\ どうやって特定してる？ ストーキングツールはどうやって個人を特定しているのでしょう？ 001[偵察編]でも書きましたが、もう少し詳しく今回は書いてみます。 基本的には001回で記述したことなので、今回はそれに肉付けする感じなので、結構さらっと読めちゃうかな〜、なんて。 では、次の章（段落？）から説明します。 　\ 説明しよう！ストーキングツールとは！ 　\ ・ \ ・ \ ・ \ 説明長い。 ゆっくり（注１）に読んで欲しい（笑） （注１：ゆっくりは、@yukkuri52のことではありません。ふくだいのことではありません。Dのことではありません。フレンチ先輩のことではありません。） 　\ 分かりにくいので図で見てみよう 大事なのは 学科システムとストーキングツールの関係 ・登録されたMACアドレスはユーザ名と一緒にDB(データベース)に保存してるよ ・矛側は、このDBを参照するという権限が与えられてるよ ・更に、各部屋のスイッチから定期的に情報を取得しちゃってるよ 　\ 大きな権限 図を見て分かる通り、ストーキングツールは個人の居場所を特定するための大きな権限を2つ持っています。 その1：スイッチから情報を持ってくる その2：学科のDBから情報を持ってくる 2つの情報を比較することで、 「hogehogeのPCが今fugafugaで接続されている　＝　hogehogeはfugafugaに居る」 ということで個人の居場所の特定を可能にしています。 　\ チートだろ… 　\

networkな（？）良い感じなネタがあったので投下。 備忘録な感じ。 これができたからといってどうというわけでも無いんだけど。 まあ趣味的な感じで。 某友人の言葉を借りると、「気持ち悪いネットワークな話。ネットワーク屋さんは何言ってるのか本当に謎で気持ち悪い」が満載かも。 こっちとしては普通なんだけど。 詰まった点はbrの名前とかvirsh editがちゃんと反映されてないとか変な部分。 環境 [bash] $ cat /etc/redhat-release CentOS release 6.4 (Final) [/bash] 　最初に補足 適宜tcpdumpやping辺りで通信を確認した方が良い。 [bash] $ tcpdump -i [interface] or $ ping [ipaddr] [/bash] 特に有効なのはtcpdump。 しっかりtag vlanなpacketが入ってきてるかをチェックすべし。 bridgeなのでおそらく問題は怒らないと思うけど。 iptablesとか設定してる人は結構ややこしくなる可能性あるので注意。 \ bonding bondingの有効化から。 [bash] $ vi /etc/modprobe.d/bonding.conf alias bond0 bonding $ modprobe bonding [/bash] これでkernelのbonding機能が使えるようになる。 modprobeはLinux kernelにmoduleを追加したりするコマンド。 確認は [bash] $ lsmod | grep bonding [/bash] くらいでオッケー？ 　\ 次、bondingしたいinterfaceの設定をする。 bondingってのは複数のinterfaceを一つのinterfaceに見せるっていう技術。 冗長性や効率性を上がるっていうやつ。 [bash] $ vi /etc/sysconfig/network-scripts/ifcfg-ethXX

001[偵察編] < - 002[偵察編 その2]　004[番外編]-> 前回までのあらすじ 情報を監視下に置こうとする矛。 「管理されてたまるか！」 対抗すべく立ち上がる盾。 矛と盾の間で高度な情報戦が行われる。 情報収集：@SNIP「@himajin315 @y0t4 Stalking Toolsの話し合いは18時から、406で。」 潜入先：406室 調査方法：@y0t4「教えて〜」 @himajin315「いいよ〜」 この情報戦により「矛がどういう風に監視しているか」が判明したため、以下の様な対策を思いつきました。 どういう風に監視しているかの詳細は矛側の話なので別で漏洩説明します 　\ 対　策　編 \ 今回のキーワード 「DHCP」 DHCP(Dynamic Host Configuration Protocol)とは… コンピュータがネットワーク接続する際に必要な情報を自動的に割り当てるプロトコルのこと (wikipedia) 要約： 「自分で設定するのがめんどくさいIPだとかMASKだとかGATEWAYだとかBROADCASTだとか云々を自動化しちゃおう！ prug and play いいね！（注１）」 （注１：prug and playとは、繋いだら(prug)すぐ使える(play)こと。特にここでは、Etherケーブルを挿すだけでネットに繋がる、という意味） ではdhcpのお勉強をしましょう！ dhcpではクライアントがdhcp discoverをBROAD(以下略\ 思いついた対策 有線の対策をします。 パッと思いついたのは以下。 対策1. 学科のネットに繋がない。 対策2. 学科内の多数の部屋で有線接続する。 対策3. 偽のパケットを流す。 対策4. 学科のDHCPなんて使わない。\ 対策1はそもそもな感じが…。ネット繋ぐ時はテザリング？ん〜、却下。 対策2は「あれ、こいつ5Fにも6Fにもいる？」みたいな混乱を招くことができます…が、みんながこれやるとポート数的に大変。却下。 対策3は面倒！もっとお手軽な方法があるはず！ 対策4が一番楽かな？\ 学科のDHCPなんて使わない prug and play なんて時代は情報工では終わるべき！

< - 001[偵察編]　003[対策編] -> 前回のあらすじ 「居場所の特定なんてされたくない！」 そんな思いを持った一人の男が立ち上がった。 しかし、相手は上位権限を持つ精鋭6人。 M1:@himajin315, @SNIP_SNIP_SNIP, @M1のジーニアス（注１） B3:@_atton, @morobororo, @nekonekomeiko\ 矛 [ vs ]{style=“font-size: large;"}[盾]{style=“color: #5c80ff; font-size: large;"} M1: @y0t4\ 如何にして一般権限で立ち向かっていくのか。 仁義なき戦いが今、始まる。（注２） (注１：作成者に@10paaaも居ますが、社会人となりフェードアウトしました) (注２：データマイニング班10回目は実験課題設定例についての解説＆討論より) 　今回 「 彼を知り己を知れば百戦して殆うからず 」 まずは相手側の情報を集めます。 今回のテーマは 「ソーシャルエンジニアリング」 ソーシャルエンジニアリングとは… 人間の心理的な隙や、行動のミスにつけ込んで個人が持つ秘密情報を入手する方法のこと。 (wikipedia) 事例：JNSAのページ 上記の事例にもあるように、ソーシャルエンジニアリングは 「ゴミ箱にあるマル秘文書を手に入れる」だとか「パスワードを盗み見る」などです。 今回は実際にM1とB3のミーティングに参加するという 「それソーシャルエンジニアリングかよ！普通に聞いただけじゃん！」 っていうレベルな情報収集をしてきました。 　潜入 そういうわけで、ストーキングツール作成者M1と引き継ぐB3のミーティングに潜入しました。 情報収集： 潜入先：406室 調査方法：@y0t4「教えて〜」 @himajin315「いいよ〜」 　今回の成果 ・どのソースがどういう風に動いているか ・スイッチなどから情報を持ってくる仕組み ・サーバを移行するか(結局、後日にサーバを移行したようです。) ・データベースのテーブル構成 ・今後どう拡張していくか (矛側がSNS情報を見るらしい)

002[偵察編 その2] -> 食あたりで5日ほどベッドで過ごすというバカンス楽しんだ僕です。 串屋さんに行った時のレバーなんかが怪しいのかなー、と。 まあそんなにひどい症状でもなかったので一安心（？）。 本題 学科にはストーキングツールというものがありまして、その内容が 「今、誰が学科のどこにいるのかを把握する」 みたいな。 中二病まっさかりな僕としては謎キャラを追求すべく、今どこにいるかなんてばれたくないわけです。 実際ばれたところで害があるかどうか分からないうえに、ほぼ研究室にいるのであまり意味は無いよね、とかは置いときます。 ともかく、 「居場所の特定なんてされたくない！」 そんな思いを持つ一人の男が立ち上がった…。（それっぽいBGM） **ほこ「居場所を突き止めるべく動くストーキングツール組（M1:3人 B3:複数人）」 vs たて「情報を守るアンチストーキングツール（僕）」 ** ＼ｼﾞｬｰﾝ／ 現在の状況 攻撃である矛側はなんと、スイッチから情報を取ってくるという権限を持っています。 ついでに言えば学科のDBからも情報をぶっこ抜く権限を持ってます。 つまり、現時点では攻撃側が有利な状況なわけです！ このままいけば、我々一般権限userは為す術もなく情報を搾取されてしまいます。 ついでに言えば人数的にも圧倒的不利なこの状況。 この状況を頑張って打破したいと思います。 （＊注１：盾側はいつでも、人員を募集しています。） （＊注２：一般権限のuserでもできる対策を考えます。） まずは敵を知る ストーキングツールですが、学科の特性を活かした内容のものになっています。 学科ではDHCPを使っていますが、IP情報を受け取るのにmacアドレスを登録しなくてはなりません。 ストーキングツールはその情報を引っ張ってきて、登録されたmacアドレスとスイッチの情報をやり取りすることでどこに誰がいるかを把握しています。 (今後仕様が変わる可能性はありますが…。） 「ネットに繋ぐにはmacaddrを登録してIPとかのネットワーク情報をdhcpサーバから受け取らないといけない。ってことは、これ対策できないんじゃないの？」 そんな考えが一瞬よぎりますが、間違い。 そもそも、ネットに繋ぐためにdhcpが必要なんていうことはありません。staticに設定をしてやれば良いだけです。 上記の考えを持った人は、prug and play の恩恵を受けまくりです。 では、どのように対策したら良いのか。 to be continued…。 あとがき 攻撃側だけってのも味気ないっていう感じがしたので、守備側として/*無理矢理*/参戦してみました。 ほこ×たて@ie 次回をお楽しみに！ P.S…. それにしてもこのブログの見にくさ…。 なんとかならないものか。 002[偵察編 その2] ->

1. KVMの環境構築 2. qemuによるimgの作成とCentOS6 minimal版のインストール 3. VMの設定 4. kernelのconfigとbuild (3.9.2) 2と3を軽く2桁こなしたので、もう virsh destroy は得意。 複数人の協力のおかげで、gdbでkernelを追いかけるとこまでなんとか到着。 次は、openvswitch追いかけるようにするわけだけど、はたしてうまくいくのか謎。 openvswitchは、kernel buildのときのconfigでbuilt-inするように設定したのでそっち側はオッケーのはず（？）。 openvswitchコマンドのmakeはさっき終わったので、kernelとコマンド間の連携を追えれば…。 ってところ。 今日見たいに長時間は頭がボーッとしてくる。

授業始まってからというもの、なかなか時間が取れない。 かなり時間かかってしまいましたが、ようやく読み終わり。 内容はOSの役割とか歴史とか構造とかが簡単に書かれてる感じ。 歴史とか知ってみたい人には良いのかも。 普段何気なくやってることが「これってこういうことだったんだ」みたいな感じで思わぬところで繋がるのは結構楽しい。 といっても内容的には不満足かなぁ、と。 深くやりたい人はLinuxカーネル解読室とか読めよ、ってなりそうですけど。 シリーズもの制覇したわけですが、やっぱりネットワークが良いですね。 それにしても、ほんとに基礎知識なシリーズでした。 基礎大事だし、良し。 ちゃちゃっと次の段階にいける脳みそ作るには土台必須だし虫食い状態な脳みそのデフラグしないと。