亚洲av成人无遮挡网站在线观看,少妇性bbb搡bbb爽爽爽,亚洲av日韩精品久久久久久,兔费看少妇性l交大片免费,无码少妇一区二区三区

Chinaunix

標題: 【大話IT】你的業(yè)務安全嗎？你的機器安全嗎？(服務器安全與網(wǎng)絡安全的開放性討論) [打印本頁]
作者: Fl_wolf    時間: 2017-02-08 14:40
標題: 【大話IT】你的業(yè)務安全嗎？你的機器安全嗎？(服務器安全與網(wǎng)絡安全的開放性討論)
獲獎公布：
最佳優(yōu)勝獎：lsstarboy
精彩回復：shenlanyouyu    l495051275    Purple_Grape
請以上獲獎人員在4月20日前將姓名、電話、郵箱、公司、職務、快遞地址站短給hyukhae079408，以便盡快給大家發(fā)放禮品。


導語：

網(wǎng)絡教育越來越普及，教育的內容也越來越廣泛，經常有教黑客工具的使用等.另一方面黑客工具的＂傻瓜化＂，＂低齡化＂更多的青年年甚至是少年開始接觸黑客行列(所謂的腳本小子  script kiddie)，據(jù)我見過的能使用簡單的黑客工具進行簡單的SQL注入，提權能完成一整套操作的少年只有13歲。
為此安全問題成為了未來的重中之重！安全問題涉及了網(wǎng)絡安全，web安全，app安全，服務器安全等等，我相信在未來的2-3年內會成為大家必須要越過的坎子。


做為開發(fā)或者運維人員，應該如何應對這些安全問題？

１.你所寫的代碼或者服務器遇到過被黑的情況嗎？如果有敘述下解決方案。
２.你的代碼與服務器是否有對防黑進行監(jiān)控，或者有什么安全措施？是如何實現(xiàn)的？
３.除了外患，也許還有內憂，如離職人員的代碼后門檢測，運維人員的服務器后門檢測，是否有快速的方法？
４.你對未來的安全提出一些友好的方案。

開放性問題~~也可以談談你身邊遇到的安全問題


活動時間：2月9日—3月6日


活動獎勵：
本期活動，我們將特設1個最佳優(yōu)勝獎，送DTCC2017大會門票一張。

同時，我們將會選取3個精彩回復，各送社區(qū)15周年限量版男士商務晴雨傘一把。




DTCC 2017 來啦！

隨著云計算和大數(shù)據(jù)時代的來臨，數(shù)據(jù)正在以前所未有的速度成為各個領域價值創(chuàng)造的核心驅動力。

在此背景下，國內最受關注的數(shù)據(jù)庫技術盛會——2017第八屆中國數(shù)據(jù)庫技術大會（DTCC2017）將于2017年5月11-13日如約而至。本屆大會以“數(shù)據(jù)驅動•價值發(fā)現(xiàn)”為主題，匯集來自互聯(lián)網(wǎng)、電子商務、金融、電信、政府、行業(yè)協(xié)會等20多個領域的120多位技術專家，共同探討Oracle、MySQL、NoSQL、云端數(shù)據(jù)庫、智能數(shù)據(jù)平臺、區(qū)塊鏈、數(shù)據(jù)可視化、深度學習等領域的前瞻性熱點話題與技術。大會共設定2大主場和20個技術專場，將吸引5000多名IT人士參會，為數(shù)據(jù)庫人群、大數(shù)據(jù)從業(yè)人員、廣大互聯(lián)網(wǎng)人士及行業(yè)相關人士提供最具價值的交流平臺。



官網(wǎng)鏈接：http://dtcc.it168.com/
購票鏈接：http://dtcc.it168.com/goupiao.html

歡迎掃碼關注DTCC官方微信，獲取最新信息！



作者: Fl_wolf    時間: 2017-02-08 15:16
本帖最后由 Fl_wolf 于 2017-02-08 15:33 編輯

自坐沙發(fā)！

因為近期公司一直遇到安全問題，以及身邊的朋友也遇到安全問題

比如　　　網(wǎng)站被黑　　被注入　　　被Ｄ　　等等
問題多多　　啥都有
作者: qingduo04    時間: 2017-02-08 18:34
本帖最后由 qingduo04 于 2017-02-10 09:00 編輯

