Router compromised?

I mentioned some time ago that I set up an obsolete laptop as a router/firewall using IPFire...

Well, part of the setup is a transparent proxy, which I use to filter ads. And lately, it's been blocking entire pages that shouldn't qualify as ads. For instance:



Note how the URL in the browser toolbar is different from the one supposedly being blocked...

I would have figured this was a quirk of the filtering proxy, erroneously blocking a whole page due to embedded ad content. But I've also noticed that this sometimes happens when I go to sites with no ad content - this forum for instance. Sometimes I enter a definitely ad-free URL into the toolbar, hit return, and am greeted with the Access Denied page; and the page I wanted only becomes accessible if I hit the refresh button.

This happens on all my computers, bar none; and apparently with all browsers. It happens more often with some browsers than with others (e.g. much more with IE than with Firefox) but if I browse, I eventually encounter it.

The router logs and settings don't look abnormal; but then, if it were hacked, they probably woudn't.

So what does this sound like? A bug in the filtering proxy? Or something more nefarious?

 

Seems like a bug, what do the logs say? Post some log action!

 

Nothing in the logs but the usual barrage of hostile connection attempts from all over the world.

Edit: for the sake of experimentation, I tried setting one of my computers to use Google DNS. If anything that made the problem worse.

 

Hmmmmm, do you have UnUp enabled on your router?

 

Sounds like a misconfiguration.
Probably filehippo has google ads and that's what gets filtered.
Mrk

 

I'm not familiar with IPFire, but a quick look at its wiki suggests it has numerous configuration and logging features. Since *outbound* filtering is involved, you'd want good information about that. If there is any way to increase the info shown on the Access Denied page... displaying Referer, an internally maintained request ID and/or timestamp that would help you find nearby events in a logfile, etc... you might do that. In general it isn't uncommon for outbound logs to be turned down because there will be so much traffic that is normally not of interest. In this case you may want to turn them up so that you can see both filtered and non-filtered requests.

Looking at the HTTP exchanges (via IPFire logs and/or other means) around the time that you get unexpected access denieds and comparing things may help you to zero in on the answer. It sounds like you see some access denieds due to ads that don't fit with the site you are visiting. You might look to see if they fit with some other browsing session that you or someone else had going at the time.

 

FileHippo does have Google ads. It's not just FileHippo though. I was able to start up a fresh browser session, point it at Wilders, and get stopped due to a supposed Google ad.

Maybe it has something to do with the proxy's caching?

 

Got it. It was a simple but counterintuitive misconfiguration...



It seems that, if this option is not checked, ads will be "blocked" with the Access Denied banner instead of being removed in place. Not only is the issue gone, ad blocking actually works properly now; I'm seeing about half as many ads as I was before.

 

Why at Wilders though?

 

Not sure; I think it has something to do with the order in which the browser requests web pages.

 

Seems to me that such a proxy could indeed have a problem reliably identifying which HTTP requests are associated with the loading of a page. The browser could use separate sockets for requests. You could have two browser windows open to the same site, same Referer, with ads only served up for one of those. The browser might even block Referer. Then what? Lets put the proxy on the WAN side of a router serving multiple users too, just to torment it even more.

It occurs to me that if the browser inserted a session id type header, where the ID would be unique to all those HTTP requests associated with the page URL, the proxy could use that to correlate things and strip it out before passing on the requests. Off the top of my head though, I don't recall ever hearing of such a feature.