1. 项目缘起：为什么我们需要关注HTTP/1.*协议的IP？

在日常的服务器运维和网络安全工作中，我经常需要处理大量的访问日志。一个反复出现的现象引起了我的注意：在那些被标记为恶意、需要加入黑名单的IP地址中，有很大一部分其访问请求使用的仍然是HTTP/1.0或HTTP/1.1协议，而非更现代的HTTP/2或HTTP/3。这并非巧合。

HTTP/1.*协议，尤其是HTTP/1.0，设计于互联网的早期。它有几个显著特点：每个TCP连接通常只用于一次请求-响应，或者通过Keep-Alive头维持有限的生命周期；没有头部压缩，每次请求都会携带完整的、冗长的头部信息；更重要的是，它缺乏像HTTP/2那样的强制加密要求（虽然HTTPS可以用于HTTP/1.1，但并非强制），通信过程相对透明。

这些“古老”的特性，恰恰被一些自动化扫描工具、爬虫甚至攻击脚本所青睐。使用HTTP/1.*协议进行扫描，客户端实现简单，兼容性极广，从十几年前的旧设备到最新的服务器都能连通。它不像HTTP/2需要协商复杂的帧和流机制，也不像某些现代应用层协议有更严格的握手过程。一个简单的telnet命令或者最基础的curl就能发起一次完整的HTTP/1.1请求。对于攻击者而言，这意味着更低的部署成本和更广泛的攻击面。

因此，*将“使用HTTP/1.协议”作为识别潜在恶意流量的一个辅助信号，是具备实战价值的。它不能作为唯一的判定标准（因为大量正常老旧客户端、某些API接口或内部服务也可能使用HTTP/1.1），但结合请求频率、路径特征、User-Agent等信息，可以显著提高我们筛选“可疑IP”的效率和精度。本项目的核心，就是构建一个自动化流程，从海量访问日志中，精准定位那些频繁使用HTTP/1.*协议进行“试探性”访问的IP，并将其纳入监控或直接加入黑名单。

2. 核心数据源：Nginx访问日志的深度解析

我们的数据基石是Web服务器（以Nginx为例）的访问日志。一个典型的配置了combined格式的日志条目如下：

123.45.67.89 - - [15/Oct/2023:10:23:45 +0800] "GET /wp-admin HTTP/1.1" 404 162 "-" "Mozilla/5.0 (compatible; BadBot/1.0; +http://bad-bot.example.com)"

这条日志蕴含了我们需要的关键信息：

• 123.45.67.89: 客户端的IP地址。
• [15/Oct/2023:10:23:45 +0800]: 访问时间戳。
• "GET /wp-admin HTTP/1.1": 请求方法、请求路径以及至关重要的HTTP协议版本。
• 404: 服务器响应状态码。
• 162: 返回给客户端的主体大小（字节）。
• "-": 来源页（Referer）。
• "Mozilla/5.0 ...": User-Agent字符串，是识别客户端类型（浏览器、爬虫、扫描器）的黄金指标。

注意：确保你的Nginxlog_format中包含了$server_protocol变量，它记录了客户端请求使用的协议版本。标准的combined格式已包含此项。

我们的策略是，编写一个日志分析脚本，周期性（例如每分钟）解析新增的日志，筛选出所有协议为HTTP/1.0或HTTP/1.1的条目。但仅仅这样会误伤大量正常流量。因此，我们需要引入更精细的过滤规则。

2.1 定义“可疑”访问的行为特征

单纯使用HTTP/1.*协议不足为奇，我们需要结合其他特征来勾勒出一个“扫描器”或“攻击脚本”的画像：

1. 高频访问：短时间内对服务器发起大量请求。这是最直接的异常信号。
2. 探测敏感路径：请求的URL路径指向常见的后台管理入口（如/wp-admin,/admin,/phpmyadmin）、配置文件（如.env,config.php）、或漏洞测试路径（如/api/v1/test,/console）。
3. 非常规User-Agent：User-Agent为空、为明显伪造的浏览器字符串、或包含已知的扫描器/黑客工具标识（如sqlmap,nikto,Acunetix）。
4. 返回状态码模式：大量出现404（文件不存在）、403（禁止访问）、401（未授权），特别是当这些请求针对的是敏感路径时。
5. 缺乏完整的HTTP会话：只请求页面，不加载关联的CSS、JS、图片等静态资源，行为不像真实用户。

