Remote distributed load testing is one of the performance models used to measure the performance (or latency) of the application under test, as it helps in scaling the test. Performance testing using IP spoofing helps in testing the application from the end-user location simulation. Like any other commercial tools, JMeter also supports distributed load testing fashion, but as an engineer, we need to spend effort for the initial setup. Cloud vendors like AWS or Azure have their own flavor of distributed load testing model which heavily relies on JMeter on the backend. In this blog post, I am presenting another perspective to measure the performance of the application using Proxychains.
Before we delve into the model, let us try to understand about Proxychains and its semantics, and also about Tor. Though I have been working as a performance engineer for many years. I also spend time learning around cybersecurity. Proxychains is one of the favorite tools for ethical hackers, penetration testers and security experts. It is written in C language.
Proxychains is a UNIX program that hooks network-related libc functions in dynamically linked programs via a preloaded DLL and redirects the connections through SOCKS4a/5 or HTTP proxies.
I know there are a lot of technical terms involved in the above introduction. Simply put, Proxychains helps in bringing anonymity to the system. It is not 100% foolproof system that brings anonymity, but it makes it hard to track.
This blog is intended for educational purposes only. I am not responsible for any damage you cause.
How Proxychains works?
Proxychains forces any TCP connection to use either TOR or any other SOCKS4 or SOCKS 5 or HTTP(S) proxy.
Here are the features of Proxychains:
- Various chaining options, such as strict, random and dynamic order
- support any application, including nmap, portscan, JMeter and more
- long chains with configurable timeouts.
More proxies, you add the latency shoots up.
Using Proxychains in Performance Testing and Engineering
Proxychains is more of an ethical hacker utility. Why should we use Proxychains for performance testing and engineering? I hear you. Proxychains brings anonymity via TOR or SOCKS and/or HTTP(S) proxy. This can be used to measure the latency of the application during the load testing. Also, it brings the flavor of security (at scale) in performance testing.
In this demo, let us use Fedora 36 to install Proxychains, Tor, and JMeter. I spun up a basic droplet in Digital Ocean to install a demo app using nginx.
Launch terminal and enter the following commands, which will update and install Proxychains.
sudo dnf update sudo dnf install proxychains-ng
To verify the installation, enter
proxychains in the terminal, which should display its usage.
In this demo, I intend to use Tor to bring anonymity. But if you would like to use freely available proxy servers, you can configure it in the proxychains conf file, which we will see in a moment.
sudo dnf install tor
After installing Tor, start the service and check the status using
sudo systemctl start tor systemctl status tor
Below are the
conf file locations that will be used by proxychains in order.
- ./proxychains.conf - $(HOME)/.proxychains/proxychains.conf - /etc/proxychains.conf **
Let us configure the below settings in
/etc/proxychains.conf. To make the changes,
sudo privilege is required. Enter the below command to open the conf file in
sudo vim /etc/proxychains.conf
dynamic_chainproperty, which uses the proxies chained in the order they appear in the list
proxy_dnsto proxy the DNS requests
- Go to the
[ProxyList]section and add the below entries:
[ProxyList] socks4 127.0.0.1 9050 socks5 127.0.0.1 9050
Save the configuration file and exit.
Test the Proxychains and Tor
To quickly smoke test the proxychains and tor, issue the below command, which will display your IP address:
Now let us launch curl with proxychains using the below command. This command will show you the different IP address. Because of the proxy chaining, as the log shows.
proxychains curl ipinfo.io/ip
Demo Application Setup
As I mentioned earlier, the demo app is running on Digital Ocean droplet. You can install nginx using the below commands:
sudo dnf install nginx sudo systemctl start nginx systemctl status nginx
Let us watch the nginx logs using the below command, which will display the source IP info if anyone accesses the nginx webpage.
tail /var/log/nginx/access.log -f
In the above screenshot I blurred my actual IP address. But this is how the access log logs the information about the traffic.
Proxychains in JMeter
Now let us launch the JMeter using the proxychains command, which launches the JMeter test plan.
proxychains /usr/bin/apache-jmeter-5.5/bin/jmeter.sh -t ~/jmeter-scripts/Proxychains_Demo.jmx
Here is the test plan design.
Execute the JMeter test plan by clicking on the Run button or pressing
Ctrl + R shortcut and observe the nginx access logs.
You will see a different IP address. If you google this IP address, it should be from a totally different country. In my case, it was from Romania. This IP address will be persistent for about 20 minutes. If you execute the test again, you will see a different IP address as source.
If you execute your load test, the source is from varying locations. Using this approach, you can test the actual (server-side) performance of your application.
We can also chain multiple proxies and use strict chain config. But it will increase the latency further.
There are free proxies available if you simply search in your favorite search engines. But most of them do not work. You can try your best.
This strategy can be extended in running the JMeter test using remote distributed load testing using multiple worker nodes.
Restricting IP Locations
By configuring the entry and exit nodes, it is possible to restricts the IP address of specific countries using the
Though the Proxychains is for ethical hacking and penetration testing, it can be used in almost any application. Usage of Proxychains along with Tor, helps in testing the application from a real location with few configuration. Otherwise, the initial setup to run tests like this needs networking knowledge. Consult with your network admin team and validate the settings before you use the above approach in performance testing.