# Need a working VPN for public WIFI

## LIsLinuxIsSogood

What possible solutions are there for a working security implementation that covers me from the traditional or otherwise types of attacks that can happen on public wifi networks?

I do a lot of my work from these places (i.e. coffee shops, and libraries) so I was previously not concerned because I didn't think the threat was present for others to want to hack the information on my laptop.  I've reconsidered.

In case it helps to have my intended security consequences for protection these are the ones I am most concerned about:

1) Security from malware and destructive access to my system

2) Also ease of use and I want something that works out of the box and works all the time (something that doesn't have as many "gaps" or holes in terms of protection)

3) Cheap solution shouldn't cost more than a few dollars to implement (per month or whatever).,,but if it works much better than I will consider bending the amount upwards to between $0-10 monthly.

I currently use a way of hiding my IP but I don't think that is the same as the type of VPN I need for security among other hosts on a network.  Please will someone point me in the right direction for the easy to follow instructions. Thanks.

----------

## szatox

 *Quote:*   

>  1) Security from malware and destructive access to my system 

 No VPN can protect you from this. You must always be connected to some local network to maintain the tunnel.

What you can do is as simple as it is effective though: Just don't expose services to the network. It's damn hard to attack a machine which does not listen to you.

As long as the security of your local machine is your primary concern, you want to focus on _not_ giving any control to the network. This is not a task for a VPN.

----------

## khayyam

 *LIsLinuxIsSogood wrote:*   

> What possible solutions are there for a working security implementation that covers me from the traditional or otherwise types of attacks that can happen on public wifi networks?

 

LIsLinuxIsSogood ... the primary exposure in such environments would be MiTM ("man in the middle") attacks, and/or DNS poisoning (often for the purposes of MiTM). If your client is resolving DNS via the servers provided via DHCP then you are trusting that this server is providing valid DNS resolution ... given the client does no validation on such things. A more robust approach to DNS resolution is to use dnscrypt, which involves SSL for communication between the client and resolver.

A dnscrypt client (net-dns/dnscrypt-proxy) in conjuction with a DNS cache (net-dns/unbound) can be configured like so:

First you must make sure that no DNS is requested from the DHCP server, and provide a dns server address for '/etc/resolv.conf', in this case 127.0.0.1 localhost (the address unbound is listening on).

```
dhcp_wlan0="nodns"

dns_servers_wlan0="127.0.0.1"

dns_options_wlan0="edns0"
```

dnscrypt-proxy is then configured to listen on 127.0.0.2

```
LocalAddress 127.0.0.2:53
```

... and unbound is configured to forward requests to dnscrypt-proxy

```
forward-zone:

    name: "."

    forward-addr: 127.0.0.2@53
```

Once configured, and unbound/dnscript-proxy started, you should be able to see the following:

```
# cat /etc/resolv.conf

# Generated by net-scripts for interface wlan0

nameserver 127.0.0.1

options edns0

# netstat -tulpn

Active Internet connections (only servers)

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name

tcp        0      0 127.0.0.2:53            0.0.0.0:*               LISTEN      22924/dnscrypt-prox

udp        0      0 127.0.0.2:53            0.0.0.0:*                           22924/dnscrypt-prox

udp        0      0 127.0.0.1:53            0.0.0.0:*                           22908/unbound

udp        0      0 0.0.0.0:49929           0.0.0.0:*                           22924/dnscrypt-prox
```

By default dnscrypt-proxy is configured to us a "random" resolver ("that doesn't log and supports DNSSEC") and so you should be able to check you are resolving, and additionally using DNSSEC, with one of the following:

```
# dig com. SOA +dnssec

# dig gov. +dnssec +adflag NS @127.0.0.2
```

You should see "status: NOERROR" in the output.

You will probably want to change "random" to a resolver in your geo-location (see: /usr/share/dnscrypt-proxy/dnscrypt-resolvers.csv for available resolvers) replace "random" with, eg, 'cs-uk'

```
ResolverName cs-uk
```

I think unbound should work out of the box for such a setup though I'm not sure if any specific configuration is required for DNSSEC, ie root-anchors, (I may have done some configuration when initially setting this up, I can't be sure). I expect DNSSEC to work, if not, then you may need to dig a little deeper into /etc/unbound/unbound.conf. Whatever the case, dnscrypt should function without DNSSEC.

The other obvious thing to consider in such environments is to be using SSL/TLS for browsing, and/or when authenticating.

HTH & best ... khay

----------

## LIsLinuxIsSogood

