[Openvds-devel] Re: ow to DISABLE vm-pop3 in virtual server???

[Simon Garner]

From: "Marcos Rubinstein - ALPA WWW" <address@hidden>
>
> .- use xinetd instead of inetd, and define the service to be
> used for each ip. You could even have xinetd running in each
> virtual!.- the same warning that before... applies.
>


I suggest that for future versions of freeVSD and OpenVDS it should be
changed so that (for RH7 with xinetd at least) each VS gets its own service
file in /etc/xinetd.d, and instead of using virtuald we bind each service to
its own IP using xinetd itself (with the bind_address directive).

The advantages of this are twofold:

1) You can enable and disable inet services on a per-VS basis (in
particular, this lets you disable services like FTP and POP on the host
server).

2) Each service will be tracked separately by xinetd. Note that if a service
receives too many connections per minute (?), xinetd will disable that
service for 30 seconds. With the current configuration, this means that, for
example, if a user with a download accelerator like DAP starts hammering the
FTP service on *one* VS with a load of failed connections (e.g. if you have
ProFTPD set to only allow 2 connections from each host), then FTP service
could be disabled on *all* your VS's for 30 seconds!

Giving each VS its own FTP service in xinetd resolves this issue, as each VS
will be treated separately. Making this change should just require some
small additions and modifications to config_vs() in vsd-vsbatch.pl.

I expect this issue could also be fixed by modifying the connection rate
limit in the xinetd configuration, but a) if you increase the rate limit you
are still lumping all the VS's together and risking the problem occurring,
and b) if you disable the rate limit entirely then you risk having real DoS
attacks not being blocked.

Also, I would caution against running a separate copy of xinetd inside the
VS because: a) unless you let admin have write access to xinetd.conf then
there is no point in it. You're just creating an extra process for each VS,
which increases memory usage on the host server and so should be avoided,
and b) if you let admin have write access to xinetd.conf then you just
opened a gaping security hole, since xinetd runs as root. It would be
trivial to set up a inet service running as root, giving the admin user full
superuser access.

Cheers,

Simon