Any monkey could probably clean it or re-install it and put it on line. The reason I used the term "consult" is because I would hope whoever goes in to correct this would be able to educate them and secure them so they are not repeating their mistakes.
:) On Tue, Feb 16, 2010 at 3:25 PM, Craig White <craigwh...@azapple.com> wrote: > On Tue, 2010-02-16 at 14:37 -0700, JD Austin wrote: > > My 2 cents :) > > It may be a simple web form exploit or something more serious and they > > have no guarantee that it won't be exploited again and again. > > I'm not a security expert but used to hang out with hackers back when > > it was just starting to be illegal and have a good understanding of > > how they think and operate. I'm perfectly capable of doing such > > things but thankfully hacking never appealed to me :) Good hackers > > will patch your system in ways you would never detect... for that > > matter you'd never even know they were there... they won't show up in > > a process list, you won't find their files searching for them, they > > eliminate any trace of themselves in logs, and you probably won't find > > their back door unless they're amateur 'script kiddies'. Fortunately > > MOST hacker attacks are script kiddies. You'll usually find traces of > > their attack in logs and temp folders. > > > > The 'clean and recover' method will never give you 100% certainty that > > you've eliminated the exploit. The machine could have patched > > binaries all over the place. I have cleaned up such messes before; it > > can be very time consuming. Even if you find how they got in, how can > > you ever be completely sure you've stopped them from getting back in > > without building an new instance to replace it? > > > > The safest way to deal with it is to build a hardened server from > > scratch; before loading data: > > * change all passwords/etc on the new server > > * generate new ssh keys if they exist > > * install mod_ssl, intrusion detection, and fail2ban/denyhosts > > * re-write applications NOT to use register_globals in PHP and > > turn it off > > * turn up logging > > * migrate the applications/data to it after checking logs for > > clues of exploit and fix before migrating. > > The data center can probably give them some information to help them > > find where their server was exploited. > ---- > If the mandate is to clean in place and put back online, I myself would > not be interested because the predicate is one that I could never agree > to and hence, JD is right. You would surely spend more time fixing and > trying to locate and removing the exploits than backing up, clean > install and putting the data back and still, if it is not a clean > install, someone is going to have some sleepless nights. > > I myself am an avid fan of denyhosts. It is of course, the curse for the > dyslexic's among us ;-) > > Craig > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > --------------------------------------------------- > PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us > To subscribe, unsubscribe, or to change your mail settings: > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss > -- James Finstrom Rhino Equipment Corp. http://rhinoequipment.com ~ http://postug.com Phone: 1-877-RHINO-T1 ~ FAX: +1 (480) 961-1826 Twitter: http://twitter.com/rhinoequipment IP: gu...@asterisk.rhinoequipment.com
--------------------------------------------------- PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us To subscribe, unsubscribe, or to change your mail settings: http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
