Blocking Ads.

Blocking Ads.

[Ninad A]

Hope What I am asking is not idiotic.

When we block ads or any such things with iptables then there is lot of delay caused for the application to complete as it is expecting the data which has already been dropped.
Packets are dropped at IP Layer but who takes care of the delay caused to the application and how to minimize that delay ?

N.




      

Re: Blocking Ads.

[Curby]

On Tue, Jun 22, 2010 at 12:18 PM, Ninad A <ninad_adi@yahoo.com> wrote:
> When we block ads or any such things with iptables then there is lot of delay caused for the application to complete as it is expecting the data which has already been dropped.
> Packets are dropped at IP Layer but who takes care of the delay caused to the application and how to minimize that delay ?

As far as I know, ad blocking is more commonly performed using DNS, by
resolving domain names to 127.0.0.1, or to a server to serve up
notices of removed content (e.g. in a business environment, users
could request that sites be unblocked).  Is there a reason why you
want to block specific IP addresses instead of domains?

Anyway, I suspect that sending back appropriate ICMP error messages
instead of DROPing such requests would provide hints to clients that
they should give up instead of wait for a reply.

--Mike

Re: Blocking Ads.

[Jan Engelhardt]

On Tuesday 2010-06-22 20:18, Ninad A wrote:

>Hope What I am asking is not idiotic.
>
>When we block ads or any such things with iptables then there is lot of delay caused for the application to complete as it is expecting the data which has already been dropped.
>Packets are dropped at IP Layer but who takes care of the delay caused to the application and how to minimize that delay ?

You have to use REJECT for an immediate reponse/teardown, not DROP.

Re: Blocking Ads.

[Grant Taylor]

On 06/22/10 13:41, Curby wrote:
> As far as I know, ad blocking is more commonly performed using DNS, 
> by resolving domain names to 127.0.0.1, or to a server to serve up 
> notices of removed content (e.g. in a business environment, users 
> could request that sites be unblocked).  Is there a reason why you 
> want to block specific IP addresses instead of domains?

Agreed.  Normally this is done via DNS, or (IMHO) better via an 
application layer proxy.

If I was going to DNS poison names where content was served from, I'd 
either provide a place holder, or an HTTP 404 error so that the client 
could gracefully handle the missing (blocked) content.

> Anyway, I suspect that sending back appropriate ICMP error messages 
> instead of DROPing such requests would provide hints to clients that 
> they should give up instead of wait for a reply.

Agreed.  This is why you want to REJECT with an ICMP error message, so 
that clients (that will honer them) get an immediate notification that 
the connection has been blocked.

Not all clients will honor the ICMP rejection message.  But that is a 
client problem, not a flaw introduced by your firewall.  Returning an 
HTTP 404 error would probably be better handled than returning an ICMP 
unreachable message.



Grant. . . .

Re: Blocking Ads.

[Ninad A]

Thanks, for so prompt answers to all.

I am sorry for this state, but I am bit confused.

INFO : Mine is a simple UBUNTU system with kernel 2.6.34 behind ppp0 not a 
       security device which has LAN and WAN ports so that FORWARD chain 
       can be used.

1) Using REJECT target will definitely send an ICMP error message to the   
   opposite party but still that doesnt help connection at my machine  
   which times out and thats why application delay is caused.
   What might be the problem ?

2) That makes me to think on different line, whether to use iptables for
   content filtering or let Application proxy handle the case.
 
   This might be a newbie question.
3) How do I write a iptable rule for the DNS, i.e At the LOCAL INPUT HOOK
   in the filter table when the packet is received there is no trace
   of DNS. i.e Whatever we have is un-interpreted data, not in user format.

4) Finally, how to handle the missing content gracefully.
          i) Using Application Proxies
         ii) Apply iptables typical source ip address rules with REJECT.
        iii) Writing a custom iptable module according to individual 
             requirements.
         iv) Putting a place holder.

Thanks,
N
------------------------------------------------------------------------

For Reference.

> > As far as I know, ad blocking is more commonly
> performed using DNS, by resolving domain names to 127.0.0.1,
> or to a server to serve up notices of removed content (e.g.
> in a business environment, users could request that sites be
> unblocked).  Is there a reason why you want to block
> specific IP addresses instead of domains?
> 
> Agreed.  Normally this is done via DNS, or (IMHO)
> better via an application layer proxy.
> 
> If I was going to DNS poison names where content was served
> from, I'd either provide a place holder, or an HTTP 404
> error so that the client could gracefully handle the missing
> (blocked) content.
> 
> > Anyway, I suspect that sending back appropriate ICMP
> error messages instead of DROPing such requests would
> provide hints to clients that they should give up instead of
> wait for a reply.
> 
> Agreed.  This is why you want to REJECT with an ICMP
> error message, so that clients (that will honer them) get an
> immediate notification that the connection has been
> blocked.
> 
> Not all clients will honor the ICMP rejection
> message.  But that is a client problem, not a flaw
> introduced by your firewall.  Returning an HTTP 404
> error would probably be better handled than returning an
> ICMP unreachable message.
> 
> 
> 
> Grant. . . .




      

