使用redis来调用iptables,封禁恶意IP
话不多说,通常大多数站点都会有被薅羊毛的情况,防护无非也就是业务层做处理,短时内不再响应恶意请求啦.虽然不响应了,可还是会消耗资源的,比如我要从数据库(当然也可能是内存数据库)去查询下,你是不是恶意的IP. 那么能否网络层或应用层去处理呢?在前几篇文章有写过应用层方案,今天就写下网络层方法.
说起iptables 除非是专业人员,像普通开发者是不会使用的,一堆表一堆链的一看就头疼.所以**RedisPushIptables**就应时而生,开发者不须为iptables复杂语法头疼,只需要像使用redis那样简单,就可使用iptables来阻挡恶意IP地址.
RedisPushIptables是一个redis模块,用于更新防火墙规则,以在指定的时间内拒绝IP地址或永久拒绝。比fail2ban更好用点,不到400行代码实现.适用任意业务,API调用,不需要分析应用日志,业务主动调用,缺点是要手动编码.不适用普通使用者.
该模块可以通过 redis 来操作 iptables 的 filter表INPUT链规则的增加和删除,可以用来动态调用防火墙。比如用来防御攻击。
但是前提要以 root 来运行,因为 iptables 需要 root 权限。
#1: Compile hiredis cd redis-4.0**version**/deps/hiredis make make install #2: git clone https://github.com/limithit/RedisPushIptables.git cd RedisPushIptables make 加载模块 MODULE LOAD /path/to/iptablespush.so 语法 accept.insert - Filter table INPUT ADD ACCEPT accept.delete - Filter table INPUT DEL ACCEPT drop.insert - Filter table INPUT ADD DROP drop.delete - Filter table INPUT DEL DROP ttl.drop.insert - Dynamic delete filter table INPUT ADD DROP 127.0.0.1:6379>accept.insert 192.168.188.8 (integer) 13 127.0.0.1:6379>accept.delete 192.168.188.8 (integer) 13 127.0.0.1:6379>drop.delete 192.168.188.8 (integer) 13 127.0.0.1:6379>drop.insert 192.168.188.8 (integer) 13 127.0.0.1:6379>ttl.drop.insert 192.168.188.8 60 (integer) 13 root@debian:~# iptables -L -n Chain INPUT (policy ACCEPT) target prot opt source destination DROP all -- 192.168.188.8 0.0.0.0/0 ACCEPT all -- 192.168.188.8 0.0.0.0/0
iptables 动态删除配置
默认情况下,禁用键空间事件通知,虽然不太明智,但该功能会使用一些CPU。使用redis.conf的notify-keyspace-events或CONFIG SET启用通知。将参数设置为空字符串会禁用通知。为了启用该功能,使用了一个非空字符串,由多个字符组成,其中每个字符都具有特殊含义,如下表所示:
K Keyspace事件,使用keyspace @前缀发布。E Keyevent事件,使用keyevent @前缀发布。g通用命令(非类型特定),如DEL,EXPIRE,RENAME,... $ String命令l列表命令设置命令h哈希命令z排序的设置命令x过期事件(每次键到期时生成的事件)e被驱逐的事件(为maxmemory驱逐密钥时生成的事件)g$lshzxe的别名,“AKE”字符串表示所有事件。
字符串中至少应存在K或E,否则无论字符串的其余部分如何都不会传递任何事件。例如,只为列表启用键空间事件,配置参数必须设置为Kl,依此类推。字符串KEA可用于启用每个可能的事件。
# redis-cli config set notify-keyspace-events Ex 也可以使用以下redis.conf配置指令加载模块: notify-keyspace-events Ex #notify-keyspace-events "" #注释掉这行 使用root用户运行ttl_iptables守护程序 root@debian:~/RedisPushIptables# ./ttl_iptables 日志在/var/log/ttl_iptables.log中查看 root@debian:~# redis-cli TTL.DROP.INSERT 192.168.18.5 60 (integer) 12 root@debian:~# date Fri Mar 15 09:38:49 CST 2019 root@debian:~# iptables -L -n Chain INPUT (policy ACCEPT) target prot opt source destination DROP all -- 192.168.18.5 0.0.0.0/0 root@debian:~/RedisPushIptables# tail -f /var/log/ttl_iptables.log pid=5670 03/15-09:39:48 iptables -D INPUT -s 192.168.18.5 -j DROP root@debian:~# iptables -L INPUT -n Chain INPUT (policy ACCEPT) target prot opt source destination
从此普通开发也能像运维那样,使用防火墙了.其实我不擅长写作,大伙凑合看吧,就这么多。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
基于代理的数据库分库分表框架 Mycat实践
文章共 1796字,阅读大约需要 4分钟 ! 概 述 在如今海量数据充斥的互联网环境下,分库分表的意义我想在此处就不用赘述了。而分库分表目前流行的方案最起码有两种: 方案一:基于应用层的分片,即应用层代码直接完成分片逻辑 方案二:基于代理层的分片,即在应用代码和底层数据库中间添加一层代理层,而分片的路由规则则由代理层来进行处理 而本文即将要实验的 MyCAT框架就属于第二种方案的代表作品。 注: 本文首发于 My Personal Blog:CodeSheep·程序羊,欢迎光临 小站 环境规划 在本文中,我拿出了三台 Linux主机投入试验,各节点的角色分配如下表所示: 节点 部署组件 角色 192.168.199.75 MySQL 、 MyCAT master 192.168.199.74 MySQL slave 192.168.199.76 MySQL standby master 如果说上面这张表不足以说明实验模型,那接下来再给一张图好了,如下所示: 我想这样看来的话,各个节点布了哪些组件,节点间的角色关系应该一目了然了吧 实验环境规划好了以后,接下来进行具体的部署与实验过程,首...
- 下一篇
flink内部计算指标的95线-99线等的实现
15年在某电商从0设计了一个通用的API监控系统,当时只是计算了成功率+平均耗时,没有算75,90,95,99,999,9999线,这次单位需要,所以促使我去思考这个问题,问了单位CAT维护人员,大致了解了计算方式,跟我在18年7月份在单位内网BBS发表的文章思路是一致的,所以就直接写了下面的代码 PercentageCalculation.java package com.ymm.computation.udf.define; import org.apache.flink.table.functions.AggregateFunction; import org.slf4j.Logger; import org.slf4j.LoggerFactory; //批量计算95line类似的数据 public class PercentageCalculation extends AggregateFunction<Object, PercentageAccumulator> { /** */ private static final long ser...
相关文章
文章评论
共有0条评论来说两句吧...