On Mon, Apr 1, 2013 at 8:11 AM, Michael H. Warfield <mhw@xxxxxxxxxxxx> wrote:
> It's the the job of your security
> perimeter firewalls to filter local vrs foreign packets and on-session
> vrs unsolicited packets.
You say that as though everyone has such tools. Or that they are such
an integrated part of the TCP/IP standards that applications can
simply assume that it is someone else's problem... But I don't think
that is generally true - or that the concept even makes sense in the
context of the redundant routing TCP/IP is clearly designed to handle.
You might instead say that people are forced to add specialized
tools like that by stupid applications that are easy to exploit if you
don't...
> If you absolutely MUST combine them (and I would love to hear the
> rational as to why, beyond cost and laziness) then, by all means,
> restrict recursion to your local networks, with the understanding that
> they can still be abused to attack yourself..
The rationale is that the applications were written that way. Put
the blame on the design where it belongs. And talk about it in terms
of people later being essentially forced to deal with the fallout from
the design by having to change the buried IP address configurations
that the DNS system was supposed to avoid having to do in the first
place.
> I don't know where you are in the Internet "food chain" (end consumer,
> ISP, Tier 1 provider, or backbone) but if you are in the routing chain
> (you manage or provide routing - anyone other than an end consumer) then
> it's also very important to implement BCP (Best Common Practice) 38.
> BCP 38 recommends router egress filtering. That is, you only route out
> what will route back in. That prevents you (or any of your customers)
> from being a spoofing source. That strikes at the heart of many of
> these types of attacks.
So, what tools do that in combination with dynamic routing protocols?
And with asymmetric routes?
> Routing issues and BCP38 aside, you really should separate your
> authoritative an recursive name servers if at all possible.
I don't disagree with that, but I look as a workaround to fix an
initial bad design and wouldn't call the people who haven't
accomplished it yet lazy.
--
Les Mikesell
lesmikesell@xxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
