Figured out how to get Node-Red to acknolodge TOR .onion addresses

255 views
Skip to first unread message

Josh Conway

unread,
Jan 19, 2016, 12:54:39 PM1/19/16
to Node-RED
Greetings,

I use a significant amount of HiddenServices to communicate back and forth with my machines. My eventual goal was to be able to process data from different geographical areas and have them inserted into MQTT via Node-Red. Until now, it was all or nothing with regards to proxy settings.

I have figured that out. For those that want to integrate seamless .onion usage across the whole of Node-Red (and every other Linux program), follow this.

get the following packages (Ubuntu, Debian)

sudo apt-get install tor iptables dnsmasq dnsutils

 
Add the following to the /etc/tor/torrc file

VirtualAddrNetworkIPv4 10.192.0.0/10
AutomapHostsOnResolve 1
TransPort 9040
DNSPort 53
DNSListenAddress 127.0.0.2

Restart TOR
sudo service tor restart

Edit /etc/dnsmasq.conf and add the following:
listen-address=127.0.0.1
resolv-file=/etc/realresolv.conf
server=/onion/127.0.0.2

Make a new file, called /etc/realresolv.conf . Add this in the file:
nameserver 107.170.95.180
nameserver 8.8.8.8

Restart DNSmasq:
sudo service dnsmasq restart

Run the IPtables firewall update for redirection
sudo iptables -t nat -A OUTPUT -p tcp -d 10.192.0.0/10 -j REDIRECT --to-ports 9040

Also, this script must be run at every boot, so add this in /etc/rc.local, ABOVE the "exit 0"
/sbin/iptables -t nat -A OUTPUT -p tcp -d 10.192.0.0/10 -j REDIRECT --to-ports 9040


Once you do those things, your whole Linux sustem will be able to resolve .onion addresses seamlessly, yet leaving alone canonical address schemes. this means that you can talk with a MQTT-out on an .onion, or control remote servers via exec node and SSH. And since you don't have to poke holes through firewalls, networking between Hidden Nodes with Node-Red sitting on top makes IoT sensor capture from remote areas (Work, home, car, hackerspace) very easy.

Of course, this does not discuss how to actually add a new hidden service You should think very hard before enabling a service: Make sure there is good authentication on them along with the newest updates. There is no determining origination on these kinds of attacks. But to do so, go to my blog : https://crankylinuxuser.net/2016/01/12/using-and-abusing-tor-like-no-ip-but-better/

Sincerely,
Josh Conway

cite: http://www.linuxquestions.org/questions/linux-networking-3/how-to-access-the-darknet-tor-network-4175553338/ , Have confirmed directions work flawlessly on Ubuntu 14.04, 15.04, and 15.10 (various flavors of Ubuntu, XUbuntu, KUbuntu)

Julian Knight

unread,
Jan 19, 2016, 4:22:04 PM1/19/16
to Node-RED
Wow! Nice work.

I'm adding this to my list of interesting possibilities. Maybe one day I'll get round to trying it out ;)


On Tuesday, 19 January 2016 17:54:39 UTC, Josh Conway wrote:
Greetings,

I use a significant amount of HiddenServices to communicate back and forth with my machines. My eventual goal was to be able to process data from different geographical areas and have them inserted into MQTT via Node-Red. Until now, it was all or nothing with regards to proxy settings.

I have figured that out. For those that want to integrate seamless .onion usage across the whole of Node-Red (and every other Linux program), follow this.
...

Ty George

unread,
Jan 20, 2016, 1:26:27 PM1/20/16
to Node-RED
Nice work ... I will have to try this out soon.

Ty

Greg EVA

unread,
Jan 21, 2016, 5:12:13 AM1/21/16
to Node-RED
Sweet Josh!  Thanks for sharing.

Josh Conway

unread,
Jan 21, 2016, 7:44:41 AM1/21/16
to Node-RED

Gladly, everyone !

My reason for doing this, is to challenge the idea that IoT needs some server in "the cloud" to handle your data processing. Instead, I want to bring the cloud of devices that I already own and online to Me.

The stated goal why many companies' IoT hardware offerings use their servers is so that you, the user, can communicate from anywhere to your devices. This also has the added effect of lockin and access to all your data. And the fact that it adds a single point of failure to your IoT network, it seems a bad deal. Of course, how do we compensate for this if we roll our own? We need our servers, sitting somewhere, handling the data (MQTT) and routing and making decisions on data (Node-Red)....

So why not make the server and all your clients in different locations to the same network? If they could talk to each other as if on a simple LAN, would be a tremendous advantage. Doing that the "standard" way means VPNs and pain and suffering. And then on the same network, the machines start chattering.

Right now, I have a home which I'm slowly wiring up with Arduino Nano/nRF24L01+/MySensors library kit. I also have a PIR sensor on my work machine's serial port to see if someone comes to my desk. And I also am a member of the local hackerspace, where I use that as a testbed for less stable rollouts. And I also have a private workshop where my 3d printer is located. I have internet in all places, and yet I want to submit data to my main MQTT server so I have it all in 1 place. Before, this wasn't possible. I don't control the routers some of those areas, so they were islands of data.

Now, with full .onion resolution, I can take local data and do an MQTT-in to my hrfuwhrf43fif3o.onion (made up address) main server from all my remote nodes, along with being able to subscribe to data on the MQTT as well. This also means that I can support websockets as well now with Node-red webpages and my Mosquitto client.

