【大话IT】你的业务安全吗？你的机器安全吗？(服务器安全与网络安全的开放性讨论)

mocou

被东突黑过。。。

wangbin

境外的赌博网站黑过，主要是没有注意nginx的限制顺序，被注入攻击了。

Purple_Grape

１.你所写的代码或者服务器遇到过被黑的情况吗？如果有叙述下解决方案。
遇到过，主要是低级错误，1、网工把ssh端口给映射出去了，密码超级简单 2、tomcat用root运行，一个漏洞让系统失守

２.你的代码与服务器是否有对防黑进行监控，或者有什么安全措施？是如何实现的？
第一、防火墙日志监控
第二、应用防火墙waf+日志分析
第三、web一般通过反向代理出去，自己无法上网

３.除了外患，也许还有内忧，如离职人员的代码后门检测，运维人员的服务器后门检测，是否有快速的方法？
主要以内网运维，配合服务器操作记录审计。安全教育为主，善待离职人员，




４.你对未来的安全提出一些友好的方案。
安全是一种习惯和自觉，安全问题也不完全是能力问题，多数安全问题往往不是疏忽就是缺乏责任感导致。通过培训可解决多数安全问题。可以是技术培训和企业文化培训，提高安全能力，增强安全意识和责任感。

lsstarboy

１.你所写的代码或者服务器遇到过被黑的情况吗？如果有叙述下解决方案。

　　常在河边走，哪不能湿鞋？大多数人应该都遇到过。我遇到典型的两次，一次是在网站上写了个测试的脚本，文件名没起好，被黑客猜出来了，泄露了一些信息；另一次是shell漏洞那次，服务器被挂了马，一个劲向香港的某个机器发数据。前一种情况纯属人为失误造成的，这个只能平时多小心；后一种没有好的解决方案，只能平时多留意安全网站，还要加强服务器的监控，出现异常抓紧查原因被漏洞，我的服务器ssh心脏出血的那次漏洞处理的很及时，还没被挂马。
　
２.你的代码与服务器是否有对防黑进行监控，或者有什么安全措施？是如何实现的？

服务器肯定要有监控的，硬件的防火墙先不说，大点的公司都会有，并且供应商也就那几家，没有太多可挑选的余地。单说自己做的监控，我觉得有几个层次：
　一、系统级监控，包括用户登录、系统中的关键进程、网卡流量、系统load、内存占用等，这几个我现在自己写的脚本，定时发送到监控服务器（可用snmp，syslog等），用户登录记录了用户名和IP，如果不是常用IP则发消息报警；进程监控主要监控进程数量和pid号；网卡流量也是必须监控的，包括发包数和字节数，超出正常值后也要报警；系统的中断数监控一下，对于排除问题也是有帮助的；可能的情况还有硬盘的IO数据等。
　　这个步骤很多时候只是记录在本机，其安全性会下降一个层次，因为如果被黑客非法登录，搞掉监控的程序和日志那是必须的。
　二、服务器程序监控，比如apache和nginx的监控，简单一点，只监控它的日志，特别要监控post。我曾接手了一个dedecms的网站，被黑了N次，最后没办法开始监控日志，配合防火墙，现在已坚持了三年没大问题了，具体做法：每分钟分析一次日志，（１）后台登录页和发帖页，这几个页全部是post，这部分作为白名单，简单过滤一下post的内容即可，有其他页面的POST的IP一律拉入黑名单；（２）过滤GET的参数，发现特殊字符，则将其IP拉入黑名单；（３）统计非202、302、301的页面，特别是404的页面，如果某个IP次数过多，直接拉黑名单中；（４）首页的返回字节数，一旦发现超长或超短，则报警。

　三、文件的监控，包括源代码和可执行程序，用脚本定期将几个关键的程序，比如nginx、mysqld、.php文件等做个md5或sha1，再顺便在/etc、/sbin、/usr/sbin、/lib目录下find -newer一下，找一下最近更新的文件，将信息发至监控服务器。

　四、日志更位置，不要一直放在/var/log中。虽然这个措施防不了高手并且仅仅是事后诸葛亮，但是防初级黑客和小屁孩练手还是很有用的。

