私はSambaファイル共有をvsftpd（TLS経由）に置き換えるための概念証明作業を進めています。これはパブリックファイルストアではないため、セキュリティが重要です。クライアントは、サーバーが受信して処理できるように、この場所にのみ記録します。
しかし、JMeterを使用してFTP部分のロードテストを開始したとき、いくつかの問題に直面しました。負荷テストのシナリオは、各ユーザーがローカルアカウントに接続してログインし、小さなファイルをアップロードした後にログアウトして1秒間待つことです。
最大300人程度のユーザーにうまく機能します。その後、問題が現れ始めました。unix_chkpwds-waveは数秒ごとに膨大なCPUスパイクを起こし始め、約1分後に持続的な負荷になりました。 16の論理コアシステムでは、負荷平均は60から80の間で表されます。シャドウファイルを解読して読み込むことは、それほど大きな負担にならないようです。
現在/etc/pam.d/vsftpdの構成は次のとおりです。
auth required pam_succeed_if.so user = citsl_ftp
auth required pam_unix.so
account sufficient pam_permit.so
匿名ログインを有効にしたり、認証にモジュールを無効にしたりすると、/etc/pam.d/vsftpd問題pam_unix.soを「修正」することができます。プロセス数が制限を超えていないことを確認しましたが、ps -A --no-header | wc -l約400〜800のプロセスのみが表示されます。しかし、私はまた、プロセスのPIDが非常に急速に上昇し、約10秒ごとに繰り返されていることに気づきました（少し心配なようですが、これが実際の問題であることがわかるほど、Linuxについて十分にはわかりません）。
これまで多くのことを学んだので、私が愚かであれば、FTPは個人的な書き込み専用ファイルの保存に間違ったツールだと言ってください。しかしunix_chkpwd、この場合には期待した動作が合うのでしょうか、それとも私が何かを逃しているのでしょうか？パスワードで保護されたローカルユーザーを使用するのは間違った方法ですか？非常に制限された匿名ログインを使用すると、自分がどれほど脆弱になる可能性がありますか？
編集：TooTeaが疑ったように、犯人はパスワードのハッシュアルゴリズムです。 SHA-512の使用からmd5に変更すると、平均CPU使用量が約9に減少しました。サーバーへの負荷が低いことを考慮すると、まだわずかに高くなりますが、オプションが提供されます。
答え1
これは、パスワードのハッシュ費用によるものかもしれません。/etc/shadowこの暗号化されていないファイルには、適切なパスワードハッシュ関数から派生したパスワードハッシュが含まれています。最新のシステムは、パスワード推測攻撃を防ぐために意図的に計算コストがかかる高度なハッシュ関数を使用しています。
/etc/shadow2番目のフィールドの最初の数文字を見て確認してください。$6$または、$y$ドル記号などの接頭辞があるかもしれません。これはハッシュ関数を決定します。man 5 cryptプレフィックスの意味を見てください。
影響を受けたアカウントが高価なハッシュ関数を使用している場合は、必要なスループットを達成するために、より安価なハッシュ関数に切り替える（または最新の調整可能関数を使用している場合はハッシュパラメータを調整する）ことを検討してください。次に、無差別代入攻撃に問題がないように、アカウントが非常に長く、ランダムなパスワードを使用していることを確認してください。
または、パスワードを使用する代わりに、FTP用のクライアント証明書TLS認証の展開を検討することもできます（特に転送中のデータを保護するためにすでにTLSを使用している場合）。