転載・引用について

ユーザ用ツール

サイト用ツール


tweet

つぶやき

技術系や雑感等は再編集して本文の記事にする事を前提としているので、こっちにLinkを張らないでください。

FreeBSDのWeb ServerにLet's Encryptの証明書を突っ込む

かねてからの懸案だったLet's Encrypt証明書対応のメモ。

2017/02/01現在、まだFreeBSDでの動作確認をしていないので、この記事を鵜呑みにしても動かない可能性が高い。

→ 続き...

· 2018/07/02 19:01 · 2018/05/14 13:51

pfSenseとXenServer

XenServerでpfSenseを使っていると、非常に限定された状況で、通信性能が激烈に劣化することがある。

この劣化は、以下の条件で発生することがわかっている。(ただし、これに限定されるかどうかは未確定)

  • 同一のXenServer上に配置されているVM間での通信である
  • XenServer側及びVM側双方でTSO(TCP Checksum Offloading)が生きている

この条件に合致する場合に、TCP Checksumがおかしくなって性能が激烈に低下するように見える。 こういう場合には、以下の設定をVM側で行えば良い

  1. /boot/loader.conf.localを作成し、以下を記載
    • net.inet.tcp.tso=0
      kern.ipc.nmbclusters=1000000	# この行は、NICがIntel系(em等)の場合に入れておくと良い
  2. /etc/sysctl.confに以下を記載
    • net.inet.tcp.tso=0
      kern.ipc.nmbclusters=1000000	# この行は、NICがIntel系(em等)の場合に入れておくと良い

加えて、rc.confなどで設定するifconfigの引数に -tso を加えると良い。自分の場合は、 -rxcsum -txcsum -tso -lro を加えている

これをpfSenseで行うには以下を実行する。

  1. System → Advanced → System Tunables を選択
    1. net.inet.tcp.tso エントリーがあれば、それを編集、なければ、「+」をクリックして作成し、値を 0 にする
    2. kern.ipc.nmbclusters エントリーがあれば、それを編集、なければ、「+」をクリックして作成し、値を 1000000 にする
  2. Diagnostics → Edit File を選択
    1. ファイル名に /boot/loader.conf.local を指定し Load をクリック
      • 以下を記載する
        net.inet.tcp.tso=0
        kern.ipc.nmbclusters=1000000	# この行は、NICがIntel系(em等)の場合に入れておくと良い

これで、再起動すればOK。

なお、XenServer側からの設定に関しては、

    xe vif-param-set uuid=VMに割り当てられているVIFのUUID other-config:ethtool-gso="off"
    xe vif-param-set uuid=VMに割り当てられているVIFのUUID other-config:ethtool-ufo="off"
    xe vif-param-set uuid=VMに割り当てられているVIFのUUID other-config:ethtool-tso="off"
    xe vif-param-set uuid=VMに割り当てられているVIFのUUID other-config:ethtool-sg="off"
    xe vif-param-set uuid=VMに割り当てられているVIFのUUID other-config:ethtool-tx="off"
    xe vif-param-set uuid=VMに割り当てられているVIFのUUID other-config:ethtool-rx="off"

とすれば良いのだが、自分の場合は面倒なので、全VMのTSO類をoffにするために以下のようなscript実行している

#! /bin/sh
# See http://cloudnull.io/2012/07/xenserver-network-tuning/
#
# for All VM's VIF NIC offloading to off.
#
for VMUUID in `xe vm-list | awk '/uuid/ {print $5}'`; do
  INSTANCEID=`xe vm-list uuid=$VMUUID | awk '/name-label/' | grep -v "Control domain" | sed 's/     name-label ( RW): //'`
  for VIFUUID in `xe vif-list vm-uuid=$VMUUID | awk '/uuid/ {print $5}' | sed '/^$/d'`; do
    echo $INSTANCEID
    xe vif-param-list uuid=$VIFUUID | grep "other-config"

    xe vif-param-set uuid=$VIFUUID other-config:ethtool-gso="off"
    xe vif-param-set uuid=$VIFUUID other-config:ethtool-ufo="off"
    xe vif-param-set uuid=$VIFUUID other-config:ethtool-tso="off"
    xe vif-param-set uuid=$VIFUUID other-config:ethtool-sg="off"
    xe vif-param-set uuid=$VIFUUID other-config:ethtool-tx="off"
    xe vif-param-set uuid=$VIFUUID other-config:ethtool-rx="off"

    xe vif-param-list uuid=$VIFUUID | grep "other-config"
  done
