Re: [Full-disclosure] one of my servers has been compromized

[John Jacobs <flamdugen@xxxxxxxxxxx>]

> 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/