1. 项目概述：为什么企业级Solr安全加固刻不容缓

最近在帮一个客户做安全审计，他们的搜索服务用的是Apache Solr。不查不知道，一查吓一跳，几个默认配置和已知的高危漏洞几乎全中，攻击者完全有可能利用这些漏洞拿到服务器权限或者窃取核心数据。这让我意识到，很多团队把Solr当作一个“开箱即用”的搜索黑盒，只关注搜索功能是否正常，却严重忽略了其作为一款复杂Java应用所固有的安全风险。尤其是在当前环境下，各类远程代码执行（RCE）漏洞频发，比如最近讨论很多的fastjson 1.2.83 RCE漏洞，其本质也是通过不当的反序列化机制被攻击者利用，这与Solr历史上的一些高危漏洞（如CVE-2019-0193）在攻击思路上有异曲同工之妙。因此，对Solr进行系统性的安全加固，绝不是简单的版本升级，而是一套涵盖漏洞修复、配置优化、访问控制、监控审计的组合拳。今天，我就结合这次实战经验，把这套企业级的Apache Solr安全加固方案拆解清楚，从7个最常见的高危漏洞修复入手，延伸到深度的配置优化，目标是构建一个既安全又高性能的搜索服务。

2. 核心安全风险与漏洞修复全景图

在动手之前，我们必须先理清Solr面临的主要威胁来自哪里。Solr的安全风险可以粗略分为三类：组件漏洞、配置缺陷和架构风险。组件漏洞主要指Solr自身、其依赖的库（如Apache Lucene、Jetty、ZooKeeper）或第三方插件存在的可被利用的代码缺陷；配置缺陷则是由于管理员采用了不安全的默认设置或错误配置，人为打开了攻击面；架构风险则涉及部署模式、网络隔离等更高层面的问题。我们的加固工作，就是要系统性地解决这三个层面的问题。

2.1 7个必须立即修复的高危漏洞与实操方案

这里我梳理了7个最具代表性的高危漏洞或配置缺陷，它们覆盖了从远程代码执行到信息泄露的多种攻击方式。修复它们是企业安全基线的最低要求。

2.1.1 漏洞一：未授权访问与数据泄露（默认配置陷阱）

这是最普遍也最危险的问题。Solr默认安装后，管理界面（Admin UI）和API接口通常没有任何认证，直接暴露在网络上。

风险分析：攻击者无需任何凭证即可访问/solr/admin/、/solr/#/~cores等路径，查看所有核心（Core）信息、执行查询、甚至通过某些接口进行配置修改。更危险的是，如果Solr中索引了敏感数据，攻击者可以通过构造查询，直接批量导出这些数据。

修复方案：

1. 启用基础认证（Basic Authentication）：这是最直接的方案。修改solr.in.sh（Linux）或solr.in.cmd（Windows），取消以下行的注释并设置强密码：

   # 在solr.in.sh中启用 SOLR_AUTH_TYPE="basic" SOLR_AUTHENTICATION_OPTS="-Dbasicauth=solr:YOUR_COMPLEX_PASSWORD_HERE"

   重启Solr后，访问任何界面都需要输入用户名（solr）和密码。
2. 配置基于规则的访问控制（RBAC）：对于生产环境，仅基础认证不够。需要配置security.json文件，实现更细粒度的权限控制。例如，可以定义admin、search、update等不同角色，并指定哪些用户或IP地址拥有这些角色。

   // 放置在Solr主目录的security.json { "authentication": { "class": "solr.BasicAuthPlugin", "credentials": {"solr": "IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0= Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c="} }, "authorization": { "class": "solr.RuleBasedAuthorizationPlugin", "permissions": [ {"name": "security-edit", "role": "admin"}, {"name": "collection-admin-edit", "role": "admin"}, {"name": "read", "role": ["admin", "search-user"]} ], "user-role": {"solr": "admin", "app_user": "search-user"} } }

   注意：上述credentials中的密码是经过SHA-256哈希加盐处理的，不能直接写明文。可以使用Solr提供的bin/solr auth工具来生成。

实操心得：不要只保护Admin UI。务必确保所有API端点，特别是/solr/下的所有路径，都受到认证保护。同时，将认证信息集成到你的应用连接Solr的客户端配置中。

