Skip to main content

How to block a POST Text string using mod security ?

Comments

4 comments

  • quizknows
    Append this to your modsec config: SecRule REQUEST_METHOD "post" "deny,chain,status:500,id:9379635" SecRule REQUEST_HEADERS "a9a007"
    This is assuming that the POST data is not encoded using base64 or something. You could add this to cover that: SecRule REQUEST_METHOD "post" "deny,chain,status:500,id:9379636" SecRule REQUEST_HEADERS "a9a007" t:base64Decode
    How you should really track this down, is run 'stat' on one of the modified files. Take the exact change and modify times provided, and find those times in the domains apache access log (domlog). This will really answer how it's happening, the file POSTed to at the time the other files were modified is the one doing the injection. That said, the modsec rules above might stop it. I would not recommend leaving these in place permanantly as it will deny any POST request with the string "a9a007" anywhere in the request headers.
    0
  • fuzioneer
    thx added the rules Having real problems trying to find the source, initially the hacker was uploading somehow a file to our server in a directory, the file was randomly named and contained a series of php code to find flaws in security (none disabled functions in php.ini etc) We found this file, disabled any functions it might use We are still getting attacked "successfully" once or twice a week with redirector code being added to .php and .html files on our site !!! (Note nothing since adding the mod sec extra rules but this is very early days) trying to find how they are gaining access and not really getting anywhere checked messages log but nothing happening around the time of attacks checked domain logs but nothing happening at time of attacks any other pointers of where / how to check ?
    0
  • fuzioneer
    the only facet of info I have found is from an older attack where an ip address was continuously over a very short timeframe so obviously a script accessing our forums (an old derivative of phpnuke / phpbb 2) http://ourdomain.com/ftoptitle-137109.html&sa=U&ei=JBgnUdXtNaTg0QHZw4CICg&ved=0CLsBEBYwMTisAg&usg=AFQjCNG0v848-sF24eoGCwqcmgJywrALNA" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)" this may or may not be a red herring though
    0
  • quizknows
    Nothing stands out to me from that request. What I would do in your case, aside from modsec rules, is go into the cPanel account and enable the "Raw Access Logs" archiving. As soon as a file gets affected again, before restoring or fixing it, just 'stat file.php' from a root shell. Note the output for Change and Modify. Technically Modify can be spoofed, however, "Change" cannot (at least, not on a system that is not root-level compromised). Assuming this is a webapp hack (and they don't have your FTP password or something), when you get the file stats, you will be able to match a request to that exact time in the archived Apache access logs (located in /home/$username/logs). If the times don't match up then you need to start checking your FTP logs and cPanel access log for file manager access.
    0

Please sign in to leave a comment.