Tails

#1 Updated by darkgrid 2014-04-08 20:34:07

This would actually be an easy fix since macchanger is already implemented, just need a couple extra lines of code.

If the “All random” is selected on startup do a simple ifconfig wlan0 down, macchanger -r, ifconfig wlan0 up or something similiar to that.

As far as the random hostname, I think that’s a much needed feature however that might take a little longer to implement than the random mac but it shouldn’t be that difficult to do.

Just one thing I want to mention about the random hostname. I’m a system administrator myself of a mid-size network and if I see an “amnesia” hostname on my network that’s a red flag however if it’s something random that will do a better job at flying under the radar and not calling so much attention to itself.

The hostname can be random characters however most hostnames are peoples computer names (Mike, Laptop, Susan, HomePC, Sunshine, moon, bluelap, etc.). A better way to implement this feature would be to a have a word list with something like the top 50,000 common English words or top 10,000 common names. If “Random hostname” is selected at startup the script basically picks one word or name from the list and sets it as the computers hostname. Of course this method will be a little more difficult to implement.

For a quick and easy way to implement the random hostname I see a random number 1 - 10,000 being a easy and effective fix.

#2 Updated by pluto 2014-04-09 22:28:14

This is a much needed feature, I constantly find myself having to manually assign a random mac everytime I use Tails which is rather annoying.

All they would need to do is change the startup from macchanger -a to macchanger -r if “Completely Random” checkbox is marked on startup.

Shouldn’t be more than 2 or 3 lines of code change.

Hopefully Tails developers notice this and implement it in Tails 1.0

#3 Updated by intrigeri 2014-04-10 05:50:30

> Hopefully Tails developers notice this

It is on purpose that we only change non-vendor bits. I realize the
relevant design doc doesn’t make this very clear, and I therefore
created Feature #7054 about it.

#5 Updated by intrigeri 2014-04-10 05:52:37

anon62 wrote:
> As an added bonus if a user selects this “Fully Random” option upon startup it can also assign a random host name instead of just “amnesia” which it currently assigns.

Please don’t use a single ticket for two different feature requests. Thanks in advance :)

#7 Updated by techfx 2014-04-14 01:26:13

Would be very useful if Tails 1.0 implemented the full random mac address option.

If fully random is not possible at least a 02-xx-xx-xx-xx-xx random mac would be great.

#8 Updated by sajolida 2014-04-14 06:51:34

Please read the thread on tails-dev I linked in order to understand why we are doing that on purpose.

#9 Updated by t3x 2014-04-15 20:32:30

I have looked over the link you posted and I still don’t understand why we can’t have a complete random mac address option on startup.

Can you please elaborate as to why the developers of Tails are against the idea of a fully random mac address option? Thanks.

#11 Updated by anonym 2014-04-16 12:10:05

I’d like to start by pointing out that the MAC spoofing feature in Tails is not only about hiding the user’s real MAC address, but is trying to achieve multiple goals at the same time, sometimes with tradeoffs due to conflicts between them. I recommend that you all read the “Threat model” section of our MAC spoofing design document so you get an understanding of, in particular, AdvGoalIdMacSpoof and AvoidIdMacSpoof.

intrigeri:
> anonym, please answer this. I guess your answer will be a good draft for Feature #7054 :)

I gave it a shot (will reference this comment in Feature #7054):

A MAC address has two components:

1. The first six bytes determines the Organizationally Unique Identifier (OUI) which in practice is the chipset’s manufacturer. Note that manufacturers generally do not have only a single OUI, but multiple.

2. The last six bytes are used to enumerate unique network interfaces for a particular OUI, i.e. so cards within the same OUI can be distinguished.

Spoofing the OUI part in a way that satisfies our threat model is not straightforward because of AvoidIdMacSpoof since multiple, large categories of OUIs violate that user goal:

• Unregistered OUI so its not used for any real device (-r option in macchanger)
• Registered OUI that was registered but never used for any real device (-r, -A, -a)
• Registered OUI but NICs are special purpose and hence impossible to run Tails on, e.g. NICs only used in ATMs, vending machines or embedded devices (-r, -A, -a)
• Registered OUI used for NICs in normal computers but for a different type of NIC than the device being spoofed, e.g. wireless vs wired (-r, -A. And -a if we consider other NIC categories than simply “wireless vs wired” since that’s the only distinction macchanger has)
• Registered OUI used for NICs in normal computers but they were manufactured decades ago (-r, -A, -a)
• Registered OUI used for NICs in normal computers but whose distribution is limited to some restricted, geographical area (-r, -A, -a)

So we have ruled out all macchanger options except -e, which means leaving the OUI as it is. We know it isn’t the perfect strategy. The more uncommon the OUI is, the more that part can be used for tracking and the more it violates the AvoidTracking user goal. At least this comes with some uncertainty compared to many of the impossible choices of OUI listed above, which would guarantee widespread violation of AvoidIdMacSpoof among Tails users.

Leaving macchanger aside, we’ve learned that when spoofing the OUI, it has to be picked very carefully, and there are other tools that take smarter approaches. macchiato, for instance, aims to maintain lists of current and common MAC addresses for different categories of devices so one can do less suspicious choices. However, both the “current” and “common” here are disputable since the criteria for inclusion in macchiato seems rather lax. The verification is up to the submitter, so an ignorant (not necessarily malicious) submitter can easily get an uncommon OUI into the lists. See e.g. the “Contribute” section of the homepage, or the author’s request on reddit.

Furthermore, the lists do not take into account that some devices are pretty much only used in some geographical areas. To end with, the lists are very small with around ~20 OUIs in most categories in current Git (as of 2014-04-16). Because of all this, the benefit and potential drawbacks of using macchiato are not well-understood.

Since we haven’t found anything better than macchiato, leaving the OUI seems like the best tradeoff between the different user goals in our threat model for now.