2.1.2 漏洞二：XML实体扩展（XXE）攻击（CVE-2017-12629）

Solr在接收XML格式的数据更新请求时，默认的XML解析器可能支持外部实体引用。攻击者可以构造恶意的XML文档，诱使服务器读取本地文件（如/etc/passwd）或发起内部网络请求。

风险分析：通过Update Handler提交包含恶意DTD和ENTITY声明的XML文档，可能导致敏感文件内容被读取并返回给攻击者。

修复方案：

1. 升级Solr版本：此漏洞在Solr 7.1版本中得到修复。最根本的方案是升级到7.1或更高版本。
2. 配置禁用XXE：如果因故无法立即升级，可以在solrconfig.xml中为UpdateRequestHandler配置XML解析器属性，显式禁用DTD和外部实体。

   <requestHandler name="/update" class="solr.UpdateRequestHandler"> <lst name="defaults"> <str name="update.contentType">application/xml</str> <str name="xmlParser.parser">com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl</str> <bool name="xmlParser.isSupportingExternalEntities">false</bool> <bool name="xmlParser.isSupportingDTD">false</bool> </lst> </requestHandler>

3. 使用JSON作为数据交换格式：在业务允许的情况下，优先使用JSON格式进行数据更新，从根本上规避XML解析器带来的风险。

2.1.3 漏洞三：远程代码执行（RCE） via Velocity模板（CVE-2019-17558）

Solr的/solr/corename/configAPI允许修改配置。其中，params.resource.loader.enabled这个参数控制着是否允许从Solr配置目录外加载Velocity模板文件。当此参数被恶意开启，且Solr开启了Velocity响应编写器（wt=velocity）时，攻击者可以上传并执行恶意模板，实现远程代码执行。

风险分析：攻击流程通常是：通过未授权或弱权限账户访问config API，开启params.resource.loader.enabled，然后通过查询接口指定一个指向攻击者可控文件的Velocity模板路径，最终在服务器上执行任意命令。

修复方案：

1. 立即升级：该漏洞在Solr 8.3.0及更高版本中已被修复。升级是最佳路径。
2. 严格配置访问控制：如果无法升级，必须确保/solr/corename/configAPI只能由最高权限的管理员角色访问。在security.json中，为config-edit权限设置最严格的角色限制。
3. 全局禁用Velocity响应编写器：如果业务完全不需要Velocity模板渲染功能，可以在solrconfig.xml中彻底禁用它。找到并注释掉或删除所有与velocity相关的queryResponseWriter配置块。

   <!-- 查找并禁用类似配置 --> <!-- <queryResponseWriter name="velocity" class="solr.VelocityResponseWriter"/> -->

2.1.4 漏洞四：JMX服务未授权访问

Solr默认会开启JMX（Java Management Extensions）服务，用于监控和管理。如果JMX服务端口（默认可能为18983）暴露在网络上且未设置认证，攻击者可以直接连接并操作MBean，这可能导致信息泄露甚至执行代码。

风险分析：通过JConsole或类似工具直接连接到暴露的JMX端口，可以查看JVM运行状态、线程堆栈、甚至动态加载类。

修复方案：

1. 禁用远程JMX：在非必须远程监控的情况下，最简单安全的方式是禁用远程JMX访问。在solr.in.sh中，确保以下参数不被启用或指向本地回环地址。

   # 禁用远程JMX # ENABLE_REMOTE_JMX_OPTS="false"

2. 启用JMX认证与SSL：如果必须使用远程JMX，务必启用强认证和SSL加密。这需要配置复杂的com.sun.management.jmxremote.*系列JVM参数，包括指定密码文件、访问控制文件、启用SSL等。操作繁琐且容易出错，一般不建议在生产环境开放。
3. 网络层隔离：通过防火墙或安全组策略，严格限制只有监控服务器或跳板机的IP地址可以访问Solr服务器的JMX端口。

2.1.5 漏洞五：敏感配置文件信息泄露

Solr的Web界面或API可能无意中暴露包含敏感信息的配置文件内容，例如solrconfig.xml、schema.xml，甚至security.json本身（如果配置不当）。

