前言本文分享了自动化采集、分析Nginx日志并实时封禁风险IP的方案及实践. 阅读这篇文章你能收获到: - 日志采集方案.
- 风险IP评估的简单方案.
- IP封禁策略及方案.
阅读本文你需要: - 熟悉编程.
- 熟悉常用Linux命令.
- 了解Docker.
背景 分析nginx访问日志时, 看到大量404的无效请求, URL都是随机的一些敏感词. 而且近期这些请求越来越频繁, 手动批量封禁了一些IP后, 很快就有新的IP进来. 因此萌生了通过自动化分析Nginx日志实时封禁IP的想法. 需求 分析从日志中简单总结几个特征: 备注: 这里分析IP是通过ip2location的免费版数据库, 后面会有详细的描述. 方案 日志采集 来源: 笔者的网站通过docker部署, Nginx作为唯一入口, 记录了全部访问日志. 采集: 由于资源有限, 笔者选择了一款轻量的日志采集工具Filebeat, 收集Nginx日志并写入Redis. 风险评估 Monitor服务根据URL、IP、历史评分等进行风险评估, 计算出最终的危险系数. IP封禁 Monitor发现危险IP后(危险系数超过阈值), 调用Actuator进行IP封禁, 封禁时长根据危险系数计算得出. 实施日志采集 Filebeat的用法很简单, 笔者通过swarm进行部署, 其部署文件如下(为防止代码过长, 此处略去了其他服务): version: '3.5' services: filebeat: image: docker.elastic.co/beats/filebeat:7.4.2 deploy: resources: limits: memory: 64M restart_policy: condition: on-failure volumes: - $PWD/filebeat/filebeat.yml:/usr/share/filebeat/filebeat.yml:ro - $PWD/filebeat/data:/usr/share/filebeat/data:rw - $PWD/nginx/logs:/logs/nginx:ro environment: TZ: Asia/Shanghai depends_on: - nginx - image: 指定镜像和版本.
- deploy.resources.limits.memory: 限制内存.
- $PWD/filebeat/filebeat.yml:/usr/share/filebeat/filebeat.yml:ro: filebeat.yml是配置文件, 其中描述了日志来源和去处. $PWD为当前目录, 即执行docker stack deploy的目录. ro为只读权限.
- $PWD/filebeat/data:/usr/share/filebeat/data:rw: 需要持久化data目录, 这样删除docker重新部署也会记录上一次读取日志的位置.rw为读写权限.
- $PWD/nginx/logs:/logs/nginx:ro: 将Nginx日志目录映射到Filebeat.
- environment.TZ: 时区
filebeat.yml文件内容如下: filebeat.inputs: - type: log enabled: true paths: - /logs/nginx/access.log json.keys_under_root: true json.overwrite_keys: true
output.redis: hosts: ["redis-server"] password: "{your redis password}" key: "filebeat:nginx:accesslog" db: 0 timeout: 5 - filebeat.inputs: 定义输入
- paths: 日志路径
- json.keys_under_root: 将日志内容放到json的根节点(如果没有设置, 整条数据会被放到一个二级节点下). 注: 笔者将nginx日志配置为json格式. 参考配置如下:
log_format main_json escape=json
'{'
'"@timestamp":"$time_iso8601",'
'"http_host":"$http_host",'
'"remote_addr":"$remote_addr",'
'"request_uri":"$request_uri",'
'"request_method":"$request_method",'
'"server_protocol":"$server_protocol",'
'"status":$status,'
'"request_time":"$request_time",'
'"body_bytes_sent":$body_bytes_sent,'
'"http_referer":"$http_referer",'
'"http_user_agent":"$http_user_agent",'
'"http_x_forwarded_for":"$http_x_forwarded_for"'
'}'; - json.overwrite_keys: 覆盖Filebeat生成的KEY, 此处为了覆盖@timestamp字段.
- output.redis: 定义输出.
部署成功后查看redis数据: 风险评估 Monitor服务使用Java编写, 使用docker部署, 与Actuator服务通过http交互. 风险评估需要综合多个维度: 获取IP归属地 IP归属地获取比较容易, 有不少数据服务网站提供了免费套餐, 如IpInfo等. 也有免费版IP数据库可以下载如ip2location等. 笔者使用了ip2location的免费版数据库: ip_from和ip_to是IP段起止, 存储的格式是十进制, MySQL中可通过inet_aton('your ip')函数将IP转为十进制. 如: set @a:= inet_aton('172.217.6.78'); SELECT * FROM ip2location_db11 WHERE ip_from <= @a AND ip_to >= @a LIMIT 1;获取AS、ASN及用途 多数网站提供的免费服务中都无法查询ASN或没有其用途. ASN数据也有免费的数据库, 但是依旧没有其用途及类型等. 此时笔者通过其它的方法曲线救国. ip2location提供了免费版本的IP2LocationLITE IP-ASN和IP2ProxyLITE数据库. IP2LocationLITE IP-ASN: 数据库提供了确定自治系统和编号(ASN)的参考. IP2ProxyLITE: 数据库包含被用作开放代理的IP地址. 该数据库包括所有公共IPv4和IPv6地址的代理类型、国家、地区、城市、ISP、域、使用类型、ASN和最新记录. IP2LocationLITE IP-ASN中无法查询到IP的使用类型, IP2ProxyLITE数据较少中不一定会包含指定的IP. 但可以结合这两个库, 大致猜测IP的用途: - 首先, 在IP2ProxyLITE中查询出IP的ASN
- 结合ASN和IP, 查询相同ASN最接近指定IP的前后两条记录
- 计算查询到的proxy记录中IP与当前IP的差值的绝对值;如果绝对值很接近, 那么就认为此IP的用途和proxy IP相同. 很接近的定义可以根据情况调整, 如绝对值在65535范围内.
综合评分 综合评分的规则可根据实际场景进行调整 综合上述1-5项, 进行计算, 可以简单的相加, 也可加权计算. IP封禁 笔者采用**iptables+ipset**的方式进行IP封禁. Actuator服务使用node编写, 运行在主机上, docker中的Monitor通过http与其交互. 封禁IP部分代码如下: 'use strict';
const express = require('express'); const shell = require('shelljs'); const router = express.Router();
router.post('/blacklist/:name/:ip', function (req, res, next) { let name = req.params.name; let ip = req.params.ip; let timeout = req.query.timeout; let cmd = `ipset -exist add ${name} ${ip} timeout ${timeout}`; console.log(cmd); shell.exec(cmd); res.send('okn'); });
module.exports = router; - name: 黑名单名称.
- timeout: 超时时间, 单位: 秒.
目前, 还是有不少"头铁"的IP频繁扫描笔者的网站, 在发现后几秒内自动屏蔽掉, 目前效果比较理想. 结语- 爬虫、机器人、漏洞扫描等给网站造成了不必要的开销甚至带来风险, 不可忽视. 绝对安全很难做到, 但要尽量做到比别人安全.
- 封禁是相对暴力的手段, 一定要把握好尺度, 出现误杀会导致网站流失用户.
- 除了封禁外, 也可考虑"祸水东引", 将风险IP 302重定向到gitpage(备份站点), 这样就算误杀, 也不会造成用户无法访问的情况.
- 道路千万条, 安全第一条
纯属娱乐,点个关注吧! |