Need a consultant

[James Finstrom]

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 at 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 at 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 at asterisk.rhinoequipment.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.PLUG.phoenix.az.us/pipermail/plug-discuss/attachments/20100216/ff980ec6/attachment.htm