Fortysomething Geek

Tails is a TOR based amnesic based operating system. It is basically a Live-CD/USB operating system that gets you on to the TOR based Onion network for complete privacy. The normal usage is to run it off a CD or USB. Virtual Machines are not recommended but people do it anyways. I won't get into the debate or discuss the merit of running it via live boot USB versus running it in a VM. The basic argument against the VM's premise is if the host hypervisor is compromised, you are not truly anonymous. Furthermore, keyloggers, remote desktop can cause problems. Lastly, most VM's bridge or NAT networking can potentially leak info.

If you are going to run it in a VM, I have some suggestions. Hence, the topic of this blog post.

First of all, you want to have much isolation as possible. Most Hypervisors allow you to dedicate specific hardware to the guest operating system. Never share anything. This includes soundcards, bluetooth, and most importantly ethernet/wi-fi devices.

For the sake of this post, I am using Mac OSX and VMWare Fusion. However, the concepts and principles apply to Windows, Linux or VirtualBox.

When you create your guest, try not to store it on your drive.If you do store it on your drive, encrypt it. And encrypt it again. My main hard drive has file fault but I go even further and store my image in an Encrypted container. In this case a DMG.




I can then go toss my DMG image into an encrypted USB stick.
Then go another step further and use VMware's built-in encryption to protect the VM file.

(be sure to enable it to ON!)

Since the whole guest will be relatively small, I strongly suggest throwing it on a USB stick. You don't want anything on your host.

Now to the VM itself. Clean it up.

I then remove everything I do not need. Remove the Sound Card. Disable the bluetooth sharing.
Everything except USB. If you need sound, I have a solution for that later.


Most importantly, remove the hard drive as you don't need it. You will be booting from the ISO file. Your VM files should be less than 2MB.

In fact, you can disable all networking on your host computer. When you bridge or NAT, you cannot truly mask your host's computer with advance sniffing. Your host computer doesn't even need to be physically connected to the network.

Now, if you disable networking, how do you get on the Internet or have any networking?

This is the important piece of info. Get yourself some cheap NIC devices. USB ethernet dongles, wi-fi sticks. Treat them like disposable SIM cards you have on disposable phones. The MAC ethernet addresses of those devices will be unique and will not trace back to your computer.

No bridging. Not NAT traversal. Complete isolation from the host. If you no longer have a need for the NIC, simply throw it away and get a new one. That last tip is for the paranoid.

Under your USB settings, you will want the guest operating system to "own" the particular device.
In this case, my portable USB dongle. Since Tails uses Debian, I've notice most USB network and wireless dongles work out of the box including the ASIX 88179 USB 3.0 gigabit dongle.


Once you boot into TAILS, you'll see the USB network adapters as if they were native to the TAILS operating system.

I would also do a simple ifconfig to verify you are indeed using the hardware.



Another cool thing you can do is dedicate a separate USB mouse/keyboard to the Virtual Machine. This should eliminate one of the key concerns of running Tails inside a VM - potential keylogging from the Host. As for sound, since you disabled sharing from the host, you can use a USB sound DAC if you really want sound inside Tails. Again, you need to give dedicated USB ownership to the guest.

Here I use a Motorola LapDock. I dedicate a separate full screen display to my VM and use the built in keyboard/trackpad. The key entries are unknown to my host Macbook Pro. Also pictured is an Apple 10/100 USB dongle that also works very well with Tails.


Now back to my disclaimer on the top of this post. This is for informational purposes. I've been evaluating Tails/Tor to see if anyone on our network can go un-detected. We've provisioned Kali intrusion boxes; sniffed network with Wireshark/Ethereal and we are still testing. I have to say, I am very impressed and scared at the same time.

Did you ever want to have your own private GitHub-like repository where you can store your code and share them with others? Well, today, I will be discussing how to install a private GIT web app that takes only a few minutes to set-up. Writing this post will take longer than running this exercise.



GITLAB is a GITHUB clone built on RoR (Ruby on Rails). It is a web application designed to allow you to host your own private GIT repositories. You can go to their website and do the full install or simply install a VM appliance. It works great for storing code. It has some basic collaborative tools like sharing guests, issuing merge and issues. This is an ideal app for a small web or smartphone-app development team.

