打造更安全的防火墙WEB安全

打造更安全的防火墙WEB安全（共5篇）

打造更安全的防火墙WEB安全篇1

只开放必要的端口，关闭其余端口.因为在系统安装好后缺省情况下,一般都有缺省的端口对外开放，

就会利用扫描工具扫描那些端口可以利用，这对安全是一个严重威胁，本人现将自己所知道的端口公布如下(如果觉得还有危险需要过滤的,请联系本人：OICQ 250875628

端协议应用程序

21 TCP FTP

25 TCP SMTP

53 TCP DNS

80 TCP HTTP SERVER

1433 TCP SQL SERVER

5631 TCP PCANYWHERE

5632 UDP PCANYWHERE

6(非端口) IP协议

8(非端口) IP协议

那么,我们根据自己的经验,将下面的端口关闭

TCP

25 TCP SMTP

53 TCP DNS

135epmap

138[冲击波]

139smb

445

1025DCE/1ff70682-0a51-30e8-076d-740be8cee98b

1026DCE/12345778-1234-abcd-ef00-0123456789ac

1433 TCP SQL SERVER

5631 TCP PCANYWHERE

5632 UDP PCANYWHERE

3389

4444[冲击波]

4489

UDP

67[冲击波]

137 netbios-ns

161 An SNMP Agent is running/ Default community names of the SNMP Agent

打造更安全的防火墙WEB安全篇2

随着Internet的不断发展, 如何加强Web服务器的稳定性, 增强对黑客入侵的抵抗能力越来越重要。当然, Web服务器安全是个很大的范畴, 文章仅仅讨论构建Web防火墙。

2 WEB应用防火墙的具体结构设计

2.1 WEB应用防火墙的部署方式

本文所用的Web服务器防火墙是网神Sec WAF 3600 WEB应用防火墙。本系统有两台独立运行的Web服务器, 根据实际情况采用透明代理模式。结构如图1:

2.2 网络配置

网络配置主要描述本设备的网络工作模式以及网络方面的配置方法。VLAN可以绑定端口和以太网通道, VLAN内部进行二层交换, VLAN之间进行三层路由。在VLAN之上可以配置IP业务, 比如ARP, IP地址, 路由等。

3 WEB应用防火墙的安全性防护方案

WEB应用防火墙的安全性防护方案主要分为事前评估、事中防护、事后弥补。

3.1 事前评估

在每次“攻击事件”发生前期, 网站会被扫描软件进行扫描, 当扫描软件扫描出网站漏洞后, 黑客会使用网站漏洞对网站发起攻击。Web应用防火墙就是根据这类事件现象, 对网站代码漏洞进行扫描, 在“攻击事件”来临前对网站进行评估, 提醒用户提高安全意识。

3.2 事中防护

Web应用防火墙针对SQL注入、信息泄露、扫描器、网络爬虫等做出了Web应用防火墙的Web防护特征库。Web应用防火墙深入理解HTTP和HTTPS协议, 提高网站的兼容性。对于黑客使用“洪水攻击”, Web应用防火墙开发了DDo S防护模块, 针对流量峰值和平均值进行限制, 防止黑客使用“洪水攻击”攻击网站服务器, 避免网站服务器出现高负荷宕机现象。

3.3 事后弥补

Web应用防火墙针对网页防篡改提出一套自主开发防护措施, 根据等级保护、分级保护的要求, Web应用防火墙推出了内核控制、本地备份、异地备份多种安全组合模式。

4 系统测试

4.1 测试环境

如图3所示为Sec WAF网络测试拓扑图。WAF串联在Web应用服务器之前, 交换机之后。管理口连接交换机。

4.2

网页防篡改测试

4.3 DDos测试 (cc攻击)

相关测试还有很多, 本文只列举了几个较为典型的测试加以论述。

5 与传统防火墙和入侵保护系统的对比

5.1 传统防火墙的局限

传统防火墙的不足主要体现在:

首先, 传统的防火墙主要工作在OSI模型三、四层, 基于IP报文进行检测。它就无需理解Web应用程序语言如HTML、XML, 也无需理解HTTP会话。这样, 恶意的攻击流量就可将封装为HTTP请求从80或443端口顺利通过防火墙检测。

其次, 有一些提供丰富功能的防火墙, 也具备一定程度的应用层防御能力, 但只能提供非常有限的Web应用防护, 如SQL注入、跨站脚本。对网页篡改、网页挂马也无能为力。

5.2入侵保护系统的不足

入侵检测系统IPS可以对应用层的威胁可以进行实时阻断。它弥补了传统防火墙的某些缺陷, 但随着网络技术和Web应用的发展复杂化, IPS在WEB专用防护领域也开始力不从心。具体体现为:

首先, 传统IPS设备更多从防护着手, 不具备事前预防的能力。其次, 针对国内比较泛滥的DDo S攻击, 传统IPS设备仅具备基本防护功能, 很难满足应用层细粒度防护的需求。最后, 如果已经被实施攻击、引发安全事件发生时, 传统IPS设备不能提供补偿措施从而为客户降低安全风险。

6小结

随着网络的普及使Web攻击更加疯狂, 重要部门的数据资产亟需保护这些都迫使我们加强对Web应用的防护意识和意愿。我们应该合理根据不同的安全需求进行科学的选择产品, 只有这样才能真正的让其起到应有的网站防护作用。

参考文献

[1]陈欣豪.多设备防火墙安全策略冲突分析[J].计算机光盘软件应用, 2012 (02) .

打造更安全的防火墙WEB安全篇3

随着IP网络建设的大发展。现在基于IP网络环境下的视频通信应用越来越普遍，不但一部分政府部门、大型企业采用基于IP的网络传输环境构筑专用的视频通信网，商业、企业更加倾向于将他们的视频通信系统构建在基于IP的传输环境中，以降低建设成本，特别是使用成本。

目前符合国际标准的视频通信应用模式。主要为遵循ITU组织H.323标准的系统。以及遵循ITEF组织SIP的系统。

经过几年的实际应用考验和不断改进。基于H.323的应用模式的应用体系非常成熟。相关产品在稳定性，连接的安全、可靠性等方面可以完全满足市场，特别是专业视频，多媒体会议的要求。由于H.323标准体系非常完备和严格。从而确保了基于H.323的众多产品所具有的良好互通互联性，这一点为H.323协议的大范围推广奠定了技术基础。基于SIP的视频应用是随着NGN的需求而日益得到市场的重视，特别是在3G背景环境下，越来越多的厂商相继推出了基于SIP的视频通信产品，以满足个人用户、移动用户对视频通信的需求。SIP提出的目的是在基于Internet环境中，实现多媒体通信的应用。它和HTTP、SMTP等ITEF的协议一样。是一种基于“文本”的通信协议。结构简单，便于扩充、扩展是SIP与H.323体系的明显区别。

二、视频通信在防火墙环境下的应用

和所有的网络应用一样，无论基于H.323标准还是基于SIP的，视频通信系统都不可避免地受到所依托网络环境的限制。这一点不但影响到视频产品选型、系统结构方案，同时对网络环境本身是否需要进一步改造都有着比较大的影响。在所有影响因素中，除了网络环境传输条件本身外，如何有效解决“防火墙”对视频系统的影响是所有用户、建设方以及视频厂商乃至网络厂商所不得不面对的一个“难题”。

从协议中对握手的定义来看，无论是H.323还是SIP。这个过程和保证网络安全的“防火墙”、NAT等机制是一对矛盾体。

对于目前经常使用的“防火墙”而言，为保证墙内内部网络的安全性，其工作机制一般是屏蔽掉外部数据对受保护网络中计算机的数据访问。而只开放少许的指定地址和通信端口，以保证Internet服务器等设备正常工作。

NAT则通过地址转换，一方面保护了内部网络中各计算机以免被外部恶意数据的直接破坏；另一方面也可以保证内部局域网络对有限公网地址的有效利用。

就目前企事业单位、国家机关的现有网络状况来看。标准的网络安全防护措施一般是“防火墙”和NAT同时使用，而且在所保护网络中开辟出一个DMZ区域供Internet和E-mail等服务器使用，而将所有办公计算机放置于受保护的内网，位于外网的数据只能到达位于DMZ区域的设备，而不能直接访问位于内网的设备，它们之间的数据传输则是通过位于DMZ区的各种服务器来实现。这样位于外网的视频设备A是不能直接和位于内网的设备B直接进行通信的。对于一般的数据应用而言。在这种网络结构下，位于内网的计算机可以访问外网的设备。但和常规的网络应用不同，基于H.323或SIP的视音频通信设备通信时，在握手的同时，发出呼叫申请的一端将自己本身的地址包括在有效的数据包中，设备B向A发出一个呼叫申请，A要根据数据包中的有效地址发出应答信息，而这个有效地址是一个内网的“私有”地址，该应答会被“防火墙”有效屏蔽。由于在指定的时间周期不能得到A端的应答信息。在B端会显示呼叫被拒绝。即使通过开放端口的手段后，A端的应答信息可以到达B端，建立连接，对于有严格合法性、“同源性”检查的H.323系统而言。视音频数据可以从B发送到A。但A的视音频信号难以到达B，这种现象在具体的视频通信网络建设过程中会经常看到。

为有效解决在有安全机制的网络环境中的视频应用，网络设备商已做了大量工作，相继推出了一些支持H.323，SIP的防火墙产品，而视频通信厂商则对标准H.323／SIP产品和系统体系加以扩充，推出了可以在NAY／防火墙环境中使用的视频产品。

下面就几种目前常见的解决方案进行简单介绍：

(1)开放网络／VPN

这种方法是直接将视频设备放置在DMZ区或直接放置在外网，这种办法不需要对现有网络进行大的改造，但这是以基本丧失对视频产品进行网络安全保护为代价的，同时由于和内网之间原有的“隔绝”没有消除。难以实现到桌面的视频应用。这种办法比较适合在全网有较好的安全保障的专网使用。或在VPN内部使用。

(2)选用支持NAT的视频产品

由于H.323产品在呼叫信息的有效数据包中包含了本地的地址信息，在经过NAT转换后，被邀请端设备难以给予有效应答，因而部分H.323产品通过在呼叫过程中，将有效的NAT映射地址取代本地私有地址来完成呼叫应答，解决了地址解析问题。如VTEL公司的VISTA系列产品，不但可以支持NAT的地址解析，还可以指定NAT端口，便于网络设置。这种方案对单一NAT机制比较有效，如ADSL等PPPOE网络环境下，可以不附加其他网络或H.323设备，就可以解决问题。

(3)代理服务器

H.323代理服务器是为解决防火墙／NAT环境下，实现H.323通信的一种“非标准”H.323设备。在标准的H.323系统中没有它的严格意义的定位。和Internet代理服务器一样，它同样被置于网络的DMZ区，在实际呼叫过程中所有的内外网的呼叫都通过它来“中继”。即代理服务器将一个呼叫转换成为由它发起的两个呼叫来完成，从而绕过了防火墙的限制。

使用代理服务器不需要防火墙／NAT设备以及H323设备的特殊支持，实现比较容易，但由于代理服务器本身能力的限制。对呼叫数量以及数据交互量的规模都有一定的影响，同时，使用H.323代理服务器对视频网络建设成本的影响，也是需要根据实际情况考虑的一个问题。如当本地只有一台视频终端时，使用代理服务器不是一个经济的解决方案。

相对于H.323代理服务器，SIP的灵活性使得SIP代理服务器解决方案更为简单灵活，通过位于公网的一个代理，注册服务器，可以较为简单和便宜地解决这个问题。目前Microsoft的MSN就是一个比较好的应用实例。

(4)使用应用层网关(ALG)

应用层网关也就是具有协议分析功能的防火墙产品，通过这些防火墙在判断数据是否可以通过时，不是简单地对IP数据包的包头进行分析，而是要对数据包中的具体数据进行相应的协议分析，并对视音频通信过程中所需求的数据通道进行动态打开，关闭，以保证视音频通信的正常进行。

现在许多网络设备商推出了采用ALG支持H.323和SIP的产品，可以在新建视音频网络时或进行网络改造时考虑。

(5)视频网关

为在标准H.323框架下解决防火墙／NAT对视频通信的影响，出现了一种“变形”的MCU。该产品一般由两个独立的网络接口分别和内网、外网连接，位于内外网的H.323设备分别和对应的端口进行连接，而视音频数据的交换则通过MCU本身来实现。采用该类产品在构造视音频通信网时。不需对网络结构进行改造，实现方法比较直接、简单。如VTEL公司的Codian MCU是这种产品的一个代表，采用双工作端口模式，不需要对内外网的规模进行预先定义，也不会对MCU总的处理能力有所影响，有较好的实际应用效果。

以上是目前经常使用的解决防火墙／NAT环境下实现视音频通信的方法，这些方法之间不是相互独立的。在一个实际的应用中可根据各个通信点的网络状态、使用情况以及建设成本等多方面因素进行综合考虑。

三、结束语

打造更安全的防火墙WEB安全篇4

一、网站安全检测工具

一个网站有没有安全隐患，只是目测或简单使用，很难得到满意的答案;除非你是专业的技术人员，而且经常处理BUG，不然很难找到网站漏洞或隐患。

为了找出网站的安全隐患，我们可以使用网站安全检测工具，好比SCANV网站安全中心、百度站长平台安全检测等，对网站进行全面的安全检测，通常可以找到常见的漏洞或隐患，好比后台地址泄露什么的;当我们发现漏洞、隐患以后，可以按教程修复漏洞或设置程序。

二、使用WEB防火墙

当我们用工具已经检测不出新的漏洞，不是说网站非常安全，只能说明过去发现的漏洞已经被修复;如果出现新的漏洞，而网站没有及时升级补丁，同样会让网站不安全，

对此，我们可以使用WEB防火墙来解决这个问题，好比零部署使用加速乐，五分钟即可生效，支持防黑、防攻击，若发现异常的请求，那么会主动拦截，避免网站被攻击;即便是新出现的程序漏洞，加速乐会很快升级防护并生效，避免网站因为没升级补丁而出现意外。

三、服务器防火墙

虽然WEB防火墙用起来很方便，可以在短时间内生效，不过很难保护到服务器本身，好比对方已经知道服务器IP地址，或者是扫描到服务器端口，依然可以直接入侵。

面对这类攻击，可以使用系统防火墙来防护。不管是系统自带的防火墙，还是第三方防火墙，好比D盾、冰盾，防护效果都还不错，可以避免服务器被轻易入侵。当然，服务器防火墙有个不可避免的缺点，使用时会占用不少的服务器资源;若服务器的内存或CPU不足，反而会严重影响服务器性能。

除了自己做好基本的安全防护准备，我们在选择主机的时候，要尽量选择较为知名的主机商，主机商知名一点，技术人员负责一点，那么服务器本身的安全性会高不少。

打造更安全的防火墙WEB安全篇5

一、先来说crossdomain.xml这个文件

flash如何跨域通信，全靠crossdomain.xml这个文件，这个文件配置在服务端，一般为根目录下，限制了flash是否可以跨域获取数据以及允许从什么地方跨域获取数据。

比如下面的列子：

1、www.a.com域下不存在crossdomain.xml文件，则不允许除了www.a.com域之外的其他任何域下的flash进行跨域请求。

2、www.a.com域下存在crossdomain.xml文件，如若配置 allow-access-from 为www.b.com，则只允许www.b.com域下的flash进行跨域请求，以及来自自身域www.a.com的网络请求。

crossdomain.xml需严格遵守XML语法，有且仅有一个根节点cross-domain-policy，且不包含任何属性。在此根节点下只能包含如下的子节点：

site-control

allow-access-from

allow-access-from-identity

allow-http-request-headers-from

site-control

早期的flash允许从其他位置载入自定义的策略文件，目前最新版的flash在接受自定义的策略文件之前会去检查主目录的crossdomain.xml来判断是否接受自定义策略文件。该选项就由site-control进行控制。

不加该选项时，默认情况下flash不加载除主策略文件之外的其他策略文件，即只接受根目录下的crossdomain.xml，这样可以防止利用上传自定义策略文件进行的攻击。如果需要启用其他策略文件，则需要配置permitted-cross-domain-policies属性，该属性有以下五个值：none: 不允许使用loadPolicyFile方法加载任何策略文件，包括此主策略文件。

master-only: 只允许使用主策略文件[默认值]。

by-content-type:只允许使用loadPolicyFile方法加载HTTP/HTTPS协议下Content-Type为text/x-cross-domain-policy的文件作为跨域策略文件。

by-ftp-filename:只允许使用loadPolicyFile方法加载FTP协议下文件名为crossdomain.xml的文件作为跨域策略文件。

all: 可使用loadPolicyFile方法加载目标域上的任何文件作为跨域策略文件，甚至是一个JPG也可被加载为策略文件!

例子：

允许通过HTTP/HTTPS协议加载http头中Content-Type为text/x-cross-domain-policy的文件作为策略文件

允许加载任意文件作为策略文件

allow-access-from

该选项用来限制哪些域有权限进行跨域请求数据。

allow-access-from有三个属性

domain：有效的值为IP、域名，子域名代表不同的域，通配符*单独使用代表所有域。通配符作为前缀和域名进行组合代表多个域，比如*.weibo.com,代表weibo.com所有的子域。

to-ports：该属性值表明允许访问读取本域内容的socket连接端口范围。可使用to-ports=“1100,1120-1125”这样的形式来限定端口范围，也可使用通配符(*)表示允许所有端口。

secure：该属性值指明信息是否经加密传输。当crossdomain.xml文件使用https加载时，secure默认设为true。此时将不允许flash传输非https加密内容。若手工设置为false则允许flash传输非https加密内容。

例子

a.com/crossdomain.xml文件内容如下

允许所有qq.com的子域通过https对t.qq.com域进行跨域请求。

allow-access-from-identity

该节点配置跨域访问策略为允许有特定证书的来源跨域访问本域上的资源。每个allow-access-from-identity节点最多只能包含一个signatory子节点。

allow-http-request-headers-from

此节点授权第三方域flash向本域发送用户定义的http头。

allow-http-request-headers-from包含三个属性：

domain：作用及参数格式与allow-access-from节点中的domain类似。

headers：以逗号隔开的列表，表明允许发送的http头。可用通配符(*)表示全部http头。

secure：作用及用法与allow-access-from节点中的secure相同。

注：Flash 在自定义HTTP头中无法使用下列请求标题，并且受限制的词不区分大小写(例如，不允许使用 Get、get 和 GET)。另外，如果使用下划线字符，这也适用于带连字符的词(例如，不允许使用 Content-Length 和 Content_Length)：

Accept-Charset、Accept-Encoding、Accept-Ranges、Age、Allow、Allowed、Authorization、Charge-To、Connect、Connection、Content-Length、Content-Location、Content-Range、Cookie、Date、Delete、ETag、Expect、Get、Head、Host、Keep-Alive、Last-Modified、Location、Max-Forwards、Options、Post、Proxy-Authenticate、Proxy-Authorization、Proxy-Connection、Public、Put、Range、Referer、Request-Range、Retry-After、Server、TE、Trace、Trailer、Transfer-Encoding、Upgrade、URI、User-Agent、Vary、Via、Warning、WWW-Authenticate 和 x-flash-version，

二、web应用中安全使用flash

设置严格的crossdomain.xml文件可以提高服务端的安全性，在web应用中也会经常使用flash，一般是通过

flash是直接可以执行js代码的，所以在web应用中如果使用不当也会很危险，所以flash使用下面两个属性来保证引用flash时的安全性。

allowScriptAccess 和 allowNetworking

allowScriptAccess用来控制flash与html的通讯，可选的值为：

always //对与html的通讯也就是执行javascript不做任何限制

sameDomain //只允许来自于本域的flash与html通讯，这是默认值

never //绝对禁止flash与页面的通讯

allowNetworking用来控制flash与外部的网络通讯，可选的值为：

all //允许使用所有的网络通讯，也是默认值

internal //flash不能与浏览器通讯如navigateToURL，但是可以调用其他的API

none //禁止任何的网络通讯

在allowNetworking设置为internal时，下面API将会被禁止使用：

fscommand

navigateToURL()

ExternalInterface.call()

在allowNetworking设置为none时，下面API将会被禁止使用：

sendToURL()

FileReference.download()

FileReference.upload()

Loader.load()

LocalConnection.connect()

LocalConnection.send()

NetConnection.connect()

URLStream.load()

NetStream.play()

Security.loadPolicyFile()

SharedObject.getLocal()

SharedObject.getRemote()

Socket.connect()

Sound.load()

URLLoader.load()

XMLSocket.connect()

在web应用中使用flash的时候一般通过设置这两项即可保证安全性，如果在web应用中使用的flash为用户可控，强烈建议这两项的设置值为

allowScriptAccess=never allowNetworking=none

三、flash安全编程

如果web应用中调用flash时设置的allowScriptAccess为never、allowNetworking为none，即使flash文件本身存在漏洞也可以忽略。不过事实上大部分web应用不会设置这两项属性，甚至会设置的不安全，比如allowScriptAccess为always、allowNetworking为all。所以在进行flash开发的时候就要考虑好安全性。

flash编程不安全可导致两方面的漏洞：

1、通过ExternalInterface.call()执行javascript代码

2、通过loadMovie()等方式可以载入外部flash文件执行

这两类问题都是需要通过参数接收外面传入的数据，在flash内部没有对数据进行严格的控制造成的。

例子：

this.movieName = root.loaderInfo.parameters.movieName;

this.flashReady_Callback = “SWFUpload.instances[”“ + this.movieName + ”“].flashReady”;

ExternalCall.Simple(this.flashReady_Callback);

public static function Simple(arg0:String){

ExternalInterface.call(arg0);

return;

}