Tuesday, May 12, 2015

SSH Tunnel with Proxychains

Thought I would quickly document how I have been utilizing SSH to create a tunnel and then using proxychains to access devices at and beyond the device the tunnel is connected to.

To establish the tunnel the following command is executed after the keys are setup to allow authentication with an SSH key:

ssh -i key.priv -p 22 thepcn3rd@7host.local -D 7500 -N -f

This connects to the host at 7host.local with the username thepcn3rd over port 22 with the key.priv.  Then it establishes on the local computer port 7500.  The best explanation for the -D switch I have found is in the man page for SSH:

-D [bind_address:]port
Specifies a local “dynamic” application-level port forwarding.  This works by allocating a socket to listen to port on the local side, optionally bound to the specified bind_address.  Whenever a connection is made to this port, the connection is forwarded over the secure channel, and the appli‐cation protocol is then used to determine where to connect to from the remote machine.  Currently the SOCKS4 and SOCKS5 protocols are supported, and ssh will act as a SOCKS server.  Only root can forward privileged ports.  Dynamic port forwardings can also be specified in the configuration file.

Now you can configure proxychains to use port 7500 by modifying /etc/proxychains.conf.  Typically the last line of the proxychains.conf file is the only one that needs to change as shown below:

# proxychains.conf  VER 3.1
#        HTTP, SOCKS4, SOCKS5 tunneling proxifier with DNS.

# The option below identifies how the ProxyList is treated.
# only one option should be uncommented at time,
# otherwise the last appearing option will be accepted
# 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 - 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
# 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
#chain_len = 2

# Quiet mode (no output from library)

# Proxy DNS requests - no leak for DNS data

# Some timeouts in milliseconds
tcp_read_time_out 15000
tcp_connect_time_out 8000

# ProxyList format
#       type  host  port [user pass]
#       (values separated by 'tab' or 'blank')
#        Examples:
#             socks5 1080 lamer secret
# http 8080 justu hidden
# socks4 1080
#        http 8080
#       proxy types: http, socks4, socks5
#        ( auth types supported: "basic"-http  "user/pass"-socks )
# add proxy here ...
# meanwile
# defaults set to "tor"
socks4 7500

The last line contains the address that the port is bound to and then the port above, that we used after the -D switch.  I also removed the comment before the proxy_dns data setting.  This is necessary if the remote location has internal DNS and you want the DNS to work properly.  But then how do you configure proxychains to use the DNS server through the tunnel.

You can find the file /usr/lib/proxychains3/proxyresolv.  Below is what the file looks like for my current system:

# This script is called by proxychains to resolve DNS names

# DNS server used to resolve names

if [ $# = 0 ] ; then
echo " usage:"
echo " proxyresolv <hostname> "

export LD_PRELOAD=libproxychains.so.3
dig $1 @$DNS_SERVER +tcp | awk '/A.+[0-9]+\.[0-9]+\.[0-9]/{print $5;}'

In the above configuration file you can set DNS_SERVER to be the server inside your environment or where you are working.  Then to use proxychains with any application, I will use the example of iceweasel.  To launch it using proxychains you can type:

proxychains iceweasel

Then it will launch iceweasel making it aware of the tunnel.  Then any address that you go to through iceweasel and it exists on the other side of the tunnel will open.  If it is a URL like http://www.myserver.com it will resolve based on the DNS server setting above and pull up in the browser again if it is on the other side of the tunnel.  

No comments:

Post a Comment

Script for /usr/bin/theharvester

Wrote this quick script to run theharvester: #!/bin/bash # Script runs the harvester dns="domain.local" sources="baidu bing...