Database Info

Tutorial - Port knocking w/ ssh, vnc - Secure access from android to remote computer

What I wanted was a simple, secure way to access my home computer remotely from my android phone. I know there are vpn options but I’ve seen that cause battery drain issues if in constant use, and also is more than I wanted/needed to setup. I know I could just setup a ssh server but leaving port 22 open on the remote computer for anyone to scan and hack the password seemed too insecure for me. So I came up with this solution and have been using it for about 2 years now without any problems. I thought maybe I should share this method since it may be of use to someone else and I don’t know of anyone else putting all these together for use with android.
What this does:
By running a small script on your android phone in terminal (only 2 commands), your phone knocks 3 specific ports, in a specific order (like a combination lock), your remote computer recognizes this order and opens port 22 for 10 sec. Your script then ssh’s the remote computer on port 22 and you log in. The port 22 on the remote computer closes so no one else can see it, but the keep-alive feature keeps your ssh session open so you can do whatever you need, for as long as your like, without worrying about someone port sweeping the remote computer and seeing the port open, or brut forcing a ssh password on it. You with me so far?
Now the ssh session also uses port forwarding to forward port 5900 from the remote computer to port 5900 on the localhost of the android phone. Now you can open your vnc client and connect to the remote computer through your ssh tunnel and see your x11 desktop. So you know also have a secure VNC connection! All this is done securely and only runs ondemand.
While this may look like a lot to setup, it’s actually quite easy and should only take about 15min tops. This tutorial should be complete but if I’ve forgotten anything, let me know and I’ll be sure to update this page.
In other words, run two simple commands within a script and you have secure access to your remote computer from your phone! Enjoy!
Pros:
- Secure
- Works on 3G and wifi
- Runs on all android versions
- Works on all x11 GUI’s (gnome, kde, etc). Assuming a VNC session is also desired.
- Fun!
Problems:
- This only works on linux computers, although I’m sure there is a way to setup port knocking on windows. I have no use for this, but if people are interesting, I can add a way to my tutorial as well.
Howto:
Setup Remote Computer:
First we need to setup the remote computer. This is geared towards Debian/Ubuntu but small adjustments should have it working on all distros (I’m using Debian Squeeze personally). Let’s begin:
First we need to install a few packages if not already there:
Code:
apt-get install openssh-server x11vnc knockd
Now lets configure your ssh daemon. Using nano or another text editor, edit /etc/ssh/sshd_config:
Change the following line to read as follows:
Code:
PermitRootLogin no
This will disable root login, so you will login in as a user and then su to root (You can leave root login if desired, it’s just less secure and not recommended).
Next we need to edit our iptables, so open /etc/network/if-pre-up.d/iptables and add the following:
MAKE A BACKUP FIRST OF THIS FILE
Code:
# Accepts all established inbound connections
iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allows all outbound traffic
iptables -A OUTPUT -j ACCEPT
# Allow ping
iptables -A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
# log iptables denied calls (access via 'dmesg' command)
iptables -A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7
# Reject all other inbound - default deny unless explicitly allowed policy:
iptables -A INPUT -j REJECT
iptables -A FORWARD -j REJECT
Now we setup our port knocking. Edit /etc/knockd.conf:
Code:
[options]
UseSyslog
[openSSH]
sequence = port1,port2,port3
seq_timeout = 5
command = /sbin/iptables -I INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT
cmd_timeout = 10
stop_command = iptables -I INPUT -p tcp -m state --state NEW --dport 22 -j DROP
tcpflags = syn
[closeSSH]
sequence = port1,port2,port3
seq_timeout = 5
command = /etc/init.d/ssh stop
tcpflags = syn
The section [openSSH] is what opens the port for 10 sec by running the iptables command and then drops the packets after the time expires, running the stop_command. The section [closeSSH] is not needed. It was a failsafe I use in case I want to disable ssh if I thought I was getting hacked and could not login. This is also left to show how you can use the knocking to run different commands using another sequence of ports (for ftp, etc.)
Now lets restart the network interface and restart the knock daemon:
Code:
ifconfig eth0 down #adjust to whatever interface you use normally
ifconfig eth0 up
dhclient
/etc/init.d/knockd restart
/etc/init.d/sshd restart
Test your internet and make sure it works. To make sure you have it setup to run on boot, first determine your runlevel:
Code:
runlevel
Make sure knockd, ssh are in the /etc/rcX.d (where X equals your runlevel). If not, add it
Code:
ln -s /etc/init.d/knockd /etc/rcX.d/S02knockd
And so on for shh if needed, (again, adjust X to equal your runlevel)
Setup X11VNC password:
Code:
x11vnc --store password
create a script for ~/bin/x11vncserver
add this to the script
Code:
#!/bin/bash
x11vnc -safer -forever -usepw -noxdamage
The “-noxdamage” fixes a display problem of the desktop not updating in the android vnc client. Now if using gnome and you only care about vnc login for one user then, goto System → Preferences → Startup Applications → Add →
Name = VNC Server
Command = x11vncserver &
Or add to GDM for access to any user, add to /etc/gdm3/Init/Default:
Code:
x11vnc -safer -forever -usepw -noxdamage
DONE! (KDE will be similar but slightly different to load on login, post if help is needed)
Setup android phone:
create script called knockh in /system/xbin. Then add this:
Code:
nc -z [ipaddress] port1 port2 port3
ssh -L 5990:localhost:5900 [email protected][ipaddress]
Replaces the ipaddress with your own (google “what is my ip” if you don’t know your external ip). Replace the ports with the ones used in the config file above for knockd. Change the user to whatever user has ssh rights. Then
Code:
chmod 755 /system/xbin/knockh
Now run knockh in the terminal and you should see a login for ssh on your remote computer.
Next download “android-vnc-viewer” from the market (it’s free). Create a new connection by selecting “new” from the dropdown box.
Create a nickname, enter your x11vnc pasword, address is “localhost” and port is “5900”. For 3G connections, I recommend 8 colors, for wifi 256. I also check the “Local mouse pointer” in the checkbox. Now click connect and see your desktop!
(If you are on your local wifi network be sure to create another connection for your local ip address)
Fixes:
Keep in mind this is for remote networks, if you are on your local lan, this won’t work without changing the ip address.
If using a router or modem, setup port forwarding to your remote computer for TCP ports 5900, 22, port1, port2, port3 (your port knocking ports). Also make sure to setup a static dhcp for the remote computer so your router/modem doesn’t change it’s ip address and you can’t connect.
If you are using an ISP that doesn’t give you a static ip address for your router, you will not be able to login whenever they change it, you’ll have to update the script first with the new IP. A solution is to setup a dynamic dns, using dyndns.org or something similar. Free options are out there, just google it.
I hope this helps, please post if you have any questions, comments, etc. Enjoy!
-Mike

