ProxyChains is a truly useful tool when indirect access to a server is needed, whether due to geographic restrictions, IP filtering, or any other reason. This software operates by intercepting libc functions related to networking and reflecting them through a pre-configured SOCKS4a/5 or HTTP proxy. This implies that it will only work with programs dynamically linked against the same system libc.

Install the software:

pkg install proxychains-ng

apt install proxychains4

We set up the proxy, in my case, a SOCKS5 proxy set up via SSH on port 7778:

We consult the example configuration file(only available under FreeBSD):

In my case, I add the commented proxy:

vi /usr/local/etc/proxychains.conf

vi /etc/proxychains4.conf

# Remote server:
socks5	127.0.0.1 7778

We check the IP without ProxyChains:

79.116.9.6

Now using ProxyChains:

[proxychains] config file found: /usr/local/etc/proxychains.conf
[proxychains] preloading /usr/local/lib/libproxychains-4.so
[proxychains] DLL init: proxychains-ng 4.17
[proxychains] Strict chain  ...  127.0.0.1:7783  ...  icanhazip.com:80  ...  OK
A.B.C.D

ProxyChains allows chaining multiple proxies together. As an example, I’ve used the one previously configured via SOCKS5 and a public HTTP proxy from this website . Be cautious with public proxies as they may inspect traffic or even log connections, potentially revealing the masking if demanded by any authority:

[ProxyList]
socks5  127.0.0.1 7783
http 35.185.196.38 3128

We can see the proxy chain by running ProxyChains:

[proxychains] config file found: /usr/local/etc/proxychains.conf
[proxychains] preloading /usr/local/lib/libproxychains-4.so
[proxychains] DLL init: proxychains-ng 4.17
[proxychains] Strict chain  ...  127.0.0.1:7783  ...  35.185.196.38:3128  ...  icanhazip.com:80  ...  OK
34.105.87.158

Additionally, we can have a list of proxies and connect through them in various ways:

#dynamic_chain
#
# Dynamic - Each connection will be done via chained proxies
# all proxies chained in the order as they appear in the list
# at least one proxy must be online to play in chain
# (dead proxies are skipped)
# otherwise EINTR is returned to the app
#
strict_chain
#
# Strict - Each connection will be done via chained proxies
# all proxies chained in the order as they appear in the list
# all proxies must be online to play in chain
# otherwise EINTR is returned to the app
#
#round_robin_chain
#
# Round Robin - Each connection will be done via chained proxies
# of chain_len length
# all proxies chained in the order as they appear in the list
# at least one proxy must be online to play in chain
# (dead proxies are skipped).
# the start of the current proxy chain is the proxy after the last
# proxy in the previously invoked proxy chain.
# if the end of the proxy chain is reached while looking for proxies
# start at the beginning again.
# otherwise EINTR is returned to the app
# These semantics are not guaranteed in a multithreaded environment.
#
#random_chain
#
# Random - Each connection will be done via random proxy
# (or proxy chain, see  chain_len) from the list.
# this option is good to test your IDS :)

# Make sense only if random_chain or round_robin_chain
#chain_len = 2

Another interesting aspect is tunneling DNS requests through proxies to avoid correlation between the time of connection to the final server and the time of DNS record resolution:

## Proxy DNS requests - no leak for DNS data
# (disable all of the 3 items below to not proxy your DNS requests)

# method 1. this uses the proxychains4 style method to do remote dns:
# a thread is spawned that serves DNS requests and hands down an ip
# assigned from an internal list (via remote_dns_subset).
# this is the easiest (setup-wise) and fastest method, however on
# systems with buggy libcs and very complex software like webbrosers
# this might not work and/or cause crashes.
proxy_dns

# method 2. use the old proxyresolv script to proxy DNS requests
# in proxychains 3.1 style. requires `proxyresolv` in $PATH
# plus a dynamically linked `dig` binary.
# this is a lot slower than `proxy_dns`, doesn't support .onion URLs,
# but might be more compatible with complex software like webbrowsers.
#proxy_dns_old

# method 3. use proxychains4-daemon process to serve remote DNS requests.
# this is similar to the threaded `proxy_dns` method, however it requires
# that proxychains4-daemon is already running on the specified address.
# on the plus side it doesn't do malloc/threads so it should be quite
# compatible with complex, async-unsafe software.
# note that if you don't start proxychains4-daemon before using this,
# the process will simply hang.
#proxy_dns_daemon 127.0.0.1:1053

Some usefull commands that work correcty under ProxyChains are:

proxychains nmap -sT -PO -p 80 -iR targethost.com
proxychains telnet targethost.com 25

Be careful because there is possibly software that doesn’t work with it due to this . As a personal recommendation, I suggest testing it in a controlled environment before launching anything blindly to ensure that our IP address is not leaked.