-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 empathiz
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 scanne
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 experim
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
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.
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 publicl
-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
-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
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.w
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]
Su
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 wh
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 clic
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
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 tha
> - -- "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 change
> 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
-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.
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
-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 Desk
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 Se
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
>
> 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
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
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.
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
si
> 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
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
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
> 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 st
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
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 interrup
> 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 PCI
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 pa
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 peopl
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
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
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
recomme
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
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 cel
> 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
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. H
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)
[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,
coun
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 r
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 mu
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.
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
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 majorit
[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 bandwid
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 h
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 ar
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
52 matches
Mail list logo
