As a first line of defense, make sure your Caster is set to accept connections only from users with preexisting accounts rather than being open for anyone to connect.\u00a0 This is controlled by the Manage User Accounts <\/strong>dialog (which is reached with the menu command Setup<\/em> \u21d2 Manage Users Accounts\u2026<\/em>) Ensure the check box \u201cAllow Anonymous Access\u201d is unchecked.\u00a0 While you can run your Caster in an Open<\/em> mode (no user account required), this makes it more vulnerable to attacks.<\/p>\n Then, assign any missing but needed User Accounts so that every valid user is registered with the Caster, and ensure they use the provided credentials.<\/p>\n If the problem connection is coming from one of your legitimate users, the next step is typically to contact that user and work out the issues.\u00a0 It is fairly common for a user to enter incorrect settings and then leave the NTRIP Client device on for many hours.<\/p>\n If the connection is unknown and unauthorized, it presents greater challenges and most of the remainder of this article is devoted to managing that issue.<\/p>\n We next consider the various tools SNIP<\/strong><\/span> and the Host Windows machine provide to block such connections for varying periods of time.\u00a0 We then review the general process to detect and track such abuses.<\/p>\n Once your Caster is closed (so a user account is required), there are three primary lines of defense used to block unwanted connections; each is considered further in turn.<\/p>\n For the most part, legitimate users are well handled by the first point. In the event of multiple bad connection attempts (greater than the threshold levels you have set in the below dialog), such users are banned for a fairly short period of time you have set.\u00a0 If your Caster has the eMail Plug-In<\/a>, the SNIP<\/strong><\/span> operator will receive an eMail alerting them when a user is blocked (as well as the reason for the block).<\/p>\n The use of these settings is described further here<\/a> and here<\/a>.\u00a0 \u00a0Access this dialog with the menu command SetUp<\/em> \u21d2 IP Ban Settings\u2026<\/em>\u00a0\u00a0\u00a0 You will see the below dialog.<\/p>\n The key point to be observed is that the various controls shown on the upper section of the dialog allow you to set the thresholds for various events that will result in a temporary ban for the offending source IP.<\/p>\n The ban time is set with the 2nd<\/sup> control (\u201cBan length time\u201d – here set for 300 seconds, or 5 minutes).\u00a0 You will typically want to set this in a range of no more than a few hours.\u00a0\u00a0 When you edit a banned entry<\/a>, a drop\u2013down combo allows selecting much longer time periods.\u00a0 These can span up to 4 weeks in length.\u00a0 This is usually only required for “problem” cases. \u00a0You can also make any IP ban permanent in that dialog.\u00a0 This is discussed further in the next section.<\/p>\n The three buttons deserve further discussion.<\/p>\n Ban by MountPt<\/strong>; \u00a0Enable the \u201cAuto Ban by MountPt” checkbox whenever a problem base station or user is connecting to a specific mountPt using multiple IPs in a small subset.\u00a0\u00a0 Press \u201cEdit<\/strong>\u201d and enter the mountPt name in the list of prohibited mountPt names.\u00a0\u00a0\u00a0 If the connection attempt comes only from a single IP, there is no need to use this method.<\/p>\n The Exempt IPs<\/strong>\u2026 \u00a0button is used to create a list of IPs which you NEVER want to have banned.\u00a0 Such IPs are typically trusted devices used to monitor aspects of the Caster\u00a0 For example, you might have a 3rd<\/sup> party monitoring service that is checking the caster or a specific mountPt in the caster.\u00a0 [Aside: Tracking and reporting any base station that has gone offline is much better handled by the NTRIP Server Warnings which are part of the automatic eMail reports; see this article<\/a> for more details.]<\/p>\n The Exempt\u00a0 Agents\u2026<\/strong> button does that same thing for known agents string.\u00a0 Use this button (rather than Exempt IPs\u2026) if a trusted devices may connect from multiple IPs.<\/p>\n When an IP is blocked, it is listed in the lower section of the above dialog.\u00a0 You can also examine the current list by pressing the Edit<\/strong> button. \u00a0This brings up a display of the currently blocked IPs.\u00a0 The radio buttons can be used to show\/hide the temporary or permanent blocked IPs in the display.<\/p>\n In the Edit dialog you can extend the ban period for any entry by selecting it and then selecting a longer time period.\u00a0\u00a0 You can also\u00a0 use the Add\u2026<\/strong> button to create a new entry.\u00a0 And the Remove<\/strong> button deletes the selected entry.\u00a0\u00a0\u00a0 Both Add<\/strong> and Edit<\/strong> bring up the below dialog.<\/p>\n If you check the box for Permanent<\/strong> then the IP will never be removed from the blocked list.\u00a0 Do this only when you have an IP which you will never allow to connect to your Caster.<\/p>\n Use the \u201cNote:\u201d section to (optionally) add a short textual message regarding why this IP was blocked.\u00a0 This will be of value to you when you next look at the IP.\u00a0 Some customer report settings can allow other parties to see this text, so politeness should be considered to avoid embarrassment.<\/p>\n The blocked IP entry also allows for the use for a subrange<\/em> for the lower byte, using the \u201c*\u201d character.\u00a0 An entry like \u201c1.2.3.*\u201d will block every IP between the ranges of 1.2.3.0\u00a0 to 1.2.3.255\u00a0 This has great value if the problem connection comes from a limited range of IPs that often changes.<\/p>\n Adding an IP manually (or editing an existing one to persist for longer period of time) is your primary defense for problem connections that are not sufficiently handled by the automatic logic above.\u00a0<\/strong><\/span>\u00a0 It is not uncommon to block such connections for several days or more at a time on the presumption that the device owner will notice that their connections are blocked and correct things.<\/p>\n Aside<\/strong><\/span>:\u00a0 If you have the eMail Plug-In<\/a> and the Enhanced User Management<\/a> (EUM) Plug-In, then the owner of the user account can be automatically emailed when the offending device is first blocked.\u00a0 The email (which is CCed to the Caster operator as well) contains a summary of the error cause.\u00a0\u00a0 This is often enough to resolve the problem without further technical support.<\/p>\n When a customer informs you that they have corrected the issue or requests that an IP block be removed, bring up the above dialog, select that IP, and press Remove<\/strong> to clear it.<\/p>\n Whenever SNIP<\/strong><\/span> has blocked an IP, that IP can still establish a connection to SNIP<\/strong><\/span> (or to any other open port on the host machine). \u00a0\u00a0In the SNIP<\/strong><\/span> process flow, new connections are checked against the blocked list and if found are then promptly disconnected.\u00a0 This requires a small amount of processing effort which can be noticeable in very heavily loaded Casters.<\/p>\n Another way to block such connection is the use the firewall logic on the host machine that is running SNIP<\/strong><\/span>.\u00a0 \u00a0An IP blocked at the host firewall will never connect to SNIP<\/strong><\/span> and is discarded without ever interacting with the SNIP<\/strong><\/span> application.\u00a0 As a result; such IPs do not leave any traces in the connection logs.<\/p>\n On a Windows server host this is called the Windows Defender Firewall;<\/strong> on Windows 7 machines it is called Windows Firewall<\/strong>, changing the name for Windows 8 and 10.\u00a0 The interface details vary in small ways.\u00a0 You will want to make changes with the Advanced Settings, in the section called Inbound Rules<\/strong>.\u00a0 \u00a0Here you can add multiple IPs (or ranges of IPs) to be blocked.<\/p>\n Adding a new IP involves three dialog box, shown below.\u00a0 From the advanced settings, proceed as follows.\u00a0 Create an inbound \u201cport\u201d rule for port 2101 (or whatever port your Caster uses).\u00a0 This will be set to \u201cblock\u201d any \u201cTCP\/IP\u201d type connection from the IPs you enter.\u00a0\u00a0 We suggest you name this rule \u201cBlock InBound SNIP Connections.\u201d\u00a0\u00a0 You then use the \u201cScope\u201d tab to enter and review the remote IP addresses you wish to block. \u00a0If you press the \u201cAdd\u201d button the dialog in the foreground below is displayed.\u00a0 You can enter either a single IP or a range of IPs here.\u00a0 If you enter an ill-formed one or a duplicate, the dialog will not accept it and will warn you.<\/p>\n This is basically the opposite action of the in-bound rule you may have created when you first set up SNIP<\/strong><\/span> to ALLOW traffic on port 2101 to reach your Caster.\u00a0 [An example of doing this can be found in this article on AWS firewall setups<\/a>.]<\/p>\n Blocking an IP at the host machine firewall should be considered a drastic and final step to take for devices that repeatedly attempt \u00a0to connect over a long periods of time.\u00a0<\/strong><\/span> It would generally be unusual \u00a0to take this step for a known customer who could be contacted offline and the problem resolved.<\/p>\n <\/p>\n How do you monitor or observe bad connections?\u00a0\u00a0\u00a0 <\/em><\/p>\n There are several ways including using the console log, the events view, looking at various IP reports, and watching live user connection attempts using the Connected Users<\/strong> dialog.<\/p>\n Well, the first place to look in real time is the console log itself. There you will see any connection as they occur in real time. If you set the console log to be \u201cMinor<\/em>\u201d (mid-screen combo button) and check the box marked \u201cShow Protocol Details<\/em>\u201d\u00a0 (found in the Caster and Clients<\/em> tab) – then you will see the details of the connection as well as the way the connection was handled.\u00a0 Use the Pause<\/strong> button (mid-screen right side) to stop the console from scrolling when there are many entries occurring.<\/p>\n The \u201cMajor Events\u201d view along the right side also provides a quick color-highlighted summary of good\/bad connections for both Base Stations and User Connections.\u00a0 [This is a Pro<\/em> <\/strong><\/span>model feature only; enable its display with the Show Sums<\/em> check box]\u00a0 You can easily see repeating\u00a0 connection problems over short time spans this way.\u00a0 See this article<\/a> for further details.<\/p>\n To get a summary of recent Blocked IPs (both active and those in the past) a report can be used.\u00a0 \u00a0The Network Traffic reports are useful for this (menu: Reports<\/em> \u21d2 Network Traffic<\/em>\u00a0 then select the desired report).<\/p>\n The IP_Ban_Report<\/strong> report provides a summary of current and past Blocked IPs. It often provides both the MountPt involved and the reason for the block.\u00a0 This report also provides a prior history of the past ~100 blocked IPs which is useful when checking for problems that have occurred over the past few days.\u00a0 An example report (without user identities and supporting report links removed) can be found here (to be provided).<\/p>\n Bad connections from any IPs which are currently being blocked can also be easily tracked using the Connected Users<\/strong> dialog (open with the menu command SetUp<\/em> \u21d2 Display Current Users<\/em>).\u00a0 \u00a0You can sort the columns to see who is connecting.\u00a0 Click on the header in either the BAN<\/strong> column or the Duration <\/strong>column so that the display is sorted by this value.\u00a0 Press Pause<\/strong> to stop updating the display when one of more banned entries are shown you wish to examine.\u00a0 [Note<\/strong><\/span>: Any IPs blocked by the host firewall will not be displayed here because they never reach the SNIP<\/strong><\/span> application.]<\/p>\n![\"\"](\"https:\/\/www.use-snip.com\/kb\/wp-content\/uploads\/2022\/06\/CloseTheCaster.png?_t=1654121355\")
<\/a><\/p>\nLines of Defense<\/strong><\/h2>\n
\n
The threshold setting in the IP Ban Settings dialog<\/strong><\/h3>\n
![\"\"](\"https:\/\/www.use-snip.com\/kb\/wp-content\/uploads\/2022\/06\/IP_Dialog.png?_t=1654121464\")
<\/a><\/p>\nManually Blocking an IP at the Caster
\n(for a temporary period or permanently) <\/strong><\/h3>\n![\"\"](\"https:\/\/www.use-snip.com\/kb\/wp-content\/uploads\/2022\/06\/Example_IPbanDialog.png?_t=1654121495\")
<\/a><\/p>\n![\"\"](\"https:\/\/www.use-snip.com\/kb\/wp-content\/uploads\/2022\/06\/Edit_IP_Ban.png?_t=1654121531\")
<\/p>\nBlocking on the Host machine using the Windows Firewall<\/strong><\/h3>\n
![\"\"](\"https:\/\/www.use-snip.com\/kb\/wp-content\/uploads\/2022\/06\/Firewall_IPblock.png?_t=1654121568\")
<\/a><\/p>\nDetecting and Watching Bad Connections<\/strong><\/h2>\n
The Console Log<\/h3>\n
![\"\"](\"https:\/\/www.use-snip.com\/kb\/wp-content\/uploads\/2022\/06\/consoleControls.png?_t=1654121603\")
<\/a><\/p>\nThe Event View<\/h3>\n
An IP Report<\/h3>\n
Watching live User Connections<\/h3>\n
![\"\"](\"https:\/\/www.use-snip.com\/kb\/wp-content\/uploads\/2022\/06\/connectedUsers-clean.png?_t=1654121618\")
<\/a><\/p>\n![\"\"](\"https:\/\/www.use-snip.com\/kb\/wp-content\/uploads\/2022\/06\/ConnectedUsers-banned.png?_t=1654121653\")
<\/p>\n