Home未分类使用Falco检测Kubernetes安全问题简介

使用Falco检测Kubernetes安全问题简介

2016 年 3 月 18 日

：

周五截止，你填了吗？


10人将获赠CNCF商店$100美元礼券！


来参与2020年CNCF中国云原生调查

问卷链接（
https://www.wjx.cn/jq/97146486.aspx
）

作者：Frederick Fernando。本文于2020年12月16日首次发表在
InfraCloud的博客
上。

https://www.infracloud.io/blogs/introduction-kubernetes-security-falco/
我们来谈谈Kubernetes的安全问题
随着Kubernetes的不断普及，了解如何保护它是很重要的。在Kubernetes等动态基础设施平台中，检测和处理威胁很重要，但同时也具有挑战性。
开源云原生运行时安全项目Falco是Kubernetes威胁检测引擎中领先的开源引擎之一。Falco由Sysdig在2016年创建，是第一个作为孵化级项目加入CNCF的运行时安全项目。Falco检测意外的应用程序行为，并在运行时发出威胁警报。
为什么这么难？

根据
这一分析
，安全是运行Kubernetes的一个更困难的挑战。困难的原因是，在云原生堆栈中有多个移动层，因此运营者可能不会在一开始就关注安全性。另一个因素是Kubernetes的一些发行版在默认情况下可能并不安全，这与运营者的假设相反。

https://thenewstack.io/top-challenges-kubernetes-users-face-deployment/
预防和检测
信息安全是一个通过不同阶段进行自我建设和加强的过程。安全是一段旅程，而不是目的地。虽然信息安全过程有多种策略和活动，但我们可以将它们全部分为三个不同的阶段——预防、检测和响应。
预防措施
预防措施包括适当的访问控制、身份验证和授权。不管一个系统可能拥有何种程度的保护，它都会因为更大程度的动机和技能而受到影响。没有万无一失的“银弹”安全解决方案。应该部署深度防御策略，这样当每一层发生故障时，它就安全故障到一个已知的状态，并发出警报。这一战略的最重要因素是及时发现并通知遭到入侵。
检测措施
检测措施的一个例子包括从安全和网络设备，如基于主机的入侵检测系统（HIDS）和网络入侵检测系统（NIDS），向SIEM发送日志，并建立规则，在发现可疑活动时发出警报。根据深度防御的方法，我们应该在技术堆栈的多个层次上审计和放置检测触发器，从查看云审计日志（如Cloudtrail）、Kubernetes集群、容器、应用程序代码、主机操作系统和内核。我们将在这个博客中看看这些检测措施，这些措施将进一步帮助我们应对这些威胁。


图片来源：@leodido
在Kubernetes上设置Falco
运行Falco最安全的方法是直接在主机系统上安装Falco，这样Falco就可以与Kubernetes隔离。然后，可以通过运行在Kubernetes中的只读代理使用Falco警报。如果不需要隔离，Falco也可以直接在Kubernetes运行。我们将在本教程中使用Helm设置Falco，但你应该意识到你所选择的方法的利弊。
步骤
前提条件：为此我们需要一个有效的Kubernetes设置。你可以使用AWS/GCP提供的云Kubernetes，也可以使用minikube在本地设置一个。我们还要求kubectl和Helm安装在你的客户端机器上。
让我们从Falco的安装开始。
1. 在Helm中添加falcosecurity仓库

$ helm repo add falcosecurity https://falcosecurity.github.io/charts
 
$ helm repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "falcosecurity" chart repository
...Successfully got an update from the "stable" chart repository
Update Complete. ⎈Happy Helming!⎈

2. 安装chart

$ helm install falco falcosecurity/falco
NAME: falco
LAST DEPLOYED: Mon Nov 9 22:09:28 2020
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Falco agents are spinning up on each node in your cluster. After a few
seconds, they are going to start monitoring your containers looking for
security issues.
No further action should be required.

3.
几秒钟后Falco应该开始运行，验证一下，你马上就会看到你创建的pod。

$ helm ls
   
$ kubectl get pods

设置环境
我们需要一个环境来模拟攻击并检测它们。我们来设置一下。我们要用Helm。
让我们添加Helm的stabel仓库，并从其中安装mysql-db chart。

$ helm repo add stable https://charts.helm.sh/stable




$ helm repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "falcosecurity" chart repository
...Successfully got an update from the "stable" chart repository
Update Complete. ⎈Happy Helming!⎈
$ helm install mysql-db stable/mysql


NAME: mysql-db
LAST DEPLOYED: Mon Nov 9 22:11:07 2020
NAMESPACE: default
STATUS: deployed
REVISION: 1
NOTES:
MySQL can be accessed via port 3306 on the following DNS name from within your cluster:
mysql-db.default.svc.cluster.local




…

现在让我们监控Falco日志：

$ kubectl get pods
NAME                      READY  STATUS   RESTARTS  AGE
falco-6rr9r               1/1    Running  0         49m
mysql-db-d5dc6b85d-77hrm  1/1    Running  0         47m
ubuntu                    1/1    Running  0         43m




$ kubectl logs -f falco-6rr9r # Replace with your Falco pod name here

