个人对K8s的安全做个随笔总结

  Kubernetes，简称K8s，相信看这篇文章的朋友，应该都不会太陌生，最近正好研究了一下这个东西，根据网上和自己的一些研究，简单对这个东西的安全性以及可能存在的安全问题，进行个总结。

一 K8s 架构

整体的架构如下图所示，

K8s 整体可以分为控制节点（Master）与工作节点（Node)两部分。Master 节点又包括如下组件：apiserver，etcd，scheduler，contorller-manager。各个组件的功能里就不作太多介绍详情可以参考K8s各组件介绍：

https://kubernetes.io/zh-cn/docs/concepts/overview/components/

二 K8s常见的安全问题

2.1 未授权访问

  这是笔者认为最不应该或者最愚蠢的错误类型，包括且不限于因为各种五花八门的弱口令，配置错误导致的apiserver，kubectl，etcd等可以直接访问，或者得通过各种方式拿到到kubeconfig的配置文件，这样的后果便是使得整个K8集群彻底沦陷。

例如kubectl，默认情况下访问是未授权状态：

但如果修改了某个节点的config.yaml配置文件，将匿名认证打开：

再次访问则会出现信息泄露：

甚至可以在对应的宿主机的容器中进行命令执行：

因此需要尽量在日常的应用运维中犯下类似这样的错误。常见的组件对应的端口如下：

1. K8S组件	默认端口
   kube-apiserver	6443
   kubelet	10250
   etcd	2379 , 2380
   kube-proxy	10256
   kube-controller-manager	10252
   kube-scheduler	10251

2. 
   

2.2 特权容器

  这也是运维中可能出现的情况，如下图配置，在运维过程中为了某种原因，把容器配置为特权模式:

  这样，万一这个容器失陷，便可以通过挂载宿主机目录，操作宿主机的文件，例如/root/.ssh/authorized_keys, crontab 等等，达到控制宿主机，进行逃逸。

  除此之外，容器的一些特殊能力的赋予也需要慎重，例如CAP_SYS_PTRACE，便是拥有着追踪进程的能力，这样有可能通过strace等命令捕获SSH密码：

  CAP_SYS_ADMIN，允许执行系统管理任务例如加载或卸载文件系统，基本等同于特权容器，也需要谨慎赋予。

其他容器能力介绍可以使用命令 man capabilities 进行参考。

2.3 挂载宿主机的重要目录

  与2.2类似，尽量不要挂载宿主机的重要目录，例如/root ,/etc ,/porc等目录，毕竟这些目录都存有系统的重要信息，如果攻击者进入到容器内，便可能通过操作某些文件，达到容器逃逸的目的。

2.4 容器自身安全

  因为容器本身与宿主机共享内核，那么便可以通过内核漏洞进入宿主机的namespace，从而达到逃逸的目的，最典型的应该算脏牛漏洞（CVE-2016-5195）。

2.5 容器内应用安全

  容器内的应用本身也存在各种安全问题，例如命令执行，SQL注入，文件上传，rce等等，与传统安全一致，所以这里就不用再进行展开了。当然，如果通过某种漏洞进入到应用pod中，在没有网络隔离的情况下，便可以面向整个K8S集群进行进一步攻击了。

2.6 容器镜像安全

   这也比较容易理解，例如使用了有漏洞的镜像，或者使用了被投毒的镜像，或者带有后门的镜像等等类似供应链攻击。

2.7 K8s本身组件的漏洞及第三方组件的漏洞

  K8s本身拥有着非常众多的组件，因此非常有可能因为某些组件出现漏洞从而导致整个集群沦陷的可能。

2.8 一些管理平台

  除了官方的Dashborad外，还有很多的K8s管理平台，例如Rancher ,KubeCube，KubeSphere 等等，这些平台除了未授权访问，弱口令外，本身也可能存在其他漏洞，一旦出现安全问题，也可能导致整个集群失陷。

2.9  其他问题

  例如某些功能，本意是想为运维提供方便，但被发现，可以利用控制集群的情况，类似system函数。

三  关于K8s的一些安全实践

  个人觉得，K8s使用了这么长时间，只要做到了安全里边的最小授权原则，做好网络控制与准入，做好资源的用量规划，除pod应用与自身组件产生的安全问题外，基本不会出现太多的安全问题。当然，审计与安全工具也十分重要，例如我之前推荐的两款工具Falco—云原生安全守护者，

NeuVector----功能丰富且强大的容器安全开源软件，大到整体集群，小到单个容器，都可以进行监控。

四 一点感悟

  本文参考了腾讯安全的《红蓝对抗中的云原生漏洞挖掘及利用实录》（https://security.tencent.com/index.php/blog/msg/183）这篇文章，这篇文章发表于2021年三月，感概腾对K8s的研究领先了我3年半。这篇文章一直存在我的收藏里。从最初的完全懵逼到现在可以看懂，也欣慰自己在K8s方面也有了一点点进步，也终于可以可以把这个收藏的文章画个圈了。

阅读原文

跳转微信打开

如果说之前的NeuVector是从宏观上看容器的安全，那么Falco便是从容器，主机的角度出发

一 Faclo 介绍

      在云原生应用和容器化环境中，安全性成为了一个至关重要的关注点。随着容器技术的普及和应用的快速发展，容器环境中的安全挑战也日益增加。为了保护应用程序和数据免受潜在威胁，开发者和运维团队需要有效的安全工具和机制。Falco是一个开源的云原生安全工具，通过实时监控和检测容器、主机和Kubernetes集群中的安全事件，为云原生环境提供智能的守护功能。Falco 可以监测调用 Linux 系统调用的行为，并根据其不同的调用、参数及调用进程的属性发出警告。例如，Falco 可轻松检测：

•      容器内运行的 Shell

•      服务器进程产生意外类型的子进程

•      敏感文件读取（如 /etc/shadow）

•      非设备文件写入至 /dev

•      系统的标准二进制文件（如 ls）产生出站流量等

  其原理如下图所示：

二FALCO 安装

Falco的安装方式相对比较简单，单机版安装方式可以参考：https://falco.org/docs/getting-started/falco-linux-quickstart/

  Falco 单机规则配置文件为自带的falco_rules.yaml，以及可以用于自定义规则的falco_rules.local.yaml文件构成，如果在K8S中使用自定义的规则文件，需要创建configmap 指定。

   Falco的配置规则由三大部分组成分别为：Lists,Macros,以及Rules

