Re: SANS: DNS Bug Now Public?

[Steven M. Bellovin]

On Tue, 22 Jul 2008 08:00:51 -0500
"Jorge Amodio" <[EMAIL PROTECTED]> wrote:

> It has been public for a while now. Even on the print media, there
> are some articles about it on the latest Computerworld mag without
> giving too much detail about how to exploit it.
> 
> ie PATCH NOW !!!
> 
Kaminsky's blog says "Patch.  Today.  Now. Yes, stay late."


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Software router state of the art

[Zed Usser]

Hi all!

There's been some discussion on the list regarding software routers lately and 
this piqued my interest. Does anybody have any recent performance and 
capability statistics (eg. forwarding rates with full BGP tables and N ethernet 
interfaces) or any pointer to what the current state of art in software routers 
is?

- Zed


  

Re: Software router state of the art

[Valdis . Kletnieks]

On Wed, 23 Jul 2008 02:52:56 PDT, Zed Usser said:
> There's been some discussion on the list regarding software routers

The performance of "software routers" has always had a hardware component.

Basically, for the vast majority of them, take your PCI bus bandwidth,
count how many times a packet has to cross it, and do the math.  You can't
forward more than that much traffic no matter *what* software you run on
that box.  If that number falls short, stop right there and look for
some box of different design that has the required backplane bandwidth.

You will, of course, take additional performance hits due to locking issues
and similar in your software stack (that, and most "software" routers will
suffer from not having special hardware assist for routing table lookups).

Let us know if you find a suitable chassis/motherboard that has enough
bandwidth to make it worth thinking about for anything other than the
smaller edge routers that most providers have zillions of... :)



pgp0gGVsylFmF.pgp
Description: PGP signature

Re: Software router state of the art

[Charles Wyble]

[EMAIL PROTECTED] wrote:

On Wed, 23 Jul 2008 02:52:56 PDT, Zed Usser said:
  

There's been some discussion on the list regarding software routers



The performance of "software routers" has always had a hardware component.

Basically, for the vast majority of them, take your PCI bus bandwidth,
count how many times a packet has to cross it, and do the math.  You can't
forward more than that much traffic no matter *what* software you run on
that box.  If that number falls short, stop right there and look for
some box of different design that has the required backplane bandwidth.
  


This might be of interest:

http://nrg.cs.ucl.ac.uk/mjh/tmp/vrouter-perf.pdf


--

Charles Wyble (818) 280 - 7059
http://charlesnw.blogspot.com
CTO Known Element Enterprises / SoCal WiFI project

Re: Software router state of the art

[William Herrin]

On Wed, Jul 23, 2008 at 11:24 AM,  <[EMAIL PROTECTED]> wrote:
> On Wed, 23 Jul 2008 02:52:56 PDT, Zed Usser said:
>> There's been some discussion on the list regarding software routers
>
> The performance of "software routers" has always had a hardware component.
>
> Basically, for the vast majority of them, take your PCI bus bandwidth,
> count how many times a packet has to cross it, and do the math.  You can't
> forward more than that much traffic no matter *what* software you run on
> that box.  If that number falls short, stop right there and look for
> some box of different design that has the required backplane bandwidth.

The Endace DAG cards claim they can move 7 gbps over a PCI-X bus from
the NIC to main DRAM. They claim a full 10gbps on a PCIE bus.

Regards,
Bill Herrin



-- 
William D. Herrin  [EMAIL PROTECTED] [EMAIL PROTECTED]
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: SANS: DNS Bug Now Public?

[Jorge Amodio]

Let me add that folks need to understand that the "patch" is not a fix to a
problem that has been there for long time and
it is just a workaround to reduce the chances for a potential
attack, and it must be combined with best practices and
recommendations to implent a more robust DNS setup.

There are plenty of documents out there (check cert.org for example) that
can provide some guidance.

Perhaps this situation will help move things on the DNSSEC front, as far as
I remember there are some IETF drafts on
the standards track addressing these issues.
Cheers
Jorge
On Wed, Jul 23, 2008 at 2:31 AM, Steven M. Bellovin <[EMAIL PROTECTED]>
wrote:

>  On Tue, 22 Jul 2008 08:00:51 -0500
> "Jorge Amodio" <[EMAIL PROTECTED]> wrote:
>
> > It has been public for a while now. Even on the print media, there
> > are some articles about it on the latest Computerworld mag without
> > giving too much detail about how to exploit it.
> >
> > ie PATCH NOW !!!
> >
> Kaminsky's blog says "Patch.  Today.  Now. Yes, stay late."
>
>
>--Steve Bellovin, http://www.cs.columbia.edu/~smb
>

Re: Software router state of the art

[Adrian Chadd]

On Wed, Jul 23, 2008, Charles Wyble wrote:

> This might be of interest:
> 
> http://nrg.cs.ucl.ac.uk/mjh/tmp/vrouter-perf.pdf

Various FreeBSD related guys are working on parallelising the forwarding
layer enough to use the multiple tx/rx queues in some chipsets such as the
Intel gig/10ge stuff.

1 mil pps has been broken that way, but it uses lots of cores to get there.
(8, I think?)

Linux apparently is/has headed down this path.

If someone were to spend some time dissecting the rest of the code to
also optimise the single-core throughput then you may see some interesting
software routers using commodity hardware (for values of "commodity"
roughly equal to "PC servers", rather than "magic lotsacore core MIPS with
some extra glue for jacking packets around."

Sure its not a CRS-1, but reliably doing a mil pps with a smattering of
low-touch features would be rather useful, no?

(Then, add say, l2tp/ppp into that mix, just as a crazy on-topic example..)



Adrian

Re: Software router state of the art

[Chris Marlatt]

Adrian Chadd wrote:


1 mil pps has been broken that way, but it uses lots of cores to get there.
(8, I think?)



http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2008-06/msg00364.html 
has all the details. It's rather long thread but 1mpps was achieved on a 
single cpu IIRC (the server had multiple cpus but only one being used 
for forwarding). Firewall rules slowed it down quite a bit but theres 
also some work out there being done to minimize this.


Regards,

Chris

Re: Software router state of the art

[Adrian Chadd]

On Wed, Jul 23, 2008, Chris Marlatt wrote:

> http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2008-06/msg00364.html 
> has all the details. It's rather long thread but 1mpps was achieved on a 
> single cpu IIRC (the server had multiple cpus but only one being used 
> for forwarding). Firewall rules slowed it down quite a bit but theres 
> also some work out there being done to minimize this.

Yah, all of that is happening. Some people keep asking why FreeBSD-4
forwarding was always much faster than same-hardware forwarding under
current FreeBSD but at least thats finally being worked on.

Of course, with my FreeBSD advocacy hat on, if you -want- to see
something like FreeBSD handle 1mil+ pps forwarding then you should
really drop the FreeBSD Foundation a line and introduce yourself.
There are developers working on this (note: not me! :) who would
benefit from equipment and funding.

Anyway. Some PC class hardware is pretty damned fast. Some vendors
even build highish-throughput firewalls and proxies out of PC class
hardware. :) The "wah wah PC class hardware has anemic bus IO/memory IO/
CPU speed/ethernet modules and is thus too crap for serious routing" argument
is pretty much over for at least 1 mil pps, perhaps more.

2c,


Adrian

Re: Software router state of the art

[Joel Jaeggli]

[EMAIL PROTECTED] wrote:

On Wed, 23 Jul 2008 02:52:56 PDT, Zed Usser said:

There's been some discussion on the list regarding software routers


The performance of "software routers" has always had a hardware component.

Basically, for the vast majority of them, take your PCI bus bandwidth,
count how many times a packet has to cross it, and do the math.  You can't
forward more than that much traffic no matter *what* software you run on
that box.  If that number falls short, stop right there and look for
some box of different design that has the required backplane bandwidth.

You will, of course, take additional performance hits due to locking issues
and similar in your software stack (that, and most "software" routers will
suffer from not having special hardware assist for routing table lookups).


The current state of the art is around 2 million pps for fast intel arch 
system.



Let us know if you find a suitable chassis/motherboard that has enough
bandwidth to make it worth thinking about for anything other than the
smaller edge routers that most providers have zillions of... :)

Re: Software router state of the art

[randal k]

That is a very interesting paper. Seriously, 7mpps with an
off-the-shelf Dell 2950? Even if it were -half- that throughput, for a
pure ethernet forwarding solution that is incredible. Shoot, buy a
handful of them as hot spares and still save a bundle.

Highly recommended reading, even if (like me) you're anti-commodity routing.

Cheers,
Randal

On Wed, Jul 23, 2008 at 10:17 AM, Adrian Chadd <[EMAIL PROTECTED]> wrote:
> On Wed, Jul 23, 2008, Charles Wyble wrote:
>
>> This might be of interest:
>>
>> http://nrg.cs.ucl.ac.uk/mjh/tmp/vrouter-perf.pdf
>
> Various FreeBSD related guys are working on parallelising the forwarding
> layer enough to use the multiple tx/rx queues in some chipsets such as the
> Intel gig/10ge stuff.
>
> 1 mil pps has been broken that way, but it uses lots of cores to get there.
> (8, I think?)
>
> Linux apparently is/has headed down this path.

Re: Software router state of the art

[Adam Armstrong]

Adrian Chadd wrote:

On Wed, Jul 23, 2008, Charles Wyble wrote:


Sure its not a CRS-1, but reliably doing a mil pps with a smattering of
low-touch features would be rather useful, no?

(Then, add say, l2tp/ppp into that mix, just as a crazy on-topic example..)
  
Sounds like a Juniper J-series. Have a look at the forwarding figures 
for the J6350. It does something around 2mpps and it's just an intel CPU 
with some PCI/PCI-X interfaces. The device just below it, the J4350 uses 
a 2.53Ghz celeron. I'm not sure what the J6350 uses.


adam.

Re: Software router state of the art

[Naveen Nathan]

> The Endace DAG cards claim they can move 7 gbps over a PCI-X bus from
> the NIC to main DRAM. They claim a full 10gbps on a PCIE bus.

I wonder, has anyone heard of this used for IDS? I've been looking at
building a commodity SNORT solution, and wondering if a powerful network
card will help, or would the bottleneck be in processing the packets and
overhead from the OS?

- naveen

Re: Software router state of the art

[Chris Adams]

Once upon a time, Adam Armstrong <[EMAIL PROTECTED]> said:
> Sounds like a Juniper J-series. Have a look at the forwarding figures 
> for the J6350. It does something around 2mpps and it's just an intel CPU 
> with some PCI/PCI-X interfaces. The device just below it, the J4350 uses 
> a 2.53Ghz celeron. I'm not sure what the J6350 uses.

IIRC the new slots (the EPIMs) are PCI-E.  The J6350 CPU is a P4 3.4GHz.
It is my understanding that the J-series use a real-time layer under the
FreeBSD kernel and have a real-time thread for forwarding (as opposed to
the M-series with a hardware forwarding engine).

-- 
Chris Adams <[EMAIL PROTECTED]>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

Re: Software router state of the art

[William Herrin]

On Wed, Jul 23, 2008 at 2:03 PM, Naveen Nathan <[EMAIL PROTECTED]> wrote:
>> The Endace DAG cards claim they can move 7 gbps over a PCI-X bus from
>> the NIC to main DRAM. They claim a full 10gbps on a PCIE bus.
>
> I wonder, has anyone heard of this used for IDS? I've been looking at
> building a commodity SNORT solution, and wondering if a powerful network
> card will help, or would the bottleneck be in processing the packets and
> overhead from the OS?

The first bottleneck is the interrupts from the NIC. With a generic
Intel NIC under Linux, you start to lose a non-trivial number of
packets around 700mbps of "normal" traffic because it can't service
the interrupts quickly enough.

The DAG card can be dropped in to replace the interface used for a
libpcap-based application. When I tested the 1gbps PCIE version, I
lost no packets to 1gbps and my capture application's CPU usage
dropped to about 1/5th of what it was with the generic NIC. YMMV.

Regards,
Bill Herrin


-- 
William D. Herrin  [EMAIL PROTECTED] [EMAIL PROTECTED]
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: SANS: DNS Bug Now Public?

[Joe Abley]

On 23 Jul 2008, at 12:16, Jorge Amodio wrote:

Let me add that folks need to understand that the "patch" is not a  
fix to a

problem that has been there for long time and
it is just a workaround to reduce the chances for a potential
attack, and it must be combined with best practices and
recommendations to implent a more robust DNS setup.


Having just seen some enterprise types spend time patching their  
nameservers, it's also perhaps worth spelling out that "patch" in this  
case might require more than upgrading resolver code -- it could also  
involve reconfigurations, upgrades or replacements of NAT boxes too.  
If your NAT reassigns source ports in a predictable fashion, then no  
amount of BIND9 patching is going to help.


(Reconfiguring your internal resolvers to forward queries to an  
external, patched resolver which can see the world other than through  
NAT-coloured glasses may also be a way out.)



Joe

Re: Software router state of the art

[Christopher Morrow]

On Wed, Jul 23, 2008 at 11:05 AM, Naveen Nathan <[EMAIL PROTECTED]> wrote:
>> The Endace DAG cards claim they can move 7 gbps over a PCI-X bus from
>> the NIC to main DRAM. They claim a full 10gbps on a PCIE bus.
>
> I wonder, has anyone heard of this used for IDS? I've been looking at
> building a commodity SNORT solution, and wondering if a powerful network
> card will help, or would the bottleneck be in processing the packets and
> overhead from the OS?

http://www.endace.com/our-products/ninja-appliances/NinjaProbe-NIDS

snort at 1g & 10g

-chris

Re: Software router state of the art

[Wes Young]

We use them here and there (the 1Gig versions). The biggest thing to  
think about is the types of rule-sets you'll be using compounded by  
the number of flows being created / expired. Once tuned, they work  
quite well, but the balance is how fast you can pull/analyze out of  
RAM. Compiling the rules down to the card's level speeds things up a  
bit, but at the loss of using more dynamic rulesets.


If you can get the raw data to some sort of larger medium (say,  
rotating pcaps on a disk), you length the buffer-window. FWIW however,  
probably the best way to scale this is get an Xport fiber regen tap,  
populate with a few of these, tune them to monitor different segments  
based on address space or port ranges. You'll have yourself a  
relatively cheap solution, but extremely effective solution.


I've yet to test out the NinjaProbes... It's on my todo list...

On Jul 23, 2008, at 2:21 PM, Christopher Morrow wrote:

On Wed, Jul 23, 2008 at 11:05 AM, Naveen Nathan <[EMAIL PROTECTED]>  
wrote:
The Endace DAG cards claim they can move 7 gbps over a PCI-X bus  
from

the NIC to main DRAM. They claim a full 10gbps on a PCIE bus.


I wonder, has anyone heard of this used for IDS? I've been looking at
building a commodity SNORT solution, and wondering if a powerful  
network
card will help, or would the bottleneck be in processing the  
packets and

overhead from the OS?


http://www.endace.com/our-products/ninja-appliances/NinjaProbe-NIDS

snort at 1g & 10g

-chris



--
Wes Young
Network Security Analyst
CIT - University at Buffalo
http://claimid.com/saxjazman9









smime.p7s
Description: S/MIME cryptographic signature

Re: SANS: DNS Bug Now Public?

[Darren Bolding]

After a bit of looking around, I have not been able to find a list of
firewalls/versions which are known to provide appropriate randomness in
their PAT algorithms (or more importantly, those that do not).

I would be very interested in such a list if anyone knows of one.

As a side note, most people here realize this but, while people mention
firewalls, keep in mind that if a load-balancer or other device is your
egress PAT device, you might be interested in checking those systems
port-translation randomness as well.

--D

On Wed, Jul 23, 2008 at 10:11 AM, Joe Abley <[EMAIL PROTECTED]> wrote:

>
> On 23 Jul 2008, at 12:16, Jorge Amodio wrote:
>
> Let me add that folks need to understand that the "patch" is not a fix to a
>> problem that has been there for long time and
>> it is just a workaround to reduce the chances for a potential
>> attack, and it must be combined with best practices and
>> recommendations to implent a more robust DNS setup.
>>
>
> Having just seen some enterprise types spend time patching their
> nameservers, it's also perhaps worth spelling out that "patch" in this case
> might require more than upgrading resolver code -- it could also involve
> reconfigurations, upgrades or replacements of NAT boxes too. If your NAT
> reassigns source ports in a predictable fashion, then no amount of BIND9
> patching is going to help.
>
> (Reconfiguring your internal resolvers to forward queries to an external,
> patched resolver which can see the world other than through NAT-coloured
> glasses may also be a way out.)
>
>
> Joe
>
>
>


-- 
-- Darren Bolding --
-- [EMAIL PROTECTED] --

Re: Software router state of the art

[Jeffrey Ollie]

On Wed, Jul 23, 2008 at 11:17 AM, Adrian Chadd <[EMAIL PROTECTED]> wrote:
>
> Various FreeBSD related guys are working on parallelising the forwarding
> layer enough to use the multiple tx/rx queues in some chipsets such as the
> Intel gig/10ge stuff.
>
> Linux apparently is/has headed down this path.

I've seen some notes from Dave Miller about adding multiple TX queues
to the 2.6.27 kernel.  See Dave's blog for the gory details:

http://vger.kernel.org/~davem/cgi-bin/blog.cgi
http://git.kernel.org/?p=linux/kernel/git/davem/net-tx-2.6.git;a=summary

AFAIK he hasn't made any claims about performance improvements.  I
don't know the state of RX queues in Linux.

Jeff

Re: Software router state of the art

[Kevin Oberman]

> Date: Wed, 23 Jul 2008 14:17:53 -0400
> From: "William Herrin" <[EMAIL PROTECTED]>
> 
> On Wed, Jul 23, 2008 at 2:03 PM, Naveen Nathan <[EMAIL PROTECTED]> wrote:
> >> The Endace DAG cards claim they can move 7 gbps over a PCI-X bus from
> >> the NIC to main DRAM. They claim a full 10gbps on a PCIE bus.
> >
> > I wonder, has anyone heard of this used for IDS? I've been looking at
> > building a commodity SNORT solution, and wondering if a powerful network
> > card will help, or would the bottleneck be in processing the packets and
> > overhead from the OS?
> 
> The first bottleneck is the interrupts from the NIC. With a generic
> Intel NIC under Linux, you start to lose a non-trivial number of
> packets around 700mbps of "normal" traffic because it can't service
> the interrupts quickly enough.

Most modern high performance network cards support MSI (Message Signaled
Interrupts) which generate real interrupts only in an intelligent
basis. and only at a controlled rate. Windows, Solaris and FreeBSD have
support for MSI and I think Linux does, too. It requires both hardware
and software support.

With MSI, TSO, LRO, and PCI-E with hardware that supports these, 9.5
Gbps TCP flows between systems is possible with minimal tuning. That
puts the bottleneck back on the forwarding software in the CPU to do
the forwarding at high rates.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: [EMAIL PROTECTED]   Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751


pgpQ9niz4enfu.pgp
Description: PGP signature

Re: Software router state of the art

[William Herrin]

On Wed, Jul 23, 2008 at 3:59 PM, Kevin Oberman <[EMAIL PROTECTED]> wrote:
>> The first bottleneck is the interrupts from the NIC. With a generic
>> Intel NIC under Linux, you start to lose a non-trivial number of
>> packets around 700mbps of "normal" traffic because it can't service
>> the interrupts quickly enough.
>
> Most modern high performance network cards support MSI (Message Signaled
> Interrupts) which generate real interrupts only in an intelligent
> basis. and only at a controlled rate. Windows, Solaris and FreeBSD have
> support for MSI and I think Linux does, too. It requires both hardware
> and software support.

"ethtool -c". Thanks Sargun for putting me on to "I/O Coalescing."

But cards like the Intel Pro/1000 have 64k of memory for buffering
packets, both in and out. Few have very much more than 64k. 64k means
32k to tx and 32k to rx. Means you darn well better generate an
interrupt when you get near 16k so that you don't fill the buffer
before the 16k you generated the interrupt for has been cleared. Means
you're generating an interrupt at least for every 10 or so 1500 byte
packets.

Regards,
Bill



-- 
William D. Herrin  [EMAIL PROTECTED] [EMAIL PROTECTED]
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: SANS: DNS Bug Now Public?

[Jasper Bryant-Greene]

FWIW, anyone using iptables for NAT can use --random, e.g.:

iptables -t nat -A POSTROUTING -o ethX -j SNAT --to x.x.x.x --random

Useful for Linux NAT/load-balancer boxes, or for Linux-powered embedded
devices where the vendor has not been forthcoming with a firmware patch
to alter the rules they generate.

I believe this requires kernel >= 2.6.21.

-Jasper

On Wed, 2008-07-23 at 12:16 -0700, Darren Bolding wrote:
> After a bit of looking around, I have not been able to find a list of
> firewalls/versions which are known to provide appropriate randomness in
> their PAT algorithms (or more importantly, those that do not).
> 
> I would be very interested in such a list if anyone knows of one.
> 
> As a side note, most people here realize this but, while people mention
> firewalls, keep in mind that if a load-balancer or other device is your
> egress PAT device, you might be interested in checking those systems
> port-translation randomness as well.
> 
> --D
> 
> On Wed, Jul 23, 2008 at 10:11 AM, Joe Abley <[EMAIL PROTECTED]> wrote:
> 
> >
> > On 23 Jul 2008, at 12:16, Jorge Amodio wrote:
> >
> > Let me add that folks need to understand that the "patch" is not a fix to a
> >> problem that has been there for long time and
> >> it is just a workaround to reduce the chances for a potential
> >> attack, and it must be combined with best practices and
> >> recommendations to implent a more robust DNS setup.
> >>
> >
> > Having just seen some enterprise types spend time patching their
> > nameservers, it's also perhaps worth spelling out that "patch" in this case
> > might require more than upgrading resolver code -- it could also involve
> > reconfigurations, upgrades or replacements of NAT boxes too. If your NAT
> > reassigns source ports in a predictable fashion, then no amount of BIND9
> > patching is going to help.
> >
> > (Reconfiguring your internal resolvers to forward queries to an external,
> > patched resolver which can see the world other than through NAT-coloured
> > glasses may also be a way out.)
> >
> >
> > Joe
> >
> >
> >
> 
> 

Re: Software router state of the art

[Kevin Oberman]

> Date: Wed, 23 Jul 2008 16:51:50 -0400
> From: "William Herrin" <[EMAIL PROTECTED]>
> Sender: [EMAIL PROTECTED]
> 
> On Wed, Jul 23, 2008 at 3:59 PM, Kevin Oberman <[EMAIL PROTECTED]> wrote:
> >> The first bottleneck is the interrupts from the NIC. With a generic
> >> Intel NIC under Linux, you start to lose a non-trivial number of
> >> packets around 700mbps of "normal" traffic because it can't service
> >> the interrupts quickly enough.
> >
> > Most modern high performance network cards support MSI (Message Signaled
> > Interrupts) which generate real interrupts only in an intelligent
> > basis. and only at a controlled rate. Windows, Solaris and FreeBSD have
> > support for MSI and I think Linux does, too. It requires both hardware
> > and software support.
> 
> "ethtool -c". Thanks Sargun for putting me on to "I/O Coalescing."
> 
> But cards like the Intel Pro/1000 have 64k of memory for buffering
> packets, both in and out. Few have very much more than 64k. 64k means
> 32k to tx and 32k to rx. Means you darn well better generate an
> interrupt when you get near 16k so that you don't fill the buffer
> before the 16k you generated the interrupt for has been cleared. Means
> you're generating an interrupt at least for every 10 or so 1500 byte
> packets.

You have just hit on a huge problems with most (all?) 1G and 10G
hardware. The buffers are way too small for optimal performance in any
case where the RTT is anything more that half a millisecond, you exhaust
the window and stall the stream.

I need port move multi-gigabit streams across the country and between the
US and Europe. Those are a bit too far apart for those tiny buffers to
be of any use at all. This would require 3 GB of buffers. This same
problem also make TCP off-load of no use at all.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: [EMAIL PROTECTED]   Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751


pgpMiyt2bekzk.pgp
Description: PGP signature

sizing router buffers (Re: Software router state of the art )

[Mikael Abrahamsson]

On Wed, 23 Jul 2008, Kevin Oberman wrote:


be of any use at all. This would require 3 GB of buffers. This same
problem also make TCP off-load of no use at all.


3 Gigabyte? Why?

The newer 40G platforms on the market seems to have abandonded the 600ms 
buffers typical in the 10G space, in favour of 50-200ms of buffers (I 
don't remember exactly).


Aren't there TCP implementations that don't use exponential window 
increase, but instead can do smaller increments, which I would have 
believed would enable routers to still do well with ~50ms of buffering.


High speed memory is very expensive, also a lot of applications today 
would prefer to have their packets dropped instead of being queued for 
hundreds of milliseconds. Finding a good tradeoff level between the demand 
of different traffic types is quite hard...


Also, DWDM capacity seems to get cheaper all the time, so if you really 
need to move data at multigigabit speeds, it might make sense to just rent 
that 10G wave and put your own equipment there that does what you want.


--
Mikael Abrahamssonemail: [EMAIL PROTECTED]

Exploit for DNS Cache Poisoning - RELEASED

[Robert D. Scott]

Now, there is an exploit for it.

http://www.caughq.org/exploits/CAU-EX-2008-0002.txt

Robert D. Scott [EMAIL PROTECTED]
Senior Network Engineer 352-273-0113 Phone
CNS - Network Services  352-392-2061 CNS Receptionist
University of Florida   352-392-9440 FAX
Florida Lambda Rail 352-294-3571 FLR NOC
Gainesville, FL  32611  321-663-0421 Cell

Re: Exploit for DNS Cache Poisoning - RELEASED

[Joe Greco]

> Now, there is an exploit for it.
> 
> http://www.caughq.org/exploits/CAU-EX-2008-0002.txt

Maybe I'm missing it, but this looks like a fairly standard DNS exploit.

Keep asking questions and sending fake answers until one gets lucky.

It certainly matches closely with my memory of discussions of the
weaknesses in the DNS protocol from the '90's, with the primary difference
being that now networks and hardware may be fast enough to make the
flooding (significantly) more effective.  I have to assume that one other
standard minor enhancement has been omitted (or at least not explicitly
mentioned), and will refrain from mentioning it for now.

So, I have to assume that I'm missing some unusual aspect to this attack.
I guess I'm getting older, and that's not too shocking.  Anybody see it?

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

RE: Exploit for DNS Cache Poisoning - RELEASED

[Robert D. Scott]

Actually you are not missing anything. It is a brute force attack. I think
you had the right concept when you indicated that "networks and  hardware
may be fast enough". It is not maybe, it is; and every script kiddie on your
block has the power in his/her bedroom. Then you add the college crowd
sitting on 10Gig pipes to the Internet and the threat is real. But other
than just muck things up where is the motivation for a poisoning?

Robert D. Scott [EMAIL PROTECTED]
Senior Network Engineer 352-273-0113 Phone
CNS - Network Services  352-392-2061 CNS Receptionist
University of Florida   352-392-9440 FAX
Florida Lambda Rail 352-294-3571 FLR NOC
Gainesville, FL  32611  321-663-0421 Cell



-Original Message-
From: Joe Greco [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 23, 2008 6:31 PM
To: Robert D. Scott
Cc: [EMAIL PROTECTED]
Subject: Re: Exploit for DNS Cache Poisoning - RELEASED

> Now, there is an exploit for it.
> 
> http://www.caughq.org/exploits/CAU-EX-2008-0002.txt

Maybe I'm missing it, but this looks like a fairly standard DNS exploit.

Keep asking questions and sending fake answers until one gets lucky.

It certainly matches closely with my memory of discussions of the
weaknesses in the DNS protocol from the '90's, with the primary difference
being that now networks and hardware may be fast enough to make the
flooding (significantly) more effective.  I have to assume that one other
standard minor enhancement has been omitted (or at least not explicitly
mentioned), and will refrain from mentioning it for now.

So, I have to assume that I'm missing some unusual aspect to this attack.
I guess I'm getting older, and that's not too shocking.  Anybody see it?

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then
I
won't contact you again." - Direct Marketing Ass'n position on e-mail
spam(CNN)
With 24 million small businesses in the US alone, that's way too many
apples.

Re: Exploit for DNS Cache Poisoning - RELEASED

[Mike Lewinski]

Joe Greco wrote:


So, I have to assume that I'm missing some unusual aspect to this attack.
I guess I'm getting older, and that's not too shocking.  Anybody see it?


AFAIK, the main novelty is the ease with which bogus NS records can be 
inserted. It may be hard to get a specific A record 
(www.victimsbank.com) cached, but if you can shim in the NS records of 
your ns.poisoner.com authority, then getting the real target A record is 
trivial since you'll be asked directly for it (and can wait for the 
legit clients to ask for it for you).


Mike

Re: Exploit for DNS Cache Poisoning - RELEASED

[David Conrad]

Hi,

On Jul 23, 2008, at 3:51 PM, Robert D. Scott wrote:

Actually you are not missing anything. It is a brute force attack.


I haven't looked at the exploit code, but the vulnerability Kaminsky  
found is a bit more than a brute force attack. As has been pointed out  
in various venues, it takes advantage of a couple of flaws in the DNS  
architecture. No, not simply the fact that the QID space is only 16  
bits.  That's part of it, but there is more. Really.  I'm sure you can  
find the 'leaked' Matasano Chargen description of the attack on the  
net somewhere.


But other than just muck things up where is the motivation for a  
poisoning?


Man-in-the-middle attacks directed at ISPs serving end users who want  
to (say) get to their banks?


Regards,
-drc

Re: Exploit for DNS Cache Poisoning - RELEASED

[Tuc at T-B-O-H.NET]

> 
> Now, there is an exploit for it.
> 
> http://www.caughq.org/exploits/CAU-EX-2008-0002.txt
> 
For anyone looking to use it, you MUST update the frameworks
libraries. Some of the code only came out ~5 hours ago that
it needs.

Tuc/TBOH

Re: Exploit for DNS Cache Poisoning - RELEASED

[Kevin Day]

On Jul 23, 2008, at 5:30 PM, Joe Greco wrote:


Maybe I'm missing it, but this looks like a fairly standard DNS  
exploit.


Keep asking questions and sending fake answers until one gets lucky.

It certainly matches closely with my memory of discussions of the
weaknesses in the DNS protocol from the '90's, with the primary  
difference

being that now networks and hardware may be fast enough to make the
flooding (significantly) more effective.  I have to assume that one  
other
standard minor enhancement has been omitted (or at least not  
explicitly

mentioned), and will refrain from mentioning it for now.

So, I have to assume that I'm missing some unusual aspect to this  
attack.
I guess I'm getting older, and that's not too shocking.  Anybody see  
it?




What's new is the method of how it is being exploited.

Before, if you wanted to poison a cache for www.gmail.com, you get the  
victim name server to try to look up www.gmail.com and spoof flood the  
server trying to beat the real reply by guessing the correct ID. if  
you fail, you may need to wait for the victim name server to expire  
the cache before trying again.



The new way is slightly more sneaky. You get the victim to try to  
resolve an otherwise invalid and uncached hostname like  
1.gmail.com, and try to beat the real response with spoofed  
replies. Except this time your reply comes with an additional record  
containing the IP for www.gmail.com to the one you want to redirect it  
to. If you win the race and the victim accepts your spoof for  
1.gmail.com, it will also accept (and overwrite any cached value)  
for your additional record for www.gmail.com as well. If you don't win  
the race, you try again with 2.gmail.com, and keep going until you  
finally win one. By making up uncached hostnames, you get as many  
tries as you want in winning the race. By tacking on an additional  
reply record to your response packet you can poison the cache for  
anything the victim believes your name server should be authoritative  
for.


This means DNS cache poisoning is possible even on very busy servers  
that normally you wouldn't be able to predict when it was going expire  
its cache, and if you fail the first time you can keep trying again  
and again until you succeed with no wait.


-- Kevin

Re: Exploit for DNS Cache Poisoning - RELEASED

[Joe Abley]

On 23 Jul 2008, at 18:30, Joe Greco wrote:

So, I have to assume that I'm missing some unusual aspect to this  
attack.
I guess I'm getting older, and that's not too shocking.  Anybody see  
it?


Perhaps what you're missing can be found in the punchline to the  
transient post on the Matasano Security blog ("Mallory can conduct  
this attack in less than 10 seconds on fast Internet link").


Being able to divert users of a particular resolver (who thought they  
were going to paypal, or their bank, or a government web page to file  
their taxes, or, or, etc) to the place of your choosing with less than  
a minute's effort seems like cause for concern to me.


Luckily we have the SSL/CA architecture in place to protect any web  
page served over SSL. It's a good job users are not conditioned to  
click "OK" when told "the certificate for this site is invalid".



Joe

Re: Exploit for DNS Cache Poisoning - RELEASED

[Paul Ferguson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- -- Joe Abley <[EMAIL PROTECTED]> wrote:

>It's a good job users are not conditioned to click "OK" when
>told "the certificate for this site is invalid".

I appreciate your sense of humor. ;-)

- - ferg

-BEGIN PGP SIGNATURE-
Version: PGP Desktop 9.6.3 (Build 3017)

wj8DBQFIh9n2q1pz9mNUZTMRAq5cAKCEx/4G+FJb6XSQyZu1IOvd9UBixgCfbZUk
nDISb0J+YuIJlLYkVIKkLBo=
=1Swd
-END PGP SIGNATURE-

--
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 fergdawg(at)netzero.net
 ferg's tech blog: http://fergdawg.blogspot.com/

Re: Exploit for DNS Cache Poisoning - RELEASED

[Jasper Bryant-Greene]

On Wed, 2008-07-23 at 21:17 -0400, Joe Abley wrote:
> Luckily we have the SSL/CA architecture in place to protect any web  
> page served over SSL. It's a good job users are not conditioned to  
> click "OK" when told "the certificate for this site is invalid".

'course, as well as relying on users not ignoring certificate warnings,
SSL as protection against this attack relies on the user explicitly
choosing SSL (by manually prefixing the URL with https://), or noticing
that the site didn't redirect to SSL.

Your average Joe who types www.paypal.com into their browser may very
well not notice that they didn't get redirected to
https://www.paypal.com/

-Jasper

Re: Exploit for DNS Cache Poisoning - RELEASED

[Paul Ferguson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- -- "Robert D. Scott" <[EMAIL PROTECTED]> wrote:

>Now, there is an exploit for it.
>
>http://www.caughq.org/exploits/CAU-EX-2008-0002.txt

Now also (mirrored) here:

 http://www.milw0rm.com/exploits/6122

...and probably a slew of other places, too. ;-)

- - ferg

-BEGIN PGP SIGNATURE-
Version: PGP Desktop 9.6.3 (Build 3017)

wj8DBQFIh9qmq1pz9mNUZTMRAuXEAJ0cmn10Rz4Z0RG5LfseroFFvLbUmgCgipoV
rLDjjPCo+7w7+aV8udRK7fc=
=n1cC
-END PGP SIGNATURE-



--
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 fergdawg(at)netzero.net
 ferg's tech blog: http://fergdawg.blogspot.com/

Re: Exploit for DNS Cache Poisoning - RELEASED

[Joe Greco]

> Before, if you wanted to poison a cache for www.gmail.com, you get the  
> victim name server to try to look up www.gmail.com and spoof flood the  
> server trying to beat the real reply by guessing the correct ID. if  
> you fail, you may need to wait for the victim name server to expire  
> the cache before trying again.

That's why that crummy technique isn't used.

> The new way is slightly more sneaky. You get the victim to try to  
> resolve an otherwise invalid and uncached hostname like  
> 1.gmail.com, and try to beat the real response with spoofed  
> replies.

That's the normal technique, as far as I was aware.

> Except this time your reply comes with an additional record  
> containing the IP for www.gmail.com to the one you want to redirect it  
> to. 

Thought that was the normal technique for cache poisoning.  I'm pretty 
sure that at some point, code was added to BIND to actually implement
this whole bailiwick system, rather than just accepting arbitrary out-
of-scope data, which it ... used to do (sigh, hi BIND4).

> If you win the race and the victim accepts your spoof for  
> 1.gmail.com, it will also accept (and overwrite any cached value)  
> for your additional record for www.gmail.com as well. If you don't win  
> the race, you try again with 2.gmail.com, and keep going until you  
> finally win one. By making up uncached hostnames, you get as many  
> tries as you want in winning the race.

Right.  To the best of my knowledge, that's neither a new nor a clever 
technique for generating additional DNS request transactions.

> By tacking on an additional  
> reply record to your response packet you can poison the cache for  
> anything the victim believes your name server should be authoritative  
> for.

And that's one standard form of poisoning.

Cache poisoning and sending extra data is an interesting topic.  I have
to admit that my experience with it is somewhat dated, and a lot of it is
as much as a decade out of date, when I was writing miniature authoritative
name servers for application load balancing purposes.  I did in fact do
a number of experiments against various implementations to see what sins I
could get away with, and I have to say, the protocol is remarkable in that
so many broken-seeming things that I deliberately inflicted while playing
around can be worked out by server implementations.  But, then again, the
beauty of DNS is that it hasn't really changed much over time ...

> This means DNS cache poisoning is possible even on very busy servers  
> that normally you wouldn't be able to predict when it was going expire  
> its cache, and if you fail the first time you can keep trying again  
> and again until you succeed with no wait.

This is disappointing, because Vixie specifically stated that this was a 
new attack, and I'm pretty sure he said it was one where the exploit could
not be determined merely by knowing the sort of change that was being made
to BIND.

Well, the change that was made to BIND was to randomize source ports,
which indicated it was a forged-response attack of some kind.

Knowing that there were further statements about the weakness of the PRNG
for the QID suggested that it was susceptible to a brute-force attack.

I guess there's a vague hint of novelty in it all if you want to be a tad
more clever about what you're corrupting.  I can think of a few examples,
which I will respectfully not discuss, just in case someone hasn't thought
of them, but basically it seems to me that this is neither a new nor a 
novel attack.

So I'm not super impressed.  Do I see the need for the patch?  Yes.  Do I
see the need to lie about the nature of the problem?  I guess, but this is
not any more of a problem today than it was a year (or ten!) ago, except 
maybe now someone is threatening to finally do something that might cause 
DNSSEC to get deployed, which seems like it would have been a better way
to scare people, IMHO.

I think a bunch of us saw the problem with spoofed DNS years ago, and I'm 
pretty sure a bunch of DNSSEC people have been predicting exactly this 
state of affairs for quite some time, and knowledge of the general problem 
predates even that.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

Re: Exploit for DNS Cache Poisoning - RELEASED

[Tuc at T-B-O-H.NET]

> - -- "Robert D. Scott" <[EMAIL PROTECTED]> wrote:
> 
> >Now, there is an exploit for it.
> >
> >http://www.caughq.org/exploits/CAU-EX-2008-0002.txt
> 
> Now also (mirrored) here:
> 
>  http://www.milw0rm.com/exploits/6122
> 
> ...and probably a slew of other places, too. ;-)
> 
The changes the put into metasploit for this don't seem
to work if running from FreeBSD 5.5, possibly other BSD's and 
versions from talking to the author. 

Tuc/TBOH

Re: Exploit for DNS Cache Poisoning - RELEASED

[William Herrin]

On Wed, Jul 23, 2008 at 9:44 PM, Joe Greco <[EMAIL PROTECTED]> wrote:
>> Except this time your reply comes with an additional record
>> containing the IP for www.gmail.com to the one you want to redirect it
>> to.
>
> Thought that was the normal technique for cache poisoning.  I'm pretty
> sure that at some point, code was added to BIND to actually implement
> this whole bailiwick system, rather than just accepting arbitrary out-
> of-scope data, which it ... used to do (sigh, hi BIND4).

Joe,

I think that's the beauty of this attack: the data ISN'T out of scope.
The resolver is expecting to receive one or more answers to
1.gmail.com, one or more authority records (gmail.com NS
www.gmail.com) and additional records providing addresses for the
authority records (www.gmail.com A 127.0.0.1).

Regards,
Bill Herrin


-- 
William D. Herrin  [EMAIL PROTECTED] [EMAIL PROTECTED]
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Exploit for DNS Cache Poisoning - RELEASED

[Patrick W. Gilmore]

On Jul 23, 2008, at 9:27 PM, Jasper Bryant-Greene wrote:

On Wed, 2008-07-23 at 21:17 -0400, Joe Abley wrote:

Luckily we have the SSL/CA architecture in place to protect any web
page served over SSL. It's a good job users are not conditioned to
click "OK" when told "the certificate for this site is invalid".


'course, as well as relying on users not ignoring certificate  
warnings,

SSL as protection against this attack relies on the user explicitly
choosing SSL (by manually prefixing the URL with https://), or  
noticing

that the site didn't redirect to SSL.

Your average Joe who types www.paypal.com into their browser may very
well not notice that they didn't get redirected to
https://www.paypal.com/


That did not even occur to me.

Anyone have a foolproof way to get grandma to always put "https://"; in  
front of "www"?


Seriously, I was explaining the problem to someone saying "never click  
'OK'" when this e-mail came in and I realized how silly I was being.


Help?

--
TTFN,
patrick

Re: Exploit for DNS Cache Poisoning - RELEASED

[Jared Mauch]

On Wed, Jul 23, 2008 at 11:01:11PM -0400, Patrick W. Gilmore wrote:
>> https://www.paypal.com/
>
> That did not even occur to me.
>
> Anyone have a foolproof way to get grandma to always put "https://"; in  
> front of "www"?
>
> Seriously, I was explaining the problem to someone saying "never click  
> 'OK'" when this e-mail came in and I realized how silly I was being.

The problem is there is no perfect solution to these challenges
that the industry faces.

The enhanced SSL certs and browser magic, eg:
www.paypal.com w/ Firefox3 gives a nice green "happy" bar.

If you don't invest in these, or if there is a lack of user
education around these issues it's just one big Pharming pool.

I talked to some govvies today and made what I believe is
the clear case when it comes to "Doing the right thing(tm)".  My
case was that the industry would do the right thing as a whole.
There would be stragglers, but the risk of doing nothing is too
high.

If your nameservers have not been upgraded or you did
not enable the proper flags, eg: dnssec-enable and/or dnssec-validation
as applicable, I hope you will take another look.

- Jared

-- 
Jared Mauch  | pgp key available via finger from [EMAIL PROTECTED]
clue++;  | http://puck.nether.net/~jared/  My statements are only mine.

Re: Exploit for DNS Cache Poisoning - RELEASED

[Mike Lewinski]

Patrick W. Gilmore wrote:

Anyone have a foolproof way to get grandma to always put "https://"; in 
front of "www"?


Some tests from my home Comcast connection tonight showed less than 
desirable results from their resolvers.


The first thing I did was to double check that the bookmarks I use when 
visiting my banking sites all begin https. I was happy to see I had the 
sense to create them some time ago, by hand, with the https.


Even when I receive a notice of a new statement or pending payment on 
something in the email, and I KNOW it's valid, I'm still visiting it 
from the bookmark.

RE: Exploit for DNS Cache Poisoning - RELEASED

[Skywing]

Bookmarks or favorites or whatever your browser of choice wishes to call them, 
for the https URLs.  That, or remember to type in the https:// prefix.

- S

-Original Message-
From: Patrick W. Gilmore [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 23, 2008 11:01 PM
To: [EMAIL PROTECTED]
Subject: Re: Exploit for DNS Cache Poisoning - RELEASED

On Jul 23, 2008, at 9:27 PM, Jasper Bryant-Greene wrote:
> On Wed, 2008-07-23 at 21:17 -0400, Joe Abley wrote:
>> Luckily we have the SSL/CA architecture in place to protect any web
>> page served over SSL. It's a good job users are not conditioned to
>> click "OK" when told "the certificate for this site is invalid".
>
> 'course, as well as relying on users not ignoring certificate
> warnings,
> SSL as protection against this attack relies on the user explicitly
> choosing SSL (by manually prefixing the URL with https://), or
> noticing
> that the site didn't redirect to SSL.
>
> Your average Joe who types www.paypal.com into their browser may very
> well not notice that they didn't get redirected to
> https://www.paypal.com/

That did not even occur to me.

Anyone have a foolproof way to get grandma to always put "https://"; in
front of "www"?

Seriously, I was explaining the problem to someone saying "never click
'OK'" when this e-mail came in and I realized how silly I was being.

Help?

--
TTFN,
patrick

Re: Exploit for DNS Cache Poisoning - RELEASED

[Matthew Kaufman]

Skywing wrote:

Bookmarks or favorites or whatever your browser of choice wishes to call them, 
for the https URLs.  That, or remember to type in the https:// prefix.

- S



Which works great until you run into something like Washington Mutual 
(of which you have no doubt heard)...


http://www.wamu.com  redirects to
http://www.wamu.com/personal/default.asp

and

https://www.wamu.com *also* redirects to
http://www.wamu.com/personal.default.asp (!)

And yes, then you're supposed to trust that the page you've been served 
up will send the form submit with your username and password to the 
right place over https.


They do now have a link to 
https://online.wamu.com/IdentityManagement/Logon.aspx on that main page, 
but you have to look for it. But really, https://www.wamu.com should 
redirect to *that* in order for it to be safe for the 
slightly-knowledgeable-about-http-security.


Matthew Kaufman
[EMAIL PROTECTED]
http://www.matthew.at

Re: Exploit for DNS Cache Poisoning - RELEASED

[Paul Ferguson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- -- Jared Mauch <[EMAIL PROTECTED]> wrote:

>If your nameservers have not been upgraded or you did
>not enable the proper flags, eg: dnssec-enable and/or dnssec-validation
>as applicable, I hope you will take another look.

Let's hope some very large service providers get their act together
real soon now.

http://www.hackerfactor.com/blog/index.php?/archives/204-Poor-DNS.html

- - ferg

-BEGIN PGP SIGNATURE-
Version: PGP Desktop 9.6.3 (Build 3017)

wj8DBQFIiAJiq1pz9mNUZTMRAiSqAJwL9t4ldzKMjHyA4KITrLz2dHvTFQCgkfuR
G4SnZhKReOYYBjdSSJamVQw=
=ac5p
-END PGP SIGNATURE-



--
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 fergdawg(at)netzero.net
 ferg's tech blog: http://fergdawg.blogspot.com/

Emerging Threats SNORT [Was: Re: Exploit for DNS Cache Poisoning - REL EASED]

[Paul Ferguson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- -- "Paul Ferguson" <[EMAIL PROTECTED]> wrote:

>-- Jared Mauch <[EMAIL PROTECTED]> wrote:
>
>>If your nameservers have not been upgraded or you did
>>not enable the proper flags, eg: dnssec-enable and/or dnssec-validation
>>as applicable, I hope you will take another look.
>
>Let's hope some very large service providers get their act together
>real soon now.
>
>http://www.hackerfactor.com/blog/index.php?/archives/204-Poor-DNS.html

Sorry to respond to my own post, but I thought this might be of
interest to the list.

Matt Jonkman, over at Emerging Threats (previously known as Bleeding
Threats) has a 'prototype' SNORT sig for these attacks -- try it
out and provide feedback, if you are so inclined.

http://www.emergingthreats.net/content/view/87/9/

- - ferg

-BEGIN PGP SIGNATURE-
Version: PGP Desktop 9.6.3 (Build 3017)

wj8DBQFIiASRq1pz9mNUZTMRAmjnAKDYOmtUbm+er2OBUfjxcGdNWggOlgCfYbkn
V8pibFdRpbHul2PrZu0oBg0=
=QPWh
-END PGP SIGNATURE-


--
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 fergdawg(at)netzero.net
 ferg's tech blog: http://fergdawg.blogspot.com/

Re: XO contact

[William R. Lorenz]

Do XO engineers still read and participate in this mailing list?

We've been going back-and-forth for a couple of weeks now on a newly 
installed XO circuit.  The circuit does not work, and we've heard reports 
of engineers resetting an ML100 card, possibly RE Cisco's CSCec78266.


We have publicly-traded companies in the facilities, and it would be 
wonderful if we could get in touch with a knowledgeable XO engineer?




On Tue, 24 Jun 2008, Zaid Ali wrote:

Can someone from XO who handles this neighbor 65.46.253.157 help me out 
with a BGP session going down? This is the second time within a week 
where a misconfiguration of an ACL on XO end is bringing down my BGP 
session with you and its frustrating to go through the normal tech 
support chain.

Re: XO contact

[Martin Hannigan]

On Thu, Jul 24, 2008 at 1:00 AM, William R. Lorenz <[EMAIL PROTECTED]> wrote:
> Do XO engineers still read and participate in this mailing list?

Yes.

Re: Exploit for DNS Cache Poisoning - RELEASED

[Sean Donelan]

On Thu, 24 Jul 2008, Paul Ferguson wrote:

If your nameservers have not been upgraded or you did
not enable the proper flags, eg: dnssec-enable and/or dnssec-validation
as applicable, I hope you will take another look.


Let's hope some very large service providers get their act together
real soon now.


There is always a tension between discovery, changing, testing and 
finally deployment.


DNS vendors learned about the vulnerability on March 31 (or possibly 
earlier).  DNS vendors waited over 3 months to publically release their

patches, even though they knew their customers and users were vulnerable.

It probably took the vendors some time to change their code, test their 
changes, work on beta releases in various deployments because programmers 
are human and sometimes patches have bugs too. Then they announced their 
patches to the world, and the world (and ISPs, etc) has much less time

to regression test and verify the systems still work.  Vendors have
released bugging patches in the past. Patching a large ISP infrastructure 
under ordinary circumstances can be challanging.  If it takes software
vendors 90+ days to fix something, is it a surpise it may take a large ISP 
more than 14 days?


If they move to quickly and crash the resolvers because of a bug the 
human programmers may have not forseen in the ISPs DNS architecture, the 
Internet is effectively "down" for a large number of users.  Result: Bad 
press, angry customers, lawsuits, etc.


If they don't move quickly enough and the vulnerability is exploited by
a human bad guy, the Internet is effectively "corrupted" for a large
number of users.  Result: Bad press, angry customers, lawsuits, etc.

Damned if they do, damned if they don't.  Or in this case: Damned if
they are too fast, damned if they are too slow.

I don't think there really is a correct answer.  People are going
to say they suck no matter what.  Anyone who has ever been in the position
of scheduling security patches across a large ISP knows they aren't going
to get much thanks.

Although I didn't know the right answer, I did try to always patch 
production network first and the corporate network last; so if we didn't 
get everything finished before the exploit hit I could tell customers
we did try to put the customer first.  Although internal MIS folks 
would sometimes get mad at me for waiting to tell them.  Some people

think you should patch the corporate network first, and the production
network later.


So it brings up the ancient question about the schedule of vulnerability
announcements and whether some providers of some core infrastructure
should have an early start to patch their systems; because everyone
else will be depending on them functioning to obtain the patches when
the vulnerability is widely disclosed.  How do you decide how early,
who, what, how, ...

Or do not play favorites, and announce everything to everyone at
the exact same time; and its off to the races.

Or something in between.

Re: Avg. Packet Size - Again?

[k claffy]

most recent update on this question, with
just a couple of data points:
http://www.caida.org/research/traffic-analysis/pkt_size_distribution/graphs.xml
(so, yes the peak has moved up to 1500.)

note there are more tiny packets in our recent ipv6 data, 
but that could just be someone's ping experiment, 
it's too small a sample (76k pkts) 

k


On Wed, Jul 16, 2008 at 08:24:59AM -0700, fred baker wrote:
  CAIDA has been doing a lot of that, at least in the past. Last I asked  
  them, which was quite a while back, they said that O(35%) of traffic  
  in their samples was at the path MTU (which included 576 bytes for  
  historical reasons), O(40%) was about the size of a TCP SYN or ACK,  
  for reasons that are apparent if you think about common TCP  
  implementations, and sizes were scattered more or less uniformly in  
  between - last packet in a burst or transaction exchanges. From the  
  numbers that Valdis posted the other day, it sounds like the logic  
  remains about the same but the relevance of "576" has largely gone away.
  
  On Jul 16, 2008, at 4:42 AM, Randy Bush wrote:
  
  >>Our network also shows peaks at the ethernet MTU (our MTU is higher
  >>than that) and the DNS packet size.
  >
  >so who has been tracking packet size distributions for some years and
  >has published or could provide data?
  >
  >randy
  >
  >
  >
  
  

re: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

[Paul Vixie]

this is for whoever said "it's just a brute force attack" and/or "it's the
same attack that's been described before".  maybe it goes double if that
person is also the one who said "my knowledge in this area is out of date".

g.

re:


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

--- Begin Message ---
> >The difference is its use of additional RR records. The request is for 
> >some arbitrary sub domain like 12345.google.com, but your spoofed 
> >response also includes the record for www.google.com
> 
> Which is also decades old and well known.  So at best, it's a 'new' attack
> that is a combination of 2 well-known/documented ones. Maybe I am somewhat
> disappointed because I expected a second coming/something truly novel
> (please note that I'm not discounting the seriousness of the issue, just
> commenting on its apparent novelty)

downplay this all you want, we can infect a name server in 11 seconds now,
which was never true before.  i've been tracking this area since 1995.  don't
try to tell me, or anybody, that dan's work isn't absolutely groundbreaking.

i am sick and bloody tired of hearing from the people who aren't impressed.
every time some blogger says "this isn't new", another five universities
and ten fortune 500 companies and three ISP's all decide not to patch.
that means we'll have to wait for them to be actively exploited before they
will understand the nature of the emergency.

perhaps dan's defcon talk will open some remaining eyes among those glued
shut by the pride and prejudice of the minds behind them.  i am stunned,
absolutely stunned, that there was a ready-to-go blog posting sitting in
clear text on a network connected machine, written by tom ptacek who had
whined about how the hacker community needed to be in the loop, waiting for
the "publish" button to be hit "accidentally" by his wife.  is this how the
community rewards dan for trying to buy us all some time to protect the
infrastructure?  is this how the community plans to incentivize slow and
careful disclosure of the next big flaw?

we've exited another era in the disclosure debate, and not even dan knew it.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
dns-operations mailing list
[EMAIL PROTECTED]
http://lists.oarci.net/mailman/listinfo/dns-operations
--- End Message ---

Re: Exploit for DNS Cache Poisoning - RELEASED

[Paul Ferguson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- -- Sean Donelan <[EMAIL PROTECTED]> wrote:

>>
>> Let's hope some very large service providers get their act together
>> real soon now.
>
>There is always a tension between discovery, changing, testing and 
finally deployment.
>

Sure, I can empathize, to a certain extent. But this issue has
been known for 2+ weeks now.

Not sure I can be very empathic now, given the seriousness, and the
proper warning ISPs have been given.

$.02,

- - ferg

-BEGIN PGP SIGNATURE-
Version: PGP Desktop 9.6.3 (Build 3017)

wj8DBQFIiBldq1pz9mNUZTMRAiLjAJ91jnOPW+nhuk0PA5qGjrwz0bH25ACgjOXS
IEJTnVU4BIZ8bMfU7dB4ZKY=
=sBS2
-END PGP SIGNATURE-


--
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 fergdawg(at)netzero.net
 ferg's tech blog: http://fergdawg.blogspot.com/