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，控制容器，甚至連宿主一同控制。