On some roms, the busybox version of "nc" does not allow the -z command for knocking the proper ports. I've pulled the version of it from CM 7.2 and put in my /system/xbin and full functionality has been retained. I've included both "nc" and "ssh" here and they should work fine if you are missing them. (Tested on my EVO LTE running mostly stock Sense ICS, but this is fine for other android versions)
nc
ssh
Hope this helps!
-Mike

Setting up OpenVPN on VPS server, and on ICS/GB clients

Warning: This configuration no longer works for me. Try at your own risk.
Who is this for?:
People who are comfortable installing servers but still need a little bit of spoon-feeding at times. People who already have a VPS and want to use it as a VPN for privacy purposes or to bypass a firewall. If you don't use ICS, your phone needs to be rooted.
I just spent a few hours figuring out VPN issues and want to share the fruits of my labor. This is for people with a server who want to set up both the server and the client. Goal: route all your internet traffic through your server when the VPN is active. You need a VPS or dedicated server to do this. I went with OpenVPN because PPTP VPNs don't work with some ICS roms. I don't know a lot about networking issues, so I can probably help with some linuxy-server setup issues, but a lot of networking is beyond my grasp.
Server config:
The hard part was the server config, which I found helpful information for on two pages. OpenVPN must be installed, and then you must generate keys and a little bit of data for the server. I used instructions here (but if you search for "server generate openvpn keys", there should be a lot of tutorials). On my system the "init-config" command didn't exist, so I basically skipped that step. When finished, copy client1.crt, client1.key, and ca.crt to the phone.
I had a really hard time with the config file, but this little bug report was a fantastic resource. I ended up with the following config file:
Code:
dev tun
server 10.8.0.0 255.255.255.0
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key
dh /etc/openvpn/keys/dh1024.pem
verb 5
push "redirect-gateway def1"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
comp-lzo
status /var/log/openvpn-status.log
log /var/log/openvpn.log
log-append /var/log/openvpn.log
The DNS servers I'm using are google's. OpenDNS would be another good choice.
ICS instructions:
Install OpenVPN for Android. Open it, click "All your precious VPNs", add one and configure it. In the "basic" section, choose your server's hostname. For "type", choose "Certificates". Below that, select "ca.crt", "client1.crt", and "client1.key" in order. (Choose them with the file picker then press the "Select" button.) These are the files you generated on the server and copied to the phone. No other options need to be changed. Press "back" to save and touch the name of the configuration you've created. Enjoy your VPN-based browsing!
Gingerbread instructions (or ICS if you like pain):
Your device needs to be rooted with busybox and kernel tunneling capability. If you're running a popular rooted ROM, you probably have all you need. Install OpenVPN Installer and OpenVPN Settings. Run OpenVPN Installer and install the OpenVPN executable (please read the instructions--this may not work if your phone does not have the file /system/xbin/busybox).
Remember the files I told you to copy to your phone? Put them in /sdcard/openvpn/. Here's the client configuration file I used, which you should save as /sdcard/openvpn/openvpn.conf:
Code:
remote YOUR-SERVER.com
dev tun
client
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
comp-lzo
ca ca.crt
cert client1.crt
key client1.key
mute-replay-warnings
Then open the OpenVPN Settings app and check the two checkboxes to start the server and start the tunnel. Enjoy your VPN-based browsing!
To check whether it worked:
Use a browser to visit whatismyipaddress.com. The result that's displayed should be the IP address of your server.

