<div style="font-family:arial,helvetica,sans-serif;font-size:10pt">On Wed, Nov 28, 2012 at 1:43 AM, Benedikt Stockebrand <span dir="ltr"><<a href="mailto:me@benedikt-stockebrand.de" target="_blank">me@benedikt-stockebrand.de</a>></span> wrote:<br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Using a default setting with a "diode configuration" (I don't really like to use the term "firewall" here) and an option that allows users to change that behaviour sounds like the safest option to me---for both the customer and the ISP.</blockquote>
<div><br></div><div>But the one-way configuration is ham-fisted and stupid and ends up being overkill in many cases.</div><div><br></div><div>Suppose you see a packet inbound to port tcp/445 (or 139, or whatever the Windows ports are). How likely is that to be an attack? Probably fairly likely. It seems reasonable to block it - after all, if the user is trying to set up Windows file sharing across the Internet, they either know what they're doing or it won't work.</div>
<div><br></div><div>On the other hand, say your CPE sees a UDP packet from port 61209 to port 48993, from a flow it hasn't seen before. Is it an attack? Or is there just a missing state entry because it's part of a peer-to-peer protocol (e.g., video chat) - or if the router lost state due to a reboot, timeout, state overflow, or anything else?</div>
<div><br></div><div>I would argue that that packet is extremely unlikely to be an unsolicited attack. The chances of an attacker successfully mounting an attack like that without any prior knowledge are basically zero - there are way better avenues of attack than that. The packet is much more likely to be a video chat, peer-to-peer or RTSP packet that the user actually wants. but the one-way configuration blocks it anyway, because "zomg it comes from outside drop it!!1".</div>
<div><br></div><div>If you will, it's a bit like pouring reinforced concrete on the floor of your garage just in case someone steals your car by digging a tunnel into the garage - sure, it prevents that particular mode of theft, but who's going to do that, really?</div>
<div><br></div><div>Always remember that if the user is running a binary that listens on port udp/48993, then you have already lost - because all that binary needs to do is the extra, trivial step of setting up a rendezvous point (heck, even a teredo tunnel) to allow unsolicited incoming traffic anyway. And what does the firewall buy you? Nothing, really.</div>
<div><br></div><div>Well, perhaps not quite nothing. It does allows you to CYA. ("We give users firewalls! Our connection is super safe! It's not our fault they get hacked!!!"). That may be enough for many, and certainly in certain countries (e.g., the USA), it's very important. But it's not really a good reason, I think. We should be able to do better than that.</div>
</div></div>