Date: Thu, 10 Dec 2009 08:12:14 -0600 From: Squirrel <squirrel@mail.isot.com> To: "Matthew Seaman" <m.seaman@infracaninophile.co.uk> Cc: FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org> Subject: Re: Hacked - FreeBSD 7.1-Release Message-ID: <b05d939654444c69f5b92288d20eb2c0@mail.isot.com>
next in thread | raw e-mail | index | archive | help
I do have most of measure you've mentioned implemented. There is one website that is required to have register_global, which I have set on his directory/.htaccess to prevent site-wide. Currently, I'm in process of upgrading all my ports. Thanks for info. -----Original message----- From: Matthew Seaman m.seaman@infracaninophile.co.uk Date: Thu, 10 Dec 2009 02:24:34 -0600 To: squirrel@isot.com Subject: Re: Hacked - FreeBSD 7.1-Release > Squirrel wrote: > > I've just finished the rtld patch. Now in process of regenerating > > all the keys and certs. Next will look into php. But far as rtld > > vulnerability, doesn't it require at least a local user account? > > Looking at all the authentication, there wasn't any authenticated > > session during the time frame. So I'm leaning more towards php > > 5.2.9, and checking all my ports. > > You don't necessarily need to have a login session (ie. recorded in wtmp) > to exploit the rtld bug -- just control over some process and the ability > to run commands through it. Although the rtld bug is "only" a local root > compromise, since it is so simple to exploit it is a lot more dangerous > than most, and in combination with just about any form of remote exploit > it means your box get rooted. > > Upgrading PHP and all ports is a good move. portaudit(1) is a good idea > but it doesn't necessarily address the direct route your attackers used. > My suspicions (in the absence of any detailed forensic examination of > your machine) are that you are running some vulnerable PHP code. This > may be part of a well known application, or it may be something locally written. > > In this case, I'd recommend a number of measures: > > * Run a security scanner like nikto (ports: security/nikto) > against each of the websites on your server. Do this at > regular intervals, and take action to fix any problems it > discovers. > > * Make sure that you only grant the minimum necessary permissions > on the filesystem to allow apache to run your applications. In > general, everything under your doc root should be *readable* by > uid www but not *writable* -- don't be seduced by the idea of > making the webroot owned by www:www --- root:wheel is a much > better idea, and files should be mode 644, directories mode 755 > unless there's a good reason to have them otherwise. > > * Refuse to run any PHP application that requires you to have > 'register_globals = YES' or to similarly poke enormous holes > in security through php.ini. Any application developer that > has not modified their code to use the $GLOBALS array by now > is lazy and incompetent and their code is likely to have all > sorts of other holes. > > * Similarly give your web application only the minimum necessary > permissions it needs to access any databases. You'll frequently > see instructions to do things like: 'GRANT ALL PRIVILEGES ON foo.* > TO www@localhost WITH GRANT OPTION;' This is way too much and should > be trimmed down. Web apps rarely have any need to make schema > changes, and creating other UIDs is right out, so > 'GRANT SELECT,INSERT,UPDATE,DELETE ON foo.* TO www@localhost' is a > much more reasonable starting point. > > * Where a web application has a legitimate reason to want to write > to the filesystem (eg. uploading files), preferably confine the > write access to a separate directory tree outside the web root -- > /tmp or /var/tmp aren't bad choices, but it might be better to > create a specific location for a particular application. > > * Where a web application has an administrative mode preferably > arrange to run this over HTTPS thus protecting any passwords > from snooping. If the administrative mode needs to have generic > read/write access to the web tree, then consider running it in a > completely separate Apache instance with different user credentials > than the generally accessible web server. > > Making the last point work with some arbitrary web application is > frequently challenging, but usually at least possible by a combination > of mod_rewrite and mod_proxy functions in the Apache config. > > Cheers, > > Matthew > > -- > Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard > Flat 3 > PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate > Kent, CT11 9PW > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b05d939654444c69f5b92288d20eb2c0>