linux 构建安全的负载均衡集群系统

作者: admin 分类: linux 发布时间: 2018-08-07 18:02

 

  采用负载均衡体系结果的业务系统,可能存在哪些薄弱环节?下边我们以两种负载均衡模型来进行说明。

  直通模式负载均衡。即keepalived + lvs 模式,负载均衡器与后端真实提供服务的主机集群在同一个网络,所有系统都暴露在网络上。从安全角度考量,cdn边缘缓存节点的负载均衡集群、内部网络负载均衡集群,采用直通模式安全隐患较低。

  代理模式负载均衡。只有负载均衡器暴露在外边,而应用服务器集群处于内网,较之直通式负载均衡集群,薄弱环节大大减少。虽然代理模式在性能上,要比直通模式逊色,如果是较为重要的业务系统,考虑经济损失、社会影响等诸多因素,综合权衡,建议以代理模式为佳。

  不要以为,把应用服务器集群放在内网就完事大吉,做到这点,仅仅是基本要求。把应用服务器集群关到内部网络以后,那么就剩下负载均衡器暴露在外。

  

负载均衡安全措施

  

包括但不限于如下几点:

  限制远程ssh登录系统,即不影响正常的登录,又不给心怀不轨的人有机可乘。我通常把sshd监听到内网接口,只有通过私有专用网拨号,才可以进行连接;更进一步,启用秘钥验证。如果条件不具备,最起码把sshd的监听端口改成别的非著名端口。

  专机专用。负载均衡调度器,就只有负载均衡相关的工具被安装和运行。一些人认为,负载均衡转发服务,本身占的计算资源不多,可以复用这些计算资源,比如有的负载均衡上运行mysql从数据库、有的运行zabbix_proxy;更有甚者,有的上边还运行java应用,问基于什么考虑,答:“多一个负载啊”!

  初始安装部署时,尽量用经过测试得、较新的系统及软件版本。及时关注安全漏洞发布信息,出现重大安全漏洞时,尽可能的打官方补丁修补漏洞。

  关闭系统上不必要的服务,对于centos来说,ntsysv是个很便利的工具。centos 7虽然以systemctl代替centos6 以前的工具service ,但ntsysv依然是可用的。

  

安装工具

 

  安装完以后,直接敲指令ntsysv,弹出操作界面,用上下键选定,空白取消(或者选定),如下图所示:

  

ntsysv指令弹出操作界面

 

  通过一通操作以后,系统上剩下ssh、network、rsyslog等少数几项服务。检查一下,看随开机启动的服务是否都精简得合适。无误后直接重启,这样比一个个去杀进程省事。

  有一个问题,值得拿出来讨论,那就是主机防火墙。centos 7默认启用的防火墙,而且规则很多,执行命令“iptables -L -n”可查看其所有规则链。centos 7与centos 6的主机防火墙在操作方法上有很大的差异。就取消防火墙规则而言,centos 6及以前版本,用service iptables stop就使设置失效,而centos 7却是使用systemctl stop firewalld.service。远程网络,不要尝试在centos 7上执行iptables -F,这会把自己关在系统之外。

  一般情况下,我是主动关闭掉主机防火墙,并尽可能的说服决策人购买硬件防火墙,用专业的设施来保护整个网络。在2009年的夏天,连续两周,我负责的网络遭受猛烈的XXX,对外服务基本停摆。最开始的处理措施是在负载后端服务器统计访问ip,排序后做成文件列表,然后写脚本用iptables加载这些文本行,效果不佳。再加码,在负载均衡器用ipvsadm -lcn输出来源ip,排序、去重,再写iptables脚本。开始有些效果,但过不了多久,负载均衡负载飙升,请求到不到后端服务就卡住了。不得已,找了几个安全厂商,部署硬件安全设施在网络入口(透明模式、不改变任何现有网络结构),问题得以解决。

  不确定其它人采取什么样的方案,希望拿出来能分享。

  

应用服务器安全措施

  安全问题最大的风险就在后端应用服务。尽管前端网络做了防护,并且也尽可能地把后端集群部署在内部私有网络。还是可能被有心人找到薄弱环节,从而沦陷。有哪些因素会导致存在安全漏洞?我也给不出准确的答案,还是先看案例吧,都是亲身经历,有一定的代表性。

  

案例一:支付网站商户信息被篡改,大笔资金被冒领

  该项目的规划、实施与日常维护皆有本人负责,典型的负载均衡架构。前端两台服务器做负载均衡,部署keepalived + haproxy;应用服务器部署nginx 与java多实例;数据存储为oracle 11g rac两节点集群。采取的安全措施为:

  网络入口部署防ddos防火墙硬件设施、部署由虚拟专用网(只能这样写才能够绕过关键字屏蔽,读者请见谅)作为系统管理入口。

  所有服务器的sshd都监听到内网私有地址。

  应用服务器集群、数据库集群、备份系统等都划分到内部私有网络。

  nginx以没有shell权限的www用户启动(创建用户时,执行useradd www -s /sbin/nologin)。

  tomcat也用普通帐号www启动。具体做法是修改启动脚本startup.sh,把最后一行注释掉,然后加一行,其内容如下:

  #exec "$PRGDIR"/"$EXECUTABLE" start "$@"

  exec su www -c "$PRGDIR/$EXECUTABLE start $@"

  项目目录定制到单独的分区,与默认的tomcat安装路径完全分离(默认路径/usr/local/tomcat7601/webapps),并且删掉该目录下的所有目录和文件。项目目录的属主全部指定为www,并给予合理的权限(一些人运行程序,只要报权限问题,立马就执行 chmod -R 777 dir ,这些人要严重批评)。

  某一天,运营部门接到某个商户的电话,问为啥中午了还没到账。要了对方的帐号,相关人员登录管理后台一查,发现资金被打入另外的帐号。仔细比对,发现数据被人篡改(身份证照片被替换、银行卡照片也被替换,与图片相对应的用户信息被更改)。资金被系统自动转账到更改后的帐号里,而真正的商户收不到款项。

  一次性被搞走20几万,又不敢告诉商户说是被恶意盗取,只能公司自己赔偿。这是不能这样算了,老板下令,一边去报警,一边排查问题。怎么查?先查系统,再查访问日志。限于自身在安全的经验不够,建议决策人找外援。

  经过好长一段时间的努力,安全外援不仅找到了漏洞的根源,而且还追踪到作恶者的行踪。提交报告及证据给警方后,作恶者在山东诸城被北京西城警方抓获。据交代,为逃避追查,有人出钱带他去越南实施跨境XXX。

  此次作恶者利用了Struts2旧版本的安全漏洞,对版本进行升级,解决掉这个问题。

  