Any way to make this work with http://tunlr.net/

Sorry, Tunlr.net is not related to OpenVPN.

Proxy Merry Go Round

I have ConnectBot configured to tunnel to a remote machine and the appropriate ports forwarded to access several services on that machine. As I understand it I further need a proxy layer to pass traffic to ConnectBot locally. I currently use proxydroid for this purpose. It worked the first time I configured it and I only recently found something about it I do not like and went in search of alternative proxy apps that might behave in the way I need.
The goal is to be able to write a Tasker sequence that connects the tunnel (completed this portion) and then activates the proxy. Unfortunately there is not automated way that I can determine to toggle proxydroid active/inactive. The interface, AFAICT, requires manual interaction in order to turn it on and off. proxydroid does have an option to automatically connect in the presence of certain networks but that it almost entirely useless to me, in fact, it would be better if it could connect when a particular network is NOT present.
Anyhow, in my search for alternative proxies I discovered a few apps that have some serious potential but hardly work:
Auto Proxy (not to be confused with AutoProxy): Is free, has amazing options for autoconnecting based on IP strings (which would be super and not involve Tasker at all) and has some of the more unique features. Unfortunately this proxy does not work in the least. I may be doing it wrong but it should be kept in mind that I can easily use proxydroid so the settigns are a known factor.
AutoProxy Lite: Is free, has fairly limited options and requires the paid version to autoconnect but even then autoconnection appears to be based on network presence which as I have mentioned is useless. This one I can get to work although I have to enter the necessary ports in the forwarding section which is really strange to me. The port forwarding should be happening at the tunnel not at the application layer but whatever if it works. The interface leaves much to desired, options are extremely limited and I just don't get the warm fuzzies about using the app. Using the free version will result in nag screens which will trip up any automated use.
Sandroproxy: Is free, appears to be fairly configurable and would be easy to automate with Tasker. Unfortunately this proxy doesn't work at all either. I appreciate the direct iptables output this one offers.
iptables, yes, now that we are talking about iptables I have some questions. I have a passing understanding of iptables/ipchains and can parse an iptables stack and can do some mediocre manual entry into one. However, regardless of which proxy I activate a listing with "iptables -L" always indicates a stock iptables stack. I've read that kernel level support must be enabled for iptables to work which would explain the failure of the 2 apps that don't work at all and the unchanging iptables list output. I'm using CleanKernel which is stock with some CPU frequency change allowance and some optimizations but nothing added outside stock. So, does a stock GS3 kernel support iptables/netfilter? Are the working apps using a method outside iptables? I suspect my iptables works fine but I'm missing something about how to get appropriate listing from it.
What the hell is keeping the other apps from working?
Any help is appreciated even if it input on passing startup info to proxydroid which "just works" 100% of the time.

Hi,
As far I can understand you have tunnel from android to machine and you want that some application use it.
So you probably want to redirect some android port to android tunnel port.
Something like this one:
iptables -t nat -A OUTPUT -m owner --uid-owner <xxxxx> -p tcp --dport 80 -j DNAT --to 127.0.0.1:8009
This will redirect all tcp that process (uid-owner) wants to make to destination port 80 to android port 8009.
You will see iptables NAT table with:
iptables -t nat -L
And you need proper version of iptables (iptables -V). 1.4 or higher should work with redirection.
You don't need SandroProxy to achive that.

