|
InstallationAndUsage
InstallationThe tool is distributed as portable package, so just download the latest tarball from Downloads section, extract, configure, compile, and install: $ tar -xzvf slowhttptest-x.x.tar.gz $ cd slowhttptest-x.x $ ./configure --prefix=PREFIX $ make $ sudo make install Where PREFIX must be replaced with the absolute path where slowhttptest tool should be installed. You need libssl-dev to be installed to successfully compile the tool. Most systems would have it. Update: Apologies for FreeBSD users for failed build. Fix checked into svn. Use svn checkout http://slowhttptest.googlecode.com/svn/trunk/ slowhttptest-read-only to build on FreeBSD, until we release new version. UsageTool works out-of-the-box with default parameters, which are harmless and most likely will not cause a Denial of Service. Type $ PREFIX/bin/slowhttptest and test begins with the following default parameters:
Every connection generates an initial request containing: GET / HTTP/1.1 Host: localhost:80 User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2) Where user-agent is being randomly picked from hard-coded list of user-agent strings, and remains the same for entire test. Then, every 10 seconds a follow up header with random name and value each not greater than 32 bytes is being sent: X-HMzV2bwpzQw9jU9fGjIJyZRknd7Sa54J: u6RrIoLRrte4QV92yojeewiuDa9BL2N7 . . 10 seconds . X-nq0HRGnv1W: T5dSL . . 10 seconds . X-iFrjuN: PdR7Jcj27P . .
Repeated until server closes the connection or test hits time limit, 240 seconds in this case. There is a Probe socket, which connects every second and takes a probe of web server availability by sending complete GET request. If server responds within probe connection timeout interval (specified by -p argument), server is considered available, otherwise it's considered DoSed. Default value of 5 seconds might be not enough for slow servers, or if SSL connection is being used, so appropriate value should be around average response time of the server. Full list of configurable options is the following:
Example of usage in slow message body mode: ./slowhttptest -c 1000 -B -g -o my_body_stats -i 110 -r 200 -s 8192 -t FAKEVERB -u https://myseceureserver/resources/loginform.html -x 10 -p 3 Example of usage in slowloris mode: ./slowhttptest -c 1000 -H -g -o my_header_stats -i 10 -r 200 -t GET -u https://myseceureserver/resources/index.html -x 24 -p 3 OutputDepends on verbosity level, output can be either as simple as heartbeat message generated every 5 seconds showing status of connections with verbosity level 1, or full traffic dump with verbosity level 4. -g option would generate both CSV file and interactive HTML based on Google Chart Tools. Here is a sample screenshot of generated HTML page
that contains graphically represented connections states and server availability intervals, and gives the picture on how particular server behaves under specific load within given time frame. CSV file can be used as data source for your favorite chart building tool, like MS Excel, iWork Numbers, or Google Docs. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
► Sign in to add a comment
Hello Sergey. I wasn't sure where to post my question. I am trying to run slowhttptest to test it against a proxy server (I should say a web server via a proxy server, but my main goal is to analyze proxy server performance). Similarly the way you did in your "How I Knocked Down 30 Servers from One Laptop" blog post against Squid. I noticed there is no option to specify proxy to pass traffic through in the tool. So my question is how you managed to direct the slowhttprequest generated traffic through proxy? Will there be an option in upcoming releases to use proxy? I noticed in the Issues section you mentioned "support web proxy for probe connection". Not sure if my question relates to that. I assume there is a way to redirect traffic via proxy (at least in the case of Squid) via firewall (ie iptables), but what I am concerned is whether that will have side effects on the analysis (ie lagging because of constant firewall redirection rules, thus affecting true test results). I would appreciate if you please could reply.
Regards, -Akbar
Hi Akbar, if under proxy you mean reverse proxy like Squid or Varnish, then it should be tested the same way you would test your HTTP server, e.g. if proxy/cache server/load balancer is running on 1.2.3.4:80, and web server is on the same interface but different port, or different interface or machine, just make sure you run slowhttptest with -u http://1.2.3.4:80, as from tool's standpoint, that proxy wouldn't be different from web server. That's how I tested squid. In case you mean an HTTP proxy, e.g. something that accepts all connections from your browser and acts as a tunnel, between your machine and whaver host is in Host header, then slowhttptest doesn't support it. Basically speaking, browser sends different requests for plain and proxy'd connections. In second case, the URL should be absolute, and Host header should point to the proxy server itself. I would play with this, but I doubt it would work, as to my knowledge, HTTP proxies are implemented in the way, that they suppose to accept the entire HTTP request before redirecting it to the destination. May be I am wrong, need to test it. The bug I opened is related to redirecting probe connection traffic through an HTTP proxy, to get true availability results in case target server is blocking the IP address of slowhttptest. You can find more details on differences between proxy models here - http://en.wikipedia.org/wiki/Reverse_proxy (types of proxy). What I call HTTP proxy is referenced there as open/forward proxy. If you are testing HTTP proxy, let me know, I'll either give you modified binary, or tell you how to compose the arguments to test the proxy itself.
Hi Sergey. Thank you for your response. In fact, I am trying to test HTTP proxy. So consider an example with curl: curl -x proxy:port http://website:port, where proxy is an HTTP proxy through which the web traffic is tunneled. However my goal is to test the slow read performance of the "HTTP proxy" (the application), not the webserver the traffic is redirected too. Also, the assumption is I have 3 separate hosts: 1) client machine 2) HTTP proxy machine 3) Web Server machine. Client machine is where I am running the test tool.
Currently I am considering a solution where the client hosts talks to the HTTP proxy host transparently by some means of network routing (that is all web traffic from client gets redirected to HTTP proxy, which in turn forwards it to the web server) . So I am wondering if there could be a way to do this from the tool perspective rather than routing. In any case I am interested on what you offered: "If you are testing HTTP proxy, let me know, I'll either give you modified binary, or tell you how to compose the arguments to test the proxy itself". I would appreciate your suggestions.
Akbar, what you want is doable, and I guess it makes sense to test HTTP proxy for slow read, as no matter how it is implemented - expecting the entire HTTP request or establishing connection to target website once it reads the Host header, it should be as vulnerable to slow read as any other process, that deals with concurrent connections. It should bepretty easy to add that functionality to slowhttptest. This is I am kind of busy now, but will do my best to finish it on the weekend.
So I added basic support for HTTP proxies(no SSL so far). Use -d host:port to direct all traffic to the proxy. Once I add SSL support for proxied connections, all release a new version. Meanwhile, checkout from svn.
Thanks for your time and effort, Sergey. I will try it out.
:D
well, that greate. thank you.
o.O
My site died in the first 5 seconds :( And I was SO sure I had protected it... ugh, well at least now I know...
Hi Sergey. I was trying to perform SLOWBODY attack on my IIS 7.5 hosting static web page as part of my school project. Seem like I could not get to DoS my IIS 7.5. Try by executing multiple tool to attempt but to no avail. Any clues if I have done anything wrong and any advises?
Regards, Kevin
Emailed you