I am testing my website with hydra brute-force software. But accessing my apache conf remote server file, it seems that an attacker can't log-in more a limited number of times per seconds. Does hydra systematically uses the same source IP to log, or can it spoof the adresses in order to attempt multiple logins alledgedly coming from numerous sources. If not, how can I test a brute force coming from several sources ?

  • 2
    Check your ISP and hosting provider's policies before you do anything like this. They're not likely going to expect you to go about brute forcing your own machine. – AbsoluteƵERØ Jun 5 '13 at 16:29

The server is going to respond to the IP given as the source. To brute force if it limits the number of connections per client, you would need multiple clients. This is often one of the ways that bot nets are used when brute forcing since they can connect from a large number of different IPs and each tries a smaller number of attempts.

  • But we're ok about the fact that no site can be brute-forced without bots, because I imagine that any server prevents a same IP from connecting too many times per second. Am I right ? – epsilones Jun 5 '13 at 20:26
  • @Newben - sadly no, unless you setup limits, the default behavior typically is not to prevent too many accesses per second, or if they do, it's measured in thousands of attempts, not single digit counts. – AJ Henderson Jun 5 '13 at 20:50

When making a connection to a webserver you make use of the TCP protocol. It is a stateful protocol and requires a hand shake to set up. The handshake is set up in three messages:

enter image description here

  1. a SYN message from the client
  2. a SYN+ACK message from the server
  3. another ACK message from the client

Only after this is done you can transmit data. The problem with IP spoofing is that the SYN+ACK message will never reach you and you will not be able to send the ACK message in reply. This makes the handshake incomplete and you will not be able to send any data. Furthermore when bruteforcing the login screen you need to get a reply from the server that you logged in successfully.

Even if you do not take into account my previous statement about TCP (for instance technologies which use UDP). If you spoof your IP the server will reply to the random IP and you wouldn't see the data either (unless you are on a hub like device or network and sniff all traffic AND provided the target device is on that same network).

  • 1
    Well written and nice choice of diagram. – adric Jun 5 '13 at 18:09
  • But we're ok about the fact that no site can be brute-forced without bots, because I imagine that any server prevents a same IP from connecting too many times per second. Am I right ? – epsilones Jun 5 '13 at 20:25
  • You'd be surprised how many sites don't have limits on the number of connections from a given IP, or very liberal limits. For example, an IP might be blocked if it's flooding the server in an attempt to DoS it, but a brute force attempt may not be connecting rapidly enough to trigger that defense. – guest Nov 25 '17 at 6:13

Yes, as long as you can figure out when you are successful without hearing directly from the host whose login you are brute forcing.

As noted elsewhere, simple TCP sequencing will thwart you from hearing back directly with a login success. Therefore you will have to devise another way to determine when you have used the correct login if you wish to succeed with this technique. The problem is the same if the protocol is UDP, actually, unless you can sniff the traffic heading to the hosts you are impersonating.

The IDLE scan technique developed for hping2 and currently implemented in Nmap (etc) suggests one way to do this sort of thing by looking for changes to IP header values that don't require a response to your spoofed IP. This is explained well in the Nmap book.

Extrapolate on this and either come up with a way to detect a change in the target host on successful login (perhaps web readable log files or status display such as found in unhardened web servers?) or cause one with your attack code.

Go for something subtle that you will be able to detect but that doesn't give the game away to others to win. Did the background color of this web site change just now? :D

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.