Redis / キャッシュ - Redis / キャッシュセキュリティ
Redis / Memcached 等のインメモリキャッシュのセキュリティ。デフォルトで認証なし・全公開になりがちな危険性、AUTH 設定、TLS 対応、Sentinel / Cluster 構成での考慮点を解説。
概念図
攻撃シナリオ
認証なし Redis 経由のサーバー乗っ取り
bash
# 攻撃者が認証なしの Redis に接続し、SSH 公開鍵を書き込む
redis-cli -h <target>
> CONFIG SET dir /root/.ssh/
> CONFIG SET dbfilename "authorized_keys"
> SET payload "\n\nssh-rsa AAAA...attacker-key\n\n"
> SAVE
# → サーバーに SSH ログイン可能にMemcached を悪用した DDoS 増幅攻撃
bash
# Memcached リフレクション DDoS
# 攻撃者が送信元 IP を偽装し、Memcached に小さなリクエストを送信
# → 被害者に数万倍のレスポンスが返る（増幅率 51,000 倍）
# 2018 年の GitHub への 1.35 Tbps 攻撃に使用された手法
# 対策: Memcached を外部公開しない
# memcached -l 127.0.0.1 -U 0 # UDP 無効化デフォルト設定の危険性
Redis や Memcached はデフォルトで認証なし・外部公開の状態になりやすく、インターネット上で数万台の無防備なインスタンスが発見されています。
- Redis: バージョン 3.2 以前は
bind 0.0.0.0がデフォルトで、認証なしで外部からアクセス可能だった。3.2 以降はprotected-modeが追加されたが、明示的にバインドアドレスを設定しないと警告のみで起動する - Memcached: デフォルトで TCP/UDP 11211 ポートが全インターフェースにバインドされる。認証機構を持たないため、ネットワークレベルでの隔離が唯一の防御策
- 共通の問題: クラウド環境でセキュリティグループの設定を誤り、キャッシュサーバーのポートがインターネットに公開されるケースが頻発
Redis の認証と暗号化
Redis 6.0 以降では ACL（Access Control List）が導入され、より細かなアクセス制御が可能になりました。
- AUTH / requirepass: 基本的なパスワード認証。全クライアントが同じパスワードを使う単純な仕組みだが、設定しないよりはるかに安全
- ACL（Redis 6.0+）: ユーザーごとに異なるパスワードと、実行可能なコマンド・アクセス可能なキーパターンを制御できる
- TLS（Redis 6.0+）: クライアントとサーバー間の通信を暗号化。
tls-port,tls-cert-file,tls-key-fileで設定 - 危険なコマンドの無効化:
FLUSHALL,FLUSHDB,CONFIG,DEBUG,KEYS等の危険なコマンドをrename-commandで無効化またはリネームする
Sentinel / Cluster 構成のセキュリティ
高可用性構成では追加のセキュリティ考慮が必要です。
- Sentinel: Sentinel 自体にも
requirepassを設定する。Sentinel が管理する Redis インスタンスのパスワードが Sentinel の設定ファイルに平文で保存されるため、ファイルのパーミッションを厳格に管理する - Cluster: ノード間通信に使われる Cluster Bus ポート（通常 16379）もファイアウォールで保護する。Redis 6.0 以降ではノード間 TLS も設定可能
- レプリケーション: レプリカへのデータ同期は平文で行われるため、TLS を有効化するか、VPN / プライベートネットワーク内に閉じる
- 設定の一貫性: 全ノードで ACL・TLS・パスワード設定を統一する。一部ノードだけ設定が甘いと、そこが攻撃の入口になる