Why is this strange IP address in Network connections?

Message

greengeek · #76 Post by **greengeek** » Sun 12 Jan 2014, 22:55

mavrothal wrote:You are still talking about "protection" BTW...

That's true, but my thinking is that a PC which is using an unknown IP address must be (to some extent) more protected than one which makes a calls to a remote party and says "Hi folks, I'm here, can you find out what my address is and send me a message telling me what that address is please"

I thought the first rule of internet security was to keep your address to yourself (at least till you open a browser).

If I was a hacker the first thing I would do is attract users to my website so I could harvest a list of IP addresses currently in use. If I don't visit any websites I don't give away my address. If hackers don't have my address then they have to guess where I am and go fishing for me. That in itself has to be some form of protection I would have thought.

Anyway, like I said, I was wrong in my belief about recent puppies putting their hands up at boot time and contacting a website without my knowledge. I appreciate the time taken to unveil the facts and lift the fog of my ignorance. Thanks!

anikin · #77 Post by **anikin** » Sun 12 Jan 2014, 23:59

greengeek wrote:If I understand you correctly you are saying that my computer DID NOT CONNECT TO icanhazip until I myself clicked on the 'network status information' option.

In that case I must apologise because I was under the impression that the external IP check was automatically occurring in the background at boot time. One of my concerns had been that this action would be like puppy putting it's hands up and saying "here I am!!" at a time when I may have preferred to stay below the radar and not be on the web.

So now I have the double protection of understanding that the external check was NOT happening automatically in the first place, and now also knowing that the modified ipinfo gives me the choice of permanently switching off the external check if I want to do so.

Yes, your computer DID CONNECT TO icanhazip or whatever that IP range means, your initial impression was absolutely correct. For the sake of this post, I will boot slacko-5.6 with unmodified network scripts and the first and only thing I'll do type 'netstat -a' in the terminal, to see all the internet connections, that have occurred. They are listed on the top above 'Active UNIX domain sockets (servers and established)'. I will not click on the network connections icon, because we are checking to see if the connections were auotmatic - not user initiated. Mavrothal, for some reason wants you to see only established connections, let's ignore his command and use our own. Here's what you'll see in the terminal:

Code: Select all

# uname -a
Linux puppypc30443 3.10.5 #1 SMP Sun Aug 4 22:29:04 EST 2013 i686 Intel(R) Atom(TM) CPU N270   @ 1.60GHz GenuineIntel GNU/Linux
# netstat -a
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 localhost:631           *:*                     LISTEN     
tcp        0      0 10.229.96.116:42158     delta.colo.mhtx.net:www TIME_WAIT  
udp        0      0 *:631                   *:*         
Active UNIX domain sockets (servers and established)

Not a single program is running on this machine, I didn't click the network icon, and yet the connection is there. Mavrothal will say it is harmless, it is closing. Yes, it is harmless in that sense. All that's happened is you have been tracked.

01micko · #78 Post by **01micko** » Mon 13 Jan 2014, 00:23

Firewallstate isn't fixed in 5.6

The source is now but that isn't released yet.

A simple whois will show that delta.colo.mhtx.net is owned by Nugget Enterprises, the host of icanhazip.com

http://myip.ms/info/whois/216.69.252.10 ... nhazip.com

No more FUD now please.

PS. I'll contact radky about making it optional in Pup-Sysinfo.

Appendix:

Code: Select all

# traceroute icanhazip.com
traceroute to icanhazip.com (216.69.252.100), 30 hops max, 46 byte packets
 1  home.gateway (192.168.1.254)  0.514 ms  0.347 ms  0.328 ms
 2  172.18.213.3 (172.18.213.3)  11.315 ms  11.854 ms  11.249 ms
 3  172.18.70.101 (172.18.70.101)  11.316 ms  11.852 ms  11.013 ms
 4  172.18.241.233 (172.18.241.233)  18.389 ms  20.019 ms  12.239 ms
 5  bundle-ether10.cha47.brisbane.telstra.net (110.142.226.9)  11.029 ms  20.417 ms  14.928 ms
 6  bundle-ether4.cha-core4.brisbane.telstra.net (203.50.11.50)  14.024 ms  12.597 ms  10.770 ms
 7  bundle-ether11.ken-core4.sydney.telstra.net (203.50.11.72)  29.272 ms  31.592 ms  31.945 ms
 8  bundle-ether1.pad-gw2.sydney.telstra.net (203.50.6.29)  29.031 ms  25.258 ms  28.488 ms
 9  203.50.13.118 (203.50.13.118)  27.540 ms  28.856 ms  28.286 ms