只能做板凳了！占座更新，目測此帖會火。



１.你所寫的代碼或者服務器遇到過被黑的情況嗎？如果有敘述下解決方案。
   當前還沒有遇到，不是因為自己寫的代碼或者程序很NB，而是系統(tǒng)處于核心環(huán)境中，對外有多層安全保護，同時系統(tǒng)也沒在DMZ區(qū)，所以受到攻擊的可能性很小。
按照我的理解，對于安全問題，需要從如下角度分析





２.你的代碼與服務器是否有對防黑進行監(jiān)控，或者有什么安全措施？是如何實現(xiàn)的？

３.除了外患，也許還有內憂，如離職人員的代碼后門檢測，運維人員的服務器后門檢測，是否有快速的方法？

４.你對未來的安全提出一些友好的方案。


作者: shang2010    時間: 2017-02-08 19:24
３.除了外患，也許還有內憂，如離職人員的代碼后門檢測，運維人員的服務器后門檢測，是否有快速的方法？


難道你們平時就沒有管理么？？？還是不重視技術的緣故
作者: Fl_wolf    時間: 2017-02-09 20:10
回復 3# qingduo04

所說的 防火墻雙層具體是怎么樣的一個結構？
作者: Fl_wolf    時間: 2017-02-09 20:12
回復 4# shang2010

哪方面的管理？  LDAP這類的還是公司內的管理？
作者: qingduo04    時間: 2017-02-10 08:59
本帖最后由 qingduo04 于 2017-02-10 09:00 編輯

回復 5# Fl_wolf

雙層異構：類似于防火墻需要部署兩套不同廠家的防火墻，避免黑客通過一家防火墻的漏洞就長驅直入了。
作者: Fl_wolf    時間: 2017-02-10 11:24
回復 7# qingduo04

這樣數(shù)據(jù)包處理不會比較復雜，導致影響訪問速度嗎？
作者: forgaoqiang    時間: 2017-02-10 12:26
不一定是代碼問題 服務器肯定是被拿下過 有空分享下
作者: qingduo04    時間: 2017-02-11 09:10
回復 8# Fl_wolf

      不會，現(xiàn)在防火墻性能很好。
并且這個雙層異構不是簡單的某個項目組認為，而是集團組織下發(fā)各個省建設的時候，嚴格要求。
作者: mocou    時間: 2017-02-13 15:40
被東突黑過。。。
作者: wangbin    時間: 2017-02-14 11:09
境外的賭博網(wǎng)站黑過，主要是沒有注意nginx的限制順序，被注入攻擊了。
作者: Purple_Grape    時間: 2017-02-16 17:04
本帖最后由 Purple_Grape 于 2017-02-17 08:58 編輯

１.你所寫的代碼或者服務器遇到過被黑的情況嗎？如果有敘述下解決方案。
遇到過，主要是低級錯誤，1、網(wǎng)工把ssh端口給映射出去了，密碼超級簡單 2、tomcat用root運行，一個漏洞讓系統(tǒng)失守

２.你的代碼與服務器是否有對防黑進行監(jiān)控，或者有什么安全措施？是如何實現(xiàn)的？
第一、防火墻日志監(jiān)控
第二、應用防火墻waf+日志分析
第三、web一般通過反向代理出去，自己無法上網(wǎng)

３.除了外患，也許還有內憂，如離職人員的代碼后門檢測，運維人員的服務器后門檢測，是否有快速的方法？
主要以內網(wǎng)運維，配合服務器操作記錄審計。安全教育為主，善待離職人員，




４.你對未來的安全提出一些友好的方案。
安全是一種習慣和自覺，安全問題也不完全是能力問題，多數(shù)安全問題往往不是疏忽就是缺乏責任感導致。通過培訓可解決多數(shù)安全問題�？梢允羌夹g培訓和企業(yè)文化培訓，提高安全能力，增強安全意識和責任感。


作者: lsstarboy    時間: 2017-02-18 17:38
１.你所寫的代碼或者服務器遇到過被黑的情況嗎？如果有敘述下解決方案。

