CrowdHandler includes a powerful firewall that can be used to control access to waiting rooms and your website.

The firewall feature is available on Plus plans and up, allowing you to add rules based on ranges to block, prioritize, or bypass traffic. Additional, automated IP filtering is available on Professional and Enterprise plans. These features work in tandem with Anomaly Detection.

Accessing The Firewall

Go to the domains list, Click on the shield icon next to the domain name you want to establish rules for (IP rules are configured on a domain by domain basis).

Manage IPs

The Manage IPs screen is the default view within the firewall. The screen shows your current firewall rules and your most prolific currently connected IPs. You can add new rules, edit an existing rule, or quickly change the status of a listed IP.

Rules affect traffic that is in scope for protection by your active waiting rooms. If you want the firewall rules to apply to all traffic on your domain at all times, you will need to establish a catch-all waiting room.

Adding a Rule

  1. Enter the IP address (or CIDR range)
  2. Add an optional note for easy identification
  3. Select the list you want to add this IP or range to

The statuses are as follows:

  • Ignore - This means the IP should be treated as normal with regard to site access and queue prioritization, but that it should not be subject to any automated activity, such as auto-blocking or anomaly tracking. Use this status if you know and trust the origin of an IP or range and would not want it to be blocked by normal rules.
  • Block - Use this to block IPs or ranges. The user will be redirected to the waiting room, displaying the blocked state. You can modify the messaging by customizing your template.
  • Bypass - Traffic from IPs or ranges set to bypass is essentially invisible to CrowdHandler. We will not check the user, queue them, track the session, or even log the request. This does mean that CrowdHandler is not protecting you from bypassed traffic at all, so we recommend using this for small numbers of trusted users where helpful. The obvious use cases are operational staff checking that the application is operational behind the queue and developers who want to test their application without any queue interference.
  • Prioritize - Traffic from prioritized IPs and ranges gets served first in the queue. Users may experience this as skipping the waiting room entirely, depending on traffic levels. But they are checked against overall domain rates anyway and if necessary will be queued in a smaller priority lane. This works the same as if the user had used a priority code. IP prioritization can be useful to automatically prioritize VIP clients connecting from corporate networks, or in cases where internal sales and support staff use public applications on behalf of customers.

IP Readout and Changing Statuses

The Manage IPs screen lists your existing rules and shows the most prolific IPs currently connected. The information is as follows:

  • IP address - v4 and v6 are supported
  • Country of origin flag and network icon - Hovering over each icon will show you the city and country name and the name of the network or ISP. Clicking on either of these will show you IP lookup information including more details about the location and the network. Of particular interest may be the route (a CIDR range) because instead of blocking or ignoring a specific IP, you may find it more effective to apply a rule to the entire route.
  • Note - You can update this. Any auto-blocked IPs will have a note about the reason for blocking. Any IPs crossing warning thresholds will also have notes.
  • Sessions - A count of the number of sessions originating from this IP. High counts can be indicators of bot activity, fraudulent behavior, or users attempting to game a queue with many devices or private tabs. They could also indicate a corporate, governmental, or educational network. If these look like a legitimate audience for you, you may wish to set these IPs (or routes) to ignore.
  • Connected - Indicates the time sessions from this IP first connected. Sessions that have been connected for an unusually long time may be suspicious.
  • Status - You can quickly set an IP to one of the statuses described above by selecting the status and clicking the save icon.

IP Filtering and Automated Blocking

At the top of the screen are three controls for automatically filtering traffic based on IP intelligence or behavior.

Known threat filtering and Blocking by anomaly score require you to be on the Professional plan or above.

Known Threats

