Add support for network interface selection

[edermi]

Hi,

it would be great to have a command switch to specify which interface gobuster uses for scanning.

[OJ]

Not a bad idea. I shall look into it.

[0xdevalias]

https://stackoverflow.com/questions/44571331/specify-network-interface-for-http-request-in-golang

Go's http.Client makes requests using a http.RoundTripper. This, in turn, uses a net.Dialer to establish the outbound network connections. net.Dialer has a field LocalAddr which specifies the local address from which the connections will be made. You can use your own Client, with your own RoundTripper, with your own net.Dialer, specifying the LocalAddr you want to use. You can see how each of these is instantiated in the stdlib code linked from the documentation, and copy the mechanisms used to create the default instances to maintain default behavior while overriding the LocalAddr as needed.

[firefart]

Is there any benefit on doing this in code? I think this should be rather done on the OS level using routes to keep things simple

[hlein]

Is there any benefit on doing this in code? I think this should be rather done on the OS level using routes to keep things simple

Sure. Suppose you have a scanning box w/multiple IPs. You are scanning some target that might have active defenses (https://github.com/fail2ban/fail2ban, etc.) and don't want to get yourself blocked during an enumeration run. gobuster -S or gobuster --interface while doing other things from other source IPs concurrently.

Another similar case would be if you have multiple IPs you can rotate requests through. Say a host will block after 10 404s in 3 minutes. Combine a pool of source IPs (obvs this requires a more complicated implementation than just "set my source") with --delay in order to maximize throughput without getting blocked.

You could achieve much the same with iptables rules, but that'd be quite cumbersome, require root to update, etc.

[firefart]

@hlein @edermi @0xdevalias I added a first try on the dev branch to specify either the interface name or the ip directly. Would be great if you can try it out (go install github.com/OJ/gobuster/v3@dev)

[hlein]

@hlein @edermi @0xdevalias I added a first try on the dev branch to specify either the interface name or the ip directly. Would be great if you can try it out (go install github.com/OJ/gobuster/v3@dev)

Thank you! Hm, I see --local-ip, --interface, --iface options now. But... when I add another IP to eth0 and use --local-ip otherip, the requests still originate from my default IP on that interface.

[firefart]

@hlein ok I thanks I will try to reproduce it. Seems like it's not that easy like described in the stack overflow article :D

[firefart]

@hlein sorry for the delay, could you please try again with the latest dev version? I currently have no VPS available that supports multiple public ipv4s per machine to test this properly. The options are --iface and --local-ip

[hlein]

@hlein sorry for the delay, could you please try again with the latest dev version? I currently have no VPS available that supports multiple public ipv4s per machine to test this properly. The options are --iface and --local-ip

Hi, sorry for the slow response... well, I still see the same behavior, outbound traffic uses the default IP.

I first tested using remote hosts and multiple IPs on eth0, but here is a test setup that should work locally on a Linux box with ncat installed.

In one terminal:

$ ncat -n -v -k -l 127.0.0.1 8888

In another:

# ip addr add dev lo 127.0.0.2/8
# ip addr add dev lo 127.0.0.3/8
# ip addr list dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
       valid_lft forever preferred_lft forever
    inet 127.0.0.2/8 scope host secondary lo
       valid_lft forever preferred_lft forever
    inet 127.0.0.3/8 scope host secondary lo
       valid_lft forever preferred_lft forever
# ncat -n -v -z --source 127.0.0.1 127.0.0.1 8888
Ncat: Version 7.95 ( https://nmap.org/ncat )
Ncat: Connected to 127.0.0.1:8888.
Ncat: 0 bytes sent, 0 bytes received in 0.06 seconds.
# ncat -n -v -z --source 127.0.0.2 127.0.0.1 8888
Ncat: Version 7.95 ( https://nmap.org/ncat )
Ncat: Connected to 127.0.0.1:8888.
Ncat: 0 bytes sent, 0 bytes received in 0.06 seconds.

Back in the first terminal:

Ncat: Connection from 127.0.0.1:10837.
Ncat: Connection from 127.0.0.2:6719.

Back in the second terminal:

# ./go/bin/gobuster dir --local-ip 127.0.0.2 --url http://127.0.0.1:8888/ -w ~/list
===============================================================
Gobuster v3.7
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url:                     http://127.0.0.1:8888/
[+] Method:                  GET
[+] Threads:                 10
[+] Wordlist:                /root/list
[+] Negative Status codes:   404
[+] User Agent:              gobuster/3.7
[+] Local IP:                127.0.0.2:0
[+] Timeout:                 10s
===============================================================
Starting gobuster in directory enumeration mode
===============================================================

Back in the first:

Ncat: Connection from 127.0.0.1:61402.
GET / HTTP/1.1
Host: 127.0.0.1:8888
User-Agent: gobuster/3.7
Accept-Encoding: gzip

Here we would expect to have seen from 127.0.0.2:....

Same for vhost and fuzz.

I can't spell Go, but when I strace gobuster I see regular socket() followed by connect(), whereas ncat does socket(), bind(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("127.0.0.2")}, 16) = 0, connect().