Re: Re[3]: [cobalt-users] wish to Cobalt: suppressing "sensitive"information

[Kris Dahl <krislists@xxxxxxxxxxxxx>]

on 9/21/00 2:38 AM, Jerome Tytgat at j.tytgat@xxxxxxxx wrote:

> 
>> I agree, its NOT a good idea.  But neither is running software with an
>> exploit available.  Patching the the software is the solution.
>> Also, there
>> are many ways of fingerprinting a system, software, etc. not just
>> based upon
>> those messages.

> Right but why making the hacker life simplier ???? As really easy
> to suppress theses informations...

It is also really easy just to update the packages.  I guess I am saying
that keeping up to date on security is not as simple as being in 'shy' mode.
You have to update software--and if you think that not announcing version
numbers, etc., is a good way of making a hacker's life more difficult, then
you'd be wrong.

Turning of 'identifying' features is only a small effect.

>> It is a publicly readable file, for Christ's sake!  On a shared
>> server!  You
>> don't put sensitive information or code, or *anything* on a
>> server with such
>> circumstances!

> It depends... maybe we want to have A PHP3 server shared by several
> customers, they may have user/password database...

No, it doesn't depend.  I am saying if you are on a shared server, and you
have files that are publicly accessible then of course they'll be readable
by other users.  Its not a problem--its how file permissions work.

That's one reason why we a) use different passwords for the db read, stored
in a non publicly visible folder and b) don't let anyone onto our servers,
period.

If you want to have files that are not accessible to other people, you
pretty much need to get your own server.

There aren't too many sys admins that are going to want to come up with
method for access control on machines.
 
> Any way it's not a good idea to show a complete Web directory structure !!!!
> Think of whose your are trying to protect using .htacces...
> 
> USELESS !!!!

That is what .htaccess is: virtually useless.  It is NOT a substitution for
other methods of securing data.  It is simply a high level (as in simple)
method for restricting access to certain documents (that are normally 644)
via httpd.  Nothing more.  Even that can be worked around in some
situations.

Let me repeat this.  .htaccess is NOT a substitution for securing data.  It
is a simple tool that can help you restrict access to certain resources via
http.  It is neither a security method or an authentication tool.  It is a
tool to control web server configurations on the file.  Just because an
.htaccess file is most commonly used for htpasswd stuff doesn't make it a
best practice tool.   It is not a substitution for a true authentication
system.

If you are concerned with security you can not afford to be on a shared
server.  Bottom line.

>> I also wish that people would get the terminology right--that is not
>> 'telnet' access, but 'shell' access you are talking about.  Telnet is a
>> client, server, & protocol.  The shell is the actual command line
>> interface
>> that is commonly accesses with telnet, serial, or SSH.  Telnet should not
>> even be enabled or allowed or supported, especially now that the
>> RSA patent
>> has expired.
>
> The use of Telnet or SSH is out of word here... if we accord Telnet access
> or SSH acces to all our customers, the problem is rather the same...
> THEY CAN ACCESS OTHER PEOPLE DIRECTORIES !

I am saying that the proper term is 'shell' access.  Shell access can be
obtained by using a telnet or ssh client.

But again, its not that you can see other peoples directories, its that you
can see other peoples WORLD READBLE FILES.  You understand what that means,
right?  It means that the owner of the file has said "Here, everyone on this
system can read this file if they want to."

There are ways of engineering a better way to do this stuff--like storing
passwords in non public readable directories and have scripts suid or sudo
to read them, etc.  I guess I am saying that if you are concerned with
security you need to come up with an actual authentication system and use a
private non-shared server.  Sure that is harder to do than say 'magically
make all folders readable to the world, except other users on the server'.

>> I'd like to see the Raq's come with IPChain management
>> interfaces.  I.e. you
>> select the services you're running on the machine (POP, FTP, WWW, SSH) and
>> it blocks all other ports to the external interface.
> Yes but again that's not really necessary... As you have (i hope) a firewall
> in front. The WWW/POP/SMTP/FTP (USE FTP OVER SSH !!!) are enough for a good
> exploit, event WWW whith some CGI script.

No, having a firewall isn't necessary.  There are many issues involved with
running a firewall in front of a web server.

So running a firewall is not the only, or even the most desirable method for
filtering packets.  We use IPChains as a tcp wrapper.  This software is
commonly used in firewalls.  It is quite simply a firewall to the kernel.

a) latency
Adding an additional box that filters stuff will add latency to your
network.

b) single point of failure (we can stay running if one web server catches
fire)
If your firewall is down you're out of business.  Unless you want to have a
firewall to each machine.  Which is what we essentially have using IPChains.

c) can't easily be adapted by intrusion detection systems
We're able to detect attacks and immediately modify the firewall rules
based on this--something that may be difficult if you had an external
firewall

d) misc. 'problems' (confirmation issues, vendor software updates, rack
space, etc., etc. etc.)
Most firewalls take a 2U, some take 1U, some more than 2U.  That is more
space than your server.  Kind negates the effectiveness of a low form
factor.

-K