Forwarding traffic from public IP to public IP.

Forwarding traffic from public IP to public IP.

[Jason Hawthorne]

I need to temporarily forward all traffic from one public IP address
(a.b.c.d) to another public IP address (e.f.g.h). I have tried setting
up iptables with the following rule

-t nat -A PREROUTING -d a.b.c.d -j DNAT --to-destination e.f.g.h

but it doesn't seem to be working. As far as I can tell the traffic is
getting forwarded to the final ip (e.f.g.h) but when the return traffic
comes back it doesn't come back through the debian box, it goes straight
to the source and fails. Basically it skips the debian box on its return
like this

SOURCE ---> DEBIAN (iptables with nat) ---> DESTINATION ---> SOURCE

Is there a way to get this working with iptables?

-
Jason Hawthorne

Re: Forwarding traffic from public IP to public IP.

[Grant Taylor]

On 11/28/07 10:09, Jason Hawthorne wrote:
> I need to temporarily forward all traffic from one public IP address 
> (a.b.c.d) to another public IP address (e.f.g.h). I have tried 
> setting up iptables with the following rule
> 
> -t nat -A PREROUTING -d a.b.c.d -j DNAT --to-destination e.f.g.h
> 
> but it doesn't seem to be working. As far as I can tell the traffic 
> is getting forwarded to the final ip (e.f.g.h) but when the return 
> traffic comes back it doesn't come back through the debian box, it 
> goes straight to the source and fails. Basically it skips the debian 
> box on its return like this
> 
> SOURCE ---> DEBIAN (iptables with nat) ---> DESTINATION ---> SOURCE

Ah, yes.  This is what I like to refer as a "TCP Triangle".  You see the 
problems with it.

> Is there a way to get this working with iptables?

Yes there is a way to get around this.  You need to SNAT the traffic as 
it's leaving DEBIAN on its way to DESTINATION so that it will follow the 
same path in reverse back to the original client.  Thus you end up with 
this:

SOURCE ---> DEBIAN ---> DESTINATION ---> DEBIAN ---> SOURCE

The main problem with this is that your DESTINATION system will not see 
the real source IP of the traffic.  If this is important, you may want 
to consider some sort of reverse proxy that will add a header with the 
original IP address in it (I think that is how this can work???) or you 
may want to look in to something like Linux Virtual Server's Direct 
Routing solution if the DESTINATION is on the same network as DEBIAN and 
can thus use the same return path.  (Refer to LVS DR approach for more 
details on how this actually works.)



Grant. . . .

RE: Forwarding traffic from public IP to public IP.

[Jason Hawthorne]

> -----Original Message-----
> From: netfilter-owner@vger.kernel.org [mailto:netfilter-
> owner@vger.kernel.org] On Behalf Of Grant Taylor
> Sent: Wednesday, November 28, 2007 10:39 AM
> To: Mail List - Netfilter
> Subject: Re: Forwarding traffic from public IP to public IP.
> 
> On 11/28/07 10:09, Jason Hawthorne wrote:
> > I need to temporarily forward all traffic from one public IP address
> > (a.b.c.d) to another public IP address (e.f.g.h). I have tried
> > setting up iptables with the following rule
> >
> > -t nat -A PREROUTING -d a.b.c.d -j DNAT --to-destination e.f.g.h
> >
> > but it doesn't seem to be working. As far as I can tell the traffic
> > is getting forwarded to the final ip (e.f.g.h) but when the return
> > traffic comes back it doesn't come back through the debian box, it
> > goes straight to the source and fails. Basically it skips the debian
> > box on its return like this
> >
> > SOURCE ---> DEBIAN (iptables with nat) ---> DESTINATION ---> SOURCE
> 
> Ah, yes.  This is what I like to refer as a "TCP Triangle".  You see
> the
> problems with it.
> 
> > Is there a way to get this working with iptables?
> 
> Yes there is a way to get around this.  You need to SNAT the traffic
as
> it's leaving DEBIAN on its way to DESTINATION so that it will follow
> the
> same path in reverse back to the original client.  Thus you end up
with
> this:
> 
> SOURCE ---> DEBIAN ---> DESTINATION ---> DEBIAN ---> SOURCE
> 
> The main problem with this is that your DESTINATION system will not
see
> the real source IP of the traffic.  If this is important, you may want
> to consider some sort of reverse proxy that will add a header with the
> original IP address in it (I think that is how this can work???) or
you
> may want to look in to something like Linux Virtual Server's Direct
> Routing solution if the DESTINATION is on the same network as DEBIAN
> and
> can thus use the same return path.  (Refer to LVS DR approach for more
> details on how this actually works.)
> 
> 
> 
> Grant. . . .
> -

So would the rules look like this than?  Because it doesn't seem to be
working.

iptables -t nat -A POSTROUTING -d DESTINATION-IP -j SNAT --to-source
DEBIAN-IP
iptables -t nat -A PREROUTING -d DEBIAN-IP -j DNAT --to-destination
SOURCE-IP

Blocking web-based proxy traffic

[James Lay]

Hello all!

A curious question I have been asked from a client...any way to block
web-based proxies with iptables?  Wondering what it would take.  Thanks!

James

Re: Blocking web-based proxy traffic

[Grant Taylor]

(Please do not start a new thread by replying to an old one.)

On 11/28/07 11:56, James Lay wrote:
> A curious question I have been asked from a client...any way to block 
> web-based proxies with iptables?  Wondering what it would take.

Well, IPTables can filter packets based on source IP of the proxies if 
they are known.  You could also use some sort of layer 7 match looking 
for some sort of header indicating that a proxy was in use.  However 
this would be very easy to circumvent and very much a catch up game on 
the IP blocking.

If you are really serious about doing this I would suggest that you do 
something that functioned based on the number of connections from a 
given source IP with in a time frame knowing that it is likely that 
proxies will possibly have a higher hit count than single systems. 
However this will also catch NATing gateways for companies.  So you will 
have to deal with white listing too.



Grant. . . .

Re: Blocking web-based proxy traffic

[James Lay]

On 11/28/07 12:20 PM, "Grant Taylor" <gtaylor@riverviewtech.net> wrote:

> (Please do not start a new thread by replying to an old one.)
> 
> On 11/28/07 11:56, James Lay wrote:
>> A curious question I have been asked from a client...any way to block
>> web-based proxies with iptables?  Wondering what it would take.
> 
> Well, IPTables can filter packets based on source IP of the proxies if
> they are known.  You could also use some sort of layer 7 match looking
> for some sort of header indicating that a proxy was in use.  However
> this would be very easy to circumvent and very much a catch up game on
> the IP blocking.
> 
> If you are really serious about doing this I would suggest that you do
> something that functioned based on the number of connections from a
> given source IP with in a time frame knowing that it is likely that
> proxies will possibly have a higher hit count than single systems.
> However this will also catch NATing gateways for companies.  So you will
> have to deal with white listing too.
> 
> 
> 
> Grant. . . .

Interesting idea.  I know that when I've captured this proxy traffic I see
in ASCII "http://" and then whatever proxied site (usually myspace).  I was
thinking maybe a matchstring type thing?  Here's a snippet from an
access.log from a transparent squid proxy, using sureproxy hitting playboy:

10.1.1.191 - - [28/Nov/2007:12:49:26 -0700] "GET
http://www.sureproxy.com/nph-index.cgi/011110A/http/www.playboy.com/imx/fron
tpage/2008-calendars.jpg HTTP/1.1" 200 366
"http://www.sureproxy.com/nph-index.cgi/011110A/http/www.playboy.com/"
"Opera/9.24 (Macintosh; Intel Mac OS X; U; en)" TCP_MISS:DIRECT

Does my idea make sense or am I on crack :D

James

Re: Blocking web-based proxy traffic

[Grant Taylor]

On 11/28/07 14:01, James Lay wrote:
> Interesting idea.  I know that when I've captured this proxy traffic 
> I see in ASCII "http://" and then whatever proxied site (usually 
> myspace).  I was thinking maybe a matchstring type thing?  Here's a 
> snippet from an access.log from a transparent squid proxy, using 
> sureproxy hitting playboy:

Possibly.

> 10.1.1.191 - - [28/Nov/2007:12:49:26 -0700] "GET 
> http://www.sureproxy.com/nph-index.cgi/011110A/http/www.playboy.com/imx/frontpage/2008-calendars.jpg 
> HTTP/1.1" 200 366 
> "http://www.sureproxy.com/nph-index.cgi/011110A/http/www.playboy.com/" 
> "Opera/9.24 (Macintosh; Intel Mac OS X; U; en)" TCP_MISS:DIRECT
> 
> Does my idea make sense or am I on crack :D

Are you wanting to prevent proxy services from accessing your web 
site(s) or are you wanting to prevent people behind your proxy from 
accessing prohibited material?  This makes a *BIG* difference in what 
direction you go.



Grant. . . .

Re: Blocking web-based proxy traffic

[James Lay]

On 11/28/07 1:07 PM, "Grant Taylor" <gtaylor@riverviewtech.net> wrote:

> On 11/28/07 14:01, James Lay wrote:
>> Interesting idea.  I know that when I've captured this proxy traffic
>> I see in ASCII "http://" and then whatever proxied site (usually
>> myspace).  I was thinking maybe a matchstring type thing?  Here's a
>> snippet from an access.log from a transparent squid proxy, using
>> sureproxy hitting playboy:
> 
> Possibly.
> 
>> 10.1.1.191 - - [28/Nov/2007:12:49:26 -0700] "GET
>> http://www.sureproxy.com/nph-index.cgi/011110A/http/www.playboy.com/imx/front
>> page/2008-calendars.jpg
>> HTTP/1.1" 200 366
>> "http://www.sureproxy.com/nph-index.cgi/011110A/http/www.playboy.com/"
>> "Opera/9.24 (Macintosh; Intel Mac OS X; U; en)" TCP_MISS:DIRECT
>> 
>> Does my idea make sense or am I on crack :D
> 
> Are you wanting to prevent proxy services from accessing your web
> site(s) or are you wanting to prevent people behind your proxy from
> accessing prohibited material?  This makes a *BIG* difference in what
> direction you go.
> 
> 
> 
> Grant. . . .


The latter ;)  Keeping the people on the inside from being naughty.  One of
my clients doesn't want a proxy server installed....I would normally just
use squid and squidguard and be done with it, but that's not an option.  So
baring using Snort to do it (somehow) I was thinking netfilter/iptables to
match strings on port 80 for "http".  Hope that explains it better.

James

Re: Blocking web-based proxy traffic

[Grant Taylor]

On 11/28/07 14:16, James Lay wrote:
> The latter ;)  Keeping the people on the inside from being naughty. 
> One of my clients doesn't want a proxy server installed....I would 
> normally just use squid and squidguard and be done with it, but 
> that's not an option.  So baring using Snort to do it (somehow) I was 
> thinking netfilter/iptables to match strings on port 80 for "http". 
> Hope that explains it better.

Ok.  Aside from needing to use a Clue-by-4 on your client, you are 
headed down an ok track.

Be aware that you are looking for ASCII text that is recognizable as a 
prohibited site.  If you do use IPTables to do your matches, you will 
either be able to DROP, REJECT, or DNAT (redirect) the traffic.  The 
first option is not graceful at all as it will leave clients in a time 
out condition while the second option will probably more gracefully 
fail.  The preferred option would be to DNAT (redirect) the traffic to a 
mini web server that will serve up a generic web page indicating that 
the access has been blocked.

