search

agdsn / hades

AG DSN Authentication and Authorization Infrastructure
MIT License
8 stars 3 forks source link

DNS/IP based whitelisting #20

Closed fgrsnau closed 8 years ago

fgrsnau commented 8 years ago

Another early PR. The changes are (obviously) not ready yet.

Planned changes:

Discussion is welcome…

sebschrader commented 8 years ago

This should be rebased after #24 is merged as well, right?

fgrsnau commented 8 years ago

Two problems so far:

The 2nd one is not too hard to solve. For the 1st we could use some agent which updates the routing table from time to time (probably hard to get right). I would prefer a more straight forward solution…

EDIT: I’m wrong with point 2. Extract from the manual:

The special server address '#' means, "use the standard servers", so --server=/google.com/1.2.3.4 --server=/www.google.com/# will send queries for .google.com to 1.2.3.4, except www.google.com which will be forwarded as usual.

fgrsnau commented 8 years ago

Another problem: dnsmasq always matches all subdomains.

It is not possible to allow www.agdsn.de and agdsn.de without allowing ftp.agdsn.de to resolve. Note that it is possible to allow www.agdsn.de (+ all subdomains) and disallow *.agdsn.de (incl. agdsn.de).

For the record, the following configuration works somehow (the root of the domain, agdsn.de, will still not be resolved correctly).

address=/#/$REDIRECT
address=/agdsn.de/$REDIRECT
server=/www.agdsn.de/#

I played with prepending dots and stuff (.agdsn.de) but this doesn’t seem to have any semantics here. The manual does not consider this to be worth talking about…

fgrsnau commented 8 years ago

I’m not super happy with the routing table solution, but it works.

Missing bits:

fgrsnau commented 8 years ago

Not allowing agdsn.de to be resolved is not the best idea.

http://www.agdsn.de redirects to https://agsdn.de which gets DNATed to hades and we get a nice certificate error. Entering https://www.agdsn.de works.

If we want to whitelist exeternal sites (university’s website/webmail) we should make this more robust.

sebschrader commented 8 years ago

If the whitelisted IP lies inside of a network of the unauth interface routing fails. This is the case for www.agdsn.de. Adding entries to routing table (ip route add $IP via $DEFAULT_GW) solves the issues, but this cannot be done easily for all addresses of a ipset.

Then we have to change that. Having our own services in the user networks is a legacy thing anyway.

sebschrader commented 8 years ago

It should be fine, to allow all of agdsn.de including the subdomains.

Of course, it would be a lot nicer, if we could whitelist only a single domain.

sebschrader commented 8 years ago

As far as I can see, we probably don't need the reverse proxy feature, right now.

The only advantage of a reverse proxy in contrast to whitelisting would be, that the original IP of the unauthenticated user would be preserved in the X-Forwarded-For header and SIPA could therefore detect the user.

This would however only be an advantage for users that are moved from auth state to unauth state, as they would retain their public IP for a little while (until their lease is renewed). All other unauth users would get an IP from the unauth DHCP range.

fgrsnau commented 8 years ago

I don’t worry about agdsn.de so much. But let’s say we would like to whitelist www.tu-dresden.de and tu-dresden.de. This would allow access to login and vpn servers. Of course, there are countermeasures but no generic ones.

sebschrader commented 8 years ago

I agree with you, but we can live with this limitation for now. We don't have to whitelist these other domains until we have working solution for this issue.

fgrsnau commented 8 years ago

I consider this ready for merging now. We tested this yesterday successfully. I just want to wait for your approval.

Please note that I dropped the last change and this PR does not include the routing table hack anymore (necessary for Sipa at the moment).