案例二:大流量网站被挂马,关键字搜索跳转到非法博彩网站

  一老牌社区网站,一直由我负责运维管理,随着时间的推移,站点项目越来越多,到目前竟然到达50多个。由于资源有限,业务增长乏力,这些站点都是通过一台nfs共享目录,挂接到各应用服务器集群上,然后通过负载均衡把请求转发到各应用服务器。

  除负载均衡器直接暴露在公网外,其它服务器均在内部私有网络。应用服务器部署nginx及php,各站点在nginx主配置文件里边以include的方式包含起来,每一个站点一行,看配置名称即知对应哪一个站点。有的人喜欢include后用通配符,比如"include *.conf",我不建议使用这个省事的办法,因为你写的时候倒是省事了,等到维护的时候,就没有那么省事。除了没采购硬件防火墙而外,其它安全措施都跟上例相同,不再重复描述。

  由于主站访问量大,在搜索引擎的权重高,因此经常被人盯上,注入恶意代码往其它无关站点引流。中招以后,常采取如下措施:

  排查系统,包括应用服务器、负载均衡等所有主机。

  查看系统进程,看是否有不熟悉的、或者异常的进行在运行;

  查看网络状态,简单的执行netstat,更精准一点的,用ipraf或者ifstat;

  查看系统账号,看/etc/passwd是否有异常,新增账号时是否配置不当(如www账号给了/bin/bash);

  检查计划任务crontab,不光检查root账号的,还要对普通帐号进行核查,指令形如“crontab -u www -l”;

  重点关照一下目录/tmp,用ls -al /tmp,很可能在此处发现蛛丝马迹。

  使用工具chkrootkit检查系统文件有没有被恶意者替换。

  分析web访问日志,根据关键字进行筛选、排序、去重等处理,寻找可疑之处。

  用360在线安全监测,域名是webscan.360.cn,注册用户后,根据提示下载验证文件。验证通过以后,就可以在360网站的页面执行扫描操作。

  专用漏洞扫描工具,如acunetix 10及以上版本。不过执行扫描后,效果甚微。因为站点太多,扫描一个站点都要花费很长的时间。不能确定漏洞在哪里,可能在本站点,也可能在其它站点(共享目录,共享nginx及php),要想全部扫完,基本没可能。

  

终极措施:拆分与隔离

  在得到支持以后,一些站点被迁移到公有云;剩下来的站点,通过服务器虚拟化,创建若干虚拟机,彻底从nfs共享里边剥离出来。最终目标是一个虚拟机对应一个站点,访问量大的、重要性的站点,部署到多个虚拟机上,做成负载均衡集群。这样一来,即便有站点被攻陷,也不至于全军覆没。到本文撰写时,已经隔离了一大半的站点,被黑的几率大大降低。等迁移完毕,如果又被黑掉,那么存在问题的站点就只能是它本身了,排查问题也容易定位。

  

案例三:误开监听,服务器变挖矿机

  某位老兄新入职一地产公司,负责服务器运维,刚上任就火急火急地找过来,说服务器被黑掉了,表现状况为cpu负载高。我一听,就怀疑是被人拿下系统,多半是当矿机使了。他在微信里发了几个截图,以我的经验定是门罗币挖矿程序。

  在了解他的系统架构以后,给他临时做了处理。中招的服务器,处于负载均衡集群的内部网络,我检查服务器ip地址的时候,发现那台服务器上多了一个公网地址,nginx倒是监听到那个内网ip,但有个监听是所有网络接口,它就是redis。

  

nginx倒是监听

 

  通过了解,是有人觉得服务器资源还有空余,就安装了一个redis服务此主机。另外在别的网络,有一个服务要临时访问此redis,因此把此服务器临时加了一个公网ip。再确认不会再有外网请求此redis服务以后,关闭那个公网ip地址,并且再改一下redis配置文件,bind这一样直接写上内网私有地址,如下所示:

  bind 172.16.23.129

  事后建议他们单独用主机运行redis,不要跟其它服务混用。

  安全这事还挺复杂的,涉及的面也很广,远不止文中所列几例。有些问题,运维人员可以从系统层面加以解决,但更多时候,代码层面及业务逻辑层面的漏洞,就无能无力了。负载均衡只解决了可用性问题,不解决安全问题,但作为运维人员,安全也是份内之事。除了紧跟形势抓紧学习外,还应该了解业务,跟其它人员通力合作,共同维护系统安全。


 

Linux 命令大全

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!