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 <
craigwhite@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:
guest@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
(text/plain)