Monthly Archives: April 2020

资源占用率监测方法

CPU

TOP,地球人都知道
[root@~]# top
top – 14:50:56 up 22:31, 7 users, load average: 45.76, 33.64, 15.93
Tasks: 622 total, 1 running, 621 sleeping, 0 stopped, 0 zombie
%Cpu(s): 3.6 us, 0.2 sy, 0.0 ni, 93.9 id, 2.4 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 13198510+total, 56110604 free, 41665376 used, 34209120 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 89487664 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2566 root 20 0 629720 561460 70156 D 67.2 0.4 0:19.35 clang
3197 root 20 0 144644 69224 42192 D 15.6 0.1 0:00.66 clang
3057 root 20 0 308968 234124 53692 D 12.6 0.2 0:06.64 clang

磁盘IO

[root@~]# iostat -x

Linux 3.10.0-514.el7.x86_64 (bsabj36) 02/10/2020 _x86_64_ (32 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle 11.12 0.00 2.45 0.70 0.00 85.73
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %utilsda 0.01 0.22 8.82 7.20 1072.97 386.24 182.17 0.17 10.34 2.75 19.65 9.98 15.99sdb 0.02 0.57 9.43 8.03 1064.23 325.95 159.18 0.20 11.41 22.09 29.59 11.08 19.35sdc 0.00 0.17 9.58 1.88 955.05 222.93 205.64 0.01 0.51 12.96 68.48 8.94 10.24sdd 0.05 0.56 1.97 3.99 42.70 73.31 38.93 0.14 22.93 5.20 31.71 3.53 2.10dm-0 0.00 0.00 1.34 3.35 30.00 29.12 25.22 0.11 22.51 5.16 29.43 3.13 1.47dm-1 0.00 0.00 0.06 0.16 0.23 0.64 8.00 0.11 484.35 7.16 652.83 0.19 0.00dm-2 0.00 0.00 0.64 0.77 12.43 43.54 79.25 0.05 36.75 5.56 62.72 5.55 0.78
看来rkB/s wkB/s比较高,可能存在io竞争看看哪些进程io占用率高?iotop -oPTotal DISK READ : 3.37 M/s | Total DISK WRITE : 1689.08 K/sActual DISK READ: 3.37 M/s | Actual DISK WRITE: 15.33 M/s PID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND 991980 be/4 qemu 3.37 M/s 0.00 B/s 0.00 % 9.29 % qemu-kvm -name WANNA_defend_win7_update_BJOBM1 -S -machine~alloon-pci,id=balloon0,bus=pci.0,addr=0x7 -msg timestamp=on 845146 be/4 qemu 0.00 B/s 1520.52 K/s 0.00 % 3.57 % qemu-kvm -name WANNA_defend_win7_update_GDSZ1 -S -machine ~alloon-pci,id=balloon0,bus=pci.0,addr=0x7 -msg timestamp=on 232279 be/4 qemu 0.00 B/s 158.02 K/s 0.00 % 0.73 % qemu-kvm -name MNG_ESPC -S -machine pc-i440fx-rhel7.0.0,ac~alloon-pci,id=balloon0,bus=pci.0,addr=0x8 -msg timestamp=on 860489 be/4 qemu 0.00 B/s 0.00 B/s 0.00 % 0.01 % qemu-kvm -name WANNA_SECURITY_RSAS_off -S -machine pc-i440~alloon-pci,id=balloon0,bus=pci.0,addr=0x7 -msg timestamp=on 993858 be/4 bsaworke 0.00 B/s 10.53 K/s 0.00 % 0.00 % java -Dproc_nodemanager -Xmx1000m -Dhadoop.log.dir=/home/b~rties org.apache.hadoop.yarn.server.nodemanager.NodeManager

网络IO

[root@~]# iftop -n -i eth0
-n表示不解析域名,-i表示对应网络接口

                            191Mb                                    381Mb                                    572Mb                                    763Mb                               954Mb
└───────────────────────────────────────┴────────────────────────────────────────┴────────────────────────────────────────┴────────────────────────────────────────┴────────────────────────────────────────
192.168.19.14 => 101.6.8.193 42.5Kb 34.5Kb 34.5Kb
<= 2.75Mb 2.45Mb 2.45Mb 192.168.19.14 => 10.63.1.90

RSAC 2020 | 云安全观察

RSAC 2020如期在旧金山举办,还是2月,还是在Moscone Center,只是没有了诸多中国同行的参加,也没有了百度游艇。很可惜我没有亲身参加本届RSAC,(也不知道市场街梅西百货外面的市政有没有弄好,这也似乎成为一个旧金山新景点了,囧),因而文中不会出现身临其境的感受,所以更多的谈的是从会议session中观看和阅读的感觉。

时间有限,还没来得及看所有的胶片,不过从云安全高峰论坛(CSA Summit)、云安全和虚拟化(Cloud Security & Virtualization)和DevSecOps 和应用安全(DevSecOps & Application Security)几个Track的内容中,我有以下几个观点,仅供探讨。

观点1 :云计算已经成为了互联一切的基础设施,云安全已经成为了纯安全问题

    第一天早上CSA高峰论坛[1]、第一天下午创新沙盒,第二天上午Keynote乎已经成为RSA的近几年标配,也是三大看点。CSA高峰论坛作为先发阵容中的先发队员,其影响力可见一斑。不过很有意思的是,每年CSA的影响力是越来越大,各种标准、工作组和培训,应该都让它挣得钵满盆满,覆盖范围也从最初的云计算安全扩展到物联网安全、软件定义边界等交叉领域,可见,云计算已经成为互联一切的基础设施,云安全联盟的触角已然不满足狭义的公有云和私有云计算安全领域了。

可以说,CSA和安全厂商和已经成为了合作伙伴的关系,在共同的研究点和产品方向互为背书,互为推广。例如,2019年的高峰论坛上几家做SDWAN安全的厂商在大谈软件定义边界,也为它在2013年提出的SDP捧场。今年OneTrust的VP Kevin Kiley在讲供应链安全,其中就是对供应链中的第三方厂商的安全进行评估,也就是Gartner近两年提的IRM(Integrated Risk Management)中的VRM(Vendor Risk Management),为什么OneTrust会在云安全的会场谈这个话题呢?因为云计算一个很大的挑战是用户对云服务商的信任,CSA在前几年提出了Consensus Assessments Initiative (CAI)[2],即对用户让云服务商就Cloud Controls Matrix (CCM)标准填写评估,从而得到第三方云基础设施的可靠度。显然OneTrust的方案也是契合该方向的。可以说云安全联盟在商业运作上非常成功,通过与厂商的合作,与客户的培训,形成了云安全领域很好的生态体系,共同推进云计算安全的发展。

另一方面,云计算既然成为了普适的基础设施,提供了计算、存储、网络、函数等服务,那么客户就会将云计算作为一种内生资源,嵌入在他的基础设施中,最终形成统一的IT架构,近两年多云(Multi-Cloud)、混合云(Hybrid Cloud)、SDWAN就比较热,在这样的IT环境中提供安全产品、安全服务,那前几年的云安全产品或方案必然要融入传统环境,提供统一的功能。可以预见,在未来几年,安全厂商的安全方案不会显示地带有“云安全”的定语,因为这就是默认选项,即云安全已经成为纯安全问题。一个证据是今年CSA高峰论坛的话题则覆盖了网络检测响应(NDR)、供应链安全、数据泄露响应、CISO视角等各安全细分领域的话题,但上午的session标题中都没有出现cloud一词。当然细看内容,其实云安全的理念已经融入其中,甚至可以说,大家无论谈安全理念,或是安全技术、安全方案,都是面向云计算环境。例如Extrahop Networks的COO Raja Mukerji在谈检测响应,主张将NDR、EDR、SIEM组合,构建面向公有云的检测响应机制,实现云原生的安全。

当然,虽然传统安全问题会发生在云计算场景中,但云环境也有其独特的地方,所以在云安全和虚拟化(Cloud Security & Virtualization)session中,如子域名接管[3]的原因在于一些子域名是租用的,管理不当容易被恶意租户发现并接管;又如好几个胶片谈到暴露面检查,就是Gartner说的CSPM(Cloud Security Posture Management),本质来看就是传统的服务(端口)暴露和弱口令(正如现在很多互联网上脆弱的物联网设备一样),转变成了公有云上的存储资源暴露和弱口令。所以这些本质来说是传统安全问题,但公有云计算环境下有新的特点,值的我们重视。

观点2: 云安全更加实战,已从纯合规性要求转向攻防要求

从前几年AWS在各个大会上有独立session做AWS安全入门培训,彼时大部分的客户对公有云还不太熟悉,一部分是因为公有云服务太多、配置太复杂了,另一部分原因是,对于攻击者而言也比较新,相对而言,IaaS和PaaS的云安全还是以合规性要求居多。

而如今,云计算对于攻击者而言,开放API、灵活的资源编排,俨然成为了另一个维度好用的攻击资源;另外,云用户错误配置,也给觊觎云上敏感数据的攻击者可乘之机。所以无论是数据面安全CWPP(Cloud Workload Protection Platform),还是管理面安全CSPM,各类云安全厂商也兴起,从本届RSAC云安全session中的内容来看,跟往届相比更加实战。

例如前面提到的子域名接管攻击,在两个胶片[3,4]中提到,其中[3]是星巴克安全团队作为受害者出来讲,更令人信服。而[4]则更全,介绍了十种面向云平台的攻击链,其中侦查阶段大部分是CSPM关注的暴露token、bucket等,另一部分则是恶意内部攻击者,即前面提的供应链覆盖的内容。

当然只有用户和安全厂商显然不全,session中还有一个是来自AWS的Ben Potter,职位是the security lead for Well-Architected,属于架构师,介绍了AWS的架构(Well-Architected)中的安全设计,可以看出,AWS的安全体系已经覆盖了事前管理、准备,事中检测和响应,事后恢复的闭环,其中还提到使用了金丝雀账户,部署了一些诱饵,这说明云厂商的安全团队已经不止关注传统的清理(hygiene)和被动防护的工作,也开始做一些主动防御的工作了。

总体而言,检测响应已经从传统企业环境转向云计算环境,如[5,6]都介绍了云服务商和用户如何做检测响应的经验,[6]则是介绍了在线交易的领域如何实现身份和访问控制(SSO、MFA,RBAC),数据安全(加密、密钥管理),应用安全(API安全,session管理),日志和监控(分析,日志集中),事件响应(告警、IR剧本),在云计算环境中必须要引入自动化和xDR才能满足规模化的要求。

作为防守方,一家小公司IMG Security的咨询师,[9]介绍了云环境下的威胁狩猎,案例非常具体,涉及到渗透测试和事件响应

观点3:云原生进入主流,从只谈容器安全、Kubernetes安全到云原生安全,代码、应用

在2019年的RSAC的早期厂商展览,已经有一两家做Kubernetes和容器安全了,而今年的云安全和DevSecOps session中,有两篇Kubernetes攻防的胶片,还有一篇介绍云原生安全和Serverless安全,说明这话题已经被主流观众所关注,而且关注点不断向上,从容器到编排,再到无服务和云原生安全。

例如,SANS的培训师在[7]hack了AWS的lamda函数,通过反向代理获得无服务的操作系统细节,见下图。

图片包含 屏幕截图

描述已自动生成

然后分析了如何从外部获取凭证进入容器,进而收集容器内部更多凭证,横向移动,建议将函数放在vpc里面,减少暴露面。

在[8]中,讲者是一家安全资讯公司inguardians的CTO,先介绍了Kubernetes下的攻击思路,在master节点攻击api server等几个核心组件,在slave攻击kubelet和运行时容器,给了一个自己开源Kubernetes的渗透测试工具(https://github.com/inguardians/peirates),该工具主页demo介绍了获得暴露的secret,然后从api-server创建账号,新建容器,并得到反连shell。另外给了一个测试训练环境,供学习 https://www.bustakube.com/

从以上几个胶片的内容可以看出,今年云计算安全很明显的,安全倾向于攻防细节,环境则侧重于编排系统之上的部分。

观点4:DevSecOps成为热点,DevSecOps和云原生安全不断融合,创造了一些共同的话题

敏捷开发DevOps似乎与云计算是两个维度,但“容器-编排”可以支撑敏捷CI/CD的开发模式,而“编排-无服务”的云原生运营模式可以支撑大规模弹性的应用场景,这套技术栈似乎为全世界绝大多数的开发者所青睐,而容器-Kubernetes-Serverless又是云原生的底层技术,所以随着敏捷开发本身的安全机制(DevSecOps)不断发展,两种安全视角的融合不断加深。今年的云安全session中有一些问题的起源,如代码中的硬编码token、代码仓库的暴露凭证,都是安全敏捷开发需要关心的内容,而今年的DevSecOps 和应用安全(DevSecOps & Application Security)session中,则有一篇[10]是专门介绍Kubernetes的访问控制安全的。

观点5:人是对抗永远的主题,人的因素不可忽视

今年大会的主体是Human Element,不可避免地很多胶片中也出现了这个元素,大部分都是简单涉及,不过确实有两篇是专门对人的因素进行探讨。

如[11]介绍了在传统环境和云环境中不同的思路,在云环境中做安全应该与云计算的思路匹配,如安全即代码,拥抱自动化,此外要避免人为错误所造成的影响,组织红蓝对抗。而[12]是出现在敏捷开发的session中的,很有意思的讨论了工作时间、团队规模和修改他人代码频繁度等因素对代码安全性产生的影响。总之,技术、流程和人是信息安全的三个组成部分,人的因素在不断的提升。如何发挥人的主观能动性,对于提升安全防护效率至关重要。

总之,云计算已经成为了连接万物的普适的基础设施,云计算安全已经进入了下半场,如何形成统一的安全体系,如何提升云计算的真实安全水平,如何提升使用云计算的各种团队的安全能力,将是接下来云安全的发展方向。

参考链接

[1]  https://www.rsaconference.com/usa/agenda/csa-summit-privacy-and-security-in-the-cloud

[2]  https://cloudsecurityalliance.org/research/working-groups/consensus-assessments/

[3] Same Thing We Do Every Few Minutes, Pinky – Try to Take Over All Your Subdomains ,RSAC 2020

[4] Break the Top 10 Cloud Attack Killchains, RSAC 2020

[5] Using Automation for Proactive Cloud Incident Response,RSAC 2020

[6] Untangling SaaS Security in the Enterprise, RSAC 2020

[7] Defending Serverless Infrastructure in the Cloud, RSAC 2020

 [8] Kubernetes Practical Attack and Defense, RSAC 2020

[9] Cloud Threat Hunting, RSAC 2020

[10] Compromising Kubernetes Cluster by Exploiting RBAC Permissions, RSAC 2020

[11] Hacking Your Security Culture for the Cloud,RSAC 2020

[12] Which Developers and Teams Are More Likely to Write Vulnerable Software,RSAC 2020