风险分析：这些文件可能包含数据库连接字符串、加密密钥、内部路径等信息。攻击者通过访问特定的管理端点或利用某些功能（如文件列表接口）可能获取到这些文件内容。

修复方案：

1. 审查并清理配置文件：从配置文件中移除所有明文密码、密钥、内部IP等敏感信息。使用环境变量或外部密钥管理服务来注入这些敏感配置。
2. 限制Config API的访问：确保/solr/corename/config/overlay和/solr/corename/file等用于查看和修改配置的API受到严格的授权控制。
3. 禁用目录列表：确保内嵌的Jetty服务器或前置的Web服务器（如Nginx）已禁用目录浏览功能。

2.1.6 漏洞六：不安全的反序列化点

Solr的某些功能，例如使用JavaBin格式进行通信，或者某些自定义插件，可能涉及Java对象的序列化与反序列化。如果反序列化过程没有进行严格的白名单校验，就可能被注入恶意序列化数据，导致RCE。这与“fastjson 1.2.83的远程代码执行漏洞”的原理非常相似。

风险分析：攻击者构造一个恶意的Java序列化流，通过特定的API端点（如某些插件自定义的端点）发送给Solr服务器。Solr在反序列化这个流时，会执行流中指定的类构造方法或代码，从而被攻击者控制。

修复方案：

1. 避免使用不安全的通信格式：除非绝对必要，否则避免使用JavaBin等二进制格式作为外部系统的通信协议。优先使用JSON或XML。
2. 升级依赖库：确保Solr所使用的所有第三方库，特别是序列化相关的库（如Jackson, fastjson如果被间接引用）都是已知安全的最新版本。
3. 自定义插件的安全审计：对于自行开发的Solr插件，必须审查所有从网络接收数据的入口点，避免直接使用ObjectInputStream进行反序列化。如果必须使用，应遵循Java官方安全指南，使用ObjectInputFilter设置严格的白名单。

2.1.7 漏洞七：SSRF（服务器端请求伪造）

如果Solr的某个功能（如数据导入处理器DIH的dataimport命令，或某些自定义功能）允许从URL加载数据，且未对URL地址进行严格校验，就可能存在SSRF漏洞。攻击者可以诱使Solr服务器向内部网络发起请求，探测或攻击内网服务。

风险分析：攻击者构造一个指向内网地址（如http://169.254.169.254/latest/meta-data/获取云服务器元数据）的URL，通过Solr的功能让服务器去请求，并将结果返回给攻击者。

修复方案：

1. 禁用或限制危险功能：如非必要，禁用DataImportHandler（DIH）功能。如果必须使用，务必在其配置中严格限制可连接的数据库地址和URL地址白名单。
2. 实施网络层出口过滤：在服务器或容器层面，配置严格的出站防火墙规则，限制Solr进程只能访问必要的、已知的外部服务地址（如数据库、特定的API网关），阻止其随意访问内网段。
3. 代码层面校验URL：对于任何允许传入URL参数的功能，在代码层面进行校验，只允许HTTP/HTTPS协议，并禁止访问回环地址（127.0.0.1, localhost）、私有IP段（10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16）和链路本地地址（169.254.0.0/16）。

3. 深度配置优化：构建安全与性能的基石

修复漏洞是“堵后门”，而良好的配置则是“筑高墙”。一套优化的配置不仅能提升安全性，还能显著提高系统稳定性和性能。这里我分享几个关键的配置优化点，其中一些思路与“mysql配置优化参数”的核心理念是相通的——即根据硬件资源和业务负载进行精细化调优。

3.1 运行环境与JVM调优

Solr是Java应用，JVM是它的“发动机”。错误的JVM配置是导致内存溢出、GC停顿长、性能低下的首要原因。

关键参数与解析：

• -Xms和-Xmx（堆内存）：这是最重要的参数。-Xms设置JVM堆内存初始大小，-Xmx设置最大大小。必须设置为相同的值，以避免运行期堆内存动态调整带来的性能抖动。对于中等规模的Solr节点，设置为物理内存的50%-70%是合理的起点。例如，一台32G内存的机器，可以设置-Xms16g -Xmx16g。

  # 在solr.in.sh中设置 SOLR_JAVA_MEM="-Xms16g -Xmx16g"

