{"id":9102,"date":"2024-07-26T20:10:30","date_gmt":"2024-07-26T20:10:30","guid":{"rendered":"https:\/\/www.use-snip.com\/kb\/?post_type=ht_kb&p=9102"},"modified":"2024-07-28T23:45:50","modified_gmt":"2024-07-28T23:45:50","slug":"ip-blocking-and-banning-dialog","status":"publish","type":"ht_kb","link":"https:\/\/www.use-snip.com\/kb\/knowledge-base\/ip-blocking-and-banning-dialog\/","title":{"rendered":"IP Blocking and Banning Dialog"},"content":{"rendered":"

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

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

The IP Ban Setting Dialog is reached from the Setup Menu<\/strong> with the item General Setup Values…<\/strong>\u00a0 several related menu items are grouped with it.<\/p>\n

\"\"<\/a><\/p>\n

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

Main Dialog<\/h2>\n

\"\"<\/a><\/p>\n

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.\u00a0 A set of Checkboxes are used to enable \/ disable the various tests which SNIP<\/strong><\/span> will perform on new connections, while the value entered (when present) is used as the trigger threshold for the event or time.\u00a0 As is normal in SNIP<\/strong><\/span>, hovering the mouse over the control provides a tool-tip with a quick summary of use.<\/p>\n

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

\n

The basic Controls…<\/h2>\n

Various Tests and Thresholds<\/h3>\n

Core Settings:<\/h4>\n

The master on\/off switch at the top of the dialog marked Enable IP Ban Processing<\/strong> controls the entire blocking process.\u00a0 When disabled<\/strong>, no IP blocking is performed (all IPs are processed to determine if they are ‘good’ requests and no IP is ever blocked).\u00a0 It is recommend you only disable this during periods of debugging a connection and testing and leave it enabled at all other times.\u00a0 When the switch is enabled<\/strong> (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.<\/p>\n

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

Failed Connections, 1st time\u00a0<\/strong><\/em>\u00a0 This is the number of times in a row a bad connection must occur before the user is blocked\/banned.\u00a0 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.<\/p>\n

Failed Connections, 2nd time<\/strong><\/em> \u00a0 This is the number of times in a row a bad connection must occurs before the user is blocked\/banned, after<\/strong> being blocked at least once before\u00a0 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.\u00a0 The default is 1000 tries, still a large value.<\/p>\n

Ban Length Time<\/strong><\/em> \u00a0 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.\u00a0 The IP will not be allowed to successfully connect until the block period has past.\u00a0 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.\u00a0 [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]<\/p>\n

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

Other Settings:<\/h4>\n

The remaining check boxes control various proprietary logic tests performed by SNIP<\/strong><\/span> on each IP connection to detect misbehavior.\u00a0 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.<\/p>\n

Quick Connections<\/strong>\u00a0 Some misbehaving NTRIP devices will drop a connection and reconnect quickly, often faster than a 1Hz rate.\u00a0 One well known open source NTRIP device allows setting re connection rates much faster than recommend in the NTRIP documents.\u00a0 Other devices will only stay connected for a moderately short period of time, sending only a very small amounts of actual of data.\u00a0 This control allows setting the blocking thresholds for both events.\u00a0 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.\u00a0 When checked, anything less is considered a bad connection.<\/p>\n

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

NTRIP Server Multiplier<\/strong>\u00a0\u00a0\u00a0 This control is directed at base station devices (NTRIP Servers<\/a>) who are making bad connections.\u00a0 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<\/em> <\/strong>the allowed thresholds used on base station connections.\u00a0 The default value (when enabled) is a ‘multiplier’ of 4.\u00a0 That is, every bad connection from a base station is counted as four bad connections to reach the trigger threshold.<\/p>\n

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

Max. User Connections \/per IP\u00a0<\/strong> \u00a0 This control is designed to detect devices that create multiple TCP\/IP sockets without correctly closing their prior sockets.\u00a0\u00a0 Such devices all appear to come from the same source IP but with unique port numbers.\u00a0 Typically this is due to bad coding practices on the source device,.\u00a0 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.\u00a0 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.\u00a0 The fault value is set to be ten.\u00a0 Also note that the User Account<\/a> itself will likely also have a default number of\u00a0 simultaneous connections that are allowed, the connection would be rejected if either is exceeded.<\/p>\n

Max. Input Data Rate \/per Base <\/strong>\u00a0\u00a0 This control is designed to detect devices that send in way too much data.\u00a0 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).\u00a0 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.\u00a0 This value is averaged over a one minute period, so any short bursts in message transmissions will not cause false triggering.<\/p>\n

Count Repeated Caster Table Requests<\/strong> \u00a0\u00a0 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.\u00a0 If you wish to count, and in time block, such connections, enable this.\u00a0 Hints:\u00a0<\/strong><\/span> 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<\/strong>\u00a0 (see this link<\/a>).\u00a0\u00a0 If you want to ensure that your Caster will automatically restart if it is ever taken off line, run the SNIP<\/strong><\/span> monitor program for this (see this link<\/a>).<\/p>\n

Quick Ban Abusers<\/strong> \u00a0\u00a0 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.\u00a0 These devices are “quick banned” for a period of only ten minutes.<\/p>\n

Sandbox abusive connections<\/strong>\u00a0\u00a0\u00a0 This control is designed to detect devices that very<\/em> rapidly re-connect after being disconnected for a prior bad connection, often in only a few milliseconds.\u00a0 Such abusive devices are handled by “sandboxing” them.\u00a0 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\u00a0 v e r y-v e r y-slowly<\/em>.\u00a0 This has the effect of reducing the resources used by the Caster to manage such connections.<\/p>\n

Blocking a MountPt (on any IP)<\/h3>\n

The control Auto Ban by MountPt<\/strong> 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. \u00a0\u00a0 [If the mountPt is a Push-In reservation<\/a> you can also remove it there or just change the password to a value not known to the remote party.]<\/p>\n

Blocking a User\u00a0 Email<\/h3>\n

The control Block Emails<\/strong> 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)<\/strong> running your Caster in an OPEN mode (no User Account<\/a> required) and also b)<\/strong> you are requiring that all NTRIP Clients provide a valid email as the User Account string.\u00a0\u00a0 You can learn more about this mode of operation in this article<\/a>.<\/p>\n

Exempting an IP<\/h3>\n

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

Exempting an NTRIP Agent<\/h3>\n

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

The Reset Button<\/h3>\n

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.<\/p>\n

 <\/p>\n

\n

A Summary of Current Blocked IPs<\/h2>\n

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

\"\"<\/a>The listed IPs are shown in a table with a hyperlink for each IP.\u00a0 Pressing the link will provide an IP report<\/a> of the connections seen for that IP in the document viewer<\/a>.<\/p>\n

\n

Lower Controls and Buttons<\/h2>\n

The three checkboxes control which events are displayed in the console and in the logs.\u00a0 It is not unusual to UNcheck these in a busy Caster to reduce screen clutter.<\/p>\n