Very useful john jacob ... really helpful. do you maintaine your blog or any other resource you want to share with us. thanx a ton .
On Mon, Dec 5, 2011 at 8:18 AM, Michael Wood <itnet...@gmail.com> wrote: > Awesome tips guys... > > On Dec 5, 2011 11:01 AM, "John Jacobs" <flamdu...@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/ -- Best Regards, Suresh Kumar Prajapati Linux System Admin E-mail: er.sureshprajap...@gmail.com Mob No: +91-8800920533 ---------------------------------------------------------------------------------------- Theory is when you know all and nothing works. Practice is when all works and nobody knows why. In this case we have put together theory and practice: nothing works... and nobody knows why! _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