•      Lists: 项目的命名集合，可以用于macros、rule甚至其他lists中，由list及items两部分构成，例如定义一个user_lists:

• 
  

• - list: user_lists 

•    items: [root,lion,admin,nginx,public]

•  

• Macros:可以在里边定义一些规则片段，方便在Rules中重复使用，例如判断用户在上面的（user_lists）中，可以使用上面的list，由macro

• 和condition 组成，conditi顾名思义，是各种表达条件例如定义一个用户在user_lists中的条件:

• - macro：user_in_user_lists

•    condition: user.name in (user_lists)

• 更多的表达式可以参考 https://falco.org/docs/rules/conditions/

• Rules: 最重要的部分，生成告警的规则，由下面几个部分组成：

•       rule: 规则名字

•       desc: 规则描述

•       condition：定义具体的规则内容，也可以使用上面的宏

•       exceptions: 排除的条件

•       output：输出的内容

•       priority：报警的级别

•       tags：规则的分类标签

• 例如：当user_lists 中的用户执行了frp 便进行报警，输出用户名，进程号，进程id完整的规则为：

• 
  

• -list: user_lists

•   items: [root,lion,admin,nginx,public]

• -macro：user_in_user_lists

•  condition: user.name in (user_lists)

• -rule: some_one_open_frp

• condition：user_in_user_list and proc.name contains “frp”

• output: "Detected frp process (user=%user.name command=%proc.cmdline pid=%proc.pid)" 

• 这里说明一下，falco有着非常丰富的可以作为条件判断源（condition）和输出（output）的字段，例如user.name，proc.pid 等等，大致分为：evt（事件类）例如:evt.source

• ，process（进程类）例如 proc.name

• ，user（用户类）例如 user.name

• ，group（组类）例如 group.name

• ，container（容器类）例如 container.name

• ，fd（文件类）例如 fd.filename ,fd.cip

• ，syslog例如syslog.severity

• ，k8s ,例如：k8s.pod.name 等等，完整列表可以参考https://falco.org/docs/reference/rules/supported-fields/。

• 下面就分别在单机及k8s中分别挑几个案例进行演示

• 
  

• 3.1 FALCO 单机

• 判断主机有外连行为：

• 规则为：

• 

当发现主机外联时会有如下告警：

这里生成了一个cs的后门，通过strace跟踪ip

在Falco中生成的告警：

• Webshell 或 其他文件访问敏感文件 例如/etc/shadow,规则为：

  

产生的告警为：

• 检测frp规则：

产生的告警为：

3.2 FALCO k8s

    在k8s中，falco 作为daemonset启动，利用configmap将自定义规则加入:

同样的，当一个容器访问了敏感文件:

产生的告警为：

检测当一个特权容器启动规则为：

对应告警：

Falco支持将告警通过syslog，web，文件等发送，这里我将falco的告警转发至es中，并用kibana 进行了展示，由于测试关系我没有对内容字段进行进一步拆解。

四 Faloc检测ebpf 后门

现在有很多关于ebpf的研究，我曾试着想利用falco发现ebpf后门，不过，经过测试，falco仅仅发现了系统调用了bpf函数,如下图所示，但是并未找到如何配置，让其产生告警。希望有兴趣的读者可以进一步进行研究。

五 与ossec 比较

  在我的《互联网安全建设从0到1》这本书中，介绍了一款主机ids-ossec，这里可以简单的将两个软件进行比较，ossec的告警更多是依赖log进行，对log进行decoder，从而匹配规则，进而产生告警。而falco本身依赖的是系统的系统调用捕获，因此可以更加深度的对系统行为进行分析，而ossec，对容器方面支持的不够完善，而这正是falco的优势，当然ossec 可以进行集中管理，这点上falco还是需要运维软件进行控制，在这点上，不如ossec。

六 结语

   以上便是对falco的一些简单介绍，而falco的规则，有了gpt后，便更加容易编写了，很多规则可以通过询问gpt进行编写了，这很好的降低了编写规则的难度，但依然需要进行测试，毕竟有的时候gpt还是会一本正经的胡说八道。另外毕竟falco在这里仅仅是一个工具，想要真正发挥它的作用，还需要在日常工作中不断的打磨，需要对falco的资源占用情况，告警准确情况，进行不断的了解，改进这又变成了运营问题。同样的，这个软件想要发挥最大的价值，还需要考虑到其在公司业务系统的覆盖率，毕竟工程化一个软件，比研究一个软件的功能要难很多。

阅读原文

跳转微信打开

​

阅读原文

跳转微信打开

这个号叫安全防御，也应该分享一点个人在安全防御方面的一些心得。

  这个号叫安全防御，也应该分享一点个人在安全防御方面的一些心得。作为在攻防对抗的防守方，个人觉得有点类似对一个城池进行防守一样。而防守的目的，便是识别异常的能力。当然，这种能力不是与生俱来的，需要经过大量的事前准备，知识储备，应急演练等等才可以形成。在我之前的书中，以知己，知彼的角度写了一些心得，这次笔者再从平台（知己），技术（知彼），以及运营这几个纬度进行。

一 平台层面（知己）：

 工欲善其事，必先利其器。这里的平台是指搭建防御体系的产品（或者工具）的能力，因为对于防御者来说，并没有任何银弹可以使用，指望着一招鲜吃遍天的想法基本上来说是不现实的，因此好的防御应该是层次型的，或者立体式的防守。每层可以互相弥补不足，协同完成发现异常的过程。

如上图所示，把一个传统IDC 分为网络层，业务层(HTTP),主机层，以及周边部分，在不同的层上，使用不同的技术进行监控。

1 网络层

笔者认为是眼睛的作用，这里在笔者之前的书中已经介绍过，这里不多做介绍。可以使用的开源检测工具例如suricata等。当然如果有能力做一个监控平台，那么就要考验开发能力和工程化的能力了，毕竟不同于做工具能使用即可的思路，需要考虑稳定性，在大流量下的可扩展性，操作的简易性，甚至对于误报，漏报，策略的准确性等等都要仔细考虑进去。

