#ssmjp で発表した ―「ダークネットのはなし」
"深淵を覗き込む時、深淵もまたこちら側を覗き込んでいるのだ。"
2015年2月20日のssmjpという勉強会でダークネットについて発表させていただきました．(会場は品川のBIGLOBEのオフィス)
「ダークネット」という，なんとも厨二くさいワードですが，れっきとしたネットワーク用語です．
インターネットのダークサイドへようこそ...
会場で寄せられた質問は以下のとおり．
Q．IPアドレスがダークネットか否かを判断する方法はなにか
A．あらゆるリクエストパケットを投げてみて，なにも応答がなかったらダークネットと考える．
Q．ダークネットと経路なしの区別はなにか
A．ダークネットはパケットが「到達可能」なのに対して，経路なしはパケットが「到達不可能」なもの．到達不可能とはルータの先に経路情報がなくパケットが到達し得ない状態のこと．
Q．一時的にサーバーダウンして応答を返さないIPアドレスもダークネットに含まれるか
A．そういったIPアドレスもダークネットの定義に当てはまる．ダークネットの領域は日々変化するものと考えてよい．
Q．ダークネットのデータセットは公開されているのか
A．今回使用したNICTER Darknet DatasetはMWS(マルウェア対策研究人材育成ワークショップ)で大学等の研究者向けに提供されているものであり，一般に公開はされていない．データの解析はNICTが管理するVM上で行う．（参考：マルウェア対策研究人材育成ワークショップ 2014 (MWS2014)）
Q．IPv6のダークネットにおいても同様にパケットは観測され，サイバー攻撃の傾向分析に役立つか
A．IPv6のダークネットでもパケットは観測されるとは思うが，IPv4のようにアドレス空間全体をスキャンしようと考える人はほとんどいないのではないかと思うので，その数は少なく，傾向分析は難しいのではないかと考えている．攻撃者としては，スキャンをする際はある程度ターゲットに当たりをつけてスキャンするはず．
他にも「スキャンされにくいようなネットワーク構築を心がけるべき．セグメントは大きく分割しすぎない．」などのご意見も頂きました．議論に参加してくださった方々，本当にありがとうございました．
※DAEDALUSの解説，NTP/DNS amp 攻撃の解説，スキャンツールの解説等は口頭で済ませてしまったためスライドにはありません（また別の機会に）．アップロード版の自己紹介スライドではなんとなく本名は伏せてあります．
発表についての感想
ssmjpはこれまで2回ほど参加していて，今回初めて発表側に立たせていただきました．今回はいつもより学生が少なくほとんどが社会人のプロな方だったので若干緊張しました．とくに質疑応答の時は慌てずもっと落ち着いて答えられるようになりたいです（若干的はずれな回答もしてしまった気がして反省している）．また，「ダークネットおもしろい！」という言葉をたくさん頂けたことは嬉しかったです．アウトプットはホント大事だなあと実感したので，今後も精進してまた何かしらの勉強会で発表できたらと思います．
SECCON CTF 2014 決勝戦に出場した
SECCON CTF 2014 決勝戦にチームm1z0r3(みぞれ)として出場してきました．結果は431点で24チーム中20位，日本チームでは10位でした．SECCON CTF 2014決勝戦・全国大会カンファレンス
SECCON CTF 2014 Finals Ranking
特別賞として，「Medical × Security Hackathon賞」を頂きました．3月に福島で行われるハッカソンに招待していただけるようです．
圧倒的実力不足を痛感しました．Writeupが書けない．
個人的に取り組んだ問題について書いていこうと思います．問題サーバは全部で6台ありましたが，主にWEB系の問題を中心にに1,2,5,6に取り組みました．
サーバ 壱
指定されたURLにアクセスするとユーザ登録とログインが出来るようになっている．
ログインすると以下の画面が開く．各チームごとにUser NameやURLに使えない文字のブラックリストが作れるようになっている.
このサーバでは登録したユーザ数が最も多いチームにDefenseポイントが入るようになっている．ただし短時間に連続して登録できないようになっており，さらにブラックリストもかいくぐらないといけないため工夫が必要．
Attackポイントを取るにはページ下部にあるのSendフォームが狙い目のよう．ここで指定されたURLに管理者がアクセスしてくる．実際に手元(192.168.6.9)にWEBサービスを立ち上げ，http://192.168.6.9/を指定するとGETでアクセスしてくるがとくに管理者のセッション情報はない(クロスドメインの問題がある)．HTTPヘッダのUser-Agentに"Admin's Browser"の文字を発見したのでこのUAでアクセスしたがなにも起きなかった．Sendの下にShow Passwordのフォームがあるので一旦管理者にここをアクセスさせてからごにょごにょ...といろいろ考えたがここで挫折．あとで聞いた話によるとXSSが可能だったらしい．
サーバ 弐
以下のようなキャプチャ認証がある掲示板がある．
画面下には直近の投稿履歴が表示される．一定時間ごとにこの履歴欄に表示されているチームにDefenseポイントが入る．他のチームはこの投稿を並列処理で自動化してがっぽり点を稼いでいた(ほぼDDoS攻撃の状態だった)．なお自動化の際にはキャプチャの画像を見る必要はなく，cookieの設定の脆弱性を突いて認証を突破することが可能らしい．うちのチームは自動化ができなかったのでなんとか脆弱性を突いてAttackポイントをば，と思っていたが，後で投稿数が最も多いチームがフラグを得ていたことを聞き，「なんだそれ」と言った．
bodyではダブルクオート，"script"，"alert"などの文字がエスケープされたり，imgタグなどが埋め込めたりなど，とっても思わせぶりな挙動をしてくれたのにXSSは全く関係なかった．
サーバ 伍
CGIが動いていて，最初の画面がこのような表示になる．
ここに自分のチームのDefense Keyを置くことでDefenseポイントが入るようになっている．後にKeyは/flags下にあることがわかった．直感的にいま流行りのShellshockの攻撃でコマンドインジェクションができるかなと思ったができなかった．
次にこのWEBサーバーのIPアドレスが10.100.5.2なのだが，終端が1でなく2な時点で怪しい．/24でネットワークスキャンを行ったら他にも10.100.5.102，10.100.5.202，10.100.5.252も動いてることがわかった．しかもそれぞれポートがごっそり開いていて更に怪しい．全てのサーバ，全ての空いてるポートに対してnetcatするスクリプトを書いて試したがHTTPの80番ポート以外は反応はなし．ほかにもApacheの脆弱性を調べたりURLをごにょごにょしてみたが何も見つけられずここで頓挫．
以下，終了後に聞いた話だが，まず/key.txtに一つ目のAttackポイントのフラグがあったらしく，「なんだそれ」と言った．こういう問題が今後の大会でも出るのかなと思うと少しつらい．ところがチームdodododoのakiymさんはこういうCTFでありがちなURLを試行するスクリプトを用意して見つけたらしく，プロは違うなと思った．ほかには/cmd.shや/svn/flagsが存在したらしく，Defense Keyが送信可能だったらしい(参考：SECCON 2014 全国大会に出た - misodengakuのブログ)．これを解いたチームはほとんどいなかった模様．
追記(2015/02/16)
他の人のWriteupを見て，実はこの問題はガッツリNetworkな問題だということがわかった．じつは5つ目のサーバが存在し，パケットをよく監視しているとそれに気づくことができるという．/key.txtの存在もその流れで知ることができる．こういうことに気づけないようではパケリストとしてまだまだだなあとおもう．
問題の詳細についてはもりたこさんのブログを参照されたい
サーバ 六
暗号の問題．平文と暗号文の対応を見て暗号化のアルゴリズムを読み解き，Keyとなる暗号文を解読する．問題は全部で4問ある．1～3問目までは素直な問題だったらしく，チームの先輩がすぐに解いてくれた．4問目はかなりの難問で，自分も加わって協力して解いた．
暗号文は以下のとおり．
AAAAgBX7KsK03QWS3Leud1FmWe5LyodjFstpL6Eo1JFKpioWItFrXBdrv6Vrf9ZwOK3TmBqriKkisDVXD/E45TcNOQUwNumw8L8pNiO4vLfxzsz6FYGDMB25IvYwO2ZI6qzbhOMi4dfSGkQfd8h5YAB
平文と暗号文の対応のサンプルは以下のとおり．
ede AAAAA1lsiAB edb AAAAA1iWSy8AA dbac AAAABCw2JY7JpAB
まず，暗号文に使われる文字は大文字，小文字のアルファベットに加え，"_"と"/"の全部で64種類であることがわかった．これはBASE64と同じで，全ての文字を6bitで表現できるため，BASE64の変換表を用いて文字を全て2進数になおした．
ede 000000000000000000000000000000110101100101101100100010000000000001 edb 000000000000000000000000000000110101100010010110010010110010111100000000000000 dbac 000000000000000000000000000001000010110000110110001001011000111011001001101001000000000001
０１に直すと前半分は文字列長を表す領域になっていて，中盤部分は出現する文字をASCII変換したものが出現頻度順に並んでいた．後半部分は文字の並びを表現しているようだったが，途中でハフマン符号っぽいことに気づいた．
ところが平文を一つ一つ手作業で符号化していくと，文字の種類が多い時にハフマン木が思ったとおりにならない．ここでこの符号化はハフマン符号に似たシャノン符号ではないかと思ったらビンゴで，チームの先輩がコードを書いて復号してくれた．
暗号文を複合した結果は以下のとおり.
Password_located_you_done_of_you_that_mailing_and_C/C_Japanese_I_university_of_fend_time_used_Free_Basic_at_get_take_in_debug_Li
所感
自分の実力不足を痛感した大会だった．自分は端から比較的得意なWEB問題を担当するつもりだったが，点数に直結する貢献がまったくできなかった．また序盤にDefenseに取り組んだチームが大きくリードしたように思えたが，うちのチームは1日目にDefenseポイントがまったく取れず，2日目に追い上げるのが困難な状況となってしまった．戦略によってはもう少し点も取れたかも知れない．
一方で，みんなで協力して議論しながら問題を解いたことは嬉しかったし楽しかった．とくに6番目の暗号のwriteupは簡単に書いたが，あれは徹夜して紙に起こした０と１の羅列をひたすら眺めてみんなで解いた問題だった．あの感覚を忘れず今後もCTFを続けていきたい．
ちなみに私は来年度からのm1z0r3の次期代表を拝命したので，そういった面でも頑張って行きたい．
Dionaeaを改変してNmapによる検出を回避する
Dionaeaは低対話型のハニーポットであり，本物"そっくり"のサービスをエミュレートするため，本物とはわずかに異なる挙動を取ることがある．有名なネットワークスキャンツールであるNmapはそういったわずかな挙動の違いを突いてハニーポットを検出することができる．以下のようにNmapに-sVや-Aオプションを付けてスキャンを行うとDionaeaが検出される．
$ nmap -sS -sV AAA.BBB.CCC.DDD Starting Nmap 6.46 ( http://nmap.org ) at 2015-01-30 07:08 Asi Nmap scan report for ec2-AAA-BBB-CCC-DDD.us-west-2.compute.amazonaws.com (AAA.BBB.CCC.DDD) Host is up (0.31s latency). Not shown: 988 closed ports PORT STATE SERVICE VERSION 21/tcp open ftp Dionaea honeypot ftpd 22/tcp open ssh OpenSSH 5.3 (protocol 2.0) 42/tcp open tcpwrapped 80/tcp open http 111/tcp open rpcbind 2-4 (RPC #100000) 135/tcp open msrpc ? 443/tcp open ssl/https ? 445/tcp open microsoft-ds Dionaea honeypot smbd 1433/tcp open ms-sql-s Dionaea honeypot MS-SQL server 3306/tcp open mysql MySQL 5.0.54 5060/tcp open sip (SIP end point; Status: 200 OK) 5061/tcp open ssl/sip-tls ?
攻撃者に自分がハニーポットであることがばれてしまうと，攻撃者がそれ以降の攻撃をやめてしまうという問題がある．そこでDionaeaのソースコードを改変して挙動を調整し，Nmapによる検出を回避する．
まずは，NmapがどのようにしてDionaeaを検出しているかを調査する．Nmapはハニーポット特有の挙動を示すシグネチャを保持しており，スキャンの結果とシグネチャを比較してハニーポットを検出する．そのシグネチャが収められているファイル(nmap-service-probes)を以下のURLからダウンロードしてくる．
$ cat nmap-service-probes |grep -i dionaea match ftp m|^220 Welcome to the ftp service\r\n| p/Dionaea honeypot ftpd/ match http m|^HTTP/1\.0 200 OK\r\nContent-type: text/html; charset=utf-8\r\nContent-Length: 204\r\n\r\n<!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 3\.2 Final//EN\"><html>\n<title>Directory listing for /</title>\n<body>\n<h2>Directory listing for /</h2>\n<hr>\n<ul>\n<li><a href=\"\.\./\">\.\./</a>\n</ul>\n<hr>\n</body>\n</html>\n$| p/Dionaea honeypot httpd/ match microsoft-ds m|^\0...\xffSMBr\0\0\0\0\x98\x01\x40\0\0\0\0\0\0\0\0\0\0\0\0\xff\xff\x40\x06\0\0\x01\0\x11\x07\0\x03\x01\0\x01\0\0\x10\0\0\0\0\x01\0\0\0\0\0\xfd\xe3\0\0..........\x00\x34\0W\0O\0R\0K\0G\0R\0O\0U\0P\0\0\0H\0O\0M\0E\0U\0S\0E\0R\0-\0.\0.\0.\0.\0.\0.\0\0\0|s p/Dionaea honeypot smbd/ match honeypot m|^HTTP/1\.0 200 OK\r\nAllow: OPTIONS, GET, HEAD, POST\r\nContent-Length: 0\r\nConnection: close\r\n\r\n| p/Dionaea Honeypot httpd/ match honeypot m|^SIP/2\.0 200 OK\r\nContent-Length: 0\r\nVia: SIP/2\.0/TCP nm;branch=foo\r\nFrom: sip:nm@nm;tag=root\r\nAccept: application/sdp\r\nTo: sip:nm2@nm2\r\nContact: sip:nm2@nm2\r\nCSeq: 42 OPTIONS\r\nAllow: REGISTER, OPTIONS, INVITE, CANCEL, BYE, ACK\r\nCall-ID: 50000\r\nAccept-Language: en\r\n\r\n| p/Dionaea Honeypot sipd/ match ms-sql-s m|^\x04\x01\x00\x2b\x00\x00\x00\x00\x00\x00\x1a\x00\x06\x01\x00\x20\x00\x01\x02\x00\x21\x00\x01\x03\x00\x22\x00\x00\x04\x00\x22\x00\x01\xff\x08\x00\x02\x10\x00\x00\x02\x00\x00| p/Dionaea honeypot MS-SQL server/
NmapはDioneaで動作するサービスのうち，FTP, HTTP, SMB, MSSQL, SIPについてのシグネチャを持っていた．それぞれに対して対策を行う．
FTP
FTPでは，FTP接続時に表示される"220 Welcome to the ftp service"というバナーの文字列のみをチェックしている模様．このバナーを既存のFTPサーバ(今回はMicrosoft FTP)の中から適当なものを選び書き換えると良い．具体的には/opt/dionaea/lib/dionaea/python/dionaea/ftp.pyの227行目を以下のように変更する．
self.reply(WELCOME_MSG, "Welcome to the ftp service") ↓ self.reply(WELCOME_MSG, "Microsoft FTP Service")
HTTP
HTTPでは，HTTPヘッダーとHTMLのソースコードをチェックしている模様．Dionaeaの/opt/dionaea/var/dionaea/wwwroot下にindex.htmlを置いておくと80番ポートに接続した際にこのページが表示されることになっている．適当にHTMLファイルを置いてさえすればNmapの検出は回避することができるのであとはお好みで．
SMB
SMBの"SMB Negotiate Protocol Response"に含まれる"OemDomainName"と"ServerName"の値をチェックしているようなので，/opt/dionaea/lib/dionaea/python/dionaea/smb/include/smbfields.pyの690行目と693行目を次のように変更する．
ConditionalField(UnicodeNullField("OemDomainName ", "WORKGROUP"), lambdax: not x.Capabilities & CAP_EXTENDED_SECURITY), ConditionalField(UnicodeNullField("ServerName ", "HOMEUSER-3AF6FE"), lambda x: not x.Capabilities & CAP_EXTENDED_SECURITY), ↓ ConditionalField(UnicodeNullField("OemDomainName ", "MIDOMINIO"), lambdax: not x.Capabilities & CAP_EXTENDED_SECURITY), ConditionalField(UnicodeNullField("ServerName ", "EQUIPO-TEST"), lambda x: not x.Capabilities & CAP_EXTENDED_SECURITY),
MSSQL
MSSQLデータベースに接続する際のpre-login TDS package (Tabular Data Streams)の情報をチェックしている模様．Token Typeの値が0x00になっているので，これを0x01に変更する．/opt/dionaea/lib/dionaea/python/dionaea/mssql/mssql.pyの151行目を次のように書き換える．
r.VersionToken.TokenType = 0x00 ↓ r.VersionToken.TokenType = 0x01
変更後のスキャン結果
$ nmap -sS -sV AAA.BBB.CCC.DDD Starting Nmap 6.46 ( http://nmap.org ) at 2015-01-30 07:32 Asi Nmap scan report for ec2-AAA-BBB-CCC-DDD.us-west-2.compute.amazonaws.com (AAA.BBB.CCC.DDD) Host is up (0.12s latency). Not shown: 988 closed ports PORT STATE SERVICE VERSION 21/tcp open ftp Microsoft ftpd 22/tcp open ssh OpenSSH 5.3 (protocol 2.0) 42/tcp open tcpwrapped 80/tcp open http ? 111/tcp open rpcbind 2-4 (RPC #100000) 135/tcp open msrpc ? 443/tcp open ssl/https ? 445/tcp open microsoft-ds ? 1433/tcp open ms-sql-s ? 3306/tcp open mysql MySQL 5.0.54 5060/tcp open sip (SIP end point; Status: 200 OK) 5061/tcp open ssl/sip-tls ?
これにてNmapによるDionaeaの検知を回避することができた．めでたしめでたし．
Dionaeaハニーポット観測記録 Part1
ハニーポットを植えてからしばらく経ってログも溜まってきたのでそろそろ観測記録を公開しようと思う．
環境は以下のとおり
- サーバ：Amazon EC2サーバ
- CPU：1コア
- メモリ：1GB
- OS：Red Hat Enterprise Linux Server release 6.5 (Santiago)
- ハニーポットツール：Dionaea
Dionaeaがエミュレートする主なサービスは以下の通り．
- Server Message Block (SMB)
- Hypertext Transfer Protocol (HTTP)
- File Transfer Protocol (FTP)
- Trivial File Transfer Protocol (TFTP)
- Microsoft SQL Server (MSSQL)
- Voice over IP (VoIP)
ハニーポットの稼働期間は2014年10月09日～2015年01月29日（ただしお手入れを怠ったせいで2014年11月24日～2014年12月10日のデータが欠損している）．2015年01月29日現在も稼働中．ドメイン取得，広告活動はとくになし．
今回はDionaeaFRというDionaeaのログの解析ツールを用いてざっくりとした統計を行う．詳細な攻撃のログに関しては別の機会に報告することにする．
基礎統計データ
これまでの全てのログの基本的な統計データを示す．
全部で16,157名のお客様がお越しくださいました．本当にありがとうございました．
ドメインを取得しているわけでもないのにこれだけのアクセスが来るのはハニーポット初心者にとっては驚きだった．なお，"Malware Analized"とは，ハニーポットに送られたバイナリのハッシュ値を自動でVirusTotalで検索したことを表している．ハニーポットに送られたバイナリのほとんどは既知のマルウェアであることが分かる．
下の図はハニーポットにアクセスしてきたホストのロケーションを分析した結果である．
送信元の国を見てみると，コネクション数ではベネズエラ，ウクライナ，台湾の順に多い．またユニークなIPアドレス数で見るとジョージア(アメリカ)，エクアドル，ベネズエラの順に多い．コネクション数に対してIPアドレス数が多い国は攻撃ホストが比較的多く，IPアドレス数に対してコネクション数が多い国は1攻撃ホストあたりのアクセス回数が比較的多いということになる．
直近1週間のデータ
2015年01月22日～2015年01月29日の1週間分のログの解析結果を示す．
Services
下の図はターゲットなったサービスの分析結果である．
最も多く攻撃のターゲットとなったのはSMB(Server Message Block)であった．SMBとはネットワーク(LAN)上の複数のWindowsコンピュータの間でファイル共有やプリンタ共有などを行うためのプロトコルである．SMBにはこれまで様々なエクスプロイトのバグが発見された歴史があり，ワームのターゲットとなることが非常に多い．
Ports
下の図は送信先のポート番号についての分析結果である．
アクセスが最も多かった445番ポートは，Confickerというワームがスキャンを行うポートして知られている．445番ポートではMicrosoft Directory Service (SMB/CIFS)というサービスが動作するポートであり，Conficerは445番ポートへのスキャンに続いて，Microsoft Directory Service の脆弱性を突く攻撃を試みる(参考：IPA 独立行政法人 情報処理推進機構：情報セキュリティ技術動向調査（2009 年上期）)．次にアクセスが多かった139番ポートはNetBiosというサービスが動作するポートだが，これもワームのターゲットとなることがある(参考：http://www.jpcert.or.jp/at/2003/at030007.txt)．また，3389番ポートのリモートデスクトップのサービスは2011年に流行したMortoというワームのターゲットになることが知られている(参考：ワーム「Morto」の挙動)．
Malware
下の図はハニーポットに送られてきたマルウェアをVirusTotalで分類した結果である．
これを見ると，ほとんどのマルウェアはConfickerの亜種であることが分かる．最も多いConficker-AはNetbiosを感染経路とし，サーバーサービスの脆弱性MS08-067(参考：マイクロソフト セキュリティ情報 MS08-067 - 緊急)への攻撃を行う．わずかではあるがトロイの木馬と思われるマルウェアも送られてきたので嬉しい．
Countries
最後に送信元ホストのロケーションを世界地図にマッピングしたものを示す．
ぱっと見で多いのは，アメリカ，ヨーロッパ，中国，インドあたり．
余談(DionaeaFRについて)
DionaeaFRはとっても便利．しかし，ログが収められたデータベース(logsql.sqlite)のサイズが大きくなるに連れて動作がかなり重くなる．今回解析したsqliteファイルのサイズは1.7GBだったが，1GBメモリのマシンではまったく動かなかった(ついでにDionaea本体も落ちた)．そこで手元のハイスペマシンでDionaeaFRを動かしたところ，メモリの使用量は7～8GBに達していた．DionaeaFRはlogsql.sqliteさえあればDionaeaがある環境と切り離しても動作するので，ハニーポットサーバが貧弱の場合は，解析は別のマシンで行うのがおすすめ．
最小二乗法のロバスト推定についてまとめた
最近，研究とはほとんど関係ないところで統計学にハマっているので自己満でロバスト推定をやってみた．それからRのggplotモジュールで描けるグラフの美しさをみなさんに知ってほしい．
最小二乗法
最小二乗法とは，測定で得られた数値に組を適当なモデルから想定される関数(ここでは1次関数)を用いて近似するときに，残差の二乗和を最小とするような係数を決定する方法である．残差とは，二変量の観測値（Xi, Yi）に対してその回帰式が y ＝ax + b で与えられるときの Yi - (aXi + b) の値をいう．
近似直線の式を"y = ax + b"とした時のa, bは以下の行列計算によって求めることができる．
この辺は前提知識として扱うので，詳しくは「最小二乗法」でググって一番上に出てきたサイトを参照されたい．
最小二乗法について
例えば，以下の様な分散図に対して最小二乗法で近似した直線が描ける．
ところが，計測の際に何らかの拍子でプロットが1つだけ大きく外れた値(外れ値)を取ると，以下の青色のグラフように近似が大きくずれる．
グレーの網掛けになっている部分は回帰モデルに対する95%信頼区間を表している(グレーの領域に95%の確率でプロットが存在するという意味)．外れ値がある方は分散が大きく，95%信頼区間も大きく広がってしまう．
このような外れ値が最小二乗法に大きく影響を与えるという問題点を解決する方法として，ロバスト推定法がある．
ロバスト推定
ロバスト推定とは，誤差があるデータに対してその誤差の影響を最小にすることを目的とした理論である．ここではロバスト推定法の中の「M推定法」を扱う(他にはL推定やR推定がある)．
M推定法とは，二乗誤差基準では誤差が大きいほど値が大きくなるが，ある一定以上の誤差で値の上昇を抑えることで，外れ値による影響を小さくする方法である．最小二乗法のロバスト推定における誤差とは，近似した直線と各プロットとの距離のことをいう．また重み付けにはTukeyのBiweight推定法という手法を採用する．
点(Xi,Yi)と近似直線との誤差をd = Yi - (aXi + b)，Wを誤差の許容範囲としたとき，誤差が大きいほど最小二乗に与える影響力を小さくするように，以下のような式を用いて重みw(d)を計算する．
この重みの関数w(d)をグラフで表すと，以下のようになる．
(引用:ロバスト推定法（Ｍ推定法） 画像処理ソリューション)
この重みWiを各近似データ(Xi、Yi)に関して計算し、Wiを付加した最小二乗法を再度行い，ロバスト推定による近似式y = a'x + b'のa', b'を求める．
ロバスト推定後のグラフは以下のようになる．
青いグラフのように外れ値による影響が抑えられ，測定データに近い直線が描けた．
最終的に作成したRスクリプトは以下のとおり．
library(ggplot2) library(MASS) pdf("robust.pdf", width=8, height=4) set.seed(123) # allow reproducible random numbers orig <- within(data.frame(x=1:10), { type <- "orig" y <- rnorm(x, mean=x) } ) outlier <- orig outlier$y[2] <- 20 outlier$type <- "outlier" theme_set(theme_grey(base_size = 16)) # increase default font etc. size #p <- ggplot(orig,aes(x,y)) + geom_point(colour="#F8766D") #p <- p + geom_smooth(method="lm", se=FALSE, colour="#F8766D") p <- ggplot(data = rbind(outlier, orig), aes(x, y, colour=type, linetype=type)) + geom_point() # "base" plot, with points only p <- p + geom_smooth(method = "rlm") # fit & plot *robust* model + envelope print(p) dev.off()
LaTeXでbibファイルのURLに関するエラーが発生する時の対処法
今まで論文を書くときはLatexのテンプレート的なものを使って何も考えずにコンパイルしていたので，今回変なところでつまづいてしまった．自分のための備忘録．
Latexで参考文献(サイトのURL)を載せたいとき，例えば以下のようにbibファイルを作成する．
@misc{twitter,
title = {{Twitter}},
howpublished = {\url{http://twitter.com/}}
}
コンパイルの際はbibファイルを元に以下の様なbblファイルが生成され読み込まれる．(自分の環境ではTeXworksかmakeコマンドを使っている)
\begin{thebibliography}{}
\bibitem[twi]{twitter}
``{Twitter}'', \url{http://twitter.com/}
\end{thebibliography} ところがこのbblファイルのurlの部分でUndefined control sequence.というエラーが発生してしまう．
解決策
どうやらbibファイルのurlの書き方には次の2通りあるらしい．
howpublished = {http://twitter.com/}howpublished = {\url{http://twitter.com/}}
1の方法ではエラーは発生せず，2の場合にはエラーが発生する．このエラーは「url」というパッケージが入っていないために起こる．
2の方法を用いるときは，styファイルに以下の一行を追加する．
\usepackage{url}
これで正常にコンパイルが成功する．
URLであることを明記するためには2の方法をとるのが望ましいと思われる．
情報セキュリティスペシャリスト試験に合格した話
平成26年度 秋期 情報処理技術者試験にて，情報セキュリティスペシャリスト(SC)試験に合格しました．
情報セキュリティスペシャリストは，IPAの情報処理技術者試験のレベル4にあたる高度試験のうち，セキュリティ分野に特化した国家資格です．
今回の受験者平均年齢は36.2歳，合格率は14.4％(試験会場に到達できなかった人も含めると9.1％)でした．受験者はやはり実務経験のある社会人の方が殆どのようですが，自分の周りにはキャンパーの方など，学生の受験者も多い印象でした．
IPA 独立行政法人 情報処理推進機構：制度の概要：情報セキュリティスペシャリスト試験
まずは成績から．平成26年度春期で応用情報技術者試験に合格したので，情報セキュリティスペシャリストの午前Ⅰは免除となりました．
午後ⅡのWEBの問題が解けなくてかなり心配しましたがギリギリボーダーを超えていました．その他は概ね想定内の成績です．
合格体験記
準備期間
SCの勉強を始めたのは試験日のおよそ一ヶ月前です．ホントはもっと時間を取りたかったのですが，論文投稿などで忙しくて直前のスタートとなってしまいました．
試験対策として，以下の2つの参考書を購入しました．
情報処理教科書 情報セキュリティスペシャリスト 2014年版 (EXAMPRESS)
- 作者: 上原孝之
- 出版社/メーカー: 翔泳社
- 発売日: 2013/09/13
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (1件) を見る
ポケットスタディ 情報セキュリティスペシャリスト 第2版 (情報処理技術者試験)
- 作者: 村山直紀
- 出版社/メーカー: 秀和システム
- 発売日: 2014/05
- メディア: 単行本
- この商品を含むブログ (2件) を見る
また，午前Ⅱの対策として「情報セキュリティスペシャリストドットコム」というサイトのWebアプリ過去問道場で，過去問の演習を行いました．
情報セキュリティスペシャリストドットコム
まずは情報処理教科書を辞書代わりにしてひと通り読んだあと，サイトで過去問演習を行い，あとは時間の許す限りポケスタを繰り返し読み倒していきました．
ポケスタいい感じにボロボロになった http://t.co/usbPmirMLx
— そにっくん/sonickun (@y_hag) 2014, 10月 18 この村山先生の「ポケスタ」には本当に助けられました．特に午後対策の「速効サプリ」では，出題・解答パターンがまとめられており，効率的に試験対策が出来ました．
また，10月4日の江戸前セキュリティ勉強会では，村山先生の試験対策のお話も聞いてきました．（ちゃっかりサインも貰った）
江戸前セキュリティ勉強会(2014/10) #edomaesec #edomae_asp - Togetterまとめ
そしてちゃっかり貰っていたサイン http://t.co/CV5oFd6rOo
— そにっくん/sonickun (@y_hag) 2014, 10月 18@y_hag ああ，あなたでしたか！
— 村山直紀 (@MurayamaNaoki) 2014, 10月 18
試験当日
～試験直前～
明日は情報早起きスペシャリスト試験・・・
— そにっくん/sonickun (@y_hag) 2014, 10月 18ﾌﾊﾊ起きれたぞ…!!
— そにっくん/sonickun (@y_hag) 2014, 10月 18情報処理技術者試験最高難易度科目「時間までの会場への移動」が行われている
— ろ。＠ 3日目 西く 20b (@kamiya344) 2014, 10月 18ぼくの隣の席の受験者は毎回会場に到達できないの法則
— そにっくん/sonickun (@y_hag) 2014, 10月 19～試験終了後～
各位お疲れさまでございました
— そにっくん/sonickun (@y_hag) 2014, 10月 19がっつりバッファオーバーフローの問題出て白目剝いたけどなんとかなった
— そにっくん/sonickun (@y_hag) 2014, 10月 19午後Ⅱは泣きながら全部埋めた…WEB力が足りなかった…
— そにっくん/sonickun (@y_hag) 2014, 10月 19 会場への到達に成功したので合格はもらった！とおもいきや，午後ⅡでXSSやHSTSなどのWEB系の問題が解けずに大汗を書きました．WEB分野の対策が完全に不足していた．．．
大事なことは全て徳丸本に書いてあった
体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践
- 作者: 徳丸浩
- 出版社/メーカー: ソフトバンククリエイティブ
- 発売日: 2011/03/03
- メディア: 大型本
- 購入: 119人 クリック: 4,283回
- この商品を含むブログ (143件) を見る
合格発表
SC合格しました！
— そにっくん/sonickun (@y_hag) 2014, 12月 19どうも，情報セキュリティスペシャリスト(初心者)です．
— そにっくん/sonickun (@y_hag) 2014, 12月 19半年前にWiresharkの存在を知った人間でもここまでこれることを証明した．
— そにっくん/sonickun (@y_hag) 2014, 12月 19村山先生からもお祝いのお言葉を頂きました．
@y_hag おめでとうございます！
— 村山直紀 (@MurayamaNaoki) 2014, 12月 19
まとめ
情報セキュリティスペシャリスト試験は，私のような実務経験のないぽっと出の大学生でもある程度テクニックを身につけて勉強すれば十分合格できるということを証明できたと思います．
また午後の文章題は国語の問題といわれることもあり，知識がなくとも文章をじっくり読めば解ける場合があるので，最後まで諦めずに解ききることが大事だと思います．
今後は他のスペシャリスト資格の取得を目指して頑張りたいと思います．
