如何做好日常运维的安全工作

一、主动与被动发现漏洞

这里的主动是指安全工程师主动去做的事情,而被动并不是被动挨打,而是积极去获取信息,积极防御。

因为攻防之间信息不对称,很多攻击、利用方式及漏洞安全工程师不一定能第一时间获取到信息

就导致了服务器被黑,出现被上传webshell无外乎这集中情况:

使用开源程序出现高危漏洞被攻击者上传webshell,服务器配置错误导致攻击者利用运维缺陷上传webshell

程序员编写代码存在诸如sql注入、文件包含,命令执行问题被攻击者发现并利用导致被上传webshel

那是不是说作为防御者我们就一定是被动挨打的呢?答案当然是否定的

如果运维安全做的好的情况下,会在服务器上线初期做安全检查将加固服务做成加固基线包

后期邀请外部人员进行渗透测试来检查企业安全情况,安全基础就牢靠。

从主动来说,企业可以通过这些办法来将攻击者的想法消灭在萌芽之中。

1、积极主动的做好对系统加固工作,坚决消灭弱口令、回收外网默认管理后台
    (能回收的回收,不能回收的做好访问控制),对诸如tomcat、jboss、resin之类的服务器做好加固
    避免出现弱口令,因为互联网上每时每刻都有人来通过这几种服务来抓肉鸡。
   
2、对于漏洞的修复不能只仅限于加固还要主动去发现,需要定期对生产环境和web进行扫描
    其中外网端口扫描需要结合资产进行,如果不能结合资产,扫描的结果会差强人意。
   
3、对企业所使用的开源程序另外诸如webserver、第三方中间件都有深入了解
     并关注这些app近期存在安全风险:比如struts漏洞
     如果能早发现事情也可控制(通过关注乌云、微博等来及时获取信息)
     其次是权限控制,在struts漏洞中,使用root运行的struts2
     受影响最严重而运行权限为tomcat之类的较轻,较轻不是说不被脱裤
     而是攻击者没有权限对服务器来做更进一步操作比如rm -rf /,所以对于权限的控制也需要考虑到加固中去
     
4、被动发现漏洞可以依靠对乌云等平台的漏洞提交来预测可能爆发的漏洞情况
     并且结合第3点对应用做检测,如果发现漏洞了则快速修复,将不会到被攻击者上传webshell的情况


二、监控为主分析为辅

监控的重要性不需要在陈述,在城市的各个角度都有监控摄像头,监控的作用是属于事中或者事后阶段

举个例子,某人犯罪如果没有监控的情况下,无法追溯,这时候如果有监控的话就可以对其行为做分析和追溯。

举一反三,在企业安全防护方面也可以这样做,通过部署ossec之类的行为监控,对攻击者的行为做检测

比如对于webshell的检测来说,更关注”行为”,啥叫行为呢,你的一举一动都是行为,上传了文件,修改了权限

删除了权限这些都该被记录下来,而类似ossec之类的监控工具可以做到,当然你也可以编写脚本来对目录做实时检测

分析为辅,可以从多点上来结合,比如攻击者对于网站的注入行为,都会触发记录,记录到log里,攻击者对ssh的

扫描行为,都会被记录到日志里,而这些都可以用作对攻击者的行为分析,更超前一些恶意的扫描都可以算作是行为

并且这些行为都是可以分析和追溯攻击者的,其次日志需要备份到远程,并且可以利用大数据日志分析利器splunk

来对日志分析,备份到远程也导致了攻击者删除本机日志时能被追溯到。对于webshel检测来说,可以从日志里进行

分析,因为任何攻击者的操作都会在日志里显现记录,这时候只要有足够的日志分析能力就可以对产生的webshell

揪出来,使攻击者无处遁形。

最后说说运维安全,运维安全工作本来其实是工作范畴的事,但运维做不好这部分工作或者说大多数运维对安全

的理解并不深入,所以企业有了运维安全这个职位,或者你可以把它叫做安全运维

运维安全需要有较宽的知识面来撑起企业安全的一片天。

有一个朋友是做游戏的,他告诉我他们公司关于ssh安全方面就有五层验证!

好吧,可能对于一些不是很注重安全的运维小伙伴来说,弄那么复杂干嘛?

甚至有的公司直接root登陆(很危险),
甚至有的ssh默认端口都不改

我个人认为不一定安全做的那么多

(当然要根据公司业务具体环境具体来定)但起码一些基本的安全方面要做到位!

下面是我多年实战个人总结一些方法,介绍并分享给大家!

三、常用的服务器安全方面的措施

1、硬防火墙。

通过硬件防火墙acl策略也决定是否可以访问某台主机

2、软防火墙    [常用]

比如iptables,tcpwrappers,防护软件等,内部对主机进一步进行限制

3、修改默认的ssh端口    [必用]

默认是22,建议改成五位。

4、密码要符合复杂性要求,防止暴力破解   [必用]

避免ssh暴力破解,建议密码稍微复杂一些,符合四分之三原则!

5、禁止root登陆             [必用]

禁止root远程ssh登录

在/etc/ssh/sshd_config设置:PermitRootLogin no:

禁止root本机登录(根据具体环境,这个不是很必要)

将 auth required pam_succeed_if.so user != root quiet

添加到/etc/pam.d/login 文件第一行

6、禁止密码登陆            [常用]

删除不必要的账号,并禁止用户密码登陆

7、公钥私钥认证            [常用]

通过公钥私钥rsa2048,并设置复杂性密码

8、LDAP等方式统一认证登陆

通过对ssh账号集中化管理,进一步提升安全

9、对secure日志进行日志切割,通过脚本,对于不安全的访问ip进行过滤并报警

