January 2, 2020

Guide: Generate and rotate .onion addresses

Learn how to create burner .onion addresses. Run through mass regeneration, backup and restore. Stay ahead of the game.

With a hidden service operating, security becomes a concern.

How to simply rotate .onion addresses through backup and restore


Let's learn how to automate generation of  .onion addresses.

Before we start here's reference to the previous guides, a quick how to create a vanity .onion address.  We've already covered how to host your own .onion site using nginx - now our mission is to stay anonymous with address rotation, gateways and workers.

Proceed to backup ALL addresses before we start - to later restore someday.
It's good practice to be keeping a backup of your keys anyway

tar -czvf ~/DIRECTORY/onions.tar.gz --exclude=cached-certs --exclude=cached-microdesc-consensus --exclude=cached-microdescs --exclude=cached-microdescs.new --exclude=lock --exclude=state  /var/lib/tor

Restore this at later date by extracting within the same folder

tar -xvf onions.tar.gz

Don't forget to modify the configuration (/etc/tor/torrc) on restore

NOTE: Please don't forget to use these addresses at some point (with rotation)

For fun, use generation.sh to produce .onion addresses on a large scale to mirror your current port :80
Note: don't forget to modify the "CHANGE THIS" sections

wget https://chown.io/files/scripts/generation.sh
chmod +x generation.sh
nano generation.sh

Please take the time to understand the code pay attention to annotations


#Creates directories, avoiding conflicts with randomisation
no5=$(< /dev/urandom tr -dc  A-Z | head -c5; echo)
no6=$(< /dev/urandom tr -dc  A-Z | head -c6; echo)
no7=$(< /dev/urandom tr -dc  A-Z | head -c7; echo)
no8=$(< /dev/urandom tr -dc  A-Z | head -c8; echo)
no9=$(< /dev/urandom tr -dc  A-Z | head -c9; echo)
no10=$(< /dev/urandom tr -dc  A-Z | head -c10; echo)
now=$(date +"%Y-%m-%d-%s")

#THINK: Just incase something screws with your torrc.. this can be restored
mkdir /etc/tor/$now
cp /etc/tor/torrc /etc/tor/$now/torrc

#####!!!!!!!YOU NEED TO CHANGE THIS BIT!1111!!!!!!!
echo "\nHiddenServiceDir /var/lib/tor/$no5/\nHiddenServicePort 80" >> /etc/tor/torrc
echo "\nHiddenServiceDir /var/lib/tor/$no6/\nHiddenServicePort 80" >> /etc/tor/torrc
echo "\nHiddenServiceDir /var/lib/tor/$no7/\nHiddenServicePort 80" >> /etc/tor/torrc
echo "\nHiddenServiceDir /var/lib/tor/$no8/\nHiddenServicePort 80" >> /etc/tor/torrc
echo "\nHiddenServiceDir /var/lib/tor/$no9/\nHiddenServicePort 80" >> /etc/tor/torrc
echo "\nHiddenServiceDir /var/lib/tor/$no10/\nHiddenServicePort 80" >> /etc/tor/torrc

#reloads Tor
service tor reload

#Graceful sleep for Tor to build, and write
sleep 5

#!!!!!!!!CHANGE THIS and CREATE your directory1!!
cat /var/lib/tor/*/hostname >> ~/DIRECTORY/onions.txt


Hosting the same service on the same server offers zero protection.

How could this be implemented within production to protect oneself?

EXAMPLE - A crook or spook has found our .onion address. We would like only a certain group to be notified of our secret area - alternatively, we could simply be rotating for extra caution.

Let's in effect create burner addresses and rotate only for example purposes

Remove ALL addresses and keys from /var/lib/tor


You could start by outputting the directories deleted

find /var/lib/tor -mindepth 1 -name keys -prune -o -type d -exec  rm -rf '{}'  \; -exec echo '{}' \; 2>/dev/null

Alternatively, mute output - echo the output to /dev/null

find /var/lib/tor -mindepth 1 -name keys -prune -o -type d -exec  rm -rf '{}' \; -type f -exec echo '{}' \; 2>/dev/null

With leaving our configuration (/etc/tor/torrc) the same, we'll automatically generate new .onion addresses

Let's reload..

service tor reload

Confirm Tor has reloaded

ps aux | grep tor

Who knew, bash could be so fun?

Grab ALL your .onion addresses using this

cat /var/lib/tor/*/hostname

Alternatively, echo the output to file

cat /var/lib/tor/*/hostname >> ~/onions.txt

That new address suits you - I must say.

Scenarios and future ideas

Output ALL addresses and print to a centralised location, allow users to communicate with separate workers for decent load balancing.

EXAMPLE: Have your workers communicate with gateways. Send the list of addresses to a database, a hidden application finds the lowest latency - passing this to users instantly.

Servers can be booted, cloned and configured with minutes; scaling, tuning, serving users. Fresh IPs, increased protection from DDoS, potentially

How It Works: DDoS is received to  worker -> the server is constantly mirrored, transferred to a fresh location -> Gateway 1 is notified of the move and receives new the list of .onion addresses  -> this fresh server isn't seen by the DDoS – the previous address "null routed"

You could alternatively have the workers distributed to only your users. Allows your team to communicate through Tor in time of need.

Explore possible options
– Configure a cron to implement
– Temporarily freeze addresses
– Generate / rotate / restore your addresses automatically
– Exclude your gateway .onion addresses
– Feed this data to ALL gateways and databases
– Use this to lower operating costs during non-peak
– Have staff notified of changes in addresses
– Move the same application across the world within minutes
– Leave the DDoS playing cat and mouse in following your automated trial
– Automatically send the updated lists to users
– Design a gateway infrastructure to prevent DDoS
– Constantly mirror your application and add load balancers

Are you keeping this identity?

I wouldn't settle

Considering hiring me

As always, stay well until the next time

Related articles
Simple guide: Tor Middle Relay
Host your own .onion site using nginx and Tor
Create a vanity .onion web address - learn how to import and export
Decrypt: Ross Ulbricht and Silk Road

Guide | Insight | Life | Linux | Tor