Mailing List Archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [tlug] Host Blocking and Logfile Parsing



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


Home | Main Index | Thread Index

Home Page Mailing List Linux and Japan TLUG Members Links