ただひたすら書こうと思った事を書くところ

タイトルの通り、のつもり。主に技術的なこと、を書けるようになりたい。そんな大したことないことも書くかも。

スポンサードリンク

2016年秋の情報セキュリティスペシャリストの午後の答えを晒してみる

某所で晒されてるのを見て何となく自分もやってみたくなりました。
ただ、合っている保証は全くないというか、むしろ自分が合っているかどうか知りたいので、参考までに。
アイテックの解答速報は19に午後1、20に午後2、TACの解答速報はまとめて20にアップされるそうなので、上がったら見比べてみます。 ブログなので、どこをどう考えて答えたかも細かく書いてます。

あ、問題は既にIPAの公式ページに上がっています。

IPA 独立行政法人 情報処理推進機構:問題冊子・配点割合・解答例・採点講評(2016、平成28年)

ものすっごく長くなったので続きを読むの下に埋めておきます。

午後1

大問は1と3を選択しました。
2が簡単だ、という話を後で見たんですが、セキュアプログラミングは無対策だったのでやむなし。
問1を選択してる人が某所には少なくて、不安が広がります…。
が、簡単なのを選ぶとみんなできてしまうから相対的に点数が高くならないのでは、
という気も。そのへんどうなんだろう。

問1

組み込み機器を利用したシステムのセキュリティ対策についての問題。
流行りのIoTを意識した問題でしょうか?

設問1
a:エ b:イ
…調べたら、bはア(アグレッシブ)が正解のようです。IPSecについてはあんまり知らなかった…。

設問2
(1) c: x1.x2.x3.x4 d: y1.y2.y3.y4
…cのほうは外部からローカルに大してSSHログインしているIPということで、22番ポートでESTABLISHEDになっているもの。
dのほうはメール送信してるので25番ポート。SYN_SENTになっているものの外部アドレスの方(宛先なので)。
という基準で書きました。
某所だとcをローカルアドレスにしている人やグローバルじゃないアドレスにしている人が結構いたような。

(2)監視端末の公開鍵をLTEルータのSSHサービスに登録した。
…公開鍵認証を設定する、ともっとシンプルに書いてもよかったかもしれない…。SSHの設定変更と書いてあったので、具体的に書いたのですが、うーん…。
あと、ワンタイムパスワードの認証にするという回答をした人もいるみたいです。
ただ、これは厳密に言うとパスワード強度に全く依存しないわけではないのでどうなんだろう。

設問3
(1)(TCP Wrapperを使って)監視端末が使用するIPアドレスのみを許可し、他のものは拒否(することで実現できます。)
TCP WrapperについてはLPIC対策したときの知識が生きててどんなものかは覚えてました。
これは多分これでいい、はず。
もっともあんまりTCP Wrapperそのものを使ってアクセス制御したことはないですが…。
TCP Wrapperについてはこちら。
TCP Wrapper による SSH 接続のアクセス制御、 /etc/hosts.deny, /etc/hosts.allow の設定 〜 CentOS6 | EasyRamble

(2)ホスト鍵を流用して他機の認証を突破する。
…ここは正直よくわからなかったんですが、まずホスト鍵について誤解していました。
よく考えたらSSHサーバ側の設定なので、警戒すべきは中間者攻撃、ということかもしれません。
そうするとこの回答だと的外れですね。運が良ければ部分点もらえるかもしれませんけれど…。
ホスト鍵を流用して…の部分が引っかかれば、くらいですが期待薄。

参考:【重要】SSHホスト鍵の再作成のお願い(追記あり) | さくらのクラウドニュース

(3)
イメージファイル作成時:ひみつ鍵を使用してイメージファイルにディジタル署名する。
イメージファイル更新時:作成時の署名に使用したひみつ鍵に対応する公開鍵で署名を検証する 。

ここで「秘密」という漢字が何故か試験時間中に正確に思い出せなかったので、ひらがなで書くハメに…。 ひらがなで書いたらどうなるか、というものに対し正確なところはわかりませんが、減点だろう、と見る人は多いようで、ちょっと不安です…。

