読んでいただけると幸いです。6/22の朝空港へ向かう際の出来事でした。Molochが不定期にキャプチャ停止する問題を、我々はcronでモグラ叩き戦法という水際作戦で乗り越えようと考え、弊社セキュリティオペレーションセンターの清水が圧倒的当事者意識で上記問題のあらゆる原因を検討していました。清水「molochのパケットキャプチャ用のバッファが16KBしかないんではないか、という気がしてます<これからソース読む。MTU1500以上のいわゆるジャンボフレーム/ジャンボパケットを扱う際にはConfig設定を入れなければなりませんでした。そのパラメーターはconfig.iniにはデフォルトで記載されていない「snapLen」という隠しパラメーターです。羽田空港に到着してゲートをくぐるや否や、検証機のチューニングをします。Byteで最大値は128KBでした。ソースコードの読み込みが甘かったようです。このパラメーターは一つ前の0.18.2から追加された真新しいものでした。Bでまた落ちたので、競技環境の設定が64KBであると想定し、ちょっと余裕を持たせてsnapLen=81920で再度設定を入れ直して飛行機に乗りました。夕方、沖縄のホテルで確認するとエラー停止しなくなっていました!ただ、以下のようにジャンボフレームを捕まえるtcpdumpを設定しても、半日取高ありませんでした。下記のように設定を変更して再度様子を見ます。65536パケットが生成されていない?!またもやキャプチャ障害か!エラーはなく以下のInfoがあるだけです。65536とpcapファイルにデータが書かれました!Viewerでもデータが見えるようになっていました。そのあともソースコードを読みながら状況を確認していると以下のことが判明しました。・MolochはPcapファイルにはブロック単位でしか書き込まず、ElasticSearchのMetaDataから紐付けてペイロードを見るにはpcapファイルを参照する・したがって、ブロック単位である262143を超えた流量が流れてこないとファイル書き出しが発生せず、Viewerからもその部分のパケットペイロードが読み込めない単にパケット流量が少ないだけでした!これが直近のパケットペイロードが見えない原因でした。メモリから参照してくれていると勝手に認識してしまっていました。Molochはその瞬間のパケット流量をリアルタイムで確認できないため、流量が少ない場合にキャプチャ状況の把握が難しくなるのが弱点です。262143を下げれば良いのですが、検証する時間がないのと逆にディスクI/Oが増えることでの負荷を懸念して、いじらずに当日を迎えました。当日発生したタイムスリップ問題6/23当日、気合をいれて二人で色違いの「かりゆし」を着て出陣しました。緊急値下げをして2チームからご購入!プレ活動と称して、プレイヤーとしてのノウハウを売り込み、やっとのことで2チームから購入していただきました。これから本番、構築・運用スタートです。リモートからチューニングして、正常性確認の手順で配布を実施予定でした。NAT設定で問題が起きます。CashFlowでは、昨年のpfsenseのようなFWソフトウェアではなく、CentOS7のfirewalldにて設定を入れねばなりませんでした。FWの設定は各チームのビジネスを止めかねないので、各チームにお願いしていましたが、NAT設定がなかなか入らずサポートできない状況が続きました。tablesの設定を教えたりもしたのですが、なぜか設定が反映されませんでした。そこで急ぎfirewalldでの設定コマンドを調べて伝えたところ、なんとかリモートアクセスできました。サービスを購入してくれた2チームのうちの一つ、チーム10にはここまで3時間もかかってしまい、申し訳なく思っています。後ほど検証して分かったことは、CentOS7ではfirewalldとiptablesでNAT設定を入れられるのですが、firewalldデーモンがiptablesコマンドで実行した設定を上書きして元に戻してしまうようで、一度firewalldを停止させてiptablesの設定を入れてから起動する必要があったようです。firewalldを停止するとビジネスが止まるため、firewalldプロセスがアクティブ状態でも設定が反映できるfirewalldコマンドでpriorityパラメータを足してNAT設定を入れることが求められました。うまくいったNAT設定はこちらです。192.168.0.126ところが、リモートアクセスしてみたら2チームともおかしな事象が起こっています!!Metadata/pcapの保存時刻が約半日後の「未来」を指している!パケットキャプチャはできていたのですが、キャプチャ時刻が未来にずれており、検索ができません。時刻を未来にずらしていくとログが発見できる状態でした。OSの時間を疑ったのですが、timedatectlの結果も正しく、NTPも正常に動いていました。調査しているとはじめに作成されたpcapの作成時刻がなぜか翌日の6月24日になっています。等のログファイルには正しい時間で書き出されていました。moloch-170623-00000594.pcapとpcapファイルへの書き込みは正しい時間で書き込まれるようになっていました。未来時間となっていたため、検索ができなくなったという仮説が生まれました。そこで、使えなくなったDBやpcapを消去したり、サービスを再起動したり、パラメーターをチューニングしたりとあの手この手を使いましたが、結局時刻ずれは最後まで治りませんでした。OSSを使うのと使いこなすには大きな隔たりがあり、OSSの厳しさを身を持って体感した1日でした。ずれたタイムゾーンで記録されている現象が確認できました。07:43:49(UTC)で記録されるべき時刻が16:43:49(ローカルタイム)で記録され、Molochはさらに+9時間後の25:43:49と解釈してしまうのです。時刻が未来を指し示してしまった原因を推定しました。・当該環境ではRTCはJSTのタイムゾーンで定義された時刻情報が設定されていた・CentOSが起動した直後は、タイムゾーンが設定されていない状態で起動する。その後、ntpで時刻同期が出来た時点で正しいタイムゾーンになるが、Cron設定したMolochCaptureがすでに異なるタイムゾーンで起動して、pcapファイルやメタデータの処理を未来時刻で開始してしまった。MolochCaptureを起動させるべきであったこれが今回のトラブルの本当の原因であるかは競技環境へアクセスできない我々には確認するすべがありません。秋のハードニングではきっと無事Molochを提供できると信じています。最後に今回初のマーケットプレイスで参加させていただき、1ヶ月半という短期間で通常では得られない経験とプレッシャーを得ることができました。Hardeningで出品すると決まってからは急ピッチで理解が進みました。Project運営の皆様、競技中に購入していただいた2チームの皆様に深く感謝を申し上げます。裕司なんでもこなすオールラウンダー、専門領域を追い求め中。リクルートユーザーへ安心を届けることがお仕事。サービス提供って難しい。ARCHIVES2020年2月2020年1月2019年12月2019年11月2019年10月2019年8月2019年7月2019年6月2019年5月2019年4月2019年3月2019年2月2019年1月2018年12月2018年11月2018年10月2018年9月2018年8月2018年7月2018年6月2018年5月2018年4月2018年3月2018年2月2018年1月2017年12月2017年11月2017年10月2017年9月2017年8月2017年7月2017年6月2017年5月2017年4月2017年3月2017年2月2017年1月2016年12月2016年11月2016年10月2016年9月2016年8月2016年7月2016年6月2016年5月2016年4月2016年3月2016年2月2016年1月2015年12月2015年11月2015年10月2015年9月2015年8月2015年7月SHAREリクルートグループサイトへ利用規約プライバシーポリシーお問い合わせ。