Date: Mon, 18 Jul 2005 23:26:22 -0500 From: "Christopher D. Lewis" <Lewis@Alumni.Duke.edu> To: alex-bsd@yandex.ru Cc: freebsd-pf@freebsd.org Subject: Re: PF & BLOCK MP3 (AVI) Message-ID: <73864AD4-7FCF-4087-9069-BB42E0FAC8C5@Alumni.Duke.edu> In-Reply-To: <42D6B8D9.000001.16708@mfront7.yandex.ru> References: <42D6B8D9.000001.16708@mfront7.yandex.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?73864AD4-7FCF-4087-9069-BB42E0FAC8C5>