0x00背景
常见的不安全的运维意识与运维漏洞，前车之鉴，后者可鉴。
0x01 常见薄弱的安全意识
敏感端口对外开放
数据库或者缓存应用属于敏感应用，通常部署在内网，但是如果部署的机器有内外网ip，且默认监听地址为0.0.0.0的话，则敏感端口会对外开放。如mysql/mongodb/redis/rsync/ docker daemon api等端口对外开放。
敏感应用无认证、空口令或者弱口令
如果敏感应用使用默认配置，则不会开启认证，mysql/mongodb/redis/rsync/supervisord rpc/memcache等应用无认证。有时为了测试方便，配置了弱口令或空口令，则认证形同虚设。
敏感信息泄露，如代码备份、版本跟踪信息、认证信息泄露
web.tar.gz/backup.bak/.svn/.git/config.inc.php/test.sql等信息泄露随处可见，人人知道危险，但是始终时不时会有人会踩坑。
应用默认配置未清除
jenkins script/apache server-status等默认功能未清理，例如下图可直接执行命令。
应用系统打开debug模式
Django debug模式开启暴露uri路径，phpinfo()暴露服务器信息甚至webroot等，之后攻击者便可借此进一步渗透，很多白帽子应当有此同感，发现了sql注入但是写不了webshell，如果能遇上个phpinfo()那是再好不过的事情了。
应用漏洞未及时升级
越是通用的应用，就越经常爆出漏洞。有句话说的好：不是因为黑客这个世界才不安全，而是因为不安全才会有了黑客，才会有黑客去揭开那层假象，让我们发现有那么多不安全。于是Struts2、OpenSSL、Apache、Nginx、Flash等等CVE接踵而来。
权限管理松散
不遵循最小权限原则，给开发提供root权限或者给业务账号授权admin权限。
0x02 安全风险典型案例
弱口令
- SSH弱口令、数据库弱口令、中间件管理后台弱口令、zabbix弱口令等。
- 攻击者利用资产扫描或者暴力破解攻击发现弱口令。
WEB-INF泄露
- WEB-INF 是 Java 的 WEB 应用的安全目录。如果想在页面中直接访问其中的文件，必须通过 web.xml 文件对要访问的文件进行相应映射才能访问。通常一些 web 应用我们会使用多个 web 服务器搭配使用，解决其中的一个 web 服务器的性能缺陷以及做均衡负载的优点和完成一些分层结构的安全策略等。在使用这种架构的时候，由于对静态资源的目录或文件的映射配置不当，可能会引发一些的安全问题，导致 web.xml 等文件能够被读取。
- 攻击者通过扫描目录，浏览器直接读取即可
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镜像仓库的任意镜像，后果将难以想象。
docker安全配置风险
- 单机安装docker之后忽略检查iptables，导致docker修改iptables开放外网，docker daemon默认是能控制宿主iptables的,如果docker daemon使用tcp socket或者启动的容器,危害更大。
- 攻击者通过访问docker daemon，控制容器，甚至连宿主一同控制。