Falco的日志分析
攻击者在访问Kubernetes集群后所做的第一步是枚举可用的网络主机。攻击者会试图在一个看似陌生的环境中寻找出路。他们可以尝试使用安全/较少噪音的命令来从集群中获得更多的信息。让我们看看攻击者可能会做的步骤，并看看来自Falco的相应检测信号。我们将使用Falco附带的默认规则集，这些规则可以根据你的环境需要进行调整。你可以在这里找到Falco的默认规则：
https://github.com/falcosecurity/falco/tree/master/rules
容器内的终端
描述：探测到在pod中产生的终端。我们在运行的pod上打开一个终端外壳来复制这个场景。

$ kubectl exec -it mysql-db-d5dc6b85d-77hrm -- bash -il # Replace with the mysql pod name you have

检测：

18:08:40.584075795: Notice A shell was spawned in a container with an attached terminal (user=root user_loginuid=-1 k8s.ns=default k8s.pod=mysql-db-d5dc6b85d-77hrm container=3fc8155f9d1a shell=bash parent=runc cmdline=bash -il terminal=34816 container_id=3fc8155f9d1a image=mysql) k8s.ns=default k8s.pod=mysql-db-d5dc6b85d-77hrm container=3fc8155f9d1a

从容器联系Kubernetes API服务器

描述：我们运行kube-recon，这是一个在Kubernetes环境中进行初步侦察的工具。该规则检测从容器联系Kubernetes API服务器的尝试。

$ kubectl run kuberecon --tty -i --image octarinesec/kube-recon
/ # ./kube-recon
2020/11/09 18:21:22 Testing K8S API permissions
2020/11/09 18:21:23 Your K8S API Server is configured properly
2020/11/09 18:21:23 Running Nmap on the discovered IPs
2020/11/09 18:21:23 Getting local ip address and subnet
2020/11/09 18:21:23 Trying to download EICAR file
2020/11/09 18:21:23 Downloaded EICAR successfully. No malware protection is in place

检测：

18:20:45.927730981: Notice A shell was spawned in a container with an attached terminal (user=root user_loginuid=-1 k8s.ns= k8s.pod= container=4f63870599d0 shell=sh parent= cmdline=sh terminal=34816 container_id=4f63870599d0 image=octarinesec/kube-recon) k8s.ns= k8s.pod= container=4f63870599d0
18:21:22.657590195: Warning Docker or kubernetes client executed in container (user=root user_loginuid=-1 k8s.ns=default k8s.pod=kuberecon container=4f63870599d0 parent=kube-recon cmdline=kubectl get pods image=octarinesec/kube-recon:latest) k8s.ns=default k8s.pod=kuberecon container=4f63870599d0
18:21:22.723707794: Notice Unexpected connection to K8s API Server from container (command=kubectl get pods k8s.ns=default k8s.pod=kuberecon container=4f63870599d0 image=octarinesec/kube-recon:latest connection=172.17.0.5:56972->10.96.0.1:443) k8s.ns=default k8s.pod=kuberecon container=4f63870599d0

检查shell是否是一个容器环境（更改线程名称空间）
描述：amicontained是一个检查终端是否为容器化环境的工具。该规则检测更改程序/线程名称空间的尝试。

$ cd /tmp; curl -L -o amicontained https://github.com/genuinetools/amicontained/releases/download/v0.4.7/amicontained-linux-amd64; chmod 555 amicontained; ./amicontained




Output: 
Container Runtime: docker
Has Namespaces:
  pid: true
  user: false
AppArmor Profile: kernel
Capabilities:
  BOUNDING -> chown dac_override fowner fsetid kill setgid setuid setpcap net_bind_service net_raw sys_chroot mknod audit_write setfcap
Seccomp: disabled    
Blocked Syscalls (19):
  MSGRCV SYSLOG SETSID VHANGUP PIVOT_ROOT ACCT SETTIMEOFDAY UMOUNT2 SWAPON SWAPOFF REBOOT SETHOSTNAME SETDOMAINNAME INIT_MODULE DELETE_MODULE LOOKUP_DCOOKIE KEXEC_LOAD OPEN_BY_HANDLE_AT FINIT_MODULE

检测：

18:43:37.288344192: Notice Namespace change (setns) by unexpected program (user=root user_loginuid=-1 command=amicontained parent=bash k8s.ns=default k8s.pod=kuberecon container=c6112967b4f2 container_id=c6112967b4f2 image=octarinesec/kube-recon:latest) k8s.ns=default k8s.pod=kuberecon container=c6112967b4f2
Mon Nov 9 18:43:37 2020: Falco internal: syscall event drop. 9 system calls dropped in last second.
18:43:37.970973376: Critical Falco internal: syscall event drop. 9 system calls dropped in last second. (ebpf_enabled=0 n_drops=9 n_drops_buffer=0 n_drops_bug=0 n_drops_pf=9 n_evts=15232)

总结
在本教程中，我们了解了Kubernetes安全监视的基础知识，以及Falco如何允许我们使用规则来检测安全问题。Falco的默认检测规则集足以让你启动并运行，但是你很可能需要在默认规则集的基础上进行构建。如果你有任何反馈或建议，请通过Twitter @securetty_与我联系。
点击【阅读原文】阅读网站原文。


扫描二维码联系我们！
CNCF (Cloud Native Computing Foundation)成立于2015年12月，隶属于Linux  Foundation，是非营利性组织。 



CNCF



（




云原生计算基金会

）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。请长按以下二维码进行关注。

Related Posts

About The Author

bjmayor

程序员，码农，php,python,ios,android,go，产品经理，创业。