# be prepared for the german law for big WLAN hot spots

## toralf

```
#  WLAN

#

#config_wlp3s0="dhcp"

preup(){

  if [[ "$IFACE" = "wlp3s0" ]]; then

    macchanger -r $IFACE

  fi

}

postdown(){

  if [[ "$IFACE" = "wlp3s0" ]]; then

    macchanger -p $IFACE

  fi

}
```

edit: limit this for WLAN interface and filed  https://bugs.gentoo.org/show_bug.cgi?id=547020

Update much better :

```
mac_wlp3s0="random-samekind"
```

within /etc/conf.d/net (if it works however, I do suffer from a driver bug)Last edited by toralf on Thu Apr 23, 2015 4:47 pm; edited 5 times in total

----------

## NeddySeagoon

toralf,

Will we be able to get these big WLAN hot spots in Scotland :)

----------

## toralf

yeah, btw (in german) : http://www.heise.de/newsticker/meldung/Oeffentliche-WLAN-Hotspots-sollen-schnueffeln-helfen-2599623.html

----------

## UberLord

 *toralf wrote:*   

> 
> 
> ```
> #  WLAN
> 
> ...

 

If you do that, please set your DHCP clients to release their lease if they can so to reduce the lease pool burning out!

----------

## toralf

 *UberLord wrote:*   

> If you do that, please set your DHCP clients to release their lease if they can so to reduce the lease pool burning out!

 good hint

----------

## UberLord

Of far greater concern is sites you visit tracking the EUI64 component of your SLAAC address - so they have your MAC address regardless of the hotspot itself.

Luckily dhcpcd defaults to providing a private stable SLAAC address without any MAC details being leaked past the router  :Wink: 

----------

## UberLord

 *NeddySeagoon wrote:*   

> Will we be able to get these big WLAN hot spots in Scotland 

 

Scotland has teh intertubez?   :Rolling Eyes: 

Isn't the Scottish hotspot called England?   :Twisted Evil: 

OK, I'll stop now   :Very Happy: 

----------

## steveL

 *UberLord wrote:*   

> Of far greater concern is sites you visit tracking the EUI64 component of your SLAAC address - so they have your MAC address regardless of the hotspot itself.
> 
> Luckily dhcpcd defaults to providing a private stable SLAAC address without any MAC details being leaked past the router ;)

 

That's good to know. Sometimes I think we should publicise all these aspects of dhcpcd more brazenly.

As for the rest: please do.. ;p

----------

## toralf

 *steveL wrote:*   

>  *UberLord wrote:*   Of far greater concern is sites you visit tracking the EUI64 component of your SLAAC address - so they have your MAC address regardless of the hotspot itself.
> 
> Luckily dhcpcd defaults to providing a private stable SLAAC address without any MAC details being leaked past the router  
> 
> That's good to know. Sometimes I think we should publicise all these aspects of dhcpcd more brazenly.

 +1 - that' a candidate for die GMN

----------

## steveL

Yeah that'd be cool, toralf.

----------

## krinn

Sorry for being curious. What this law is about?

----------

## toralf

 *krinn wrote:*   

> Sorry for being curious. What this law is about?

 Bigger public WLAN hot spots have to support the spy action of the goverment (as this has to be made by TelCos for wired communication already)

----------

## krinn

Ah, i knew it was something stupid again.

Looks like european countries cannot work together, but when it comes to do shit, even following different paths, they all walk toward the same direction.

french did it easier btw, we have the great entity that attack the IP owner (lol yeah, i know, you were thinking nobody could do worst than germans, but french beat you badly).

Of course our ISP add free wifi option that takes few of your bandwith to provide free wifi to other travellers next to your spot, combine that with the "your IP is the badass, so you're the rat" ; wonder result  :Smile: 

It would be laughable if they (our politicians) weren't pay to do that crap, but they are, and with good big numbers.

----------

## steveL

 *toralf wrote:*   

> Bigger public WLAN hot spots have to support the spy action of the goverment (as this has to be made by TelCos for wired communication already)

 

Hmm. Art. 1 of the Grundgesetz provides:

```
(1) The dignity of [man] shall be inviolable. To respect and protect it shall be the duty of all state authority.

(2) The German people therefore acknowledge inviolable and inalienable human rights as the basis of every community, of peace and justice in the world
```

I really don't see how one can square arbitrary, Stasi-style blanket surveillance of all correspondence, with respect for anyone's right to privacy and a family life.

I was under the impression the ECHR had already ruled to that effect, but that might just be wishful thinking.

----------

## krinn

Yeah steveL, but something you read as "is" was written as "shall be"  :Smile: 

Don't worry, they would do the same even if it was written with "is"

----------

## steveL

krinn: As it was, so shall it be..  yea, and verily. ;-)

----------

## yngwin

 *toralf wrote:*   

>  *steveL wrote:*    *UberLord wrote:*   Of far greater concern is sites you visit tracking the EUI64 component of your SLAAC address - so they have your MAC address regardless of the hotspot itself.
> 
> Luckily dhcpcd defaults to providing a private stable SLAAC address without any MAC details being leaked past the router  
> 
> That's good to know. Sometimes I think we should publicise all these aspects of dhcpcd more brazenly. +1 - that' a candidate for die GMN

 

I'll be in charge of the next GMN. So can someone do a write-up with clear directions of how to do that and send it to gmn@gentoo.org? Then I'll include it.

----------

## UberLord

 *yngwin wrote:*   

>  *toralf wrote:*    *steveL wrote:*    *UberLord wrote:*   Of far greater concern is sites you visit tracking the EUI64 component of your SLAAC address - so they have your MAC address regardless of the hotspot itself.
> 
> Luckily dhcpcd defaults to providing a private stable SLAAC address without any MAC details being leaked past the router  
> 
> That's good to know. Sometimes I think we should publicise all these aspects of dhcpcd more brazenly. +1 - that' a candidate for die GMN 
> ...

 

Unsure what you mean? This is a feature of the stock dhcpcd install, so just use dhcpcd  :Smile: 

----------

## lost+found

rm /var/lib/dhcpcd/dhcpcd-wlan0.lease

Otherwise the old lease is requested (and NAK'ed because of the changed MAC), and "they" gotcha...    :Confused: 

And how about:

dhcp_wlan0="nontp nosendhost"

So they can't give you a clock skew, and write down your host name.   :Smile: 

When things don't go as expected (after a crash for instance, or restarting udev after an upgrade), it's a good idea to check /etc/udev/rules.d/70-persistent-net.rules. The MAC addresses in there, must be the real ones. Any extra interfaces added by Udev - based on fake MACs - can be removed. After that it needs a cold boot (power switch off).

Added:

Some reading about macchanger (syntax) in: /usr/share/doc/netifrc-0.2.2/net.example.bz2Last edited by lost+found on Thu Apr 23, 2015 6:14 am; edited 1 time in total

----------

## krinn

 *UberLord wrote:*   

>  *yngwin wrote:*    *toralf wrote:*    *steveL wrote:*    *UberLord wrote:*   Of far greater concern is sites you visit tracking the EUI64 component of your SLAAC address - so they have your MAC address regardless of the hotspot itself.
> 
> Luckily dhcpcd defaults to providing a private stable SLAAC address without any MAC details being leaked past the router  
> 
> That's good to know. Sometimes I think we should publicise all these aspects of dhcpcd more brazenly. +1 - that' a candidate for die GMN 
> ...

 

Because this feature is not well known, and just this feature may let many users use hdcpcd to have it.

Privacy (to my knowledge) isn't really a problem for us resident, but europeans really take that seriously.

----------

## charles17

 *steveL wrote:*   

>  *UberLord wrote:*   Of far greater concern is sites you visit tracking the EUI64 component of your SLAAC address - so they have your MAC address regardless of the hotspot itself.
> 
> Luckily dhcpcd defaults to providing a private stable SLAAC address without any MAC details being leaked past the router  
> 
> That's good to know. Sometimes I think we should publicise all these aspects of dhcpcd more brazenly.

 

You're welcome to add it to the wiki.

----------

## steveL

I'd gladly add it, if I knew wtf "the EUI64 component of your SLAAC address" meant (beyond the obvious that it looks like a 64-bit field, which reveals your LAN MAC addr.) Still, it's not so much about the wiki, though ofc it should be there too.

IOW: we need about a paragraph at least from UberLord, explaining what it is in a bit more context.

----------

## UberLord

IPv6 supports end to end connectivity. There is no NAT (at least not normally).

As such, a host you connect to will know your IPv6 address.

A IPv6 address is compromised of two parts - the Prefix which is unique to your site (office, home, etc) and your HostID, which is unique to your host at the site.

The HostID is generally formed from the MAC address of the network interface (which has to be unique to the site as well for IPv4 to work)

Take this IPv6 address

fe80::dead:beff:feef:f00d

From this, we can derive tha the MAC address is de:ad:be:ef:f0:0d.

We know this because the magic bits ff:fe are inserted in the middle.

If this host had a global prefix (fe80:: is local) it would look like so

2345:123:3::dead:beff:feef:f00d

So you can see, MAC address is the same.

There are two ways to mitigate this - DHCPv6 (because it's a stateful address and not PHY based) or a different way of generating the HostID.

IPv6 has long supported random temporary addresses, but this has pitfalls as you cannot use it on say a server and won't easily work with DNS.

This is where RFC 7217 comes into play. By storing a secret key on the host, we can use this along with other information such as the Prefix, MAC address and SSID of the connected network (obviously wired interfaces won't have that) and combine them together. Put the result through SHA256 and take a portion of the result to the be host ID.

This results in a stable but private address which changes for each network you connect to, so you cannot be tracked by IPv6 address across networks *

Here's the original Gentoo news article:

https://www.gentoo.org/support/news-items/2014-07-17-dhcpcd_6.4.2_changes_defaults_for_ipv6.html

* Of course, you are generally tracked by your browser as well, but we're strictly talking network topology here.

----------

## steveL

Perfect, thanks UberLord. :-)

----------

## krinn

How can it works with a NAT?

From my knowledge if my IP is 3.3.3.3 and this host (mac 4.4.4.4) send something to someone, it would send it back to my IP with my mac in it, allowing the router to know even it's for 3.3.3.3 the reply is for the host with the mac 4.4.4.4 and not some other random hosts.

So if the router cannot match the mac return value, it may drop the reply or give it to the host that is dmz no?

I don't have any ipv6 router to see how this work, but do ipv6 packets aren't made with the mac inside them too?

----------

## UberLord

 *krinn wrote:*   

> How can it works with a NAT?
> 
> From my knowledge if my IP is 3.3.3.3 and this host (mac 4.4.4.4) send something to someone, it would send it back to my IP with my mac in it, allowing the router to know even it's for 3.3.3.3 the reply is for the host with the mac 4.4.4.4 and not some other random hosts.
> 
> So if the router cannot match the mac return value, it may drop the reply or give it to the host that is dmz no?
> ...

 

Sorry, I was talking about http://tools.ietf.org/html/rfc5902 which discusses the possibility of NAT for IPv6.

There is also NAT64 - http://en.wikipedia.org/wiki/NAT64

----------

## krinn

Disappointed a bit, using ipv4 looks a better bet (as it is more common than ipv6, and more common mean higher anon).

Thanks for the info UberLord

----------

## szatox

Krinn, server doesn't have to know your MAC for any NAT to work. It's NAT that does all the Network Address Translator work.

It maps active connection from internal network (IP:port pairs) to external addresses (NAT's own IP:port) and replaces them in headers on the fly (along with CRC)

There are many modes of NAT which makes it hard to describe how exactly it works. Some modes (symmetric) are more annoying than others (full cone) though. For example symmetric can't be pierced with assistance from STUN because they will be mapped differently.

What might be worth noting, when you specify a gateway in your routing table, say:

route add XXX default gw YYY

what you tell your system is: do not ask XXX for it's MAC address. Ask YYY for it's MAC and send packet addressed to XXX with XXX's IP and YYY's MAC. 

After translation NAT looks like the source so incoming traffic will be addressed with NAT's external IP and external MAC. NAT maintains a list of active connetions and again replaces heades and forwards traffic.

----------

## UberLord

 *krinn wrote:*   

> Disappointed a bit, using ipv4 looks a better bet (as it is more common than ipv6, and more common mean higher anon).
> 
> Thanks for the info UberLord

 

Why is IPv4 a better bet?

https://trac.torproject.org/projects/tor/wiki/doc/IPv6RelayHowto

You've also missing one very importing point - games, especially P2P games!

A lot of games don't work well via NAT and require you to run uPnP on the firewall which IMHO is a security risk by itself.

This also means that only one host behind the NAT can play the game.

Because IPv6 is end to end games no longer have to have nasty code to get working connectivity.

TLDR; you can make IPv6 just as anonymous as IPv4

----------

## krinn

UberLord:

If you cannot manage to hide informations, then it's a better bet that the information seen is the most common, hiding yourself in the mass. Like your browser example, if you cannot hide your browser infos, then make sure your browser answer the name of the most common browser as it will make it harder to track yourself out of the mass.

Because of the limited range of IP from ipv4 class, and people habit with them, using yourself a class A or C should make it harder to track you. While of course the ipv6 should gave a perfect answer.

Oh and i see the point that i forgot with nat, even behind a nat, if this nat is part of the network, anyone can query arp and get your hw mac from it (as i don't think any nat exists that randomize/anon hw mac on arp queries ; at least mine doesn't) as the layer use in the network is 802.11 or 802.3 for the classic ones and not tcp.

And the problem with wireless is that you aren't joining an host from your external ip, but going to be part of its network, making hard to hide something to it.

Now i get really toralf concern about anon its mac.

Now the question is: if you join someone network with ipv6 trick you have in dhcpcd6, does the mac address is really taken from your stateful ipv6 given to the host or does the host query arp to get it (or read it in the ether header)? At least for ipv4 you cannot get it from the ip, so you must get it from arp, it would mean an ipv6 router may take the mac from the ipv6 address only and as such will use your fake mac build in your ip, but it would mean if someone do any ipv4 query in it, that router would be unable to find who is really behind that mac address, and making ipv4 fails.

----------

## szatox

 *Quote:*   

> even behind a nat, if this nat is part of the network, anyone can query arp and get your hw mac from it (as i don't think any nat exists that randomize/anon hw mac on arp queries ; at least mine doesn't)

  why would it use random values? This is how traffic is directed  through a switched network, it can't be random and still work.

In local (switched) network all traffic is being delivered based on MAC addresses. In routed network it's delivered based on IP. One your packet reaches router, source MAC address is replaced with router's external MAC and destination MAC (router's internal MAC) replaced with next-hop's MAC.

So, if you checked MAC adresses inside your local network, then you can see all MACs. Because there is no router in your way, even if that's how you call the box you plug all wires into. Router is being sidestepped, it's only a switch until you send your traffic out.

----------

## krinn

Sorry this is not how it works on my side: if any host wish speak with another host, it do an arp query and this is my router who answer to it, not my hosts. It looks like any answer would be taken as "truth" and hostA querying hostB for its mac will be handled and answered by my router. And hostA see no problem that it isn't hostB who answer it.

So it is not sidestepped but an active device.

ps: and i don't think i have a kick ass router  :Smile: 

----------

## steveL

 *krinn wrote:*   

> hostA see no problem that it isn't hostB who answer it.

 

Precisely: because it never knew about the internal MAC at all; it only answered the translated packet.

As for queries, I don't think that applies so much to established connections as to ports you have open in the firewall, in which case you're in another territory altogether (port-forwarding).

The point here is that the client host can select the MAC component (EUI64?), specific to the network it's on, instead of the router doing it.

That doesn't make it insecure because it's based on pseudo-random cryptography (so not leaking internal configuration), and can be changed at any point.

Though I agree a client doesn't need to preserve it across reboots, so there would be value in defaulting to flush at reboot, unless configured otherwise for server-usage, and allowing it to timeout with the dhcp lease etc. Though I imagine that happens already, it would be cool to have it change on a connection basis too (where a known-host is not required.)

No idea how much code that would take; can't think it'd be too much, but I'm not volunteering.

What about you? Patch/test/repeat-til-dead.. ;)

----------