10  i-0-4-0-5.paix-core01.bx.telstraglobal.net (202.84.143.157)  174.643 ms  i-0-3-0-6.paix-core01.bx.telstraglobal.net (202.84.140.194)  178.515 ms  i-0-3-0-4.paix-core01.bx.telstraglobal.net (202.84.140.157)  173.279 ms
11  i-0-3-0-7.eqnx-core01.bi.telstraglobal.net (202.40.149.62)  165.214 ms  i-0-2-0-7.eqnx-core01.bi.telstraglobal.net (202.40.149.38)  164.852 ms  i-0-3-0-7.eqnx-core01.bi.telstraglobal.net (202.40.149.62)  168.586 ms
12  i-0-0-0-1.eqnx03.bi.telstraglobal.net (202.84.251.50)  164.727 ms  i-0-4-0-0.eqnx03.bi.telstraglobal.net (202.84.251.66)  163.912 ms  i-0-0-0-0.eqnx03.bi.telstraglobal.net (202.84.251.85)  165.340 ms
13  l3-peer.eqnx03.pr.telstraglobal.net (134.159.62.198)  196.150 ms  163.305 ms  l3-peer.eqnx03.pr.telstraglobal.net (134.159.61.6)  164.072 ms
14  vlan60.csw1.SanJose1.Level3.net (4.69.152.62)  243.079 ms  243.081 ms  vlan90.csw4.SanJose1.Level3.net (4.69.152.254)  244.171 ms
15  ae-82-82.ebr2.SanJose1.Level3.net (4.69.153.25)  243.506 ms  ae-91-91.ebr1.SanJose1.Level3.net (4.69.153.13)  250.714 ms  257.131 ms
16  ae-5-5.ebr1.SanJose5.Level3.net (4.69.148.137)  252.466 ms  258.331 ms  250.944 ms
17  ae-1-100.ebr2.SanJose5.Level3.net (4.69.148.110)  243.208 ms  242.735 ms  241.824 ms
18  ae-6-6.ebr2.LosAngeles1.Level3.net (4.69.148.201)  244.142 ms  245.066 ms  ae-3-3.ebr3.Dallas1.Level3.net (4.69.132.78)  242.637 ms
19  ae-63-63.csw1.Dallas1.Level3.net (4.69.151.133)  252.477 ms  ae-3-3.ebr3.Dallas1.Level3.net (4.69.132.78)  243.761 ms  ae-73-73.csw2.Dallas1.Level3.net (4.69.151.145)  243.398 ms
20  ae-71-71.ebr1.Dallas1.Level3.net (4.69.151.138)  254.422 ms  ae-91-91.ebr1.Dallas1.Level3.net (4.69.151.162)  243.317 ms  ae-93-93.csw4.Dallas1.Level3.net (4.69.151.169)  246.792 ms
21  ae-1-13.bar1.Houston1.Level3.net (4.69.137.137)  250.885 ms  253.349 ms  252.243 ms
22  ae-1-13.bar1.Houston1.Level3.net (4.69.137.137)  251.499 ms  250.313 ms  ae-5-5.car1.Houston1.Level3.net (4.69.132.229)  241.042 ms
23  ae-5-5.car1.Houston1.Level3.net (4.69.132.229)  240.677 ms  240.822 ms  NUGGET-ENTE.car1.Houston1.Level3.net (4.28.35.134)  213.543 ms
24  *  NUGGET-ENTE.car1.Houston1.Level3.net (4.28.35.134)  214.036 ms  *
25  *  *  *
26  *  *  *
27  *  *  *
28  *  *  *
29  *  *  *
30  *  *  *

Times out after 30 hops. See http://en.wikipedia.org/wiki/Traceroute

It's like walking.. every step I take I either leave a tiny bit of my DNA or my shoe behind.. same on the net. I went through no less than 24 servers (yes my router is a "server") to get to icanhazip.com, my IP will be recorded in each one of those server logs. These are facts. Don't want to leave footprints? Don't walk!

greengeek · #79 Post by **greengeek** » Mon 13 Jan 2014, 02:23

In a 'standard' home or small office setting with the commonly available DSL routers - at what point do I actually get allocated an external IP address?

- at the same time as I request a DHCP lease for a local IP address?

or:

- the first time I try to send a data packet across the internet?? (which could be hours, days or even weeks after my initial DHCP request to the local router)

01micko · #80 Post by **01micko** » Mon 13 Jan 2014, 02:45

greengeek