我们的脚本需要综合这些维度进行判断。一个简单的加权评分模型会很有效：例如，每条HTTP/1.*协议的请求记1分，请求敏感路径加3分，User-Agent识别为扫描器加5分。同一个IP在5分钟内的累计得分超过一个阈值（比如20分），则判定为可疑，进入下一步处理流程。

3. 实战构建：基于Go的实时日志分析与IP过滤系统

我将选择Go语言来实现这个系统，因为它编译部署简单、并发性能好、内存占用低，非常适合作为常驻后台进程处理持续的日志流。整个系统可以分为几个模块：日志监听、实时解析、规则匹配、IP评分与黑名单管理。

3.1 系统架构与核心模块

日志文件 (access.log) | v [ 日志监听模块 (Tail) ] -- 实时读取新日志行 | v [ 日志解析模块 (Parser) ] -- 提取IP、路径、协议、UA等 | v [ 规则匹配与评分引擎 ] -- 应用规则，对IP进行累加评分 | v [ IP状态管理模块 ] -- 维护IP的分数和时间窗口 | v [ 黑名单动作执行器 ] -- 分数超阈值时，执行封禁操作

3.2 关键代码实现详解

首先，我们使用github.com/hpcloud/tail库来实时追踪日志文件，就像Linux下的tail -f命令。

package main import ( "fmt" "log" "regexp" "strings" "time" "github.com/hpcloud/tail" ) // 定义一条日志记录的结构 type AccessLog struct { IP string Time time.Time Method string URL string Protocol string // 我们关注的核心字段 Status int UserAgent string } // 定义敏感路径的关键字列表 var sensitivePaths = []string{ "wp-admin", "admin", "phpmyadmin", "manager", "backup", ".env", "config", ".git", ".svn", "console", "api/test", } // 定义已知恶意User-Agent关键字 var badBotIndicators = []string{ "sqlmap", "nikto", "acunetix", "nessus", "metasploit", "dirbuster", "gobuster", "wfuzz", "badbot", "scanner", } // IP评分模型 type IPScore struct { Address string Score int LastSeen time.Time FirstSeen time.Time } var ipScoreMap = make(map[string]*IPScore) var scoreMutex sync.RWMutex func main() { // 启动日志跟踪 t, err := tail.TailFile("/var/log/nginx/access.log", tail.Config{Follow: true, ReOpen: true, Location: &tail.SeekInfo{Offset: 0, Whence: 2}}) if err != nil { log.Fatal(err) } // 处理日志行 for line := range t.Lines { logEntry := parseLogLine(line.Text) if logEntry != nil && (logEntry.Protocol == "HTTP/1.0" || logEntry.Protocol == "HTTP/1.1") { processLogEntry(logEntry) } } }

parseLogLine函数使用正则表达式解析日志行。这里使用一个简化但高效的 regex：

