Hi, Does anyone think, that it makes sense to let have /bin/bash the following permissions? -rwx---r-x 1 root www 490716 Sep 9 18:12 /bin/bash With that setting, anyone exploiting the webserver could not execute /bin/bash (if course the same permissions could also be applied to /bin). Has anyone ever tried this? Does it break things? Did I find something cool? ;-) Markus -- __________________ /"\ Markus Gaugusch \ / ASCII Ribbon Campaign markus(at)gaugusch.at X Against HTML Mail / \
"exploiting" the webserver will give you the same "shell" rights as the
process for running the webserver does.
So changing the permission of /bin/bash is trivial.
Security for webservers starts by jailing the webserver. That's a
no-brainer.
Tim Rainier
Information Services, Kalsec, INC
trainier@kalsec.com
Markus Gaugusch
Markus Gaugusch wrote:
Does anyone think, that it makes sense to let have /bin/bash the following permissions? -rwx---r-x 1 root www 490716 Sep 9 18:12 /bin/bash
With that setting, anyone exploiting the webserver could not execute /bin/bash (if course the same permissions could also be applied to /bin).
Has anyone ever tried this? Does it break things? Did I find something cool? ;-)
I like it :-) It's not a real protection though. Especially not against an attacker that spends time to break into your system. It might help as quick workaround in situations where a hole is not fixed yet against script kiddies or worms that cannot adapt to such surprises. You probably want to apply it to other shells and interpreters like perl or csh as well. Of course cgi scripts that rely on them would stop working. You can also use ACLs instead of the group: setfacl -m u:wwwrun:--- /bin/bash cu Ludwig -- (o_ Ludwig Nussel //\ SUSE LINUX Products GmbH, Development V_/_ http://www.suse.de/
Ludwig Nussel wrote:
Markus Gaugusch wrote:
Does anyone think, that it makes sense to let have /bin/bash the following permissions? -rwx---r-x 1 root www 490716 Sep 9 18:12 /bin/bash
With that setting, anyone exploiting the webserver could not execute /bin/bash (if course the same permissions could also be applied to /bin).
Has anyone ever tried this? Does it break things? Did I find something cool? ;-)
I like it :-) It's not a real protection though. Especially not against an attacker that spends time to break into your system. It might help as quick workaround in situations where a hole is not fixed yet against script kiddies or worms that cannot adapt to such surprises.
For that, removal of wget(1) is probably more useful. Does YOU work even without wget? Rainer
Hi Markus, Rainer Duffner wrote:
Ludwig Nussel wrote:
Markus Gaugusch wrote:
Does anyone think, that it makes sense to let have /bin/bash the following permissions? -rwx---r-x 1 root www 490716 Sep 9 18:12 /bin/bash
With that setting, anyone exploiting the webserver could not execute /bin/bash (if course the same permissions could also be applied to /bin).
Has anyone ever tried this? Does it break things? Did I find something cool? ;-)
"real cool" people do not use Blacklisting, but whitelisting. So do groupadd bashusers chown root:bashusers /bin/bash chmod 510 /bin/bash and add any allowed Bash user to the group. Or even better, as already mentioned, cache the Webserver into at least a chroot environment. So you do not need to bother about wget&co. Dirk TRIA IT-consulting GmbH Joseph-Wild-Straße 20 81829 München Germany Tel: +49 (89) 92907-0 Fax: +49 (89) 92907-100 http://www.tria.de -------------------------------------------------------- working hard | for your success -------------------------------------------------------- Registergericht München HRB 113466 USt.-IdNr. DE 180017238 Steuer-Nr. 802/40600 Geschäftsführer: Richard Hofbauer kaufm. Geschäftsleitung: Rosa Igl -------------------------------------------------------- Nachricht von: Dirk.Schreiner@tria.de Nachricht an: rainer@ultra-secure.de, ludwig.nussel@suse.de, suse-security@suse.com # Dateianhänge: 0 Die Mitteilung dieser E-Mail ist vertraulich und nur für den oben genannten Empfänger bestimmt. Wenn Sie nicht der vorgesehene Empfänger dieser E-Mail oder mit der Aushändigung an ihn betraut sind, weisen wir darauf hin, daß jede Form der Kenntnisnahme, Veröffentlichung, Vervielfältigung sowie Weitergabe des Inhalts untersagt ist. Wir bitten Sie uns in diesem Fall umgehend zu unterrichten. Vielen Dank The information contained in this E-Mail is privileged and confidental intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient or competent to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this E-Mail is strictly prohibited. If you have received this E-Mail in error, please notify us immediately. Thank you
Rainer Duffner wrote:
[...] Does YOU work even without wget?
IIRC only on 8.1 wget was used. Newer YOU use libcurl. cu Ludwig -- (o_ Ludwig Nussel //\ SUSE LINUX Products GmbH, Development V_/_ http://www.suse.de/
Ludwig Nussel wrote:
Rainer Duffner wrote:
[...] Does YOU work even without wget?
IIRC only on 8.1 wget was used.
And SLES8, consequently. Boy, how I hate(d) to run YOU on freshly installed SLES (or esp. SLOX)-servers. It took ages, even on fast pipes (the only exception being the one company that had a 100 MBit pipe and was probably a direct downstream of the colo where the YOU-server was located)
Newer YOU use libcurl.
Ah, good to know. Thanks, Rainer
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! There are several methods securing your webserver. - - firerights - - chroot-ing - - compardment (set "kernel-attributes" for file-execution) - - (n)ids - - logserver for all servers within you network (no local logging) - - install only needed stuff - no more no less - - secure php.ini - - disable suexec within apache-config - - minimal php/other modules setup - - run mysql without network support (access only over localhost/127.0.0.1) - - restrict usage of directories to only inside special folders (php.ini: open_basedir) - this will only allow this directory as root for webpages no traversal out of this directory will be allowed! - - disable cgi ... - - customize your logs (log what's needed and extra data which might be interesting but not too much) - - with ssl enable high encryption [...] By setting rights to programs that may be used by another app (e.g. at apache startup) you may alter your configuration. Better give apache a restricted bash! Try chrooting your apache instead to make it a way more secure. Make a chroot-jail by copying ann needed libraries and stuff to /var/chroot/apache (/bin, /etc, and so on) and start apache with unprivileged user from chroot. This will give script-kiddie no rights except within chroot-jail. Maybe you want ACL's (not compareable to file-rights!) within chroot. Mention: The more effort you do on security the more time you will consume by doing so! The more secure a daemon is the more difficult it will be to "get it running". Regards Philippe - -- Diese Nachricht ist digital signiert und enthält weder Siegel noch Unterschrift! Die unaufgeforderte Zusendung einer Werbemail an Privatleute verstößt gegen §1 UWG und 823 I BGB (Beschluß des LG Berlin vom 2.8.1998 Az: 16 O 201/98). Jede kommerzielle Nutzung der übermittelten persönlichen Daten sowie deren Weitergabe an Dritte ist ausdrücklich untersagt! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQD1AwUBQ3HkHUNg1DRVIGjBAQIFfwb9Hdvx9tseJejJ7Fb80faBSK6DbELxXsxM uBQmaqhchLecagnpGjj+h4jIfyQVZ2GMgWcAPJTpTTEE5FAOlCmBMfg1cl2B96J+ vx5eAOp9/LZhDL1N1UZUTybvpX61ypWkC3zRilh20XSrKkJqYFejOhg/FA4wKvmP 04KU049kLGZCTuwKMonXmTu2EaASVNZmziN4HtVCwASJEqmPlZh4e5oz0E0uA4um vHzZiwzk3DLgk6emyuXxMcRj8vJ2C39KDAigSDG7MsjmprU2OdWtp2eWPzWOzDsp OlM1jh0Ed/Y= =MU5A -----END PGP SIGNATURE-----
Philippe Vogel wrote:
By setting rights to programs that may be used by another app (e.g. at apache startup) you may alter your configuration. Better give apache a restricted bash! Try chrooting your apache instead to make it a way more secure.
Make a chroot-jail by copying ann needed libraries and stuff to /var/chroot/apache (/bin, /etc, and so on) and start apache with unprivileged user from chroot. This will give script-kiddie no rights except within chroot-jail. At the risk of being accused of spamming again :) this is something that Novell AppArmor is very good at.
Unlike chroot jails, AppArmor confinement can be applied per CGI program, so that you don't have to put your entire web site into a single security container. More over, you can even put individual PHP pages and mod_perl scripts into individual security containers, achieving a very high degree of "least privilege" execution per program. An evaluation version of AppArmor is now included in SUSE Linux 10.0 if you would like to check it out. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering, Novell http://novell.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Markus, Markus Gaugusch wrote:
Hi, Does anyone think, that it makes sense to let have /bin/bash the following permissions? -rwx---r-x 1 root www 490716 Sep 9 18:12 /bin/bash
With that setting, anyone exploiting the webserver could not execute /bin/bash (if course the same permissions could also be applied to /bin).
Has anyone ever tried this? Does it break things?
iirc php needs a shell for serval functions like opening sockets. But when i last tested it, it was around end 2003 (i chrooted some apaches and was wondering why serval things stopped working until i found php needs at least a /bin/sh). So you might check that ;) Regards, Sven -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFDcc0rQoCguWUBzBwRAmKlAJ9woPXkfSbw1vhfkVRhqXtlPNQ7TQCggq9S ww1XAgmveOapImizNwPsajE= =zCfI -----END PGP SIGNATURE-----
participants (8)
-
Crispin Cowan -
Dirk Schreiner -
Ludwig Nussel -
Markus Gaugusch -
Philippe Vogel -
Rainer Duffner -
Sven 'Darkman' Michels -
trainier＠kalsec.com