done

この時、XenServerのdom0側も設定したいのであれば、併せて以下のscriptを実行するのも良い。

#! /bin/sh
# See http://cloudnull.io/2012/07/xenserver-network-tuning/
#
# for All XenServer PIF NIC offloading to off
#
for PIFUUID in `xe pif-list | awk '/uuid/ {print $5}' | sed '/^$/d'`
  do
    xe pif-param-list uuid=$PIFUUID | grep "other-config"

    xe pif-param-set uuid=$PIFUUID other-config:ethtool-gso="off";
    xe pif-param-set uuid=$PIFUUID other-config:ethtool-ufo="off";
    xe pif-param-set uuid=$PIFUUID other-config:ethtool-tso="off";
    xe pif-param-set uuid=$PIFUUID other-config:ethtool-sg="off";
    xe pif-param-set uuid=$PIFUUID other-config:ethtool-tx="off";
    xe pif-param-set uuid=$PIFUUID other-config:ethtool-rx="off";

    xe pif-param-list uuid=$PIFUUID | grep "other-config"
done
· 2018/07/02 19:01 · 2018/05/14 13:50

セキュリティー人材とやらについて

まくら

最近忙しすぎて、ちっともTwitterでもFaceBookでも駄文を書けなかったのだが、今日久しぶりにTwitterでちょっとした会話をしたので少し書いてみたくなった。

お題はSecurity人材というもの。もちろん、このコンテクストでは情報セキュリティを採り上げるので、物理セキュリティはあまり考慮に入ってません。

まぁ、個人的考えだし、異論反論はあると思うけど、例によって気に入らない人はスルーしてくださいな。

本文

世は「セキュリティ人材不足」とやらで姦しいわけだが、そもそも個人的には「セキュリティ人材 is なに?」的な気分なわけだ。 もっと言えば、それ以前にいわゆる「セキュリティ is なに?」という気分になるわけで。

日本は島国であって、かつ江戸時代という「外国の影響を極力排除」した上で、合衆国のような「小さな単位で分割統治」することによる「均質化」を経験してきた歴史がある。この歴史観には異論が多々あるだろうが、個人的にそう感じるわけだ。

この歴史が、「均質化の結果」としての「異物の排除」が文化として定着させたように思う。その結果としての「身近に異物がない」状態がすなわち「感覚的な安全」論(つまり「安全でないなら異物を排除すれば良い」的考え)になっているように感じる。もちろんこれはある一面から切った見方であって、当然それ以外の流れも考えもあるが、今でもこの「感覚的な安全」論が割と幅を利かせているのではないか?と思わざるをえない。

自分がセキュリティの話をする時に必ず使う説明に、Securityの元となる単語のSecureの語源の話がある。

Secure = Se-Cure = Se + Cura = (〜から)離れる(という接頭語) + 不安・心配事

つまり、Secureとは「不安や心配事から離れた状態」=「不安や心配事がない状態」が原義である。

この原義から、日本における「感覚的安全」を実装するための「異物排除」はそれがいいか悪いかは置いておいて確かにセキュリティ対策と言える。 もちろん、今のご時世、このセキュリティ実装では、対策としてはあまりにもお粗末に過ぎるのだが、自分の経験では、日本において、れがセキュリティ対策の一番目に入りやすいように思う。(単に日本以外の国の事を知らないだけです)

セキュリティ対策の話は本題ではないので、話を引き戻す。

自分が、「ゼキュリティ人材不足」という表現を見た時に思うことは、

  • セキュリティ人材と言われた時に想像するのはどういう人材だろう?
  • 不足していると言われているセキュリティ人材ってなんだろう?

