Installation & Cfg

Hi @yvrdarb,

> I am not seeing any configuration menu link in WP plugins; is there any reason to use the main/non wp configuration interface?

CIDRAM doesn’t yet have its own specific page in the WordPress admin dashboard from which to customise its configuration and so on, but this is something on the to-do list and will be happening in the near future. ??

As some background: Due to that CIDRAM was originally intended as a general solution to be usable throughout a range of different frameworks and CMS (aside from WordPress; phpBB, Drupal, SMF, FluxBB, InvisionBoard, etc), many of the considerations specific to each of these various frameworks/CMS/etc (e.g., in the case of WordPress, direct integration into the WordPress admin dashboard) have tended to be secondary priority against things like general feature requests, improvements to CIDRAM’s own internal interface, signature updates and so on. Introducing CIDRAM as a plugin to the WordPress plugins database came a reasonable time after CIDRAM had already been made generally available via GitHub, and after it had, for the most part, already had most of its current features implemented (which is why we’ve got a plugin already at major version 2, yet without its own specific page in the WordPress admin dashboard yet).

The main and only meaningful hindrance to getting it done is the availability of time (i.e., against offline commitments, work, life, and all the other things that take time away from getting work done on the various unpaid open-source projects around, CIDRAM included). So, being primarily a question of available time, I don’t want to put a specific date on it, but I’m aiming to have it done at some point within the near future (preferably within no more than a few releases from now).

(Reference: https://github.com/CIDRAM/CIDRAM/issues/135)

> Should there be an entry in the .htaccess file? How can I test and be sure that it is configed and running?

The TL;DR version of CIDRAM’s .htaccess requirements: You don’t want any non-(trusted/authorised) people/users/bots/etc poking around CIDRAM’s “vault”, because the “vault” contains its “config.ini” file, which (if you’ve customised/written anything to it, like API keys and whatnot) could be exposed/compromised if anyone is able to poke around in there. But also, the “vault” needs to be writable, because it also contains CIDRAM’s cache data, and it’s where all your logs will be written to (if you’ve enabled logging via CIDRAM’s configuration), plus needing the ability to write to the configuration file and anything else in the first place if you happen to customise your configuration via CIDRAM’s own internal interface. So, restrictive access permissions, but allow write permissions (for PHP, at least). Nothing in the “vault” should ever be called directly (due to CIDRAM being loaded as a plugin by WordPress to do its thing, or only ever needing to be accessed via the loader.php file to access its own internal interface), so the vault shouldn’t generally need execute permissions at all.

• This reply was modified 5 years, 2 months ago by Maikuolan.
• This reply was modified 5 years, 2 months ago by Maikuolan.

In terms of testing whether it’s installed and working properly: If you enabled logging, you should see block events appearing in the logs within a day or so for any requests that CIDRAM blocks (assuming that it’s working properly), or nothing appearing in the logs otherwise (if it isn’t working properly and therefore not blocking anything).

Otherwise, for a more immediate test: If you’re able to trick WordPress/CIDRAM into thinking that you’re accessing your site using an IP address covered by any one of the CIDRs blocked by CIDRAM by default, you should then see the “Access Denied!” page appear when accessing your site, which is what should normally be seen in response to requests sent from the particular IP address in question to your site. Otherwise, if it fails to show the “Access Denied!” for one of the IP addresses covered by one of its blocked CIDRs, that could indicate a problem.

(And of course, if you or anyone else sees the “Access Denied!” page when it’s not intended, and assuming that everything has been configured correctly, that could indicate a false positive, which doesn’t necessarily mean it isn’t working properly, but is another kind of problem nonetheless, and something to be addressed, so let me know).

Thanks for the reply.

Yes, I actually figured it out afterwards.

I was expecting a config menu in WP because of point #6 in the install directions:

After you’ve activated the plugin, you’ll be able to modify the CIDRAM configuration file directly from your plugins dashboard.

So with that menu missing, I wasn’t sure if I had a good install or not and was concerned about site security because I had already stripped away a couple of layers of defence.

Ditto on the .httacess question, I wasn’t sure where or how it hooked and didn’t see anything readily.

But yes, it wasn’t long until my log file started to grow and I was comfortable going to bed ….

CIDRAM has to be the greatest hidden gem in the PHP security arena. I just happened to stumble across mention of it somewhere a week or so ago and have since put it up in front a couple of PHP scripts that were only protected by a free WAF. I used to believe that it was just a matter of time until they got compromised; with CIDR and a WAF I believe that they are pretty safe now.

A couple of suggestions for improvements for consideration:

– integration with Project Honeypot would add another proven layer of hostile filtering.
– more country specific geo-filtering options (ie Germany and/or Hetzner).
– better tor exit blocking because those are the ones that will eventually get you.

But a wonderful project none the less, thanks for your time and effort on the project.

Brad

• This reply was modified 5 years, 2 months ago by yvrdarb.