服务器被DDOS攻击更佳解决方案是什么？报网警有用么？
服务器被DDOS攻击更佳解决方案是什么？报网警有用么？
目前，有效缓解DDoS攻击的解决方案可分为 3 大类：
架构优化
服务器加固
商用的DDoS防护服务
架构优化
在预算有限的情况下，建议您优先从自身架构的优化和服务器加固上下功夫，减缓DDoS攻击造成的影响。
部署DNS智能解析通过智能解析的方式优化DNS解析，有效避免DNS流量攻击产生的风险。同时，建议您托管多家DNS服务商。
屏蔽未经请求发送的DNS响应信息
典型的DNS交换信息是由请求信息组成的。DNS解析器会将用户的请求信息发送至DNS服务器中,在DNS服务器对查询请求进行处理之后,服务器会将响应信息返回给DNS解析器。
但值得注意的是,响应信息是不会主动发送的。服务器在没有接收到查询请求之前,就已经生成了对应的响应信息,这些回应就应被丢弃。
丢弃快速重传数据包
即便是在数据包丢失的情况下,任何合法的DNS客户端都不会在较短的时间间隔内向同- -DNS服务器发送相同的DNS查询请求。如果从相同IP地址发送至同一目标地址的相同查询请求发送频率过高,这些请求数据包可被丢弃。
启用TTL
如果DNS服务器已经将响应信息成功发送了，应该禁 止服务器在较短的时间间隔内对相同的查询请求信息进行响应。
对于一个合法的DNS客户端,如果已经接收到了响应信息,就不会再次发送相同的查询请求。
每一个响应信息都应进行缓存处理直到TTL过期。当DNS服务器遭遇大查询请求时,可以屏蔽掉不需要的数据包。
丢弃未知来源的DNS查询请求和响应数据
通常情况下,攻击者会利用脚本对目标进行分布式拒绝服务攻击( DDoS攻击) , 而且这些脚本通常是有漏洞的。因此,在服务器中部署简单的匿名检测机制,在某种程度上可以限制传入服务器的数据包数量。
丢弃未经请求或突发的DNS请求
这类请求信息很可能是由伪造的 *** 服务器所发送的,或是由于客户端配置错误或者是攻击流量。无论是哪一种情况，都应该直接丢弃这类数据包。
非泛洪攻击(non-flood) 时段,可以创建一个白名单 ,添加允许服务器处理的合法请求信息。
白名单可以屏蔽掉非法的查询请求信息以及此前从未见过的数据包。
这种 *** 能够有效地保护服务器不受泛洪攻击的威胁,也能保证合法的域名服务器只对合法的DNS查询请求进行处理和响应。
启动DNS客户端验证
伪造是DNS攻击中常用的一种技术。如果设备可以启动客户端验证信任状,便可以用于从伪造泛洪数据中筛选出非泛洪数据包。
对响应信息进行缓存处理如果某- -查询请求对应的响应信息已经存在于服务器的DNS缓存之中,缓存可以直接对请求进行处理。这样可以有效地防止服务器因过载而发生宕机。
使用ACL的权限
很多请求中包含了服务器不具有或不支持的信息,可以进行简单的阻断设置。例如,外部IP地址请求区域转换或碎片化数据包,直接将这类请求数据包丢弃。
利用ACL , BCP38及IP信营功能
托管DNS服务器的任何企业都有用户轨迹的限制,当攻击数据包被伪造,伪造请求来自世界各地的源地址。设置-个简单的过滤器可阻断不需 要的地理位置的IP地址请求或只允许在地理位置白名单内的IP请求。
同时,也存在某些伪造的数据包可能来自与内部 *** 地址的情况,可以利用BCP38通过硬件过滤清除异常来源地址的请求。
部署负载均衡通过部署负载均衡( SLB )服务器有效减缓CC攻击的影响。通过在SLB后端负载多台服务器的方式,对DDoS攻击中的CC攻击进行防护。
部署负载均衡方案后,不仅具有CC攻击防护的作用,也能将访问用户均衡分配到各个服务器上,减少单台服务器的负担,加快访问速度。
使用专有 *** 通过 *** 内部逻辑隔离,防止来自内网肉鸡的攻击。
提供余量带宽通过服务器性能测试,评估正常业务环境下能承受的带宽和请求数,确保流量通道
不止是日常的量,有-定的带宽余量可以有利于处理大规模攻击。
服务器加固
在服务器上进行安全加固,减少可被攻击的点,增大攻击方的攻击成本:
确保服务器的系统文件是最新的版本,并及时更新系统补丁。
对所有服务器主机进行检查,清楚访问者的来源。
过滤不必要的服务和端口。例如, WWW服务器,只开放80端口,将其他所有端口关闭,或在防火墙上做阻止策略。
限制同时打开的SYN半连接数目,缩短SYN半连接的timeout时间,限制SYN/ICMP流量。
仔细检查 *** 设备和服务器系统的日志。一旦出现漏洞或是时间变更,则说明服务器可能遭到了攻击。
限制在防火墙外与 *** 文件共享。降低黑客截取系统文件的机会,若黑客以特洛伊木马替换它，文件传输功能无疑会陷入瘫痪。
充分利用 *** 设备保护 *** 资源。在配置路由器时应考虑以下策略的配置:流控、包过滤、半连接超时、垃圾包丢弃,来源伪造的数据包丢弃, SYN阀值,禁用ICMP和UDP广播。
通过iptable之类的软件防火墙限制疑似恶意IP的TCP新建连接,限制疑似恶意IP的连接、传输速率。
识别游戏特征,自动将不符合游戏特征的连接断开。
防止空连接和假人攻击,将空连接的IP地址直接加入黑名单。
配置学习机制，保护游戏在线玩家不掉线。例如,通过服务器搜集正常玩家的信息,当面对攻击时,将正常玩家导入预先准备的服务器,并暂时放弃新进玩家的接入,以保障在线玩家的游戏体验。
商用的DDoS防护服务
针对超大流量的攻击或者复杂的游戏CC攻击,可以考虑采用专业的DDoS解决方案。目前，阿里云、磐石云、腾讯云有针对各种业务场景的DDOS攻击解决方案。
目前，通用的游戏行业安全解决方案做法是在IDC机房前端部署防火墙或者流量清洗的一些设备, 或者采用大带宽的高防机房来清洗攻击。
当宽带资源充足时,此技术模式的确是防御游戏行业DDoS攻击的有效方式。不过带宽资源有时也会成为瓶颈:例如单点的IDC很容易被打满,对游戏公司本身的成本要求也比较高。
您可根据自己的预算和遭受攻击的严重程度,来决定采用哪些安全措施。
安全防护有日志留存的可以选择报网警,前提是你自己的业务没有涉灰问题。
报网警有用吗？
至于报警，肯定有用，你不报警,警方没有线索,怎么抓人?
但是，这个作用不一定立即体现,警方需要时间侦查,需要取证。
DDoS的特点决定了,如果不在攻击时取证,证据很快就没了。因此要攻击者反复作案,才好抓。
对一一个被害人，只作案一次,或者随机寻找被害人的情况，最难抓。
而且调查涉及多方沟通、协调,比如被利用的主机的运营者,被害人,可能涉及多地警方的合作等等。
指望警方减少犯罪分子是可以的,但是指望通过报警拯救你的业务,只能说远水解不了近渴。
如何防止跨站点脚本攻击
防止跨站点脚本攻击的解决 *** ：1.输入过滤对每一个用户的输入或者请求首部，都要进行过滤。这需要程序员有良好的安全素养，而且需要覆盖到所有的输入源。而且还不能够阻止其他的一些问题，如错误页等。 final String filterPattern="[{}\\[\\];\\]"; String inputStr = s.replaceAll(filterPattern," ");2.输出过滤public static String encode(String data) { final StringBuffer buf = new StringBuffer(); final char[] chars = data.toCharArray(); for (int i = 0; i chars.length; i++) { buf.append("" + (int) chars[i]); } return buf.toString(); } public static String decodeHex(final String data, final String charEncoding) { if (data == null) { return null; } byte[] inBytes = null; try { inBytes = data.getBytes(charEncoding); } catch (UnsupportedEncodingException e) { //use default charset inBytes = data.getBytes(); }byte[] outBytes = new byte[inBytes.length]; int b1; int b2; int j=0; for (int i = 0; i inBytes.length; i++) { if (inBytes[i] == '%') { b1 = Character.digit((char) inBytes[++i], 16); b2 = Character.digit((char) inBytes[++i], 16); outBytes[j++] = (byte) (((b1 0xf) 4) + (b2 0xf)); } else { outBytes[j++] = inBytes[i]; } }String encodedStr = null; try { encodedStr = new String(outBytes, 0, j, charEncoding); } catch (UnsupportedEncodingException e) { encodedStr = new String(outBytes, 0, j); } return encodedStr; } !-- Maps the 404 Not Found response code to the error page /errPage404 --error-page error-code404/error-code location/errPage404/location /error-page!-- Maps any thrown ServletExceptions to the error page /errPageServ -- error-page exception-typejavax.servlet.ServletException/exception-type location/errPageServ/location /error-page!-- Maps any other thrown exceptions to a generic error page /errPageGeneric -- error-page exception-typejava.lang.Throwable/exception-type location/errPageGeneric/location /error-page 任何的非servlet例外都被/errPageGeneric路径捕捉，这样就可以处理。 Throwable throwable = (Throwable) request.getAttribute("javax.servlet.error.exception"); String status_code = ((Integer) request.getAttribute("javax.servlet.error.status_code")).toString( );3.安装三方的应用防火墙，可以拦截css攻击。附：跨站脚本不像其他攻击只包含两个部分：攻击者和web站点。 跨站脚本包含三个部分：攻击者，客户和web站点。 跨站脚本攻击的目的是窃取客户的cookies，或者其他可以证明用户身份的敏感信息。攻击 一个get请求 GET /welcome.cgi?name=Joe%20Hacker HTTP/1.0 Host:会产生如下的结果 HTML TitleWelcome!/Title Hi Joe Hacker BR Welcome to our system ... /HTML 但是如果请求被篡改 GET /welcome.cgi?name=scriptalert(document.cookie)/script HTTP/1.0 Host: 就会得到如下的响应 HTML TitleWelcome!/Title Hi scriptalert(document.cookie)/script BR Welcome to our system ... /HTML 这样在客户端会有一段非法的脚本执行，这不具有破坏作用，但是如下的脚本就很危险了。 ;scriptwindow.open(“”%2Bdocument.cookie)/script 响应如下： HTML TitleWelcome!/Title Hi scriptwindow.open(“”+document.cookie)/script BR Welcome to our system ... /HTML 浏览器回执行该脚本并将客户的cookie发到一个攻击者的网站，这样攻击者就得到了客户的cookie。
XSS攻击如何实现以及保护Web站点免受跨站点脚本攻击
使用工具和测试防范跨站点脚本攻击. 跨站点脚本（XSS）攻击是当今主要的攻击途径之一，利用了Web站点的漏洞并使用浏览器来窃取cookie或进行金融交易。跨站点脚本漏洞比较常见，并且要求组织部署涵盖威胁建模、扫描工具和大量安全意识在内的周密的安全开发生命周期，以便达到更佳的XSS防护和预防。本文解释了跨站点脚本攻击是如何实现并且就如何保护企业Web应用免于这种攻击提供了建议。 跨站点脚本（XSS）允许攻击者通过利用因特网服务器的漏洞来发送恶意代码到其他用户。攻击者利用跨站点脚本（XSS）攻击向那些看似可信任的链接中注入恶意代码。当用户点击了链接后，内嵌的程序将被提交并且会在用户的电脑上执行，这会使黑客获取访问权限并偷走敏感数据。攻击者使用XSS来攻击受害者机器上的漏洞并且传输恶意代码而不是攻击系统本身。 通过用户输入的数据返回错误消息的Web表格，攻击者可以修改控制Web页面的HTML代码。黑客能够在垃圾信息中的链接里插入代码或者使用欺诈邮件来诱使用户对其身份产生信任。 例如攻击者可以发送带有URL的邮件给受害人，这个URL指向一个Web站点并且提供浏览器脚本作为输入；或者在博客或诸如Facebook、Twitter这样的社交网站上发布恶意URL链接。当用户点击这个链接时，该恶意站点以及脚本将会在其浏览器上运行。浏览器不知道脚本是恶意的并将盲目地运行这个程序，这转而允许攻击者的浏览器脚本使用站点的功能来窃取cookie或者冒充合法的用户来完成交易。 一些通常的跨站点脚本预防的更佳实践包括在部署前测试应用代码，并且以快速、简明的方式修补缺陷和漏洞。Web应用开发人员应该过滤用户的输入来移除可能的恶意字符和浏览器脚本，并且植入用户输入过滤代码来移除恶意字符。通常管理员也可以配置浏览器只接受来自信任站点的脚本或者关闭浏览器的脚本功能，尽管这样做可能导致使用Web站点的功能受限。 随着时代的进步黑客们变得更加先进，使用收集的工具集来加快漏洞攻击进程。这意味着仅仅部署这些通常的XSS预防实践是不够的，保护和预防过程必须从底层开始并持续提升。预防过程必须在开发阶段开始，建立在一个牢靠、安全的开发生命周期 *** 论之上的Web应用在发布版本中不太可能暴露出漏洞。这样以来，不仅提升了安全性，也改善了可用性而且缩减了维护的总体费用，因为在现场环境中修补问题比在开发阶段会花费更多。 威胁建模在XSS预防中也是重要的一个方面，应该纳入到每个组织的安全开发生命周期当中。威胁建模评估和辨识在开发阶段中应用程序面临的所有的风险，来帮助Web开发人员更好地理解需要什么样的保护以及攻击一旦得逞将对组织产生怎样的影响。要辨识一个特定应用的威胁级别，考虑它的资产以及它访问的敏感信息量是十分重要的。这个威胁建模过程将确保在应用的设计和开发过程中战略性地融合了安全因素，并且增强了Web开发人员的安全意识。 对于大型项目的Web开发人员来说，源代码扫描工具和Web应用漏洞扫描器是提高效率和减少工作量的通常选择。
SQL服务器怎样做才能防止黑客攻击?
SQL服务器防黑客？
我不太清楚你服务器组的拓扑结构，不过一般来讲数据库服务器在服务器层面上应该是属于后端设备，理论上数据库服务器不直接连接公众网。
在这个前提下SQL服务器防黑客应该是在前段的应用服务器上面完成。
黑客攻击经常出现的是两种：1.以获取管理权限为目的的入侵行为。2.已破坏使用为目的的阻断行为。
针对之一条：及时修复系统漏洞、关闭不使用的端口、提高密码等级、通过组策略对访问进行限制等等可以再很大程度上防御攻击。
针对第二条：无解，基本上没有办法抵御10G级流量的DDOS攻击，只能通过硬防完成，可能还要增加“黑洞”
如何防止xss攻击，需要过滤什么
XSS攻击通常是指黑客通过"HTML注入"篡改了网页，插入了恶意的脚本，从而在用户浏览网页时，控制用户浏览器的一种攻击。
一、HttpOnly防止劫取Cookie
HttpOnly最早由微软提出，至今已经成为一个标准。浏览器将禁止页面的Javascript访问带有HttpOnly属性的Cookie。目前主流浏览器都支持，HttpOnly解决是XSS后的Cookie支持攻击。
我们来看下百度有没有使用。
未登录时的Cookie信息
可以看到，所有Cookie都没有设置HttpOnly，现在我登录下
发现在个叫BDUSS的Cookie设置了HttpOnly。可以猜测此Cookie用于认证。
下面我用PHP来实现下：
?php
header("Set-Cookie: cookie1=test1;");
header("Set-Cookie: cookie2=test2;httponly",false);
setcookie('cookie3','test3',NULL,NULL,NULL,NULL,false);
setcookie('cookie4','test4',NULL,NULL,NULL,NULL,true);
?
script
alert(document.cookie);
/script
js只能读到没有HttpOnly标识的Cookie
二、输入检查
输入检查一般是检查用户输入的数据中是否包含一些特殊字符，如、、'、"等，如果发现存在特殊字符，则将这些字符过滤或者编码。
例如网站注册经常用户名只允许字母和数字的组合，或者邮箱 *** ，我们会在前端用js进行检查，但在服务器端代码必须再次检查一次，因为客户端的检查很容易绕过。
网上有许多开源的“XSS Filter”的实现，但是它们应该选择性的使用，因为它们对特殊字符的过滤可能并非数据的本意。比如一款php的lib_filter类：
$filter = new lib_filter();
echo $filter-go('1+11');
它输出的是1，这大大歪曲了数据的语义，因此什么情况应该对哪些字符进行过滤应该适情况而定。
三、输出检查
大多人都知道输入需要做检查，但却忽略了输出检查。
1、在HTML标签中输出
如代码：
?php
$a = "scriptalert(1);/script";
$b = "img src=# onerror=alert(2) /";
?
div?=$b?/div
a href="#"?=$a?/a
这样客户端受到xss攻击，解决 *** 就是对变量使用htmlEncode,php中的函数是htmlentities
?php
$a = "scriptalert(1);/script";
$b = "img src=# onerror=alert(2) /";
?
div?=htmlentities($b)?/div
a href="#"?=htmlentities($a)?/a
2、在HTML属性中输出
div id="div" name ="$var"/div
这种情况防御也是使用htmlEncode
在owasp-php中实现：
$immune_htmlattr = array(',', '.', '-', '_');
$this-htmlEntityCodec-encode($this-immune_htmlattr, "\"script123123;/script\"");
3、在script标签中输出
如代码：
?php
$c = "1;alert(3)";
?
script type="text/javascript"
var c = ?=$c?;
/script
这样xss又生效了。首先js变量输出一定要在引号内，但是如果我$c = "\"abc;alert(123);//"，你会发现放引号中都没用，自带的函数都不能很好的满足。这时只能使用一个更加严格的JavascriptEncode函数来保证安全——除数字、字母外的所有字符，都使用十六进制"\xHH"的方式进行编码。这里我采用开源的owasp-php *** 来实现
$immune = array("");
echo $this-javascriptCodec-encode($immune, "\"abc;alert(123);//");
最后输出\x22abc\x3Balert\x28123\x29\x3B\x2F\x2F
4、在事件中输出
a href="#" onclick="funcA('$var')" test/a
可能攻击 ***
a href="#" onclick="funcA('');alter(/xss/;//')"test/a
这个其实就是写在script中，所以跟3防御相同
5、在css中输出
在owasp-php中实现：
$immune = array("");
$this-cssCodec-encode($immune, 'background:expression(window.x?0:(alert(/XSS/),window.x=1));');
6、在地址中输出
先确保变量是否是"http"开头，然后再使用js的encodeURI或encodeURIComponent *** 。
在owasp-php中实现：
$instance = ESAPI::getEncoder();
$instance-encodeForURL(‘url’);
四、处理富文体
就像我写这篇博客，我几乎可以随意输入任意字符，插入图片，插入代码，还可以设置样式。这个时要做的就是设置好白名单，严格控制标签。能自定义 css件麻烦事，因此更好使用成熟的开源框架来检查。php可以使用htmlpurify
五、防御DOM Based XSS
DOM Based XSS是从javascript中输出数据到HTML页面里。
script
var x = "$var";
document.write("a href='"+x+"'test/a");
/script
按照三中输出检查用到的防御 *** ，在x赋值时进行编码，但是当document.write输出数据到HTML时，浏览器重新渲染了页面，会将x进行解码，因此这么一来，相当于没有编码，而产生xss。
防御 *** ：首先，还是应该做输出防御编码的，但后面如果是输出到事件或脚本，则要再做一次javascriptEncode编码，如果是输出到HTML内容或属性，则要做一次HTMLEncode。
会触发DOM Based XSS的地方有很多：
document.write()、document.writeln()、xxx.innerHTML=、xxx.outerHTML=、innerHTML.replace、document.attachEvent()、window.attachEvent()、document.location.replace()、document.location.assign()
cs服务器如何才能过滤脚本呢?有的脚本过于 *** 了,已经影响了站队的正常训练,急求反脚本软件,拜谢
以前好多CS1.5的服务器都有WWCL这样插件
专门用来反非法脚本的
只要进入服务器就会将你CFG上的非法参数 刷到正常
不过1.6见的少多了
1.6的也有
我见过
你在网上找找 好象DCOO上有
0条大神的评论