PF & BLOCK MP3 (AVI)

[Christopher D. Lewis]

On Jul 14, 2005, at 2:11 PM, alex-bsd wrote:
> On a gateway for a local network in rules of firewall it is  
> possible to add a following line:
> -A FORWARD -s 192.168.x.x -p tcp -m string --string ".mp3" -j DROP
> If the internal client of this network requests a resource with  
> name containing ".mp3" he will not receive the answer (www.mp3.com,  
> www.music.com/Mozart.mp3, etc.).
> Accordingly similar is possible to make with words "porno" "avi"  
> and etc.
> I do not consider that it is 100 % protection against downloading  
> (from internet) by users mp3 files.

Not only is it not 100% protection, but the cost of doing this is  
astronomical, requiring serious changes to how the kernel handles  
packets (e.g., the kernel reassembles the packets), the RAM required  
to run pf (you could be simultaneously reassembling a large number of  
packets, which could include a large number of maliciously crafted  
packets whose transmission are never actually completed by the  
attacker), and the security of the system (DoS is facilitated by  
dramatic resource consumption of the proposed feature.

The request for www.music.com/mozart.mp3 is not guaranteed to be  
contained in a single packet.  You would have to assemble whole  
streams of packets to conduct the investigation your proposed rule  
would require in order to operate in every case, rather than only in  
the occasional case in which ".mp3" happened to occur in a single  
packet.  This does not mean the packet might not get fragmented by  
the time your firewall sees it, though.

I think the reasons for omitting this sort of "feature" in a firewall  
have been adequately discussed on pf-related lists.  Using your  
firewall to restrict access to DNS servers other than the one  
containing your whitelisted sites might be a strategy, or using  
proxies to conduct filtering on streams, but cramming this into the  
kernel is an invitation for in-kernel bugs, denial of service, loss  
of use of hardware that used to be able to run your pf-containing OS  
but cannot with new resource consumption, and as you so eloquently  
state you still don't really stop this, you just invite attackers (or  
authors of filesharing apps, or whomever) to write around your new  
filter strategy.

On the other hand, if you are willing to risk $500, Daniel has said  
he is game to test just how effective the feature is :-)

Best regards,
     Chris