Re: Blocking Ads.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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. . . .




      
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux