Q&A
redisはどのようにインストールして、どのように起動していますでしょうか？
前提・実現したいこと
複数のウェブサーバ（CentOS7, nginx使用）で負荷分散およびセッション同期を
実現したいと考えています。
発生している問題・エラーメッセージ
redisを使用してセッション同期をしていますが、頻繁に同期が取れなくなります。
/var/log/redis/redis.logには以下のようなエラーが表示されます。（タイムスタンプ等省略）
10 changes in 300 seconds. Saving...
Background saving started by pid xxxxx
Failed opening the RDB file root (in server root dir /etc/cron.d) for saving: Permission denied
Background saving error
このログの例では
dir:/var/lib/redis→/etc/cron.d
dbfilename:dump.rdb→root
に書き換えられています。書き換えられる値は上記に限りませんが
dirがroot権限のディレクトリに書き換えられてしまうとredis ID
がRDBファイルを書き込めなくなりこのエラーになっているようです。
該当のソースコード
ソースコード
試したこと
現状ではredis-cliコマンドを使用してdirおよびdbfilenameの
値が/var/lib/redisおよびdump.rdb以外に書き換えられていたら
デフォルトに戻すツールを作成し、crontabで5分毎に実行する
ということで、エラーを抑止しています。
なぜこのような状況が発生し、どうすれば解決できるのか
ご教授いただけないかと考えます。
よろしくお願いいたします。
補足情報（FW/ツールのバージョンなど）
redis.confの修正について（マスター、スレーブ×1）
bind 127.0.0.1→#bind 127.0.0.1
protected-mode yes→protected-mode no
timeout 0→timeout 60
tcp-keepalive 300→tcp-keepalived 0
stop-writes-on-bgsave-error yes→stop-writes-on-bgsave-error no
↑変更した記憶がないのでredisが自分で変更したのではないかと（かつ2台中マスター側のみ）
slave-read-only yes→slave-read-only no
slaveof （スレーブ側のみ）
redis-sentinel.confの設定について（redisとは別サーバ×1）
protected-mode no
daemonize no
sentinel monitor redis_www_session （マスターIP） 6379 1
sentinel down-after-milliseconds redis_www_session 3000
Generated by CONFIG REWRITE
sentinel failover-timeout redis_www_session 90000
sentinel known-slave redis_www_session （スレーブIP） 6379
redisはyumでインストールしており、redis-3.2.10-2.el7.x86_64になります。systemctl enable redisでサーバ起動時に起動しています。
どのように起動と言われるのがdaemonizeのことだとしたらdaemonize noで起動しています。
redis-serverを引数無しで起動すると、redis.confが読み込まれず、dump.rdsの保存先がカレントディレクトリになりますが、そういう処理が何処かで行われていませんか？
redis-server起動時の引数の有無は分かりませんが、ps -ef | grep redisの結果が/usr/bin/redis-server *:6379となっているので、引数有ではないかと思います。
/usr/lib/systemd/system/redis.serviceを参照したところExecStart=/usr/bin/redis-server /etc/redis.conf --daemonize noとありましたのでredis.confは読み込まれていると考えます。
回答2件
0
ベストアンサー
redis はネットに公開された場所で稼働されてますか？
（ウェブサーバと同じサーバとか）
補足に bind 127.0.0.1→#bind 127.0.0.1 とあるので、気になりました。
bind は redis に接続できるサーバのIP（ローカルIP）を指定するものです。
コメントアウトしてしまうと全解放となるので、もしネット公開されていれば
どこのサーバからでも接続でき、データ取得・更新、停止・再起動までできてしまいます。
危険です。
https://github.com/kurosawatsuyoshi/doshelper/wiki/1.-redis-Setup%EF%BC%88redis%E3%81%AE%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%EF%BC%89
の Appendix に記載した crackit/crack@redis.io をみてもらえばわかると思います。
redis-cli で config get bind と打ったらどうなりますか？
もし閉じた環境であったり、 iptables で制御していれば大丈夫です。
ただ、、、 dir とか dnfilename は勝手に変わらないので誰かが外から変更しているように見えますね。
投稿2018/03/14 12:28
総合スコア780
回答ありがとうございました。
たまたま昨日redisのポートがローカルIPだけでなくグローバルIPにも
開放されていることに気づいて、ローカルIP専用のゾーンを作成し
ゾーン内のみ開放するよう設定変更したところでした。
kurosawa様の回答でこの設定変更で正しいという確証が得られました。
あらためてありがとうございました。
原因がわかって良かったです。
ただ、これまで外部公開されていたということになると
イタズラや攻撃目的でサーバに侵入されていないか確認したほうが良いです
私が実際に redis を利用して攻撃されました。
（それが紹介した記事です）
redisのDirやdbfilenameを ssh 鍵の内容とパスに変更され、save コマンドでファイルを作成して shutdown されてました。
管理者の私はredisが落ちたことに気づき再起動させますが、この段階では redisは設定ファイルからDirとdbfilenameを読み込むので、変更されてファイル作成されたことに気づきません。（たまたま再起動前に気づいたので即除去しました）
今回は root というファイルを cron.d にセットする過程に見えます。
既に外部から怪しい実行ファイルが配置され、それを定期的にキックしようと試みていたが、たまたま redis を起動しているユーザが root じゃなかったため配置に失敗していただけ。という見方もできます。
念のため、以下を確認したほうが良いです
・不明なOSユーザが登録してないか
・全員のsshキーが改ざんされていないか
・Redisのキー＆バリューに変な値がないか（16個のDBすべて）
私ならパスワードの全変更とログ調査に取り掛かります
0
めちゃくちゃ助かった。ありがとう。
投稿2019/09/09 23:55
総合スコア85
あなたの回答
tips
プレビュー
