背景是我们弄了一个jenkins做Android的持续集成，然后昨天sa突然说我们的端口有漏洞，要我们尽快配置升级。
如何升级jenkins？jenkins默认的升级中心是这个：https://updates.jenkins.io/update-center.json
但是操作更新的时候提示更新失败：jenkins 升级到 2.227.1 失败. Fail to download from https://mirrors.tuna.tsinghua.edu.cn
最后找到的方法是：
在这个页面 https://${your-server-ip,eg:yeshen.org}/pluginManager/advanced
配置升级站点为：
https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json
等配置重新同步，同步完点升级即可。
我配置后2.324 (2021-12-06) ，更到最新版之后看起来功能正常（顺便把使用的插件也一并更新了）
Log4j2 的漏洞是啥？Apache Log4j2某些功能存在递归解析功能，攻击者可直接构造恶意请求，触发远程代码执行漏洞。漏洞利用无需特殊配置，所有使用了log4j2组件的服务均可能受到影响
受影响版本：Log4j2 versions >= 2.0-beta9 and <= 2.14.1
细节可以参考这两个文章：
https://blog.qualys.com/vulnerabilities-threat-research/2021/12/10/apache-log4j2-zero-day-exploited-in-the-wild-log4shell
https://www.tenable.com/blog/cve-2021-44228-proof-of-concept-for-critical-apache-log4j-remote-code-execution-vulnerability
The crafted request uses a Java Naming and Directory Interface (JNDI) injection via a variety of services including: - Lightweight Directory Access Protocol (LDAP) - Secure LDAP (LDAPS) - Remote Method Invocation (RMI) - Domain Name Service (DNS) If the vulnerable server uses log4j to log requests, the exploit will then request a malicious payload over JNDI through one of the services above from an attacker-controlled server. Successful exploitation could lead to RCE.
个人看文章的理解来说，就是它支持远程加载JNDI服务，在解析日志的时候。
Java runtimes later than 8u121, then it is protected against remote code execution by defaulting “com.sun.jndi.rmi.object.trustURLCodebase” and “com.sun.jndi.cosnaming.object.trustURLCodebase” to “false”
这个功能关掉了安全验证，导致如果打印中的日志包含JNDI接口，log4j会自动加载，且在本地服务上执行。
处理方法可以是： 配置 “log4j2.formatMsgNoLookups” to “true”
也可以是升级版本到 log4j2 2.15
jenkins 2.324(2021-12-06最新版) 中使用的是 org.slf4j:log4j-over-slf4j:1.7.32
实际日志解析是slf4j，而不是log4j，所以不受影响
不过sa确实是发现了我们的jenkins的一些网络配置问题，他顺手给修了
