The fuckwits in Westminister have signed off on the Investigatory Powers Bill, including all the privacy-invasive provisions such as ICRs. The bill is simply awaiting Royal Assent now.
Someone on Ars has helpfully listed the agencies that will be able to request access (WITHOUT a warrant) to Internet Connection Records
Air Accidents Investigation Branch
Charity Commission
Commission for Healthcare Audit and Inspection
Commissioners of Revenue and Customs
Common Services Agency for the Scottish Health Service
Criminal Cases Review Commission
Department for Environment, Food and Rural Affairs (for the purposes of the Marine Fisheries Agency)
Department for Transport (for the purposes of transport security, Vehicle and Operator Services Agency, Driving Standards Agency and Maritime and Coastguard Agency)
Department for Work and Pensions
Department of Agriculture and Rural Development for Northern Ireland
Department of Enterprise, Trade and Investment for Northern Ireland (for the purposes of Trading Standards)
Department of Health (for the purposes of the Medicines and Healthcare Products Regulatory Agency)
Environment Agency
Financial Services Authority
Fire Authority for Northern Ireland
Food Standards Agency
Gambling Commission
Gangmasters Licensing Authority
General Pharmaceutical Council
Government Communications Headquarters
Health & Safety Executive
Her MajestyÂ's Chief Inspector of Schools in England
HM Revenue and Customs
Home Office (for the purposes of HM Prison Service and the UK Border Agency)
Information Commissioner
Marine Accident Investigation Branch
Maritime and Coastguard Agency
Ministry of Defence
NHS ambulance service Trust
NHS Counter Fraud and Security Management Service
Northern Ireland Ambulance Service Health and Social Services Trust
Northern Ireland Health and Social Services Central Services Agency
Northern Ireland Office (for the purposes of the Northern Ireland Prison Service)
Ofcom
Office of Fair Trading
Office of the Deputy Prime Minister
Office of the Police Ombudsman for Northern Ireland
Port of Dover Police
Port of Liverpool Police
Post Office Investigation Branch
Postal Services Commission
Rail Accident Investigation Branch
Royal Air Force Police
Royal Military Police
Royal Navy Regulating Branch
Scottish Ambulance Service Board
Scottish Environment Protection Agency
Secret Intelligence Service
Security Service
Serious Fraud Office
The Armed Forces
The Pensions Regulator
Special Police Forces (including the Scottish Drug Enforcement Agency)
Territorial Police Forces
Welsh Ambulance Services NHS Trust
Welsh Government (for the purposes of the NHS Directorate, NHS Finance Division, Common Agricultural Policy Management Division and Care Standards Inspectorate for Wales)
The Government, quite frankly, can go fuck itself.
I cannot, in good conscience, allow my family's data to be recorded on a list that will, inevitably, be misused/leaked. Managed by incompetent ISPs and scope and access "controlled" by bungling politicians. No thanks.
Raising this issue to start the process of moving all relevant traffic over to using a VPN and/or Tor.
There are a number of requirements
- The solution must support failover, so if an endpoint goes down, another should be used
- Responses to inbound connections should not transit the link
- Policies should be used to control what can and cannot egress the network (for example, the current VPN links should be allowed to leave as they do now)
- Port 80 traffic should still go via the transparent proxy and then transit the VPN link
- The system should fail closed. If all endpoints are unreachable, block all traffic (but provide me a way to override that for troubleshooting)
Most DNS queries already leave via a VPN, but this may also be a good opportunity to look at setting up DNSCrypt
Once the provisional infrastructure is in place, I'll run an audit with PAS to check that egress traffic is as expected
Use of a VPN won't be enough to stop a targeted investigation, but that's explicitly not the aim of this issue. The aim is purely to ensure that the ISP held Internet Connection Records for my connection don't contain anything of relevance.
Activity
2016-11-17 19:50:07
For example, France have a similar law on the books, but it only applies to ISPs that have residential customers, so a number of datacentres don't (officially at least) have the capability deployed.
An alternate approach, which may be suitable for some of the traffic, is to run a transparent Tor instance and configure it only to use exit nodes in the UK
ExitNodes {GB}There'll be a few headaches there though with some services blocking known exit nodes
2016-11-17 19:57:10
To begin with I'll use DNS round-robin for failover purposes and set something a little more intelligent up later.
2016-11-17 19:57:41
2016-11-17 20:28:49
2016-11-17 20:30:13
2016-11-17 20:30:39
2016-11-20 13:21:21
2016-11-20 13:31:57
2016-11-20 14:11:18
512Mb droplet running Debian 8
Essentially following the steps here - https://www.bentasker.co.uk/documentation/linux/259-openvpn-on-debian - though the easy-rsa steps are different on Jessie
Using subnet 10.17.0.0/24, so setting the following in server.conf. Also changing the DH param size to 2K
Setting up easy-rsa
KEY_SIZE was already 2048, so leaving that
Building the certs
Hit a slight issue here
Using configuration from /etc/openvpn/easy-rsa/openssl-1.0.0.cnf /etc/openvpn/easy-rsa/keys/index.txt: No such file or directory unable to open '/etc/openvpn/easy-rsa/keys/index.txt' 140002835130000:error:02001002:system library:fopen:No such file or directory:bss_file.c:398:fopen('/etc/openvpn/easy-rsa/keys/index.txt','r') 140002835130000:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:400: root@debian-512mb-lon1-01:/etc/openvpn/easy-rsa# > keys/index.txt root@debian-512mb-lon1-01:/etc/openvpn/easy-rsa# ./build-key-server server Using configuration from /etc/openvpn/easy-rsa/openssl-1.0.0.cnf /etc/openvpn/easy-rsa/keys/serial: No such file or directory error while loading serial number 140583156987536:error:02001002:system library:fopen:No such file or directory:bss_file.c:398:fopen('/etc/openvpn/easy-rsa/keys/serial','r') 140583156987536:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:400: root@debian-512mb-lon1-01:/etc/openvpn/easy-rsa# echo 01 > keys/serial root@debian-512mb-lon1-01:/etc/openvpn/easy-rsa# ./build-key-server serverSorted.
Copying the keys/certs to the right place
root@debian-512mb-lon1-01:/etc/openvpn/easy-rsa# cp keys/{server.crt,server.key,ca.crt} ..Also going to set up HMAC
So, using the following config in server.conf
Setting up the firewall for masquerading and enabling forwarding
Restarting OpenVPN and making sure it starts at boot
Generating a client config so it can be tested
root@debian-512mb-lon1-01:/etc/openvpn/easy-rsa# . vars root@debian-512mb-lon1-01:/etc/openvpn/easy-rsa# ./build-key lan1 root@debian-512mb-lon1-01:/etc/openvpn/easy-rsa# mkdir /root/lan1 root@debian-512mb-lon1-01:/etc/openvpn/easy-rsa# cp keys/{lan1.crt,lan1.key,ca.crt} /root/lan1/ root@debian-512mb-lon1-01:/etc/openvpn/easy-rsa# cp ../ta.key /root/lan1/ root@debian-512mb-lon1-01:/etc/openvpn/easy-rsa# cat << EOM > /root/lan1/vpn.ovpn client dev tun port 1194 proto udp remote $MYIP 1194 nobind ca ca.crt cert lan1.crt key lan1.key tls-auth ta.key 1 comp-lzo persist-key persist-tun EOMTesting
root@milleniumfalcon:~/VPNS/lanbridge# openvpn vpn.ovpn ben@milleniumfalcon:~/VPNS/lanbridge$ ip route get 8.8.8.8 8.8.8.8 via 10.17.0.5 dev tun0 src 10.17.0.6 cache ben@milleniumfalcon:~/VPNS/lanbridge$ ping -c 3 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=60 time=12.7 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=60 time=12.9 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=60 time=13.1 ms --- 8.8.8.8 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002msSo the server's up and running (though I could do with adding some additional firewall rules to lock down access). For now, making sure the masquerade is restored on boot
Need to build the lan side concentrator next then.
2016-11-20 14:11:30
2016-11-20 14:11:53
2016-11-20 14:22:30
Leaving port 80 open as the intention is to have a default page up explaining that this IP is just a VPN endpoint. Plus I'll probably use it for status checks in the DNS load balancer
I've not enabled IPv6 on the droplet, and don't currently intend to, so have left ipv6 tables untouched (for now)
2016-11-20 14:22:39
2016-11-20 14:27:53
For now the balancer will only have the one entry in it. Until RR-7 is done I can't add the protocol VPN, so as "SSH" isn't in use anywhere else I'll use that for the time being
2016-11-20 14:32:46
Seems to be working
2016-11-20 14:36:18
2016-11-20 14:36:50
2016-11-20 14:53:03
2016-11-20 15:14:22
Moving config over and testing connectivity
root@vpn1:~# mv /tmp/lanbridge/ ./ root@vpn1:~/lanbridge# openvpn vpn.ovpn root@vpn1:~# ip route get 8.8.8.8 8.8.8.8 via 10.17.0.5 dev tun0 src 10.17.0.6 cacheSo, next we want to set it up as a router so it'll forward packets on
Quick test
It's more or less ready to go, though need to set up a script to make sure that VPN's restarted if it breaks. Will re-use part of this script - https://github.com/bentasker/RaspbPiVPNRoutingMgr.git (originally from https://www.bentasker.co.uk/documentation/linux/260-usurping-the-bthomehub-with-a-raspberry-pi-part-4-using-a-vpn-to-tunnel-connections-to-specific-ips )
Then running again to check it doesn't try and start a new process
Cronning it up
Should be good to go
2016-11-20 15:14:25
2016-11-20 15:14:50
2016-11-20 15:16:33
2016-11-20 15:18:52
2016-11-20 15:26:50
2016-11-20 15:38:56
Testing
Looks good so far then.
Access to the stuff VPN'd from the main router still works as well.
Next step, I guess, will be to look at configuring the transparent proxy to transit the link. That'll knock a whole lot of cleartext off what the ISP can see in one hit.
2016-11-20 15:44:11
Need to run a PCAP to check for certain, but there should now be no port 80 traffic hitting the WAN interface at all.
2016-11-20 15:44:30
2016-11-20 15:45:06
2016-11-20 15:58:59
- If TCP and dst port == 80, GW TransparentProxy
- if src == mydesktop, GW VPNConcentrator
On the DMZ interface (where the proxy lives)
- If src == TransparentProxy, GW VPNConcentrator
So port 80 connections from my desktop still hit the cache first, but everything else will be directed via the VPN.
Going to leave a PCAP running for about 15 minutes (whilst the network is fairly busy) to confirm. Did a quick speed test though, throuhput is reasonable
So that's 39 megabits. Still a bit of a drop compared to what I'm used to.
Running a quick test from the VPN concentrator itself, it looks like it's a product of going through the cache though, as I get about 50Mb/s from there (still slightly slower).
Not a big enough drop to be too inconvenient, and haven't really done anything to tune the connection speed yet, so will leave for the time being.
2016-11-20 16:12:13
But nothing outgoing despite having generated rather a lot of traffic. So that's good.
Before I can look at cutting everything over I need to create some policies so that there are exceptions
- Existing VPNs from the main router should just go straight out
- Connections from the concentrator to the endpoint obviously need to go straight out
There might be other exceptions I want to make too, but that's a starting point.
Also need to spin up a second endpoint so I can do some failover testing. That'll mean taking the endpoint down, so better to do first.
2016-11-20 16:12:29
2016-11-20 16:43:52
I've stopped openvpn on the first gateway, want to see whether it'll re-resolve and then try on the second (though the load balancer will still return both IP's as I haven't set up the status checks yet).
Doesn't seem to have done yet. There would only have been one IP when it last resolve it though, so killing the process and seeing what happens now.
Doesn't look like it does a DNS round-robin then, will need to get the status checks up and running. For now (as a test) I'll configure a status check on the load balancer for the first endpoint - should have the result of knocking it out of selection
So lets see whether the VPN switches over to trying to connect to the other.
No, y'know what, I'm an idiot. I forgot to update the config to use the DNS name. Possible round-robin does work then, will try that again shortly, will make sure the connection to ep2 works first.
2016-11-20 16:56:51
2016-11-20 17:02:07
2016-11-20 17:31:26
Creating the status check script
root@debian-512mb-lon1-01:~# apt-get install python-psutil cat << EOM > /root/status.py #!/usr/bin/env python # # # OFFLINE_FILE='/usr/share/nginx/offline.lock' import os,json,psutil response = { "status" : "Online", "loadavg" : '', "processors" : 0, "loadperc" : 0, "loadperc5" : 0, "loadperc15" : 0 } f = open('/proc/loadavg', 'r') response['loadavg']=f.read() f.close() f = open('/proc/cpuinfo', 'r') cpucount=f.read() f.close() response['processors'] = cpucount.count('processor\t') # Calculate the loadpercentage based on number of processors loads = response['loadavg'].split(' ') # Now response['loadperc'] = round(float(loads[0]) / response['processors'],2) # 5 min response['loadperc5'] = round(float(loads[1]) / response['processors'],2) # 15 min response['loadperc15'] = round(float(loads[2]) / response['processors'],2) s=0 for pid in psutil.pids(): p = psutil.Process(pid) if p.name() == "openvpn": s=1 break if s == 0: response['status'] = "Offline" if os.path.exists(OFFLINE_FILE): response['status'] = "Offline" print json.dumps(response) EOM root@debian-512mb-lon1-01:~# chmod +x /root/status.pyTesting
root@debian-512mb-lon1-01:~# /root/status.py {"status": "Online", "processors": 1, "loadperc": 0.0, "loadperc15": 0.02, "loadavg": "0.00 0.01 0.02 1/69 1500\n", "loadperc5": 0.01} root@debian-512mb-lon1-01:~# service openvpn stop root@debian-512mb-lon1-01:~# /root/status.py {"status": "Offline", "processors": 1, "loadperc": 0.0, "loadperc15": 0.02, "loadavg": "0.00 0.01 0.02 1/72 1527\n", "loadperc5": 0.01}Setting up a cronjob
Have added the status pages to the load balancer
2016-11-20 17:31:41
2016-11-20 17:39:53
Going to set a monitoring pcap running on the WAN interface, to keep size down I'll exclude the VPN traffic.
Will come back and analyse that later
2016-11-20 18:01:24
IPv6 traffic will still hit the helium tunnelled connection as I haven't quite figured out exactly how I want to address that yet - supporting failover is going to be a little more tricky unless I use NAT64 (which will probably be the only option, in truth).
Most clients on the LAN aren't given an IPv6 address, so it won't affect the majority of the traffic anyway.
Using the VPN does mean that we won't see the benefit of any ISP level caches, but it's not the end of the world.
Looking at an analysis of the capture so far, the only traffic I'm seeing is one of the existing VPNs (which doesn't use port 1194) and the Helium IPv6 tunnel. Bodes well
2016-11-20 18:01:39
2016-11-20 20:02:52
I've added a new policy to allow the iplayer box to go out without transiting the VPN, though it comes at the cost of leaking anything else I stream too.
I've a suspicion they only do the geo-location stuff when fetching the manifest though, so it might be possible to work around by setting up a reverse proxy (that'll go out without transiting the VPN) and letting the stream use the VPN.
2016-11-20 20:29:31
2016-11-20 23:47:05
- The solution supports failover.
- Responses to inbound connections do not transit the link
- Policies control what can and cannot egress the network
- Port 80 traffic still goes via the transparent proxy and then transits the VPN link
- The system fails closed
- Iplayer still works (albeit with a bit of hacking)
However, it's worth nothing that both endpoints are currently in the same datacentre, so there's no geographic redundancy. I will look at addressing that, but as it's almost trivial to spin up a new endpoint now I may wait until the government get around to defining what's classed as a CSP.
I think I'll probably raise a separate issue to track getting DNSCrypt set up as this ones getting quite large.
2016-11-27 11:34:25
Was fairly simple to set up.
I've got a routed /48 so using a /64 from that inside the tunnel. Edited the OpenVPN config to include
As the VPN is load balanced, I either need NAT or to have the LAN addresses update whenever the tunnel fails over. The former is simpler, so NAT it is
Enabling NAT and forwarding at both ends
Enable IPv6 forwarding
Added policies to direct IPv6 traffic via the VPN concentrator on the LAN. Job done
2017-07-06 10:14:17
2017-07-06 10:14:17
2017-07-06 10:14:17
2017-07-06 10:14:20
2019-03-27 10:10:43
2019-03-27 10:10:43
2019-03-27 10:11:05
2019-03-27 10:11:05
2019-03-27 10:11:08
2019-04-26 12:26:00
2019-04-26 12:26:00
2019-04-26 12:50:57
2019-04-26 12:50:57
2019-04-26 12:51:01
2019-12-10 15:40:21
2019-12-10 15:40:21
2019-12-10 15:50:15
2019-12-10 15:50:15
2019-12-10 15:50:19