secure日志记录着用户远程登陆的信息,可通过查看此日志排查不安全因素。

10、搭建日志服务器,对secure日志进行监控。排查不安全因素

一个好的日志服务器,可大大减轻管理员的工作,并方便管理。

时间: 2024-11-09 01:53:27

如何做好日常运维的安全工作的相关文章

日常运维工作中如何确保你的linux操作系统安全

在现在这个世道中,Linux操作系统的安全是十分重要的.但是,你得知道怎么干.一个简单反恶意程序软件是远远不够的,你需要采取其它措施来协同工作.下面是日常运维工作中常用的几种Linux安全的策略方法. 1. 使用SELinux SELinux是用来对Linux进行安全加固的,有了它,用户和管理员们就可以对访问控制进行更多控制.SELinux为访问控制添加了更细的颗粒度控制.与仅可以指定谁可以读.写或执行一个文件的权限不同的是,SELinux可以让你指定谁可以删除链接.只能追加.移动一个文件之类的

mysql日常运维与参数调优

日常运维 DBA运维工作 日常 导数据,数据修改,表结构变更 加权限,问题处理 其它 数据库选型部署,设计,监控,备份,优化等 日常运维工作: 导数据及注意事项 数据修改及注意事项 表结构变更及注意事项 加权限及注意事项 问题处理,如数据库响应慢 导数据及注意事项 数据最终形式(csv,sql文本,还是直接导入某库中) 导数据方法(mysqldump,select into outfile,) 注意事项 导出为csv格式需要file权限,并且只能数据库本地导 避免锁库锁表(mysqldump使用

zookeeper 用法和日常运维

本文以ZooKeeper3.4.3版本的官方指南为基础:http://zookeeper.apache.org/doc/r3.4.3/zookeeperAdmin.html,补充一些作者运维实践中的要点,围绕ZK的部署和运维两个方面讲一些管理员需要知道的东西.本文并非一个ZK搭建的快速入门,关于这方面,可以查看<ZooKeeper快速搭建>. 1.部署 本章节主要讲述如何部署ZooKeeper,包括以下三部分的内容: 系统环境 集群模式的配置 单机模式的配置 系统环境和集群模式配置这两节内容大

hadoop日常运维与升级总结

日常运维 升级 问题处理方法 日常运维 进程管理 由于配置文件的更改,需要重启生效, 或者是进程自己因某种致命原因终止, 或者发现进程工作出现异常等情况下,需要进行手动进程的关闭或启动, 或者是增删节点过程中的需要, 进程的关闭与启动,使用 hadoop-daemon.sh start|stop datanode/namenode/journalnode/zkfc yarn-daemon.sh start|stop nodemanager/resourcemanager 检查进程是否完成关闭:

做Linux运维,每日工作职责有哪些?

Linux系统在互联网公司应用越来越多,也有不少的朋友愿意加入运维的行列中,那么,运维每天都做什么工作呢? 运维人员做事需遵循"简单.易用.高效"的原则.对于运维服务有3大宗旨:1.企业数据安全保障.2.7*24小时业务持续提供服务.3.不断提升用户感受.体验. 初中级运维的日常涉及工作: 1.评估产品需求及发展需求,设计网站架构. 2.选择IDC公司.云产品,CDN等产品. 3.采购服务器.安装系统.配置服务.服务器IDC上架. 4.调试网络.优化系统及服务. 5.上线代码.配合研发

Hbase 日常运维

1.1监控Hbase运行状况 1.1.1操作系统 1.1.1.1IO a.群集网络IO,磁盘IO,HDFS IO IO越大说明文件读写操作越多.当IO突然增加时,有可能:1.compact队列较大,集群正在进行大量压缩操作. 2.正在执行mapreduce作业 可以通过CDH前台查看整个集群综合的数据或进入指定机器的前台查看单台机器的数据: b.Io wait 磁盘IO对集群的影响比较大,如果io wait时间过长需检查系统或磁盘是否有异常.通常IO增加时io wait也会增加,现在FMS的机器

MySQL 日常运维业务账号权限的控制

在MySQL数据库日常运维中,对业务子账号的权限的统一控制十分必要. 业务上基本分为读账号和写账号两种账号,所以可以整理为固定的存储过程,让数据库自动生成对应的库的账号,随机密码.以及统一的读权限,写权限.(这里没有对 host进行过多的限制.只赋给通用的192.168.% .有兴趣的同学可以在存储过程加个参数,对host 控制) delimiter // set session sql_log_bin=OFF; drop PROCEDURE IF EXISTS `usercrt` // CRE

Openstack云计算项目实施其二(安装后日常运维)

5 安装后日常运维   运维基本的操作都在控制节点上的,较为方便的方式就是在openstack 的 dashboard(仪表盘)中进行,进入 dashboard 的方式就是直接在浏览器中输入控制节点的 IP 地址.(需要注意的是浏览器选择方面最好选择火狐浏览器或则谷歌浏览器,因为相对于 IE 浏览器而言,前面两个浏览器对于 openstack 的支持性要好,使用 IE 会在打开实例控制台时无法进入,出现"No vnc...."的错误信息) 用户名和密码放在控制节点/root 下,存放在

kafka知识体系-日常运维命令

本文主要讲解kafka日常运维的命令,包括topic管理.性能测试脚本. kafka版本0.10.0,安装步骤见大数据平台搭建-kafka集群的搭建 常用脚本 如下所有的命令均基于KAFKA_HOME=/wls/oracle/kafka ,服务器列表如下: 10.20.112.59 10.20.112.64 10.20.112.65 10.20.116.129 10.20.116.175 创建topic /wls/oracle/kafka/bin/kafka-topics.sh --zookee