How to setup proxy servers for using the -p option?

[gratuitous-regex]

Hi, I'm just learning to use this tool from online articles and YouTube videos. Almost all of those sources are from around 2020 and talk about the -j flag. I noticed a lot of other flags have changed since then resulting in "unrecognized arguments" errors. After some more digging, I found a more recent article that discusses using proxies in a round-robin configuration. I'm a noob and I was wondering if someone could point me to documentation where I can learn how to setup proxy servers for the purpose of using pagodo?

[opsdisk]

Hi @gratuitous-regex - yeah, I've updated it a bit over the years so some of the switches aren't relevant. My biased advice is to check out my book on SSH tunneling, specifically the section on SOCKS proxies. You can find it for free here: https://github.com/opsdisk/the_cyber_plumbers_handbook

There's a paid lab portion as well if you're interested in getting more hands on experience with it that can be found here: https://opsdisk.gumroad.com/l/cphlab

You can spin up a cheap VPS from Digital Ocean, Vultr, etc...as long as you can SSH into it, you can set up a SOCKS proxy. Let me know if you have any other questions!

[opsdisk]

On your local box that you ran the ssh command from, ensure the SOCKS5 port is listening:

netstat -nato | egrep 10000

If so, swap out mydroplet'sipv4address for 127.0.0.1 or localhost:

python3 pagodo.py -d domaintosearch.com -g dorks/files_containing_juicy_info.dorks -p socks5h://127.0.0.1:10000 -s

[gratuitous-regex]

Thanks for responding. Port 10000 was not listening, so I changed to port 9051 and ran netstat -nato | egrep 9051 and confirmed the status was LISTEN. My query now looks like this:

python3 pagodo.py -d domain.com -g dorks/files_containing_juicy_info.dorks -p socks5h://localhost:9051 -s

I now get error 111 "connection was refused":

[MainThread ] [ERROR] EXCEPTION: SOCKSHTTPSConnectionPool(host='www.google.com', port=443): Max retries exceeded with url: / (Caused by NewConnectionError('<urllib3.contrib.socks.SOCKSHTTPSConnection object at 0x7f08847d3a60>: Failed to establish a new connection: [Errno 111] Connection refused'))

This is likely fundamental user-error on my end, so I greatly appreciate your patience. It is my understanding that in order to create a connection to the SOCK5 proxy, I only need to run this command:

ssh -D 9051 [publicipv4addressofmydroplet]

Then authenticate and verify the port is listening.

I then run my pagodo query from my "main" pc in a different terminal (not from the droplet's terminal). I am guessing that I'm missing a configuration step (I don't understand how the droplet's 127.0.0.1 becomes my main pc's 127.0.0.1).

[gratuitous-regex]

So I tried this again and it suddenly started working. No idea what I did differently. Thanks anyway for your assistance and this awesome program!

[opsdisk]

Good to hear! Appreciate the kind words.

[beachf2lightning]

Caveat for the Pagodo -p option with Kali's Mozilla or Firefox

Just wanted to offer a shout-out to Kali (Linux) users, which by default uses Firefox as its default browser......in the Pagodo -p parameter, -->try using socks5 rather than socks5h, and it will "work" - given that Pagodo utilizes Mozilla browser agent (in this case) to perform its Google searches.
My thoughts: It seems that Firefox / Mozilla does not support socks5h.

See the attached file "Caveat for the Pagodo -p option wit.t
Caveat for the Pagodo -p option wit.txt
xt" for my reasoning, background and example

[opsdisk]

Hi @beachf2lightning - apologies it took so long to respond, I do appreciate the data point. Perhaps I don't fully understand your use case, but the type of browser you use should be independent of pagodo and the SOCKS proxies you set up...as in it shouldn't matter. pagodo just interfaces with whatever proxy you specify with ssh -D 9050 for example.

This is more FYI and not related to pagodo, but if you want the Firefox browser to do remote DNS lookups, ensure the "Proxy DNS when using SOCKS v5" is checked at the bottom. In general, you always want that, otherwise you will "leak" your local DNS lookup requests (https://en.wikipedia.org/wiki/DNS_leak).