Re: [SC-L] virtual server - security

2004-04-01 Thread James Walden
Along the same lines as the suggestion to use VMware, have you thought 
about User Mode Linux?  User Mode Linux lets you run virtual Linux 
machines on your existing Linux system.  If you have enough memory, you 
could give each of your user groups their own virtual Linux machine with 
its own filesystem and virtual hardware, offering much greater isolation 
than chroot.  Each could also run their own version of 
Apache/mod_perl/PHP, fulfilling potentially different security 
requirements.  Compromise of one virtual machine wouldn't compromise the 
others or the real box that they're running on.

James Walden, Ph.D.
Visiting Assistant Professor of EECS
The University of Toledo @ LCCC

Re: [SC-L] virtual server - security

2004-03-31 Thread Fernando Schapachnik
Working for an ISP in a previous life we used FreeBSD jails. There are
kind-of-similar solutions for linux also (there's actually people in the list
who sell them even).

Good luck.

En un mensaje anterior, Serban Gh. Ghita escribió:
 I am banging my head on the table every day, because i cannot find an
 elegant and safe solution to secure a virtual shared environment (server).
 Take the following facts:

Re: [SC-L] virtual server - security

2004-03-31 Thread Louis Solomon [SteelBytes]
I am banging my head on the table every day, because i cannot find an
elegant and safe solution to secure a virtual shared environment (server).
Take the following facts:
-you have a virtual server (unix) and you have to take care of a lot of
maybe something like plesk may be useful
PS.  don't bother to flame me if you disagree, I am not a unix guru

Louis Solomon 

RE: [SC-L] virtual server - security

2004-03-31 Thread Dave Paris
a few notes..

 -Original Message-
 From: jnf [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, March 31, 2004 11:23 AM
 To: Dave Paris
 Cc: Serban Gh. Ghita; [EMAIL PROTECTED]
 Subject: RE: [SC-L] virtual server - security
  What's the point of the exercise if you're passing plaintext passwords
  across on port 21?  At the very least, mandate SCP/SFTP on port 22.

 yes because having a remote exploit every month or two for
 root^H^H^HSecure shell is much better than limiting it to sniffing on the
 lan, or even better than using one of the ssl type wrappers for telnet.

Sniffing on the LAN isn't my main concern, it's the concentration points
inbetween A and B.  Good idea on the SSL wrapper on Telnet, although the
original poster said they doesn't want to offer shell access.  I'm not quite
sure the security community's concensus would agree that FTP is better than
SCP/SFTP.  I certainly don't, but I've already made that point.  So that
leaves us with flaws in implementation *and* plaintext usernames/passwords.
That doesn't give me warm fuzzies.

  use 'chroot' jails

 and look into kernel patches like grsec that take some of the damn
 stupidity out of the standard chroot system call. You perhaps may want to
 look into where you might be able to use read only filesystems in your
 setup, while breaking out of a (good) chroot jail on a read only
 is not impossible- it could make life hell for quite a few.

Good call.  Perhaps better would be using SELinux as a base, although the
learning curve is one heckuvalot steeper.

  PHP and run safely in the same sentence?  Have you perused Bugtraq

 have you ever noticied that a good 80-90% of those posts are cross site
 scripting holes or sql injections that are the result of shoddy
 programming (web developers bad programmers as a whole? nooo never.)
 And less often language specific. As to answer the poster's question, I'm
 not sure if suexec works with php, i dont think it does, but you might
 want to look into that or see if you can find something similar.

  That's primarily because PHP will let you shoot yourself in the head, as
  opposed to most languages which will only let you shoot yourself in the
  foot, or at least no higher than the knee.  (snide
 commentary... unless it's
  a microsoft product, which seem to aim squarely for the jewels)

 yea I'd describe a stack or heap based overflow to be shooting
 yourself in
 the foot.

Assuming your foot is squarely between your thighs or in front of your
nose.. ;-)  My comments were based on the nature of the poster's message,
which seemed to allow scripted/interpreted languages rather than compiled
executables, given the lack of shell access.  (that's not to say that a user
can't upload a binary, but if a non-x86 arch is chosen as a base for the
deployment, things get tougher for a user to screw up by default... save for
misconfigurations of the host, of course)

  Yes.  Near daily bugtraq reports about why PHP is a darned good
 idea that
  made a left turn into a really bad neighborhood.  The manpage for
  SCP/SFTP/SSH.  The manpage for 'chroot'.

 I will agree that php could be more secure, although i must admit
 its come
 a hell of a long ways since its first introduction, there are plenty of
 articles over php security on google- I'm sure your local bookstore will
 have books that will at least cover the subject to some degree. Just like
 any language php will let you screw yourself- most of what you find on
 bugtraq as I said are not language problems, but programmer problems. A
 quick google search will show nearly as many exploits (if not more) for
 [open]ssh as for wuftp, yet wu is considered horribly insecure and ssh
 secure, go figure. I'd also look into chroot as suggested, I am unsure of
 whether it is avail. to php programs, it might be- and you might consider
 figuring a way to wrap all php scripts executed in chroot, although if it
 is anything like perl, chroot'ing it will be a major pain in the ass.
 In short, screw bugtraq- goto google or your book store, or even -
 they are all bound to have tons of information about what you are looking

It's not the poster who's writing the PHP, it's the users.  Unless the users
are sufficiently clued into the existing issues, the view doesn't change.
My comments regarding PHP are centered around most of the default
configuration issues that too many web programmers (for very loose values
of the word programmer) won't mitigate or fail to mitigate at any rate.
While all of the flaws stated can be reproduced in any language, PHP makes
it _relatively_ easy for the flaws to remain, or to be coded in.

Rather than going to specific distributions, I ran a slightly different
google queries...

Google results:
search terms:  exploit SCP  results:   9,810
search terms:  exploit SFTP results:   3,300
search terms:  exploit SSH  results:  71,900
search terms:  exploit FTP  results: 285,000

What does this mean?  Not much

Re: [SC-L] virtual server - security

2004-03-30 Thread Scott Nemec
Have you looked at VMware?  ( )

It let's you provide an environment at the hardware-like level inside a
real box.  This way, if the the script kiddie get's control of your
virtual environment, you can just reset back to a pre-saved state.
Meanwhile, the real box is protected from the virtual (at least should

On Tue, 30 Mar 2004, Serban Gh. Ghita wrote:


 I am banging my head on the table every day, because i cannot find an
 elegant and safe solution to secure a virtual shared environment (server).
 Take the following facts:
 -you have a virtual server (unix) and you have to take care of a lot of
 -no one has acces to shell, cronjobs or stuff like that, only 21 and 80
 -you dont want anyone to get out of his 'box' (eg /home/sasha/)
 -you want to allow php, perl or other web languages to run safely and in the
 same time will _almost_ all features.
 -in php (because this is the one of the most user language for web - for
 mostly endusers), i have options like safe_mode, but if i activate that,
 many functions and features will not work. i know (because i tested) that
 the best solution is open_basedir, but i cannot create an restriction like
 that for each user, or at least i dont know how to do that.

 My problem is that i tested some script-kiddies local exploits (php,perl)
 and the system is vulnerable, the user can get out of his box and see system
 files (etc/passwd, other dirs).

 What are the options here. Any paper or book written about this?


 Serban Gh. Ghita