Re: [tlug] Host Blocking and Logfile Parsing

[Curt Sampson <cjs@example.com>]

On Sat, 20 Jan 2007, scott wrote:

> Sure, but last time I was hacked it was remote php inclusion not brute
> force ssh attempts, so my thinking is drop all traffic from *all*
> suspicious machines. I agree that not allowing password authentication
> for ssh is a good idea, but I also think blacklisting the bad guys seems
> like a proactive measure as well.

Well, assuming, as I pointed out, that you're not using a script that
makes the problem worse. And even there, it provides no protection
against someone who tries the PHP attack *before* the ssh attack.

There are lots of things you can do to make your system more secure, and
you due to limited time (human lifetimes, and so on) you can implement
very few of them. So you need to analyze what you'll get the most
benefit from spending your time on.

Web applications, especially PHP ones, are notorious for for all sorts
of hacks; you'd probably get more advantage from sandboxing the apps to
the greatest degree possible. Here are some ideas.

Chroot the web servers running your applications, and give the minimal
set of tools they need to run. If there's no shell available, for
example, an attack that relies on eval'd code that then executes a shell
is not going to work.

If you've got multiple applications, run a separate web server for each
one, and then use a web server running in front of these to proxy the
requests to the application web servers based on host and/or path. If
the application web servers are running chrooted as different users,
it further limits the access of an attacker who gains control of the
application.

Use separate unix users and database logins for each web application,
so that getting control of one does not give you access to the data of
others.

Ensure that your web servers' database users have only the minimum
access necessary to carry out their work. There's usually never any
reason that an application running on a web server would need to be
able to add and drop tables for example. If it's your own application,
you can go quite far with this, and even disallow read access to things
such as user names, passwords and credit card numbers. For login, for
example, you can use a stored procedure in the database that takes
a user name and password and validates it, returning a user id; the
application then no longer has to be able to read user names and
passwords.

cjs
--
Curt Sampson       <cjs@example.com>        +81 90 7737 2974