例如笔者这套自行开发的监控系统，基本上就算满足了上面的需要。另外讨论比较多的问题是关于流量的加密问题，其实主要分为两个部分，可解密场景，即业务访问，这个场景，因为证书是自己这边的，可以通过在抓取ssl卸载节点后的流量即可解决。另外一个是无法解密的情况，类似木马，webshell之类。这种情况，可能就需要下一个层面主机层进行协同了。

2 主机层

针对网络层无法了解具体主机行为的这一缺陷，就可以在主机层进行进一步的布防，例如hids，xdr产品等等。这些系统可以针对主机文件，进程，端口变化，系统日志等信息进行收集并加以分析。另外现在的hids,或xdr产品，也有资产收集的功能，可以协助防守方了解资产情况。现在各种类型的hids已经层出不穷，例如笔者书里花了不少篇幅介绍的ossec,或者一些商业软件等等。

3 周边部分

可布防的区域除了主机，网络层外，还可以在数据库层，端口，DNS,堡垒机，vpn等众多地方进行监控，覆盖的范围越广，发现异常的概率也就越高，考验的其实也就是资产识别的能力。

4关于资产识别

笔者认为这是在进行安全防御中非常重要的环节，这就好比在守城中，如果将领对自己一方的人员，粮草，环境都不了解，那结果，基本上就可想而知了。笔者在书中用自创的圆圈理论已经阐述过，而且，公司越是大，资产识别越是一个苦差事，但不能说因为苦，就放弃这项工作，而相反，这算是考验安全能力的最基本功，先不说很多攻击都是从未识别到的资产中得手的情况，单说攻防对抗最重要的环节之一就是时间，如果监控到有问题，第一时间可以联系到相关业务的负责人，那也可能会在劣势中及时止损，争得时间。因此对于资产识别的重要性已经不言而喻了。当然对资产识别的颗粒度越细，那在监控中或对抗中越可以取得时间上的优势。而对于容器的使用，笔者推荐了一款个人认为比较出色的工具：neuvector，具体可以参考之前的文章《NeuVector ---功能丰富且强大的容器安全开源软件》。

二 技术层面（知彼）

 攻防对抗，本身来说就是一个非常有技术挑战的事情，因为我们的对手是同样有着各种思想，不同目的人，因此笔者认为，不真正经历过一线的攻防对抗，提出来的策略基本上也就只能是纸上谈兵。而在对抗过程中能够灵活与变通，往往会是制胜的关键。但对于防守方来说，这两点更应该是日常积累才可能做到的，例如对于防守方来说，除了要了解攻击者可能使用的技术，工具外，还可能需要了解各种漏洞产生的原理，利用方式，甚至是系统或者语言等特性，因为在现实中可能就是因为对某种特性不熟悉，而导致被利用的情况发生。例如笔者能想到的基于资源的约束委派攻击便是利用了msDS-AllowedToActOnBehalfOfOtherIdentity这一特性，通过伪造管理员申请ticket的方式进行的。再比如webshell中，利用了evel，system函数可以执行系统命令等等。

再例如反弹shell这个场景，如下图所示（ps：此图非本人原创，来源于AnonySec@安恒《实战中内网穿透的打法》）

那么针对这么多情景，就需要有针对性的梳理和检验出来可以检测出的规则

而这对于防守方来说，便算是日常积累的事情，webshell的检测也是同理：

除此之外，例如一些特殊日志的产生，如下图所示：

（异常情况下的命令执行，执行账户:机器名）

                  （正常情况下的管理员命令执行，执行账户:普通用户或管理员）

也是可能产生异常行为，或攻击方攻击成功的标志，而作为防御方，则需要把对应的日志提炼成相应的规则。另外笔者在自己的书里第八章安全监控中也介绍了需要了解的其他攻击手段的技术，这里就不再赘述。

三 运营

有了平台，也有了技术，但最终的结果还需要人为做最终决断，因此，对于策略的运营也是非常重要的一环。而目前来说，笔者认为的主要手段有以下几种：

1 关键字监控：

这种方式是应用最广泛的方式，只要了解攻击中的任何特征，便可以建立监控规则，对于已知攻击来说，是最有效的检测手段。

2 频率监控：

用于弥补未知攻击的一种手段，例如极少数访问，或者某ip突发访问某url等情况。通过建立正常基线的方式，发现可能的异常行为，并进行判断。

3 行为分析：

 通过发现异常行为，或设定一些场景，进而发现攻击的手段。例如非业务时间访问、不该有的访问或者端口开方等等。

4 机器学习：

频率监控的升级版本，目前来说针对DGA识别比较有效，（笔者用来识别公交车的图像识别也比较成功:P） 也可以先对异常进行第一步筛查，减少告警后，再使用人工进行二次判断，进而不断反馈规则经验，形成闭环，使报警更加准确。

5 关联分析：

笔者认为告警的最高境界，并一直研究的方向，（怎奈水平有限，突破很少）通过收集各个系统之间的日志（报警，行为）从而产生非常准确的告警，并可以把攻击路径完整识别。

除此之外，针对告警的运营，笔者认为还有几点也非常重要：

策略的优化：

  尽量将做到告警的准确化，力争每条告警都是准确的，毕竟动辄999+的告警，再有责任心的人耐心也会终将被耗尽，因此个人认为，作为防御者，应该把最大的精力用在规则的准确化上。

监控覆盖面：

  就如同开篇介绍的，防守是个全方面的工作，任何一个细小的疏漏，都可能导致千里之堤，毁于蚁穴。因此对防守区域的了解，对资产的了解，对监控覆盖面的了解，便是能否做好防御的一个因素，更不应出现马奇诺防线这种情况发生。但在部署agent的情况下，又需要对自己的agent，系统有一定的了解，不能因此而影响业务，这又一次回到了技术领域的范畴。

责任心/好奇心：

  笔者认为，这个是做安全工作，尤其是前者是防御工作的重要素质，笔者见过很多攻击事件，告警明明已经产生，但是由于没人去看，导致攻击的手，这非常令人惋惜。另外，笔者觉得很多攻击都是非常“朴素”的，不需要什么0day，只用一个可能n年前已知的漏洞，一个简单的弱口令，普通的再不能普通的bash反弹，便打穿了整个防御体系。因此需要有足够的责任心，要从告警（哪怕是海量）中抽丝拨茧，发现问题。这里笔者有个非常深刻的感触，就是lake2之前说的一个案例，他们可以从一个告警中发现cve，个人觉得这应该算防御的一个最高境界了，而笔者个人觉得，一般公司做到这样固然好，但是没有那么强的技术能力，从告警中能识别到攻击，也已然非常不错了 。

