Show HN: Wag, MFA and Enrollment for WireGuard

Show HN: Wag, MFA and Enrollment for WireGuard(github.com)

149 points by Nullence 2 years ago | 58 comments

Howdy folk,

I've been building this project as both a side project and my job for a little while now. The rationale behind it is while wireguard is a fantastic protocol cryptographically it leaves a lot to be desired when it comes to enrollment and end user device security.

Obviously instead of using an off the shelf solution like tailscale, I decided to reinvent the wheel which has honestly been quite fun with learning about eBPF, and recently clustering and HA with etcd!

The most recent version (in the docker container) contains about 6 months of very new work bringing it all from sqlite3 to etcd. So please be forgiving if it does some weird things!

Hope you all enjoy!

P.s Im not a web developer and any tips on that front to make it less teeth pullingly awful are welcome!

ta1243 2 years ago |

This looks nice, but a couple of things

> curl http://public.server.address:8080/register_device?key=e83253...

> The service will return a fully templated response

It looks like the "registration" involves the server generating a private key then sending to the client, rather than the client generating a private key and sending the public key to the server.

Not only that but your example is http! Probably worth replacing that part at least in case people think http is a reasonable option.

> To authenticate the user should browse to the servers vpn address, in the example, case 192.168.1.1:8080, where they will be prompted for their 2fa code.

So when the session times out, is there any way for the client to realise this? Or does their ssh session (or whatever) just stop working?

I've on and off looked for a wireguard client which can do something like the captive portal detection on wifi. Ideally it would be an extra line in the config file (like persistentkeepalive), which does a URL pull. Could be checked periodically (like with the keepalive). If it returns "OK", then fine, if it doesn't return then there's a network problem, but if it returns a "Location" header, the client would pop up a browser at that location, allowing for session reauthentication or whatever.

I haven't found one.

Nullence 2 years ago | |

Howdy! Kind of forgot that I put this up, the registration url can also take an optional pubkey parameter, so you dont have to rely on the server generating the private key for you (docs are a little lacking so I understand the confusion!)

To answer your last question, eBPF XDP which is what I use can only do PASS, DROP or REDIRECT. So I stick with the easiest possible outcome and do PASS/DROP, which means your connections will just stop working.

However you can always set up the detection yourself by adding the captive portal detection pages to your wag MFA list then the browser should do everything else for you.

Unfortunately doing interception or acting like a proxy isnt something Im looking to do with wag (which makes authorisation timeout/logout a bit easier to deal with)

Hope that answers things!

ta1243 2 years ago | | |

The problem I've seen when I've looked at this is signalling to the user that the session has ended. Sure your EBF filter stops passing traffic, but the user as to know that they need to visit a page to reauthenticate

That requires integration with a client, which is a massive pain to integrate

20after4 2 years ago | |

> I've on and off looked for a wireguard client which can do something like the captive portal detection on wifi. Ideally it would be an extra line in the config file (like persistentkeepalive), which does a URL pull. Could be checked periodically (like with the keepalive). If it returns "OK", then fine, if it doesn't return then there's a network problem, but if it returns a "Location" header, the client would pop up a browser at that location, allowing for session reauthentication or whatever.

That would be really cool. I hope the author of this will consider it.

Nullence 2 years ago | | |

Ironically I've also been thinking about this on and off for a bit, as it is definitely one of the pain points of using Wag at the moment.

My only problem is that if you capture that route and then redirect it, or whatnot, your peers wont be able to log in to wifi in public areas like coffee-shops/libraries/etc because the route will be trying to go via a VPN which wont be returning any real data.

Such as where you should be going to log in haha

blipvert 2 years ago | |

I have written a similar server (per-device client cert required which gets you mTLS to a logon page which uses OIDC the authenticate the user and enable the tunnel) but the client is the tricky bit.

I have written one in Go for the Mac which uses the command line wg from Brew and handles key gen, but it is clunky and requires sudo.

A proper native app which uses the network entitlements would be great, but it is beyond my ken

asimops 2 years ago |

Have you tackled the issue of session management or are you planning to do so? Essentially wireguard key are just eternal session keys.

I would expect software that implements the wireguard transport layer to implement session management to be called a working VPN server solution. This means a second channel to the server for periodically rotating session keys, terminating sessions, changing IP addresses, configuring new routes and repeating authentication if necessary.

d-z-m 2 years ago |

Do you protect against bruteforcing the TOTP code? I.e. via rate-limiting or a set amount of retries? I took a quick glance at the code and couldn't find anything to this effect.

The scenario I'm imagining is: someone opens the TOTP entry UI in their browser, opens devtools, and starts to loop through all possible TOTP codes.

Nullence 2 years ago | |

Yep! I do indeed have protections against bruteforcing TOTP codes, effectively each authentication has a number of "attempts" a user can make before their account gets locked, and an admin is then required to unlock it.

Specifically to force people to have a bit of a think as to why their device is trying to force auth to begin with, as it indicates an endpoint compromise.

8organicbits 2 years ago | |

I think thats here:

https://github.com/NHAS/wag/blob/cdbdbec3393fa86bf6c823117c8...

Avicebron 2 years ago | |

I can't speak to the specifics of this particular implementation but usually if someone has the login (username + password) to get to totp that user has already been compromised..

asimops 2 years ago | | |

But MFA is there to prevent this compromise from affecting the service and alert users/admins to the compromise, right?

If you have username and password and are able to force the TOTP in the 60s window, the TOTP would be useless imho.

yonatan8070 2 years ago | | |

If a user keeps their credentials in a notebook and it got stolen, the TOTP check can be the difference between the attacker getting in, and the user being notified and changing their password

Nullence 2 years ago | | |

Oh wag doesnt use username and password auth by default. Those are only available in the OIDC integration or if you use PAM auth.

hnarn 2 years ago |

This sounds very similar to Head- or Tailscale, nice to see some alternatives to managing wireguard networks. Is there a comparison anywhere to understand what functionality overlaps, what is added, what differs and what will perhaps never be implemented?

Nullence 2 years ago | |

Similar in terms of it uses wireguard definitely! I havent made a direct comparison in the documentation as it's not something I'm currently going toward. This project suits my needs and is quite fun!

But I'll try and give a basic run down on the differences/similarities.

Wag is good for hub and spoke design where you want to have a hard boundary, rather than a tailscale-esque mesh where everything touches everything and then the rules define the overlay.

Both wag and tailscale add SSO integrations and effectively 2FA for securing your users.

And both of us have a way to enroll and a web UI to manage things, although I'm sure TailScale is much more polished considering I'm one guy who doesnt like web development.

As for things Im definitely not going to implement, probably interception or a TLS proxy to redirect users once their session logs out. Primarily just because doing that in eBPF is a little bit beyond me right at this second, and I dont feel like writing the DNAT/SNAT components I'd probably have to in order to get it working

mahkoh 2 years ago |

>IPv4 only.

You'd think that sites choosing wireguard would have a more modern setup and might make heavy use of (self service) ULAs.

Nullence 2 years ago | |

I do plan on supporting IPv6 sometime soon, and doing something along the lines of mapping folks IPv4 addresses into private IPv6 space to reduce the risk of clashing with a users real local network.

Is there something specific you were thinking about when you mention ULAs?

tptacek 2 years ago | |

What are the ULA wins you're thinking of here?