Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Need a working VPN for public WIFI
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
LIsLinuxIsSogood
Veteran
Veteran


Joined: 13 Feb 2016
Posts: 1179

PostPosted: Fri Dec 08, 2017 9:42 pm    Post subject: Need a working VPN for public WIFI Reply with quote

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.
Back to top
View user's profile Send private message
szatox
Advocate
Advocate


Joined: 27 Aug 2013
Posts: 3134

PostPosted: Fri Dec 08, 2017 9:56 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

PostPosted: Sat Dec 09, 2017 1:53 pm    Post subject: Re: Need a working VPN for public WIFI Reply with quote

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).

/etc/conf.d/net:
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

/etc/dnscrypt-proxy.conf:
LocalAddress 127.0.0.2:53

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

/etc/unbound/unbound.conf:
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:

Code:
# 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:

Code:
# 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'

/etc/dnscrypt-proxy.conf:
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
Back to top
View user's profile Send private message
LIsLinuxIsSogood
Veteran
Veteran


Joined: 13 Feb 2016
Posts: 1179

PostPosted: Sun Dec 10, 2017 12:40 am    Post subject: Reply with quote

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)
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54234
Location: 56N 3W

PostPosted: Sun Dec 10, 2017 12:34 pm    Post subject: Reply with quote

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.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

PostPosted: Sun Dec 10, 2017 1:30 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 21624

PostPosted: Sun Dec 10, 2017 7:47 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
LIsLinuxIsSogood
Veteran
Veteran


Joined: 13 Feb 2016
Posts: 1179

PostPosted: Mon Dec 11, 2017 10:14 am    Post subject: Reply with quote

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 :)

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
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54234
Location: 56N 3W

PostPosted: Mon Dec 11, 2017 11:19 am    Post subject: Reply with quote

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.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 21624

PostPosted: Tue Dec 12, 2017 3:40 am    Post subject: Reply with quote

I learned iptables direct from its manual pages. I don't know of any tutorials for it that I can recommend.
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

PostPosted: Wed Dec 13, 2017 4:05 pm    Post subject: Reply with quote

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:

/etc/unbound/unbound.conf:
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:

/etc/conf.d/net:
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:

/etc/sanewall/sanewall.conf:
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
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum