redirect to webpage

redirect to webpage

[dhottinger]

I currently block a host of proxifier sites at my firewall using:
$IPC -t nat -A PREROUTING -p tcp -d apchemistry.info -j DROP

Not sure if this is the best practice, but it works fine.  What I  
would like to do, instead of dropping this traffic is have it sent to  
an internal webserver that has our acceptable use policy on it.  Is  
there a REDIRECT command, or what would be the best way to accomplish  
this.  Most of this traffic is actually on port 443, and I cant funnel  
this through my transparent proxy (squid).

thanks,


-- 
Dwayne Hottinger
Network Administrator
Harrisonburg City Public Schools

"rarely do people communicate, they just take turns talking"

Re: redirect to webpage

[Grant Taylor]

On 10/31/07 10:11, dhottinger@harrisonburg.k12.va.us wrote:
> Not sure if this is the best practice, but it works fine.  What I would 
> like to do, instead of dropping this traffic is have it sent to an 
> internal webserver that has our acceptable use policy on it.  Is there a 
> REDIRECT command, or what would be the best way to accomplish this.  
> Most of this traffic is actually on port 443, and I cant funnel this 
> through my transparent proxy (squid).

Yes.  You want to look in to DNATing the traffic to an internal web 
server that is specifically set up to do what you are wanting to do.

Hint, set up the web server of your choice that will answer any and all 
domain names with one single page, the 404 (not found) error page that 
is the content that you want displayed.  That way no matter what is 
requested, your page will be displayed.  I would also suggest that you 
include the headers to control how long the page is cached for, say 5 - 
15 minutes.  You may or may not want to return a 200 reply code.  Some 
browsers will display ""Friendly 404 pages and thus not display your text.



Grant. . . .

Re: redirect to webpage

[dhottinger]

Quoting Grant Taylor <gtaylor@riverviewtech.net>:

> On 10/31/07 10:11, dhottinger@harrisonburg.k12.va.us wrote:
>> Not sure if this is the best practice, but it works fine.  What I   
>> would like to do, instead of dropping this traffic is have it sent   
>> to an internal webserver that has our acceptable use policy on it.   
>>  Is there a REDIRECT command, or what would be the best way to   
>> accomplish this.  Most of this traffic is actually on port 443, and  
>>  I cant funnel this through my transparent proxy (squid).
>
> Yes.  You want to look in to DNATing the traffic to an internal web
> server that is specifically set up to do what you are wanting to do.
>
> Hint, set up the web server of your choice that will answer any and all
> domain names with one single page, the 404 (not found) error page that
> is the content that you want displayed.  That way no matter what is
> requested, your page will be displayed.  I would also suggest that you
> include the headers to control how long the page is cached for, say 5 -
> 15 minutes.  You may or may not want to return a 200 reply code.  Some
> browsers will display ""Friendly 404 pages and thus not display your
> text.
>
>
>
> Grant. . . .
> -
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Cool and thanks,
So something like:
$IPC -t nat -A PREROUTING -d cantbustme.net -j DNAT --to-destination  
mywebserver.com ?  Where cantbustme is the site I want to redirect and  
mywebserver is the box with the youve been busted page?

ddh


-- 
Dwayne Hottinger
Network Administrator
Harrisonburg City Public Schools

"rarely do people communicate, they just take turns talking"

Re: redirect to webpage

[Grant Taylor]

On 10/31/07 12:02, dhottinger@harrisonburg.k12.va.us wrote:
> Cool and thanks,
> 
> So something like:  $IPC -t nat -A PREROUTING -d cantbustme.net -j 
> DNAT --to-destination mywebserver.com ?  Where cantbustme is the site 
> I want to redirect and mywebserver is the box with the youve been 
> busted page?

Yes, well sort of.  Keep in mind that IPTables operates on a packet 
level (OSI Layers 2 and / or 3), not the URL level (OSI Layer 7).  Thus 
if you have multiple different web sites all residing on the same 
server, IPTables by default has no way to differentiate packets going to 
one URL over packets going to another URL.  (That is not quite true, you 
could use Layer 7 filtering to do this.)  Also keep in mind that the 
IPTables binary will translate the names to IP addresses at the time the 
command was run.  So if the IP address changes you will need to update 
your rule.  All this being said, yes your rule will catch and DNAT 
(redirect) packets to your server.