最后，笔者还认为，既然建立了监控体系，那么就应该多用，因为只有使用了，才可以从中发现问题与不足，从而进一步完善系统与策略，毕竟只有平时像战时，才能战时像平时。

以上便是个人的一点点关于安全防御的粗浅理解，在这条路上，个人觉得还是初学者，还有很长的路要走，也有很多经验需要学习，希望可以抛砖引玉，共同学习。

阅读原文

跳转微信打开

应邀工联大讲堂聊聊安全防御建设

跳转微信打开

跟好友301聊聊企业安全建设，从甲乙两方的视角，也看看乙方是怎么看这个事情的

阅读原文

跳转微信打开

好久没有遇到值得推荐的系统了，NeuVector可以称得上是一款开源容器安全解决方案了。

  随着容器的广泛应用，容器的安全问题，也需要关注。例如容器中引用的组件，容器之间的隔离，甚至容器中的进程等等。因此对容器的管理，也会在安全防御中起着至关重要的影响，正好笔者无意中发现了NeuVector这款开源软件，在测试中发现，确实是一个功能丰富且强大的容器开源软件。

一 安装

  关于NeuVector的安装，可以参考官方文档：https://open-docs.neuvector.com/deploying/kubernetes，或者这篇文章：《云原生安全平台 NeuVector 部署》，笔者在部署中遇到了一点点权限问题,不过按照相关提示设置权限也完成了安装，总体来说，安装还是比较容易的。安装完成后登录即可。

二 主要功能介绍

  NeuVector的功能，也可以参考官方文档，笔者仅仅测试了几个功能，效果还是比较不错的

2.1 检测出入口暴露风险

  该功能主要可以检测出对外暴露的pod，以特权或root运行的POD等。例如我新建一个influxdbPOD，内容如下图，网络为hostNetwork，外部可以之间访问到fnfluxdb的8086端口：

此时NeuVector便识别出该POD端口可以对外访问，如下图所示：

再建立个使用特权容器运行的POD，如下图所示：

在下图中，也可以看到已经识别到使用了特权模式

2.2 WAF功能及网络可视化功能

  网络可视化功能可以方便之间观察各组件之间的网络连接情况，可以查看会话，甚至进行数据包抓捕，极大的方便了管理。而WAF功能更是可以给组件提供保护，不过目前只支持正则表达式的模式。在下图中，使用test-con1及test-web1进行测试，在未连接前如下图所示：

在test-con1中访问test-web1

可以看到，连接的情况：

这时，配置WAF，并将WAF规则引用于test-web1中，内容为：若URL包含lion则进行后续处理

此时再次访问test-web，并在url中包含关键字lion

可以看到，连线变成了黄色,并产生了安全事件的告警：

同时，可以在安全事件中的显示数据包中看到对应的内容：

但此时仍可以正常访问test-web1的原因是因为test-web1处于学习（或者监控）模式，若将该模式改为保护模式,则无法再进行访问，WAF功能已经拦截，并产生拦截告警，同时，网络活动中可以看到连线已经变成红色。

2.3 准入控制

  在生产环境中，往往需要满足一定的安全条件才可以进行相关的发布操作，因此可以使用准入控制这一功能完成上述需求。这里以不可以以特权模式运行pod为例：

  并将状态设为启用，并将模式改为保护：

此时再次建立另一个特权模式的POD ，便会提示无法创建，同时也会产生对应告警，如下图：

2.4 其他功能

  除以上功能外，NeuVector还可以学习到容器中的网络连接，进程等相关信息，可以针对这些信息，设置相关的规则，进行后续的处理。

例如识别进程信息：

识别网络规则：

除此之外，还可以对容器/系统/集群/代码仓库进行扫描，

还可以进行合规性的扫描：

当然，以上的展示的只是笔者个人关注一部分，如果读者感兴趣，可以继续深入研究。

三 总结

  通过上述的演示，笔者认为NeuVector确实可以解决实际生产中的容器安全问题，不过笔者也仅仅也是在实验环境中使用，在生产环境中，笔者了解到两个可能存在隐患的地方：

1 针对系统的漏洞扫描，是需要将整个系统转入内存中进行，因此如果POD过大，可能会对系统产生一定的资源消耗问题。

2 WAF,DLP 等功能，会对应用产生性能影响，如果配置错误，很可能也会演变为安全事故，因此这些功能也应该谨慎使用。

  综上所述，个人觉得，这款软件确实可以称得上是一个容器安全解决方案了，值得推荐。不过这仅仅是一个工具，好比一把剑，普通人，只能瞎甩，而令狐冲可以使出独孤九剑，因此重要的更是使用的人。

阅读原文

跳转微信打开

本文主要简单说明 Kerberos 协议的认证过程，然后介绍了 MS14-068 的漏洞原理和利用过程，同时

本文主要简单说明 Kerberos 协议的认证过程，然后介绍了 MS14-068 的漏洞原理和利用过程，同时结合了漏洞利用产生的事件日志和攻击流量进行分析。

Kerberos

Kerberos 是 MIT 提出的一种网络身份验证协议，它通过密钥加密技术验证用户或主机的身份。Kerberos 默认使用 UDP 端口88。

Windows 使用 Kerberos 作为其默认身份验证方法。如果将客户端加入 Windows 域，则说明将启用 Kerberos 作为从该客户端到 Windows 域中的服务以及与该域具有信任关系的所有域的身份验证的默认协议。但需要注意的是，如果客户端或服务端或两者都未加入域，Windows 将改为NTLM提供身份验证。

先看看Kerberos的角色功能。

• Domain Controller (DC)：域控制器。

• Key Distribution Center (KDC)：秘钥分发中心，默认安装在域控里，包括 AS 和 TGS。

• Authentication Service (AS)：身份验证服务，用于 KDC 对 Client 认证。

• Ticket Grantng Service (TGS)：票据授予服务，用于 KDC 对通过 AS 发送给 Client 的 TGT 换取 ST(Service Ticket)。

• Active Directory (AD)：活动目录，用于存储用户、用户组、域相关的信息。

• Privilege Attribute Certificate (PAC)：特权属性证书，用于验证是否有服务访问权限。