• -XX:+UseG1GC（垃圾回收器）：对于大内存（>8G）的Solr服务，G1垃圾回收器通常比传统的Parallel或CMS GC表现更好，它能提供更可预测的停顿时间。确保启用此参数。
• -Dsolr.autoSoftCommit.maxTime和-Dsolr.autoCommit.maxTime：这两个参数控制着软提交和硬提交的频率。过于频繁的提交会导致性能下降，过于稀疏则可能导致数据丢失风险增大或搜索延迟高。需要根据业务对数据实时性的要求来权衡。例如，设置软提交每1秒一次（-Dsolr.autoSoftCommit.maxTime=1000）以实现近实时搜索，硬提交每5分钟或索引变化达到一定量时一次。
• -Djetty.request.header.size：如果查询语句或字段值非常长，可能需要增大Jetty服务器允许的请求头大小，避免出现414 URI Too Long或请求被截断的错误。可以设置为-Djetty.request.header.size=65536（64KB）。

实操心得：JVM调优没有银弹。强烈建议在预发布环境进行压力测试，结合GC日志（使用-Xlog:gc*参数生成）进行分析。观察Full GC的频率和时长，目标是尽可能避免Full GC，让Young GC的停顿时间保持在业务可接受的范围内（如200ms以下）。

3.2 索引与查询性能优化配置

安全稳定的前提下，性能是核心诉求。优化主要围绕solrconfig.xml展开。

索引优化：

• mergePolicyFactory（合并策略）：索引段（Segment）的合并是I/O密集型操作。使用TieredMergePolicy并调整参数，如maxMergeAtOnce（一次合并的最大段数，默认10，可降低为5以减少I/O突发）、segmentsPerTier（每层的段数，默认10，可适当增加）。
• ramBufferSizeMB：控制文档在写入索引前在内存中缓冲的大小。增加此值（如从默认的100MB增加到512MB）可以减少磁盘I/O频率，提升索引速度，但会消耗更多堆外内存。需要监控系统的内存使用情况。
• useCompoundFile：对于大量小文件的场景，设置为true可以减少Lucene索引文件的数量，对某些文件系统性能有益，但可能会略微降低搜索速度。需要根据实际情况测试。

查询优化：

• 过滤器缓存（filterCache）：这是对查询性能提升最明显的缓存。它缓存了过滤器查询（fq参数）的结果位集。对于频繁使用的、结果集变化不快的过滤器（如“状态=已发布”、“分类=科技”），大的过滤器缓存能极大加速查询。

  <filterCache class="solr.CaffeineCache" size="512" initialSize="512" autowarmCount="128"/>

  将size设置为一个较大的值（如几千甚至上万），前提是你的过滤器数量多且内存充足。
• 查询结果缓存（queryResultCache）：缓存完整的查询结果。对于完全相同的查询（相同的q、fq、sort等参数）重复率高的场景有效。但如果查询模式多样，其命中率会很低，反而浪费内存。需要根据监控决定是否启用及大小。
• 字段值缓存（fieldValueCache）：用于加速分面（Facet）、高亮（Highlighting）和按字段排序。如果业务中大量使用这些功能，适当调大此缓存。
• maxBooleanClauses：限制一个查询中布尔子句的最大数量，防止过于复杂的查询拖垮服务器。默认是1024，对于极端复杂的查询可能需要调高，但需警惕恶意查询。

3.3 网络与访问控制强化

配置优化不仅限于Solr自身，还包括其运行环境。

