VSRC连载系列（2）：VPN真的安全吗？继上周机房排错后，A同学又接到公司需求：总部希望有一个更加灵活的上网环境，希望SOHO员工能便捷的接入公司资源，且出于安全考虑，所有数据必须经过严格的加密传输。于是A同学便想到了EzVPN，EzVPN采用中心站点管理模式，通过动态的分发策略，从而降低远程访问VPN部署的复杂度，在数据加密安全传输的同时还能增加网络的扩展性和灵活性。那么，这个方案是否可行呢？点击以下链接，查看完整内容：http://mp.weixin.qq.com/s?__biz=MzI5ODE0ODA5MQ==&mid=404487823&idx=1&sn=ddd720dfd215eed4d8d1417971bca760#rd

VSRC连载系列（1）：谁动了我的500端口？作为一枚代码小白，周末当然一如往常的宅家学习Coding啦，不过突然接到A同学的求助说上周在机房配置好的VPN现在突然连不上了。而且监控发现流量很大，怀疑是被恶意攻击了。于是在简单了解之后发现是一个普通的站点到站点的IPSec VPN，两端采用ESP加密。这种情况只能一步一步排错：一、基本路由排错1、全局地址可达Site1#ping 101.1.2.3 source 101.1.1.2Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 101.1.2.3, timeout is 2 seconds:Packet sent with a source address of 101.1.1.2!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 16/34/52 ms2、路由可达Site1#show ip routeCodes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2       E1 - OSPF external type 1, E2 - OSPF external type 2       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2       ia - IS-IS inter area, * - candidate default, U - per-user static route       o - ODR, P - periodic downloaded static route, + - replicated routeGateway of last resort is 101.1.1.4 to network 0.0.0.0S*    0.0.0.0/0 [1/0] via 101.1.1.4      2.0.0.0/32 is subnetted, 1 subnetsC        2.2.2.2 is directly connected, Loopback0      101.0.0.0/8 is variably subnetted, 2 subnets, 2 masksC        101.1.1.0/24 is directly connected, FastEthernet0/0L        101.1.1.2/32 is directly connected, FastEthernet0/0点击以下链接，查看完整内容：http://mp.weixin.qq.com/s?__biz=MzI5ODE0ODA5MQ==&mid=403866875&idx=1&sn=fa463a4a02a8dc60767ff12fe3f232ab#rd

