NetAPPのquotaを自動で適用するデーモンを開発した@福岡Ruby会議

皆さん!福岡Ruby会議02楽しんでますか!? 僕はというもののCFP期限を逃し、全く何も生み出していないので、セッションの合間にデーモンを書いていました。 NetAPPではqtreeやVolumeに対してファイル数やディスク容量のクォータを設定することが出来ますが、クォータを設定するだけでは有効にならないので、一度クォータをVolume単位でOFF,ONして上げる必要があります。 今回開発したデーモンを利用すると、指定秒数間隔でクォータをOFFし、指定秒数間隔でクォータがONされます。それぞれの処理はgoroutineで並列実行されるため、300秒間隔で、OFFし、10秒間隔でONするようにすると実質5分毎にクォータが有効になるような実装です。 例外時は停止するよりも通知だけ行い、処理は継続すべきと考え、エラーログを出力し、Slack通知だけして処理は継続する設計です。実運用時はsystemdなどと組み合わせて利用するのがよいと思います。 このあとは @k1LoW さんと @matsumotory

More

パッケージの脆弱性管理サービスVeetaをリリースしました

キャプチャ

以前より個人で開発していたパッケージ脆弱性管理サービスVeetaをリリースしました。 現状はAWSで個人資金にて運用しているため、1オーガニゼーション5台までの制限がありますが、無料で利用できます Veetaのアーキテクチャは下記の通りです。 利用方法は、ドキュメントにも記載がありますが、以下の手順ですぐに始めることができます。 オーガニゼーションを登録する 認証トークンを発行する クライアントをインストールし、認証トークンを設定する この作業を行うだけで、クライアントであるVazがサーバ内のパッケージ情報を取得し、Veetaにアップロードし、自動的にスキャンしてくれます。 スキャンした結果はVeetaのコンソール上で確認することができ、脆弱性の詳細を確認したり、無視することができます。また、脆弱性の有無はレポート機能でメールやSlackに指定した時間に通知することが可能です。 解決したかった課題 以前よりペパボでは一部でVulsを利用して脆弱性の管理を行っておったのですが、Vulsには以下の課題がありました。 スキャンユーザーでのSSHログイン設定が必要、もしくはローカルスキャンの環境作成が必要、ディープスキャンを行うには特権が必要 Vulsはパッケージのドキュメント(changelog)をパースして、 CVE-xxxxxxxの文字列を拾っているだけで、必ずしも脆弱性の有無をチェックしているわけではない 追記 vulsはv4.0でバージョンでの比較にも対応しているようです!@kotakanbeさん有難うございます! Vuls開発者の神戸です。v0.4.0でバージョン比較での検知に対応してます。誤解を生まぬよう修正お願いします" Vulsはパッケージのドキュメント(changelog)をパースして、 CVE-xxxxxxxの文字列を拾っているだけで脆弱性の有無をチェックしているわけではない — Vulsのちょんまげ (@kotakanbe) November 1, 2017 引用元: https://github.com/future-architect/vuls/blob/master/README.ja.md#fast-scan 特に、複数サービスを運用するペパボではサーバの権限管理の観点から共有ユーザーに特権を与えるような運用は厳しい現状がありました。それを解消すべく、今回はクライアントサーバ方式を採用しています。 またVeetaのスキャン方式は取得したパッケージのバージョンとCVEデータベースの情報を全件チェックしているため、Vulsと比べて脆弱性の検知の精度が高い設計です。まだサービス導入期なのでサーバ台数は比較的少ない状態ですが、今後の利用者増加に合わせてスケールアウト可能な構成にしています。 追記 VulsはOVALの対応も行われていたため、いま時点ではVulsのほうが検出精度が高い場合が多いです。この機能はVeetaでも実装したいと思います。 あと、これ事実ですか??VulsはOVALも併用して使ってるので信じがたいっす。。“CVEデータベースの情報を全件チェックしているため、Vulsと比べて脆弱性の検知の精度が高い設計です — Vulsのちょんまげ (@kotakanbe) November 1,