1. 使用反向代理（如Nginx）：永远不要将Solr的Jetty服务器直接暴露在公网。在前端部署Nginx或Apache HTTP Server作为反向代理和负载均衡器。
   • 作用：终止SSL/TLS连接，提供HTTPS；实现IP白名单过滤；限制请求速率（rate limiting）防止CC攻击；作为静态资源服务器，减轻Solr负担。
   • 关键Nginx配置示例：

     upstream solr_backend { server 127.0.0.1:8983; # Solr监听在内网端口 keepalive 32; } server { listen 443 ssl; server_name solr.yourcompany.com; ssl_certificate /path/to/cert.pem; ssl_certificate_key /path/to/key.pem; # IP白名单，只允许应用服务器访问 allow 10.0.1.0/24; deny all; # 速率限制 limit_req_zone $binary_remote_addr zone=solrlimit:10m rate=10r/s; location /solr/ { limit_req zone=solrlimit burst=20 nodelay; proxy_pass http://solr_backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # 重要：传递认证头 proxy_set_header Authorization $http_authorization; proxy_pass_header Authorization; } }

2. 修改默认端口：将Solr默认的8983端口改为一个非标准端口，虽然不能防止定向攻击，但可以减少自动化扫描工具的骚扰。
3. 操作系统用户与权限：切勿使用root用户运行Solr。创建一个专用的、低权限的系统用户（如solr），并将Solr的安装目录、数据目录、日志目录的所有权赋予该用户。严格限制该用户对系统其他文件的访问权限。

4. 监控、审计与应急响应

安全是一个持续的过程，加固之后必须配以有效的监控和审计。

4.1 关键监控指标

• 系统层面：CPU使用率、内存使用率（尤其关注非堆内存）、磁盘I/O、网络流量。
• JVM层面：堆内存使用情况（老年代、新生代）、GC频率与耗时（特别是Full GC）、线程数。
• Solr应用层面：
  • 查询请求率/QPS：监控每秒查询请求数，发现异常流量。
  • 请求延迟（P95, P99）：跟踪查询响应时间，性能劣化可能是攻击或配置问题的前兆。
  • 缓存命中率：关注filterCache、queryResultCache的命中率，过低可能意味着需要调整缓存策略或存在异常查询模式。
  • 索引大小与段数：监控索引的增长和段合并情况。
  • 错误日志：实时监控Solr日志（solr.log）中的ERROR和WARN级别信息。

4.2 安全审计日志

确保Solr的审计功能被启用，记录所有关键操作。

1. 在solr.xml中启用审计日志插件：

   <auditLogPlugin class="solr.SolrLogAuditLoggerPlugin"> <str name="async">true</str> <!-- 异步记录，避免影响性能 --> </auditLogPlugin>

2. 审计日志会记录诸如：用户登录/登出、集合/核心的创建/删除、配置修改、数据导入导出等事件。定期审查这些日志，寻找可疑行为（如非管理员在非工作时间修改配置、大量失败的登录尝试等）。

4.3 应急响应预案

事先制定好预案，当发现安全事件（如漏洞被利用、出现异常流量）时，能快速响应。

1. 隔离：立即通过防火墙或负载均衡器将受影响节点从生产流量中摘除。
2. 取证：备份当前状态下的日志文件、配置文件、索引数据，用于事后分析。
3. 遏制与根除：根据漏洞分析，应用补丁、修改配置、修复代码。对于被植入的后门或恶意数据，进行彻底清理。
4. 恢复：从干净的备份中恢复数据，在验证环境充分测试后，重新上线。
5. 复盘：召开复盘会议，分析事件根本原因，更新安全配置和应急预案。

5. 持续集成与自动化加固

对于使用容器化或自动化部署的团队，可以将安全加固步骤脚本化、流程化。

1. Dockerfile安全实践：在构建Solr镜像时，就集成安全配置。
   • 使用官方镜像的最小化变体（如-slim）。
   • 以非root用户运行容器。
   • 在Dockerfile中直接写入加固后的solr.in.sh、security.json等配置文件。
   • 扫描镜像中的已知漏洞（使用Trivy、Grype等工具）。
2. 配置即代码：将solrconfig.xml、schema.xml、security.json等配置文件纳入版本控制系统（如Git）。任何修改都通过Pull Request流程进行评审和审计。
3. 自动化安全扫描：在CI/CD流水线中集成针对Solr的漏洞扫描工具（如针对其特定版本的CVE数据库检查），确保新部署的实例符合安全基线。

企业级Solr的安全加固是一项系统工程，它始于对漏洞的及时修复，成于精细化的配置与架构设计，并依赖于持续的监控和自动化运维。这套方案不是一成不变的，你需要结合自己业务的实际流量模式、数据敏感度和运维能力进行调整。最关键的是建立起“安全左移”的意识，在系统设计和部署的初期就将这些安全考量融入进去，而不是等问题发生后再来补救。