Installing via an VM appliance is the most painless way to go. No need to install a full Linux distro and setting it up.I use Turnkey Linux and you should too. It has a large library of pre-built appliances and GITLAB is one of them I use on a day-to-day basis. I have installed over four instances of GITLAB on my ESXi server.

Today, I am going to show you how easy it is to get your own private GIT repo server up in a few minutes running just VirtualBox.

Step 1. Download ISO or OVF from Turnkey Linux.
Step 2. Create New Guest inside VirtualBox
Step 3. Install, set passwords
Step 4. Reboot.

That is it.





Ok. this post was short on specifics but if you know what you are doing, you can see it only takes a few minutes. Now, there are some things to consider and I'll elaborate and you give you a more detail set of instructions in this second part of my post.

The Detailed Setup Instructions.

This is for Mac OSX and Linux users.

The most important thing about setting up a VM appliance is deciding what sort of networking you want to use. In VirtualBox and with GitLab (or any other Linux web app), there are only two choices: Bridge-Mode or Host Only. Do not use NAT mode.

Bridge Mode will make the guest act as another computer on your network. If you have a DHCP server, it will request an get an assigned IP address. The advantage to this is that the machine is available to others on your network. Your friends and colleagues can access your GIT server as well.

Host Only mode allows the host computer and guest to see each other. Only the computer running VirtualBox will see the guest. The advantage to this is if you work offline, say camping 2 weeks at Yosemite Park without WIFI, you can access your Virtual Guest. Unfortunately, since the guest does not have outside network access, it can't do things like send email notifications and the like.

Both have their advantages and disadvantages and their use case.


The second most important thing is Hostname. You need a domain name to use GITLAB. Do not rely on IP address because it may change. If you do not have a valid DNS name (one being issued by a DNS server on your network), you can fake it by using and modifying /etc/hosts.
This is what I do. My clients (be it OSX, Linux) only need to add an entry to the host file to see my GIT server. If you are hosting this on the Internet and have your own DNS name, this you don't need to worry about it.

In my example, I will be using localgit.local.
On my machines that need to access the GIT server, I add an entry with the IP address (either DHCP or static) and my fake DNS hostname, localgit.local



That is pretty much the only two important things you need to know.

Now for the full instructions.

After downloading the Turnkey Linux iso, you will need to create a Guest OS in VirtualBox.
Choose Linux & Debian for machine Type and version.


Specify the memory you want to use. 768MB- 1GB is enough.
Specify the disk type you want to use for the virtual harddrive. I always choose VMDK because it allows me to migrate later to VMware Vshpere if I choose to migrate my build. Your choice will be your own personal preference.


Set the drive size you want. I default to 20-60GB depending on my needs and I use Thin provisioning (or let the drive dynamically allocate/grow).

Before starting up the VM, choose the ISO disk image to boot from

Next Step. Boot the VM and go through the install process.




A few notes. It will ask you how to partition the Virtual Drive. This is your call and preference. I use the second option, Guided, because it is quick. I prefer not to use LVM in the event I want to mount this virtual drive from another Virtual guest that doesn't support Linux LVM. It will guide you through the process, install the bootloader and reboot one more time before you can use it.





After the VM restarts, you can disconnect the .iSO disk image. This next process is a series of prompts from Turnkey for passwords and set-up.

You will be ask to enter

• root password
• mysql password
• password for admin account (to access web site)
• email address for admin account

Once finished, you will be shown a menu where you can view administrative links, change IP, reboot, etc. This concludes the installation of GITLAB.

Post Install.

If you are reading this, I assume you know the basics of GIT and how to connect to remote GIT repos.
It will be the same here, you will need to set up SSH keys. GITLAB's web interface allows you to copy-n-paste into the web browser which simply things. Some GIT apps don't even require you to generate SSH keys and generate unique ones within their respective apps.






Creating Repos.
You can migrate existing repos from your local machine and push them to GITLAB or create a new blank empty one within the web app.




As you can see here below, I can see my source code and view changes within the GITLab web interface.