<p>Awesome tips guys...</p>
<div class="gmail_quote">On Dec 5, 2011 11:01 AM, "John Jacobs" <<a href="mailto:flamdugen@hotmail.com">flamdugen@hotmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> 2. Do you think said phpmyadmin vulns are reasonable attack vectors in my<br>
> case?<br>
<br>
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.<br>
<br>
You are taking the correct steps with the egress firewall policy.<br>
<br>
Forward-going, I think it may be valuable to consider:<br>
<br>
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.<br>
2) Consider chrooting Apache via the 'chroot' directive for Apache (no more mod_chroot required).<br>
3) Consider a strict ingress and egress firewall which would have prevent the egress connection to the IRCd.<br>
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)<br>
5) Consider sane php.ini values and leverage Suhosin (plugin) as well (<a href="http://www.hardened-php.net/suhosin/index.html" target="_blank">http://www.hardened-php.net/suhosin/index.html</a>); 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.<br>
6) Restrict access to PHPMyAdmin based on authentication or remove it's access entirely.<br>
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.<br>
8) As you've already done with SSH, move it from TCP 22, PermitRootLogin no, and disable password authentication using key-based authentication.<br>
9) Using OSSEC-HIDS (<a href="http://www.ossec.net/" target="_blank">http://www.ossec.net/</a>) with inotify() to watch changes to your system and Apache directories including those that are HTTP writable.<br>
10) Mount /tmp noexec,nosuid,nodev as others have recommended.<br>
11) Optionally use mod_security with a tuned ruleset or another WAF.<br>
<br>
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.<br>
<br>
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.<br>
<br>
I hope this helped,<br>
John<br>
<br>
_______________________________________________<br>
Full-Disclosure - We believe in it.<br>
Charter: <a href="http://lists.grok.org.uk/full-disclosure-charter.html" target="_blank">http://lists.grok.org.uk/full-disclosure-charter.html</a><br>
Hosted and sponsored by Secunia - <a href="http://secunia.com/" target="_blank">http://secunia.com/</a><br>
</blockquote></div>