Network Trojan Present

There are no trojans in Variety of any kind, and its code is fully open so anyone is free to audit it.

This IP belongs to tiny.cc which is a URL shortening service and which subsequently is used by all kinds of people for pointing to all kinds of things, thus its normal that "bad" things could be hosted there, just as they can be on any platform with user-submitted content, hence it's no surprise the IP is in AbuseIPDB.

Variety specifically hits the URL "http://tiny.cc/variety-options-063", which redirects to a Github-hosted settings file (https://gist.githubusercontent.com/peterlevi/a7d1dbf3a4e76e15760a/raw/5ba8d1a48ba96f81bb06cd7660cc2061a41248ea/variety_server_options.json), which controls the rate at which Variety is allowed to fetch new images from the various image sources. You can safely open the URL in a browser and see for yourself the contents of that settings file. The reason we use tiny.cc to redirect is that we need to update the file form time to time and Github up until recently did not provide a permalink to the latest version of the file.

More on why Variety needs these options can be read here: https://github.com/varietywalls/variety/issues/198

In the meantime I'll check if we can somehow change the URL which Variety uses to be directly to Github instead of using the tiny.cc redirection.

Btw, you mention vrty.org which has no longer been part of Variety for 1-2 years, so you are probably running an old version. But the current one still fetches those external options.

Aah, and another reason we use tiny.cc instead of GitHub directly is because this way we get aggregated statistics for how many people actually run Variety daily, which is important for keeping our API usage for Unsplash and Flickr in check.

Thank you Peter for your answer. I feel better now that these alerts I get can be explained.

Currently I’m dropping these packets, can you please tell me what limitations this would introduce into variety?

I didn’t realise that the version of variety picked up from the standard app repositories weren’t the latest, so I’ve updated my version to the latest using the instructions from your website.

With the increasingly wider use of routers containing deep packet inspectors, do you think that it is possible to look at a method to achieve what you want without using techniques which are considered a high risk threat to these detectors?

Thanks

What is the brand and model?

There is really nothing "suspicious" about the technique itself so I can't think of any other reason the router will flag it apart from it being a connection to tiny.cc.If you open http://tiny.cc/variety-options-063 in a browser or curl it, does the router still complain?

If this becomes a common complaint, I'll think about removing the dependency on tiny.cc. However I doubt this will be an issue soon, because I hope most routers out there have a saner deep packet inspection that does not blindly blacklist IPs.

You aren't losing anything significant, except that your instance of Variety will not be throttled the same way as everyone else's. As long as the majority of Variety instances out there adhere to the throttling rules, we are "collectively" fine.

Hi, I taped on that link from my phone and my router wouldn’t allow me to access that website and I got notification email from the router telling me an attempt was made to access a high risk IP address.
Just to say that the decision as to whether a particular website is allowed to be accessed through my router isn’t a dependency set by the manufacturer of the router, it’s set by google and IBM and they have entered this server as high risk in their Threat Protection databases.

Thank you for a great app, but I’ll continue to use it without overruling my router.

Kind regards
Neil

Thinking about how threat protection works, it’s not the use of tiny.cc that is the problem, I don’t have any trouble with using twitter etc that use tiny.cc. The issue is the IP address:- 192.241.240.89
 To prove the point I put 192.241.240.89 in the url of my phones browser and the router rejected the connection.

I hope this helps.

Neil

Hm, but that is an IP of tiny.cc, maybe not the only one, but if you put it in a browser, you'll get redirected to tiny.cc's homepage.
We don't have that IP hardcoded, the URL is uses the hostname (tiny.cc) - "http://tiny.cc/variety-options-063".

The router is a Synology rt2600ac, darn good for 200 money tokens.

I’ve just tried the https GitHub url you gave above and I can load that fine. So the problem isn’t where your configuration file is, but the route how users gain access to it.

  I’m rapidly getting out of my depth now. So it seems that the non http (non http is a bit scary) url is being redirected to somewhere other than your github file first. I’d guess this redirection is the problem to this non https server somewhere, may be its being hijacked without your knowledge?

I now feel worried again about allowing these packets through, so I’m going to continue to drop these packets.

I’m sure you will come up with a solution, please let me know when you do. I have an interest in cyber security.

There seems to be a lot of scaremongering in this post and the firewall output to begin with. If you had read the message carefully, you would know that the policy being logged relates to a URL Shortener Service. As Peter mentioned, these are not nefarious by nature and are only being flagged because user generated content has a *potential* of causing abuse.

The reason you're getting a filter on 'tls' is because tiny.cc redirects to HTTPS (which is HTTP backed by TLS encryption). This isn't anything to be alarmed by since this sort of redirection is very commonplace these days.

This is what the redirect path looks like as of writing:

$ ./h.py http://tiny.cc/variety-options-063
301 Moved Permanently: http://tiny.cc/variety-options-063 => https://tiny.cc/variety-options-063
303 See Other: https://tiny.cc/variety-options-063 => https://gist.githubusercontent.com/peterlevi/a7d1dbf3a4e76e15760a/raw/5ba8d1a48ba96f81bb06cd7660cc2061a41248ea/variety_server_options.json
200 OK: https://gist.githubusercontent.com/peterlevi/a7d1dbf3a4e76e15760a/raw/5ba8d1a48ba96f81bb06cd7660cc2061a41248ea/variety_server_options.json

James, I think that you missed some of the thread where I said that the use of tiny.cc is frequently used by Twitter and lots of other sites. I never before had any trouble using tiny.cc so the problem isn’t using tiny.cc facility.
However, putting 192.241.240.89 in my browser’s url from any device on my network results in an alert and the packet bring dropped. This is nothing to do with http/https conversions.

Twitter's URL shortener is t.co, a completely different domain: https://help.twitter.com/en/using-twitter/url-shortener ...

There's nothing special about 192.241.240.89 other than the fact that it *is* the server behind tiny.cc. So your network filter is blocking tiny.cc right now, simple as that.

$ host tiny.cc
tiny.cc has address 192.241.240.89
tiny.cc mail is handled by 15 eforward4.registrar-servers.com.
tiny.cc mail is handled by 20 eforward5.registrar-servers.com.
tiny.cc mail is handled by 10 eforward1.registrar-servers.com.
tiny.cc mail is handled by 10 eforward2.registrar-servers.com.
tiny.cc mail is handled by 10 eforward3.registrar-servers.com.

We've explained the rationale for server options fetching in this issue and at https://github.com/varietywalls/variety/issues/198

Thank you for your observation about Twitter using a different server, that would explain why I can access links from Twitter. I’ve read the links you have given me, all interesting and I’m still struggling to properly understand the mechanism you are using to slow down downloads. Obviously my knowledge is rudimentry and I hope that you will excuse me for suggesting the following. The first is to put your latest version of variety on the Ubuntu package servers. I had no idea that I wasn’t using your latest version, naturally I assume that if an app can be downloaded with the use of the Software Manager, that updates will be automatic which is essential these days due to security vulnerabilities being spotted and fixed and they need to be deployed immediately. Manually going to your site every xxxx days is, well, I’m not going to remember.
Then if you were to put the downloading throttling in your app you then won’t need redirection services, I think that’s what you are telling me but I still don’t understand how that helps. Just a general comment, redirection services are an ideal target for being taken over by the bad guys, may be that’s why Mr. Google and Mr. IBM have rated this server as high risk, may be there was an incident. I’m not going to argue with them about how much of a risk this tiny.cc server is, they say it’s high risk, I’m happy to be in their hands and I’m relying on them to get it right.
Anyway, Variety is a really good app, I like it a lot, I think you both have done a really good job and it gives a lot of pleasure to all your users. So well done and please keep on doing it.