再来看看看认证流程。

1. AS REQ
   客户端用户 Client 向 KDC 发送一条消息 AS REQ 进行预验证，其中消息包含了 Client 密码 HASH 加密的时间戳、Client-info、网络地址等。

2. AS REP
   KDC 请求AD查询Client，若存在该用户则用其密码 HASH 解密 AS REQ 中的时间戳，若解密成功且时间戳在5分钟之内，则验证成功。AS 会返回 Sessionkey-AS (经过 Client 密码 HASH 加密)和 TGT (包含经 KRBTGT HASH 加密的 Sessionkey-AS 和时间戳等信息，因此 TGT 无法被 Client 解密解析)。

3. TGS REQ
   Client 用自身密码解密 Sessionkey-AS，再用 Sessionkey-AS 加密时间戳和 Client-info 作为其中一部分内容，和 TGT 一起发送给 KDC 中的 TGS 以认购换取 ST 票据。

4. TGS REP
   TGS 首先自检是否存在 Client 所请求的服务，若存在，则使用 KRBTGT 密码 HASH 解密 TGT，解密得到 Sessionkey-AS 、时间戳、Client-info。然后再用这个 Sessionkey-AS 解密步骤 3 中的一部分内容，得到第二份时间戳和 Client-info，两者进行比较，有效时间范围，网络地址是否相同。认证成功后，TGS 会生成用 Sessionkey-AS 加密的 Sessionkey-TGS 和 Server 密码 HASH 加密的 Sessionkey-TGS (即 ST 票据)返回给 Client。

5. AP REQ
   Client 先用之前本地缓存的 Sessionkey-AS 解密得到 Sessionkey-TGS。当 Client 需要访问 Server 上的服务时，Client 使用 Sessionkey-TGS 加密时间戳等信息，和 ST 一起发送给 Server。

6. AP REP
   Server 使用自己密码 HASH 解密 ST 得到 Session-Key TGS，然后再解密得到时间戳等信息，与 ST 的时间戳和 Client-info 等分别进行验证对比。

这里需要提醒的是，一般地，有些服务并不需要 PAC 验证，该服务会接受 TGS 票证中的所有数据，而不与 DC 通信。

PAC

PAC 即 Privilege Attribute Certificate(特权属性证书)，它是 Kerberos 票证的扩展。需要注意的是，Kerberos 以上认证过程说明了客户端是否为真实有效用户，但未声明该用户是否具有访问目标服务的权限，因为在域中不同权限的用户所能访问的资源是不同，而 PAC 解决了访问权限问题。

PAC 包含了用户或组安全标识符 (SID)。当用户在 AD 域中进行身份验证时，域控制器会将此信息添加到 Kerberos 票证中。当用户使用 Kerberos 票证访问其他服务进行身份验证时，可以读取 PAC 来确认其权限级别，而无需联系域控制器来查询该信息。

继续完善上面的认证流程。

• PAC Validation Request
  PAC 是在 AS REQ 后由 KDC 生成的，返回给 Client 的 TGT 包含了 PAC。CLient 与 KDC 完成认证以后，此时需要访问 Server 所提供的某项服务，Sever 会拿着 PAC 去请求 DC 查询 Client 是否有访问权限。

• PAC Validation Response
  DC 对 PAC 进行解密，通过 PAC 中的 SID 判断 Client 的用户组信息、用户权限等信息，然后将结果返回给 Server，Server 再将此信息与域用户请求的服务资源的 ACL 进行对比，最后决定是否给 Client 提供相关的服务。通过认证后 Server 将返回最终的 AP-REP 并与 Client 建立通信。

但需要说明的是，有些服务并不需要 PAC 验证，该服务会接受 TGS 票证中的所有数据，而不与 DC 通信，而银票攻击则也正利用了这个条件。

MS14-068

MS14-068 是位于 kdcsvc.dll 域控制器的 KDC 服务中的漏洞，它允许经过身份验证的用户在其获得的票证 TGT 中伪造插入任意的 PAC 。普通域用户可以通过呈现改变了的 PAC 的 TGT 来伪造票据获得管理员权限。

利用过程

域测试环境：

• DC
  系统：Windows Server 2008 R2 x64
  主机名：win08
  地址：192.168.1.8
  域名：bbk.lab
  系统信息：无 KB3011780 补丁

• 域成员机器
  系统：Windows 7 x64
  主机名：pc
  地址：192.168.1.7
  域普通账户：user1

• exp：Pykek工具包的 ms14-068.py 编译后的可执行文件exe

漏洞利用前，收集账户信息，查看当前权限。

使用 exp 在当前目录路径下生成一个高权限的 TGT 票据

mimikatz 清楚内存中票据信息，将 TGT 票据注入到内存。

注入成功，dir查看当前权限，可以看到已经提权成功。

漏洞成因与流量分析

以下通过 exp 结合流量分析和学习 MS14-068 漏洞原理。对 exp 设置断点 debug，并使用大鲨鱼抓包。

这里的参数pac_request为 False，说明在构建 AS REQ 消息时，Client 将向 KDC 申请一张不包含 PAC 票据，这个是微软默认的设计。

查看对应流量，确认include-pac: False。

查看正常 AS REQ 请求流量，两者进行对比。

AS REP 响应，将 KDC 加密的TGT 返回给客户端。

参数tgt_a获取 TGT 票据。

构造 TGS REQ。跟进build_pac函数查看 PAC 构造。

分别提取了 domain_sid、user_id，_build_pac_logon_info构造高权限 SID 以达到提权目的。

该函数将组成员身份声明更改为包含更高特权的组，由于 PAC 包含用户或组 SID，这就使得 AD 域中具有有效 AD 凭据的计算机上的 Client 能够绕过所有已配置资源的 ACL。

往下，关注默认参数server_key=(RSA_MD5,None)、server_key=(RSA_MD5,None)，关注checksum函数，以及参数server_key和kdc_key。

关于 PAC 签名，微软也做了相应的说明。

意思就是 PAC 通过包含两个数字签名(分别为 Server 密码 HASH 与 KDC 密码 HASH)防止 PAC 被伪造。

那么这两个数字签名 PAC_SERVER_CHECKSUM 和 PAC_PRIVSVR_CHECKSUM 则对应为chksum1和chksum2。

