季兴 发布的文章

上次的数据库故障余波未平。老服务整改周期内仍有可能增高，有没什么方法限制单个pod只能建立一定数量的数据库连接，把事故控制在一定范围内

  • 首先是数据库层面，可以在配置文件中限制连接数，但基于容器的环境IP会有变化 pass
  • 其次想到的是服务网格，因为是业务标配+出色的流量控制，应该可以从这里入手。看了圈文档，Istio更多关注的是进方向
  • 再次想到kubernetes本身的网络插件也有限流的功能，calico具备对进出方向端口的限制，但没找到连接数的

陷入僵局，最笨用iptables限制，但还能实时发现pod的重启更换IP，难道要复杂化，监控结合脚本的方式吗？忽然灵光一闪，initContainers阶段不是可以做很多事情嘛

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  initContainers:
  - name: init-iptables
    image: my-iptables-image
    command: ['sh', '-c', 'iptables -A OUTPUT -p tcp --dport 3306 -m connlimit --connlimit-above 20 -j REJECT']
  containers:
  - name: my-container
    image: my-image

😅未验证，原理可行- -

某日读写分离中间件报警，有大量非业务IP连接涌入，新连接无法建立。查询数据库连接有大量的”unauthenticated user 1.2.3.4:37414 NULL Connect NULL Reading from net NULL”。一时间大量用户报障，“登录失效”、“设备断连”、“影响产线生产”等等
解决过程倒不复杂，跳过中间件恢复。售后工程师承认是中间件设计问题，释放连接逻辑bug，也提到了有大量连接时可能触发！

反观自身，架构设计阶段把过多的压力放在主库，19年上线的读写分离中间件就是“业务迭代优先，没时间基础设施改造”、“历史包袱”背景下的缓兵之计。阿里云的问题有几点
1.中间件控制台无法显示真实IP，故障后对方研发回复“日志因升级规格消失？”
2.假死后控制台无法重启
3.控制台监控不准确，使用者无法准确选择
4.1.2版本释放连接逻辑bug
主因是内部某服务突然建立了大量连接，进而引发的故障。

  • 开发阶段的考虑对运维阶段的影响：

开发阶段把更多的重点放在功能实现和业务迭代上，而忽略了基础设施的可扩展性。这可能会造成短期内的业务顺利进行，但长期看来，如果基础设施不能跟上业务的发展，最终可能会形成技术债务，导致在运维阶段遇到无法解决或者处理复杂度高的问题。

  • 对云服务商SLA的信任问题：

云服务提供商的SLA（服务等级协议）是我们选择使用其服务的一个重要依据，但是是否100%信任SLA，我们需要结合自身的业务情况和对服务提供商的了解来决定。在应急情况下，我们可能需要更具备自主的故障应对能力，而不是完全依赖服务提供商的SLA。

在对内部OS部门优化的过程中发现，服务器整体利用率很好，编译时可以将服务器所有线程打满，唯一掉链子的时候是解压缩unzip环节，只有单线程升高。简单了解了下，原来已经有了多线程的pigz工具，格式做一些微调即可。详细评测https://zhuanlan.zhihu.com/p/389817246
在翻看docker源码时，发现也会将pigz等压缩工具优先docker_source_code.jpg

chatGPT火爆IT圈已经几个星期了，仿佛没用过就被时代所抛弃。了解后发现，使用门槛还是挺高，需要使用海外的手机号注册openai，常见的“机场”都会被屏蔽。偶然发现接口在国内是可以访问的
testchatgpt.jpg

接下来的事就很简单了，使用django起了个页面，调用接口就可以了，供内网体验wangyechat.jpg

有效代码12行

import openai

openai.api_key = "sk-od9TZTgXar70JLTxf4K1T3BlbkFJlcQjxxxxx"

response = openai.Completion.create(
    engine="text-davinci-003",  # select model
    prompt="人生的意义何在？",
    max_tokens=512,  # response tokens
    temperature=1,  # diversity related
    top_p=0.75,  # diversity related
    n=1,  # num of response
)

completed_text = response["choices"][0]["text"]
print(completed_text)

需求描述：对某一地址，公司网络解析至172.16.1.1，外部解析到1.1.1.1
现状：公司内无单独的DNS服务器，DHCP分配上海公共DNS 202.96.209.5/133
过程：

  1. 内部搭建DNSmasq，DHCP更改配置。稍繁琐，所有DNS流量都走DNSmasq，单点且没必要
  2. 智能DNS解析中的自定义线路解析，实现原理

云解析是通过识别LOCALDNS的出口IP，来判断访问者来源。
如客户端LOCALDNS支持EDNS
因为云解析DNS支持 edns-client-subnet，所以在获取访问者来源IP时，优先获取 edns-client-subnet 扩展里携带的IP ，如果edns-client-subnet 扩展里存在IP，云解析DNS会以该IP来判断访问者的地理位置 ；如果不存在，则以LocalDNS出口ip来判断访问者的地理位置。

dig +short TXT whoami.ds.akahelp.net

不错的办法，但我的DNS出口IP带ipv6，测试下来不生效
自定义线路解析.jpg

  1. 偶然发现华为防火墙有DNS透明代理功能，可以把特定解析指定DNS服务器，配合DNSmasq，测试下来效果逆天。不管设置何DNS，都受影响

一、一直自诩是柔性的管理者，讲情怀、谈感情、不涉及原则问题都是友善提醒。谈谈近期遇到的一位伙伴小王，他是一个月前加入，原本负责网络的同学匆忙离开。积压的问题越来越多，小王在上手之后不太能搞定，我经常提醒不要成为“沟通黑洞”，发包过去一声不吭。无奈，离开