ということ。そして、実はこの言葉、おそらく定義がないまま「イメージ」だけで語られているような気がする。 曰く

  • 情報システムへの攻撃を防いでくれる正義の味方
  • 情報システムへの攻撃を見つけて対応してくれるスーパーマン

じゃないか?と思うわけだ。

ぶっちゃけ、「他力本願で甘えすぎじゃない?」と思わざるをえない。

インターネットは、(ある意味)異物の集合体である。Internet = Inter-Network であり、Network間接続なのだから、そもそも定義として異物の集合とも言える。そこに、黄門様よろしく「葵の紋所」を見せれば問題が解決するだの、ウルトラマンよろしく最後は「スペシウム光線」で、などという「必殺技」や「銀の弾丸」なんてあるはずがない。

私見だが、 ;#; 「何(対象)」を、「誰(攻撃者)」から、「どのくらいの期間」、「どんな手法」で、「いくら(費用)」かけて護るか - (1) ;#; が定義されない限り、いわゆるセキュリティを実装することはできない。 この定義がないまま「規定」だけ実装している例はごまんと見ているが、そんなものはセキュリティではない。

とすると、(少なくとも自分が考える)セキュリティ人材とは、上記(1)を定義・実装できる人ではないかと思う。

翻って、いわゆる報道などで見かけるセキュリティ人材とやらは、「セキュリティ関連技術を知っている人」に矮小化されているように感じる。報道で取り上げられるようなセキュリティの専門家と言われる人は、「セキュリティ関連技術を知っている『だけ』の人」では断じてないにもかかわらず、そういう取り上げられ方がされやすいように見受けられる。 もちろん、「関連技術」は実装する際に非常に重要だし、緊急時の対処にもやはり非常に重要である。だから、セキュリティ技術がある人材はもちろん育てなければならないし増えるべきだと思うが、「セキュリティ人材不足」というコンテクストで考えるなら「そこは本質ではない」と言いたくなるわけだ。

会話中に

「セキュリティ人材という言葉でいうと発する人、受け取る人によって定義、理解も曖昧でどこまでのことを求めているのか、先ほどのどの範囲をどのようにカバーできるのかも見えてこず、足らない足らないと騒ぐだけになっちゃうのが怖いなって思います」

という発言があったが、まさにこの「騒ぐだけ」になること、そして「何が足りないのか」という場合の「何」の部分が置き去りになるのが恐ろしい。

今本当に必要なのは、「できるだけ根に近い部分」を(なんとなくでも)理解している人材なのだろうと思う。そこがあって初めて、実装できる技術者も生きるのだろうと。「排除する」だけでなく、「入り込まれても大丈夫なように対策」することや、「攻撃成功時のリターンよりも攻撃失敗時のリスクのほうが大きい」ようにすることを考えられる人材や制度が必要なのだろうなと思う。

もう一つ。やはり会話中に

「それで数年後には量産された人材がぽいっとされてしまうこととか考えると心が痛くなります。」 </note> という発言もあって、これは自分も同感するところである。

しかし、この点は実は自分は楽観している。

自分は、現時点では、セキュリティ関連技術を「現場で身につける」のは多くの人にとって難しいと思う。 それは、必要となる知識が多岐にわたるからであり、セキュリティ技術を身につける余力があるような「現場」は少ないからである。

この問題は、少し前の「プログラマが足りない」→「学校で教える」→「JAVA(等各種言語)プログラマ量産」の流れと同じだと思っている。 今、曲がりなりにもプログラマやコーダーがそこそこの人数存在しているのは、この「プログラマ量産」プログラムのおかげである。(足りているかの議論は別)

量が増大したことにより質が劣化したという話もしばしば聞くが、供給がないと今よりもさらにプログラマ不足になっていたであろうことは想像に難くない。もちろん、質の向上は永遠のテーマだが、そもそも量が提供されなければ質の向上は望めない。(量が不足していると、高品質のプログラマも時間に追われ、結果として単体あたりの品質が劣化する可能性が高い)

いうまでもないが、個人としての質が向上しないならば必ず淘汰されてしまう。ここでの議論は個人レベルの話はしていないので、為念。