跟进查看checksum函数，server_key[0]和kdc_key[0]指的就是加密方式，指定为 MD5，这里server_key[1]和kdc_key[1]应为 Server 和 KDC 密码 HASH 并都设置了为None。

构造好 PAC 后，将其传入build_tgs_req函数构造 TGS REQ，然后发送给 KDC。

在上图中可以看到前面得到的 TGT 和通过eTYPE-ARCFOUR-HMAC-MD5加密方式的 PAC。

KDC 验证完成以后，返回 TGS REP，其中包含一张新的 TGT，它会将 exp 生成具有高权限的 PAC 包含在其中。

exp 收到上图新的 TGT 后会将其保存为TGT_user1@bbk.lab.ccache文件以方便 Client 导入到内存中使用。

在 Client 上使用 mimikatz 清除内存中现有的 Kerberos 票据，然后将 exp 生成的 TGT 导入到内存中进行提权。尝试连接访问 DC 的共享文件夹，继续抓包。

进行了两次的 TGS REQ 请求，第一次 TGS REQ 请求是使用上面exp生成的高权限 TGT 票据，然后返回了一张 win08.bbk.lab (win08是DC主机名)的 CIFS 服务的 ST 票据。

然后通过 SMB 协议拿着这个 ST 票据请求 CIFS 服务，发起 Session Setup Request(AP REQ)。

最后，返回 Session Setup Response(AP REP)响应。

此时，Client 拥有了 DC 上 CIFS 服务的有效 TGS，并且能够使用它通过 SMB 访问共享文件夹，甚至通过 psexec 远程连接。

日志分析与防御措施

以下是使用伪造 TGT 获取 TGS 以访问 DC 的 c

事件4769显示 user1@bbk.lab 使用伪造的 TGT 请求 TGS Kerberos服务票证。

事件4624显示 user1@bbk.lab 使用 TGS 服务票证登录到 DC。

事件5140显示 user1@bbk.lab 使用 ST 连接到只有管理员有权访问的目标域控制器的 c共享的事件日志。

事件4672显示 user1@bbk.lab 已成功验证（并登录到）只有域管理员才能访问的目标域控制器。

而且，此该用户具有 SeBackupPrivilege、SeRestorePrivilege、SeDebugPrivilege、SeTakeOwnership 等权限，表明该用户具有对此计算机的完全管理员访问权限。说明域控已经沦陷。

防御措施：

• 使用更高版本操作系统，安装补丁(KB3011780)，定期进行安全更新。

• 对域内账户进行控制，禁止使用弱口令，及时、定期修改密码。

• 当确认已被提权成功域控沦陷时，重装域服务。

• 攻击检测：内部流量分析标记include-pac: False作为特征，结合事件日志研判攻击是否成功。

总结

MS14-068漏洞主要是经过身份验证的域用户向 Kerberos KDC 发送伪造的 Kerberos 票据，票据其中包含了声称该用户是域管理组成员的 PAC。KDC 在处理来自攻击者的请求时不正确地验证伪造的票据签名，从而允许攻击者以域管理员身份访问任何资源。

从接触内网渗透以来，第一次分析 Windows 提权类型的漏洞，收获良多，受益匪浅。MS14-068 虽然是14年的老漏洞，但是放在今天仍然还具有一定的影响，且对该漏洞的处理与防护，也能举一反三应用到其他漏洞上。关于 Kerberos 协议的认证流程和 exp 利用，还有很多细节没深入去挖掘出来，文章篇幅较长，如有错漏还请海涵。

参考