回答内容的には、秘密鍵を署名に使用、公開鍵を署名の検証に使用、ということをただ書いただけです。
もっと正確にはハッシュ値秘密鍵で暗号化、公開鍵で暗号化されたハッシュ値を復号化し、ハッシュ値が一致することを確認する、ということなのですが、そこまで書かなければダメなのかどうか。
一応、署名をして、それを検証する、ということは書いてはいるので間違ってはいないと思いたいですが。
どこまで見てもらえるかなあこれ…。満点ならすごくラッキー、部分点もらえて御の字、くらいだろうか。
うーん、不安。

(4)同一モデルの他機から、復号のための鍵を抽出する。
…ここは素直に他機の鍵を使って復号、と思って書きました。
ただ、正直鍵の入手の方法って特定できないので、ソーシャルエンジニアリングで入手と書いた人もいるとか。
色々あるなとは思いましたが、問題に全く関係のないことは書かないほうが無難だろうと思ったので、問題文中に存在する「同一モデルの他機」という言葉を使って回答することを心がけました。

問1は振り返ってみても少し難しかったですね。
半分以上点がもらえてれば御の字、実際には15〜25点、と予想。 さすがに15点は低く見積もり過ぎかな?

問3

設問1 a:
…これは知ってるか知らないかだけ。
ラッキーでした。まあ、アとウが明らかに違うので、知らなくても二択くらいまでは絞れますかね。

設問2
b:ウ c:カ
…ここはそれぞれイ・オと答えが割れてるみたいです。
管理PCはOSの管理用コマンドを禁止すると管理できなくなるので、それは起動禁止にしない。
攻撃用プログラムはいずれも起動禁止、あとはマルウェアZを起動禁止設定に入れるかどうか。
イ・オと回答した方は「マルウェアZは文書のマクロとして実装されているのでプログラムじゃない」という意見のようです。
俺は正直どちらが合ってるのかわかりません…。 そこまで考えずに起動禁止だろう、としたのですが…。

(2)プログラム名とハッシュ値をぎそうした攻撃用プログラム
…ここでも「ぎそう」という漢字が思い出せずにひらがなに。ぐぬぬ…。 ここは正直自信薄です。プログラム名の指定は名前変えれば引っかからないのは当然なんですが、ハッシュ値については変えられるのかはわからなかったので適当に書きました。
これ以外の観点だと、未知の攻撃プログラム、というものがありましたが、どこを答えればいいのか…。

設問3
(1)プロキシ2のログに記録される送信元がプロキシ1となるため。
…ここは日本語の書き方にすごく困りました。
言いたいことを言い切るために文字数が足りない…。
プロキシ1とインターネットの間にプロキシ2を入れることになるので、社員PCのインターネット接続は全てプロキシ1→プロキシ2→インターネットという経路になります。
そのため、プロキシ2に送信元として記録されるのは全てプロキシ1になる、はず。
この日本語で大丈夫かが心配です。

(2)
…これは消去法で。多分これでよさそう。
ELBを経由したアクセスのログを見るときにX-Forwarded-Forを見てたので何となくどういうものか引っかかってたのがよかったかな?

設問4
(1)利用者IDとパスワードの組み合わせを総当りして入力し、認証が成功するまで繰り返す。
…これは色んな突破の仕方があるなあと思いましたが、プロキシの認証がIDとパスワードによるものだから、一度侵入したマルウェアならブルートフォースアタックで突破できるだろう、と思って書いたのが上記です。
セッションからIDとパスワード入手…と解答した方が某所にチラホラいて、どれが正しいのか、というところです。

(2)
URLフィルタリング: 業務に必要かつ安全であることを確認したURLをホワイトリストに設定する。
プロキシ単位フィルタリング:"検知"に設定したカテゴリを再び"遮断"に設定し直す。
…ここは多分大丈夫だと思います。設定内容について聞かれてるので、どっちが先かとかは別になくてもいいと思いました。
プロキシ2の機能を見て、あとは本文中の表現をなるべく流用して、という感じで書きました。

