Hi all, I have a few questions: 1. Redirection: a. I had the following in rules: # # # Redirect all http # REDIRECT:ULOG loc 3128 tcp www - !192.168.0.3 REDIRECT:ULOG loc 3128 tcp 8080 - !192.168.0.3 Which should, if I understand correctly, redirect all local traffic directed to ports 80 & 8080 to port 3128. (On 3128 is Dansgauardian and on 8080 is Squid). Then I found that one could bypass the proxy by just tell the browser to connect directly. b. So I googled around and found the following suggestions: REDIRECT- $FW 3128 tcp 80 - !192.168.0.3 DNAT loc loc:192.168.0.3:3128 tcp www DROP net $FW tcp 8080 DROP net $FW tcp 3128 I test all of them without success. Any suggestions from anyone would be welcomed. 2. QUEUE/Authentication/Accounting. In the documentation I read that some people use it to control p2p. Would it possible to or has anybody tried it for anything else? I have the idea to try to use it to authenticate users. I have two machines which is mostly in XP and intended for my boys to do school work, but they frequently abuse it. Unfortunately we have Internet Capping (please don''t laugh!) and it costs money to extend it. So if I can tell who used what and how much I could control it better, the ultimate would be to designate a certain amount of bandwidth to each. Any ideas in this regard? Regards and my each and everyone of you be very prosperous in 2008. Louis. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
llsjk wrote:> > Then I found that one could bypass the proxy by just tell the browser to > connect directly.What does that mean? Give us an example of what you did, what you expected to happen and what actually happened.> > b. So I googled around and found the following suggestions:> > REDIRECT- $FW 3128 tcp 80 - !192.168.0.3 > > DNAT loc loc:192.168.0.3:3128 tcp wwwI have no idea what you are trying to do with the second rule. There should be no loc->loc traffic here.> > DROP net $FW tcp 8080 > DROP net $FW tcp 3128 >Those two forbid connections from loc->fw to ports 8080 and 3128; which means that the first redirect rule is useless.> I test all of them without success.Not suprising.> > Any suggestions from anyone would be welcomed.Again, please tell us exactly what problem you are trying to solve.> > 2. QUEUE/Authentication/Accounting. > > In the documentation I read that some people use it to control p2p. > > Would it possible to or has anybody tried it for anything else? I have > the idea to try to use it to authenticate users.Most people do that by redirecting all attempts to connect to the web to a login server. Successful login causes the ruleset to be altered to remove the redirection (or preempt it with a different redirection). -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Thu, Jan 03, 2008 at 02:31:04PM +0200, llsjk wrote:> I have two machines which is mostly in XP and intended for my boys to do > school work, but they frequently abuse it.> Any ideas in this regard?You *will not* be able to solve this problem with software. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Thu, Jan 03, 2008 at 07:21:08AM -0800, Tom Eastep wrote:> > Would it possible to or has anybody tried it for anything else? I have > > the idea to try to use it to authenticate users. > > Most people do that by redirecting all attempts to connect to the web to > a login server. Successful login causes the ruleset to be altered to > remove the redirection (or preempt it with a different redirection).What a curious idea. I always use openvpn to authenticate network endpoints (give each user or group of users a static IP address or block, probably in 10.0.0.0/8, and the rest is easy). Goes well with 802.11 - it''s like a form of WEP that isn''t idiotic. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Andrew Suffield wrote:> On Thu, Jan 03, 2008 at 07:21:08AM -0800, Tom Eastep wrote: >>> Would it possible to or has anybody tried it for anything else? I have >>> the idea to try to use it to authenticate users. >> Most people do that by redirecting all attempts to connect to the web to >> a login server. Successful login causes the ruleset to be altered to >> remove the redirection (or preempt it with a different redirection). > > What a curious idea. I always use openvpn to authenticate network > endpoints (give each user or group of users a static IP address or > block, probably in 10.0.0.0/8, and the rest is easy). Goes well with > 802.11 - it''s like a form of WEP that isn''t idiotic.I use OpenVPN that way also (see http://www1.shorewall.net/OPENVPN.html#Bridge). And there is certainly no reason why the OP couldn''t also use OpenVPN. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Hi Tom,>> Then I found that one could bypass the proxy by just tell the browser to >> connect directly. >> > > What does that mean? Give us an example of what you did, what you > expected to happen and what actually happened. > >If I go via the proxy to a non-existing page like for eg www.noheret.com I get an announcement from squid that the page cannot be found. If I switch off the use of proxy, ie connect directly to the same site I get a message probably from the browser that the site does not exist. So I deducted that if you switch off the use of the proxy you can apparently bypass all of it, even the redirection. The idea is all http trafific should go to port 3128 (Dansguardian - content filtering) and then to squid(8080) for cache proxying. With the redirect I hoped that one should no be able to bypass it at all.> Again, please tell us exactly what problem you are trying to solve. > >>> 2. QUEUE/Authentication/Accounting. >> >> In the documentation I read that some people use it to control p2p. >> >> Would it possible to or has anybody tried it for anything else? I have >> the idea to try to use it to authenticate users. >> > > Most people do that by redirecting all attempts to connect to the web to > a login server. Successful login causes the ruleset to be altered to > remove the redirection (or preempt it with a different redirection). > >Any examples to look at? Kind regards, Louis. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
llsjk wrote:> Hi Tom, >>> Then I found that one could bypass the proxy by just tell the browser to >>> connect directly. >>> >> What does that mean? Give us an example of what you did, what you >> expected to happen and what actually happened. >> >> > If I go via the proxy to a non-existing page like for eg www.noheret.com > I get an announcement from squid that the page cannot be found. If I > switch off the use of proxy, ie connect directly to the same site I get > a message probably from the browser that the site does not exist.Of course -- if there is no process listening on port 3128 on the firewall, your browser will give you such a message. Try accessing a site that DOES exist -- you''ll get the same message (you may have to click the ''refresh'' button on the browser). -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Tom Eastep wrote:>> If I go via the proxy to a non-existing page like for eg www.noheret.com >> I get an announcement from squid that the page cannot be found. If I >> switch off the use of proxy, ie connect directly to the same site I get >> a message probably from the browser that the site does not exist. >> > > > Of course -- if there is no process listening on port 3128 on the > firewall, your browser will give you such a message. Try accessing a > site that DOES exist -- you''ll get the same message (you may have to > click the ''refresh'' button on the browser). > >As far as I have it: on the firewall on port 3128 is Dansguardian listening which should automatically forward the request to Squid on port 8080 who talks to the outside world. That is why I expect to get the same message, whether the browser uses proxy or not, due to the redirection. Or am I missing something somewhere? Kind Regards, Louis. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
llsjk wrote:>As far as I have it: on the firewall on port 3128 is Dansguardian >listening which should automatically forward the request to Squid on >port 8080 who talks to the outside world. That is why I expect to get >the same message, whether the browser uses proxy or not, due to the >redirection. Or am I missing something somewhere?Yes, you are missing something ! Going direct, there are several things that can happen when your client makes a request : 1) It gets a page returned 2) It gets an error response from the server (eg 404 page not found) 3) The connections attempt is rejected (eg there is no web server running on that machine, or a firewall configured to reject inbound connections) 4) The connection attempt is ignored with no response (eg there is no machine at that address, or a firewall configured to drop, not reject, inbound packets). When you go via the proxy, it''s always there, so options 3&4 are unlikely to happen. Even if the end server you are attempting to get pages from doesn''t exist, you will still be able to establish a tcp connection to the proxy - and will eventually receive an error message generated BY THE PROXY to say it couldn''t connect. So: Going direct you may get messages to the effect that the browser couldn''t connect to the server. Going via the proxy you will NOT get these errors FROM THE BROWSER but may well get them from the proxy. Does this make sense ? It''s nothing to do with Shorewall or the proxy - it''s just basic networking. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Simon Hobson wrote:> llsjk wrote: > > >> As far as I have it: on the firewall on port 3128 is Dansguardian >> listening which should automatically forward the request to Squid on >> port 8080 who talks to the outside world. That is why I expect to get >> the same message, whether the browser uses proxy or not, due to the >> redirection. Or am I missing something somewhere? >> > > Yes, you are missing something ! > > Going direct, there are several things that can happen when your > client makes a request : > > 1) It gets a page returned > 2) It gets an error response from the server (eg 404 page not found) > 3) The connections attempt is rejected (eg there is no web server > running on that machine, or a firewall configured to reject inbound > connections) > 4) The connection attempt is ignored with no response (eg there is no > machine at that address, or a firewall configured to drop, not > reject, inbound packets). > > When you go via the proxy, it''s always there, so options 3&4 are > unlikely to happen. Even if the end server you are attempting to get > pages from doesn''t exist, you will still be able to establish a tcp > connection to the proxy - and will eventually receive an error > message generated BY THE PROXY to say it couldn''t connect. > > > So: > > Going direct you may get messages to the effect that the browser > couldn''t connect to the server. > > Going via the proxy you will NOT get these errors FROM THE BROWSER > but may well get them from the proxy. > > > Does this make sense ? It''s nothing to do with Shorewall or the proxy > - it''s just basic networking. > >Thanks Simon, but I thought that through Redirection one would make sure that no one could go directly. I thought the redirection will always take the browser through port 3128. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
llsjk wrote:> Simon Hobson wrote: >> llsjk wrote: >> >> >>> As far as I have it: on the firewall on port 3128 is Dansguardian >>> listening which should automatically forward the request to Squid on >>> port 8080 who talks to the outside world. That is why I expect to get >>> the same message, whether the browser uses proxy or not, due to the >>> redirection. Or am I missing something somewhere? >>> >> Yes, you are missing something ! >> >> Going direct, there are several things that can happen when your >> client makes a request : >> >> 1) It gets a page returned >> 2) It gets an error response from the server (eg 404 page not found) >> 3) The connections attempt is rejected (eg there is no web server >> running on that machine, or a firewall configured to reject inbound >> connections) >> 4) The connection attempt is ignored with no response (eg there is no >> machine at that address, or a firewall configured to drop, not >> reject, inbound packets). >> >> When you go via the proxy, it''s always there, so options 3&4 are >> unlikely to happen. Even if the end server you are attempting to get >> pages from doesn''t exist, you will still be able to establish a tcp >> connection to the proxy - and will eventually receive an error >> message generated BY THE PROXY to say it couldn''t connect. >> >> >> So: >> >> Going direct you may get messages to the effect that the browser >> couldn''t connect to the server. >> >> Going via the proxy you will NOT get these errors FROM THE BROWSER >> but may well get them from the proxy. >> >> >> Does this make sense ? It''s nothing to do with Shorewall or the proxy >> - it''s just basic networking. >> >> > Thanks Simon, but I thought that through Redirection one would make sure > that no one could go directly. I thought the redirection will always > take the browser through port 3128.It does! -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
I assume (incorrectly?) you''re trying to set up
"interception" ("transparent") web filtering that a)
doesn''t require any proxy settings in individual
clients and b) can''t be bypassed.
That''s exactly what we have (and I''ve grown so
accustomed to it I think of it as a "no-brainer"). We
used what were the default ports at the time, which
are backward from yours: for us 8080 is DansGuardian
and 3128 is Squid. You should be able to translate
everything as necessary.
-----
In shorewall we have
REDIRECT loc 8080 tcp 80
In other words, grab all traffic where any browser is
trying to contact a web server (i.e. on 80) and
redirect it into DansGuardian instead. Note there is
only _one_ of these; we do _not_ use Shorewall to
redirect traffic on the other side of DansGuardian or
to double-redirect anything. (Of course you''ll need to
tweak this slightly to accomodate your 192.168.0.3
system, which we do not have.)
-----
In DansGuardian configuration we have
proxyport = 3128
In other words, do your thing, then pass traffic
upstream to Squid who is listening on this port.
-----
In Squid configuration we have
http_port 127.0.0.1:3128
In other words listen for connection requests on this
port _only_ on the loopback port (i.e. _only_ from
this host, not from other computers on our LAN).
-----
If users try to bypass us by setting port 8080, they
just get DansGuardian anyway. If they try to bypass us
by going _through_ our firewall using port 3128, they
get to the remote website but the remote website
ignores them because it''s not listening on 3128. If
they try to bypass DansGuardian by going _to_ our
firewall using port 3128, they time out because no
one''s listening (Squid''s listening only on the
"loopback" network, _not_ on the LAN.)
(I find the stuff you Googled and tried much much too
complicated and internally inconsistent, and suspect
it''s either trying to solve a different problem or has
been mangled somehow. Shorewall is the best place to
do _some_ of this, but other parts may be better done
in app configurations. And each bit of the
configuration should be very simple: only 1 or 2
lines. More than that indicates something''s wrong.)
I hope this helps.
good luck!
-Chuck Kollars
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search.
http://tools.search.yahoo.com/newsearch/category.php?category=shopping
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
llsjk wrote:> >> As far as I have it: on the firewall on port 3128 is Dansguardian >>> listening which should automatically forward the request to Squid on >>> port 8080 who talks to the outside world. That is why I expect to get >>> the same message, whether the browser uses proxy or not, due to the >>> redirection. Or am I missing something somewhere? >>> >> >> Yes, you are missing something ! >> >> Going direct, there are several things that can happen when your >> client makes a request : >> >> 1) It gets a page returned >> 2) It gets an error response from the server (eg 404 page not found) >> 3) The connections attempt is rejected (eg there is no web server >> running on that machine, or a firewall configured to reject inbound >> connections) >> 4) The connection attempt is ignored with no response (eg there is no >> machine at that address, or a firewall configured to drop, not >> reject, inbound packets). >> >> When you go via the proxy, it''s always there, so options 3&4 are >> unlikely to happen. Even if the end server you are attempting to get >> pages from doesn''t exist, you will still be able to establish a tcp >> connection to the proxy - and will eventually receive an error >> message generated BY THE PROXY to say it couldn''t connect. >> >> >> So: >> >> Going direct you may get messages to the effect that the browser >> couldn''t connect to the server. >> >> Going via the proxy you will NOT get these errors FROM THE BROWSER >> but may well get them from the proxy. >> >> >> Does this make sense ? It''s nothing to do with Shorewall or the proxy > > - it''s just basic networking.>Thanks Simon, but I thought that through Redirection one would make sure >that no one could go directly. I thought the redirection will always >take the browser through port 3128.As Tom has already said - IT DOES. Now please read my previous message again - it explains why going via a proxy (whether by a redirection on a network device, or by proxy settings in the browser) may well produce different results than having the web browser go direct to the website. The difference is that with a proxy involved, the browser machine should never get "no response at all" (packets dropped by firewall) or "connection rejected" (connection rejected by firewall or server without service running). ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/