一、一直自诩是柔性的管理者，讲情怀、谈感情、不涉及原则问题都是友善提醒。谈谈近期遇到的一位伙伴小王，他是一个月前加入，原本负责网络的同学匆忙离开。积压的问题越来越多，小王在上手之后不太能搞定，我经常提醒不要成为“沟通黑洞”，发包过去一声不吭。无奈，离开
二、会议效率降低怪象
对待故障要敬畏，要追根因。惩罚机制要恰到好处，避免大家不敢动，更应该把故障看成一份宝贵的经验包；对待历史问题不逃避。我反对把责任甩的一干二净。
正因为我这种“大包大揽”的责任感，质量部门经常莫名其妙定责给我。前天一次故障，其部门自行维护的服务单点宕机，事故前多次反复提醒仍不整改。坑惨一波又一波接任者
三、越来越像项目经理，技术上已得不到成长，离我的“专家”目标渐远
遇到一种场景，某前端服务部署在kubernetes中，有偶发的服务故障。想着健康探针重启就行，忽然想到，如果是重要的线上服务宕机，不查出来心里憋得慌，怎么让服务恢复的同时又能保留现场呢
改当前pod的标签，这样deployment会认为副本消失，自动创建。完美实现老容器保留，业务也及时恢复
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
最近忙于处理安全事故，在政府的白帽行动中，发现了误暴露在公网的konga，通过发送post请求，能够成功注册管理员进而管理所有规则。我试过两个版本都成功
屏蔽公网访问避免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服务器中毒
🏳️
在一次常态的EMQ集群巡检时发现，有非周期的CPU超过80%毛刺，按照预案新增了如下防火墙规则限流（此规则验证过多次），当天为了方便使用&&将多行语句连接成一行。执行后发现连接数立刻下降，通过监控发现大量连接都变成了non-establish
# 清空INPUT链，标记RELATED,ESTABLISHED，对超出限速的REJECT
iptables -F INPUT
iptables -t filter -A INPUT -p tcp -m multiport -m state --dport 1883,8883 --state RELATED,ESTABLISHED -j ACCEPT
iptables -t filter -A INPUT -p tcp -m multiport -m state -m limit --dport 1883,8883 --limit 200/second --limit-burst 600 --state NEW -j ACCEPT
iptables -t filter -A INPUT -p tcp -m multiport --dport 1883,8883 -j REJECT --reject-with tcp-reset
service iptables save
# 当天为批量执行，简化为一条
iptables -F INPUT && iptables -t filter -A INPUT -p tcp -m multiport -m state --dport 1883,8883 --state RELATED,ESTABLISHED -j ACCEPT && iptables -t filter -A INPUT -p tcp -m multiport -m state -m limit --dport 1883,8883 --limit 200/second --limit-burst 600 --state NEW -j ACCEPT && iptables -t filter -A INPUT -p tcp -m multiport --dport 1883,8883 -j REJECT --reject-with tcp-reset && service iptables save
黄色为non-establish
经排查，在执行标记流量 --state RELATED,ESTABLISHED 会将连接当前状态写入系统内核文件 /proc/net/nf_conntrack，当时每台机器均有100000左右连接，写入磁盘需要2-3秒。用&&将命令合并=没有间隔马上执行下条命令，未写完的连接未标记完成，命中了第三条REJECT tcpreset。陷入取消限速集群扛不住，增加限速丢弃连接死循环，通过SLB限速后，原厂删除集群信息后重建恢复。结论：iptables标记流量需要考虑写盘IO，执行时慢一些
家中台式机win10,连接的小爱蓝牙音响。使用中有个小bug查了好久，当使用chrome播放视频关闭标签页后，电脑声音消失，必须打开蓝牙重新连接。
今天偶然搜到 chrome浏览器 输入: chrome://flags/#hardware-media-key-handling 把Hardware Media Key Handling设置成disable ,重启浏览器.解决
在家隔离的2个多月，重新捡起了运维开发工作
已实现or改进：
待实现or改进
附几张效果图
今天在排错时遇到个奇怪的现象，相同名称添加多条A记录超过512字节时，就会影响部分递归DNS的记录同步。
测试域名 liyang.sunmi.com 添加了36条A记录，大小610字节
必现部分递归DNS无法更新、解析失败
1.查阅了DNS的RFC1035，udp包有512字节的长度限制，超出部份会被截断 原文
2.超过限制后使用tcp协议进行解析
3.公共DNS中，只有114.114.114.114会把超长结果截断在509字节，其他DNS都会原样返回
疫情在家一个月了，记录一下