　　常在河邊走，哪不能濕鞋？大多數(shù)人應該都遇到過。我遇到典型的兩次，一次是在網(wǎng)站上寫了個測試的腳本，文件名沒起好，被黑客猜出來了，泄露了一些信息；另一次是shell漏洞那次，服務器被掛了馬，一個勁向香港的某個機器發(fā)數(shù)據(jù)。前一種情況純屬人為失誤造成的，這個只能平時多小心；后一種沒有好的解決方案，只能平時多留意安全網(wǎng)站，還要加強服務器的監(jiān)控，出現(xiàn)異常抓緊查原因被漏洞，我的服務器ssh心臟出血的那次漏洞處理的很及時，還沒被掛馬。
　
２.你的代碼與服務器是否有對防黑進行監(jiān)控，或者有什么安全措施？是如何實現(xiàn)的？

服務器肯定要有監(jiān)控的，硬件的防火墻先不說，大點的公司都會有，并且供應商也就那幾家，沒有太多可挑選的余地。單說自己做的監(jiān)控，我覺得有幾個層次：
　一、系統(tǒng)級監(jiān)控，包括用戶登錄、系統(tǒng)中的關鍵進程、網(wǎng)卡流量、系統(tǒng)load、內存占用等，這幾個我現(xiàn)在自己寫的腳本，定時發(fā)送到監(jiān)控服務器（可用snmp，syslog等），用戶登錄記錄了用戶名和IP，如果不是常用IP則發(fā)消息報警；進程監(jiān)控主要監(jiān)控進程數(shù)量和pid號；網(wǎng)卡流量也是必須監(jiān)控的，包括發(fā)包數(shù)和字節(jié)數(shù)，超出正常值后也要報警；系統(tǒng)的中斷數(shù)監(jiān)控一下，對于排除問題也是有幫助的；可能的情況還有硬盤的IO數(shù)據(jù)等。
　　這個步驟很多時候只是記錄在本機，其安全性會下降一個層次，因為如果被黑客非法登錄，搞掉監(jiān)控的程序和日志那是必須的。
　二、服務器程序監(jiān)控，比如apache和nginx的監(jiān)控，簡單一點，只監(jiān)控它的日志，特別要監(jiān)控post。我曾接手了一個dedecms的網(wǎng)站，被黑了N次，最后沒辦法開始監(jiān)控日志，配合防火墻，現(xiàn)在已堅持了三年沒大問題了，具體做法：每分鐘分析一次日志，（１）后臺登錄頁和發(fā)帖頁，這幾個頁全部是post，這部分作為白名單，簡單過濾一下post的內容即可，有其他頁面的POST的IP一律拉入黑名單；（２）過濾GET的參數(shù)，發(fā)現(xiàn)特殊字符，則將其IP拉入黑名單；（３）統(tǒng)計非202、302、301的頁面，特別是404的頁面，如果某個IP次數(shù)過多，直接拉黑名單中；（４）首頁的返回字節(jié)數(shù)，一旦發(fā)現(xiàn)超長或超短，則報警。

　三、文件的監(jiān)控，包括源代碼和可執(zhí)行程序，用腳本定期將幾個關鍵的程序，比如nginx、mysqld、.php文件等做個md5或sha1，再順便在/etc、/sbin、/usr/sbin、/lib目錄下find -newer一下，找一下最近更新的文件，將信息發(fā)至監(jiān)控服務器。

　四、日志更位置，不要一直放在/var/log中。雖然這個措施防不了高手并且僅僅是事后諸葛亮，但是防初級黑客和小屁孩練手還是很有用的。

３.除了外患，也許還有內憂，如離職人員的代碼后門檢測，運維人員的服務器后門檢測，是否有快速的方法？
　　沒有這方面的經驗。


４.你對未來的安全提出一些友好的方案。
一、不要將安全完全交給硬件的防火墻，硬件防火墻只能根據(jù)已有的特殊庫來進行操作，會受到很多限制，最好根據(jù)自己的應用來制定合適的防御策略。
二、注重移動安全，大多數(shù)時候，APP相比WEB來說，可以更直接地操作服務器資源，這在方便的同時也增加了出問題的幾率。比如APP一旦被反解，很可能會暴露出關鍵的信息，本人曾反解過一個劣質的APP，竟然找到了數(shù)據(jù)庫的連接密碼，由此可見一斑，并且國內很多APP都是可以被反解/反編譯的。
　　另外寫APP時必須重視通訊的加密和防劫持，畢竟很多人都很隨意地連接wifi熱點，酒店和飯館的熱點不一定安全。
作者: qingduo04    時間: 2017-02-22 19:25
lsstarboy 發(fā)表于 2017-02-18 17:38
１.你所寫的代碼或者服務器遇到過被黑的情況嗎？如果有敘述下解決方案。

