-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/03/12 13:15, Carsten Krüger wrote:
> Hello David,
>
>> a) Mounting and un-mounting networked filesystems after the tunnel
>> is up. Here I even implemented the --route-pre-down script hook, to
>> unmount the filesystem before the tunnel is taken down. Here's the
>> config extract:
>
> This need root rights?
Not necessarily, if /etc/fstab is configured with 'user' you don't need
root priv. Or if you use FUSE stuff, that often don't need root access
either. Of course, it all depends on what kind of file system you mount.
>> This client has a web server behind it which is available on the
>> public internet via the openvpn server which got the public IP
>> address. To make sure the incoming public traffic is returned via
>> the VPN tunnel and not the default gateway on the openvpn client,
>> simple ip rules like the ones below are used in the route-up.sh
>
>> /sbin/ip rule add from ${ifconfig_local} table 132 /sbin/ip route
>> add default via 10.8.0.1 table 132
>
>> And the route-down.sh takes care of deleting the rule. This is to
>> avoid errors and duplications if openvpn is restarted. (And there
>> are probably other ways to solve this as well, but this is one way)
>
> Need root rights, too?
This case needs root access, correct. But this can be tweaked around
using sudo trikcs or similar stuff. And using SELinux, you can also lock
down things even more.
> Maybe it's a good idea to have two type of scripts. One that is
> controlled from the administrator and is executed with admin/root
> privileges and the other that runs as the user.
>
>> Plugins can be used on both server side and client side. They can
>> be used to extend the logging, or do other more advanced things
>> which is easier and cleaner solved in a C program than using plenty
>> of scripts.
>
> In an enterprise setup I would think a plugin should be not modifable
> by the user (i.e. the user should have no chance to load own
> modules).
Well, I can agree to that. But this is all open source. No matter how
much restrictions you put into the openvpn product, the user can download
the source, add the features missing, and reconnect with a modified
OpenVPN version.
Even introducing signatures and hashes which the server evaluates will
not solve this, as the openvpn client can be modified to return exactly
the data the server would expect.
To avoid this, you would need to run some code from the server - which
evaluates the system and reports back to the server. Then the server can
decide to open up the firewall on the server side or not. Otherwise, you
have no way to trust the client side at all. And all this would have to
be code which is not easily available, so the client can't fake this
operation as well.
Bottom line is, you can't fully control the client environment. All
enforcements needs to happen on the server side.
What you can do on the client side, is to avoid a third party (think
virus/malware) to figure out that openvpn is installed, and tweak the
config to run code which was not supposed to be run with higher
privileges. So the client should try to lock down things locally, to
reduce the impact from local exploits. The server side should restrict
the server side, and what is being passed via the tunnel. There's no
real way you can make the server enforce restrictions on the client.
kind regards,
David Sommerseth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk9PbIIACgkQDC186MBRfrp7GgCdE9FyhidxVP+xYDzZhvbBw6w1
ps0AmwRBWDSHk2MILKfUlrYr5OcuAkbY
=2DnA
-----END PGP SIGNATURE-----