セキュリティの基本を学んだ人材は量産されるべきである。というより、セキュリティの基本はすべての人が学ばなければならない。基本を理解した上で、それが正しいか間違っているかを考えるべきであって、「観念」だけでセキュリティを語られてはたまらない。

そして、セキュリティの基本を学んだ人の中から、セキュリティ技術を理解し使える人を量産しなければならない。そして、常識的に供給されなければならないと思う。

セキュリティの基本的な考え方は、(情報システムに限らず)どこでも必ず使えるものだから、セキュリティを学び、曲がりなりにも身につけた、人材は、たとえ量産型であろうとも、簡単に「ポイ捨て」されるようなことはないと、そして「ポイ捨て」されても次のチャンスはきっとあると思っている。

少なくとも、現時点(というよりこれから10年くらい?)は、ちゃんと基本的な知識を持った人材が増え、今の疲弊したITという土壌をもう一度豊かにする段階ではないかと思う。

最後に、やはり会話からの言葉で

一点集中というよりはもう少しセキュリティとそれを支えるものまでと付随した上での知識、技術を身に着けられるようにしていくことが大事なんだろうなと思います。

というのがあったが、これがおそらく最も大事なんだろうと思う。

· 2018/07/02 19:01 · 2018/05/14 13:49

年金機構問題における部外者の反応を見て思った雑感

昨日の駄文が結構多くの人の目にとまったらしく、嬉しいやら恥ずかしいやらという状態なのだが、人並みに自己顕示欲くらいはあるので、もう少し駄文を書いてみようと思う。

少なくとも昨日の駄文よりもさらに駄文なので、おヒマな方どうぞ。 あと、あくまでも個人の雑感なので、どういう感想を持っていただいても構わない(当方は感知しない)が、気に入らないなら「華麗に」スルーしてください。

ちなみに、私も「部外者」なので、もちろん「天に向かって唾を吐いている」事は自覚がある。自分に対する戒めも兼ねて。

さて、年金機構の問題に関わらず、今の日本はこの種の「華麗にスルーする」というスキルが無くなって来ている気がしている。 ちょっと何かあると、反射的に「非難」の意見を匿名(と思しき)方法(twitterや2ch等)で無造作に表明する。 その意見表明は、多くの場合、「非難」であって「批判」になっていない。 年金機構の問題で云っても、「そんな不審なメールを開くのが悪」的な意見を表明する方々が非常に多い。

はっきり言うが、この種の非難をしている人の多くは「不審なメールは誰にでもわかるものである」という「とてつもなく大きな誤解」をしているようにしか見えない。

10年前ならいざ知らず、今時のこの種の攻撃(の一部)は、「不審メールと思えない」ような精度で実施されている。 一部の「セキュリティ知識を十分に持つプロフェッショナル」ですら引っかかる事があるようなレベルである。 要するに、今回非難している方々の、おそらく、ほぼ100%近くが、まともに攻撃を受けたら引っかかるようなレベルのものである場合があるということ。 しかも、このレベルの攻撃なら、引っかかった時に「引っかかったと認識できない」レベルであると言える。

ただし、今回の年金機構に来たメールがそのレベルのものだったかどうかは寡聞にして知らない。そのレベルのものであっても全く不思議はないし、逆に「こんなモノに引っかかったのかよ」レベルであったかもしれない。 ここで言いたいのは、そういうレベルの攻撃が、もう普通に行われているということ。

ここで、「セキュリティ知識を十分に持つプロフェッショナル」の方々が違うのは、

  • 引っかかったかどうかを判定するための判断材料の収集を「自動化」している・することができる
  • 引っかかった可能性が高いと判断した時に、最小限何を行うべきかを熟知しており、そういう行動をそれこそ反射で実施する
  • 実際に引っかかったかどうかを調べるための手段を持ち、その手段を適切に取ることができる
  • 引っかかった時の影響範囲を(大まかにでも)想定でき、どうすればよいかを判断できる
  • 引っかかった時の被害を最小限に抑えることができる
  • 最終的に何が起こったと考えられるかを他人に説明できる