Your computer, if part of a LAN, never gets assigned an external IP. It only gets a LAN IP from the router. The router actually gets the external IP. Your computer uses something called Network Address Translation (NAT) to communicate with the internet through that external IP >> It's a deficiency of IPv4. What happens is that your internal IP, lets say it's 10.10.0.5, gets translated to the external IP. Otherwise the returning packets would not know where to go.. they are never going to find 10.10.0.5 it it's behind a router (gateway). So it finds your external IP and in the header of the packet is info which enables NAT to convert the IP back to your internal IP. I could write an essay about it but no, just look up any decent wiki on networking, computerhope maybe?

HTH

mavrothal · #81 Post by **mavrothal** » Mon 13 Jan 2014, 06:48

anikin wrote:Mavrothal, for some reason wants you to see only established connections, let's ignore his command and use our own.

Once more you spread FUD.
The command was to see is your PC was connected to something as discussed at the time

anikin wrote:Not a single program is running on this machine, I didn't click the network icon, and yet the connection is there. Mavrothal will say it is harmless, it is closing. Yes, it is harmless in that sense. All that's happened is you have been tracked.

More FUD.
I run 8-10 puppies in virtual machines. Monitoring constantly the out going connection from the host, not puppy, I can see all the connections even before puppy boots. The only time that they connect is when ipinfo runs.

BTW, use "ps" to show us what is running on your machine when you see the connection in netstat.

Code: Select all

ps > connect.log;netstat -a >> connect.log

Finally, provide a shred of evidence that the user initiated connection to icanhazip.com consist tracking or stop spreading FUD about it.

jamesbond · #82 Post by **jamesbond** » Mon 13 Jan 2014, 08:53

This thread is very educational

But to get to the point: just delete /usr/local/firewallstate/ipwget and you won't get that pesky connection on every boot anymore. Deal?

anikin · #83 Post by **anikin** » Mon 13 Jan 2014, 09:01

Finally, provide a shred of evidence that the user initiated connection to icanhazip.com consist tracking or stop spreading FUD about it.

I don't have even a shred of evidence that icanhazip is into tracking, the same as you have as much evidence, that it isn't. Potentially, it's logs can be used for tracking, as they have time and addresses, you know it better than me. Let me repeat once again, it can be any address that you impose on the user. Remove icanhazip.com, put in anikin.com instead - and I will oppose to that. This is not a feature, that Puppy users are desperately craving for. There's a reason why Slackware, Debian and even Windows XP do not have it. Because it is fishy. Here's a scenario where it can be even worse than useless. An unsuspecting Puppy user, who thinks, that Tor will anonymize his address, which perhaps it will for the browser, goes and checks his IP through your newly offered script. Now he will have revealed his true address to anikin.com. Anikin will sell that address first to Google, then will make a business offer to a more serious organization ... or, maybe not - that organization can't keep it's own secrets. Get it out - completely and let's stop waisting time on it. Regarding FUD - it is a bad thing in my book - I will never do it knowingly. You guys are defending what is indefensible ... and getting needlessly confrontational.

mavrothal · #84 Post by **mavrothal** » Mon 13 Jan 2014, 10:19

anikin wrote:
Finally, provide a shred of evidence that the user initiated connection to icanhazip.com consist tracking or stop spreading FUD about it.
I don't have even a shred of evidence that icanhazip is into tracking, the same as you have as much evidence, that it isn't.

If I state that "you are from another planet", something that neither I can prove is true nor you that is not, who has the responsibility to prove their thesis? Me that "accused" you or you?...

Accusing (which you clearly do) without a shred of evidence (as you stated) is the exact definition of FUD

01micko · #85 Post by **01micko** » Mon 13 Jan 2014, 12:30

jamesbond wrote:This thread is very e|n|d|t|u|e|c|r|a|t|t|a|i|i|o|n|n|i|a|n|l|g

anikin · #86 Post by **anikin** » Mon 13 Jan 2014, 15:30

jamesbond wrote:This thread is very educational

I understand your irony on the educational part. What you'd expect from noobs. The pesky connection is built to the highest standards of reliability - the files are spread across the system in at least 3 different folders. If one fails, there are 2 more to keep the connection alive and the customers happy.

mavrothal wrote:Accusing (which you clearly do) without a shred of evidence (as you stated) is the exact definition of FUD

I can't see how being opposed to a "feature" can qualify as accusation. I even offered anikin.com as a gesture of good will ...
Can we already start discussing practical steps? How long will it take to completely clean up Woof CE and straighten out Puppy's startup?

mavrothal · #87 Post by **mavrothal** » Mon 13 Jan 2014, 15:39

anikin wrote: How long will it take to ... Woof CE

woof-CE is public. Provide a patch.

anikin · #88 Post by **anikin** » Mon 13 Jan 2014, 16:45

