Re: [SC-L] virtual server - security
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 http://www.eecs.utoledo.edu/~jwalden/ [EMAIL PROTECTED]
RE: [SC-L] virtual server - security
[EMAIL PROTECTED] <> wrote on Wednesday, March 31, 2004 11:35 AM: > 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. Could I interrupt this rather unenlightening exchange for just a moment to point out that you can have your cake _and_ secure it? There's a good couple of dozen implementations of the draft standard for FTP over SSL / TLS listed at http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html, not to mention any of a number of other FTP schemes that avoid passing usernames and passwords around in plaintext (S/Key, SASL, etc). You can have the comfort of FTP, the protocol you've come to love, at the same time as using a secure communications protocol that has become trusted by millions (although, with the number of "didn't read the instructions" mistakes made by some of the implementations, goodness only knows why). Okay, if I go on with this much longer, it'll turn into an advert, so I'll leave it at that. Alun. -- Texas Imperial Software | Find us at http://www.wftpd.com or email 1602 Harvest Moon Place | [EMAIL PROTECTED] Cedar Park TX 78613-1419 | WFTPD, WFTPD Pro are Windows FTP servers. Fax/Voice +1(512)258-9858 | Try our NEW client software, WFTPD Explorer.
RE: [SC-L] virtual server - security
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 > partition > 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 > > lately? > > 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 > php.net - > they are all bound to have tons of information about what you are looking > for. 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&
Re: [SC-L] virtual server - security
Tuesday 30 March 2004 11.05, Serban Gh. Ghita: > What are the options here. Any paper or book written about > this? su-wrapped MODPHP: http://www.suphp.org/Home.html (CGI is done via suexec) Even UML might be a Solution for you, if you have enough ressources. hth
RE: [SC-L] virtual server - security
You might also consider one of the IPS products (e.g., Okena/Cisco, Entercept/NAI, or PlatformLogic), all of which will allow you to constrain what happens and may be somewhat more scalable than VMware if you need to run a bunch of instances of the virtual environment. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Behalf Of Scott Nemec > Sent: Tuesday, March 30, 2004 6:46 PM > To: [EMAIL PROTECTED] > Subject: Re: [SC-L] virtual server - security > > > Have you looked at VMware? ( http://www.vmware.com ) > > 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 > be). > > On Tue, 30 Mar 2004, Serban Gh. Ghita wrote: > > > Hello > > > > 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 > > clients. > > -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? > > > > Thanks > > > > Serban Gh. Ghita > > > > > > > >
RE: [SC-L] virtual server - security
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > comments interspersed below... likewise. > 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. > 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 partition is not impossible- it could make life hell for quite a few. > "PHP" and "run safely" in the same sentence? Have you perused Bugtraq > lately? 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. > > 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 php.net - they are all bound to have tons of information about what you are looking for. just my 4 peso's. j -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (OpenBSD) iD8DBQFAavBfsKAeTAhLiCERAoSPAKCEJorfTmJsOIq9SrSF5CpKTSZwJACggxlx zH6eL2iKM3yvVoTWt59K5Kc= =1LCQ -END PGP SIGNATURE-
RE: [SC-L] virtual server - security
comments interspersed below... Kind Regards, -dsp > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Serban Gh. Ghita > Sent: Tuesday, March 30, 2004 4:05 AM > To: [EMAIL PROTECTED] > Subject: [SC-L] virtual server - security > > > Hello > > 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: [...] > -no one has acces to shell, cronjobs or stuff like that, only 21 and 80 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. > -you dont want anyone to get out of his 'box' (eg /home/sasha/) use 'chroot' jails > -you want to allow php, perl or other web languages to run safely "PHP" and "run safely" in the same sentence? Have you perused Bugtraq lately? > 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. 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") > 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). ::feigns shock:: > What are the options here. Any paper or book written about this? 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'.
Re: [SC-L] virtual server - security
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 clients. ... maybe something like plesk may be useful http://www.sw-soft.com/en/products/plesk7/ PS. don't bother to flame me if you disagree, I am not a unix guru Louis Solomon www.steelbytes.com
Re: [SC-L] virtual server - security
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ó: > Hello > > 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
Have you looked at VMware? ( http://www.vmware.com ) 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 be). On Tue, 30 Mar 2004, Serban Gh. Ghita wrote: > Hello > > 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 > clients. > -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? > > Thanks > > Serban Gh. Ghita > > >
