如何破解压力测试攻击软件,攻击测试工具

作者:hacker | 分类:破解 | 浏览:134 | 日期:2022年11月07日

被别人用压力测试软件攻击了我网站之后，出现502 bad gateway，页面直接打不开，需要怎么解决，求指点

502 Bad Gateway是一种报错提示，这一错误并不意味着上游服务器已关闭(无响应网关/ *** )，而是上游服务器和网关/ *** 不同意的协议交换数据。

之一种原因：目前lnmp一键安装包比较多的问题就是502 Bad Gateway，大部分情况下原因是在安装php前，脚本中某些lib包可能没有安装上，造成php没有编译安装成功。解决办法：可以尝试根据lnmp一键安装包中的脚本手动安装一下，看看是什么错误导致的。

第二种原因：在php.ini里，eaccelerator配置项一定要放在Zend Optimizer配置之前，否则也可能引起502 Bad Gateway

第三种原因：在安装好使用过程中出现502问题，一般是因为默认php-cgi进程是5个，可能因为phpcgi进程不够用而造成502，需要修改/usr/local/php/etc/php-fpm.conf 将其中的max_children值适当增加。

第四种原因：php执行超时，修改/usr/local/php/etc/php.ini 将max_execution_time 改为300。

第五种原因：磁盘空间不足，如mysql日志占用大量空间。

第六种原因：查看php-cgi进程是否在运行。

另外的解决办法：

Nginx 502 Bad Gateway的含义是请求的PHP-CGI已经执行，但是由于某种原因（一般是读取资源的问题）没有执行完毕而导致PHP-CGI进程终止，一般来说Nginx 502 Bad Gateway和php-fpm.conf的设置有关。

php-fpm.conf有两个至关重要的参数，一个是max_children，另一个是request_terminate_timeout，但是这个值不是通用的，而是需要自己计算的。

在安装好使用过程中出现502问题，一般是因为默认php-cgi进程是5个，可能因为phpcgi进程不够用而造成502，需要修改/usr/local/php/etc/php-fpm.conf 将其中的max_children值适当增加。

计算的方式如下：如果服务器性能足够好，且宽带资源足够充足，PHP脚本没有系循环或BUG的话可以直接将 request_terminate_timeout设置成0s。0s的含义是让PHP-CGI一直执行下去而没有时间限制。如果做不到这一点，也就是说PHP-CGI可能出现某个BUG，或者宽带不够充足或者其他的原因导致PHP-CGI假死那么就建议给 request_terminate_timeout赋一个值，这个值可以根据服务器的性能进行设定。一般来说性能越好可以设置越高，20分钟-30分钟都可以。

而max_children这个值又是怎么计算出来的呢？这个值原则上是越大越好，php-cgi的进程多了就会处理的很快，排队的请求就会很少。设置max_children也需要根据服务器的性能进行设定，一般来说一台服务器正常情况下每一个php-cgi所耗费的内存在20M左右。

按照官方的答案，排查了相关的可能，并结合了网友的答案，得出了下面的解决办法：

1、查看php fastcgi的进程数（max_children值）代码：netstat -anpo | grep “php-cgi” | wc -l

5（假如显示5）

2、查看当前进程，代码：top观察fastcgi进程数,假如使用的进程数等于或高于5个，说明需要增加（根据机器实际状况而定）

3、调整/usr/local/php/etc/php-fpm.conf 的相关设置

value name=”max_children”10/value

value name=”request_terminate_timeout”60s/value

max_children最多10个进程，按照每个进程20MB内存，最多200MB。

request_terminate_timeout执行的时间为60秒，也就是1分钟。

如何破解压力测试攻击软件,攻击测试工具

如何攻破软件