I can only offer a concept:
The most important one - get rid of xorgwizard, together with all of it's scripts. I'm not a coder, but I can see a huge difference between init scripts/routines in Puppy and other distros. Just reading the comments in the scripts, some of which go back to 2004 will make one cringe. Please, have a look at how other distros start! Iguleder mentioned, he built a super fast init the other day - can it be moddded to work in Puppy? If a Puppy detractor (I don't want to mention his name here), using Barry's own scripts built a startup routine for his OS, which is far superior to the original - why you guys can't pool your collective effort and do the same? The real problem isn't the pesky connection - the problem is Puppy loosing ground to the competition and the community is loosing interest in it.

jamesbond · #89 Post by **jamesbond** » Mon 13 Jan 2014, 17:04

anikin wrote:I understand your irony on the educational part. What you'd expect from noobs.

Please, conveying irony is very far from my intention. I do learn a lot from this thread, I do learn a lot from noobs, and lastly we were all noobs once.

The pesky connection is built to the highest standards of reliability.

The files are spread across the system in at least 3 different folders. If one fails, there are 2 more to keep the connection alive and the customers happy.

Jokes aside, I would say that malice was never the intention. Security (and to a degree privacy) is always a trade-off (with functionality, with convenience, etc); and everyone has different ideas on where the dividing line should be. See for example: http://murga-linux.com/puppy/viewtopic. ... 815#534815 - would you want to keep track of your external IP address movement, *at the price of contacting icanhazip several times a day*? I don't think so, but others think differently (=ie no big deal for them).

That being said - the 3 different ways of connection comes from 3 different packages. ipinfo is from Woof (Barry); ipwget is from firewallstate (tasmod); and ifactive comes from Pup-Info (radky). Some puppies have all these three, and some gets two, some only has one (ipinfo). So no, they don't come from the same source or collude to hide their tracks in 3 different programs.

The one that concerns the most ("calling-icanhazip-at-boot") comes from firewallstate. While I don't know how firewallstate is designed (doesn't have the source with me), I would bet that it is more of an oversight rather than on purpose: tasmod explicitly mentioned the exact script that gets the external IP address for use by firewallstate in his response here: http://murga-linux.com/puppy/viewtopic. ... 460#535460; something that he wouldn't have done if he has less than honourable intention.

I believe Mick has addressed all of these 3; and this matter should be put to rest. As I said earlier, you can eliminate the "calling-icanhazip-at-boot" by deleting /usr/local/firewallstate/ipwget until a more permanent fix is released.

One last note for the technically curious: it is nearly impossible to reliably determine what is your external IP address to the world, other than actually *contacting* a site of some sort (as Mick has explained earlier).

greengeek · #90 Post by **greengeek** » Mon 13 Jan 2014, 18:22

jamesbond wrote:I believe Mick has addressed all of these 3; and this matter should be put to rest. As I said earlier, you can eliminate the "calling-icanhazip-at-boot" by deleting /usr/local/firewallstate/ipwget until a more permanent fix is released. .

Thanks for the information in this post jamesbond. I am certainly finding this thread informative and helpful. I can't say what should or should not be in woof-CE but I am certainly appreciative of the opportunity to make these changes to my own systems to stop puppy lifting it's head 'above the parapets' till I am ready for it to do so.

01micko wrote:Your computer, if part of a LAN, never gets assigned an external IP. It only gets a LAN IP from the router. The router actually gets the external IP.

So does this mean that the router requests an external IP when it is first turned on and comes ready? Or is that request occurring only when a LAN device makes the first DHCP request?

mavrothal · #91 Post by **mavrothal** » Mon 13 Jan 2014, 18:42

jamesbond wrote: The one that concerns the most ("calling-icanhazip-at-boot") comes from firewallstate.

I never run firewallstate, but removing the call from the source (found here) is pretty simple and from what I can see it is only used in the "information" window.
Firewallstate appears to work OK like that but Is there any other use that I missed (ISip and isip are the relevant points)

Code: Select all

--- firewallstate-2.0.c.orig	2011-09-27 18:46:07.000000000 +0300
+++ firewallstate-2.0.c	2014-01-13 21:01:07.360113765 +0200
@@ -24,7 +24,6 @@
 void shownet_window(GtkWidget *w, gpointer dummy);
 void show_hide_window(void);
 void timdat_window(GtkWidget *w, gpointer dummy);
-void ISip ();
 void NETip();
 void psync_window(GtkWidget *w, gpointer dummy);
 
@@ -35,7 +34,6 @@
 char pupname1[6]="Puppy";
 char keyvers[6];
 char langvers[6];
-char ipis[16];
 char netis[30];
 char tzis[25];
 
