99%的人会中招的运维安全陋习，请规避！

13、应用选型时没有考虑安全风险

Apache Struts Version：Struts 2.5 - Struts 2.5.12 #线上业务使用受S2-052影响的S2版本 

14、对软件供应链安全没有概念

从xcode事件到pip官方发现恶意ssh库，都在向我们昭示一个道理：软件供应链安全风险极大。目前比较运维人员中比较常见问题有：

ssh客户端或者开发IDE从百度网盘下载

两眼一闭，把github/pypi/dockerhub等网站下载的应用/库/镜像直接用到生产环境

未清理默认口令或者默认配置

四、常见运维安全问题

前面我们谈到了运维操作上、思路上的一些陋习，或者安全意识不足的问题，下面结合漏洞分析和响应过的情况来看，常见的运维安全问题主要可分为下面几种：

1、敏感端口对外开放

db或者cache属于敏感应用，通常部署在内网，但是如果部署的机器有内外网ip，且默认监听地址为0.0.0.0的话，则敏感端口会对外开放。如 MySQL / MongoDB / Redis / rsync / docker daemon api 等端口对外开放。

2、敏感应用无认证、空口令或者弱口令

同上，如果敏感应用使用默认配置，则不会开启认证，MySQL / MongoDB / Redis / rsync / supervisord rpc / Memcache 等应用无认证。有时贪图测试方便，配置了弱口令或空口令，则认证形同虚设。

3、敏感信息泄露，如代码备份、版本跟踪信息、认证信息泄露

web.tar.gz/backup.bak / .svn/.git / config.inc.php / test.sql 等信息泄露随处可见，人人知道危险，但是始终时不时会有人会踩坑。

4、应用默认配置未清除

jenkins script / apache server-status等默认功能未清理，例如下图可直接执行命令：

5、应用系统打开debug模式

Django debug模式开启暴露uri路径，phpinfo暴露服务器信息甚至webroot等，之后攻击者便可借此进一步渗透，很多白帽子应当有此同感，发现了sql注入但是写不了webshell，如果能遇上个phpinfo那是再好不过的事情了。

6、应用漏洞未及时升级

越是通用的应用，就越经常爆出漏洞。有句话说的好：不是因为黑客这个世界才不安全，而是因为不安全才会有了黑客，黑客去揭开那层假象，我们才发现有那么多不安全。于是Struts2、OpenSSL、Apache、Nginx、Flash等等CVE接踵而来。

7、权限管理松散

不遵循最小权限原则，给开发提供root权限或者给业务账号授权admin权限。

8、DDoS攻击

DDoS攻击对于运维人员而言，是再熟悉不过的安全问题了。我们都知道通过占满带宽、耗尽资源等方式可让服务器无法响应正常请求，说到底是资源对抗的一种攻击方式。如果仅依赖服务器资源去抗，去过滤，如下图，在大流量、高并发之下，只会引来雪崩：

加上DDoS攻击平台大量存在，而且价格低廉，这就让DDoS攻击成为打压竞争对手、报复、勒索等阴谋诡计者首选方式了。

9、流量劫持

还记得2015年小米、腾讯、微博、今日头条等六家共公司联合发表声明呼吁电信运营商打击流量劫持的报告吗?即便如此，现如今的互联网江湖仍是暗流滚滚。下面介绍三种常见的流量劫持方式，这也是困扰运维安全人员多年的痼疾：

• arp劫持：ARP协议的基本功能就是通过目标设备的IP地址，查询目标设备的MAC地址，以保证通信的进行。基于ARP协议的这一工作特性，黑客向对方计算机不断发送有欺诈性质的ARP数据包，假冒目标IP进行ARP响应，从而实现中间人攻击。
• 域名劫持：通过劫持掉域名的DNS解析结果，将HTTP请求劫持到特定IP上，使得客户端和攻击者的服务器建立TCP连接，而非和目标服务器直接连接。
• HTTP劫持/直接流量修改：在数据通路上对页面进行固定的内容插入，比如广告弹窗等。

10、案例

前面我们讨论了很多运维安全陋习和问题分类，下面要讲的，则是大家再熟悉不过的几个案例，且看运维安全漏洞如何“性价比”极高：

svn

• 部署web代码时误将.svn目录上传;
• 使用rsync上传代码时没有exclude掉 .svn目录，svn仓库也没有使用svn propedit svn:ignore <目录或文件>的方式ignore掉不应当上传的文件或目录;
• 攻击者利用svn信息泄露利用工具Svn-Tool或者svn-extractor还原代码。

rsync

• rsync使用root用户启动，模块没有配置认证，还对外开放默认端口873;
• 攻击者利用rsync写crontab任务成功反弹Shell，并种上了挖矿木马。

Redis

• Redis使用root用户启动，没有配置认证，还对外开放默认端口6379;
• 攻击者利用Redis写ssh公钥到root用户的.ssh目录成功登上机器;
• 一般部署Redis的机器都有内网IP，攻击者可借此进行内网漫游了。

Kubernetes

• K8S的API对外开放，同时未开启认证;
• 攻击者调用API创建容器，将容器文件系统根目录挂载在宿主根目录， 攻击者利用写crontab任务成功反弹Shell，并在宿主种上了挖矿木马;
• 有时候容器里跑着未编译的代码或者在沦陷的机器上可以拉到私有Docker镜像仓库的任意镜像，后果将难以想象，如下面K8S的API，调用起来则非常简单。

（编辑：晋中站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!