中午在吃飯，手機響了，運維告訴我有一台內部系統的server的cpu負載達到了80%，一共兩次，每次持續3分鐘左右。
我讓運維先別慌，去server上取apache的apache_access.log出來
apache_access.log檔案開啟來一看，每次cpu負載狂飆的時候，都密集了出現了以下的http請求，3分鐘內達到了4000次以上。
分析日誌可以看到，xx.xx.201.254的客戶端，在【】的畫面上，傳送get請求【/api/resizeimage.php?image=banner/08071002.png&width=320&height=100】到我們的server上。
第一，我們這台server位於公司防火牆背後，執行的是名為[的公司內部系統。這個系統的網域名稱也是公司內部dns的網域名稱，因此從外網直接發起攻擊可能性不大。
第二， image.php?這個畫面上確實有呼叫【api/resizeimage.php】的介面，但是如此頻繁的訪問，絕對不可能是正常的畫面操作。
第三，api/resizeimage.php的**的作用是將客戶上傳到server硬碟上的image檔案讀入記憶體，然後在cpu中進行計算，生成符合引數要求大小的縮小圖，然後作為http響應返回回來。並且在記憶體中將縮小圖釋放掉。。。。。。。這麼坑爹的**，負載一上去，cpu肯定掛
我先把注意力放在client的xx.xx.201.254上，經過調查，這台伺服器是另乙個專案組的一台公用server。。。。
果然是高手，利用這台公用server作為跳板。
這台肉雞上發生的事情和調查還在進行中，彙總之後也想寫出來。
作為補救，我們先修改了resizeimage.php的**邏輯，其次在apache前方前置乙個軟體級別的防火牆，發現多次頻繁同一ip請求則禁ip。
結論： 不能以為是內部系統就可以放鬆系統安全的考量
記一次database cpu high的處理
基本上，我們的資料庫例項每次cpu飆公升都是因read而起，很少有write導致的cpu高。這說明read，隨機讀，排序，都會占用cpu。而寫入主要是io行為，尤其是順序寫，不需要佔cpu。今次問題，rds在三個小時內都很高，始終維持50 最高甚至到98 當然我們的業務可用性並不依賴rds。觀察一段...
一次sql注入攻擊
喜歡學習 但是不想找漏洞 好麻煩 還不一定有乙個漏洞 是我在google上搜到的 畫面看著高大上 乙個頁面乙個頁面的找，尋找有輸入引數的地方，然後進行測試 本來我以為沒有注入的時候 突然 看到了一小句話 wow 有報錯資訊 可以進行報錯注入 想著可以提交烏雲了 然後先 order by 測試下有幾個...
一次SYN攻擊處理
公司有oa布置在阿里雲伺服器上，資料庫為了方便備份布置在了本地。最近幾天據同事反映，oa訪問速度很慢，測試了雲伺服器和本地伺服器的網路都是正常的，一時查不到原因。後來想到可能問題會不會出在資料庫的連線上導致阿里雲伺服器訪問本地資料庫速度慢引起oa的訪問速度慢。遂去本地資料庫伺服器 開啟cmd，輸入命...