When performing a penetration test, there is the possibility that vulnerabilities left open on one server are not available on another. Proper load balancing will be almost completely transparent, which could easily lead to miscommunication of the testing results if you find any server issues on a server that is part of a pool.
Kali includes a script named Load Balance Detector (lbd.sh) that will quickly test for load balancing. Running this tool against our current balanced Kioptrix3.com server will provide you with input that the server is not load balanced, because the tool never gets a chance to see the other server.
However, if you edit your HAProxy configuration on the Ubuntu machine to use a round robin balance type (balance roundrobin) and reboot, the following command will find your balancer:
# lbdkioptrix3.com lbd - load balancing detector 0.4 - Checks if a given domain uses load-balancing. Written by Stefan Behte (http://ge.mine.nu) Proof-of-concept! Might give false positives. Checking for DNS-Loadbalancing: NOT FOUND Checking for HTTP-Loadbalancing [Server]: Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.6 with Suhosin-Patch NOT FOUND Checking for HTTP-Loadbalancing [Date]: 00:50:52, 00:50:50, FOUND Checking for HTTP-Loadbalancing [Diff]: NOT FOUND
Here, kioptrix3.com does Load-balancing, found via methods: HTTP[Date].
A site can be hosted by many different servers with varying degrees of security. Sometimes it only takes one of these servers to finish the job, and penetration testers need to ensure that nothing is overlooked.
As highlighted in the preceding example, it is not always possible to determine if a site is balanced or not. The lbd program has provided us with an interesting fact—it was able to determine that the site was being balanced by reviewing the HTTP[Date] method. Small changes between the servers being accessed are the key to making an accurate determination.
When running an nmap scan against the servers in our balanced pool, we see the following results:
# nmap -A -T5 192.168.175.101 Host is up (0.00056s latency). Not shown: 998 closed ports PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH4.7p1Debian8ubuntu1.2 (protocol 2.0) | ssh-hostkey: 1024 30:e3:f6:dc:2e:22:5d:17:ac:46:02:39:ad:71:cb:49 (DSA) |_2048 9a:82:e6:96:e4:7e:d6:a6:d7:45:44:cb:19:aa:ec:dd (RSA) 80/tcp open http Apache httpd 2.2.8 ((Ubuntu) PHP/5.2.4-2ubuntu5.6 with Suhosin-Patch) |_http-methods: No Allow or Public header in OPTIONS response (status code 200) MAC Address: 08:00:27:56:C4:B2 (Cadmus Computer Systems)
This information is expected. But how does it compare against the other Kioptrix machine?
# nmap -A -T5 192.168.175.102 Nmap scan report for 192.168.75.102 Host is up (0.00055s latency). Not shown: 998 closed ports PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH4.7p1Debian8ubuntu1.2 (protocol 2.0) | ssh-hostkey: 1024 30:e3:f6:dc:2e:22:5d:17:ac:46:02:39:ad:71:cb:49 (DSA) |_2048 9a:82:e6:96:e4:7e:d6:a6:d7:45:44:cb:19:aa:ec:dd (RSA) 80/tcp open http Apache httpd 2.2.8 ((Ubuntu) PHP/5.2.4-2ubuntu5.6 with Suhosin-Patch) |_http-methods: No Allow or Public header in OPTIONS response (status code 200) MAC Address: 08:00:27:82:09:5A (Cadmus Computer Systems)
We see that many of the findings are identical as expected, but here there is one minor difference to look for—the MAC address of 192.168.175.102 is different than that of 192.168.175.101. If these systems were not identical clones of one another, then there is a possibility that other differences would be visible as well. These are the little differences we will need to seek out.
Our web application is hosted by the Kioptrix machines, but is being balanced by our Ubuntu machine. This would typically be a virtual IP address used strictly to provide access to the two production machines that host our application, possibly in a tiered DMZ. Of course, if the app developers or administrators left holes in one of the servers or the application, we will quickly be able to bypass any such security measures and go directly to where the critical infrastructure and data lie.