手机的防火墙怎么样能爬？

专利名称：实现手机防火墙的方法

技术领域：

本发明涉及一种实现防火墙的方法，尤指一种实现手机防火墙的方法。

背景技术：

现在大部分的手机都具有防火墙的功能，能让用户屏蔽掉一些不希望接听的电话 或短信。它们的实现原理基本上都是根据用户手机中存储的号码来进行比对。需要用户根 据自己的通讯薄来挑选一些电话号码，并选择针对这些号码手机的对应动作，如选择接听 或者屏蔽等。这种防火墙的实现都有一个前提，就是手机必须清楚的知道需要屏蔽的电话 号码或者全部接听或者全部不接听，但当用户希望屏蔽一些只能记住部分号码的电话或者 某些号码段或者某些区域的电话的时候现在的方法就很难做到。

发明内容

鉴于以上内容，有必要提供一种实现手机防火墙的方法。一种实现手机防火墙的方法，包括以下步骤一手机接收一具有一接入号码的信息请求；所述手机判断所述接入号码是否满足一拒绝条件，所述拒绝条件包括用至少一位 数字号码及一变量符号表示的电话号码区间；若所述接入号码符合拒绝条件，则所述手机拒绝所述接入号码的信息请求。相对现有技术，本发明实现手机防火墙的方法的较佳实施方式中，所述防火墙应 用程序根据所述拒绝条件判断是否屏蔽所述号码，方便实用。

图1为本发明实现手机防火墙的方法的较佳实施方式的整体架构图。图2为本发明实现手机防火墙的方法的较佳实施方式的流程图。图3为本发明实现手机防火墙的方法的较佳实施方式的第一示意图。图4为本发明实现手机防火墙的方法的较佳实施方式的第二示意图。图5为本发明实现手机防火墙的方法的较佳实施方式的第三示意图。图6为本发明实现手机防火墙的方法的较佳实施方式的第四示意图。

Linux是学习曲线比较陡峭的学科，刚开始学习有些难度 ，入门后就相对比较轻松了。学习Linux大部分做的是运维工程师或者云计算工程师。

运维不仅仅是懂Linux就行，因为还有一大部分的Windows运维，最近看一个报道说，windows的服务器占了47.71%。嗯，向windows运维人员致敬。当然我们这篇文章不是说运维除了懂Linux，还要懂Windows，而是涉及运维的其他方方面面。

环境部署

一开始这个世界是开发的，然后才是运维的。

开发实现产品逻辑，将产品开发完成后，然后提交运维进行部署。此时允许就需要准备好部署环境，如部署在Linux服务器上，安装相应的软件，如Apache、Nginx、tomcat、JDK、PHP、MySQL等等。你不能只装了软件吧，还需要看看具体是哪个版本，java 7 和java 8 的差别还是有点的，php5和php7也有些语法不兼容。把软件都安装好了，就可以上线了？还是不行。还需要测试吧，那就还需要部署一套测试环境。有些时候，开发环境也是需要运维来部署的。

排错和调优

事情从来都没有一帆风顺的。

上线没多久，服务就502了，还不被老板骂死。尽管你有一肚子的委屈，我只是个运维，代码不是我写的，为什么要我来背这锅？！委屈归委屈，服务访问不了了，就是运维的事。尽快定位问题，解决问题才是王道。怎么来定位问题呢？最简单直接的办法就是看日志，看系统日志，看软件相关的日志，结合故障现象和经验，快速的进行定位和恢复。然后就是总结经验，吸取教训，写事故报告。OK，现在你知道，需要对系统环境需要进行一定的调优 *** 作，不再做背锅侠。

相关技术: top, vmstat, iftop, awk, sed, sar, iostat, strace, ...

备份

做最好的计划，做最坏的打算。

前不久的gitlab删库事件的教训犹在眼前，丢失了几小时的数据，虽然大部分的备份策略都失效了，但还是挽救了几小时前的一个备份，才没有造成更大的数据丢失和公司损失。我们需要对设备进行备份冗余，需要对数据库进行备份及离线备份，需要对网站静态进行备份冗余，需要对机房进行备用，能做到双活，那是更好的啦。

相关技术: rsync, crontab, lvm快照, mysqldump, extrabackup, 完全备份, 差异备份, 增量备份, 离线异地备份, ...

高可用和集群

没有永垂不朽，我们不能保证硬件24小时在线，但需要保障服务24小时在线。

出现故障后，如果做好高可用和冗余，故障自动切换，移除故障节点，那样也就保障了服务的实时在线。在老板和用户不知情的情况下，悄么的把故障处理好的，KPI算是保住了，奖金也许就会有的吧。

相关技术: F5, Nginx, LVS, HA-proxy, MHA, Zookeeper, 各种其他分布式集群方案, ...

监控告警

运维工程师的第一次解放运动。

