This Community site is new! Please help us build a community around the JNIOR.
Sign up, and help share your knowledge. Please sign-up even if you do not plan to post as a sign of support.
If there is evidence of a demand we will continue to develop the content here.

Reducing the RADIUS of the Internet

All topics concerned with Security, Privacy and Protection.
Post Reply
bscloutier
Posts: 399
Joined: Thu Sep 14, 2017 12:55 pm

Reducing the RADIUS of the Internet

Post by bscloutier » Wed Jan 10, 2018 11:17 am

Beginning with JANOS v1.6.4 you will be able to adjust the Time-To-Live (TTL) parameter used by the network stack.

The IpConfig/TTL Registry key defines the lifespan of a network packet. The time-to-live value is a kind of upper bound on the time that an IP datagram can exist in the Internet system. The value is reduced with the passage through a router. If it reaches 0 the packet is discarded. The default value has been increased to 128 from the value of 64 used prior to JANOS v1.6.4.

The TTL setting can be considered to limit the maximum radius (in terms of hops) of the network within reach of the JNIOR. The default setting should allow packets to reach the far end of the globe. A low setting would limit access to the unit as only those in the local vicinity could communicate. In this respect the TTL setting can be used to improve device security.

A very low setting of 1 or 2 would constrain the JNIOR to the local network. One must consider the need to reach Doman Name Servers (DNS) and Network Time Servers (NTP). There may also be the requirement for email transfers wherein the JNIOR needs to reach out to a SMTP Server. To help determine the minimum setting you may be able to use your PC's TRACERT command to detect the hop count involved in reaching those destinations. The JNIOR does not support a route tracing function.

bscloutier
Posts: 399
Joined: Thu Sep 14, 2017 12:55 pm

Re: Reducing the RADIUS of the Internet

Post by bscloutier » Mon Apr 02, 2018 8:38 am

Real World Test

Luckily we have a neat way to test the effect of reducing TTL. We have a JNIOR we call HoneyPot sitting on the open Internet. Naturally it comes under a constant level of attack. For instance there is a fairly constant level of random login attempts on the Telnet port. On the JNIOR the Telnet port provides access to the JANOS command line interface. We log failed login attempts to a @/access.log@ file.

Log files on the JNIOR rollover to BAK files when they reach 64 KB in size. We keep only one BAK file for each log. Typically an application would archive BAK files when longer term logging is desired. A syslog server can be used for the system log @/jniorsys.log@ for longer term logging.

On HoneyPot we have an application that takes the access.log when it rolls over and analyzes the hosts attempting to log into the unit. IP addresses are added to a database (JSON based) covering data from the past 24 hours. The application uses a locating service to identify the geographical location of the host. A simple web page http://honeypot.integpg.com/map.php receives the database and uses the Google Maps API to plot these locations.

By default JANOS uses a TTL of 128. The map typically appears as follows:

ttl_default.png
ttl_default.png (307.41 KiB) Viewed 65 times

If we reduce the TTL to 16 the map changes. Note that this seems to thin out the number of hosts able to communication with the unit. It does not seem to create a geographical radius.

ttl_16.png
ttl_16.png (300.49 KiB) Viewed 65 times

bscloutier
Posts: 399
Joined: Thu Sep 14, 2017 12:55 pm

Re: Reducing the RADIUS of the Internet

Post by bscloutier » Mon Apr 02, 2018 8:53 am

The thinning effect is useful but one gets the feeling that systems within our own country may no longer be able to communicate with the unit.

The further reduction of TTL to 12 begins to suggest a geographical radius. Note in the following how the unit now seems to be invisible in China. This might suggest that our friends in far away places might actually be using shortcuts in the network to gain access to systems in the United States.

ttl_12.png
ttl_12.png (333.31 KiB) Viewed 64 times

Of course, for a controller the most important aspect of this kind of security is whether or not YOU can access your own unit. In that case you might also use the IP filtering functionality of the device and limit access to only YOU.

One note. With the TTL limited to 16 the HoneyPot unit had trouble reaching some of the @pool.ntp.org@ NTP servers for synchronizing the clock. By limiting the radius of the network you may limit the useful services such as DNS and NTP.

bscloutier
Posts: 399
Joined: Thu Sep 14, 2017 12:55 pm

Re: Reducing the RADIUS of the Internet

Post by bscloutier » Thu Apr 05, 2018 9:14 am

So this test fails in that the service that is used to determine a location for an IP address is about 12 hops away. Here we see it is 13 from inside INTEG.
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Windows\system32>tracert ip-api.com

Tracing route to ip-api.com [69.195.146.130]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  10.0.0.1
  2     1 ms     1 ms     1 ms  50-197-34-78-static.hfc.comcastbusiness.net [50.197.34.78]
  3    12 ms     9 ms     9 ms  96.120.62.245
  4    10 ms     9 ms     8 ms  te-0-1-1-1-sur01.westdeer.pa.pitt.comcast.net [68.86.146.225]
  5    32 ms    15 ms    15 ms  be-62-ar01.mckeesport.pa.pitt.comcast.net [69.139.195.37]
  6    28 ms    21 ms    37 ms  be-7016-cr02.ashburn.va.ibone.comcast.net [68.86.91.25]
  7    21 ms    20 ms    20 ms  be-10130-pe04.ashburn.va.ibone.comcast.net [68.86.82.214]
  8    20 ms    20 ms    19 ms  23.30.206.206
  9    61 ms    61 ms    72 ms  xe-0-2-1.cr2-kan1.ip4.gtt.net [213.254.215.121]
 10    62 ms    52 ms    51 ms  ip4.gtt.net [69.174.12.26]
 11    52 ms    53 ms    60 ms  10.0.1.137
 12     *        *        *     Request timed out.
 13    52 ms    51 ms    51 ms  us-mo-1.free.ip-api.com [69.195.146.130]

Trace complete.

C:\Windows\system32>
And as a result with TTL restricted to 10 I get a lot of these errors.
04/05/18 08:29:12.949
** Uncaught java/io/IOException thrown: "Unable to connect to remote host"
   in java/io/IOException.<init>:(Ljava/lang/String;)V
   in java/net/PlainSocketImpl.connect:(Ljava/net/InetAddress;I)V
   in java/net/Socket.<init>:(Ljava/net/InetAddress;ILjava/net/InetAddress;IZ)V
   in java/net/Socket.<init>:(Ljava/lang/String;I)V
   in jaccess/JAccess.main:([Ljava/lang/String;)V at line 71
Just a note that I generally create application programs that are not destined for customer deployment with a throws Throwable clause. This insures that every exception is logged to the errors.log file and I don't need to busy the code with try-catch structures. The application uses the com.integpg.system.Watchdog class which restarts the application after a timeout. You can see this in the system log up until I removed the TTL restriction.

2018-04-05_9-08-36.png
2018-04-05_9-08-36.png (82.27 KiB) Viewed 62 times

In summary...

Reducing the TTL reduces the "radius" of the the accessible Internet but that does not precisely correspond to a geographic radius. Sites in Russia appear to have access to our Internet vicinity through less hops than some citizens in this country. Still it is a good defense in limiting access to the JNIOR so long as the resources your application uses can still be reached.

Post Reply