Thanks khay, this was exactly what I was looking to know more about.  I will read your description of the DNS crypt solution carefully and give it a hack before trying back with more scenarios (for the MiTM attack sit'ns that could be of great enough concern to do something against and defend)

----------

## NeddySeagoon

LIsLinuxIsSogood,

None of this says that you do not need a VPN too.

Public wifi tends to have all users sharing the same WiFi key.  That mean all users can see all wifi traffic.

That's a verybadthing.  A VPN provides a secure tunnel over the shared Wifi. Thats all.

You need to trust the other end of the VPN tunnel, since they decrypt your traffic and forward it.

See for yourself, try wireshark when you are out and about - don't get caught though.

Provided you always use end to end encryption anyway and you are 100% sure of that, a VPN adds nothing.

The measures khayyam suggested are good on their own.

After all, a layer of encryption you don't need is just extra overhead.  It all depends on your paranoia level.

----------

## khayyam

 *NeddySeagoon wrote:*   

> Provided you always use end to end encryption anyway and you are 100% sure of that, a VPN adds nothing.

 

NeddySeagoon ... well, it could allow you to access services that are restricted via geolocation (such as BBC iPlayer, etc), but otherwise it doesn't provide anything that couldn't be similarly secured via TLS/SSL ... and services requiring authentication (mail, etc) should be doing so regardless of what kind of link you are using. In my case (which is access within various libraries) I'm fairly ok with trusting dnscrypt, HTTPS Everywhere, net-mail/offlineimap, and ssh, as mostly what I'm doing requires web & mail. I have in the past setup "poor man's VPN" using net-proxy/sshuttle but nolonger have something local, and that I admin, that I can use for such a purpose, and so make do with the above.

best ... khay

----------

## Hu

To elaborate a bit on khayyam's comment about HTTPS Everywhere, if you choose not to use a VPN, but you are concerned about your content being accessible to other Wifi users, you should establish active measures to inhibit non-encrypted traffic.  For browsers, HTTPS Everywhere can be a good choice.  You could also use iptables to ban outbound connections on ports associated with non-secure protocols.  That way, you get a hard failure (and optionally an audit message) if something tries to use an insecure connection, even if no other user attacks or intercepts it.

----------

## LIsLinuxIsSogood

Ok, I think I will use a bit of everyone's advice.  Specifically though, Hu because I haven't used iptables would there be a good tutorial on the way to use it as you are suggesting to.  The DNS MiTM attack idea seems very advanced, and it will probably be a good way to start down a path that will just maybe need to be a job that is patched together by these several tools.  That much I think I sort of knew ahead of time, although I was hoping in this case for some solution (magic maybe)  that would work out of the box similar to the way some of the basic PC components work out of the box, but this time for Security.  Like a chastity belt for my computer.  JK  :Smile: 

MiTM/DNS

HTTPS Everywhere

iptables

Does this seem like a fairly good list to start off with in terms of the public wifi issue?

EDIT: Oh an I forgot to mention Wireshark too, maybe or else a VPN, ha ha ha

----------

## NeddySeagoon

LIsLinuxIsSogood,

I gave up on using iptables directly.  It made my head hurt but I have a four interface network.

I use shorewall to set up iptables. 

Its like the difference in writing hex (iptables) or assembler (shorewall) to program your PC.

There are other pretty iptables rule compilers too.

Don't forget that you need separate firewalls for IPv4 and IPv6.  There is no point is locking down IPv4 and leaving IPv6 wide open.

You can turn off IPv6 in the kernel if you want to.  That's simpler and just as effective.

I'm just careful with my netbook. I'll follow khayyams advice there too.

----------

## Hu

I learned iptables direct from its manual pages.  I don't know of any tutorials for it that I can recommend.

----------

## khayyam

 *NeddySeagoon wrote:*   

> I'm just careful with my netbook. I'll follow khayyams advice there too.

 

NeddySeagoon ... a quick search shows that, along with the above, you also need the following:

```
do-not-query-localhost: no
```

I don't think this is enabled by default, so you would need to uncomment it. If you run into problems just ask.

@LIsLinuxIsSogood ... as far as iptables is concerned then you can take the simple route with something like net-firewall/sanewall:

```
rc_net_wlan0_need="firewall"

rc_sanewall_provides="firewalld"
```

By default the ruleset is DROP for the input chain (see: /etc/sanewall/sanewall.conf), if you wanted you could also drop outgoing traffic on http/80 (as Hu suggests above) by adding the following:

```
interface any world

protection strong

client http drop

client all accept
```

... or something more fine grained if you want both ingress and egress filtering.

If you then wanted to see what the current ruleset looks like (from an 'iptables' perspective) then 'iptables-save' should give you some idea.

best ... khay

----------

