Possible abuse of our captive portal
I haven't much experience with pfSense's captive portal.
We have a 2.0RC3 box that exhausts is php handlers and is then unavailable for a temporary period.
I have found in the error logs lots of references to:
Which is the URL: ``` http://offers.bittorrent.com/w/1.0/arj?auid=453748
So I am trying to understand what is happening here. Is it a user/viruse/malware trying to craft a URL to get to this URL without authenticating?
Trying this trailing URL on the pfSense box in question results in an error.
Any thoughts on this appreciated.
Gertjan last edited by
I think you already have a clue what program is sending out many requests.
Of course, it's bittorrent. A P2P filesharing tool.
Often, this program starts when windows starts, and starts syncing right away, and it won't stop when it get NO for an answer, it will try the entire list of torrents lists (quiet a lot).
The result: your portal page is hit really hard.
- Stop using that cigarette-box size server that you use for pfSEnse. Go for that big quad-core system with loads of memory.
- Stop accepting kids and less serious people on your wifi network.
- Have a look at your firewall. By stopping the right requests, they won't hit the portal page (adn this the entire PHP sub-system, taking of the load on your system)
Of course, only point 3 is good to go ;)
Look down on the page when you add a firewall rule on your Portal interface NIC. The last Advanced options button, and find this: layer 7.
Jump to the doc https://doc.pfsense.org/index.php?title=Special%3ASearch&search=layer&go= and read all about queues, P2P etc.
Layer7 has a 'bittorrent' rule.
Thanks for the response Gertjan
This is a work environment, a college actually.
My boss had the idea to block it at the firewall (block all torrent.com access). I didn't think it would work as the client is trying to access the portal (with a trailing path in the URL) and that will use a php process before it is converted to torrent.com outbound and thus blocked.
But I don't know how the CP fits into the big picture of pfSense.
The block he has put in seems to have worked so far (or the client has ceased).
This is happening again at the same college campus.
In the error logs.
My question is, how can one log what client IP is requesting these redirects?
The lighttpd.log log is empty and I see in the lighttpd config we have:
#accesslog.filename = "/dev/null"
Which looks to me like the default could be /dev/null.
I can't see an option in the web interface to turn on access logging and I don't want to mess with the config files.
How can I log IPs going through the captive portal?