@@ -127,13 +125,6 @@
     pclose(fp);
 		}
 
-		{  /* Get your IP address from created tmp file ipis.txt*/
-
-   fp = (FILE *)popen("cat /tmp/ipis.txt |  awk '{print $1}'  " , "r" );
-    fgets(ipis,sizeof ipis,fp);
-    pclose(fp);   
-		}
-  
 		{ /* Get your network from created tmp file ifstuff.txt */
 
    fp = (FILE *)popen("cat /tmp/ifstuff.txt |  grep 'addr:'  | head -n1 | cut -d ':'  -f2  |  awk '{print $1}'  " , "r" );
@@ -155,11 +146,6 @@
     system("/usr/local/firewallgtk/firewallgtk &");
 }
 
- ////////////////////////////////////////////////// Runs External IP script routine
-void   ISip (){
-  system("/usr/local/firewallstate/ipwget");
-}
-
 ////////////////////////////////////////////////// Runs Net IP script
 void NETip()  {
   system("/sbin/ifconfig  > /tmp/ifstuff.txt 2>&1");
@@ -196,7 +182,7 @@
 	
 	GtkWidget *window, *widget, *vbox, *frame, *box ;
 	char temp[50] , istemp1[30], istemp2[30],  istemp3[30], 
-	ipistemp[50], keytemp[25], langtemp[30] , nettemp[50],
+	keytemp[25], langtemp[30] , nettemp[50],
 	tztemp[50];
 
 	    window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
@@ -224,9 +210,6 @@
 	    gtk_box_pack_start(GTK_BOX(box), widget, FALSE, FALSE, 3);	
 	    g_snprintf(istemp1, sizeof(istemp1), "", puppyversion);
 	    widget = gtk_label_new(istemp1);
-			gtk_box_pack_start(GTK_BOX(box), widget, FALSE, FALSE, 3);	
-			g_snprintf(ipistemp, sizeof(ipistemp), "Your external IP is  %s", ipis);
-			widget = gtk_label_new(ipistemp);   	
 	    gtk_box_pack_start(GTK_BOX(box), widget, FALSE, FALSE, 3);	
 	    g_snprintf(nettemp, sizeof(nettemp), "PC network address %s", netis);
 	    widget = gtk_label_new(nettemp);   	
@@ -332,8 +315,6 @@
 
 		gtk_init(&argc, &argv);
 		 
-		ISip(NULL);
-		
 		NETip(NULL);
 		
 		Info(NULL);

jamesbond · #92 Post by **jamesbond** » Mon 13 Jan 2014, 18:57

greengeek wrote:
01micko wrote:Your computer, if part of a LAN, never gets assigned an external IP. It only gets a LAN IP from the router. The router actually gets the external IP.
So does this mean that the router requests an external IP when it is first turned on and comes ready? Or is that request occurring only when a LAN device makes the first DHCP request?

It will request an external IP address as soon as it gets connected to your ISP. If your router is configured as "always on" (which is almost always the case), this will happen immediately upon power-up. If it is configured as "on-demand" (rarely these days), it will do so when your computer try to connect to the Internet.

mavrothal wrote:I never run firewallstate,

The problem is firewallstate is auto-started in recent puppies that have it - so it's not a choice.

but removing the call from the source (found here) is pretty simple and from what I can see it is only used in the "information" window.
Firewallstate appears to work OK like that but Is there any other use that I missed (ISip and isip are the relevant points)

Thanks for pointing the source. I haven't tested it myself but it looks like you're doing it right.

Atle · #93 Post by **Atle** » Mon 13 Jan 2014, 20:59

So if I understand this right...

When i boot a modern Puppy and uses Ethernet, it will "just say hello" to icanzip? No matter if i like it or not?

And this happens several times everyday i use a modern Puppy?

01micko · #94 Post by **01micko** » Mon 13 Jan 2014, 21:09

http://distro.ibiblio.org/puppylinux/so ... .5.tar.bz2

Latest sources for firewallstate, complete with legal bits.

mavrothal · #95 Post by **mavrothal** » Mon 13 Jan 2014, 22:40

jamesbond wrote:
mavrothal wrote:I never run firewallstate,
The problem is firewallstate is auto-started in recent puppies that have it - so it's not a choice.

I believe is configurable in recent puppies and in older ones just removed from Startup folder (actually set permission to 000)
Quite frankly linux firewall is more useful psychological than practical (unless you start opening ports).

01micko wrote:Latest sources for firewallstate

Looks more quite

Will be fun if puppy users start complaining for the lost functionality

(old)Puppy Linux Discussion Forum

(old)Puppy Linux Discussion Forum

Why is this strange IP address in Network connections?