sudoを使っていて、

• あるアカウントに対して
• あるコマンドの実行権だけrootで動かせるようにしたい
• その際、引き継いで欲しい環境変数がある

という難しい状況が発生することがある。まぁvulsなんだが。

こういうときには、sudoersに、こんな風に設定すればよい

vuls ALL=(ALL) NOPASSWD:/usr/bin/yum --changelog --assumeno update *
Defaults:vuls env_keep="http_proxy https_proxy HTTP_PROXY HTTPS_PROXY"

これみて意味がわからなくて、manみてもわからなくて、ググれない人は、これ使っちゃダメですよw

さて、これでrbenvも設定し、Rubyも2.3が動くようになったので、やっとRedmine 3.2のInstallへ。

1. まず、必要そうなものを入れておく。
   • pkg install nginx ImageMagick mariadb100-client
   • gem install bundler –no-rdoc –no-ri
   • curl http://www.redmine.org/releases/redmine-3.2.0.tar.gz > redmine-3.2.0.tar.gz
2. Redmineを実行するアカウントを作る
   • ここでは、redmineとする
3. Redmineを/usr/local/wwwに入れる
   • mkdir /usr/local/www
   • cd /usr/local/www
   • tar xzf redmine-3.2.0.tar.gz
   • ln -s redmine-3.2.0 redmine
4. Redmineの初期設定を行う
   • cp redmine/config/database.yml.example redmine/config/database.yml
   • vi redmine/config/database.yml
     • 書き換えるのは、productionの部分だけで良い

   • production:
       adapter: mysql2
       database: redminedb
       host: xxx.xxx.xxx.xxx
       username: redmine_user
       password: "UltraSecret"
       encoding: utf8

5. RubyのGemを入れる
   • 今回はUnicornで動かすので、一手間かける。
     • vi redmine/Gemfile.local

       gem "unicorn"

   • bundle install –without development test postgresql sqlite
6. Redmineの初期設定を実行
   • sudo -u redmine /bin/sh
   • bundle exec rake generate_secret_token
   • RAILS_ENV=production bundle exec rake db:migrate
   • RAILS_ENV=production REDMINE_LANG=ja bundle exec rake redmine:load_default_data
7. Webrickでの試験
   • Rails 4.2以降、Webrickで通信を待ち受ける場合、defaultではlocalhostしかListenしなくなった。
   • ruby bin/rails server webrick -e production -b xxx.xxx.xxx.xxx と-bを指定してやれば、その引数のアドレスでListenするようになる。
8. NGiNXとUnicornの設定
   • /etc/rc.conf に nginx_enable=“YES”を追加
   • Unicornを設定
     • unicorn設定ファイル内after_fork内でuser,groupをredmine:redmineに設定しているので注意
     • ぐぐると、Process ownerのchown関係がちゃんと動かない(worker.userがなかった頃の)unicorn.rbが引っかかるので注意
     • vi redmine/config/unicorn.rb

       # cat config/unicorn.rb 
       # -*- coding: utf-8 -*-
       # Unicorn Configuration File for Redmine
       #       http://unicorn.bogomips.org/examples/unicorn.conf.rb
       
       $unicorn_user = "redmine"
       $unicorn_group = "redmine"
       
       @dir = "/home/www/rrrm.rusty-raven.net/redmine"
       working_directory @dir
       worker_processes 2
       
       listen "/var/run/unicorn_rrrm.sock", :backlog => 32
       # listen 8282, :tcp_nopush => true
       
       timeout 30
       
       pid "/var/run/unicorn.pid"
       stdout_path File.expand_path("log/unicorn.stdout.log", @dir)
       stderr_path File.expand_path("log/unicorn.stderr.log", @dir)
       
       preload_app true
       
       check_client_connection false
       
       before_fork do |server, worker|
         defined?(ActiveRecord::Base) and
             ActiveRecord::Base.connection.disconnect!
       
         old_pid = "#{server.config[:pid]}.oldbin"
         if old_pid != server.pid
           begin
             sig = (worker.nr + 1) >= server.worker_processes ? :QUIT : :TTOU
             Process.kill(sig, File.read(old_pid).to_i)
           rescue Errno::ENOENT, Errno::ESRCH
           end
         end
       end
       
       
       after_fork do |server, worker|
         defined?(ActiveRecord::Base) and ActiveRecord::Base.establish_connection
         begin
           worker.user($unicorn_user,$unicorn_group)
         rescue => ex
           STDERR.puts "could not change user, oh well"
           STDERR.puts ex.to_s
           raise ex
         end
       end
       
       # 

     • sudo unicorn_rails -c config/unicorn.rb -E production -D でunicornが起動する。
   • NGiNXの設定
     • NGiNX.confを修正する

               upstream REDMINE {
                       server unix:/var/run/unicorn.sock;
               }
               server {
                       listen 80 sndbuf=16k
                       server_name     redmine.example.net;
                       location / {
                               proxy_pass                      http://REDMINE;
                       }
               }

これで、とりあえず、Redmineまでは動くはず。

• 参考: http://www.virment.com/ubuntu-nginx-unicorn-rails/

Last update: 2017/02/06 : Check on FreeBSD 11

VulsというToolが公開されている。https://github.com/future-architect/vuls/blob/master/README.ja.md

要するに、Linux(現時点ではUbuntu, Debian, CentOS, Amazon Linux, RHEL)及びFreeBSDに対する脆弱性検出ツールである。 誤解する人もいるみたいだが、このツールは脆弱性を「検出」するだけであって、対処(pkgのUpgradeとか)はしない。 対象のServerにsshでloginして、様々な情報を持ってくることでそのシステム内の脆弱性を検出する。 したがって、rootでsshするという操作になる。（ただし、これは現在改良中らしい)

Vulsは、Goで動作する。散々わがままを言った挙句、VulsはFreeBSD上でも問題なく動作した。

• FreeBSD 11.0をInstallする
  • いつもの通りで良い。難しいことはなに一つしない。
  • pkg install go git sqlite3
    • 2017/02/06時点では必要なかったが、場合によってはgccを入れておくこと。
• vulsを実行するAccountを作成し、sshの鍵を生成する(ここでは、仮にmonitorとする)
  • vuls関連のDBなどは全て~monitor下に配置する
  • adduserなどでアカウントを作成。
  • ssh鍵関連の設定
    • cd ~monitor
    • sudo -u monitor ssh-keygen -t ed25519
    • cat ~/.ssh/id_ed25519.pub » ~/.ssh/authorized_keys
    • chmod 600 ~/.ssh/authorized_keys
      • 公開鍵は、検査対象マシンのauthorized_keysにも転記しておくこと
  • vuls Install前の準備
    • mkdir /var/log/vuls
    • chown monitor /var/log/vuls
    • comod 700 /var/log/vuls
  • 環境の整備
    • .profileに以下を記述

    • export GOPATH=$HOME/go
      export PATH=$PATH:$GOPATH/bin

      • 注意点。$GOROOTは設定しないこと。迂闊に設定すると色々ハマるので、自分で何をやっているかわからない人は触らないのが吉
      • go関係の実行ファイルなどは、$GOPATH内に配置される。
  • go-cve-directonary をinstallする
    • mkdir -p $GOPATH/src/github.com/kotakanbe
    • cd $GOPATH/src/github.com/kotakanbe/
    • git clone https://github.com/kotakanbe/go-cve-dictionary.git
    • cd $GOPATH/src/github.com/kotakanbe/go-cve-dictionary
    • make install
      • cc関連でWarningが出る。これは、FreeBSDのccはclangであり、gccではないため。

    • for i in 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017; do
      go-cve-dictionary fetchnvd -years $i
      go-cve-dictionary fetchjvn -years $i	# もしJVNの情報が要らないならば、ここはskipしても良い
      done

      • 自分はbashを使わないのでこんな迂遠なことになるが、bashなら for i in {2002..2017}; do go-cve-dictionary fetchnvd -years $i; done で行ける
      • ここは時間がかかるので覚悟すること。（昔と比べると本当に早くなったけど）
        • 2017/02/06現在、作成されるDBファイルは、以下のようになった。

        • -rw-r--r--  1 monitor  staff  740999168 Feb  6 12:38 cve.sqlite3
          -rw-r--r--  1 monitor  staff      32768 Feb  6 12:39 cve.sqlite3-shm
          -rw-r--r--  1 monitor  staff   22956672 Feb  6 12:39 cve.sqlite3-wal

  • vuls をinstallする
    • mkdir -p $GOPATH/src/github.com/future-architect
    • cd $GOPATH/src/github.com/future-architect
    • git clone https://github.com/future-architect/vuls.git
    • cd $GOPATH/src/github.com/future-architect/vuls
    • make install
      • cc関連でWarningが出る。これは、FreeBSDのccはclangであり、gccではないため。
    • go get github.com/future-architect/vuls
    • vulsのdictionary serverを起動する。
      • go-cve-dictionary server
  • 設定ファイルを作成する
    • 設定ファイルをどこに置くかは少し問題になる部分だが、今回は、~monitor/vuls下にvuls関連のファイルを全部置く前提で行く。

    • config.toml

      [servers]
      
      [servers.example]
      host         = "192.0.2.1"
      port        = "22"
      user        = "monitor"
      keyPath     = "/home/vuls/.ssh/id_rsa"

  • 対象となるServerに必要な設定を突っ込む
    • 対象となるホストに、config.tomlに記載したアカウントを作成する(仮にmonitorとする)
    • ~monitor/.sshにauthorized_keysを設置する
    • visudoを実行し、monitorがno passwordでroot権限を取得できるように設定する
      • monitor ALL=(ALL) NOPASSWD: ALL
      • 将来的には、実行できるコマンドを制限するべきだが、とりあえず今はこれで。
    • vulsを動作させるServerから対象のサーバーにsshで接続でき、かつsudoを実行してpasswordなしでrootになれることを確認する
  • ここまでできたら、vuls prepareを実行する
    • エラーが出たら、何らかのpermissionがおかしいなどが考えられるので、対応する
      • どうしても分からなければ、vulsのslackに報告するか、gitでissueを上げる
  • で、最後にscanする。
    • vuls scan

