Home page logo
/

fulldisclosure logo Full Disclosure mailing list archives

Re: one of my servers has been compromized
From: Josh Yavor <josh.yavor () gmail com>
Date: Mon, 5 Dec 2011 11:22:33 -0500

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 () gmail com> wrote:
Awesome tips guys...

On Dec 5, 2011 11:01 AM, "John Jacobs" <flamdugen () hotmail 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/

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]