A gotcha to keep in mind is that if you redirect internal clients 
traffic back to an internal web server, the internal web server will see 
the traffic as coming from the internal client (purportedly) directly to 
the internal web server and as such reply from the internal web server 
directly to the internal client.  In such cases your internal client 
will see an out going connection to one supposed external server and 
getting this unknown not correctly initiated TCP connection from this 
rude internal web server that needs to be told where to go.  One way to 
work around this is to SNAT the traffic that is being DNATed by your 
firewall to the internal web server such that replies from the web 
server are sent back to the internal firewall which will unSNAT and 
unDNAT the traffic and send it back to the original client in such a way 
that the original client is perfectly happy with the traffic thinking it 
came from the original destination server.

What a lot of people do is configure a proxy server on the firewall and 
configure clients to use it.  Any clients that try to bypass the proxy 
by connecting directly get redirected to the proxy server port that is 
listening in transparent proxy mode.  This way they can force everyone 
to use the proxy.  In short, have the proxy answer normal proxy queries 
on its standard port (Squid uses 3128) and also listen in transparent 
proxy mode on port 80.  This way you only need to use one statement in 
IPTables to redirect (via the REDIRECT target) traffic passing through 
the firewall on port 80 to the local port 80 that is listening in 
transparent proxy mode.

I personally prefer to have clients be aware that they are connecting to 
a proxy server rather than using transparent proxying for everything. 
It is my (possibly misguided) long held belief that talking to a proxy 
as a proxy is better than talking to a proxy as a web server.

The difference between the REDIRECT target and the DNAT target is that 
DNAT will send the traffic any where you tell it to where as REDIRECT 
only alters the destination to be the local IP address of the interface 
the traffic that it comes in on.  Thus when you want to redirect traffic 
to a proxy running on the local system the REDIRECT target will work 
just fine where as when you want to redirect traffic to a proxy running 
on a different system you will need to DNAT and SNAT the traffic.



Grant. . . .

Re: redirect to webpage

[dhottinger]

Quoting Grant Taylor <gtaylor@riverviewtech.net>:

> On 10/31/07 12:02, dhottinger@harrisonburg.k12.va.us wrote:
>> Cool and thanks,
>>
>> So something like:  $IPC -t nat -A PREROUTING -d cantbustme.net -j   
>> DNAT --to-destination mywebserver.com ?  Where cantbustme is the   
>> site I want to redirect and mywebserver is the box with the youve   
>> been busted page?
>
> Yes, well sort of.  Keep in mind that IPTables operates on a packet
> level (OSI Layers 2 and / or 3), not the URL level (OSI Layer 7).  Thus
> if you have multiple different web sites all residing on the same
> server, IPTables by default has no way to differentiate packets going
> to one URL over packets going to another URL.  (That is not quite true,
> you could use Layer 7 filtering to do this.)  Also keep in mind that
> the IPTables binary will translate the names to IP addresses at the
> time the command was run.  So if the IP address changes you will need
> to update your rule.  All this being said, yes your rule will catch and
> DNAT (redirect) packets to your server.
>
> A gotcha to keep in mind is that if you redirect internal clients
> traffic back to an internal web server, the internal web server will
> see the traffic as coming from the internal client (purportedly)
> directly to the internal web server and as such reply from the internal
> web server directly to the internal client.  In such cases your
> internal client will see an out going connection to one supposed
> external server and getting this unknown not correctly initiated TCP
> connection from this rude internal web server that needs to be told
> where to go.  One way to work around this is to SNAT the traffic that
> is being DNATed by your firewall to the internal web server such that
> replies from the web server are sent back to the internal firewall
> which will unSNAT and unDNAT the traffic and send it back to the
> original client in such a way that the original client is perfectly
> happy with the traffic thinking it came from the original destination
> server.
>
> What a lot of people do is configure a proxy server on the firewall and
> configure clients to use it.  Any clients that try to bypass the proxy
> by connecting directly get redirected to the proxy server port that is
> listening in transparent proxy mode.  This way they can force everyone
> to use the proxy.  In short, have the proxy answer normal proxy queries
> on its standard port (Squid uses 3128) and also listen in transparent
> proxy mode on port 80.  This way you only need to use one statement in
> IPTables to redirect (via the REDIRECT target) traffic passing through
> the firewall on port 80 to the local port 80 that is listening in
> transparent proxy mode.
>
> I personally prefer to have clients be aware that they are connecting
> to a proxy server rather than using transparent proxying for
> everything. It is my (possibly misguided) long held belief that talking
> to a proxy as a proxy is better than talking to a proxy as a web server.
>
> The difference between the REDIRECT target and the DNAT target is that
> DNAT will send the traffic any where you tell it to where as REDIRECT
> only alters the destination to be the local IP address of the interface
> the traffic that it comes in on.  Thus when you want to redirect
> traffic to a proxy running on the local system the REDIRECT target will
> work just fine where as when you want to redirect traffic to a proxy
> running on a different system you will need to DNAT and SNAT the
> traffic.
>
>
>
> Grant. . . .
> -
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