まだまだ考える必要がある部分はあるが、なかなか素晴らしい。

• Issue
  • Dictionary Serverの扱い
    • daemon的に動かし続けるのがいいのか、vulsを実行する際に起動するのがいいのか？
      • dailyでauto scanかけるなら、動かし続けるのもいいのだが… localhostからしか接続を許可していないからよしとするか？
  • CPEの設定
    • これは、やはり様々なSampleが欲しいところ。

FreeBSDでacme-clientを利用してLet's Encryptの証明書取得を行うことを考えた。ので、ちょっと調べたメモ

→ 続き...

FreeBSD 11.0 Releaseが出ている。 元々は、8月くらいにShipされるはずだったのだが、OpenSSLを始めとする様々な脆弱性が公開されたことから、その対応を待って公開することになったものだ。 そのせいもあって、Release時点で11.0-RELEASEではなく11.0-RELEASE-p1として公開された。

# 実際には、11.0 は少し前に公開されたのだが、脆弱性問題があるので使うな！ということになっていた。

さて、というわけで、手元のFreeBSD 10.3で動いているServerを11.0にupgradeしようとしたメモを。

FreeBSDはOSのUpgradeが原則としてとても簡単なOSである。

1. freebsd-update -r 11.0 upgrade
2. freebsd-update install
3. reboot
4. freebsd-update install
5. (場合によってpkg-static upgrade -f pkgを先に実行)
6. pkg update
7. pkg upgrade
8. portsnap fetch
9. portsnap update
10. (場合によってfreebsd-update installを実行)
11. reboot

のような手順でいいのだが、今回は少しハマったので愚痴を兼ねて。

まだ、SLB系とDNS系しかupgradeしていないのでこのくらいだが、もしかしたらもっと出るかもしれない…出たら追記する。

→ 続き...