var logLineRegex = regexp.MustCompile(`^(\S+) \S+ \S+ \[([^\]]+)\] "(\S+) (\S+) (\S+)" (\d+) (\d+) "[^"]*" "([^"]*)"`) func parseLogLine(line string) *AccessLog { matches := logLineRegex.FindStringSubmatch(line) if matches == nil || len(matches) < 9 { return nil // 忽略无法解析的行 } timeStr := matches[2] parsedTime, err := time.Parse("02/Jan/2006:15:04:05 -0700", timeStr) // 注意Nginx时间格式 if err != nil { // 尝试其他常见格式 parsedTime, err = time.Parse("02/Jan/2006:15:04:05 MST", timeStr) if err != nil { return nil } } statusCode, _ := strconv.Atoi(matches[6]) return &AccessLog{ IP: matches[1], Time: parsedTime, Method: matches[3], URL: matches[4], Protocol: matches[5], Status: statusCode, UserAgent: matches[8], } }

核心的processLogEntry函数负责评分：

func processLogEntry(entry *AccessLog) { scoreMutex.Lock() defer scoreMutex.Unlock() ipKey := entry.IP now := time.Now() // 获取或创建该IP的评分记录 record, exists := ipScoreMap[ipKey] if !exists { record = &IPScore{Address: ipKey, FirstSeen: now, LastSeen: now} ipScoreMap[ipKey] = record } // 检查时间窗口：我们只关心最近5分钟的活动 if now.Sub(record.FirstSeen) > 5*time.Minute { // 如果第一条记录已超过5分钟，重置这个IP的记录 record.Score = 0 record.FirstSeen = now } record.LastSeen = now // 基础分：使用HTTP/1.*协议 record.Score += 1 // 加分项1：访问敏感路径 for _, path := range sensitivePaths { if strings.Contains(strings.ToLower(entry.URL), path) { record.Score += 3 break // 匹配到一个即可 } } // 加分项2：状态码为4xx（客户端错误），可能是探测 if entry.Status >= 400 && entry.Status < 500 { record.Score += 1 } // 加分项3：可疑User-Agent uaLower := strings.ToLower(entry.UserAgent) if entry.UserAgent == "-" || entry.UserAgent == "" { record.Score += 2 // 空UA } for _, indicator := range badBotIndicators { if strings.Contains(uaLower, indicator) { record.Score += 5 break } } // 检查是否达到黑名单阈值 if record.Score >= 20 { fmt.Printf("[BLOCK] IP %s triggered blacklist. Score: %d, First Seen: %s, Last Seen: %s\n", record.Address, record.Score, record.FirstSeen.Format(time.RFC3339), record.LastSeen.Format(time.RFC3339)) // 执行封禁动作 go addToBlacklist(record.Address) // 从当前监控map中移除，避免重复报警 delete(ipScoreMap, ipKey) } }

3.3 黑名单动作执行：与防火墙联动

识别出恶意IP后，需要将其真正封禁。这里提供两种最常用的方案：

方案一：调用本地防火墙命令（如iptables）适用于单机或小规模集群。

import "os/exec" func addToBlacklist(ip string) { // 检查是否已存在规则，避免重复添加 checkCmd := exec.Command("sh", "-c", fmt.Sprintf("iptables -C INPUT -s %s -j DROP 2>/dev/null", ip)) if checkCmd.Run() != nil { // 规则不存在，则添加 cmd := exec.Command("iptables", "-A", "INPUT", "-s", ip, "-j", "DROP") if err := cmd.Run(); err != nil { log.Printf("Failed to block IP %s via iptables: %v", ip, err) } else { log.Printf("Successfully blocked IP %s via iptables.", ip) // 可选：将IP持久化到文件，防止重启丢失 persistIP(ip) } } }

方案二：集成云服务商API或WAF适用于云环境。例如，阿里云、腾讯云等都提供了通过API添加安全组规则或WAF黑名单的功能。你需要使用对应的SDK。

// 伪代码示例：调用阿里云SDK添加安全组规则 import aliyun "github.com/aliyun/alibaba-cloud-sdk-go" func addToCloudBlacklist(ip string) { client, err := aliyun.NewClientWithAccessKey("region-id", "access-key-id", "access-key-secret") // 构造请求，向指定的安全组添加一条拒绝该IP的规则 // ... }

重要提示：直接操作iptables或云安全组是高风险动作。务必在添加规则前进行二次确认（例如记录日志、人工审核阈值极高的IP），或者设置一个“观察名单”阶段，分数达到15分先记录并报警，达到25分再自动封禁，防止误杀重要IP（如公司出口IP、搜索引擎蜘蛛等）。

4. 高级策略与精细化调优

基础的评分模型能解决大部分问题，但在复杂的生产环境中，我们需要更精细的策略来降低误报率。

4.1 引入IP信誉库与白名单机制

不是所有高频访问HTTP/1.*协议的IP都是坏的。我们需要建立白名单。

1. 搜索引擎蜘蛛：Google、Bing、Baidu的蜘蛛虽然可能使用HTTP/1.1，但它们是友好的。可以通过验证其User-Agent和反向DNS解析来确认。例如，验证*.googlebot.com的PTR记录。
2. 合作伙伴或内部系统：公司内部的监控系统、API网关、CDN回源节点等。这些IP段应该直接加入白名单，不受评分模型影响。
3. 已知的良性公共服务：如安全扫描平台（如Shodan的某些研究性爬虫，需具体判断）、内容聚合器（如果允许的话）。

在代码中，我们可以在processLogEntry最开始加入白名单检查：

var whitelistIPs = []string{"192.168.1.0/24", "10.0.0.1"} var whitelistNets []*net.IPNet func init() { for _, cidr := range whitelistIPs { _, ipNet, _ := net.ParseCIDR(cidr) whitelistNets = append(whitelistNets, ipNet) } } func isWhitelisted(ipStr string) bool { ip := net.ParseIP(ipStr) if ip == nil { return false } for _, net := range whitelistNets { if net.Contains(ip) { return true } } // 也可以检查精确IP return false } // 在 processLogEntry 开始处： if isWhitelisted(entry.IP) { return // 直接跳过，不处理 }

4.2 协议版本权重的动态调整

我们最初的模型给所有HTTP/1.*请求加1分。但可以更智能：

• 对于/robots.txt,/favicon.ico等常见无害的请求，即使用HTTP/1.1，也可以不加分或少加分。
• 对于登录页面 (/login) 的POST请求，即使使用HTTP/2，如果频率异常高，也应该加分。因此，可以将“协议版本”作为一个权重因子，而不是绝对条件。最终评分 = 行为分 * 协议权重。对于HTTP/2，协议权重可以设为0.5或0.2；对于HTTP/1.*，权重为1.0或1.2。

4.3 状态码模式的深入分析

一个专业的扫描器在探测时，不仅看4xx，还会看不同的响应。我们可以建立更复杂的模式：

• 大量404：可能是目录爆破、文件探测。
• 大量403：可能是尝试越权访问。
• 少量200夹杂大量404：可能是扫描器找到了一个有效入口。
• 固定间隔的401：可能是暴力破解认证。

可以为不同的状态码模式设置不同的加分值，甚至定义一些状态码序列模式来识别特定工具。

4.4 分布式部署与数据聚合

对于拥有多台前端服务器的网站，扫描器可能会轮询攻击不同的服务器IP。因此，本地的IP评分需要汇总到一个中心存储（如Redis）进行全局聚合计算。

// 使用Redis存储IP的全局分数 func updateGlobalScore(ip string, increment int) { ctx := context.Background() key := fmt.Sprintf("ip:score:%s", ip) // 使用Redis的有序集合(ZSET)，分数作为SCORE，同时可以设置过期时间 // 1. 增加分数 redisClient.ZIncrBy(ctx, "ip_scores", float64(increment), ip) // 2. 更新最近活跃时间 redisClient.HSet(ctx, "ip:info:"+ip, "last_seen", time.Now().Unix()) // 3. 设置Key的过期时间，例如1小时，自动清理不活跃的IP redisClient.Expire(ctx, "ip:info:"+ip, time.Hour) }

然后，可以有一个独立的后台进程，定期（如每10秒）检查Redis中有序集合里分数超过全局阈值的IP，执行全局封禁（如推送至云WAF或所有边缘节点的防火墙）。

5. 避坑指南与实战经验分享

在实际部署和运行这套系统的过程中，我踩过不少坑，也总结出一些让系统更稳健的经验。

5.1 误报处理：如何避免“错杀”正常用户

误报是自动化封禁系统最大的风险。除了前面提到的白名单，还有以下措施：

1. 阈值设置要谨慎：不要一开始就把阈值设得太低。可以先设一个较高的阈值（比如50分），运行一段时间，观察被捕获的IP和日志，确认都是恶意流量后，再逐步调低到一个合理的水平。
2. 设置“死缓”期：不要分数一达标就立刻永久封禁。可以先将其加入一个“临时黑名单”，封禁较短时间（如30分钟或1小时）。如果该IP之后不再有恶意行为，则自动释放。这可以应对一些被短期利用的代理IP或扫描器。
3. 人工审核通道：对于分数非常高（例如超过100分）的IP，系统可以发送更高级别的告警（如短信、钉钉/飞书群@所有人），让运维人员介入确认后再执行封禁。
4. 关注封禁反馈：如果封禁后，短时间内有大量来自同一国家或ISP的正常用户投诉无法访问，就要警惕是否误封了某个公共出口IP或移动网络网关。

5.2 性能优化：处理海量日志的挑战

当网站访问量很大时，日志文件增长极快。我们的Go程序需要高效处理。

1. 使用更高效的正则解析库：标准库的regexp在反复编译和使用时可能有效能问题。可以考虑使用github.com/dlclark/regexp2处理更复杂的模式，或者对于固定的Nginx格式，直接使用strings.Split和strings.Trim进行字符串切割，这通常比正则快得多。
2. 批量处理与异步写入：不要每解析一条日志就立即去更新Redis或检查分数。可以攒够100条或等待100毫秒，批量处理。更新外部存储（如Redis）的操作尽量使用异步或非阻塞模式，避免阻塞主日志解析循环。
3. 定期清理内存中的ipScoreMap：对于长时间（比如超过1小时）没有活动的IP记录，应该从内存map中删除，防止内存泄漏。可以启动一个goroutine，每分钟遍历一次map，清理过期的记录。
4. 日志轮转（Log Rotation）处理：使用hpcloud/tail库时，它已经内置了ReOpen选项来处理日志轮转。但要确保程序有足够的权限读取新的日志文件。

5.3 与现有监控体系的整合

这个系统不应该是一个孤岛。

1. 告警集成：当IP被加入黑名单时，除了在控制台打印，还应该发送告警到你的监控平台（如Prometheus Alertmanager, Zabbix, 或商业监控软件）。告警信息应包括IP、分数、触发的关键规则、以及最近几条样例日志。
2. 数据可视化：将IP的评分数据（如每分钟新增可疑IP数、封禁IP总数、Top攻击来源IP）通过指标形式暴露出来（例如使用Prometheus的Gauge和Counter），然后在Grafana上制作仪表盘。这能让你直观地看到攻击态势。
3. 与WAF联动：如果你使用了云WAF或自建WAF（如ModSecurity），可以将识别出的恶意IP通过API动态添加到WAF的规则中，实现更全面的防护（不仅限于网络层封禁）。

5.4 关于“静态IP”与“动态IP”的思考

在热词中看到很多关于设置静态IP的内容（如rocky linux设置静态ip,debian 设定ip）。这从另一个角度提醒我们：攻击源可能是动态IP（如拨号宽带、数据中心动态分配）或静态IP（如被攻陷的服务器）。对于动态IP，封禁单个IP效果有限，攻击者可能很快更换IP。这时，我们的策略需要升级：

• 封禁IP段（CIDR）：如果发现来自某个特定/24或/22网段的大量攻击IP，可以考虑封禁整个网段。但这风险更大，需极其谨慎。
• 行为指纹识别：超越IP，尝试识别客户端的行为指纹（如TLS指纹、TCP窗口参数、请求包时序特征），即使IP变了，只要指纹相同，依然可以关联并处置。
• 启用挑战机制：对于可疑但未达到封禁阈值的IP，可以返回一个JavaScript挑战或Cookie验证，真人用户能轻松通过，而大多数自动化脚本会失败。

构建一个基于HTTP/1.*协议识别的IP黑名单系统，是一个从简单规则出发，逐步迭代到复杂、智能策略的过程。它不能替代专业的WAF或IDS，但作为一个轻量级、定制化的补充防线，它能非常有效地帮你从噪音中快速定位那些“低技术含量”但持续不断的扫描和试探行为，让你的服务器日志更加清净，安全基线更加牢固。