WOW.  Quite a lot of information.  Its been my goal to get my proxy  
server and firewall on the same box.  Havent got there yet.  My  
firewall is running on an old pII ibm workstation with 3 nics, doing  
routing, nat etc. and has worked very well.  Hardly ever breaks a  
sweat, so it hasnt been a priority like mail, etc.  The main reason I  
used the url is because the ip addresses of the sites change quite a  
bit also.  Im just about ready to throw the towel in, there is just to  
many proxiifier sites for people to use to circumvent my filter.   I  
guess the best way to do this would not run a transparent proxy, which  
maybe what I end up doing sometime in the future.  As always thanks  
for the advise.

ddh

-- 
Dwayne Hottinger
Network Administrator
Harrisonburg City Public Schools

"rarely do people communicate, they just take turns talking"

Re: redirect to webpage

[G.W. Haywood]

Hi there,

On Wed, 31 Oct 2007 dhottinger@harrisonburg.k12.va.us wrote:

> Quoting Grant Taylor <gtaylor@riverviewtech.net>:
>
> >> [snip, snip, snip]
>
> WOW.  Quite a lot of information.

Quite so.  Please trim your posts more vigorously when replying to a
public mailing list, we don't need to read it three times.

> ... The main reason I used the url is because the ip addresses of
> the sites change quite a bit also.  Im just about ready to throw the
> towel in, there is just to many proxiifier sites for people to use
> to circumvent my filter.

Have you considered using one of the firewall distros, for example IPCop?

There are facilities such as you require built-in and/or using addons
which will save you from a lot of wheel reinvention.

--

73,
Ged.

Re: redirect to webpage

[Pascal Hambourg]

Hello,

dhottinger@harrisonburg.k12.va.us a écrit :
> 
> The main reason I  
> used the url is because the ip addresses of the sites change quite a  
> bit also.

Then keep in mind Grant's remark :
>> the IPTables binary will translate the names to IP addresses at the
>> time the command was run.  So if the IP address changes you will need
>> to update your rule.

Note : cantbustme.net is a hostname, not a URL. A URL would be for 
example <http://cantbustme.net/foo/bar.html>.

Re: redirect to webpage

[Grant Taylor]

On 10/31/07 19:57, dhottinger@harrisonburg.k12.va.us wrote:
> WOW.  Quite a lot of information.  Its been my goal to get my proxy 
> server and firewall on the same box.  Havent got there yet.  My firewall 
> is running on an old pII ibm workstation with 3 nics, doing routing, nat 
> etc. and has worked very well.  Hardly ever breaks a sweat, so it hasnt 
> been a priority like mail, etc.  The main reason I used the url is 
> because the ip addresses of the sites change quite a bit also.  Im just 
> about ready to throw the towel in, there is just to many proxiifier 
> sites for people to use to circumvent my filter.   I guess the best way 
> to do this would not run a transparent proxy, which maybe what I end up 
> doing sometime in the future.  As always thanks for the advise.

*nod*

That is why I have found a liking of the unix way of thinking where you 
lock down everything and just open up what is needed.

Good luck with your problem(s).  If you are curious, you could probably 
come up with a chain and sub-chain structure that only part of the 
sub-chain(s) were updated via cron jobs when things change.



Grant. . . .