From: "Marcos Rubinstein - ALPA WWW" <[EMAIL PROTECTED]> > > .- 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 ------------------------- The freeVSD Support List -------------------------- Subscribe: mailto:[EMAIL PROTECTED]?body=subscribe%20freevsd-support Unsubscribe: mailto:[EMAIL PROTECTED]?body=unsubscribe%20freevsd-support Archives: http://freevsd.org/support/mail-archives/freevsd-support -----------------------------------------------------------------------------
