Message-ID: <CAJQ4Zp4MB3QKp2-_14ky9BCv3zuUNOqOi=pKtWocZoGTJUGLzA@mail.gmail.com>
Date: Mon, 5 Dec 2011 11:22:33 -0500
From: Josh Yavor <josh.yavor@...il.com>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: one of my servers has been compromized

Really enjoying following this thread. Any one have thoughts/opinions
on APF as an option to prevent this in the future?

On Mon, Dec 5, 2011 at 11:18 AM, Michael Wood <itnetsec@...il.com> wrote:
> Awesome tips guys...
>
> On Dec 5, 2011 11:01 AM, "John Jacobs" <flamdugen@...mail.com> wrote:
>>
>>
>> > 2. Do you think said phpmyadmin vulns are reasonable attack vectors in
>> > my
>> > case?
>>
>> I do, I believe this is to be the initial infection vector.  Scanning for
>> PHPMyAdmin is often and frequent and since it's likely that it was present
>> in it's default (or one of the default) URIs discovery is likely.  There are
>> a plethora of scanners out there which look for PHPMyAdmin specifically and
>> add to the Internet noise-floor.
>>
>> You are taking the correct steps with the egress firewall policy.
>>
>> Forward-going, I think it may be valuable to consider:
>>
>> 1) Leveraging AppArmor and creating an enforcing profile for Apache; one
>> that controls by extension or path, what the HTTPd can write to or access.
>> Be strict but sane.
>> 2) Consider chrooting Apache via the 'chroot' directive for Apache (no
>> more mod_chroot required).
>> 3) Consider a strict ingress and egress firewall which would have prevent
>> the egress connection to the IRCd.
>> 4) Remain up to date; perhaps cron 'apt-get clean all; apt-get update;
>> apt-get -t lucid-security -y dist-upgrade' (I believe the security channel
>> is correct)
>> 5) Consider sane php.ini values and leverage Suhosin (plugin) as well
>> (http://www.hardened-php.net/suhosin/index.html); disallow url_fopen and
>> url_include.  Disallow the exec(), system(), passthru(), etc commands if
>> possible.  url_fopen() will thwart RFI.  LFI should be thwarted by a sane
>> AppArmor profile.
>> 6) Restrict access to PHPMyAdmin based on authentication or remove it's
>> access entirely.
>> 7) Consider leveraging something like Fail2ban against Apache's error and
>> access logs looking for excessive high-frequency HTTP 404, 403, or 500
>> errors as these are indicative of scanning.  This is a great tool to stop
>> Web-app scanning.
>> 8) As you've already done with SSH, move it from TCP 22, PermitRootLogin
>> no, and disable password authentication using key-based authentication.
>> 9) Using OSSEC-HIDS (http://www.ossec.net/) with inotify() to watch
>> changes to your system and Apache directories including those that are HTTP
>> writable.
>> 10) Mount /tmp noexec,nosuid,nodev as others have recommended.
>> 11) Optionally use mod_security with a tuned ruleset or another WAF.
>>
>> I find #7 to be extremely helpful.  Feel free to hit me up for additional
>> clarification if needed.  I wish you the best, remember that
>> defense-in-depth is the best approach here.
>>
>> This is a good list-discussion as it is likely to yield many valuable ways
>> to correctly secure web applications.  Potentially any one of the
>> suggestiosn in #1, #2, #3, #4, #5, #6, #7, and #10 would have saved your
>> box.
>>
>> I hope this helped,
>> John
>>
>> _______________________________________________
>> Full-Disclosure - We believe in it.
>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> Hosted and sponsored by Secunia - http://secunia.com/
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists