IP Blocking and Banning Dialog

This article reviews and explains the various controls that SNIP provides to automatically deal with with abusive user connections, blocking such connections for predetermined intervals of time according to the values you have set.   This functionality is available in all models of SNIP; in prior releases of SNIP the ability to block bad IPs and users and to control how the process worked was limited in the Lite model of SNIPLite and Basic model users should upgrade to the current release if you are are using an older release and need this feature (upgrades are always free).

Regrettably abusive user connections are a fact or life on the public internet.  It is most likely that any user you see abusing your NTRIP Caster will simply be a mis-configured NTRIP Client devices whose owners need some help with proper setup.  But in time you will also encounter purposefully hostile remote devices that you will want to prevent from using your Caster (and host machine).   These can grow to become disruptive to normal Caster operations.  This dialog allows the Caster operator to set thresholds and the various logic settings found in SNIP to deal with most such events without needing operator intervention.  Together with judicious use of the host machine firewall, you can overcome even severe bulk service attacks.

The IP Ban Setting Dialog is reached from the Setup Menu with the item General Setup Values…  several related menu items are grouped with it.

You can also invoke this dialog from the Clients and Casters tab, where it appears as a button marked “Bxxx” (where xxx is the current number of temporary and permanent Blocked IPs the machine currently has).  The dialog is shown below.

Main Dialog

The upper section contains a number of event thresholds that can be set to control how (and for how long) the IP blocking is applied to a misbehaving IP connection or user.  A set of Checkboxes are used to enable / disable the various tests which SNIP will perform on new connections, while the value entered (when present) is used as the trigger threshold for the event or time.  As is normal in SNIP, hovering the mouse over the control provides a tool-tip with a quick summary of use.

The lower section displays a summary of any blocked IPs. And finally at the bottom are some reporting and general control buttons.  Each is discussed in turn below.  In general, you can use the default settings for most Casters, and these values can easily be restored with the Default button.


The basic Controls…

Various Tests and Thresholds

Core Settings:

The master on/off switch at the top of the dialog marked Enable IP Ban Processing controls the entire blocking process.  When disabled, no IP blocking is performed (all IPs are processed to determine if they are ‘good’ requests and no IP is ever blocked).  It is recommend you only disable this during periods of debugging a connection and testing and leave it enabled at all other times.  When the switch is enabled (checked), all of the various tests and thresholds shown below it are active (if checked) and any currently blocked IPs will not be allowed to successfully connect to the Caster.

The next four controls set the basic thresholds used to determine if a repeating bad user connection should be considered bad enough to be blocked.  In other words, how many times in a row (without a ‘good’ connection) a given user or IP is allowed to have a ‘bad’ connection before being blocked.  And then, the period of time the blocking will last before being reset and the IP can try to connect again.

Failed Connections, 1st time   This is the number of times in a row a bad connection must occur before the user is blocked/banned.  On most Casters this is set to a large value to allow the user some reasonable period of time (hours) to correctly enter the account details and connect. The default is 2500 tries, which would consume several hours with any well behaved NTRIP Client. This threshold is used until the very first time a user has been blocked, then the 2nd threshold value is used thereafter when (if) connections resumes.

Failed Connections, 2nd time   This is the number of times in a row a bad connection must occurs before the user is blocked/banned, after being blocked at least once before  This typically is a smaller number than the 1st value with the assumption that such a device is simply going to keep connecting until a human operator notices it and that it should not waste Caster resources.  The default is 1000 tries, still a large value.

Ban Length Time   This is the period of time the block will persist. The default is 300 seconds (15 minutes) but much longer times can also be entered.  The IP will not be allowed to successfully connect until the block period has past.  A technical detail; it does in fact connect in that there is a TCP/IP socket created and read, but the content is not processed and the connection is dropped as soon as possible.  [The drop down menu used in other locations for blocking allows selecting times as long as 4 weeks. Longer times are typically used with problem IPs that are dynamic in nature and are therefore are not suitable for permanent blocking]

Reset Period   This is the period of time needed before the entire record of the bad User and IP is removed from the Caster memory.  If the IP in question does not connect at all during that time, the record of its prior bad connections are removed.  Any connection subsequent to this will be treated as an initial first connection and the threshold for a 1st fail connection will be used.   The default time is 3 hours.

Other Settings:

The remaining check boxes control various proprietary logic tests performed by SNIP on each IP connection to detect misbehavior.  The default values are suitable for most Casters, but there is no harm you can do to your Caster or to a well behaved NTRIP device by trying different values out to suit your own environment.

Quick Connections  Some misbehaving NTRIP devices will drop a connection and reconnect quickly, often faster than a 1Hz rate.  One well known open source NTRIP device allows setting re connection rates much faster than recommend in the NTRIP documents.  Other devices will only stay connected for a moderately short period of time, sending only a very small amounts of actual of data.  This control allows setting the blocking thresholds for both events.  The default setting are that a device needs to remain connected for at least 30 seconds or needs to send at least 5 kilobytes of data.  When checked, anything less is considered a bad connection.

Repeat Offenders  This control is directed at devices that are repeatedly being classified as bad and blocked.  After the aggregate number bad connections has been reached, the ban/block period for the next time will be X times longer in duration.  The default setting is 5000 bad connection resulting in a 4x longer ban time (for example a 15 minute ban would become 1hr).

