季兴 发布的文章

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

在一次常态的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

微信截图_20220719211616.png
黄色为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 ,重启浏览器.解决
微信截图_20220717122206.png

在家隔离的2个多月,重新捡起了运维开发工作

已实现or改进:

  1. 物理资产自动采集,通过DRF上报
  2. 通知功能*
  3. 长周期任务异步
  4. 密码管理
  5. 密码操作审计
  6. 使用了新的前端模板,耳目一新

待实现or改进

  1. 异步任务通知
  2. DASHBOARD功能
  3. 资产要关联应用,应用管理
  4. kubernetes的报表功能
  5. 权限管理

附几张效果图
资产管理.png审计管理.png模态对话框js.png

今天在排错时遇到个奇怪的现象,相同名称添加多条A记录超过512字节时,就会影响部分递归DNS的记录同步。
测试域名 liyang.sunmi.com 添加了36条A记录,大小610字节
A记录.jpg

必现部分递归DNS无法更新、解析失败
解析失败.jpg

1.查阅了DNS的RFC1035,udp包有512字节的长度限制,超出部份会被截断 原文
2.超过限制后使用tcp协议进行解析
3.公共DNS中,只有114.114.114.114会把超长结果截断在509字节,其他DNS都会原样返回

疫情在家一个月了,记录一下

  1. api网关调研,测了限流、认证、更改返回内容等插件,就是简化的nginx,以往改配置文件的事,现在应用插件。https://www.yuque.com/books/share/44e4c02e-5ffb-43cc-ab51-ac2bf885913a/ssrwps
  2. apisix初体验,看到腾讯内部有些业务使用,从他们测试结果来看性能有较大提升,而且是apache基金会项目,不至于烂尾
  3. 18年搞的运维系统做了部分功能迭代,升级到django4.0。登录功能从装饰器改为中间件,搞清楚了ModelForm。深觉自己不太适合开发,不能静下心思搞
  4. excalidraw神器,用够了一板一眼的visio,返璞归真。附一张成品

全球化+WPS图片打印.jpg

近期接到个古怪需求,历史原因有部分设备在代码中访问废弃接口uat.api.xxx.com,现有接口为 api.uat.xxx.com(顺序变化)。老设备升级rom版本较繁琐,网关不想动了,在外侧加了台nginx转发

# 通过rewrite301跳转
server {
    listen 80;
    server_name uat.api.xxx.com;

    location / {
        root /usr/share/nginx/html;
        if ( $host ~* uat.api.xxx.com ){
            rewrite .* http://api.uat.xxx.com$request_uri permanent;
        }

    }

}

# 方法2
在location中加,更优
    proxy_set_header Host api.uat.xxx.com;
    proxy_pass https://api.uat.xxx.com;

背景:海外用户投诉我们一个边缘功能失效,定位到程序假死。随着各种复盘会,把这件小事无限放大。
难点:探针改造复杂,尽管已经有了基础的http接口检测,但针对服务连接各种中间件等场景无法一一覆盖
在研发根治此问题前,使用“熔断”来降低此类故障的影响

熔断,是创建弹性微服务应用程序的重要模式。熔断能够使您的应用程序具备应对来自故障、潜在峰值和其他未知网络因素影响的能力

中间方案,通过网关日志,假死会有504超时的信息,SLS已支持触发各种钩子,逐个重启故障服务的pod

  • 优点:配置相对简单,覆盖面广
  • 缺点:按照监控的频率间隔,有几分钟延迟

更优istio方案,使用VirtualService配合DestinationRule对超时或者错误重试,并将故障pod踢出

  • 优点:侦测更快,发现故障后立即生效
  • 缺点:局部配置,所有服务都要写一遍

环境:

  • kubernetes v1.18.20
  • istio 1.10.3
  • 后端服务flask,代码如下,sleep5秒用于模拟超时
from flask import Flask
import time

app = Flask(__name__)


@app.route("/", methods=["GET"])
def index():
    time.sleep(5)
    return "Hello World Pyvo 2!"

istio中配置如下

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: backend-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"

---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: vs-backend-flask
spec:
  hosts:
  - "*"
  gateways:
  - backend-gateway
  http:
  - match:
    - uri:
        prefix: /flask
    rewrite:
      uri: /
    route:
    - destination:
        host: backend-flask
        port:
          number: 80
    retries:
      attempts: 3
      perTryTimeout: 2s

---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: dr-backend-flask
spec:
  host: backend-flask
  trafficPolicy:
    outlierDetection:
      consecutive5xxErrors: 1
      interval: 10s
      baseEjectionTime: 30s

熔断.jpg
效果如图,访问出现上游服务超时错误后,在30秒内不会再调度到故障节点