問3はやや解きやすかったかも。
ただ時間がなくて見直しできなかったのが心残りです。
設問2、設問4(1)が当たっているかいないかで大きく運命が分かれそう。
高ければ40点ぐらい、低ければ20点台前半ぐらいでしょうか。

うーん、これは午前1で落ちてしまいそうな気がしてきたぞ。
とりあえず解答例待ちですね。
前回も午前1が微妙だと思っていたら午前1は余裕の突破だったので結果が出るまでわかりません。

午後2

午後2は問2を選択しました。
問1は解きやすかったというのも見ましたが、問1にCRYPTRECの推奨暗号リストを全て選ぶ問題があるのを見てこれは無理だなと思ったのと、問2もガッツリプログラム寄りの内容でもなさそうだったので、迷って問2を選択した感じです。

問2

問2はshellshockが題材でした。
騒ぎになったときにもう少し色々見ておけばよかったなあ…。

設問1
(1)ウ(リスクレベル2)
…これはまあ読み取るだけですね。

(2)管理台帳に記載されている機器の、ソフトウェア導入有無とそのバージョンを円滑に確認するため。
…ソフトウェアを導入しているか確認に手間取ったことに対する再発防止策なので、それっぽく書きました。
が、今見返すと見落としに対する再発防止という観点がうまく表現できているか微妙です。
手間取ったことに対しては「円滑に」と書いて対応させたつもりなのですが、どう受け取られるか…。

設問2
(1)
…これは消去法。暗号化されてるかどうかやCookieは関係ないと思います。
(2)
…所有者の権限で実行される場面があまり思い浮かばなかったです…。WEBブラウザはクライアント側なので関係なし、素直にWebアプリBの実行時の権限だと思いました。
まあ、そりゃそうでしょうねえ…。
(3)HTTPリクエスト(ヘッダ) …〜ヘッダと続くので、リクエストかレスポンスかだなと思いました。 まあ普通に考えてリクエストによってサーバがフィールド値を受け取るんだろうなと思ったのでHTTPリクエストと書きました。
(4)() {echo test;}; /usr/bin/cat /etc/passwd
…どう書こうかなあと思いましたが、あくまでフィールド値として指定される文字列なので、クォーテーションはいらないかなと思って外したのと、確認例に従って書くのが無難だろうと思ったので、そのまんま確認例のものを引用しました。

設問3
(1)ある時点での状態と比較する …ここはどうしてもわからなかったので適当に書きました。
調べたら多分「パターンマッチング」が多分適切な答えだと思います。
さすがにこれでは0点ですね…。

(2)サーバへのパッチ適用に対するWEBサーバの動作確認が不要となるため。
…検証作業の観点、と書いてあったので、パッチ適用後の動作確認しない分が楽になる、ということを書きました。
観点は多分いいと思うんですが、書き方がこれでいいか、かなあ。

(3)c:ウ(DNS) d:イ(CNAME)
…レコード、FQDNという言葉が出てきたのでまあDNSだろう、そして〜レコードと書いてあるのと、別名としてFQDNを、と書いてあるのでCNAMEレコードのことだ、と。
まあこれは簡単ですね。AWSでRoute53と戯れたことがあればw
(4)機器を新たに購入せずに、設定のみで導入できるため、初期費用を押さえつつ速やかに導入できること。
…こちらについては、他の方は通信量の上限を随時切り替えられることと書いている方がほとんどだったかな。
俺はアクセスの方ではなく、3週間の期間というほうしか見ていなかったので、本文中に書いてないメリットを書いてしまいました。
一応、「機器を購入する必要がない」は読み取れるメリットではあると思うんですが、それだけだとアクセスが増えることに対しての判断ではないので。迂闊でした。
ここはよくて部分点、0点でも妥当ですね。

設問4
(1)社内Webサーバの社内IPアドレス
…ここはやや書き方に迷いましたが、社内ネットワークでの社内Webサーバのアクセス情報だろうと思ってこう書きました。
アクセス情報と書くか、IPアドレスと具体的に書くかで迷いました。