时刻担心网站挂掉，一年365天、每周7天、每天24小时，时刻保持精神高度紧张，就算你是神仙都会撑不住的。我们需要一个机器来监督其他的机器工作，我们需要解放我们自己。当有故障发生的时候，通过短信、微信、钉钉、邮件等等通知对应的运维工程师来处理，甚至是自动切换或摘除故障节点，然后我们离线对故障节点进行问题排查。

相关技术：Zabbix, Nagios, Cacti, Prometheus, open-falcon, Ganglia, sar, ...

安全和审计

狂奔在互联网的康庄大道上，不过有些人是在裸奔。

不安全的网络环境和服务器配置，无异于在网络世界裸奔，任何人都可以窥探你的隐私。你的应用是否做了SQL防注入？你的防火墙是否开启？是否还在用root+密码的方式登录服务器？网站开启了https么？是否对系统 *** 作进行审计？

相关技术: iptables, firewalld, waf, auditd, 各服务的正确配置, ...

自动化和DevOps

运维工程师的第二次解放运动。

偷懒是社会进步的第一动力。聪明的我们怎么会让自己一直在重复枯燥的事情上浪费时间，装系统、部署环境、发版本、批量 *** 作，把这一切交给程序去实现吧，我们需要的是享受生活。

相关技术: shell, python, go, rundeck, ansible, saltstack, puppet, chef, cobbler, fabric, ...

虚拟化和云服务

正在发生的一场运维革命。

这场革命的发起人是买书的亚马逊，这家伙希望卖一切可以卖的东西，包括自己闲置的服务器资源。现在国内的阿里云和腾讯云也发展得如日中天，他们几乎提供了运维所需要的一切，甚至可以让一个公司不再需要运维的岗位。你需要服务器，只需要几秒钟，就可以创建一台。你需要数据库集群，只需要鼠标点击几下，就可以开通。

相关技术：docker, Moby, kubernetes, Xen, CoreOS, Hyper-V, KVM, ...

模式一：透明代理模式（网桥代理模式）

原理：

1、当WEB客户端对服务器有连接请求时，TCP连接请求被WAF截取和监控。WAF偷偷的代理了WEB客户端和服务器之间的会话，将会话分成了两段，并基于桥模式进行转发。

2、从WEB客户端的角度看，WEB客户端仍然是直接访问服务器，感知不到WAF的存在；

3、从WAF工作转发原理看和透明网桥转发一样。

优势：

1、对网络的改动最小，可以实现零配置部署；

2、通过WAF的硬件Bypass功能在设备出现故障或者掉电时可以不影响原有网络流量，只是WAF自身功能失效；

3、无需配置映射关系

缺点:

1、网络的所有流量（HTTP和非HTTP）都经过WAF，对WAF的处理性能有一定要求；

2、采用该工作模式无法实现服务器负载均衡功能；

3、需配置映射关系

模式二：反向代理模式

原理：

1、将真实服务器的地址映射到反向代理服务器上，此时代理服务器对外就表现为一个真实服务器。由于客户端访问的就是WAF，因此在WAF无需像其它模式（如透明和路由代理模式）一样需要采用特殊处理去劫持客户端与服务器的会话然后为其做透明代理。

2、当代理服务器收到HTTP的请求报文后，将该请求转发给其对应的真实服务器。后台服务器接收到请求后将响应先发送给WAF设备，由WAF设备再将应答发送给客户端。

和透明代理的唯一区别是——

透明代理客户端发出的请求的目的地址就直接是后台的服务器，所以透明代理工作方式不需要在WAF上配置IP映射关系。

优势：

可以在WAF上同时实现负载均衡；

缺点：

1、需要对网络进行改动，配置相对复杂；

2、除了要配置WAF设备自身的地址和路由外，还需要在WAF上配置后台真实WEB服务器的地址和虚地址的映射关系；

3、另外如果原来服务器地址就是全局地址的话（没经过NAT转换），还需要改变原有服务器的IP地址以及改变原有服务器的DNS解析地址。

模式三：路由代理模式

与网桥透明代理的唯一区别是——

该代理工作在路由转发模式而非网桥模式，其它工作原理都一样。由于工作在路由（网关）模式因此需要为WAF的转发接口配置IP地址以及路由。

优势：

1、对网络进行简单改动，要设置该设备内网口和外网口的IP地址以及对应的路由；

2、可以直接作为WEB服务器的网关，但是存在单点故障问题；

缺点：

1、不支持服务器负载均衡功能；

2、存在单点故障

3、要负责转发所有的流量

模式四：端口镜像模式

原理：

1、只对HTTP流量进行监控和报警，不进行拦截阻断；

2、该模式需要使用交换机的端口镜像功能，也就是将交换机端口上的HTTP流量镜像一份给WAF；

3、对于WAF而言，流量只进不出。

优势：

1、不需要对网络进行改动；

2、它仅对流量进行分析和告警记录，并不会对恶意的流量进行拦截和阻断；

3、适合于刚开始部署WAF时，用于收集和了解服务器被访问和被攻击的信息，为后续在线部署提供优化配置参考。

4、对原有网络不会有任何影响。

缺点：

不会对恶意的流量进行拦截和阻断。

---