iptables v1.4.11.1 check
netstat -tulnp | grep 8080 verifies ConnectBot listening on 8080 check
(why simply appending :8080 to the address IP doesn't hit CB without proxying it there was initially confusing but below i discuss the socks proxy)
(note, establishing proxydroid on any port that CB is forwarding will result in xxx.xxx.xxx.xxx:$port being forwarded through the tunnel so long as $port is in CB's config to forward since proxydroid is currently configured as a global proxy)
I tried a few variations of your supplied iptables append string with no positive results which is fitting with the below discussion about no socks proxy in place.
Armed with the knowledge that there is more than one table and I was simply listing the filtering table I fired up proxydroid and listed the NAT table and found all traffic redirected to port 8123. Netstat confirmed redsocks listening on port 8123. So, this leads me to believe that the missing element in simply redirecting traffic to port 8080 or any other tunneled port is a socks5 proxy.
I am currently chewing through this link: http://przemoc.net/tips/linux#making_socks_proxy_transparent with the intent of leveraging iptables and redsocks to perform the needed redirects manually possibly switched on and off with shell scripts executed by Tasker (although, if i can successfully configure to redirect based on destination ip/address then, for my putposes the only automation required is that which I have already achieved; establishing and shutting down the tunnel.
Any further insight you have to the above ends is greatly appreciated and I thank you for your input to date.
SandroBSupp said:
Hi,
As far I can understand you have tunnel from android to machine and you want that some application use it.
So you probably want to redirect some android port to android tunnel port.
Something like this one:
iptables -t nat -A OUTPUT -m owner --uid-owner <xxxxx> -p tcp --dport 80 -j DNAT --to 127.0.0.1:8009
This will redirect all tcp that process (uid-owner) wants to make to destination port 80 to android port 8009.
You will see iptables NAT table with:
iptables -t nat -L
And you need proper version of iptables (iptables -V). 1.4 or higher should work with redirection.
You don't need SandroProxy to achive that.
Click to expand...
Click to collapse

I will try with some simple Apache/ConnectBot/telnet configuration and let you know.

I tested and it works.
How I set up enviroment:
1. PC with apache running on port 80. Tested with telnet localhost 80 and GET<ENTER> that some response is shown.
2. android with connectbot port forwarding from android localhost 8100 to PC port 80. Tested with android telnet localhost 8100.
3. find out app id of browser on android with ps command and used same id in iptables rule
iptables -t nat -A OUTPUT -m owner --uid-owner app_4 -p tcp --dport 80 -j DNAT --to 127.0.0.1:8009
4. checked iptables rules that shows redirection
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
DNAT tcp -- anywhere anywhere owner UID match app_4 tcp dpt:www to:127.0.0.1:8100
5. Open browser with http://www.google.com url. It should show default page on my PC apache server instead of google first page.

Your environment seems optimal for making this work. And, maybe I need to reevaluate my remote end environment.
Currently the ssh daemon operates on a server machine that also includes a socks5 proxy for allowing unrestricted and encrypted access from any location. The service interfaces I wish to access remotely, however, reside on a separate machine on the same network. This means that the IPort has to pass unmolested through the tunnel. The socks5 proxy on the sshd machine is irrelevant to this process, it should be noted. However, as I understand it, the port being forwarded through the tunnel does have to be a dynamic port in order to appropriately reach the second PC. Dynamically forwarded ports are handled with a socks protocol in ConnectBot.
So my environment is as follows
192.168.1.101 serves sshd on port 22.
192.168.1.100 serves interfaces on ports 2100, 8080, 80801 and 8082.
From the android device (S3) I expect to enter the address 192.168.1.100:8080 into a browser and have the related service interface be accessed remotely. This is exactly what occurs with the appropriate ports forwarded from ConnectBot and using proxydroid as a global proxy or even as a proxy tied directly to the app similar to your iptables string that matches the owner application. It should be noted that since the port is dynamic it really only requires ConnectBot to have a single port forwarded and for the redirection to jump to that port regardless of the originating port (say, 8080 or 8081 or 2100) because the originating port passes the tunnel unmolested in this configuration.
It sounds like I could relocate the sshd to the PC hosting the service interfaces and alleviate this issue (maybe, possibly) of having to use dynamic ports and use a more traditional explicit local to remote port forwarding scheme. However, knowing that it can be achieved otherwise leads me to seek a solution that doesn't require reconfiguration of the remote PCs and all of the various machines I have configured to access this configuration remotely for other purposes.
I did try your iptables string exactly and also without the owner application matching making it a more global redirect if I parse it correctly. I also tried these configurations with ConnectBot configured with traditional instead of dynamic port forwards but neither way works.
I still believe that the proxydroid method is succeeding because it includes the socks5 proxy layer via redsocks. I believe but cannot prove that this is what enables the dynamic port forwarding to work through the tunnel. While the method you are outlining makes good theoretical sense it is failing in practice.
All that said, I decided to run a test wherein I redirected all traffic on port 80 to port 6543 and then configured connectbot to forward from port 6543 to port 8118 which should engage my remote socks5 proxy and use my remote internet connection. It appeared to work and to double check I disconnected ConnectBot yet somehow my android browser still had no issues accessing internet sites on the 4g connection. So, apparently iptables is being ignored entirely or I am completely missing the boat, here.
iptables -t nat -A OUTPUT -p tcp --dport 80 -j DNAT --to 127.0.0.1:6543
iptables -t nat -L =
OUPUT
DNAT tcp -- anywhere anywhere tcp dpt:www to 127.0.0.6543
Explain how that successfully fetches http requests despite having a service listening on 6543 to facilitate it.
Not sure if it was required to use that -m match switch to tie the iptables rule to an application so I tried:
ps | grep lan =
Application is 23094
therefore
iptables -t nat -A OUTPUT -m owner --uid-owner app_23094 -p tcp --dport 80 -j DNAT --to 127.0.0.1:6543
iptables -t nat -L =
OUPUT
DNAT tcp -- anywhere anywhere owner UID match app_23094 tcp dpt:www to 127.0.0.6543
Same result; not tunnel or service listening on 6543 but successful fetch of http requests.
SandroBSupp said:
I tested and it works.
How I set up enviroment:
1. PC with apache running on port 80. Tested with telnet localhost 80 and GET<ENTER> that some response is shown.
2. android with connectbot port forwarding from android localhost 8100 to PC port 80. Tested with android telnet localhost 8100.
3. find out app id of browser on android with ps command and used same id in iptables rule
iptables -t nat -A OUTPUT -m owner --uid-owner app_4 -p tcp --dport 80 -j DNAT --to 127.0.0.1:8009
4. checked iptables rules that shows redirection
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
DNAT tcp -- anywhere anywhere owner UID match app_4 tcp dpt:www to:127.0.0.1:8100
5. Open browser with http://www.google.com url. It should show default page on my PC apache server instead of google first page.
Click to expand...
Click to collapse

Before I investigate further...
Is this a typo or iptables doesn't work okey?
iptables -t nat -A OUTPUT -p tcp --dport 80 -j DNAT --to 127.0.0.1:6543
iptables -t nat -L =
OUPUT
DNAT tcp -- anywhere anywhere tcp dpt:www to 127.0.0.6543

Yeah, that was a typo into the forum.
I have globally redirected all port 80 traffic to localhost port 6543 with no service listening on 6543 yet any browser will successfully fetch pages. It seems iptables is being ignored entirely although it should be noted proxydroid modifies iptables to a successful result.
SandroBSupp said:
Before I investigate further...
Is this a typo or iptables doesn't work okey?
iptables -t nat -A OUTPUT -p tcp --dport 80 -j DNAT --to 127.0.0.1:6543
iptables -t nat -L =
OUPUT
DNAT tcp -- anywhere anywhere tcp dpt:www to 127.0.0.6543
Click to expand...
Click to collapse

Just for fun I installed DroidWall and blacklisted both browsers on my phone. Neither browser has any issues whatsoever retrieving webpages despite the blocks. I listed the iptables to verify there are indeed blocks in place. My iptables are being ignored entirely. Any input to this regard would be quite helpful. Obviously any attempts to manipulate packet redirection with iptables is meaningless if the tables are ignored.
Strangely, proxydroid is effective and it is making changes to iptables when enabled, so I have no idea WTF at this point.

Okay, I deleted all chains which seems to have cleared up the issue with all rules being ignored. If I am not mistaken my output chain was being directed to a chain called samsung_market_policy so, if I wasn't placing the rules within that chain (and I was not) they were being jumped before they could be read. I have no idea what breaks when you remove the samsung_market_policy chain but considering it was an empty chain I suppose nothing.
That said, I can now successfully redirect port 80 traffic to port 6543:
iptables -t nat -A OUTPUT -p tcp --dport 80 -j REDIRECT --to-ports 6543
^^^If no service listens on 6543 the browser provides an error message as expected. With ConnectBot listening on 6543 and forwarding through the tunnel to remote port 8118 where I have a proxy server listening the pages fetch.Note a socks5 proxy is listening on the remote machine at port 8118 to manage the retrieval of the pages.
Sooooo, now I flush the above rules and enter:
iptables -t nat -A OUTPUT -p tcp -j DNAT --to-destination 127.0.0.1:8080
^^^Should, in my understanding send all tcp traffic of any variety to localhost port 8080 where I have ConnectBot configured to forward dynamically to the remote machine.
Passing any address of any variety fails in this instance. There is a service listening on remote machine 192.168.1.100:8080. This address fails where it would not do so with a local socks5 layer. Google.com fails as well, which makes sense considering there is no proxy to perform the domain resolution but so does passing 74.125.137.138 which is Google.com's direct IP address.
I have further testing to do and will report back. If you have any input I am eager to hear it.

I will add that I am back on the same merry go round:
2 of the proxies do not work 2 of them do. The 2 that do will not connect without direct user interface on screen. At any rate, I remain convinced a local proxy layer is needed for my purposes.
The 2 proxies that do work are explicitly socks5 while the 2 that are not simply state they are socks.

Sorry that I am not very active lately. Quite busy so I can not make some proof of concept environments.
But now that you have working tunnel you can have proxy on PC side that will do all the work?
You just set in Settings->Wifi->Modify Network->Show advanced settings->Proxy->Manual->localhost 8080 on android.
And have some squid, apache proxy active on the other side of tunnel.

Yes, this works... for a wifi connections. However, I am rarely connected to wifi and when I am it is the network that the remote pcs are attached to so all of this becomes unnecessary.
For a 3G/4G connection I need to either:
A) Easily and automatically toggle a global proxy on and off (the main complaint with proxydroid is this missing feature)
or
B) Make a permanent redirect of destination IP 192.168.0.0/8 to the proxy without stripping the destination port information so that the transport carries that information.
A kludge solution I am currently using is to install FireFox mobile and then the Network Connections plugin which allows all FireFox traffic to be pointed to my ConnectBot tunnel. Then, in this way, to access my remote service I simply use FireFox Mobile and my other browsers for normal traffic.
This is a less than ideal solution, unfortunately, as I would like to be able to use any browser and also and more importantly other applications such as AndFTP, which fail unless a local socks5 layer is transporting the destination IP AND Port through the tunnel. That is, if AndFTP or a normally configured browser are pointed to the tunnel then the port information only serves the purpose of reaching the tunnel and is not transmitted to the remote end for connecting to remote services on their respective ports. There HAS to be a local transport layer that is moving the destination IP AND Port unmolested to and through the tunnel.
All that said, I suspect my earlier attempts at iptables redirection were successful at transmitting the packets TO the remote computer but additional rules must be configured to parse the incoming packets FROM the remote computer.
My next efforts will be directed at creating a shell script that sets up a redsocks proxy and an iptables redirection for the 192.168.0.0/8 range to that proxy. Which, is effectively recreating the efforts of people like yourself who wrote applications such as Sandroproxy, proxydroid and Auto Proxy. I will also be sending a request to proxydroid developers for an easier on/off toggle such as a checkbox instead of the current slider which cannot (as far as I know) be automated or, even better, to have that proxy auto-effect for a destination IP range.
SandroBSupp said:
Sorry that I am not very active lately. Quite busy so I can not make some proof of concept environments.
But now that you have working tunnel you can have proxy on PC side that will do all the work?
You just set in Settings->Wifi->Modify Network->Show advanced settings->Proxy->Manual->localhost 8080 on android.
And have some squid, apache proxy active on the other side of tunnel.
Click to expand...
Click to collapse

