1. 项目概述为什么我们需要一款“轻量级私有防火墙”在互联网上运营一个网站无论规模大小都像是在一条繁忙的街道上开了一家店铺。你的店铺网站每天会迎来形形色色的访客其中绝大多数是友善的顾客但也难免会混入一些小偷、捣乱分子甚至强盗。传统的安全方案比如购买云服务商提供的WAFWeb应用防火墙就像是雇佣了一个强大的保安公司他们经验丰富能挡住大部分威胁。但问题也随之而来保安公司需要你提供店铺的所有钥匙网站流量数据他们会把每天谁来了、做了什么、停留多久等所有细节记录在他们的服务器上。对于一家小公司、一个工作室或者个人站长来说这不仅意味着持续的成本支出更关键的是你对自己数据的所有权和隐私性完全交给了第三方。这就是“私有化部署、数据加密且仅保存本地”的轻量级网站防火墙诞生的核心场景。它不是一个试图取代商业WAF的庞然大物而是一个为你量身定制的“智能门禁本地监控系统”。你完全拥有这套系统的控制权所有的访问日志、攻击拦截记录、安全规则都加密后存储在你自己的服务器硬盘上没有任何数据会离开你的环境。这对于处理敏感客户信息、内部数据或者单纯就是希望“我的数据我做主”的团队来说具有不可替代的价值。多端支持则意味着无论你是在办公室的电脑前还是在通勤路上用手机都能随时查看安全状态处理告警实现了安全运维的灵活性与即时性。2. 核心设计思路轻量、私有、可控的技术选型当我们决定自己动手打造这样一个工具时首要原则就是“轻量”。这意味着它不能对现有的网站服务器造成显著的性能负担安装部署要简单资源占用要小。因此在技术栈的选择上我们会倾向于那些高效、成熟且社区活跃的方案。2.1 架构模式反向代理与流量分析主流网站防火墙的核心工作原理是“反向代理”。简单来说它扮演了一个“前台接待”的角色。所有外部用户访问你网站的请求首先到达的是这个防火墙程序由它对请求进行快速“安检”分析HTTP/HTTPS请求头、参数、行为频率等只有被认为是合法的请求才会被转发给后方真正的网站服务器如Nginx、Apache。如果请求被识别为攻击如SQL注入、跨站脚本XSS、恶意爬虫则直接拦截并返回错误页面。这种模式的好处是对后端业务代码完全无侵入部署灵活。2.2 关键技术组件拆解为了实现轻量化和高效我们通常会基于以下几个核心组件构建Web服务器/反向代理核心Nginx或OpenRestyNginx的增强版内嵌LuaJIT虚拟机是首选。它们本身就以高性能、低内存占用著称。OpenResty尤其适合因为它允许我们使用Lua脚本在请求处理的生命周期中直接插入安全检测逻辑实现毫秒级的规则匹配。规则引擎与匹配逻辑这是防火墙的大脑。我们不会从头写一个复杂的引擎而是实现一个简化版的“正则表达式状态机”匹配器。将常见的攻击特征如SQL注入的union select、XSS的script编译成正则表达式规则库。同时为了应对CC攻击高频请求攻击需要实现一个基于IP或会话的“滑动窗口”计数器在内存中维护短时访问频率。数据存储与加密日志和拦截记录需要持久化。为了极致轻量和避免引入重型数据库如MySQLSQLite是最佳选择。它是一个单文件数据库无需独立服务进程通过简单的文件操作即可完成所有CRUD。对于“数据加密且仅保存本地”我们可以在将日志写入SQLite文件前使用AES-256算法对敏感字段如请求参数、客户端IP进行加密。加密密钥由用户在安装时生成并保存在服务器本地的一个配置文件中确保数据离开本机即无法解密。管理界面与多端支持需要一个直观的界面来查看日志、管理规则、调整配置。一个基于Vue.js或React的前端单页面应用SPA可以满足要求。通过RESTful API与后端Nginx/OpenResty 一个轻量的API服务如用Python Flask或Go编写通信。多端支持的本质就是让这个管理界面是响应式设计的能在PC、平板、手机上良好显示。更进一步可以封装一个简单的移动端App壳如使用Uni-app或Flutter但核心仍是Web技术。注意选择OpenRestyLua而非在Nginx中写C模块是因为Lua的开发效率和热更新能力远超C更适合快速迭代和规则更新符合“轻量运维”的需求。3. 核心功能模块的详细实现3.1 流量拦截与规则匹配引擎这是防火墙最核心的部分必须在性能和准确性之间找到平衡。实现原理 所有进入的HTTP请求首先被OpenResty的access_by_lua*阶段处理。我们在这里编写Lua脚本顺序执行以下检查IP黑白名单最直接的一层。维护两个内存中的Set使用Lua的table模拟优先匹配。黑名单IP直接返回403。基础攻击特征库规则链一个包含数百条正则表达式的规则表。每条规则定义了要检查的字段如args请求参数、uri、headers和对应的正则模式。检查时采用“短路匹配”策略一旦某个请求匹配到任何一条规则立即中断后续匹配执行拦截动作。-- 示例一个简单的SQL注入检测规则片段 local rules { { field args, pattern [[union\sselect]], action block }, { field args, pattern [[(\|\|;)\s*(or|and)\s.*]], action block }, { field uri, pattern [[\.\./]], action block }, -- 路径遍历 } for _, rule in ipairs(rules) do local value ngx.var[rule.field] or if value:match(rule.pattern) then log_to_sqlite(ngx.var.remote_addr, ngx.var.request_uri, SQLI, value) -- 记录日志 ngx.exit(403) -- 拦截 end end频率限制CC防护使用共享内存字典lua_shared_dict实现。为每个客户端IP或某个关键标识如登录用户名创建一个计数器。local limit_req require resty.limit.req local limiter limit_req.new(my_limit_store, 10, 5) -- 共享内存区速率10r/s突发5个 local key ngx.var.remote_addr local delay, err limiter:incoming(key, true) if not delay then if err rejected then log_to_sqlite(key, ngx.var.request_uri, CC_ATTACK, rate limited) ngx.exit(503) end ngx.exit(500) end实操心得规则顺序将最常用、最可能命中的攻击规则如简单的扫描器特征放在前面能提升平均匹配速度。正则优化避免使用过于宽泛、耗时的正则表达式。优先使用具体字符串匹配必要时才用正则。误报处理任何规则都可能误伤正常请求。务必实现一个“误报上报”接口当合法请求被拦截时用户可以通过管理界面一键将该请求加入“白名单规则”系统会自动学习并生成一条排除规则。3.2 私有化部署与数据加密存储“私有化”不仅仅是把软件装在自己的服务器上更关键的是数据生命周期的完全掌控。部署方案 我们提供一键安装脚本如install.sh其核心工作是检测并安装依赖OpenResty, SQLite3。从GitHub Release下载编译好的前端静态文件和管理后端二进制或用Python/Go写一并打包。生成默认的Nginx配置文件并修改现有网站的Nginx配置将所有流量引导到OpenResty监听的一个新端口如8080再由OpenResty转发给原网站。在首次运行时引导用户生成一个随机的AES-256加密密钥并保存到/etc/lightwall/key权限600。数据加密流程 日志记录不是简单写入数据库。在Lua日志函数中local function encrypt_log(data_table) local cjson require cjson local plain_text cjson.encode(data_table) -- 将日志转为JSON字符串 local aes require resty.aes local key read_key_from_file(/etc/lightwall/key) local encrypted aes:encrypt(plain_text, key) -- 使用AES加密 -- 将加密后的二进制数据进行Base64编码以便存入SQLite的TEXT字段 local encoded ngx.encode_base64(encrypted) return encoded end然后通过一个独立的日志处理进程或OpenResty的定时器将加密后的日志字符串插入本地的SQLite数据库文件中。这个数据库文件本身也可以放在加密的磁盘分区上实现双重保险。重要提示密钥管理是生命线。必须明确告知用户备份此密钥文件。一旦丢失所有加密的日志将无法解密。同时严禁将密钥提交到任何版本控制系统如Git。3.3 多端管理界面的构建管理界面需要提供实时威胁可视化、日志查询、规则管理和系统配置功能。技术栈前端Vue 3 Element Plus或Ant Design Vue。选择Vue 3因其组合式API更适合封装复杂的日志查询逻辑。Element Plus提供了丰富的响应式组件能轻松适配移动端。后端API使用GoGin框架或PythonFastAPI编写一个轻量级服务。它负责从SQLite数据库中读取加密日志解密后返回给前端。提供规则文件的增删改查接口。接收前端的控制命令如临时封禁某个IP。通信安全管理界面与API之间的通信必须使用HTTPS。可以在部署脚本中自动生成一个自签名证书或引导用户配置自己的证书。前端关键页面仪表盘显示今日总请求数、拦截数、攻击类型分布饼图、实时攻击IP地图利用IP查询地理位置库。日志审计提供强大的过滤查询支持按时间、IP、攻击类型、URL路径进行筛选。列表展示解密后的日志详情。规则管理以表格形式展示所有规则支持启用/禁用、编辑、导入/导出规则集。提供“测试规则”功能输入一个URL样例快速验证规则是否匹配。IP管理手动添加/删除IP黑白名单查看当前被自动封禁的IP列表及原因。实现多端适配使用CSS媒体查询和Element Plus的响应式布局组件如el-row,el-col确保在手机竖屏时表格变为卡片堆叠图表自适应缩放。关键操作按钮要足够大便于触控。4. 从零开始的部署与配置实操指南假设我们有一台运行Ubuntu 22.04的服务器原始网站由Nginx服务监听80/443端口。4.1 环境准备与安装首先通过SSH登录服务器。步骤一安装OpenResty# 导入OpenResty的GPG密钥和仓库 sudo apt-get update sudo apt-get install -y software-properties-common sudo add-apt-repository -y deb https://openresty.org/package/ubuntu $(lsb_release -sc) main sudo apt-get update sudo apt-get install -y openresty步骤二下载并安装轻量级防火墙我们假设项目名为LightWall已经打包好。# 创建一个安装目录 sudo mkdir -p /opt/lightwall cd /opt/lightwall # 假设从项目Release页面下载安装包此处以wget示例 sudo wget https://github.com/yourname/lightwall/releases/latest/download/lightwall.tar.gz sudo tar -zxvf lightwall.tar.gz # 运行安装脚本 sudo ./install.shinstall.sh脚本会交互式地询问你原始网站的Nginx配置文件路径通常是/etc/nginx/sites-available/your-site然后自动备份原配置并修改为将流量代理到OpenResty127.0.0.1:8080。同时它会初始化SQLite数据库并生成加密密钥。4.2 核心配置详解安装后主要配置文件在/usr/local/openresty/nginx/conf/nginx.conf中其中包含了对lightwall.lua的引用。lightwall-config.json(示例){ log_path: /var/log/lightwall/lightwall.db, encryption_key_file: /etc/lightwall/key, ruleset_path: /opt/lightwall/rules/default.rules, cc_protection: { enabled: true, rate: 10r/s, burst: 5, block_duration: 300 }, admin_api: { listen: 127.0.0.1:9000, auth_token: your_strong_token_here // 用于前端API调用鉴权 } }规则文件default.rules格式- id: 1001 enabled: true description: Detect basic SQL injection field: args pattern: union\\sselect action: block - id: 1002 enabled: true description: Detect directory traversal field: uri pattern: \\.\\./ action: block4.3 启动与验证# 启动OpenResty (LightWall核心) sudo systemctl start openresty sudo systemctl enable openresty # 启动管理后端API服务 sudo systemctl start lightwall-api sudo systemctl enable lightwall-api # 检查服务状态 sudo systemctl status openresty sudo systemctl status lightwall-api # 测试防火墙是否工作 curl -X GET http://你的服务器IP/?id1%20union%20select%201,2,3 # 正常应返回403 Forbidden而不是你网站的原始页面现在你可以通过浏览器访问https://你的服务器IP:9000/admin具体端口看配置来打开管理界面使用配置的token登录。5. 常见问题排查与性能调优实录在实际部署和运行中你肯定会遇到各种问题。以下是我在多次部署中积累的“避坑指南”。5.1 部署与启动问题问题1安装后网站无法访问显示502 Bad Gateway。排查思路检查OpenResty是否运行sudo systemctl status openresty。查看OpenResty错误日志tail -f /usr/local/openresty/nginx/logs/error.log。最常见的原因是Lua脚本语法错误或依赖的Lua库未找到。检查防火墙配置中proxy_pass指向的后端地址和端口是否正确后端服务原始网站是否在运行。解决根据错误日志修正Lua代码或安装缺失的Lua包如luarocks install lua-cjson。确保后端服务可达。问题2管理界面无法打开或打开后无法加载数据。排查思路检查管理后端API服务状态sudo systemctl status lightwall-api。检查API服务监听的端口如9000是否被服务器防火墙如ufw放行。打开浏览器开发者工具F12查看Console和Network标签页确认前端是否成功连接到API以及API返回的错误信息。解决开放对应端口sudo ufw allow 9000。检查API配置文件中的auth_token是否与前端请求头中携带的一致。5.2 功能与性能问题问题3误报太多把正常用户请求拦截了。原因安全规则过于严格或宽泛。例如一条检测select的规则可能会拦截包含“select your plan”的正常搜索查询。解决精细化规则避免单独匹配select、union等词。必须结合上下文如使用正则union\sselect并限定在参数值中匹配。启用学习模式初期可以设置一个“观察模式”只记录疑似攻击而不拦截运行一段时间后分析日志调整规则。使用白名单管理界面提供“误报申诉”功能允许将特定URL路径或参数加入全局白名单。问题4开启防火墙后网站响应明显变慢。原因规则数量过多或正则表达式过于复杂导致每个请求的检测时间过长。CC防护的共享内存操作在高并发下也可能成为瓶颈。性能调优规则优化定期审计规则禁用那些几乎从未命中或误报率高的规则。将最可能命中的、简单的规则前置。启用缓存对于频繁访问的静态资源如图片、CSS、JS可以在OpenResty层面设置缓存直接返回不经过Lua检测逻辑。location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ { access_by_lua_block {} -- 此处为空跳过检测 proxy_pass http://backend; expires 30d; }调整CC参数根据实际流量调整rate和burst值。过小的值会误伤正常用户过大的值则失去防护意义。可以针对登录、搜索等关键接口设置更严格的限制对首页等静态页面放宽。监控资源使用top或htop命令监控OpenResty工作进程的CPU和内存占用。如果持续过高需要考虑升级服务器配置或将部分计算逻辑如复杂的IP地理位置查询移到异步任务中处理。问题5SQLite数据库文件越来越大影响性能。解决实现日志轮转和归档策略。在管理后端API中添加一个定时任务如使用cron每天凌晨将当前数据库文件复制备份如lightwall.db.yyyy-mm-dd然后清空或新建一个当前数据库文件。前端界面提供“日志导出”功能允许用户将历史日志导出为加密的压缩文件后从本地删除释放空间。可以考虑按时间分表但SQLite对分表的支持不如客户端管理方便简单的按日归档文件更实用。5.3 安全加固建议密钥管理加密密钥文件/etc/lightwall/key的权限必须设置为600仅root可读。考虑使用硬件安全模块HSM或操作系统提供的密钥保管服务如Linux的Keyutils进行更高强度的保护但这超出了“轻量级”范畴。管理接口隔离管理后端APIadmin_api配置务必只监听在本地回环地址127.0.0.1并通过Nginx反向代理对外提供HTTPS访问并配置强密码或证书认证。绝对不要直接暴露在公网。规则更新提供一键更新规则库的功能。可以定期从项目维护的官方规则源一个安全的URL拉取更新但更新前务必在测试环境验证避免新规则导致线上服务异常。自身防护防火墙本身也是一个服务需要防止被攻击。确保OpenResty和管理API服务都以非root用户身份运行并限制其系统权限。这套轻量级防火墙的价值不在于它比几十万一年的商业WAF更强大而在于它给了中小团队和个人开发者一个看得见、摸得着、完全可控的安全底线。你可以清晰地知道每一条拦截背后的原因可以随心所欲地调整规则以适应自己独特的业务逻辑更重要的是你的所有安全数据都牢牢锁在自己的保险柜里。在数据隐私日益重要的今天这种“自力更生”的安全能力本身就是一种宝贵的资产。