(2)e:オ(XMLHttpRequest(XHR))
g:ア(Access-Control-Allow-Origin)
h:カ(情報セキュリティ)

…ここはh以外は勘ですが、どうやらhだけ間違ってそうな感じ…。
同一生成元ポリシという言葉を知りませんでした。もったいないなあ。

(3)サーバ内のファイルを外部ネットワークに送信する機能。
…ここはすごく悩みました。が、単純に攻撃者のサイトに情報送信する、というところを想定して書きました。
ただ、ファイルと書いてしまったのがどうか。

設問5
(1)
…重要情報を扱っていないが社外からアクセスできる機器、及び社外からアクセスできないが重要情報を扱っている機器も、場合に酔っては〜と本文中に記載があったので、その両者は同等のレベル設定だろう、と。
てことで社外からアクセスできないが重要情報を扱っている→中に合わせて中にしました。

(2)ア、ク
ここは落ち着いてどの場合がどうなるかを整理しました。
修正前の案で確認が発生するのはリスクレベル2*1になるもの。
修正案で確認が発生するのは脆弱性レベル高・重要度レベル中になる組み合わせです。

スマートにやれそうな気はするんですが、見落としが怖かったので時間かけて一つ一つ確認していきました。
目で見て確認だけだと混乱しそうになったので、
重要情報を扱っている:1 or 0
社外からアクセスできる:1 or 0
脆弱性レベル: 1 or 0
で整理しました。 修正前の案がリスクレベル2になるのは110,011,101,001の4通り。
ア、ウ、オ、クが該当します。
この内、修正後の案で確認が発生するのは011,101。
つまりウ、オは修正後の案でも結局確認します。
残ったア、クが確認が発生しなくなるものとなります。

(3)
j:公開Webサーバが改ざんされる(というリスク)
k:重要情報を攻撃者に送信される(というリスク)

ここもどういうリスクだろう、ということですごく悩みました。
脆弱性で検討するリスクはいっぱい考えうると思うんですが、本文中で懸念されていることを本文中に出てきている言葉で書くとこんな感じかな、と思って書きました。
合ってるといいなあ…。

午後は見た感じギリギリ合格ラインに乗ってるかどうか、くらいでしょうかねえ…。
部分点もらえてると大分楽になりそうですけれど。

と、いうわけで、長かったですがこんな感じです。
正直午後1も午後2も不安しかないですが、うまく引っかかってくれることを祈ります。
まあ少なくともマークミスとかなければ午前1免除はできてるはずなので、ダメでも今後に生かせはすると思います。
とりあえず、解答例がでたらもう少しちゃんと見てみますかねえ。

おまけ。午前の自己採点結果

午前の採点結果。
アイテックの自己採点のページのスクショを置いときました。

  • 午前1

23/30でした。 f:id:yutaro1985:20161018022019p:plain
f:id:yutaro1985:20161018022042p:plain

  • 午前2

19/25でした。 f:id:yutaro1985:20161018022028p:plain f:id:yutaro1985:20161018022034p:plain

午前1も午前2も難しくなったという話が某所でありましたが、個人的にはこんなもんかなと。
過去問対策してれば合格点に届くレベルだと思います。
あと、知らなくても言葉そのものの意味から推測できたりとか。
AAAとかPOODLEとかはさすがに普通に対策してるだけじゃわからなかったと思いますけれど…。(案の定間違えた)
POODLEは話題になったときにもう少し調べておけばよかった。
対応もしたはずなんですけど、幸か不幸かそんなに難しい対応じゃなかったので記憶に残ってなかった…。

ぶっちゃけ、午前はテキストで知識を入れたらあとはひたすら過去問演習で問題暗記するぐらいやれば合格点に届くと思います。
午前で落ちるのは明確な対策不足だと思いますね…。

*1:重要度レベル高かつ脆弱性レベル低、または重要度レベル低かつ脆弱性レベル高

スポンサードリンク