Unsolicited web traffic

asked 2017-08-17 22:50:56 +0200

iourine gravatar image

Sailfish 2.1.0.11 does generate some incorrect traffic by itself without any obvious need. Not only this makes one anxious about privacy but leads to money losses. E.g., my mobile operator charges me a fixed rate per day if I use Internet on that day, no matter how much traffic I consumed. If I do not use Internet at all but forget to switch off mobile data, the phone goes online by itself, for some unclear reason, and the daily fee is charged.

All the obvious Internet services are disabled, of course. (NTP, update checks, Android first of all.) No applications are running. (Browser, maps, and whatever could require Internet access.) The traffic is present on the LTE interface, however.

At least one of the sources is definitely the Sailfish ifself. What I have logged is repeating attempts of TCP connections to 172.28.202.155 and 172.28.202.147, ports 8680 and 8684 (maybe some similar ones, if logged for longer time)

[195517.324652] IN= OUT=rmnet0 SRC=10.87.140.41 DST=172.28.202.155 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=58191 DF PROTO=TCP SPT=32848 DPT=8680 WINDOW=0 RES=0x00 RST URGP=0

another log, after reboot with all possible services disabled:

[root@Sailfish nemo]# dmesg |grep 172.28.
[  668.864642] IN= OUT=rmnet0 SRC=10.118.114.230 DST=172.28.202.147 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=10910 DF PROTO=TCP SPT=41909 DPT=8680 WINDOW=0 RES=0x00 RST URGP=0 
[  669.321593] IN= OUT=rmnet0 SRC=10.118.114.230 DST=172.28.202.147 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=10953 DF PROTO=TCP SPT=41909 DPT=8680 WINDOW=0 RES=0x00 RST URGP=0 
[  669.879108] IN= OUT=rmnet0 SRC=10.118.114.230 DST=172.28.202.147 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=10977 DF PROTO=TCP SPT=41908 DPT=8680 WINDOW=0 RES=0x00 RST URGP=0 
[  670.341492] IN= OUT=rmnet0 SRC=10.118.114.230 DST=172.28.202.147 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=11018 DF PROTO=TCP SPT=41908 DPT=8680 WINDOW=0 RES=0x00 RST URGP=0 
[  840.330901] IN= OUT=rmnet0 SRC=10.118.114.230 DST=172.28.202.147 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=19224 DF PROTO=TCP SPT=57138 DPT=8684 WINDOW=0 RES=0x00 RST URGP=0 
[  840.781596] IN= OUT=rmnet0 SRC=10.118.114.230 DST=172.28.202.147 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=19240 DF PROTO=TCP SPT=57138 DPT=8684 WINDOW=0 RES=0x00 RST URGP=0 
[ 1155.231588] IN= OUT=rmnet0 SRC=10.118.114.230 DST=172.28.202.147 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=47884 DF PROTO=TCP SPT=57156 DPT=8684 WINDOW=0 RES=0x00 RST URGP=0 
[ 1155.691622] IN= OUT=rmnet0 SRC=10.118.114.230 DST=172.28.202.147 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=47906 DF PROTO=TCP SPT=57156 DPT=8684 WINDOW=0 RES=0x00 RST URGP=0 
[ 3411.998626] IN= OUT=rmnet0 SRC=10.118.114.230 DST=172.28.202.147 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=57903 DF PROTO=TCP SPT=51174 DPT=8680 WINDOW=0 RES=0x00 RST URGP=0

What the #### is it? Not to say that 172.16.0.0/12 addresses are not eligible in public networks. Would Jolla developers explain this traffic?

Another big source of unwanted traffic is Android support. Once started, it immediately generates a lot of HTTP and HTTPS connections to Google, Amazon networks and various hosting providers throughout the world - with no Android apps being started yet. Actually I have only a few apps (Firefox, some Yandex services, and some others), yet there is already a malware among them or, probably, in the Android support itself. Surely this is to be explored in more details, step by step - but not at the moment.

