NGINXは標準ではCGIを動作させることができない。そこで、fcgiwrapを利用して動かしてみる。

http://qiita.com/hmikisato/items/c793ced0ba2695a89de6を参考にした。

• pkg install nginx fcgiwrap
• pkg install p5-CGI p5-JSON

で、fcgiwrapの設定。rc.confに以下を記載

nginx_enable="YES"

fcgiwrap_enable="YES"
fcgiwrap_user="monitor"
fcgiwrap_socket_owner="monitor"
fcgiwrap_socket="unix:/var/run/fcgiwrap/fcgiwrap.socket"

nginx.confを以下のように編集

load_module /usr/local/libexec/nginx/ngx_mail_module.so;
load_module /usr/local/libexec/nginx/ngx_stream_module.so;

worker_processes  1;
user monitor;
events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;
    server {
        listen       80;
        server_name  localhost;

        location / {
            root   /home/monitor/htdocs/vulsrepo;
            index  index.html;
        }

	location ~ \.cgi {
		include		fastcgi_params;
		fastcgi_pass	unix:/var/run/fcgiwrap/fcgiwrap.socket;
		fastcgi_param	SCRIPT_FILENAME $document_root$fastcgi_script_name;
		root		/home/monitor/htdocs/vulsrepo;
	}

        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   /usr/local/www/nginx-dist;
        }
    }
}

そして、nginxとfcgiwrapを起動

# service fcgiwrap start
# service nginx start

次にvulsrepoを導入。 Document rootを/home/monitor/htdocs/vulsrepoにしてあるので、以下を実行。

mkdir -p ~monitor/htdocs/vulsrepo
chown -R monitor:staff ~monitor/htdocs

次に、vulsrepoをgithubから取得

monitor$ cd /home/monitor/htdocs
monitor$ git clone https://github.com/usiusi360/vulsrepo.git

vulsの出力を取り込む必要があるので、

monitor$ vuls scan 
monitor$ vuls report -to-localfile -format-json --cvedb-path=/home/monitor/vuls/cve.sqlite3  

を実行した上で、

monitor$ cd /home/monitor/htdocs/vulsrepo
monitor$ ln -s /home/monitor/vuls/results .

これで、Browserからアクセスすれば、Vulsrepoの出力が見れるはず。

あとは、毎日の更新問題だけ。 以下のようなscriptをcronでdailyに動かせばOK

#! /bin/sh

##### Main Routine
. ~/.goenv.sh
DATE=`date "+%Y"`

${HOME}/go/bin/go-cve-dictionary fetchnvd -years ${DATE}
${HOME}/go/bin/go-cve-dictionary fetchjvn -years ${DATE}

# Run vuls
cd $HOME/vuls

${HOME}/go/bin/vuls scan
${HOME}/go/bin/vuls report -to-localfile -format-json --cvedb-path=${HOME}/vuls/cve.sqlite3

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

→ 続き...

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等)の場合に入れておくと良い

これを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

→ 続き...

まくら

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

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

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

本文

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

会話中に

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

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

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

<< 新しい記事 | 古い記事 >>