[GUIDE] Using an Android device as a Mumble (murmur) VOIP server. [No Root] Required!

Tutorial version 1.0 by: Talbot *TBOT* Simons “Monsieurtalbot”
WHY?
I was looking around the internet a while ago for a good tutorial on this. Sadly, after many years no one had released one – and after many hours of testing I have managed install and run a mumble (murmur) server - from an Android device using a Debian compatibility layer app called Debian NoRoot. It took a lot of tinkering over a couple years to discover this working method - and it works really well.
There are many benefits to having your own Mumble server… not to mention one that fits in the palm of your hand and can be transported… Not to mention one that can act independently – INCLUDING a built in WIFI network and battery – but using this method, not only is it possible to take a private VOIP server everywhere you go – it’s possible for it to run really smoothly with any mid-range smartphone made after 2012. Broadcast your own WIFI network and connect with friends in a private offline chat within WIFI range…. Or connect to a WIFI network, forward a port from your router and expand the coverage to all of the internet… All with an old android you probably have lying around somewhere. Use it anywhere a walkie talkie might be needed, but not available. Text chat is also included and working – and it’s all as private as possible really… You are even able to encrypt your connection at that point – or simply host it locally and use it anywhere you have a large local network you can tap off of… Hotels & cruises – speak between rooms via the WIFI… etc etc. I can see this being implemented in places where internet is scarce and communication is needed… It will work on devices many people are discarding – and in a world where privacy is becoming scarce – it’s nice to know that the method of your communication is safe.
DISCLAIMER - MUST READ
I am not responsible for any data loss or device damage. Proceed at your own risk, though none of what we’re doing here should be considered risky. I’m not including pictures as I’m a busy man – but the process is quite simple and the instructions are quite exact. I think you’ll be fine.
This has been tested on several Android devices of various screen sizes and processor architectures going back to 4.0. It should work on most if not all devices. An old Android you have sitting in a drawer is a perfect candidate for this – not a bad thing to just keep installed on your personal device as well if you’re a power user like me. The program we’ll be using is able to run most if not all Linux apps … A lot of possibility here. No root is required for most of the features to work in this tutorial. Root isn’t needed if you are on an unlocked device, or if you have tethering provisioned on your wireless account. Tethering is only needed if you plan on using the device to broadcast a WIFI network to make it truly independent from a WIFI router.
Some features of the server may or may not be broken, I personally don’t require much besides a server with no password. If anyone runs into any issues down the road, please let me know!
Click to expand...
Click to collapse
With that being said – let’s begin.
___________________________________________________________________________________
INSTALLATION -
1. Download the following apps from the Play Store on your Android “server device”.
1. Debian NoRoot – The Debian linux environment (takes about 900MB space on internal SD)
2. Plumble – (mumble client) either free or paid version is fine.
3. Fing – Network tools for scanning IPs and networks.
ALSO EITHER:
Stock WIFI hotspot feature (if you have active wireless service)
OR
WIFI Tether Router – (requires root) allows for WIFI networks to be created without a WAN connection.
OR
If you just want a local server hosted and want to use your home router (with or without port forwarding for WAN access to your server) – you can do that too.
Click to expand...
Click to collapse
2. Open the Debian NoRoot app you just downloaded – let it install and set your DPI and font scale to whatever is best for your device. Typically messing with the stock settings won’t do much good for you.
3. Open the terminal that is found on the desktop of Debian, or open it from the menu if your screen is small. Execute the following commands:
sudo apt-get update
(wait for the process to finish - accept any dependencies with Y)
sudo apt-get upgrade
(wait for the process to finish - accept any dependencies with Y)
sudo apt-get install mumble-server
(accept any dependencies with Y – there will be some errors, ignore them.)
sudo dpkg-reconfigure mumble-server
(Autostart: Yes, High Priority: No, Then set the super user password when prompted.)
sudo nano /etc/mumble-server.ini
(This is where you’ll edit the server info – there is much documentation on setting up a mumble server and configuring this file elsewhere on the web… Things like server name, welcome message, server password – etc etc are located in this setting file. Save the file and go back to the terminal.)
sudo /etc/init.d/mumble-server restart
(That’s it, the server should now be running with your new settings in the background. There is no UI and no icons that pop up.)
Click to expand...
Click to collapse
4. Once this is done – keep in mind even though you set the Autostart it is not going to work in this environment – so you will need to manually start the process via it’s script file – so lets create a shortcut to it on the desktop to make starting the server easier.
The script file is located at:
Code:
/usr/bin/murmur-user-wrapper
“Two finger tap” the file and “send to -> Desktop (create link)”
You will now double click this desktop link to start your server after you open the Debian Environment.
5. You can now press the home button to put the Debian environment in the background. Open the “Plumble” app you downloaded *on the same device* and set up a new server with the following settings:
Label : LOCAL SERVER
Address: 127.0.0.1 - leave the port as 64738 or change it as you like.
Username: Whatever you want – I used ADMIN for the server device.
Password: leave blank unless you set it up in the settings file.
Click to expand...
Click to collapse
Once you save the server if should show as online. Connect to it and change the default audio setting to push-to-talk in Plumble settings… If you don’t see it online, restart the phone, or some devices require to be connected to some form of network before the server will show as online. See the next step.
5. Once the server is running you have a number of options on how you can set it up and connect to it. – if you aren’t seeing the server – attempt the following - either step A, B or C first before ripping your hair out.
A. Connect to a WIFI network – set a static IP for your network in Android WIFI settings… You can then use it locally… or you can forward the port you used in the last step to the static IP you set in your router’s settings.
B. Broadcast a stock android hotspot – if you have active wireless service and tethering provisioned or an unlocked device – if you don’t, some custom Android roms will activate and broadcast a network anyway, some won’t… depends on device – your mileage may vary. This is cool for direct device to device communication but will not allow you to use it over the internet. Wireless carriers block a lot of ports incoming.
C. Open WIFI tether router – set it up based on your device. This app requires root but is the most likely to work in a completely offline scenario with no available external WIFI network or when you don’t have service but want to turn a couple phones into walkie talkies in the grocery store. Option B and C are very similar in function but C works with no service – in a plane, a cruise ship, the middle of nowhere, etc etc.
Click to expand...
Click to collapse
6. At this point – we can start connecting other devices… Either get the mumble client for PC/Mac or download “Plumble” and “Fing” on another android device. iPhone also has free mumble clients and network scanners.
7. Open “Fing” on the server device and run a scan if you are on a WIFI router network. Note your server device’s IP address and confirm that the devices you are trying to have connect have an IP address themselves. You may need to run “Fing” or another network scanning app on the secondary device to determine the server device’s IP address… Especially if you are doing this with option B or C for connection.
8. Open Plumble (Android) or your PC/Mac/iOS mumble client and configure it to the server IP you determined in the last step… As long as they are on the same network you should see the server online… Connect and set the push to talk setting on the second device. You should now be able to chat between the server device and the secondary device… and you should be able to connect multiple others as well.
9. Reboot the device.
10. At this point It’s 100% installed and ready to go. The server boot process to recap is quite simple.
- Connect the server device and secondary devices to the same network, hotspot, whatever.
- Open “Debian NoRoot” from a fresh device boot. Sometimes a fresh boot is needed for the server to run properly.
- Once Debian environment is fully loaded, two finger click the shortcut we created for the murmur server and choose the top option – “execute”
-Open Plumble on the server device and connect to the local server profile you created
- Determine the server’s IP address based on how you connected and set up the client devices.
- PROFIT.
Click to expand...
Click to collapse
I hope you enjoyed this tutorial and find it useful – if anyone takes these steps, please help the community and provide screenshots that I may add to this post. The information was sourced and pieced together from so many places… I’d like to thank… Google search - as well as the developers behind the apps used in this tutorial. I'm amazed that after all this time something just clicked and low and behold - it works!
Cheers and best wishes all!

