I think so too. Aside from 18.104.22.168, which belongs to ColoCrossing (non-ISP; colocation, hosting and cloud service), all of those IPs seem to be actual legit human endpoints belonging to actual ISPs (broadband providers, etc), so you’re correct there; adding them to the CIDRAM signature files wouldn’t be desirable, unfortunately. :-/
Shortly after posting my above reply, I also ran some tests with this service against a dummy server that I control, to see what type of IPs and UAs I’d end up seeing hit the server, with basically very similar results (mostly all human endpoints, not really viable for adding to the signature files). All the UAs belonged to real browsers too, so blocking the UAs wouldn’t be viable either, due to the massive number of false positives we’d end up seeing by way of accidentally blocked browsers and so on.
The one (and AFAIK at this point, the only) possibly reliable indicator we could use though is the referrer. The referrer of almost every request during testing seemed to all point back to the trafers homepage, so that’s something we could use (one or two didn’t, I think, due to coming from weird browsers without referrers and so on, but generally, most of them included the same referrer pointing back to trafers), so, as you’ve mentioned, I think blocking the referrer is probably the best solution here in this case.
Of course, if anyone is able to block that referrer at the server-level as well, that would be perfect, as to reduce the stress on PHP, on websites, on bandwidth and so on (due to that DDoS-level traffic is likely to cause quite a bit of stress for PHP, for websites, for bandwidth and so on regardless, even if blocked at PHP-level).
Oh well. In any case, thanks @hariharakumar for sharing the IPs. It definitely helps to be able to get a better idea of the exact nature of the type of traffic seen as a result of this service.
As a side-note to anyone thinking about using this service: During my testing, I received a number of concerning alerts from my anti-virus software due to the nature of some the sites that this service would try to direct my own browser to, starting almost immediately from the beginning of testing, through until the end of it. Aside from the risks inherent in randomly accessing unknown websites in quick succession like that anyhow, based on what I saw during testing, I think it’s quite possible that malevolent actors are intentionally using this service to attempt to spread malware to potential victims. As such, I would highly recommend avoiding it.