Nginx实践--安全升级

以前写了一些nginx的东西，此次继续，主要使用upstream针对proxy_pass转发作个处理
通常状况下咱们在使用nginx反向代理的时候，都是以下配置，

...
location /api {
   proxy_pass https://b.test.com; # 设置代理服务器的协议和地址
   proxy_cookie_domain b.test.com  a.test.com; # 修改cookie，针对request和response互相写入cookie
}       
...

这样就实现了'/api'目录接口的转发。功能是实现了，可是有什么问题么？还真有！
若是咱们能够反向代理，若是别人也知道了咱们的接口域名也不是能够本身搭一个nginx服务器就能够代理到咱们的接口服务器上去？？？是否是感受很危险，是的。。。对此当时作的时候就加了一个临时方案，在接口服务中添加一个ip白名单，白名单中的ip都是nginx服务器的ip，而后就项目上线了。这样也实现了需求，但ip若是被伪造了怎么办？因而咱们想到了另外一个方案，使用内网IP代替对外开放的域名，这样在必定程度上就直接拦截了外部的直接访问，具体实现以下，

upstream apiServer {
    server 10.10.10.10.:8888
}
...
location /api {
   proxy_pass http://apiServer; 
   proxy_cookie_domain apiServer a.test.com; 
}       
...

咱们使用upstream定义了一个apiServer的组，将转发都指向这里，这时至关于咱们把可能存在的用户直接访问接口服务器的可能给关闭了，也就是途中红色的那部分危险操做～～

可能你会想upstream的使用纯属多余，的确当apiServer只有一台机器的时候，这个的确能够不用，可是多台机器的时候，虽然proxy_pass虽然能够定义多条可是太麻烦了。。。使用upstream组统一管理便可，同时使用upstream还有一些优点好比给多个server设置负载均衡，upstream组中支持经过weight参数来设置当前server在负载均衡中所占的比重，此外还能够经过设置backup参数指定某些服务器做为备份机等等。详细的配置内容仍是建议你们参考Nginx upstream官方文档。
此外，除了安全性方面，使用内网ip进行接口转发也省去了转发中的DNS从新解析的过程，有利于大幅提高接口转发效率。同时若不想破坏已经作好的SLB的话，也能够不使用upstream，直接转发到SLB服务器的内网ip应该也是能够的。

综上，在proxy_pass转发中咱们使用了两种方案来对安全性作一些提高

• proxy_pass转发到外网域名，同时在接口服务器上添加访问来源白名单，把nginx服务器的ip写进去
• proxy_pass转发到内网域名，多服务器的话使用upstream统一管理并实现负载均衡，也能提高转发效率

第二种方案是否是通用的呢？这样可行的话，咱们的接口服务器是否是都不用设置外网可访问的域名了呢？
第二种方案是能够通用的，可是这不意味着咱们就能够抛弃外部可访问的域名，由于在一个落地业务中，好比第三方受权、微信支付等状况下外部可访问域名仍是必需要有的。所以只有那些不须要与第三方进行通讯，好比仅供公司内部使用的管理系统等，就能够直接抛弃外网域名了。此时我的建议就是上面两种方案结合一下：

• proxy_pass的转发使用内网ip，来提高转发效率，同时对外部访问添加白名单，只暴露须要和第三方通讯的接口便可。
  这样在安全和效率高上就都能获得必定的提高。

若有错误，欢迎你们指正
好好学习，每天向上～～

---

此处添加一个修正，最第一版原文中在proxy_pass后面咱们使用了https+upstream的方式进行转发，可是在生产环境上发现使用https出现服务器502网关问题。

...
location /api {
   proxy_pass https://apiServer; 
   proxy_cookie_domain apiServer a.test.com; 
}       
...

考虑到内网ip访问，不须要https，因而咱们把https换成了http，问题解决。