NTRIP Server Multiplier    This control is directed at base station devices (NTRIP Servers) who are making bad connections.  As a general rule, base station devices are held to a higher level of expected performance than NTRIP Client devices are. This control allows reducing the allowed thresholds used on base station connections.  The default value (when enabled) is a ‘multiplier’ of 4.  That is, every bad connection from a base station is counted as four bad connections to reach the trigger threshold.

Max. Connections /per User /per Minute   This control is designed to detect devices that repetitiously make too many re-connection attempts in any one minute period.  The NTRIP standard (as well as the NTRIP Client Best practices document, freely available from RTCM) make it quite clear that upon repeated connection failures the NTRIP Client should implement a progressive back-off approach.  Such clients will never trigger this logic.   When enabled, any device connecting more often than the preset limit (which defaults to 70 connections a minute) is blocked.

Max. User Connections /per IP    This control is designed to detect devices that create multiple TCP/IP sockets without correctly closing their prior sockets.   Such devices all appear to come from the same source IP but with unique port numbers.  Typically this is due to bad coding practices on the source device,.  An exception to this would be a survey field team sharing a local hot spot, in such a case you might allow a larger number.  If you are using local NAT (such as your home or office) to connect multiple devices you may see this effect as well, all users are shown as coming from the public IP of the NAT device.  The fault value is set to be ten.  Also note that the User Account itself will likely also have a default number of  simultaneous connections that are allowed, the connection would be rejected if either is exceeded.

Max. Input Data Rate /per Base    This control is designed to detect devices that send in way too much data.  This typically indicates a misconfiguration of the GNSS messages to be sent, or a GNSS that has lost its mind (and may need a power reset).  A full constellation of all GNSS types sending MSM and other messages requires under ~15kbps, so the default value of 30kbps provides a wide safety margin.  This value is averaged over a one minute period, so any short bursts in message transmissions will not cause false triggering.

Count Repeated Caster Table Requests    This control is designed to detect devices that ONLY ask for the Caster table over and over again and and then never use it to connect to anything.  If you wish to count, and in time block, such connections, enable this.  Hints:  If you are using this to simply check if the Caster is up and running, have your remote monitoring service ask for a the Uptime report  (see this link).   If you want to ensure that your Caster will automatically restart if it is ever taken off line, run the SNIP monitor program for this (see this link).

Quick Ban Abusers    This control is designed to detect devices that connect with a garbled header or with credentials so obviously bad or malformed that it makes no sense to allow them to continue to repeat the process over and over again until the ban threshold is reached.  These devices are “quick banned” for a period of only ten minutes.

Sandbox abusive connections    This control is designed to detect devices that very rapidly re-connect after being disconnected for a prior bad connection, often in only a few milliseconds.  Such abusive devices are handled by “sandboxing” them.  When a connection has been sandboxed, it is NOT immediately disconnected, rather the connection is maintained and some nonsense data is sent back to it  v e r y-v e r y-slowly.  This has the effect of reducing the resources used by the Caster to manage such connections.

Blocking a MountPt (on any IP)

The control Auto Ban by MountPt allows entering a set of mountPt names that will not be allowed to connect (even if they have accounts setup). A few names are also predefined and cannot be removed. Blocking a mountPt in this way has advantages over blocking the source IP that is comes from if that IP is dynamic and therefore may change over time and when the remote device cycles power.    [If the mountPt is a Push-In reservation you can also remove it there or just change the password to a value not known to the remote party.]

Blocking a User  Email

The control Block Emails allows entering a set of email account names that will not be allowed to connect to the Caster. This has limited use when you are a) running your Caster in an OPEN mode (no User Account required) and also b) you are requiring that all NTRIP Clients provide a valid email as the User Account string.   You can learn more about this mode of operation in this article.

Exempting an IP

The button Exempt IPs… allows editing a list of IPs that are NEVER banned or blocked.  Use this to prevent ever having certain IPs blocked (such as machines used to remotely access SNIP with the Web API from).

Exempting an NTRIP Agent

The button Exempt Agents… allows editing a list of NTRIP Agents that are NEVER banned or blocked, regardless of the IP used.  Use this to prevent ever having certain any customer built NTRIP devices you control from being blocked.  Most deployments will never se this.

The Reset Button

Pressing this button will reset any temporary IP blocked IPs. If the offending IPs are still making bad connections, they will again be blocked when the correct threshold is again reached.

 


A Summary of Current Blocked IPs

The table in the lower part of the dialog shows a current summary of the IPs that have been blocked for various reasons.  Pressing the List button on each will result in the IPs being shown in the console log.

The listed IPs are shown in a table with a hyperlink for each IP.  Pressing the link will provide an IP report of the connections seen for that IP in the document viewer.


Lower Controls and Buttons

The three checkboxes control which events are displayed in the console and in the logs.  It is not unusual to UNcheck these in a busy Caster to reduce screen clutter.

  • Show Ban Events  – When checked,  the ban is noted in the log
  • Show Un-Ban Events  – When checked,  expiring bans are noted
  • Show Banned IP Connections  – When checked,  connections from banned IPs are noted in the log

Defaults  –  Resets all control to a default setting with reasonable values.

Report  –  Presents a summary report of the current banned IPs in the document viewer.

Edit…  –  Allow editing, adding, and removing the Banned IPs in a dialog for that purpose

“i”  –  Brings up this knowledge base page

Cancel  – Closes the dialog, without saving changes

Ok – Closes the dialog, saving changes

 

 

Was this article helpful?

Related Articles