On Thu, Jan 05, 2006 at 07:27:02PM +0100, Wild Karl-Heinz wrote:
> Hello all.
>
> I've asked a month ago if it's possible to tag an incoming connection
> and keep the tag also after redirect to an other device with pf. The
> answer was no.
>
> I thought about a way to restrict an openvpn connection based on the ip
> the connection was initiated.
>
> Now I found a way I would like to show.
> I hope it's not wasted bandwidth.
>
> OpenVPN produce a status file like the following
> ----------------------------------------------------
> 10.8.0.6,test.brandwand.domain,12.12.12.12:62140,Thu Jan 5 17:45:20 2006
> 10.8.0.14,world.brandwand.domain,11.11.11.11:60646,Thu Jan 5 17:05:48 2006
> ----------------------------------------------------
>
> I read this file with a little script and set an anchor for every
> connection. After setting the active connections there should also
> be a step to reset or flush anchors they are no longer exists.
> The script isn't finish, it'll be the next time.
>
> You need in pf.conf with an anchor like
> anchor "openvpn/*"
>
> If there are any comments, they are welcome.
(Sorry for the long post. I tried to keep most irrelevant details out,
or at worst in the [footnotes], but it's still a rather long story for a
rather simple idea...)
This is a rather bad idea, even not considering the fact that the status
file may change formats without notice.
Let us postulate a priviliged user priv.example.com and an attacker
badguy.example.com.
Let us further postulate that the attacker has either managed to get
control of a lot of hosts and the certificates belonging to them, *or*
the --duplicate-cn option is enabled, *or* the OpenVPN server has a
somewhat larger number of users[1].
Now, suppose priv.example.com logs off, either of his/her own volition
or through some sort of attack[2].
Suppose badguy.example.com logs on shortly thereafter, and is assigned
the same address as priv.example.com held. Of course, access will
eventually be curtailed - but even five minutes is quite a bit of time.
Especially since it should be possible to get these five minutes several
times, especially when able to disconnect priv.example.com pretty much
at will, and faced with a typical (Windows) user who will just try again
when something unexpectedly fails.
This is not always possible, see the second assumption, but since the
OpenVPN manpage clearly states not to rely on --ifconfig-pool-persist
granting static IPs, I do not think this is a terribly good idea. And
please note that I do not say that it is not possible if the second
assumption has not been fulfilled.
The proper way to do this is to pick two subnets; reserve one for
dynamic allocation, and use the other for static addresses. You can
assign static addresses via --client-connect-script and
--client-config-dir; the latter is by far the easier in a chroot setup,
as you should be using (OpenVPN has had a few security problems[3]; not
that much, considering the complexity, but enough to merit running it
with as little priviliges as is at all possible).
I have this set up as:
/etc/openvpn.conf:
server 192.168.9.0 255.255.255.0
client-config-dir /var/openvpn-config
route 192.168.8.0 255.255.255.0
#route 192.168.7.0 255.255.255.0
/var/openvpn-config/priv.example.com:
ifconfig-push 192.168.8.1 255.255.255.0
#iroute 192.168.7.0 255.255.255.0
Be aware, however, that such a setup will cause strange-looking routing
tables. Especially if you uncomment the commented routing commands -
they will route 192.168.7.0 through priv.example.com.
Now, you can use pf to allow the hosts in 192.168.8.0/24 elevated
access, and those in 192.168.9.0/24 normal access. Works for me[4].
I did not check your implementation, so I cannot comment on that.
Joachim
[1] If --ifconfig-pool-linear is not given, the maximum is no higher
than 256/4 = 64 hosts for a /24 subnet (as Windows hosts require four
IPs in this implementation); if it is, the maximum is no higher than
255, and you'll probably have an angry mob on your doorstep soon.
(The maximum may be lower, since the server itself consumes some IP
space; also, I hope the broadcast address is not given out; and .0 seems
not be given out, either.)
[2] Look up 'Fernando Gont' and some combination of 'full-disclosure',
'icmp' and 'dos' for one possible attack - OpenBSD is (no longer)
vulnerable, but priv.example.com need not be running OpenBSD.
Alternatively, skip all the discussions and go straight to
http://www.gont.com.ar/drafts/icmp-attacks-against-tcp.html.
(This is an attack against TCP, by the way, and OpenVPN uses UDP by
default, so this is not applicable in all/many cases.)
[3] See any vulnerability database, for instance
http://search.securityfocus.com/swsearch?sbm=%2F&metaname=alldoc&query=openvpn.
(URL may break in replies, it's one long line...)
[4] IPs and paths have been changed on account of sheer, rampaging
paranoia; 'works for me' gives no guarantee of actually working for me,
let alone for you; always read the man page before implementing.
