USADOTGOV.NET Root Problems?

[Merton Campbell Crockett]

On Jul 25, 2010, at 3:34 PM, Kevin Oberman wrote:

>> From: Warren Kumari <warren at kumari.net>
>> Date: Sun, 25 Jul 2010 11:22:46 +0200
>> Sender: bind-users-bounces+oberman=es.net at lists.isc.org
>> 
>> 
>> On Jul 25, 2010, at 4:33 AM, Danny Mayer wrote:
>> 
>>> On 7/24/2010 5:10 AM, Warren Kumari wrote:
>>>> 
>>>> On Jul 23, 2010, at 2:37 PM, Danny Mayer wrote:
>>>> 
>>>>> On 7/22/2010 11:08 PM, Merton Campbell Crockett wrote:
>>>>>> Thanks for the confirmation that the problem was related to DNSSEC.
>>>>>> 
>>>>>> I didn't see your message until I got home from work; however, I did
>>>>>> find the root of the problem late this afternoon.  At each of our
>>>>>> Internet egress and ingress points, we have Cisco ASA devices sitting in
>>>>>> front of a pair of redundant firewalls.  Each ASA is configured with the
>>>>>> default DNS inspect policy that doesn't accept fragmented UDP packets.
>>>>> 
>>>>> Why would any inspection policy not allow fragmented UDP packets?
>>>>> There's nothing wrong with that.
>>>> 
>>>> 
>>>> Because it's "hard".... The issue is that then you need to buffer
>>> fragments until you get a full packet -- which leaves you open to
>>> attacks that send a bunch of fragments but leave one of them out.
>>>> 
>>>> Vendors like to avoid reassembling fragments by default, because it
>>> makes their performance numbers better....
>>> 
>>> At the expense of correct behavior and loss of real performance.
>> 
>> Yes. 
>> 
>> Sorry, if I gave the impression that I was condoning this -- I'm not.
>> 
>> Vendors exist to sell boxen -- tuning for the test cases at the
>> expense of correctness often wins....
> 
> And, as tests start to include DNSSEC (and EDNS0) tests, the vendors will
> likely adjust defaults. Tests for DNSSEC are already appearing on
> federal systems (not a trivial part of the business) and will likely
> become general test in the procurement process in the next year. 
> 
> Of course, changing defaults will take longer to change.
> 
> Now to a more basic question...why the ^@#$ does everyone put STATEFUL
> firewalls in front of servers. They are a denial of service attack
> waiting to happen. I don't know of any highly regarded security expert
> who recommends them and most object to them rather strongly.
> 
> I will admit to once having stateful firewalls in front of my DNS
> servers, but after an unfortunate case of a badly written application
> DOSing ourselves, stateful firewalls have been removed. Yes, the software
> needed fixing, but the software was not enough to cause any problem for
> the servers...just the firewall. And, yes, we still have stateless
> firewalls in front of our DNS servers and other public servers as well
> as an aggressive IDS/IPS system.

Here!  Here!  I much prefer using "packet filter" firewalls at the outer markers but haven't been able to sway security or my network colleagues.

For those interested, the error code is ASA-4-209005.  The error is that the message contains more than 1 element.  So far the first "fix" didn't solve the problem and I haven't seen what problems that the next layer of firewalls will produce.


--
Merton Campbell Crockett
m.c.crockett at roadrunner.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20100726/f20538e7/attachment.html>