Just an update - this is surprisingly stable, and I have had a server running on an old android device for over 2 weeks with no downtime.

Awesome work! I've been debating trying to port Murmur to Android for a while now as I have an Android STB sitting around that would make a perfect server.

zyperion said:
Awesome work! I've been debating trying to port Murmur to Android for a while now as I have an Android STB sitting around that would make a perfect server.
Click to expand...
Click to collapse
There's already an armhf distro for murmur on debian... This is actually still working great. It's the only reason this works... Same package for the raspberry pi. =]
Any app for Android that allows you to boot I to a chroot Linux environment this will work on...
Sent from my LG-US996 using Tapatalk

Yeah, it's a very clever solution that seems to be working pretty well. I'll have to give it a try! I've also been looking into trying to get Ubuntu installed on my Minix Neo X5 instead since I don't have any need for it as a media box anymore which makes Android far less desirable than a functional Linux install.

Apple iOS iPhone critical security - firewall - hardening

BACKGROUND:
The most basic tenet of network security is to run a tight firewall that blocks all incoming connections that the user did not initiate (some services do require new incoming packets to go through but that is a security issue and must be dealt with separately).
SECURITY ISSUE:
iOS provides a firewall pf ("packet filter") but it is turned off by default and is not configured. Major security issue. (I'm using iOS 12.5.4 on iPhone 6, not 100% sure about other devices and later iOS versions. Pretty sure it affects all devices and versions, though.)
SOLUTION:
It's not just a solution. It's a top priority requirement for all iOS device users to lock down their firewalls.
1) jailbreak your iPhone - this is the only way to access the pf firewall and secure your iPhone
2) install a terminal app
3) change root password
4) create a pf.conf file in ~. This is the pf firewall configuration file that will be used to filter packets. In this example, everything is blocked except basic internet access and connectivity on WiFi interface that is initiated by the device.
Code:
scrub in all
block in all #default behavior block everything
block out all
block quick proto tcp to 17.0.0.0/8 #Apple IPs used by analytics - a concern, kept connecting unsolicited
pass out on en0 inet proto udp from any to any port = 53 keep state #required for DNS
pass out on en0 inet proto tcp from any to any port { 80 443 } keep state #HTTP and HTTPS
pass quick on en0 inet proto udp from any port { 67 68 } to any port { 67 68 } keep state #WiFi DHCP
5) enable the firewall with the above configuration:
Code:
pfctl -F all -f ~/pf.conf -e
COMMENTS:
pf is also limited in comparison with a Linux analog iptables in that it cannot filter by process ID. This iOS shortcoming is awful and a security issue.
ADDITIONAL HARDENING:
As a next step you can close all unneeded serial ports/TTYs. For example , on iPhone 6 you will have cell signal with the ability to use cell services and use Wi-Fi if you:
chmod 000 /dev/tty
chmod 000 /dev/tty.*
chmod 000 /dev/uart.*
chmod 000 /dev/cu.* (except cu.debug is required for cell connectivity and cu.gas-gauge for battery stats, so must also chmod 006 /dev/cu.debug and chmod 006 /dev/cu.gas-gauge)
Then, restart CommCenter, bluetoothd, wifid.
You can unload com.apple.nfcd entirely because you will not be able to change permissions/close nfc's ports/TTYs.
Unload com.apple.BlueTool, it's Bluetooth and it's a hack vulnerability, until at least you can filter it.