　　常在河邊走，哪不能濕鞋？ ...

贊一個，寫的夠詳細
作者: yuanzh78    時間: 2017-02-23 15:18
精彩回復
精彩回復
精彩回復
作者: shenlanyouyu    時間: 2017-02-28 19:02
１.你所寫的代碼或者服務器遇到過被黑的情況嗎？如果有敘述下解決方案。
第一個軟件版本在阿里云服務器運行一個月后，迎來了第二個版本。在該版本中，團隊使用了Redis內存數(shù)據(jù)庫，來提高登錄和支付系統(tǒng)的效率，然而剛上線兩天問題就出現(xiàn)了。由于開發(fā)人員是首次使用Redis，對Redis的掌握程度有限，因此對于Redis存在的漏洞并不知曉。
為了更好地監(jiān)控云服務的運行，應用剛上線就設置了服務器CPU和內存使用率的監(jiān)控的短信通知，在CPU使用率超過40%就發(fā)送通知短信。在應用部署上線的第三天早上，手機剛開機收到多條阿里云的監(jiān)控短信，看完短信感覺不秒，服務器的CPU使用率很高，應用上線開始從來沒有出現(xiàn)這種情況。難道是新上線的應用中程序有問題？
開機遠程連上服務器，運行top命令，發(fā)現(xiàn)一個minerd進程占用很高的CPU，占用了一個CPU 100%額度使用率。這個是什么進程，馬上和后臺開發(fā)人員聯(lián)系確認，應用不會產生minerd進程，后臺開發(fā)人員也不知道m(xù)inerd進程，隱隱感覺服務器被入侵了。這個時候只能借助萬能的搜索引擎了，大家都懂的。

搜索才發(fā)現(xiàn)網(wǎng)上有很多人出現(xiàn)了這種問題，是服務器被入侵，掛了挖礦程序，minerd就是一個挖礦程序。
由于后臺開發(fā)人員是初次使用Redis，Redis綁定在0.0.0.0:6379，默認配置沒有開啟認證，并且沒有添加防火墻規(guī)則避免其他非信任來源ip訪問等，導致云服務器的Redis服務直接暴露在公網(wǎng)上，其他用戶可以直接在非授權情況下直接訪問Redis服務并進行相關操作。然后利用Redis自身的相關方法，可以進行寫文件操作，攻擊者可以成功將自己的公鑰寫入到云服務器的 /root/.ssh 文件夾的authotrized_keys 文件中，進而可以直接登錄云服務器。
解決方法：
http://blog.csdn.net/tjcyjd/article/details/54140321。
http://blog.csdn.net/u013082989/article/details/51971121。


２.你的代碼與服務器是否有對防黑進行監(jiān)控，或者有什么安全措施？是如何實現(xiàn)的？
為了更好地監(jiān)控云服務的運行，應用剛上線就設置了服務器CPU和內存使用率的監(jiān)控的短信通知，在CPU使用率超過40%就發(fā)送通知短信。

３.除了外患，也許還有內憂，如離職人員的代碼后門檢測，運維人員的服務器后門檢測，是否有快速的方法？
日常做好代碼的check in時的review。避免后門。

４.你對未來的安全提出一些友好的方案。

作者: cddy2016    時間: 2017-03-01 16:22
很多公司的服務器，都不安全！可能他們采取了很多措施來保證服務器的安全性，但是卻忘了給服務器來一次徹底地除塵，所以服務器很容易壞的，特別是夏天的時候。
作者: yehuafeilang    時間: 2017-03-03 15:34
對未來的安全提出一些友好的方案：
1、智能化的數(shù)字視頻音頻監(jiān)控。可以分析處理圖像音頻信息。
2、在網(wǎng)的數(shù)據(jù)智能監(jiān)控，通過設定條件達到監(jiān)控目的。
3、主動出擊，利用閑置時段，充分分析掃描。
4、源碼上對后門、漏洞的檢測。



歡迎光臨 Chinaunix (http://72891.cn/) Powered by Discuz! X3.2