当你说数据为王相比数量，我们更应关注数据质量。数据为王本身并没有错，问题是怎样的数据才能为王？典型误区：只要数据多就能解决问题当你说数据为王，通常会伴上大数据、Hadoop、Storm等一系列高大上的名词概念。我所在的团队每一天都在和数据打交道。我们建立了一套以数据为核心的风控运营体系。我们也注意到同行里很多企业都建立起了自身的风控系统，并且“数据为王“常常被大家挂在口边。华丽风控系统背后是强大的数据技术支撑，然而一句“数据为王”却是风控建设过程中无数惨痛经验教训的总结。本篇不谈成功，我们只谈失败，谈谈那些决定风控系统能否真正取得成功的决定性因素。关注数据质量完整性在某款玫瑰金手机首发的秒杀活动中，黄牛动用了有史以来最强大的资源向我们发起了最凶残的抢购请求。此时选购线各个接口开始报错，后端压力骤然飙升，监控系统疯狂告警。为快速问题，团队筛选并封禁了大量IP地址，但仍然不能彻底解决后端系统的压力。大概有上千个的黄牛账号在持续更换IP疯狂请求购物车前端接口，压力传递到了后端。此时除了封禁IP，业务风控团队还需要快速识别黄牛所使用的ID并予以踢下线和冻结。问题来了：通过这些异常IP向服务器发起请求的账户到底有哪些？从了解到的情况看，现有系统的日志包括：Nginx日志和购物车数据库记录。购物车接口请求日志（Nginx）：http://example.com/cart/add.php?&product_id=1111&ip=1.1.1.1购物车业务日志（MySQL）cart_iduser_idproduct_idtime112311112016-03-03 10:00:10245611112016-03-03 10:00:12378944442016-03-03 10:00:13很显然Nginx日志中能够看到接口的参数，有商品，有IP，就缺少UserId。购物车数据库中存储了商品Id和UserId，但却没有IP。在这样的现实条件下，再强大的风控系统也无能为力，因为两组日志数据都不完整，任何一组都不能算是完整的信息。试想，如果接口或MySQL两者中的任何一个能够完整记录一次购物请求的关键日志，业务安全监控绝不会如此被动，很显然我们需要的是这样的日志记录：http://example.com/cart/add.php?&product_id=1111&ip=131.1.1.1&userid=123或者：cart_iduser_idproduct_idclient_iptime11231111131.1.1.12016-03-03 10:00:1024561111208.2.2.22016-03-03 10:00:1237894444127.1.1.12016-03-03 10:00:13准确性经过上一次经验教训，购物车团队依照我们的要求在数据日志中同时增加了用户ID和IP两个信息。那么我们是不是可以轻松应对下一次抢购了呢？鼻青脸肿之后，我们明白——想得太简单了。由于公司网络架构的原因，购物车接口同时接受来自LVS、F5等不同设备的请求，这期间一个负载设备的错误配置导致购物车底层看到的用户IP地址为内网地址，而非用户真实IP！cart_iduser_idproduct_idclient_iptime11231111192.168.9.82016-03-03 10:00:1024561111123.10.1.12016-03-03 10:00:1237894444219.23.2.22016-03-03 10:00:13好吧，如果你看到的IP已经不是真实攻击者的IP，那么如何才能执行封禁IP呢？多样性对异常订单进行二次筛选是风控运营人员每天在做也是最为头疼的工作。举个最简单的例子，下述订单一眼就能看出是异常。order_idorder_timeorder_address12016-04-16 12:00:01广州市.番禺区.氓气氕氖路1号22016-04-16 12:00:02广州市.番禺区.気氘氙洔路2号32016-04-16 12:00:03广州市.番禺区.洣津洦洧路3号42016-04-16 12:00:03广州市.番禺区.紣崔败䴧路4号但是，如果如果面临特征不明显的订单时，单纯依靠订单自身的信息是很难判断这些是否为异常订单。很显然，在分析异常订单时，风控运营人员需要更多的辅助信息以增加识别精准度和降低误报率。针对上述情况，如果增加人机识别等多样性数据，系统或运营人员能够再次降低异常订单的误判order_idorder_timeorder_address页面浏览次数12016-04-16 12:00:01广州市.番禺区.人民路102号2022016-04-16 12:00:02广州市.番禺区.南朝大街105司库书城032016-04-16 12:00:03广州市.番禺区.胡杨小区2幢101042016-04-16 12:00:03广州市.番禺区.区政府大门口对面包子店5这里只增加了一项最近出的PV计算，就能为识别恶意订单提供有力的佐证。数据埋点&审计无数血与泪的经验告诉我们，要做好业务风控，必须要让业务系统提供足够可用的日志记录，有时我们也称之为“埋点“。那么到底哪些信息是关键的，哪些又是必须记录下来的呢？我的团队对过往的日志记录和分析过程做了多次梳理和总结，最终形成如下结论。任何数据埋点必须包含以下几大要素：时间日期时间戳用户用户ID用户登录名用户手机号用户邮箱第三方账户唯一识别号用户付款账户设备IP地址IP段IP地理区域客户端浏览器客户端APP微信H5页面资源用户信息商品信息购物车信息订单信息访问方式Web访问APP访问访问结果成功失败举一个例子：2016-04-19 12:00:01,1234567,customer001@vip.com,13888888888,113.65.254*,广东.广州,login,android,v2.11,failed最终解决问题的是你值得信赖的基础数据和分析方法。最后才是数量好了，我们已经解决了数据质量，接下来我们来解决数量的问题。嗯，我考虑好了，放在下一期：）我将以业务风控为主题进行连载，关注VSRC微信公众号可以第一时间获取信息。变的是笔名，不变的是公众号，关注我吧。原文：http://mp.weixin.qq.com/s?__biz=MzI5ODE0ODA5MQ==&mid=2652277114&idx=1&sn=82afefde2b29c494347c897d211e2ac9#rd