Cidram: [Question] Need explanation of some fields.

[Dibbyo456]

1) Could you please explain about a bit more of default_tracktime and infraction_limit a little bit more? YES..! I have read the docs but I still don't understand what is it and how it improves firewall and why should I use it and how cidram uses it.

2) What's the difference between IP Address & IP Address (Resolved) in Auxiliary rules?

[Maikuolan]

1. What's the difference between IP Address & IP Address (Resolved) in Auxiliary rules?

"IP Address" and "IP Address (Resolved)" should always be the same, except when the IP address of the request is a "6to4" address ("6to4" provides a transition mechanism between IPv6 and IPv4 networks). Generally, under most circumstances, when two endpoints communicate (e.g., communication between client and server), that communication should occur over either IPv4 or IPv6, but not both. However, in practice, I've found that sometimes, when a server supports both IPv4 and IPv6, and when an inbound request is blocked, that soon thereafter, there'll be a subsequent request from a corresponding 6to4 address (when the initially blocked request originated from an IPv4 address) or corresponding IPv4 address (when the initially blocked request originated from a 6to4 address). Because of that, and also because this demonstrates that many IPv4 CIDRs blocked by CIDRAM belong to networks that support 6to4, it made sense that CIDRAM should try to automatically "resolve" 6to4 addresses to their corresponding IPv4 addresses, to prevent switching between IPv4 and 6to4 being a used as a viable means of bypassing CIDR blocks.

An example of a resolving a 6to4 address: If you go to the front-end IP test page, and try testing 2002:c0a8:1::, the results will display it as 2002:c0a8:1:: (192.168.0.1) (because 2002:c0a8:1:: is a 6to4 address and resolves to the local IPv4 address 192.168.0.1; which shouldn't generally be blocked, but suffices as a familiar example).

[Maikuolan]

Regarding infraction_limit: For every request, CIDRAM counts "infractions" (think of this just as a number, always starting at zero). Whenever signatures are triggered by a module, that module may add to the number of "infractions" counted for that request. Usually it adds just 1, but it can choose to add more, if the reason for the "infraction" is considered "severe" (e.g., hack attempts detected or similar such activities). This number can then be tracked between requests via CIDRAM's "IP tracking" feature. If the total number of infractions corresponding to a particular IP address exceeds infraction_limit, that IP address will then be blocked immediately, regardless of whether there are any CIDR blocks blocking that IP address, and until tracking expires for that IP address ("banned"). This is useful as a means of escalating CIDRAM's response to an IP address, in cases where the IP address isn't blocked by any signature files, but is repeatedly blocked by modules due to unwanted behaviour (and is also how I define the difference between an IP address being "blocked" versus being "banned" in the semantics of CIDRAM).

Similarly, whenever a module adds to the number of "infractions" counted for a request, it may define the amount of time that CIDRAM should retain that information. However, this is optional, and when a module doesn't define this, the default_tracktime is used instead.

The documentation describes default_tracktime as "How many seconds to track IPs banned by modules." But a more technically accurate description would be, how many seconds to retain the number of "infractions" that CIDRAM remembers for any particular given IP address. If an IP address is "banned" though (per CIDRAM's semantics), it becomes effectively unbanned when it's tracking information expires (due to that the tracking information – i.e., the number of infractions for that IP address, in relation to infraction_limit – is how CIDRAM knows to immediately block the IP address, regardless of the signature files), thus making the description for default_tracktime effectively accurate (but also a little easier to understand for some users, compared to the more technically accurate description).

The aforementioned in mind, the reason for implementing the track_mode directive may make a little more sense, too: Counting infractions for an IP address already blocked by signature files is mostly pointless, considering that the IP address should thus be blocked anyway, regardless of the number of infractions, and regardless of whether it becomes "banned". For a "set and forget" setup, I would in most cases recommend setting it to false. But for setups where website owners want to keep a closer eye on what gets blocked, actively optimising CIDRAM over time, to best suit the needs of their website, and for website owners wanting a more accurate feel for what's going on, in particular, by regularly checking their IP tracking page, it may be more prudent to set is as true.

[Dibbyo456]

If an IP is flagged and CIDRAM shows captcha then does it considered as infractions?

[Maikuolan]

If the IP is flagged as the result of a module signature, then yes. In other cases though, and if track_mode is false, then no.

[Maikuolan]

Closing as resolved.