二、会议效率降低怪象

  1. 靠会议推动，会议过多
  2. 不参会被定责，各类事故复盘会中，未参会部门会被定责。质量部门亦或是质量人员不够专业

对待故障要敬畏，要追根因。惩罚机制要恰到好处，避免大家不敢动，更应该把故障看成一份宝贵的经验包；对待历史问题不逃避。我反对把责任甩的一干二净。
正因为我这种“大包大揽”的责任感，质量部门经常莫名其妙定责给我。前天一次故障，其部门自行维护的服务单点宕机，事故前多次反复提醒仍不整改。坑惨一波又一波接任者

三、越来越像项目经理，技术上已得不到成长，离我的“专家”目标渐远
qunshan.jpg

遇到一种场景，某前端服务部署在kubernetes中，有偶发的服务故障。想着健康探针重启就行，忽然想到，如果是重要的线上服务宕机，不查出来心里憋得慌，怎么让服务恢复的同时又能保留现场呢
改当前pod的标签，这样deployment会认为副本消失，自动创建。完美实现老容器保留，业务也及时恢复
截图.jpg

kong中默认有安全插件，黑白名单限流等，限制UA暂时没找到。可以自己开发一个

-- handler.lua
local BasePlugin = require "kong.plugins.base_plugin"
local MyPluginHandler = BasePlugin:extend()

MyPluginHandler.VERSION = "1.0.0"
MyPluginHandler.PRIORITY = 10

function MyPluginHandler:new()
  MyPluginHandler.super.new(self, "block-user-agent")
end

function MyPluginHandler:access(conf)
  MyPluginHandler.super.access(self)
  
  -- 检查 User-Agent 请求头
  local user_agent = kong.request.get_header("User-Agent")
  for i, ua in ipairs(conf.blocked_user_agents) do
    if user_agent == ua then
      -- 如果 User-Agent 被阻止，使用 kong.response.exit 返回响应并停止处理
      return kong.response.exit(conf.response_code, { message = conf.response_message })
    end
  end
end
-- schema.lua
local typedefs = require "kong.db.schema.typedefs"

return {
  name = "block-user-agent",
  fields = {
    { consumer = typedefs.no_consumer },
    { config = {
        type = "record",
        fields = {
          { blocked_user_agents = { type = "array", default = {}, elements = { type = "string", }, }, },
          { response_code = { type = "number", default = 403 }, },
          { response_message = { type = "string", default = "Forbidden" }, },
        },
      },
    },
  },
}

docker启动时注意修改kong/constants.lua，在插件底部加入UA_block

docker stop kong-gateway
docker rm kong-gateway  
docker run -d --name kong-gateway \
 --network=kong-net \
 -e "KONG_DATABASE=postgres" \
 -e "KONG_PG_HOST=kong-database" \
 -e "KONG_PG_USER=kong" \
 -e "KONG_PG_PASSWORD=kongpass" \
 -e "KONG_PROXY_ACCESS_LOG=/dev/stdout" \
 -e "KONG_ADMIN_ACCESS_LOG=/dev/stdout" \
 -e "KONG_PROXY_ERROR_LOG=/dev/stderr" \
 -e "KONG_ADMIN_ERROR_LOG=/dev/stderr" \
 -e "KONG_ADMIN_LISTEN=0.0.0.0:8001" \
 -e "KONG_ADMIN_GUI_URL=http://localhost:8002" \
 -v /data/UA-block:/usr/local/share/lua/5.1/kong/plugins/UA-block \
 -v /data/constants.lua:/usr/local/share/lua/5.1/kong/constants.lua \
 -p 8000:8000 \
 -p 8443:8443 \
 -p 8001:8001 \
 -p 8444:8444 \
 -p 8002:8002 \
 -p 8445:8445 \
 -p 8003:8003 \
 -p 8004:8004 \
 kong/kong-gateway:2.6.1.0-alpine

UA-ill.jpg

最近忙于处理安全事故，在政府的白帽行动中，发现了误暴露在公网的konga，通过发送post请求，能够成功注册管理员进而管理所有规则。我试过两个版本都成功

postman创建.jpg

屏蔽公网访问避免95%的安全问题！

近一周安全问题频发，明显是针对性的精准渗透行为，钓鱼邮件、ERP服务器被拿下、线上kubernetes集群被拿到部分权限成功部署反弹shell。从入侵轨迹来看，未做破坏但有明显的扫描内网行为，对方对安全、运维都有比较深入的了解。与政府组织的“磐石行动”时间点吻合，推测是对我们的白帽行为
云安全中心提醒还是很精准的，以容器中被运行反弹shell为例。从kubernetes审计日志，“黑客”使用被泄露账号通过暴露在公网的k8s api server进来，在进行了一系列尝试后发现有A命名空间的管理权限，具有onl的namespace 权限，查看了cm发现免密登陆，推送镜像，创建deployment ，镜像中传输数据。已关服务，wifi api server取消外网监听

过程中用到的命令
pstree -p -a #查看
docker inspect #查看pod信息
docker run -it --entrypoint /bin/sh xxxxx #启动疑似容器
查看kubernetes 审计日志
kubernetes get rolebinding -n xxx -o yaml

最新战报：
内部员工已中招，对方社工客服运行了可执行文件，导致在OA内向其他用户发送病毒文件
ERP服务器沦陷，有扫描内网的行为
CRM服务器中毒
🏳️

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5