Closed Tomo-9925 closed 3 years ago
ありがとうございます まだコードは深く読めていないのですが
すみません、次々と問題が見つかってしまって、こうなってしまいました…以後気をつけます🙇🏻♂️
現在行った感じだと,うまく弾いてくれるのですが,ログを見るとプロセスの特定に失敗するという問題が発生しています.何らかのバグを見つけた場合報告していただけると幸いです.
改めてログを見てみると,同じような通信がちゃんとできているものがあるので,キューから取り出される前にソケットが閉じられたり,プロセスが終了したり可能性があるので,正規の動作かなと思いました.ちゃんと検証もしたほうが良いのかな…?
pingだけですがパフォーマンス測定の結果をおいておきます
以前(キャッシュなし)
/ # ping -c {serverIP}
PING {serverIP} ({serverIP}): 56 data bytes
64 bytes from {serverIP}: seq=0 ttl=63 time=10.305 ms
64 bytes from {serverIP}: seq=1 ttl=63 time=11.974 ms
64 bytes from {serverIP}: seq=2 ttl=63 time=8.103 ms
64 bytes from {serverIP}: seq=3 ttl=63 time=7.117 ms
64 bytes from {serverIP}: seq=4 ttl=63 time=7.607 ms
64 bytes from {serverIP}: seq=5 ttl=63 time=6.809 ms
64 bytes from {serverIP}: seq=6 ttl=63 time=10.730 ms
64 bytes from {serverIP}: seq=7 ttl=63 time=6.832 ms
64 bytes from {serverIP}: seq=8 ttl=63 time=7.434 ms
64 bytes from {serverIP}: seq=9 ttl=63 time=7.179 ms
--- {serverIP} ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 6.809/8.409/11.974 ms
このPR(procキャッシュ)
3 packets transmitted, 0 packets received, 100% packet loss
/ # ping -c 10 {serverIP}
PING {serverIP} ({serverIP}): 56 data bytes
64 bytes from {serverIP}: seq=0 ttl=63 time=14.995 ms
64 bytes from {serverIP}: seq=1 ttl=63 time=8.642 ms
64 bytes from {serverIP}: seq=2 ttl=63 time=4.685 ms
64 bytes from {serverIP}: seq=3 ttl=63 time=3.793 ms
64 bytes from {serverIP}: seq=4 ttl=63 time=3.599 ms
64 bytes from {serverIP}: seq=5 ttl=63 time=3.850 ms
64 bytes from {serverIP}: seq=6 ttl=63 time=4.347 ms
64 bytes from {serverIP}: seq=7 ttl=63 time=5.159 ms
64 bytes from {serverIP}: seq=8 ttl=63 time=3.219 ms
64 bytes from {serverIP}: seq=9 ttl=63 time=3.023 ms
--- {serverIP} ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 3.023/5.531/14.995 ms
ソケットが閉じられていたのであれば,処理速度を上げる.無駄がないかを再度確認すべき.
正確にプロセスが特定できないのではと思っていたが,それよりも処理時間が原因で特定ができなくなる方が問題.
ひとまず,ここのコードの問題を修正,マージ次第,別のブランチでTO-DOの変更を行います.
ありがとうございます
僕も処理速度について確認しようと思ってたんですがそもそも使ってるnfqueueが重い説もあるのかなーと思ってるのでnfqueueに渡してすぐに透過させた場合どれくらいの速度低下があるのか測ってみたいですね…(近いうちにします)
wp-cronは通信が来るたびにスケジュールされたジョブを確認して実行するかどうかを判断します.このcronを使用した手法はパフォーマンスが下がる問題や,ジョブが正確に行われないという問題を解決します.
ここのところがあまり理解できていないです..どう言う意味ですか?
わざわざコンテナでcontabをインストールしてwp-cronをphpで実行させる意味ですよね…?あまりうまく説明できなかったと自分でも思っています… 次のページがわかりやすいと思うので参考にしてみてください.
wp-cronの起動をcronに任せてWordPressを高速化させる。 | ハックノート
キューから取り出される前にソケットが閉じられたり,プロセスが終了したり可能性があるので,正規の動作かなと思いました
キューというのはiptablesから渡してるNFQUEUEのことですよね?取り出される前にソケット・プロセスが終了するというのはこのシステムの処理が遅くて間に合ってないと言う意味にはならないですか?
システムの高速化,がんばります…
あーーなるほど!!
このcronを使用した手法はパフォーマンスが下がる問題や,ジョブが正確に行われないという問題を解決します.
これをcnetのパフォーマンス下がる問題の解決だと勘違いしてました!なるほどです!
システムの高速化,がんばります…
遅いと入ってもmsレベルの話なのでかなり厳しいチューニングにはなりそうですよね…微力ながらお手伝いさせていただけたらと思います🙇♂️
ソケットキャッシュも含め一通りできる修正は行いました(並列処理はちゃんと分けます).再度確認していただけると幸いです. (関数名が長いのはどうしようもないです…)
最小限のシステムで実験してみたんですが最初から倍遅くなってるので結構パフォーマンス厳しいですね〜〜〜 https://github.com/masibw/only-netfilter-queue 何もシステムなし
/ # ping -c 10 {serverIP}
PING {serverIP} ({serverIP}): 56 data bytes
64 bytes from {serverIP}: seq=0 ttl=63 time=0.309 ms
64 bytes from {serverIP}: seq=1 ttl=63 time=0.294 ms
64 bytes from {serverIP}: seq=2 ttl=63 time=0.422 ms
64 bytes from {serverIP}: seq=3 ttl=63 time=0.471 ms
64 bytes from {serverIP}: seq=4 ttl=63 time=0.407 ms
64 bytes from {serverIP}: seq=5 ttl=63 time=0.560 ms
64 bytes from {serverIP}: seq=6 ttl=63 time=0.398 ms
64 bytes from {serverIP}: seq=7 ttl=63 time=0.434 ms
64 bytes from {serverIP}: seq=8 ttl=63 time=0.596 ms
64 bytes from {serverIP}: seq=9 ttl=63 time=0.480 ms
--- {serverIP} ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 0.294/0.437/0.596 ms
最小限のシステムあり
/ # ping -c 10 {serverIP}
PING {serverIP} ({serverIP}): 56 data bytes
64 bytes from {serverIP}: seq=0 ttl=63 time=1.084 ms
64 bytes from {serverIP}: seq=1 ttl=63 time=1.122 ms
64 bytes from {serverIP}: seq=2 ttl=63 time=0.750 ms
64 bytes from {serverIP}: seq=3 ttl=63 time=0.873 ms
64 bytes from {serverIP}: seq=4 ttl=63 time=0.922 ms
64 bytes from {serverIP}: seq=5 ttl=63 time=0.857 ms
64 bytes from {serverIP}: seq=6 ttl=63 time=0.772 ms
64 bytes from {serverIP}: seq=7 ttl=63 time=0.812 ms
64 bytes from {serverIP}: seq=8 ttl=63 time=0.964 ms
64 bytes from {serverIP}: seq=9 ttl=63 time=0.736 ms
--- {serverIP} ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 0.736/0.889/1.122 ms
コードの改善としては,応答速度が激遅だったためキャッシュの機能をつけたり,AF_INET6のソケットを使われた場合にIPv4の検知が行えなかったためIPv6へのサポートをしたりしていました.あと,ログの出力の方,マージし忘れていたため,サクッと場所を入れ替えて対応しています.すみません.
検証内容としてWordpressコンテナでwp-cron.phpをcronで実行することを想定して,複数コンテナ(mariadb, wordpress)複数プロセス(apache2, mariadb, php)の通信制御を行います(wp-cronは通信が来るたびにスケジュールされたジョブを確認して実行するかどうかを判断します.このcronを使用した手法はパフォーマンスが下がる問題や,ジョブが正確に行われないという問題を解決します.). 発生しうる通信は,exampleのwordpressの通りです(漏れがあれば教えて下さい).
検証では,容易な認証情報の流出により,metasploitの
exploits/unix/webapp/wp_admin_shell_upload
を使用してシェルにアクセスされることを想定します(アイデアが無い…).現在行った感じだと,うまく弾いてくれるのですが,ログを見るとプロセスの特定に失敗するという問題が発生しています.何らかのバグを見つけた場合報告していただけると幸いです.