Apache Security

I read this article:

http://builder.com.com/5100-6372-5113747.html?tag=ra

and was wondering if anybody out there very seasoned in apache and
linux security could make any comments on the suggestions this article
is making. Any other things you would add to his suggestions?
Anything techinically wrong with what this author is describing?

thanks for reading and writing back!

zestyone <zestyone@netscapemail.net> wrote in
news:dhi9211uf7rpoo1qbr0g4re03o10lgl8se@4ax.com:

> Anything techinically wrong with what this author is describing?

I have systems where the default shell for root was /bin/bash

Gandalf Parker
-- Do not go quietly into the night
rage rage rage against the dying of the light - Dylan Thomas
What does that mean? It means dont be a putz and quit the
multiplayer game before your candles are snuffed.

zestyone wrote:
> I read this article:
> http://builder.com.com/5100-6372-5113747.html?tag=ra
> and was wondering if anybody out there very seasoned in apache and
> linux security could make any comments on the suggestions this article
> is making. Any other things you would add to his suggestions?
Tip of the 'iceberg'.

Security is a process thing, not a simple chroot deployment.

How do you:
- Manage/update this product?
- Capture the operational complexity added?
- Support use web apps?
- Support Apache modules required
- Monitor/debug issues effectively

> Anything techinically wrong with what this author is describing?
See above mainly. Also chroot/jail aren't the effective solution lots of
people make them out to be. They are effective tools for stopping script
kiddies, but someone with clue or real intent then this is just a hurdle
.. Very ably documented in a number of books/weblinks (e.g.
http://www.ussysadmin.com/cgi-bin/do...0/p60-0x06.txt)

On Tue, 01 Mar 2005 15:04:39 -0500, zestyone wrote:

> I read this article:
>
> http://builder.com.com/5100-6372-5113747.html?tag=ra
>
> and was wondering if anybody out there very seasoned in apache and
> linux security could make any comments on the suggestions this article
> is making. Any other things you would add to his suggestions?
> Anything techinically wrong with what this author is describing?

If Apache can't access anything outside the trap directory, how is
it going to serve web pages, which have to be accessible via FTP
for users to upload their webpages? How would Apache access Perl,
Rebol, PHP, and other scripting languages? How would the virtual
servers write their logfiles? How would CGI programs write to
their own directory tree?

And if the hacker breaks Apache via a buffer overflow or something
similar, it won't matter what Apache's permissions are, because
the hacker will already have access at a deeper level.

The advantage to what the author is describing (which he doesn't
cover much, in the article) is that after the hacker exploits
your old, insecure version of Apache, you can see what changes
he tried to make to the fake system, which *might* tell you how
to protect the real system better.

> The advantage to what the author is describing (which he doesn't
> cover much, in the article) is that after the hacker exploits
> your old, insecure version of Apache, you can see what changes
> he tried to make to the fake system, which *might* tell you how
> to protect the real system better.

Very much right on.
I have used both chroot and non-chroot deployments of apache on
production level servers. Both have their advantages and
disadvantages but I more often opt - at least initially - for a
normal /srv/www or /var/www installation, concentrating security
on other areas. As to allowing users to update sites via ftp I
cut that out a while ago - too many holes to patch and too many
places to make a fatal mistake. Instead I opt to use ssh. Much
easier to log, control, and limit - with far better encryption
for authentication and data transfer (out of the box). A couple
of users initially complained but their problems where solved with
serveral update scripts (batch with cygwin for the windoze ones).

On the security note look into selinux and some other goodies -
i.e. the gentoo hardened project. Kernel level protections are
often overlooked but are far more important - if the kernel's no
good then your box may not even be safe from you.

MFP

zestyone wrote:
> Anything techinically wrong with what this author is describing?

One just cannot assume that "these are the libraries needed for creating
chroot environment". User has the ability to know exactly what libs are
needed by issueing "ldd httpd" command.

zestyone wrote:

> Anything techinically wrong with what this author is describing?
>

Erm, on my webservers the valuable stuff is the content - this doesn't
protect it.

C.

Colin McKinnon <colin.deletethis@andthis.mms3.com> wrote:

> Erm, on my webservers the valuable stuff is the content - this doesn't
> protect it.

Nothing within your httpd's document root should be writable by the user
as which the httpd process runs. That's true on your system, right?
If not, fix that right away -- and you'll have addressed your own
concern, fully (short of someone finding a way to make the httpd process
escalate privilege).

--
Cheers, Hardware: The part you kick.
Rick Moen Software: The part you boot.
rick@linuxmafia.com

Rick Moen wrote:

> Colin McKinnon <colin.deletethis@andthis.mms3.com> wrote:
>
>> Erm, on my webservers the valuable stuff is the content - this doesn't
>> protect it.
>
> Nothing within your httpd's document root should be writable by the user
> as which the httpd process runs. That's true on your system, right?
> If not, fix that right away -- and you'll have addressed your own
> concern, fully (short of someone finding a way to make the httpd process
> escalate privilege).
>

No, on my webservers the valuable stuff is the content.

While I want to protect against defacement, the point I was making was that
since I charge for access to particular parts of the site, a hacker gets
benefit simply by downloading files bypassing the normal controls. So not
letting the webserver user write the data doesn't help.

C.

Colin McKinnon <colin.deletethis@andthis.mms3.com> wrote:

> While I want to protect against defacement, the point I was making was that
> since I charge for access to particular parts of the site, a hacker gets
> benefit simply by downloading files bypassing the normal controls. So not
> letting the webserver user write the data doesn't help.

I do appreciate your explaining the special sense in which you used the
term "protect". When most of us speak about "protecting the content" of
a Web document root, in the context of a Linux security newsgroup, we
are thinking primarily of preventing intruders from making unauthorised
changes or deletions.

I would suggest that you would be _much_ less likely to waste your time
and that of others (such as yr. humble correspondent) if you were more
precise in the future. And would request that you do so. Thank you.

--
Cheers, Hardware: The part you kick.
Rick Moen Software: The part you boot.
rick@linuxmafia.com