Another nice effect, when comparing to things like no-ip.org, is that griefers and hacklets routinely scan their DNS block for ripe machines to exploit and/or DOS. Even though your machine is fully patched and running current, you still have to deal with the greatly increased inbound traffic. With TOR, since the name is based upon your public key, it is effectively random. Scanning that whole space entails of around 36^16 addresses, or 65535*36^16 ports (?!). Effectively, unless you make your address public, it's probably going to stay hidden and garner less ingress. For me, that matters on my home network, as I only have 300KBs/100KBs.

And yes, the connections are all encrypted and anonymous, per the benefits of TOR hidden services. I really am not counting on using those abilities, because I know where my machines are. However as a really cool side effect, if one of my laptops do get stolen, if they connect to wifi (enabled guest acct with wifi access), I can log in via ssh-tor and record them :)

So, perhaps that gives a better background as to why this was an important piece of coming up with an alternate solution than "go through servers elsewhere". No, because I'll bring the servers to me.

Sincerely
Josh Conway

Greg EVA

unread,
Jan 21, 2016, 12:58:24 PM1/21/16
to node...@googlegroups.com
The idea that IoT requires cloud is in my opinion a) a narrow view on a very broad subject, and b) largely challeging due to general all encompassing definitions that have been taken on by cloud and IoT.

People love B) because you don't need to understand it or define it, you can just refer to something non-tangible and pretend like that should mean something similar for someone else without explaining anything.  You know, "the cloud", and "IoT".  Oh you mean stuff in the cloud on steroids; yeah, IoT man!  That should be the new definition for IoT. :-P

Julian Knight

unread,
Jan 21, 2016, 4:17:47 PM1/21/16
to Node-RED
I guess the "I" in IoT might be the give-away ;)

Of course, IoT is just a marketing name, people have been connecting sensors and controls over various networks as long as computers existed - maybe before. The use of the word "Internet" implies to me a standards-based, open network ToR is such a network in a fairly loose sense.

For me, ToR wouldn't be a lot of use as a command and control network as I spend too much time on enterprise sites - you can imagine the horror of a network admin or IT Security (which is actually part of my job!) discovering ToR traffic on the network :( Not good. Even worse if anyone discovered that it was me generating the traffic :}

However, it isn't that hard to create remote connections to onsite servers. Start by making the server (the Pi in this case) reasonably secure by adding https and a login. Then just forward a standard port on your router (443 perhaps) to the Pi. Now you can access it from anywhere on the Internet with encrypted comms. Really the only thing that ToR gains you is that the traffic from your computer (somewhere on the Internet) is not so easily traced back to your home location.

Josh Conway

unread,
Jan 21, 2016, 4:58:14 PM1/21/16
to Node-RED
Indeed!

I was looking at a few things, much of it being standards-ish ways of dealing with my problems. I wanted a simple interface in which to connect my sensors. And that's done, via MQTT.

Now my next pain-point is dealing with Dynamic DNS. I had a few ways I could have went: use no-ip, make my own DNS server from crankylinuxuser.net and do it from there, have node-red fire off an email every hour what my IP address is, or use TOR hidden services. No-ip has a 3 machine limit for free, and they have a restrictive TOS. They also have lots of griefing traffic, which really stinks. I also really, really don't want to run my own DNS. I could have NR deliver me my address, but then I have to update any machines that may be delivering data to my MQTT broker - no go.

That left me TOR. I get a DNS name, and I don't have to poke any holes in any router. Albeit, it's an Onion, but now I can easily work with that. And it's completely free. And it is fully encrypted and just works. If it sits, it fits :)

Sincerely,
Josh Conway

Edward Vielmetti

unread,
Jan 22, 2016, 1:57:23 AM1/22/16
to node...@googlegroups.com
I'm using an OpenVPN based VPN, with a master node living in AWS, for my command-and-control network. Granted it's not very huge but it lets me go to the cafe, fire up a tunnel, connect to the Raspberry Pi in the attic, and see how cold it is there.

--
http://nodered.org
---
You received this message because you are subscribed to the Google Groups "Node-RED" group.
To unsubscribe from this group and stop receiving emails from it, send an email to node-red+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--

Julian Knight

unread,
Jan 22, 2016, 11:40:16 AM1/22/16
to Node-RED
Good point about DNS. I've always managed to bag a fixed IP from my ISP. It is also the reason I won't switch to BT as they were one of the first to switch to so called "Carrier Grade NAT" which prevents you from serving up anything. Though it would be interesting to know if ToR works over that - anyone know?

I also have a Synology NAS and that can do some clever things with dynamic DNS so I could use that. I just stick with a fixed IP, I generally don't bother to set up a DNS for it though I could do as I've long used a cloud-based DNS service for my mail, blogs, etc.

As Edward mentioned, a cloud server can also be an intermediary. I have a couple of VPS's which tend to work out a lot cheaper than AWS or Azure and the costs are certainly more predictable.

You could, of course, run a broker on a VPS and get your Pi based broker to talk to it, that is quite a nice way of working though you would doubtless also want to run some web services on the VPS too so that you don't need to contact the Pi at all when you are on the road.

Lots of options.


On Thursday, 21 January 2016 21:58:14 UTC, Josh Conway wrote:
Indeed!

I was looking at a few things, much of it being standards-ish ways of dealing with my problems. I wanted a simple interface in which to connect my sensors. And that's done, via MQTT.

...
Reply all
Reply to author
Forward
0 new messages