Re: Blocking Ads.

[Thomas Jacob]

On Wed, 2010-06-23 at 02:37 -0700, Ninad A wrote:
> Thanks, for so prompt answers to all.
> 
> I am sorry for this state, but I am bit confused.
> 
> INFO : Mine is a simple UBUNTU system with kernel 2.6.34 behind ppp0 not a 
>        security device which has LAN and WAN ports so that FORWARD chain 
>        can be used.
> 
> 1) Using REJECT target will definitely send an ICMP error message to the   
>    opposite party but still that doesnt help connection at my machine  
>    which times out and thats why application delay is caused.
>    What might be the problem ?

Try it with a TCP reset instead

As an example:

dig +short www.leo.org

iptables -A OUTPUT -p tcp -d 80.190.158.9 -j REJECT \
  --reject-with tcp-reset


time telnet www.leo.org
Trying 80.190.158.9...
telnet: Unable to connect to remote host: Connection refused

real    0m0.008s
user    0m0.000s
sys     0m0.010s

Apparently ICMP messages generated for local processes when going thru
OUTPUT somehow don't find their way back to the upper layers of the TCP
stack, or are possibly not generated at all.

Re: Blocking Ads.

[Ninad A]

Agreed, but output chain would work if the device is between internet
and internal network. 

Mine is a Host based firewall.
Tested Application Proxies, work fine in this case.I think I would go with it.

Thanks,
N


      

Re: Blocking Ads.

[Grant Taylor]

On 06/23/10 04:37, Ninad A wrote:
> Thanks, for so prompt answers to all.

You are welcome.

> INFO : Mine is a simple UBUNTU system with kernel 2.6.34 behind ppp0 
> not a security device which has LAN and WAN ports so that FORWARD 
> chain can be used.

You should be able to do much the same thing using the INPUT and / or 
OUTPUT chains.

> 1) Using REJECT target will definitely send an ICMP error message to 
> the opposite party but still that doesnt help connection at my 
> machine which times out and thats why application delay is caused. 
> What might be the problem ?

Not all applications honor the ICMP error message that comes back to 
then.  (Microsoft programs are notoriously bad about not honoring ICMP 
errors.)

This is why I was suggesting something like a 404 error.

This is the fault of the client software that is using your connection, 
not your firewall or its design.

> 2) That makes me to think on different line, whether to use iptables 
> for content filtering or let Application proxy handle the case.

Given equal capabilities, this is somewhat a personal preference issue.

Layer 3 firewalls are great at filtering packets based on layer 3 
information.

Application layer gateways (firewall) are great at filtering on 
application layer information.

An application layer gateway (firewall) can filter different domains on 
the same IP *much* easier than a layer 3 firewall.  (Layer 3 firewalls 
can be made to do this, but it is extremely difficult.)

Application layer gateways (firewall) is really only good for the given 
application.

Layer 3 firewalls are good at about any thing that can be done at layer 
3, application independent.

So you really want to choose what is going to fit your needs the best.

> This might be a newbie question.

If you have a genuine question it doesn't matter how ""new you are.  You 
want / need help, so we will help.

> 3) How do I write a iptable rule for the DNS, i.e At the LOCAL INPUT 
> HOOK in the filter table when the packet is received there is no 
> trace of DNS. i.e Whatever we have is un-interpreted data, not in 
> user format.

I would expect that the traffic would be seen as UDP port 53 in the 
INPUT chain, probably coming in the ppp0 interface.

You could probably also match the outgoing request as UDP port 53 in the 
OUTPUT chain, most likely going out the ppp0 interface.

> 4) Finally, how to handle the missing content gracefully.
>   i) Using Application Proxies

An application (layer) proxy (gateway / firewall) can more gracefully 
handle / filter traffic in such as it can return an error that the 
client will better understand.  I.e. it can return an HTTP 404 (not 
found) error rather than a dropped (with or with out reject) packet.

>  ii) Apply iptables typical source ip address rules with REJECT.

IPTables can reject the packet with an ICMP error message.  However 
doing so has a couple of draw backs:

    1)  The client application has to honor such ICMP error messages 
(many do not).
    2) the filtering happens later after the TCP 3-way handshake meaning 
that:
       a) the connection is established and will have to be dropped or 
reset.
       b) that you have to filter through more packets to find the 
criteria that you are filtering based on.

> iii) Writing a custom iptable module according to individual 
> requirements.

You could re-invent the wheel, but it would be a lot more effort than is 
probably needed.

I'd suggest that you look at transparent proxies.  You can use IPTables 
to redirect (standard) HTTP traffic in to a transparent proxy and let 
the application layer proxy (gateway / firewall) do what it's designed 
to do.

Honestly, I think this is probably your best approach, combine the best 
of both worlds to achieve what you are wanting to do with out going to a 
lot of effort.

>  iv) Putting a place holder.

