Logging / Proxying Meetinghouse Traffic
Posted: Tue Aug 16, 2011 8:18 pm
I'm a newly called STS. When I was called, the Stake President told me that one of his priorities would be making sure that people aren't using our building internet improperly (we have the most liberal filtering due to FHC). However, after becoming familiar with the church firewall, and searching this forum, it's clear that the church isn't able to log all traffic and report the logging to the STS - clearly this would be the preferred way.
So... I'm thinking of alternatives. Checking browser histories is just not possible or practical in our stake. With 14 units and 5 buildings, I'd be driving the better part of the week to regularly monitor usage. Plus, anyone with half a brain would know to clear the browser history and cache if they were breaking the rules.
This brought me to proxying. I don't want to set up a browser settings pointing to a proxy, because those are too easily circumvented and do not capture 'guest' clients that come on and off the network (wireless).
So that leaves a transparent proxy. My thought is to obtain some low cost plug computer (i.e. fit2pc, GlobalScale Sheevaplugs, etc) set up with Squid and some Squid log analyzer/auto emailer as a transparent proxy between the Church firewall and the rest of the network. Ideally, I'd have the unit keep logs only and maybe even find a way to get the unit to email me an aggregate report automatically. I don't think it'll have a noticeable performance impact, especially if I'm only logging and not cacheing with the proxy.
The only drawback I can come up with here is that all devices would be NAT'ed behind the new proxy (would go ISP <-> Firewall <-> Proxy <-> Client), rather than NATing directly behind the firewall. This may cause some issues with any remote support software the church has installed (do they?) or with other client devices that need to communicate directly with the ASA/PIX/891 (i.e. wireless access points).
I read online that a non-NAT transparent proxy could be achieve by 'smart' switching - so that remains an attractive option - but I'm not familiar with the configuration procedure, so I would need more investigation there.
Anyone have other solutions that have worked for them? Am I trying/thinking too hard? Other ideas?
(p.s. - I did findthis old thread but don't think it really had a resolution to the problem - and it's 3 years old.. thought maybe there might be some new insight...)
So... I'm thinking of alternatives. Checking browser histories is just not possible or practical in our stake. With 14 units and 5 buildings, I'd be driving the better part of the week to regularly monitor usage. Plus, anyone with half a brain would know to clear the browser history and cache if they were breaking the rules.
This brought me to proxying. I don't want to set up a browser settings pointing to a proxy, because those are too easily circumvented and do not capture 'guest' clients that come on and off the network (wireless).
So that leaves a transparent proxy. My thought is to obtain some low cost plug computer (i.e. fit2pc, GlobalScale Sheevaplugs, etc) set up with Squid and some Squid log analyzer/auto emailer as a transparent proxy between the Church firewall and the rest of the network. Ideally, I'd have the unit keep logs only and maybe even find a way to get the unit to email me an aggregate report automatically. I don't think it'll have a noticeable performance impact, especially if I'm only logging and not cacheing with the proxy.
The only drawback I can come up with here is that all devices would be NAT'ed behind the new proxy (would go ISP <-> Firewall <-> Proxy <-> Client), rather than NATing directly behind the firewall. This may cause some issues with any remote support software the church has installed (do they?) or with other client devices that need to communicate directly with the ASA/PIX/891 (i.e. wireless access points).
I read online that a non-NAT transparent proxy could be achieve by 'smart' switching - so that remains an attractive option - but I'm not familiar with the configuration procedure, so I would need more investigation there.
Anyone have other solutions that have worked for them? Am I trying/thinking too hard? Other ideas?
(p.s. - I did findthis old thread but don't think it really had a resolution to the problem - and it's 3 years old.. thought maybe there might be some new insight...)