３.除了外患，也许还有内忧，如离职人员的代码后门检测，运维人员的服务器后门检测，是否有快速的方法？
　　没有这方面的经验。


４.你对未来的安全提出一些友好的方案。
一、不要将安全完全交给硬件的防火墙，硬件防火墙只能根据已有的特殊库来进行操作，会受到很多限制，最好根据自己的应用来制定合适的防御策略。
二、注重移动安全，大多数时候，APP相比WEB来说，可以更直接地操作服务器资源，这在方便的同时也增加了出问题的几率。比如APP一旦被反解，很可能会暴露出关键的信息，本人曾反解过一个劣质的APP，竟然找到了数据库的连接密码，由此可见一斑，并且国内很多APP都是可以被反解/反编译的。
　　另外写APP时必须重视通讯的加密和防劫持，毕竟很多人都很随意地连接wifi热点，酒店和饭馆的热点不一定安全。

qingduo04

lsstarboy 发表于 2017-02-18 17:38
１.你所写的代码或者服务器遇到过被黑的情况吗？如果有叙述下解决方案。

　　常在河边走，哪不能湿鞋？ ...

赞一个，写的够详细

yuanzh78

精彩回复
精彩回复
精彩回复

shenlanyouyu

１.你所写的代码或者服务器遇到过被黑的情况吗？如果有叙述下解决方案。

第一个软件版本在阿里云服务器运行一个月后，迎来了第二个版本。在该版本中，团队使用了Redis内存数据库，来提高登录和支付系统的效率，然而刚上线两天问题就出现了。由于开发人员是首次使用Redis，对Redis的掌握程度有限，因此对于Redis存在的漏洞并不知晓。

为了更好地监控云服务的运行，应用刚上线就设置了服务器CPU和内存使用率的监控的短信通知，在CPU使用率超过40%就发送通知短信。在应用部署上线的第三天早上，手机刚开机收到多条阿里云的监控短信，看完短信感觉不秒，服务器的CPU使用率很高，应用上线开始从来没有出现这种情况。难道是新上线的应用中程序有问题？
开机远程连上服务器，运行top命令，发现一个minerd进程占用很高的CPU，占用了一个CPU 100%额度使用率。这个是什么进程，马上和后台开发人员联系确认，应用不会产生minerd进程，后台开发人员也不知道minerd进程，隐隐感觉服务器被入侵了。这个时候只能借助万能的搜索引擎了，大家都懂的。

搜索才发现网上有很多人出现了这种问题，是服务器被入侵，挂了挖矿程序，minerd就是一个挖矿程序。
由于后台开发人员是初次使用Redis，Redis绑定在0.0.0.0:6379，默认配置没有开启认证，并且没有添加防火墙规则避免其他非信任来源ip访问等，导致云服务器的Redis服务直接暴露在公网上，其他用户可以直接在非授权情况下直接访问Redis服务并进行相关操作。然后利用Redis自身的相关方法，可以进行写文件操作，攻击者可以成功将自己的公钥写入到云服务器的 /root/.ssh 文件夹的authotrized_keys 文件中，进而可以直接登录云服务器。
解决方法：

http://blog.csdn.net/tjcyjd/article/details/54140321。

http://blog.csdn.net/u013082989/article/details/51971121。

２.你的代码与服务器是否有对防黑进行监控，或者有什么安全措施？是如何实现的？
为了更好地监控云服务的运行，应用刚上线就设置了服务器CPU和内存使用率的监控的短信通知，在CPU使用率超过40%就发送通知短信。

３.除了外患，也许还有内忧，如离职人员的代码后门检测，运维人员的服务器后门检测，是否有快速的方法？
日常做好代码的check in时的review。避免后门。

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

cddy2016

很多公司的服务器，都不安全！可能他们采取了很多措施来保证服务器的安全性，但是却忘了给服务器来一次彻底地除尘，所以服务器很容易坏的，特别是夏天的时候。

yehuafeilang

对未来的安全提出一些友好的方案：
1、智能化的数字视频音频监控。可以分析处理图像音频信息。
2、在网的数据智能监控，通过设定条件达到监控目的。
3、主动出击，利用闲置时段，充分分析扫描。
4、源码上对后门、漏洞的检测。