More

SSHのログイン先でも最適化されたvimが使いたい

サーバでオペレーションするときに、ちょっとトラブルシュートしたりするくらいならよいのですが、定期的にログインして作業するサーバがそれなりにあって、その生産性があまり無視できなくなったのでSTNSにstns-setupという機能を設けました。 STNS導入済みのクライアントでstns-setupコマンドを実行すると、事前に定義しておいたコマンドを実行することが出来ます。 $ stns-setup アトリビュートはこんな感じです。 [users.example] id = 1000 name = "example" setup_commands = [ "git clone https://github.com/pyama86/dotfiles.git /home/example/dotfiles", "/bin/sh

More

STNSが単体でのTLS暗号化&クライアント認証に対応しました

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-09-22-22-54-23

先日STNS,libnss-stnsともに0.2.2をリリースしました。主な変更内容は下記のとおりです。 TLS暗号化に対応 TLSを利用したクライアント認証に対応 retry_requestパラメーターでクライントのリトライ回数を指定可能にした ubuntu14.04における再起動が完了しない不具合を修正 TLS関連 これまではnginxなどと組み合わせてTLS/SSL暗号化を提供していましたが、@naoto_gohkoさんからissueを頂いたのと、昨今みんな出来るだけサーバ立てたくないんだろうなぁというフォースを感じたので、単体でTLS暗号化に対応し、サーバ、クライアント共にパラメータを追加しています。 STNS.jp Configuration tls_ca = "keys/ca.pem" # using only client authentication tls_cert = "keys/server.crt" tls_key = "keys/server.key" クライアント、サーバいずれもパラメーターの内容は一緒ですが、サーバのtls_ca及び、クライアントのTLS関連のパラメーターについてはクライアント認証を行うときだけ指定してください。 TLS暗号化だけを利用する場合 stns.conf tls_cert = "keys/server.crt" tls_key = "keys/server.key" libnss_stns.conf api_end_point = ["https://example.jp:1104/v2"] TLSクライアント認証を利用する場合 stns.conf tls_ca = "keys/ca.pem" tls_cert = "keys/server.crt" tls_key

More

~/.ssh/configを分割管理できるpincというコマンドを世に産んだ

初夏が猛暑!皆様いかがお過ごしでしょうか? 昨今、サーバインフラのクラウド化により一人のエンジニアが複数のサービスのサーバに対してSSH接続することも多くなってきました。また多くのサーバでグローバルIPを保つ必要がなくなり、リバースプロキシを置いて管理する構成が増えてきたように思います。そこで悩まされるのが~/.ssh/configの管理じゃないでしょうか? ファイルが500行くらいになったり、新しいエンジニアが入るたびに 「xxxに接続したいんですけど、繋がらないんですよぉ~」 「なっぁぁぁにぃぃぃ~~~~!?この内容を~/.ssh/configに黙って書いてくれ!!!1」 なんてやり取り多いですよね。。そういったやり取りをなるべく少なく出来るようにGolangでpincというコマンドを開発しました。 インストール OS Xで利用することが多いかと思いますのでhomebrewを準備しています。 $ brew tap pyama86/pinc $ brew install pinc 使い方 $ pinc init initコマンドにより~/.ssh配下にconf.dディレクトリ、pinc.yml、base_configファイルが作成されます。 conf.d 配下に作成されたディレクトリ、ファイルを再帰的に読み込みます。 pinc.yml includeディレクティブ配下に配列でファイル、ディレクトリを定義すると再帰的に読み込みます。 base_config ~/.ssh/configをコピーしたファイルです $ pinc gen initファイルで作成、定義されたファイルをマージし、~/.ssh/configファイルを作成します。 便利な使い方 複数サービスを提供している会社の場合、~/.ssh/pinc.ymlに下記のように定義することで、複数サービスの~/.ssh/configを一元管理できるようになります。 include: - /path/to/ServiceA_File -

More

パスワード暗号化について学びを得た

スクリーンショット 2016-05-29 11.03.17

今日はパスワードの暗号化について書いてみたいと思います。 きっかけはSTNSにSudoパスワードを追加した際に@matuuさんよりご指摘をいただいたのがきっかけです。 これまでパスワード暗号化に対する知見が全く無く、「とりあえずSHA256あたりでハッシュ化しとけば漏洩してもダイジョウV!!!」なんて思ってたものですから、これを機に調べてみました。 パスワードの暗号化が有効に働く機会として最も可能性が高いのは、サーバに何らかの手段で侵入され、データベース、ソースコードが参照された状態だと思います。要するに侵入者にすべてを見られた状態でもパスワードを知られ得ないことを目的として暗号化するわけです。 パスワードの暗号化時によく用いられる強固にする手法としてはSalt、Stretchingの2種類があります。今回はこの2点についてまとめてみました。 Saltを利用しパスワード暗号化を強化する Saltというのは御存知の通り塩です。パスワードに塩を足して、いい塩梅にするわけです。前提となる話として、パスワードクラックの手法の一つにレインボーテーブルを用いた手法があります。 レインボーテーブルとは予め一定量の文字列をハッシュ化したものを辞書化しておき、辞書と突合することにより瞬時に元のパスワードがわかるというものです。たとえば、下記のようなコマンドの結果をひたすら作りこんでおけば、passwordやp@sswordのようなパスワードは瞬時に破られてしまいます。 % echo -n 'password' | shasum -a 256 5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8 - % echo -n 'p@ssword' | shasum -a 256 0fd205965ce169b5c023282bb5fa2e239b6716726db5defaa8ceff225be805dc - これに対する有効な対策として、パスワードの文字列を長くすることにより、辞書に登録され得ない値を設定することが挙げられますが、我々人類の多くは怠惰であり、パスワードマネージャーを使うのもニュータイプに限られるため、システム側でなんとかしてやる必要があります。 それに対する一つの手段がSaltです。具体的にはユーザーに入力されたパスワードに何らかの文字列を追加してからハッシュ化し、保存してあげることにより、ユーザーに意識させることなく、パスワード暗号化を強固にすることが出来ます。 手軽にやるのであればユーザー名をハッシュ化したものをSaltとして利用してあげるのが良さそうです。 % echo -n 'pyama' | shasum -a 256 6b513449d1d9f85a652dc54f440603ec19761708c801eb8cd12fc96ee6cedbc9 - % echo -n '6b513449d1d9f85a652dc54f440603ec19761708c801eb8cd12fc96ee6cedbc9password' | shasum

More

STNSでSudoパスワードをサポートした

STNS 0.0.4、libnss-stns 0.0.6リリースしました。今回の主な機能追加は下記のとおりです。 sudoersアトリビュートでsudo用パスワードを指定可能にした STNSがダウンしている時にロックファイルを作成し、一定時間通信を抑制する sudoersアトリビュートの追加 これまでSTNSを利用する場合、sudoersに下記のような設定を追加し、パスワード未利用での運用が必要でした。 /etc/sudoers example ALL=(ALL) NOPASSWD:ALL 今回のアップデートにより、NOPASSWD:ALLを指定せずとも、Linuxの認証基盤であるPAMと連携することにより、sudo時のパスワードが指定可能となりました。 PAMについては@ITのSambaユーザーのパスワード管理 PAMを利用して認証を行うの記事がイメージをつかみやすいと思います。 まずSTNSに下記のような設定を追加します。 /etc/stns/stns.conf [sudoers.example] password = "f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2" hash_type = "sha256" # $ echo "test" | sha256sum # f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2 これはsudoersの設定としてexampleを定義し、パスワードにtestという文字列のSHA256ハッシュを指定します。 このようにパスワードはハッシュ値で指定し、現状はSHA256とSHA512に対応しています。 次にsudoを実行するサーバのPAMの設定を行います。 /etc/pam.d/sudo #%PAM-1.0 auth sufficient libpam_stns.so sudo example # この行を追加 auth

More