Date: Thu, 10 Dec 2009 23:36:58 +0800 From: Ganbold <ganbold@micom.mng.net> To: squirrel@isot.com Cc: FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org> Subject: Re: Hacked - FreeBSD 7.1-Release Message-ID: <4B21159A.8020509@micom.mng.net> In-Reply-To: <b05d939654444c69f5b92288d20eb2c0@mail.isot.com> References: <b05d939654444c69f5b92288d20eb2c0@mail.isot.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Squirrel wrote: > 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. > Don't forget to check vulnerable php codes for SQL injection, LFI/RFI, problematic file uploads etc. Ganbold > 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 >> >> >> >> > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > > > -- I'm glad that I'm an American, I'm glad that I am free, But I wish I were a little doggy, And McGovern were a tree.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B21159A.8020509>