full-disclosure - Re: one of my servers has been compromized

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKKN48zB0tQeXybJWjejKeF6Uc1mv4NwBDGUh=a_Wf8NaNUcWA@mail.gmail.com>
Date: Mon, 5 Dec 2011 11:18:28 -0500
From: Michael Wood <itnetsec@...il.com>
To: John Jacobs <flamdugen@...mail.com>
Cc: full-disclosure@...ts.grok.org.uk, lucio@...web.org
Subject: Re: one of my servers has been compromized

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

Content of type "text/html" skipped

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