Are you wanting to put in a place holder image or something else saying 
"denied" (or what ever wording you want)?

If you are wanting to do this, I think you will have to go with an 
application layer gateway (firewall).

To the best of my knowledge, IPTables (and it's brethren ARPTables, 
EBTables, xTables) don't have the ability to replace packets and later 
connections to the extend that is required to provide a place holder.

> Thanks,

*nod*



Grant. . . .

Re: Blocking Ads. Thanks.

[Ninad A]

> Honestly, I think this is probably your best approach,
> combine the best of both worlds to achieve what you are
> wanting to do with out going to a lot of effort.
> transparent proxy and application layer proxy.
> (gateway / firewall) do what it's designed to do.

Thanks, so Finally, I tested this seems to be a proper option for me.

Thanks to all greats out there. 
I close this rule in this mail chain. 

N.


> > Thanks, for so prompt answers to all.
> 
> You are welcome.
> 
> > INFO : Mine is a simple UBUNTU system with kernel
> 2.6.34 behind ppp0 not a security device which has LAN and
> WAN ports so that FORWARD chain can be used.
> 
> You should be able to do much the same thing using the
> INPUT and / or OUTPUT chains.
> 
> > 1) Using REJECT target will definitely send an ICMP
> error message to the opposite party but still that doesnt
> help connection at my machine which times out and thats why
> application delay is caused. What might be the problem ?
> 
> Not all applications honor the ICMP error message that
> comes back to then.  (Microsoft programs are
> notoriously bad about not honoring ICMP errors.)
> 
> This is why I was suggesting something like a 404 error.
> 
> This is the fault of the client software that is using your
> connection, not your firewall or its design.
> 
> > 2) That makes me to think on different line, whether
> to use iptables for content filtering or let Application
> proxy handle the case.
> 
> Given equal capabilities, this is somewhat a personal
> preference issue.
> 
> Layer 3 firewalls are great at filtering packets based on
> layer 3 information.
> 
> Application layer gateways (firewall) are great at
> filtering on application layer information.
> 
> An application layer gateway (firewall) can filter
> different domains on the same IP *much* easier than a layer
> 3 firewall.  (Layer 3 firewalls can be made to do this,
> but it is extremely difficult.)
> 
> Application layer gateways (firewall) is really only good
> for the given application.
> 
> Layer 3 firewalls are good at about any thing that can be
> done at layer 3, application independent.
> 
> So you really want to choose what is going to fit your
> needs the best.
> 
> > This might be a newbie question.
> 
> If you have a genuine question it doesn't matter how ""new
> you are.  You want / need help, so we will help.
> 
> > 3) How do I write a iptable rule for the DNS, i.e At
> the LOCAL INPUT HOOK in the filter table when the packet is
> received there is no trace of DNS. i.e Whatever we have is
> un-interpreted data, not in user format.
> 
> I would expect that the traffic would be seen as UDP port
> 53 in the INPUT chain, probably coming in the ppp0
> interface.
> 
> You could probably also match the outgoing request as UDP
> port 53 in the OUTPUT chain, most likely going out the ppp0
> interface.
> 
> > 4) Finally, how to handle the missing content
> gracefully.
> >   i) Using Application Proxies
> 
> An application (layer) proxy (gateway / firewall) can more
> gracefully handle / filter traffic in such as it can return
> an error that the client will better understand.  I.e.
> it can return an HTTP 404 (not found) error rather than a
> dropped (with or with out reject) packet.
> 
> >  ii) Apply iptables typical source ip address
> rules with REJECT.
> 
> IPTables can reject the packet with an ICMP error
> message.  However doing so has a couple of draw backs:
> 
>    1)  The client application has to
> honor such ICMP error messages (many do not).
>    2) the filtering happens later after the
> TCP 3-way handshake meaning that:
>       a) the connection is established and
> will have to be dropped or reset.
>       b) that you have to filter through
> more packets to find the criteria that you are filtering
> based on.
> 
> > iii) Writing a custom iptable module according to
> individual requirements.
> 
> You could re-invent the wheel, but it would be a lot more
> effort than is probably needed.
> 
> I'd suggest that you look at transparent proxies.  You
> can use IPTables to redirect (standard) HTTP traffic in to a
> transparent proxy and let the application layer proxy
> (gateway / firewall) do what it's designed to do.
> 
> Honestly, I think this is probably your best approach,
> combine the best of both worlds to achieve what you are
> wanting to do with out going to a lot of effort.
> 
> >  iv) Putting a place holder.
> 
> Are you wanting to put in a place holder image or something
> else saying "denied" (or what ever wording you want)?
> 
> If you are wanting to do this, I think you will have to go
> with an application layer gateway (firewall).
> 
> To the best of my knowledge, IPTables (and it's brethren
> ARPTables, EBTables, xTables) don't have the ability to
> replace packets and later connections to the extend that is
> required to provide a place holder.
> 
> > Thanks,
> 
> *nod*
> 
> 
> 
> 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
>