Skip to main content

Executing /usr/sbin/csf from PHP

Comments

6 comments

  • ThinIce
    One approach that may be preferable is to have your scripting update a block list text file that CSF then fetches using it's provided mechanism for doing so. That way you won't be doing anything esoteric. This is in the readme under section 24. IP Block Lists
    0
  • cPanelMichael
    Hello :) I just wanted to point out that as mentioned in the previous post, you may want to post this question to the CSF forums if you have not done so already. Thank you.
    0
  • quizknows
    Why not just use a ModSecurity rule to catch the query string, and use the LF_MODSEC setting in csf.conf to block repeat offenders? By default, CSF will block any IP which trips more than 5 ModSecurity errors in 300 seconds. I use this as a defense all the time. You can raise/lower the number of triggers, as well as set temporary instead of permanent IP blocks. Trying to let Apache/PHP run or edit anything with CSF could carry some potentially huge risks, seeing as the actual deny file (csf.deny) and other files are also root owned. Even if a non-privileged user (i.e. "nobody," or the account owner with SuPHP) could run the CSF binary, it would most likely be run without sufficient privileges to edit its own files. Obviously you don't want to let PHP or the web server do anything as root or with root owned files, nor would you want to make your firewall binaries and configs executable or writeable by non-privileged users. Also, thinice's suggestion isn't bad at all. You could have your PHP app put the IP(s) into a text file, and set up a cron job for root which runs csf -d for the IPs in that file. I'd still much prefer to go the modsec route though, much cleaner, and the requests are blocked before your app has to parse them.
    0
  • GoWilkes
    On my end, I'm already testing for injections attempts, and that sends an email to me to manual handling. So ThinIce's suggestion would be the easiest to implement; it's just a matter of writing to the file at that point. I do have other questions on that, but I'll post them on the CSF forum. Thanks for the input!
    0
  • ThinIce
    [quote="quizknows, post: 1666801"> Also, thinice's suggestion isn't bad at all. You could have your PHP app put the IP(s) into a text file, and set up a cron job for root which runs csf -d for the IPs in that file. I'd still much prefer to go the modsec route though, much cleaner, and the requests are blocked before your app has to parse them.
    We're getting down the rabbit hole now, but without actually having the energy to look I'm wondering whether CSF -d does different checking on command line input to block lists it fetches via http which could conceivably be bad. I'd imagine given CSF's pedigree that all input is appropriately sanitised. I dunno I'd want to pass anything written to a file by a web app to a root cron execution, but I might be over egging the paranoia. For the OP, I think Quizknows suggestion is the best way to go if you're using modsec already, one criticism I do have of CSF is that certain things like the lf_modsec setting aren't mentioned in the readme. You can see them in the config file / whm interface however
    0
  • quizknows
    [quote="ThinIce, post: 1670121">We're getting down the rabbit hole now, but without actually having the energy to look I'm wondering whether CSF -d does different checking on command line input to block lists it fetches via http which could conceivably be bad. I'd imagine given CSF's pedigree that all input is appropriately sanitised. I dunno I'd want to pass anything written to a file by a web app to a root cron execution, but I might be over egging the paranoia. For the OP, I think Quizknows suggestion is the best way to go if you're using modsec already, one criticism I do have of CSF is that certain things like the lf_modsec setting aren't mentioned in the readme. You can see them in the config file / whm interface however
    That's a very good point regarding csf -d, were a hacker to gain a PHP shell and edit the IP list, adding command line arguments, that could very possibly be a huge risk if the cron was not coded to accommodate that possibility (i.e. parse the list with a regex for IPs only). Parsing an extra blocklist is probably safer overall. I still contend, as you agree, that ModSecurity is a better way to go about this. You catch the malicious PHP requests before your webapp has to do anything with them. It's better security wise, and probably more efficient as far as server load goes.
    0

Please sign in to leave a comment.