如何攻破软件 James A.Whittaker 摘要本文讨论一系列用于发现软件设计与开发中的缺陷的 *** （所谓的“攻击”）。这些攻击都是手工、探索性的测试方式，设计和执行都是动态的、几乎不需要额外开销。这些攻击是经过对上百个真实的软件缺陷进行研究并且抽象出他们的成因和现象之后构造出来的。经过佛罗里达理工学院软件测试方向的学员两个学期的细化分析，已经归纳了数十个旨在发现缺陷的攻击策略。这些攻击策略被证明非常受用，已经发现了上百个额外的缺点——都是由这些攻击策略直接导致的——在短时间内对产品几乎没有任何了解的情况下。本文介绍上述攻击策略的一个子集并说明他们是如何在已发布产品中发现真实缺陷。简介是什么成就了一名优秀的测试人员？是什么样的天赋使他们对bug 如此敏感？这样的能力是可以传授的吗？这些问题就是本文的主旨。我相信优秀的测试人员更多是后天造就而不是先天生成的，事实上，多年下来许多测试人员自己似乎积累了一个攻击策略的标准库。每当他们面临测试难题时就会重组手头的攻击策略，从而总是能够发现缺陷。尽管这些攻击策略很少被记录下来，它们确确实实在手工测试和测试传承中扮演着重要的角色。通过对真实的测试人员和现实缺陷的研究，我们开始着手文档化这一财富。在本文中，我们探索来自于该项工程的一部分成果。下一个挑战是对这些攻击施行自动化，找到有效使用的具体策略。攻击无异于以下三个大类：  输入/输出攻击  数据攻击  运算攻击每个类型中都有特定类型的攻击，它们导致十分有趣的软件故障。在之后的部分我以具体的缺陷为例介绍每个大类下的攻击类型。涉及到的bug 都来自于微软公司的产品。我认为这不该被看作是一种反微软的行为。事实上，它作为软件行业霸主的事实使它自然而然地成为了“众矢之的”。但不能就这样认为微软的产品相对于其他软件产商有更多的缺陷。本文中提到的攻击策略几乎成功攻击过许多公司的软件产品，这些产品运行在你可以想到的任何平台上。我的经验表明，不管开发人员开发的应用产品域是什么、使用的操作系统有什么差异亦或是否发布源码，他们都在高频度地制造bugs。如果他们是web 开发人员，那就更不用费心了，因为web 程序本身非常容易崩溃。输入/输出攻击针对输入/输出的攻击就是测试人员所说的“黑盒”测试，因为不需要任何有关内部数据或计算的信息来支持测试执行。事实上，这是测试中最常见的一种，因为阅读源码不仅乏味、费时，并且通常收益甚微，除非你知道自己到底在寻找什么类型的bug（我们将在接下来的两部分内容里讨论什么是你应该试图寻找的）。输入/输出攻击单一输入攻击迫使所有的报错信息出现强制指定默认值尝试所有可用的字符集迫使输出区域大小改变引发显示区域溢出迫使屏幕刷新问题出现输入值组合攻击迫使无效输出出现找出不能共存的输入值组合输入序列攻击迫使无效输出出现多次重复同样的输入序列单一输入攻击这一类攻击是对使用单一输入（从变量输入的角度来说）的行为进行的检查。我们试图发现在大部分数据都正常工作的情况下由一个单一的输入导致应用崩溃的情况。其实除了单单从边界值上考虑以外还有很多别的方式来选择输入用例，特别是当你希望找到真正被开发认可的bug，而不是仅仅作为未定义的需求而忽略掉。首先给出一些看似简单但不易施行的建议：确保所有的报错信息都出现一遍。不能使程序正常地中止或结束的通常就是所谓的bug。很多报错信息仅仅是迫使程序停止来显示一条报错信息，然后接着执行下一条输入或者直到定时器超时而已。但是，也有其他一些报错信息则是来自于被程序抛出和异常处理器被执行引发的异常。异常处理器（或中央错误处理线程）因其指针突然改变而数据状态不产生相应变化，通常会存在问题。异常处理器执行的瞬间，各种各样的数据问题接踵而至：文件未关闭、内存未释放、数据未初始化。当控制重新回到主线程，很难判断错误处理器是在什么时刻被调用，又会有怎样的遗留问题在等待粗心大意的开发人员：因为文件没有关闭导致打开文件失败、在没有初始化前就开始使用数据。如果我们能确保在所有的报错信息都出现过之后系统依然正常工作，那么也算是为用户省去了不少麻烦（更不用说我们的维护工程师了）。图1 展示了我的学生在微软 Word 2000 中发现的一个有趣的bug，一条错误提示不知为何连续出现了两次。这个bug 是在通过单一输入攻击错误处理线程的过程中发现的。确保软件指定默认值。开发人员通常不记得在用户输入越界或给参数设置不合理的值时指定默认的值。有时候强制设立默认值意味着什么也不做——然而正因为想不到，这一举措甚至难倒了优秀的开发人员。例如，在Word 2000 中，如下对话框中有一个选择框，当不对其做任何修改时再次打开对话框，该控件将消失。对比左右图片中的对话框。你发现什么控件消失了吗？有的时候指定默认值需要先改变值的当前设定，然后将其设定为一个不合理的值。这种连续的转换保证了再转换成其他可用的值前是经过设置默认值。尝试输入变量的所有可用的字符集。有的输入问题很简单，特别是当你使用了类似$，%，#，引号等等字符时，这些字符在许多编程语言中有特殊意义并且作为输入被读入时通常需要特殊处理。如果开发人员未考虑这种情况，则这些输入可能导致程序的失败。通过改变输入内容的多少引发输出区域的改变。聚焦于输出本身是一种发现bug 颇有成效但是极少使用的 *** 。其思想是：先假定一种表现为bug 的输出或者行为，然后寻找能够导致这种现场产生的输入。以上所述的一个简单的攻击例子就是通过改变输入值和输入字符串的长度来引发输出区域大小的重新计算。一个很好的概念性例子是将时钟的时间设置为9:59，然后等待它转到10:00。一开始显示区域是4 个字符长度而后来是5。反过来，我们设定时间为12:59（5 个字符），然后等待其转变为1:00（4 个字符）。开发人员通常只会对初始化为空白的情况进行处理而不曾考虑到显示区域已有数据的情况下如何更新该区域以显示不同长度的数据。举个例子，PowerPoint 中的“艺术字”功能中有个有趣的bug。假定我们输入下图中的一个长的字符串。可以发现因为字符串太长，并不是整个字符串都能显示出来。但这不是问题的关键。点击确认按钮时触发两个事件。首先，程序计算出需要的输出区域大小，然后将输入的文字填充进去。现在，我们编辑该字符串，将它改为单个字符。可以发现尽管现在只有单个字符，字体大小也没有改变，但显示区域大小却没有发生改变。进一步看。如果再次编辑该字符串为多行的字符串，输出结果更有意思。我想这部分已经介绍得比较清楚了，我们将进入下一部分。确保对显示区域的边界的检查。这是基于输出的另一种攻击思路，与之前的十分类似。然而，不同于之前着力于导致显示区域内部出错，这次我们将精力集中在显示区域的外部。并且显示区域将不再重新计算显示边界而仅仅是考虑边界溢出。再以PowerPoint 为例，我们可以先画一个文本框，然后输入一个带上标的字符串。放大该字符串的字体使上标的上半部分被截断。这一问题将连同之后的相关问题一起说明。引发屏幕刷新问题。这是使用windows 图形用户界面的用户会遇到的主要问题。对开发人员来说，更是一个大问题：过度的刷新将导致程序变慢，而不刷新又会导致大大小小的问题，小至要求用户强制刷新，大到导致用户的操作失败。通常通过在屏幕上添加、删除和移动元素来触发页面刷新。这将导致背景重新绘制，如果页面不能正确、及时地作出相应，那么这就是通常意义上的bug。其中，尝试变化所移动的元素的距离是一种较好的方式，可以移动一点点，接着移动一大截，移动一两次，接着移动很多次。接着说回上面例子中的带上标的字符串，试着每次用鼠标拖动它移动一些距离，就会发现令人讨厌的问题，如下图所示。在Office 2000 中经常出现的另一个与屏幕刷新相关的问题是文本的异常消失。这一讨厌的问题在 Word 的页面边界附近出现。输入值组合攻击第二类输入/输出 bug 主要针对多个共同作用或相互影响的输入。例如，一个通过两个参数调用的API，其中一个参数的取值建立在另一个参数取值的基础上。通常，bug 正是出在值组合上，因为代码的逻辑关系复杂。找出不能共存的输入值的组合。那么哪些值的组合是有问题的？这个问题目前还处于积极研究中，但是我们已经找到了一个特别有效地 *** ，那就是先确定期望获得的输出，然后试着去找到对应的输入值的组合。尝试产生无效的输出。这是一种适用于测试人员对问题域十分清楚的有效攻击 *** 。例如，当你在测试一个计算器并且清楚部分功能点的结果有限制时，试图找到超出范围的结果所对应的输入值组合是值得的。但是，如果你不熟悉数学，那么这种努力很可能是浪费时间——你甚至可能将一个不正确的结果当成正确的。有时候windows 本身会给出提示，告诉你哪些输入是相互关联的。此时，测试人员可以去测试这些值的范围，并且尝试触犯既定的关系。输入序列攻击软件中的输入就像一种正式的语言。单一的输入相当于组成语言的字母，输入的字符串类似构成语言的句子。其中一些句子应该通过控件和输入区域的启用与禁用被过滤。通过尽可能多地输入字符串、改变输入的顺序来测试这种问题。选择导致无效输出的输入序列。和上文描述这是一种找到问题输入组合的好 *** 一样，这同样是找出有问题的输入序列的好 *** 。例如，当我们发现了Office 2000 中的一个导致文本消失的问题后，对PowerPoint 幻灯片中标题文本框进行攻击。如下的一组屏幕截图再现了一个特定的输入序列是如何导致文本消失的。有趣的是仅仅将文本框旋转180 度并不能发现这个bug。必须按照这样的操作顺序：旋转180 度后，再旋转10 度（或者更多）。逆向执行以上操作并不能修正这一问题，每当点击标题外部区域，该标题内容就会消失。改变输入的顺序之所以善于发现bug 是因为很多操作自身成功执行的同时会遗留很多问题，它们将导致之后的操作失败。对输入序列进行彻底的检查会暴露出很多这样的问题。然而有时候，下面这种攻击表明：为了发现bug，根本不需要使用多种多样的输入序列。多次重复同样的输入序列。这种方式会对资源造成大规模占用，并且对存储数据空间造成压力，当然也包括发现其他负面的遗留问题。遗憾的是，大多数应用程序并不清楚自身空间和时间的限制，而许多开发人员倾向于假定资源总是足够可用的。在Word 的公式编辑器中可以找到这方面的一个例子，程序本身似乎并不清楚它只能处理10 层嵌套括号的计算。数据攻击数据是软件的命脉；如果你设法破坏了它，那么程序将不得不使用被破坏的数据，这之后得到的就不是合理的结果。所以理解数据是如何、在何处建立是必要的。从本质上讲，数据的存储是通过读取输入，然后将其存储在内部或者存储一些内部计算的结果来实现的。因此，测试正是通过提供输入和执行计算来实现数据在应用程序中的传递。数据攻击遵循以下简单原则。数据攻击变量值攻击 1.存储不正确的数据类型 2.使数据值超过允许的范围数据单元大小攻击 3.溢出输入缓冲区 4.存储过多的值 5.存储太少的值数据访问攻击 6.找出同一数据的不同修改方式变量值攻击这一类的攻击需要对内部存储的数据对象的数据类型和合法值进行检查。如果有对源码的权限则这些信息可以轻易得到，但是，通过小小的探索性测试和对错误信息的关注也可以确定大致的类型信息。改变输入的数据类型来找出不匹配的类型。在需要整数的区域输入字符（和类似的攻击）已经被证明十分有效，但随着现代编程语言对类型检查和类型转换的处理变得容易，我们发现这样的攻击相对之前已经不再那么有效。使数据值超过允许的范围。被存储的变量数据和输入的变量数据一样，这样的攻击方式同样适用。数据单元大小攻击第二类数据攻击旨在触发数据结构的溢出和下溢。换句话说。攻击试图打破预先设定的数据对象的大小限制。首先要说的就是典型的缓冲区溢出。溢出输入缓冲区。此处通过输入长字符串导致输入缓冲区溢出。这是黑客们偏好的攻击方式，因为有时候应用程序在崩溃之后会继续执行进程。若一名黑客将一段可执行代码附在一个长字符串中输入，程序很可能执行这段代码。在Word 2000 中的一个缓冲区溢出问题就是这样一个可被利用的bug。此bug 被发现在查找/替换功能中，如下所示。有趣的是，“查找”这一字段被合理地加以限制而“替换”没有。同一数据结构存储过多的值。复杂地数据结构诸如数组、矩阵和列表在测试中不仅仅要考虑存储在其中的数值，还要考虑存储值的数目。同一数据结构存储过少的值。当数据结构允许增加和删除信息时，通常在做了n-1 次增加的同时穿插着或在其之后做n 次删除操作会导致攻击成功。数据访问攻击我的朋友Alan Jorgensen 喜欢用“右手不明左手所为”这句话来形容这一类bug。道理很简单，但开发人员却常倒在这一类攻击下：在很多程序中通常任何任务都能通过多种途径完成。对测试人员来说，这意味着同一个函数可以由多个入口来调用，这些入口都必须确保该函数的初始条件得到满足。一个极好的例子是我的学生在PowerPoint 中发现的表格数据大小相关的崩溃性bug。创建表格时更大尺寸被限定为25×25。然而，可以创建一个25×25 的表格，然后为其添加行和列——导致应用程序崩溃。这就是说，程序一方面不允许26×26 的表格存在而另一方面却并不清楚这个规则的存在。运算攻击运算攻击操作数攻击使用非法操作数进行运算找出非法操作数组合结果攻击使运算结果过大使运算结果过小功能相互作用攻击找出共享数据不佳的功能操作数攻击这类攻击需要知道在一个或更多内部运算中操作数的数据类型和可用的值。如果有源码权限则这些信息可以轻易获得。否则，测试人员必须尽更大努力去弄清楚正在进行的运算具体是什么、使用的是什么数据类型。触发由非法操作数引起的运算。有时候输入或存储的数据处于合法的范围之中，但是在某些运算类型中却是非法的。被 0 除就是一个很好的例子。0 是一个合法的整数，但作为除法运算的除数却是非法的。找出不能共存的操作数的组合。涉及到一个以上操作数的运算不仅受制于上面的攻击，同时存在操作数冲突的可能性。结果攻击第二类运算攻击旨在造成存储运算结果的数据对象的溢出和下溢。试图造成运算结果过大而存储失败。就算是简单如y=x+1 这样的运算在数值边界上也常出问题。如果x 和y 都是2 比特的整数并且x 的值为32768，则这一运算将失败，因为结果将会造成存储溢出。试图造成运算结果过小而存储失败。和上文相同，不同的是使用y=x-1 并且使x 的值为-32767。功能相互作用攻击文章中讨论的这最后一类攻击或许算是所有种类的鼻祖，可以用来区分测试菜鸟和专业人员：功能的相互作用。问题没有什么新意：不同的应用程序功能共享同一数据空间。两种功能的相互作用导致应用程序失败，不是因为对数据处理的设定不同，就是因为产生了不良副作用。但是哪些功能共享数据并且能够在冲突情况下实现数据转化目前还是测试领域中一个开放的问题。目前我们正停留在不断地尝试阶段。下面这个例子足以说明情况。这个例子给出了在Word 2000 中的同一页面上合并脚注和双列时出现的一个出人意料的结果。问题在于：Word 从注释的引用点计算脚注的页面宽度。所以，若同一页面上存在两条脚注，一条被处于双列位置的内容所引用，另一条则被处于单列位置的内容所引用，单列脚注会将双列脚注挤到下一页面。同时被挤掉的还有引用点至页面底部间的文本。下面的屏幕截图形象地说明了问题。第二列的文本去哪里了？连同脚注一起处在下一页。你会任由文档像这样显示吗？在找到解决 *** （这意味着你得花时间去整理）前你将不得不忍受这一现状。结论简单遍历一遍上面罗列的21种攻击策略可以覆盖应用程序的大部分功能。事实上，施行一次成功的攻击通常意味着尝试各种可能性，走过很多死胡同。但是仅仅因为部分这一类探索性 *** 发现不了bug并不意味着它们没有用。首先，这段时间使用应用程序帮助测试人员熟悉程序的各种功能，从而产生新的攻击思路。其次，测试通过是好的消息！它们表明，产品是可靠的：尤其当这组测试是上面所说的恶意攻击。如果代码可以承受这样的测试过程，它几乎可以应对用户作出的任何操作。另外，永远不要低估了测试时怀揣一个具体目标的作用。我见过太多测试人员把时间浪费在毫无目的地输入或者随机地调用API试图导致软件出错。实行测试意味着制定明确的目标——基于会出错的点——然后设计测试用例来实践该目标。这样，每个测试用例都有目的性并且进度可以被随时控制。最后，记住，测试应该是有趣的。攻击这一比喻正是对测试的这一特性很好的诠释并且还为愉快的消遣时光添加了些许作料。狩猎愉快！