CrowdHandler uses a combination of externally sourced intelligence about IP addresses and internal intelligence based on observation across client traffic to categorize IP addresses. You can use these categories to automatically block traffic on first contact. You can opt in to any of these categories:

  • CrowdHandler Block Rules - This is our global block database. It is built by observing traffic across our network and identifying the IP ranges that repeatedly flag anomalous, fraudulent, or threatening behavior across more than one client. It currently covers approximately 3 million IP addresses. The list of rules is regularly reviewed but updates automatically. Users who opt into this list often find that individual blocks and anomaly warnings on their domain decline by up to 80%. However, unlike all the other rules on this list, individual blocks based on this list are not logged within your control panel. Rules within your admin panel take precedence over our block rules. So if you find that we are blocking traffic you think should be allowed, you will be able to add ignore rules to override ours.
  • Known Attackers - These are IP addresses that have been flagged on external IP databases as attempting security threat type behaviors. Examples would be SQL injection or XSS attempts. We recommend blocking this traffic.
  • Known Abusers - These are IP addresses that have been flagged on external IP databases as attempting spam/abuse type behavior. Examples would include comment-stuffing, repeated newsletter registration, scraping, etc. We recommend blocking this traffic, but this category is more prone to false positives than the previous, as it is common for domestic ISP users to be unwittingly caught up in this behavior or rotate onto an IP address previously used for this behavior.
  • TOR - External intelligence flags this address as belonging to the TOR network, a source of much fraudulent traffic. We recommend blocking TOR. While users may have a right to anonymity, you probably do not want anonymous customers.
  • Data Centers - Traffic originating from data centers rather than businesses or domestic ISPs is highly likely to be scripted traffic (bots in other words). We recommend blocking data centers. Note that legitimate data center IPs may include monitoring services, search engine crawlers, and payment gateway callbacks. CrowdHandler maintains global pass lists for these, but if you find that you are blocking a service you rely on, then adding an ignore rule for that range will override auto-block behavior.
  • Proxys - Users use proxy networks (or VPNs) to disguise their identity. Most fraudulent users and bot traffic originate from proxy networks as users who are acting illegally do not want their IP address to be identifiable. Blocking proxy networks results in less fraudulent traffic. Be aware that many domestic users now use VPNs based on privacy concerns, and these users could be blocked. We recommend updating the block message in your waiting room to advise legitimate users to switch off VPNs when using your application.

Autoblock IPs with More Than X Sessions

Generally, you expect a session (a single CrowdHandler token) to map to a single IP. If you have many tokens connecting from a single IP, this can be an indication of a scraper bot or a user using many devices or anonymous tabs. This slider allows you to set the acceptable number of sessions to connect from a single IP before that IP is auto-blocked. Another reason you may see many connections from a single IP is if the IP is on a corporate network or an academic institution. We recommend setting a reasonable limit (say 10) and adding ignore rules for any IPs belonging to networks that you think may reasonably have multiple sessions.

Autoblock with Anomaly Scores Above X

This slider allows you to automatically block IPs from which sessions are originating with excessive anomaly scores. You can choose the level to trigger a block.

Recommendations

The Recommendations tab will show you up to 20 recommended rules to add to the firewall. These are based on observations of clusters of IPs triggering auto-blocks and warnings on your domain.

  • Range - This is the CIDR range recommended for blocking.
  • Country and Network Icons - Hovering over these shows you the city and ISP connected with the IP range. Clicking will provide more detailed information.
  • Sessions - This will show the number of sessions tracked to the IP range. Clicking on this will open the Sessions tab with all anomalous sessions tracked from that range in the last seven days. You can use this to get a more detailed view of the behavior behind the recommendation.
  • Started and Latest - These dates show when IPs within this range were first observed and when they were last seen.
  • Recommendation / Block - If you agree with the recommendation to block the range, click the Block button. A permanent block rule will be added to the Rules tab.
  • Ignore - If you disagree with the recommendation (e.g., you think the network and behavior are consistent with a "good" bot), you can click the Ignore button. This will add an Ignore rule to the Rules tab for that range.

Autoblock Log

The autoblock log provides a list of IPs auto-blocked over the past seven days, and the reason for blocking. Autoblocks only last one hour by default. You can use the autoblock log to verify reports of false positives. Clicking on an IP in the auto block log screen will open the Sessions screen with anomalous sessions filtered by IP, so you can see what behavior may have contributed to an autoblock.