<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 12/04/17 23:44, Chuck Tetlow wrote:
    <blockquote cite="mid:20120417222445.M41545@tetlow.net" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      <meta content="OPENWEBMAIL" name="GENERATOR">
      <font size="2"><b>---------- Original Message -----------</b>
        <br>
        From: "Darren Shea" <a class="moz-txt-link-rfc2396E" href="mailto:dshea@ecpi.com"><dshea@ecpi.com></a> <br>
        To: <a class="moz-txt-link-rfc2396E" href="mailto:blueonyx@mail.blueonyx.it"><blueonyx@mail.blueonyx.it></a> <br>
        Sent: Tue, 17 Apr 2012 17:16:27 -0500 <br>
        Subject: [BlueOnyx:10160] Re: Trojans and backdoors? <br>
        <br>
        > Thanks for all the suggestions, everyone. The particular
        hack does not seem <br>
        > to use the mailserver, nor has it created any files in the
        /tmp directory. I <br>
        > have pored over the logs (mail and httpd) thoroughly, but I
        can't say <br>
        > they've really been a whole lot of help.  I did try turning
        on suPHP, but <br>
        > that broke SquirrelMail also. There may be a configuration
        setting that can <br>
        > make that work; I'm still looking into it.. <br>
        > <br>
        > I did find one of my WordPress customers whose PHP settings
        allowed fopen <br>
        > and include - so I was able to lock that down. I also found
        several <br>
        > suspicious files in various user's directories, including
        some which <br>
        > appeared to execute strings of obfuscated code, and I
        removed all those. We <br>
        > don't appear to have had any new exploits in over 5 hours,
        but I am too <br>
        > nervous to relax about it yet! <br>
      </font></blockquote>
    <br>
    Everyone pretty much already answered how to fix this, find the
    offending script and toss it to /dev/null. Next step is try to avoid
    it imho. Every little bit helps especially when nowadays theres a
    lot of script kiddies around and lords of spam looking for servers
    to do their dirty work.<br>
    <br>
    Just wanted to share my experience and the simple methods (we
    learned banging our heads against the wall) we enforce to try to
    keep these occurences to a bare minimum (none if possible) as we've
    had numerous cases like this over our short life of 15 years
    (especially due to Joomla and Wordpress sites... "Especially"... Who
    am I trying to fool? Actually they're responsible for 100% of the
    cases).<br>
    <br>
    Injections, dovecot bruteforce and ftp bruteforce are especially
    nasty depending on the provider location.<br>
    <br>
    I remember that in one of the first providers we were, the FTP
    hammering was so bad... Like... Dozens of brute-force attempts on
    all IPs per second we had to configure Proftpd to only accepts
    logins from Portuguese IP's since our customers are 100% portuguese,
    we relied on the fact that none of them was ever going to access the
    FTP server from China or Russia, so we basically created a LOGIN
    rule that only accepted portuguese range's of IPs.<br>
    <br>
    And even configured like that we still got a bunch of hits due to
    the way our spam friends have their botnets do brute-force attempts
    with different IPs each time (really nasty to track them and ban
    them) and some of the botnet members were infected portuguese IPs
    computers.<br>
    <br>
    Worked very well for some time. But then we expanded our service and
    it stopped making sense.<br>
    <br>
    ------<br>
    Fail2ban is quite a nice option as you can nowadays configure it to
    check your logs for url includes / injection (80% of the cases..
    damned bored script kidies...) It automatically kicks in the butt
    the offending IP that tried to
    <a class="moz-txt-link-freetext" href="http://yoursite.com?variable=insert_nasty_http_include_here">http://yoursite.com?variable=insert_nasty_http_include_here</a><br>
    <br>
    Or you can just disable that php flag that allows the includes (i
    need it working on some sites though.. so needed an alternative).<br>
    <br>
    I have it set up to kick all the ssh / ftp / web injects / dovecot
    passwd fails offenders.<br>
    <br>
    Apache mod-security does the same thing and a LOT more but its also
    heavier and requires you to read a lot of pages of info to correctly
    set it up.<br>
    <br>
    ------<br>
    You can also set up a script that scans your /home/sites/ folder and
    regex looking for patterns of the most common php shells that these
    hackers love to use... Something like this (this is heavy...):<br>
    <br>
    <font face="Verdana">egrep -R -l
      '$OOO0O0O00|r0nin|m0rtix|r57shell|c99shell|phpshell|void\.ru|phpremoteview|directmail|bash_history|\.ru/|brute
      *force|MultiViews|cwings|bitchx|eggdrop|guardservices|psyBNC|DALnet|CASPER|RFI|CRACK|casper|rfi|crack|scanner'
      /home/sites/*/web | grep .php >> /root/scripts/hax.txt<br>
      <br>
      A /tmp checker that finds executable files and moves them to a
      quarantine, wipes, notifies.<br>
      <br>
      Rootkits... Its funny, never had any, guess i was just lucky but
      we do run a rootkit search every night too.<br>
      <br>
      <br>
      Hope any of this helps! Good luck<br>
      Cheers!<br>
    </font><br>
  </body>
</html>