• Microsoft Security Bulletin MS14-068 - Critical
  (https://docs.microsoft.com/en-us/security-updates/securitybulletins/2014/ms14-068)

• Python Kerberos Exploitation Kit  

  (https://github.com/mubix/pykek)

• Utilizing the Windows 2000 Authorization Data in Kerberos Tickets for Access Control to Resources
  (https://docs.microsoft.com/en-us/previous-versions/aa302203(v=msdn.10))

• Digging into MS14-068, Exploitation and Defence
  (https://labs.f-secure.com/archive/digging-into-ms14-068-exploitation-and-defence)

猎豹安全中心技术分享频道

  

1. 海量日志分析的预处理

2. OSSEC-Execd功能模块分析

3. 通过流量快速识别域名信息

4. 从android源码看脱壳

5. Ossec-Agentd模块分析

6. 猎豹移动DPIA系统开源

7. 一种新的分词方法在机器学习中的应用

8. Ossec-Logcollector模块分析

9. Ossec-Agent-Syscheckd模块分析

10. Ossec Agent总结

11. HTTP走私漏洞分析

12. BurpSuite扩展插件使用分享

13. webshell连接工具流量分析

14. JDK7u21调用链分析

15. php函数中的那些坑

16. 通过sqlmap源代码分析SQL注入漏洞检测流程

17. 猎豹移动通过“全球首个隐私信息管理体系标准”ISO/IEC 27701认证

18. DGA域名检测

19. 基于NSL-KDD数据集的网络入侵检测分析

20. 采用HAN网络模型的WebShell检测

21. Suricata可视化规则（简单）编辑器及规则统计告警系统开源

22. SQL注入检测

23. Typecho利用链分析

24. ISO27701

25. phpinfo里面有什么？

26. Django QuerySet.order_by() SQL注入分析

27. 内网渗透之SOCKS代理的5类基本场景
    

长按下方二维码关注我们

阅读原文

跳转微信打开

贫民版的SOAR----Node-red

  非常感谢二胡老板的推荐，一下增加了300多人，CEO下一步可以考虑直播带货了。

既然CEO都推荐了，怎么也要写点什么才对得起推荐，也对得起关注我的人。不过自从写完了书，感觉肚子里边的墨水真有点掏干净了，所以也憋不出太多的东西。我们对团研究的一些技术方向的文章都会发在《小豹讲安全》里边，如果有兴趣的读者，也可以关注一下这个公众号。

       回到正文，这次主要想说一下Node-red(简称NR) 这个东西，这个是我研究智能家居的时候接触到的一个东西，这里放两张流程图,用来处理网络出现故障进行线路切换的：

可以发现，这个东西，有点类似现在比较流行的SOAR，可以把一些防御策略做成可视化的形式。这样，每次想看一下当前的策略（或者给老板显摆一下），就可以非常直观的看到。

这东西的安装非常简单，有兴趣的朋友，可以参考官方文档进行安装即可，自带的插件也比较多，我主要用的SSH,HTTP,ELASTICSEARCH等等都有，所以，基本上也算可以满足一些场景的定义了。

不过这个东西的安全性，也需要注意，这里放一下TSRC的一篇针对NR的安全性研究的文档，写的已经很全了有兴趣的读者也可以看看  《物联网开源组件安全Node-RED白盒审计》  https://security.tencent.com/index.php/blog/msg/181

最后说一下个人对SOAR的一点看法吧，个人对这个来看，还是觉得有点花里胡哨的，主要我觉得安全对抗的本质还是人与人之间的对抗，用定义好的场景，脚本，往往可能都会处于自己跟自己玩的情况。而且，需要对规则的定义，使用，甚至结果都需要把握的非常准确，否则可能容易晚上没法好好睡觉了。而且看这类产品的核心功能应该是可以对接多少设备，能对接的设备越多，才能处理更加丰富的场景。不过如果作为常规性操作的防御的可视化来说，还是可以研究一下的。总之，个人觉得，注意力还是应该集中在对规则的掌控上，能做到精准判断，不误报，不漏报才是最好的。当然，针对这个话题，以后再慢慢写吧。

下期有感中途岛海战，谈谈安全工作中的战略和战术吧。

阅读原文

跳转微信打开

祝大家新年快乐

​

阅读原文

跳转微信打开

随着科技的进步，网络的发展越来越完善，企业网络的规模也在日益扩大，一旦企业网络安全失去保障，轻则影响正常办公

随着科技的进步，网络的发展越来越完善，企业网络的规模也在日益扩大，一旦企业网络安全失去保障，轻则影响正常办公，重则影响企业整个发展战略，如何提高企业网络的安全，对企业的运营及发展起到至关重要的作用。

本期安世加诚邀猎豹移动的安全总监林鹏先生，一起聊一聊《企业网络安全防御建设》这个话题。

★

本期嘉宾：林鹏

曾任当当网的安全经理、网信金融安全专家、万达电商信息安全部总经理等职务，有着长达10年的一线安全攻防实战经验，研究领域为日志分析，安全防御，金融安全等，EISS-2021北京站安全运营专场出品人。

本期看点

• 企业网络安全与企业信息安全的关联

• 企业网络安全建设的优先次序

• 企业网络安全建设的关键点

• 如何获得高层的支持

• 安全建设实践经验分享

• 安全管理者及员工的要求

视频资料

音频资料

（本期节目时长44分钟，请根据情况自行选择播放形式）

往期介绍

大咖话安全第十三期 | 王建强：货运场景下的SDL实践

大咖话安全第十二期 | 李少鹏：网络安全产业的过去、现在与未来

大咖话安全第十一期 | 肖寒：制造业信息安全建设之路

大咖话安全第十期 | 黄鹏华：针对APP开展个人信息影响的评估

大咖话安全第九期 | 马辰：基于DevSecOps理念的安全运营

大咖话安全第八期 | 大雄：SDL实践之道

大咖话安全第七期 | 胡剑飞：漫谈企业信息安全建设

大咖话安全第六期 | Joe Cai：浅析第三方风险管理

大咖话安全第五期 | 钱君生：一期看懂DevSecOps

大咖话安全第四期 | 蒋琼：新技术创新安全实践的思考与展望

大咖话安全第三期 |  周明昊：漫谈安全风险治理中的数字化

大咖话安全第二期 | Luwikes：聊一聊业务安全那些事

大咖话安全第一期 | 黄乐：浅谈安全运营之道

阅读原文

跳转微信打开

欢迎大家扫码报名参加5.14日的eiss大会，提问题送书啦

  欢迎大家扫码报名参加5.14日的eiss大会，这次我终于不用写PPT,改成了小组讨论的主持人了 。 当然这次讨论的议题个人觉得也比较贴地气的，关于安全运营与安全实践方法论，小组嘉宾也是业内实战经验非常丰富的，希望可以给大家带来一些收获。另外大家如果关于这方面有什么好问题，可以回复我，我可以代为向嘉宾提问，同时我会挑出5个问题的读者，赠送《互联网安全建设从0到1》或《网络安全与攻防策略》

在这里也感谢华章图书的支持，欢迎大家提问。

阅读原文

跳转微信打开

开发的两个关于suricata的小工具，便于编写规则和进行告警使用。

阅读原文

跳转微信打开

那个曾经的勇者，在得到了市场的垄断后也终将变成恶龙？

  今天想说说最近我们公司遇到的一个事情，牵涉的是互联网巨头公司，也是安全领域里一家技术顶级的公司-谷歌以及他的浏览器Chrome。

  事情的经过很简单，周三（10月28日）下午的时候，想登陆一下内网的oa系统，结果突然弹出来一个“大红叶”：

  一看到这种大红叶，没看内容的情况下我还以为是我的浏览器出了什么问题，或者是系统时间问题，再一看内容以为OA系统可能出了什么问题，还打算问问OA的人看看是不是被黑了。但是，接下来发现事情没有那么简单，我们的所有域名(*.cmcm.com)都被标红，只能去google的管理后台查看原因。结果发现：

仅仅只是发现了两个页面（可能）有问题，就把一个公司的全部域名彻底拉红，而且，根本不给你申诉的机会：28号在收到这个通知的时候，google就把公司整个二级域名全部判断为恶意。这分明就是打着安全的旗号刷流氓的具体表现嘛。

先不说检测的结果是否正确，（上一次是把ir的pdf财报认为是有问题的软件，后来也是申诉成功）

能不能只把有问题的域名标记，或者至少标记二级域名这么大的操作，是否可以提前通知一下管理员，这种行为对企业会造成多大的影响。这种行为算是一个有责任的科技公司干的事情吗？任何一家做安全的公司都不能因为一个ip 有问题，直接把c段甚至b段都给ban掉了吧。这种行为倒像是一个垄断企业掌握了生杀大权后行为。这不禁让我想到也许曾经的google 是一名勇者，但是也终于变成了一条恶龙。

当然，这件事也给了我们一些经验，做一点分享：

1 因为google的算法问题，可能会把一些下载的内容标记为有问题的软件，因此可能会导致全域名标红，因此如果有这样的功能页面，最好单独使用一个域名，以免主要域名受到影响。

2 经过两次的申述经验，大概判断google的审核时间为1天左右。

3 可以通过https://developers.google.com/safe-browsing对域名进行监控。

阅读原文

跳转微信打开

推荐一本个人认为最好的风控书-风控要略

   预售地址：https://item.jd.com/12946188.html

  今天给大家推荐一本我觉得非常好，好到应该是做风控甚至是业务运营人员都必备的一本书-《风控要略 互联网业务反欺诈之路》。

  先说一下这本书的作者马传雷（也给我的书写过推荐），曾经是同盾反欺诈研究院院长，个人认为同盾的风控业务水平在国内来说也算数一数二的，而马院长一直保持着对技术的热情，一直坚持研究技术，属于绝对的实战派，因此，此书一定也是干货满满，这点也可以从目录以及院长之前给我的样稿中可以看出。

   其次，我的观点是安全最好要服务于业务，而安全与业务贴合最紧密，最容易计算价值的，便是风控系统，毕竟你跟老板说发现100个webshell，没有跟老板说直接为公司止损10w，更能让老板直观的认识到安全部门的价值（当然，基础安全也非常重要，属于地基的作用）。尽管我在我的书中用了一个大章节介绍了互联网电商的刷单案例，风控系统以及解决方案，但我觉得那仅仅只是一小部分，可能是冰山的一角。而这本书能更加全面，系统的介绍这些方面的内容，因此非常适合做风控或者是向往风控业务发展的人。

   综上理由，推荐给大家这本书。了解我的人，或者读过我的书的朋友或许知道，我不爱搞什么虚的东西，文笔也不是太好，但是写的都是大实话。我也不说什么写书不易之类的话，而且这本书能出版确实也很不容易，也经历了许多波折，但之所以推荐的理由就是有内容，有干货，值得去看。尽管院长已经送我一本，但，还是要再买一本支持。

阅读原文

跳转微信打开

这几周再准备安全加和知道创宇的议题，所以没更新，明天再讲讲安全建设这事

跳转微信打开

第一次勘误及为啥暂时不建立读者群

  书已经上市了一段时间了，也得到了一些读者的好评，这里感谢所有读者对我的支持，目前接到一些读者反馈，有一些小的错别字及失误的地方，在此处进行更正:

感谢处：
应该是感谢靳晓飞@VIPKID 而非靳小飞，这里向他表示道歉。🙇‍♀️

漏掉了向红阳@国美，他在运维安全方面给了我很多启发，这里也表示感谢。🙏

正文部分：

 149页，第三行，针对主机所产生的的异常行为，这里少了一个机字 。笔误

 195页，倒数第四行 /var/messa，应改为/var/messages 。笔误

 236页，第八行，此时如果发现有攻击是针对这种服务器漏洞的（负）载荷的，多了个负字。笔误

 244页，倒数第四行 5W1H, WHERE 少了一个E。笔误

关于读者群：

  有些读者问是否有读者群，我暂时觉得还没有这个必要，相信大家都有很多群是死群，平时几乎没有什么交流，我就不再给大家多增加一个这样的群了。当然也很希望对本书，或者对安全工作有想法建议的朋友一起交流。如果真的有一起沟通的情况，到时候再建群也来得及。

阅读原文

跳转微信打开

解决OSSEC Agent 3.6.0 无法注册问题

  在第三章主机安全中，介绍了OSSEC 的使用方法，但当时Agent 使用的是3.2.0版本，在测试Agent 为3.6.0版本时发现无法注册的问题：使用Server生成的key注册时会出现下图错误：

提示：ERROR: Cannot,unlink /queue/rids/sender: No such file or directory 。

解决方法也很简单，使用如下命令：

touch /var/ossec/queue/rids/sender

即，在OSSEC 安装目录下的qurue/rids目录下新建sender 文件即可。

这样 ，便可以让Agent注册成功（需要重启Agent 服务），如下图：

在Server端，使用agent_control -l 命令也可以看到客户端是Active状态，（一定要是Active，如果没成功，可能会显示Never connected之类的）如图：

。

也可以在Server端让客户端直接重启操作。（客户端需要开启ar-auto  response 功能。这里再次建议这个功能一定要慎重使用，一定要配合白名单及绝对有把握的情况下使用）如图

Agent收到Server端的重启信号开始重启：

至此，便解决了 3.6.0版本Agent的问题。

PS：OSSEC 其实是一个比较不错的HIDS，不过因为是开源的版本，因此BUG,和坑也是很多的，坑在本书中已经介绍过一些了，BUG 也是经常有的。但个人觉得更难的是日常维护及批量部署，因此个人建议一定要有一定的开发能力，使用批量部署工具，否则会是一个比较繁重的工作。

阅读原文

跳转微信打开

互联网安全建设从0到1 发售，安全防御公众号正式运营

    时间过得真快，大概是去年6月13日，开始下定决心写书，到今天终于算是修成正果了，也算是给自己这些年的一些经验做了一次总结。同时为了继续让自己保持一点学习的动力，今天也正式开始维护这个公众号，这个号会以勘误为主，另外写一些技术方面的内容和自己的一些安全心得。

    书的内容和目录在各大平台应该都能看到了，通过之前的图片，也能看到我个人对自己内容的评价：是觉得写的满意的，是觉得写的可以的，是我确实不擅长，或者写的觉得不太好的地方。不过基本上也算是把我个人这些年的一些经验都扔进去了（想了一下还有一点点内容忘了写），然后现在感觉貌似基本上也没啥可讲的了。

  不管怎样，本书已经写完了，也算是我个人里程碑的一个小节点，人活一世，草木一秋，不求写书赚钱，只求给安全行业，给刚入行的安全人员留下点自己的经验，希望踩过的坑，就别再踩一次，造过的轮子也就别重新再造，仅此而已。但即使这样，我个人水平还是有限的，有错误的地方还请各位读者多多指正，有兴趣的读者，可以一起交流，毕竟安全防御这块，虽然不如攻击者那么耀眼，但幕后英雄这个称号也不错。

PS：头像是之前玩的塞尔达的海拉鲁之盾，也是整个游戏最好，最坚固的盾了，希望安全防御也可以做到这样，那就好了。

阅读原文

跳转微信打开

互联网安全建设从0到1

跳转微信打开