WebPagetest Forums

What improvements have been made to the security used
for public instances?

At least one public instance has had a trojan dropper
installed. For the curious, look for the service "syshost32"
and a windows firewall rule "core networking - ip stack".
The rirewall rule allows any protocol, on any port and any
address. Translation: wide open.

The result will be lots of UDP traffic, presumably to
command and control centres.

The requirement that webpagetest agents run with admin
permissions and wide open browsers settings is no doubt
a huge security threat to the machine and the network it
sits on.

Less damaging, but still annoying is seeing the machine
being abused by rapid fire "tests" which are nothing more
than a means of driving up page views for small time
web sites showing banners and youtube videos.

So what can be done to secure a public instance to avoid
a repeat performance?

+++

There's not really a lot you can do if you want to support older versions of IE (insecure by definition) and being able to drop a trojan doesn't require admin access. It's also why the first line in the docs for hosting a public instances is "EXPECT TO BE HACKED!".

Direct compromise shouldn't be possible since the machines require no inbound access and all traffic can be firewalled. Hacks will typically be a result of browsing malware pages (or ads).

There are things that can be done to help mitigate the issue but no way to completely prevent it given that by design we are browsing to any arbitrary page that users want us to visit. Some mitigations include:

- Public server blocks testing of URLs flagged by Google's safe browsing API
- Can run a lightweight antivirus on the test agent (Microsoft's tends to be the best as far as impact on systm resources, I wouldn't recommend Norton, McAffee, AVG, Avast or any of the others that border on malware themselves)
- Can run the agent as a stateless VM and reset state periodically (nightly?). That would also reverse security updates though
- Only support the latest browser (IE 11, Firefox, Chrome)

If you know of specific agents with issues then please let me know and I can work with the partner running the location to re-image the test machine.

As far as rapid-fire tests go, that should independent of the agents themselves as tests can only come through the central server. I maintain a blacklist of IP's and URLs that testing is blocked for because of abuse so usually they will only get a one-time benefit of a few page views before they are blocked from testing. It does happen but not all that often. At one point I had experimented with automatic rate limiting but that blocks a lot of valid use cases so it's a manual process right now.