189 8069 5689

如何保证服务器通信安全 为保证服务器操作系统数据安全

如何提高服务器的安全性?

1、系统漏洞的修复

创新互联主要从事网站制作、网站建设、网页设计、企业做网站、公司建网站等业务。立足成都服务开州,10余年网站建设经验,价格优惠、服务专业,欢迎来电咨询建站服务:028-86922220

安装好的系统都会有系统漏洞需要进行补丁,一些高危漏洞是需要我们及时补丁的, 否则黑客容易利用漏洞进行服务器攻击。

2、系统账号优化

我们服务器的密码需要使用强口令,同时有一些来宾账户例如guest一定要禁用掉。

3、目录权限优化

对于不需要执行与写入权限的服务器我们要进行权限修改,确保不把不该出现的的权限暴露给攻击者让攻击者有机可趁。

例如我们的windows文件夹权限,我们给的就应该尽可能的少,对于用户配置信息文件夹,不要给予everyone权限。

4、数据库优化

针对数据密码和数据库端口访问都要进行优化,不要将数据库暴露在公网访问环境。

5、系统服务优化

去除一些不必要的系统服务,可以优化我们系统性能,同时优化系统服务可以提升系统安全性。

6、注册表优化

注册表优化可以提升网络并发能力,去除不必要的端口,帮助抵御snmp攻击,优化网络,是我们优化服务器不可缺少的环节。

7、扫描垃圾文件

垃圾文件冗余可能会造成我们的服务器卡顿,硬盘空间不足,需要我们定期进行清理。

如何做好服务器安全保障策略?

众所周知,服务器在组织运行中起着至关重要的作用,由于企业的数据都在服务器上,所以把服务器保护好,企业的安全能力会有一个大的提升,可是很多企业都没有专业的服务器运维人员,所以很多企业的服务器安全保障就成为了一个大问题。如果有条件可以找专业的厂商,比如青藤云安全,青藤会从以下几个方面来做好安全策略,1、不断升级软件和操作系统。2、将计算机配置为文件备份。3、设置对计算机文件的访问限制。4、做好安全监控。5、安装SSL证书。6、服务器密码安全以及建立由内而外的防御体系。

如何保证Web服务器安全?

一、在代码编写时就要进行漏洞测试。

二、对Web服务器进行持续的监控。

三、设置蜜罐,将攻击者引向错误的方向。

四、专人对Web服务器的安全性进行测试。

在Web服务器的攻防战上,这一个原则也适用。笔者建议,如果企业对于Web服务的安全比较高,如网站服务器上有电子商务交易平台,此时最好设置一个专业的团队。他们充当攻击者的角色,对服务器进行安全性的测试。这个专业团队主要执行如下几个任务。 

一是测试Web管理团队对攻击行为的反应速度。如可以采用一些现在比较流行的攻击手段,对自己的Web服务器发动攻击。当然这个时间是随机的。预先Web管理团队并不知道。现在要评估的是,Web管理团队在多少时间之内能够发现这种攻击的行为。这也是考验管理团队全天候跟踪的能力。一般来说,这个时间越短越好。应该将这个时间控制在可控的范围之内。即使攻击最后没有成功,Web管理团队也应该及早的发现攻击的行为。毕竟有没有发现、与最终有没有取得成功,是两个不同的概念。

二是要测试服务器的漏洞是否有补上。毕竟大部分的攻击行为,都是针对服务器现有的漏洞所产生的。现在这个专业团队要做的就是,这些已发现的漏洞是否都已经打上了安全补丁或者采取了对应的安全措施。有时候我们都没有发现的漏洞是无能为力,但是对于这些已经存在的漏洞不能够放过。否则的话,也太便宜那些攻击者了。

保障接口安全的5种常见方式

一般有五种方式:

1、Token授权认证,防止未授权用户获取数据;

2、时间戳超时机制;

3、URL签名,防止请求参数被篡改;

4、防重放,防止接口被第二次请求,防采集;

5、采用HTTPS通信协议,防止数据明文传输;

所有的安全措施都用上的话有时候难免太过复杂,在实际项目中需要根据自身情况作出取舍,比如可以只使用签名机制就可以保证信息不会被篡改,或者定向提供服务的时候只用Token机制就可以了,如何取舍,全看项目实际情况和对接口安全性的要求。

HTTP协议是无状态的,一次请求结束,连接断开,下次服务器再收到请求,它就不知道这个请求是哪个用户发过来的,但是对我们有权限访问限制的模块而言,它是需要有状态管理的,以便服务端能够准确的知道HTTP请求是哪个用户发起的,从而判断他是否有权限继续这个请求。

Token的设计方案是用户在客户端使用用户名和密码登录后,服务器会给客户端返回一个Token,并将Token以键值对的形式存放在缓存(一般是Redis)中,后续客户端对需要授权模块的所有操作都要带上这个Token,服务器端接收到请求后进行Token验证,如果Token存在,说明是授权的请求。

Token生成的设计要求:

1、应用内一定要唯一,否则会出现授权混乱,A用户看到了B用户的数据;

2、每次生成的Token一定要不一样,防止被记录,授权永久有效;

3、一般Token对应的是Redis的key,value存放的是这个用户相关缓存信息,比如:用户的id;

4、要设置Token的过期时间,过期后需要客户端重新登录,获取新的Token,如果Token有效期设置较短,会反复需要用户登录,体验比较差,我们一般采用Token过期后,客户端静默登录的方式,当客户端收到Token过期后,客户端用本地保存的用户名和密码在后台静默登录来获取新的Token,还有一种是单独出一个刷新Token的接口,但是一定要注意刷新机制和安全问题;

根据上面的设计方案要求,我们很容易得到Token=md5(用户ID+登录的时间戳+服务器端秘钥)这种方式来获得Token,因为用户ID是应用内唯一的,登录的时间戳保证每次登录的时候都不一样,服务器端秘钥是配置在服务器端参与加密的字符串(即:盐),目的是提高Token加密的破解难度,注意一定不要泄漏;

客户端每次请求接口都带上当前时间的时间戳timestamp,服务端接收到timestamp后跟当前时间进行比对,如果时间差大于一定时间(比如:1分钟),则认为该请求失效。时间戳超时机制是防御DOS攻击的有效手段。

写过支付宝或微信支付对接的同学肯定对URL签名不陌生,我们只需要将原本发送给server端的明文参数做一下签名,然后在server端用相同的算法再做一次签名,对比两次签名就可以确保对应明文的参数有没有被中间人篡改过。

签名算法:

1、首先对通信的参数按key进行字母排序放入数组中(一般请求的接口地址也要参与排序和签名,那么需要额外添加url= 这个参数);

2、对排序完的数组键值对用进行连接,形成用于加密的参数字符串;

3、在加密的参数字符串前面或者后面加上私钥,然后用md5进行加密,得到sign,然后随着请求接口一起传给服务器。

注意: 对于客户端的私钥一定要妥善处理好,不能被非法者拿到,如果针对于H5的项目,H5保存私钥是个问题,目前没有更好的方法,也是一致困扰我的问题,如果大家有更好的方法可以留言一起探讨。

客户端第一次访问时,将签名sign存放到服务器的Redis中,超时时间设定为跟时间戳的超时时间一致,二者时间一致可以保证无论在timestamp限定时间内还是外 URL都只能访问一次,如果被非法者截获,使用同一个URL再次访问,如果发现缓存服务器中已经存在了本次签名,则拒绝服务。如果在缓存中的签名失效的情况下,有人使用同一个URL再次访问,则会被时间戳超时机制拦截,这就是为什么要求sign的超时时间要设定为跟时间戳的超时时间一致。拒绝重复调用机制确保URL被别人截获了也无法使用(如抓取数据)。

方案流程:

1、客户端通过用户名密码登录服务器并获取Token;

2、客户端生成时间戳timestamp,并将timestamp作为其中一个参数;

3、客户端将所有的参数,包括Token和timestamp按照自己的签名算法进行排序加密得到签名sign

4、将token、timestamp和sign作为请求时必须携带的参数加在每个请求的URL后边

5、服务端对token、timestamp和sign进行验证,只有在token有效、timestamp未超时、缓存服务器中不存在sign三种情况同时满足,本次请求才有效;

众所周知HTTP协议是以明文方式发送内容,不提供任何方式的数据加密,如果攻击者截取了客户端和服务器之间的传输报文,就可以直接读懂其中的信息,因此HTTP协议不适合传输一些敏感信息,比如信用卡号、密码等。

为了解决HTTP协议的这一缺陷,需要使用另一种协议:安全套接字层超文本传输协议HTTPS,为了数据传输的安全,HTTPS在HTTP的基础上加入了SSL协议,SSL依靠证书来验证服务器的身份,并为客户端和服务器之间的通信加密。

HTTPS也不是绝对安全的,如下图所示为中间人劫持攻击,中间人可以获取到客户端与服务器之间所有的通信内容。

中间人截取客户端发送给服务器的请求,然后伪装成客户端与服务器进行通信;将服务器返回给客户端的内容发送给客户端,伪装成服务器与客户端进行通信。 通过这样的手段,便可以获取客户端和服务器之间通信的所有内容。 使用中间人攻击手段,必须要让客户端信任中间人的证书,如果客户端不信任,则这种攻击手段也无法发挥作用。

针对安全性要求一般的app,可采用通过校验域名,证书有效性、证书关键信息及证书链的方式。

以上说的更多是设计阶段的思路,如果API已经在运行的话,我们则需要通过其他方式,如API网关工具来保护我们的API,这里推荐的是Eolinker,对于上述的5个方面,都有对应的功能做到保护API,可以自己部署开源版本试用一下:


网站名称:如何保证服务器通信安全 为保证服务器操作系统数据安全
分享路径:http://cdxtjz.cn/article/dohidep.html

其他资讯