I suppose that you can use layer 7 string matching to look for the 
prohibited URL in the the real get string.  However if there is any 
obfuscation being used, even simple URL encoding using %## the chances 
of detecting the traffic is slim.  This is why you should really look in 
to some sort of content filtering solution.

Would you be able to install something like DansGuardian and tell your 
client that it is a filter not a proxy and use that?  Of course to use 
DansGuardian, you do have to have a proxy for DG to talk to.



Grant. . . .

Re: Blocking web-based proxy traffic

[Benny Amorsen]

>>>>> "GT" == Grant Taylor <gtaylor@riverviewtech.net> writes:

GT> The preferred option would be to DNAT (redirect) the traffic to a
GT> mini web server that will serve up a generic web page indicating
GT> that the access has been blocked.

The GET request only gets transmitted once the three-way TCP handshake
is done. By then it's way too late to DNAT anything -- the mini web
server wouldn't get a SYN, so it would throw away the packet.


/Benny

Re: Blocking web-based proxy traffic

[James Lay]

On 11/29/07 3:55 AM, "Benny Amorsen" <benny+usenet@amorsen.dk> wrote:

>>>>>> "GT" == Grant Taylor <gtaylor@riverviewtech.net> writes:
> 
> GT> The preferred option would be to DNAT (redirect) the traffic to a
> GT> mini web server that will serve up a generic web page indicating
> GT> that the access has been blocked.
> 
> The GET request only gets transmitted once the three-way TCP handshake
> is done. By then it's way too late to DNAT anything -- the mini web
> server wouldn't get a SYN, so it would throw away the packet.
> 
> 
> /Benny
> 
> 
> -
> 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


Thanks to all who responded to this...looks like I'll have to use a
multi-layered approach.

Thanks again,
James

Re: Blocking web-based proxy traffic

[Grant Taylor]

On 11/29/07 04:55, Benny Amorsen wrote:
> The GET request only gets transmitted once the three-way TCP 
> handshake is done. By then it's way too late to DNAT anything -- the 
> mini web server wouldn't get a SYN, so it would throw away the 
> packet.

Very good point.  I did not think of that.

Would it be possible to possibly replace the returning traffic from a 
custom daemon that could essentially be a man in the middle.  In effect 
alter the returning stream back to the requesting client and close out 
the connection to the answering server?  A "Cut-In" if you will?  I 
would think that you could pass the traffic via a NetLink interface to a 
custom program that could do what is needed.

Is something like this possible or am I smoking too much again?



Grant. . . .

Re: Blocking web-based proxy traffic

[Tagg McDonald]

> Interesting idea.  I know that when I've captured this proxy traffic I see
> in ASCII "http://" and then whatever proxied site (usually myspace).  I was
> thinking maybe a matchstring type thing?  Here's a snippet from an
> access.log from a transparent squid proxy, using sureproxy hitting playboy:
>
> 10.1.1.191 - - [28/Nov/2007:12:49:26 -0700] "GET
> http://www.sureproxy.com/nph-index.cgi/011110A/http/www.playboy.com/imx/fron
> tpage/2008-calendars.jpg HTTP/1.1" 200 366
> "http://www.sureproxy.com/nph-index.cgi/011110A/http/www.playboy.com/"
> "Opera/9.24 (Macintosh; Intel Mac OS X; U; en)" TCP_MISS:DIRECT
>
> Does my idea make sense or am I on crack :D
>
> James

If you have a transparent squid proxy in place you can do ACL's and/or
use squidguard or dans guardian.

-- 
Tagg McDonald
Dutro Company
675 North 600 West
Logan, UT 84321
(435) 752-3921 x146

Re: Blocking web-based proxy traffic

[dhottinger]

Quoting Tagg McDonald <taggm@dutro.com>:

>
>> Interesting idea.  I know that when I've captured this proxy traffic I see
>> in ASCII "http://" and then whatever proxied site (usually myspace).  I was
>> thinking maybe a matchstring type thing?  Here's a snippet from an
>> access.log from a transparent squid proxy, using sureproxy hitting playboy:
>>
>> 10.1.1.191 - - [28/Nov/2007:12:49:26 -0700] "GET
>> http://www.sureproxy.com/nph-index.cgi/011110A/http/www.playboy.com/imx/fron
>> tpage/2008-calendars.jpg HTTP/1.1" 200 366
>> "http://www.sureproxy.com/nph-index.cgi/011110A/http/www.playboy.com/"
>> "Opera/9.24 (Macintosh; Intel Mac OS X; U; en)" TCP_MISS:DIRECT
>>
>> Does my idea make sense or am I on crack :D
>>
>> James
>
> If you have a transparent squid proxy in place you can do ACL's and/or
> use squidguard or dans guardian.
>
> --
> Tagg McDonald
> Dutro Company
> 675 North 600 West
> Logan, UT 84321
> (435) 752-3921 x146
>
> -
> 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
>
Even with a proxy and filter in place, they can still circumvent using  
proxifier sites.  I block them at my firewall using the drop in my  
preroute.  I really dont care about the timeouts, if your going around  
the filter, your breaking policy.  Even then its hard to stop.  I cant  
use my transparent proxy for https, which a lot of the sites run.   
They will have http: and https:  both of which connect to the same  
site.  I have a list of close to 300 + sites I block at the firewall  
that I try to keep up to date, but new sites are out all the time.   
One thing I have found, is that snort rules help to detect when these  
things are happening.  Their are some policy rules that are able to  
detect when some of these sites are accessed or when someone is trying  
to use them.  In short, if anyone finds a way to block access to these  
sites 100% I would sure like to hear about it.  Short of denying  
access to the entire internet except for those sites specifically  
allowed.


-- 
Dwayne Hottinger
Network Administrator
Harrisonburg City Public Schools

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

Re: Forwarding traffic from public IP to public IP.

[Grant Taylor]

On 11/28/07 11:45, Jason Hawthorne wrote:
> So would the rules look like this than?  Because it doesn't seem to be 
> working.
> 
> iptables -t nat -A POSTROUTING -d DESTINATION-IP -j SNAT --to-source 
> DEBIAN-IP
> iptables -t nat -A PREROUTING -d DEBIAN-IP -j DNAT --to-destination 
> SOURCE-IP

No, you do not want to DNAT to SOURCE-IP.  You want to do something like 
the following:

On DEBIAN, you would want to do something like the following:

# Redirect traffic originally to DEBIAN to be to DESTINATION
iptables -t nat -A PREROUTING -d DEBIAN-IP -j DNAT --to-destination 
DESTINATION-IP
# SNAT DNATed traffic from DEBIAN to DESTINATION to be from DEBIAN
iptables -t nat -A POSTROUTING -d DESTINATION-IP -j SNAT --to-source 
DEBIAN-IP

SOURCE ---> DEBIAN ---> DESTINATION ---> DEBIAN ---> SOURCE



Grant. . . .

RE: Forwarding traffic from public IP to public IP.

[Jason Hawthorne]

> No, you do not want to DNAT to SOURCE-IP.  You want to do something
> like
> the following:
> 
> On DEBIAN, you would want to do something like the following:
> 
> # Redirect traffic originally to DEBIAN to be to DESTINATION
> iptables -t nat -A PREROUTING -d DEBIAN-IP -j DNAT --to-destination
> DESTINATION-IP
> # SNAT DNATed traffic from DEBIAN to DESTINATION to be from DEBIAN
> iptables -t nat -A POSTROUTING -d DESTINATION-IP -j SNAT --to-source
> DEBIAN-IP
> 
> SOURCE ---> DEBIAN ---> DESTINATION ---> DEBIAN ---> SOURCE

Thanks this worked like a charm! 

Re: Forwarding traffic from public IP to public IP.

[Grant Taylor]

On 11/28/07 14:11, Jason Hawthorne wrote:
> Thanks this worked like a charm!

You are welcome.  :)



Grant. . . .