ということ。

つまり、「セキュリティ知識を十分に持つプロフェッショナル」は、技術力があるかどうかではなく、何をどうすればよいのかを正しく認識しているのである。 もう少し言えば、「どこまでを自分で判断するか」、「どこからは他の力を借りるか」を想定し、判断することができる人のことをいうのである。

このような判断(作業)を普通のように行える人は、情報を「効率よく」収集し、自分の判断を素早く行えるようにする努力を「継続的に」実施している。(むしろ、すでに努力ですらなく、習慣化している状態かもしれない) 従って、反射的な反応はあったとしても、入手してくる情報によって常によい方向にフィードバックをかけ、正しい方向に修正することができるし、その修正速度も非常に早い。

さて、反射的に「非難」するだけの人。 この種の人たちは、「自分の仮説」や「自分の思い込み」に都合のよい情報を収集するのが非常に早い。その上で、一度自分が建てた仮説にしがみつき、その仮説が間違っているかもしれないという事を受け入れず、指摘された場合過剰反応するというループを繰り返す。

こういう人たちに必要なのは、いわゆるスケープゴートである。 要するに、「非難されても仕方がない」と「(自分の)周囲の人たちが思ってくれる」攻撃対象である。 しかも、攻撃対象がいわゆる「お上」であるならなお都合が良い。 なぜなら、「弱い立場の自分」が権力を持っている「お上」に対して物申して憂さを晴らす事ができるから。

さて、よく考えると、「セキュリティ知識を十分に持つプロフェッショナル」が実行している事は普通の人にだってできる「はず」の事である。 (よく見てほしいが、「セキュリティのプロ」の話をしているわけではない。)

もちろん、「セキュリティ知識を十分に持つプロフェッショナル」と同じ位の速度・同じ位の精度で実施することは難しい。 しかし、時間や精度は知識や経験で、より短く・より高くなっていくものである。 そのために必要なのは、

  • 「ちゃんと考えておくこと」、つまり事前の準備
  • 「時々でいいから」継続して見直すこと

くらいのものである。

問題は、「継続的に」情報を集める事と、集めた情報を以って、自分の仮説・思い込みを「適切に修正し続ける事」が難しい事である。
前者の難しさは、「習慣的に」実施できるようになるための努力が続かない(自分がまさにそう)こと。
後者の難しさは、自分の間違いを認めることに対する「不快感・恥ずかしさなどに対抗する」ことが心理的に難しいこと。
特に(個人的には)後者の問題が非常に大きい。

しかし、もう、反射的に「非難」して憂さ晴らししていられる状況ではなくなってしまったと思う。

日本では、すでにインターネットは一般に普及し、大多数の人がすでにインターネットをなんらかの形で利用している。もうすぐ、マイナンバーも施行される。GoogleやAmazonに限らず、e-Commerceなどでは、購買履歴などの情報も蓄積されているだろう。さらにはIoTなど、世の中を変えていく技術がどんどん出てくる。

そういうときに、「利便性をできる限り損なわず、可能な限り安全に」インターネットを利用するにはどうするべきか。 非難して憂さを晴らしている場合じゃないし、他人が護ってくれるという幻想は捨てるべきだと思う。

結局、いつものとおり、まとまりのない駄文であるけど、最後に一言。

なぜか日本では、水に落ちた犬を叩く事で何かした気になる人が多すぎる気がします。明日は我が身という事を本当に考えるべきです。
水に落ちた犬に手を差し伸べるような社会の雰囲気とセキュリティ運用が望まれると思います。

以上、駄文でした。

→ 続き...

· 2018/07/02 19:01 · 2018/05/14 13:44
このウェブサイトはクッキーを使用しています。 Webサイトを使用することで、あなたはあなたのコンピュータにクッキーを保存することに同意します。 また、あなたはあなたが私たちのプライバシーポリシーを読んで理解したことを認めます。 同意しない場合はウェブサイトを離れてください。クッキーに関する詳細情報
tweet.txt · 最終更新: by seirios

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki