Currently, in our schools, we use Squid+DansGuardian for basic web content filtering (URLs, phrases, domains, client users, and client IPs). We use Squid for handling the HTTP requests, not for any local disk/mem caching.
It appears that most of this can be handled by a PA firewall with some LDAP hooks into the school Linux server (URLs, applications, threats, client users, client IPs). (Although, that may not work without ident support?)
However, for those that are using PA firewalls in a similar manner, how do you manage the rules/lists? For example, with the DansGuardian setup, we have a simple Webmin module that provides teachers with access to edit the various lists and to easily add/remove entries from the lists. And, by changing group membership for students, block access as needed.
How would that work on the firewall? We'd really prefer to not give teachers access to the firewalls directly. :) We'd also prefer to not require the schools to be constantly calling the service desk to edit the lists for them. Is this a situation where the API would come into play? Could we design a Webmin module to add/remove/view the URL filtering lists in the Security Policies?
Reason I'm asking is that we're running into some limitations and performance issues with DansGuardian, and it looks like most of the features we actually use are supported on the PA firewalls, so I'm looking at alternatives.
Replying to myself, I think I've come up with a solution for this, using the XML API.
To replace the oidentd setup for DansGuardian (to get the username associated with the source IP of a connection), we can
That gives us the ability to track users across devices via the logs, and to allow/deny access based on username. We can write a simple Webmin module to add/remove users from a block list on the firewall, if we want to give staff the ability to do it themselves, or we can keep that as a Service Desk request.
Same for URL filtering.
No need to allow staff direct logins to the firewalls. :)
We don't currently use the content filtering aspect of DansGuardian nearly as much as we did when we first implemented it 10-odd years ago. With so much web traffic moving to HTTPS, there's not a lot of page content that actually CAN be filtered. :) We're not interested in enabling SSL Decryption on the firewalls (at least, not yet), so we won't be losing anything by moving the "proxy" features to the firewall.
After reading up on the XML API, it seems we should be able to retire Squid/DansGuardian this summer without losing any features, and actually gaining some. Hopefully, we'll also see some improvements in the browsing/network experience as well, as DansGuardian is a bit of a bottleneck for us right now (limited to 1000 processes/connections per proxy server, which is hit very quickly when a single web page can use 40+ connections).
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!