To be continued...

edit retag flag offensive close delete

Comments

2

As you note, the address belongs to private network which means it is not routable; hence it should not leak any information. (for example Docker uses IP address in range 172.x.x.x on the internal bridge to communicate with host)

What's in your routing table?

If those packets are actually leaving your device then there is some misconfiguration of networking. Or it might be your operator's internal thing, maybe some sim application?

Is the traffic always directed towards your rmnet0 interface? What happens if you don't have simcard in the device, does the traffic stop or does it then exit via wlan interface?

Have you tried to capture the traffic to see what's actually contained in the packets?

juiceme ( 2017-08-18 08:20:50 +0200 )edit
1

Well, to begin with, my current problem is not the privacy but the fact that a single unsolicited packet from my phone results in charging me for Internet usage on that day.

There is nothing special in the routing table: the default route to rmnet0, plus all the interface-specific routes. The only unusual thing is the two explicit routes to the provider's DNSes/32, also via rmnet0. Apparently they are really added by the provider's app on the SIM card.

Currently I cannot make extensive tests as I am on the go and LTE is my only Internet connection. As soon as I return to my laboratory conditions, I'll definitely examine all the possible combinations of active interfaces, SIM cards, and installed software. But not now.

As of now, during one day of monitoring, I've caught a lot of packets of the 3 types:

  1. To 172.28.202.something:8680. This is really unclear but, at least, can be easily filtered.

  2. HTTP/HTTPS connections to literally tens of real addresses - I gave up, there is no sense listing them all and adding filter to every of these networks. As soon as I come home, I'll have to reset my phone and the test the bare Sailfish, SF+native apps, SF+bare libhybris, SF+Android apps added one by one. Hope to figure out which of them are in fault.

  3. To my provider's network. Apparently this is due to his particular SIM card, as well as the 2 additional routes mentioned above. Hopefully all this traffic is not charged (at least, part of it is definitely not).

Is there a binary of tcpdump or whatever else available for SF? Currently I'm just logging packets with iptables ... -j LOG

iourine ( 2017-08-18 23:12:00 +0200 )edit

Well, as a temporary workaround if you just want to stop all of it when you don't use the network you could add iptables rule to drop all outgoing packets. It's not optimal but might help.

You can install tcpdump right off repos with pkcon.

juiceme ( 2017-08-19 00:23:23 +0200 )edit

thnx for tcpdump...

To continue: allowed 172.28.x.x traffic and caught something. Appears like a "forest corpsman" does exist in the network and is scanning my ports for some vulnerable ones. This kind of traffic looks pretty unlikely to have something with Jolla. (Hopefully it is a mere coincidence that it is close to 172.28.172.0/24 used by Jolla itself for its WLAN clients.) Input filter would help to some degree, of course, but it is still unclear whether the provider charges this incoming traffic or not...

How to capture a full binary log on Jolla? Plain tcpdump -w /tmp/mypoopylog.cap creates a zero-length file, but in a short time Jolla complains that it is running out of memory. If I try to write the capture to my home dir or SD card, tcpdump terminates immediately saying "mypoopylog.cap: Permission denied" - even though I run it as root!

iourine ( 2017-08-19 11:28:44 +0200 )edit

I agree with you that this looks like connection attempts from the outside (another client) which your phone answers with simple "RST" packages. This is the default behaviour for closed ports. Given the amount of requests on the same port, I'd suspect this to be some kind of service discovery maybe!? If you capture the requests as well, you could check to see if they are being send via broadcast (which would points towards service discovery).

Anyway, I'd get in touch with your provider about that issue. Either there is a network misconfiguration (like improper client isolation) or maybe these "services" belong to their network. Either way, they can tell you if these packages are counted toward you mobile traffic. If you don't want to contact them (seeing how difficult it can be to get in contact with someone who understand your inquiry), you can simply configure iptables to drop packages on this port (or change the INPUT default policy to DROP).

ghling ( 2017-08-20 10:04:33 +0200 )edit