Re: Clue on Europe

[Colin Johnston]

Hi,
The two best colo folks in the UK are
Www.caladan.net   good colo in london and manchester
Www.bogons.net good colo in london

Colin Johnston
Www.satsig.net hub network ops

Re: Clue on Europe

[Subhi S Hashwa]

Tuesday, March 8, 2005, 3:34:07 AM, Ashe Canvar wrote:

> Plan to set up a 2 rack outpost in a colo in Europe.  I am looking for
> prior experience(s) -- Good or ugly.

Avoid Redbux Hex (London) like the plague,  just ask about their
recent power outages. AFAIK their other facilities are ok.


-- 
Best regards,
 Subhi S Hashwamailto:[EMAIL PROTECTED]
 When everything is heading your way, you're in the wrong lane.

Re: www.nanog.org returning 403 Forbidden error?

[W.D.McKinney]

>-Original Message-
>From: Brent Chapman [mailto:[EMAIL PROTECTED]
>Sent: Monday, March 7, 2005 11:58 PM
>To: nanog@merit.edu
>Subject: www.nanog.org returning 403 Forbidden error?
>
>
>I just tried accessing http://www.nanog.org/, and am getting back a 
>403 "Forbidden" error:
>
>   Forbidden
>   You don't have permission to access / on this server.
>
>Did somebody break the web server?
>

Works here fine for me. Nice to see Seattle on it also!

Dee

Re: www.nanog.org returning 403 Forbidden error?

[Brent Chapman]

At 10:43 PM -0500 3/7/05, Jim Popovitch wrote:
On Mon, 2005-03-07 at 15:58 -0800, Brent Chapman wrote:
 I just tried accessing http://www.nanog.org/, and am getting back a
 403 "Forbidden" error:
Forbidden
You don't have permission to access / on this server.
 Did somebody break the web server?
Works for me.  Perhaps it was in the process of being updated with the
Seattle info when you tried?
Could be.  There also appear to have been mail problems with the list 
this afternoon; my message sat in the queue at my end for 3.5 hours 
being repeatedly rejected or timed out by mail.merit.edu, before 
finally going through:

mycroft:/var/log# egrep 9D25832C1CC mail.log
Mar  7 15:58:36 mycroft postfix/smtpd[22677]: 9D25832C1CC: 
client=localhost[127.0.0.1]
Mar  7 15:58:36 mycroft postfix/cleanup[17797]: 9D25832C1CC: 
message-id=<[EMAIL PROTECTED]>
Mar  7 15:58:36 mycroft postfix/qmgr[6224]: 9D25832C1CC: 
from=<[EMAIL PROTECTED]>, size=810, nrcpt=1 (queue active)
Mar  7 16:04:18 mycroft postfix/smtp[22726]: 9D25832C1CC: 
to=, relay=mail.merit.edu[198.108.1.11], delay=342, 
status=deferred (host mail.merit.edu[198.108.1.11] said: 450 
<[EMAIL PROTECTED]>: Sender address rejected: Domain not found 
(in reply to RCPT TO command))
Mar  7 16:26:37 mycroft postfix/qmgr[6224]: 9D25832C1CC: 
from=<[EMAIL PROTECTED]>, size=810, nrcpt=1 (queue active)
Mar  7 16:27:08 mycroft postfix/smtp[21475]: 9D25832C1CC: 
to=, relay=none, delay=1712, status=deferred 
(connect to mail.merit.edu[198.108.1.11]: Connection timed out)
Mar  7 16:59:56 mycroft postfix/qmgr[6224]: 9D25832C1CC: 
from=<[EMAIL PROTECTED]>, size=810, nrcpt=1 (queue active)
Mar  7 17:00:27 mycroft postfix/smtp[17099]: 9D25832C1CC: 
to=, relay=none, delay=3711, status=deferred 
(connect to mail.merit.edu[198.108.1.11]: Connection timed out)
Mar  7 18:06:37 mycroft postfix/qmgr[6224]: 9D25832C1CC: 
from=<[EMAIL PROTECTED]>, size=810, nrcpt=1 (queue active)
Mar  7 18:07:22 mycroft postfix/smtp[17406]: 9D25832C1CC: 
to=, relay=none, delay=7726, status=deferred 
(connect to mail.merit.edu[198.108.1.11]: Connection timed out)
Mar  7 19:29:57 mycroft postfix/qmgr[6224]: 9D25832C1CC: 
from=<[EMAIL PROTECTED]>, size=810, nrcpt=1 (queue active)
Mar  7 19:30:09 mycroft postfix/smtp[16167]: 9D25832C1CC: 
to=, relay=mail.merit.edu[198.108.1.11], 
delay=12693, status=sent (250 Ok: queued as 95C261877)
Mar  7 19:30:09 mycroft postfix/qmgr[6224]: 9D25832C1CC: removed

So, it looks like somebody was having a bad day...
-Brent
--
Brent Chapman <[EMAIL PROTECTED]>
Great Circle Associates, Inc.
http://www.greatcircle.com/
+1 650 962 0841

Re: www.nanog.org returning 403 Forbidden error?

[Jim Popovitch]

On Mon, 2005-03-07 at 15:58 -0800, Brent Chapman wrote:
> I just tried accessing http://www.nanog.org/, and am getting back a 
> 403 "Forbidden" error:
> 
>   Forbidden
>   You don't have permission to access / on this server.
> 
> Did somebody break the web server?

Works for me.  Perhaps it was in the process of being updated with the
Seattle info when you tried?

-Jim P.

Clue on Europe

[Ashe Canvar]

Hi all,

Plan to set up a 2 rack outpost in a colo in Europe.  I am looking for
prior experience(s) -- Good or ugly.

My research leads me to believe that London and Amsterdam have the
most dense connectivity. Is this true ?

If so, then what colo's / ISPs in these 2 cities would you recommend.
The primary aim is to get smallest RTTs to most of western Europe.

- I would prefer a carrier neutral facility. 
- Backhaul to the US is a lesser concern but, of course, cheaper is better.
- I have a small setup in the Isle of Dogs (London) presently, but the
local loop charges are atrocious.
- I am posting here instead of Euronog because I want to get US based
prespective.

Will summarize to list,
Thanks !

www.nanog.org returning 403 Forbidden error?

[Brent Chapman]

I just tried accessing http://www.nanog.org/, and am getting back a 
403 "Forbidden" error:

Forbidden
You don't have permission to access / on this server.
Did somebody break the web server?
-Brent
--
Brent Chapman <[EMAIL PROTECTED]>
Great Circle Associates, Inc.
http://www.greatcircle.com/
+1 650 962 0841

Re: Is current DDoS detecting method effective?

[Florian Weimer]

* Jared Mauch:

>   If you want some "basic" detection, I recommend doing something
> like this:
>
>   sort by the top "proto+dstip+dstport+tcpflags"
> combination.  The more of these you see, the more it may
> look weird.

You should also run a similar query for source IPs in your netblocks,
particularly one restricted to 25/TCP. 8->

>   Cisco publishes the netflow datagram specification, so
> you may be able to write an optimized netflow daemon that doesn't
> take up too much cpu/disk/whatnot if you discard the lower
> levels of the "noise".

I wouldn't optimize prematurely.  I was surprised how far you can get
with simple Perl script, a slightly increased socket buffer size for
the receiving UDP socket, and rotating ASCII log files.

Re: Is current DDoS detecting method effective?

[Florian Weimer]

* Kim Onnel:

> So I can safely say that Detecting DDoS attacks is mostly done using
> Netflow data, now the only tool(known) on the market to analyze for
> attacks is Arbor, now besides being expensive, which is a problem for
> Mid-sizes ISPs,

Who qualifies as a mid-sized ISP?  What equipment is typical?

Even the most simple approach, based on sampled Netflow, an
off-the-shelf SQL database (PostgreSQL preferred) and a couple of Perl
scripts can work wonders.  You won't get reliable automated alerts,
but you can run ad-hoc queries to find out what's going on on your
network when something or somebody else has detected a problem.  The
people already doing this probably consider this trivial, so it's not
well documented.  I tried to write something down, but never found the
time to really polish it:

  

DoS detection can be quite hard, especially if you have many
compromised Windows boxes and you can't force the owners to clean them
(because it's too expensive to contact them, for example).  This
results in a lot of background noise and useless flow data, too.  If
there's little background noise, you can use rather straightforward
SQL query that you run periodically.

NANOG 34: Call for Presentations

[Steve Feldman]

* * * * * * * * * * * * * * * * *

 CALL FOR PRESENTATIONS
   NANOG 34
May 15-17, 2005

* * * * * * * * * * * * * * * * *


The North American Network Operators' Group (NANOG) will hold
its 34th meeting May 15-17, 2005, in Seattle, Washington. The
meeting will be hosted by Switch and Data and held at the Westin
Seattle.

NANOG conferences provide a forum for information exchange
among network operators, engineers, and researchers.  Meetings
are held three times each year, and include presentations,
tutorial sessions, and BOFs. The meetings are informal, with
an emphasis on relevance to current engineering practices.

NANOG solicits presentations highlighting issues relating to
technology already deployed or soon to be deployed in the
Internet.  Vendors are encouraged to work with operators to
present deployment experiences with the vendor's products and
interoperability.

The community is invited to present talks or tutorials on:

  - VOIP architectures and deployment
  - Peering/collocation coordination issues
  - Security attacks/mitigation, tools, and analysis
  - Content provider issues
  - MSO IPTV deployment and operations
  - Backbone operational case studies
  - Exchange point technologies and implementation
  - Non-telco, last-mile technologies (metro/rural, broadband,
radio, and optical)
  - Implementation experience with Ethernet, e.g., TLS, VPLS,
Ethernet private line, and VPWS.
  - Wavelength use by enterprises
  - Large-scale wireless deployment
  - Experiences with native IPv6 transport rollout
  - State of OAM tools for IP and MPLS networks
  - Options for blackhole and discard routing
  - BGP/MPLS layer 3 VPNs
  - Other interesting network technologies

Topics for short (10-20 minute) lightning talks will be
solicited on-site in Seattle.

Researchers are invited to present short (10-minute) summaries
of their work for operator feedback. Topics include routing,
network performance, statistical measurement and analysis, and
protocol development and implementation. Studies presented may be
works in progress. Researchers from academia, government, and
industry are encouraged to present.

How to Present
--
Submit an abstract and draft slides for the presentation in
email to [EMAIL PROTECTED] See
http://www.nanog.org/presentations.html for  submission
guidelines. The deadline for abstracts and slides is April 4,
2005. While the majority of speaking slots will be filled by
April 4, a limited number of slots may be available after that
date for topics that are exceptionally timely, important, or
critical to the operations of the Internet. Submissions will be
reviewed by the NANOG Program Committee, and presenters will be
notified of acceptance by April 18. Final drafts of presentation
slides are due by May 4, and final versions May 11.

Re: Is current DDoS detecting method effective?

[Jared Mauch]

On Mon, Mar 07, 2005 at 01:43:29PM +0200, Kim Onnel wrote:
> On Mon, 07 Mar 2005 06:11:35 + (GMT), Christopher L. Morrow
> <[EMAIL PROTECTED]> wrote:
> 
> > Some of your cflowd gathering should also see these things, but they will
> > need data correlation, something Arbor already went to the trouble of
> > doing for you... So, define: "attack" and then see if your tool fits that
> > definition.
> 
> So I can safely say that Detecting DDoS attacks is mostly done using
> Netflow data, now the only tool(known) on the market to analyze for
> attacks is Arbor, now besides being expensive, which is a problem for
> Mid-sizes ISPs, doing that with open-source tools(cflowd,...) isnt
> quite easy for a network engineer, who rarely has programming
> experience, thats my problem now, we either need to outsource or buy
> Arbor,
> 
> I've seen open-source Netflow DDoS specific apps. anyone tried them
> (Zazu and Panoptis)
> 
> -With the small experience i've gained to work out these tools,
> - Zazu is still under devel. but some times reports nice results
> - couldnt compile panoptis
> 
> Any luck with (stager, Silktools, ntop,...)?
> 
> I wish there could be a documented ISPs experience for using
> open-source tools to detect DDoS, or a homegrown script that uses
> flow-tools to report anomalies.

I once took some time to write a netflow processing system.

It's not that hard..

If you want some "basic" detection, I recommend doing something
like this:

sort by the top "proto+dstip+dstport+tcpflags"
combination.  The more of these you see, the more it may
look weird.

As Chris mentioned before, what defines the "bad" threshold
depends on your customerbase.  Maybe 1Kpps is bad.  Maybe 100Kpps is 
normal.

Cisco publishes the netflow datagram specification, so
you may be able to write an optimized netflow daemon that doesn't
take up too much cpu/disk/whatnot if you discard the lower
levels of the "noise".

Once you define your 'signal' and 'noise' you can then
determine what is valuable to you.

http://www.cisco.com/warp/public/cc/pd/iosw/ioft/neflct/tech/napps_wp.htm

- jared

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

Re: DNS Blackhole attack

[Rachael Treu]

On Mon, Mar 07, 2005 at 11:38:53AM +, Ketil Froyn said something to the 
effect of:
> 
> On Sat, 2005-03-05 at 14:43 -0800, william(at)elan.net wrote:
> 
> > Global DNS cache poisoning attack?; Update...
> 
> It's a bit frustrating that problems this old and well-known can
> actually be used to cause damage.

Uh...see tcp ports 135 through 139, and give thought to smtp
as a protocol.  And I hear the water is lovely in nis, nfs, and
rpc this time of year... ;P

> 
> The easiest way to check if you are vulnerable to DNS poisoning is to
> try to poison yourself. Try my "poison yourself" page here:
> 
>   http://ketil.froyn.name/poison.html

Nice, handy resource.

What's up with the patching problems, btw?

whee,
--ra

--
k. rachael treu, CISSP  [EMAIL PROTECTED]
..quis custodiet ipsos custodes?..


> 
> It tries to redirect www.example.com to a fake IP (the same one as I
> host my website on), where I have a virtualhost for www.example.com with
> a plain html page. It'll tell you if you were poisoned.
> 
> Cheers,
> Ketil Froyn
> 

Re: US slaps fine on company blocking VoIP

[Rachael Treu]

On Mon, Mar 07, 2005 at 08:45:30AM -0600, Adi Linden said something to the 
effect of:
> 
> > If VOIP doesn't run on your network because you've oversold your capacity,
> > no amount of QoS is going to put the quality back into your service.
> > People will find better ISPs. If you deliberately set QoS to favor your
> > services over a competitor, whom your customers are also paying for
> > service, you'll be staring down prosecutors, at some point. It's
> > anti-competitive behavior, as you're taking deliberate actions to degrade
> > the service of a competitor, simply because you can.
> 
> Let's say I sell a premium VoIP offering for an additional fee on my
> network. I apply QoS to deliver my VoIP offering to my customers but as a
> result all other VoIP service is literally useless during heavy use
> times you'd consider this anti-competitive behavior?

Possibly, but even if not it's a glancing blow at another violation.  At the 
very least I would consider it failure to deliver service.  

Unless you explicitly and frequently refer to this non-QoS-ified service as 
"best effort" (read: in this case, no effort at all) and in the interest of 
anti-liability full disclosure explain that this traffic is regularly 
superceded by your premium subscribers' traffic (spin doctor as appropriate), 
you wll be fielding the angry phone calls of customers who rightfully feel 
that they were mislead.  While you may not be hit with antitrust suits,
you're pushing the envelope with the generic SLA that acts as junk drawer
for the rest of your traffic, I would think...

Then again, no one pays me to think.

RTI,
--ra

-- 
k. rachael treu, CISSP   [EMAIL PROTECTED]
..quis custodiet ipsos custodes?..
> 
> Adi

Re: US slaps fine on company blocking VoIP

[Bill Nash]

On Mon, 7 Mar 2005, Adi Linden wrote:
If VOIP doesn't run on your network because you've oversold your capacity,
no amount of QoS is going to put the quality back into your service.
People will find better ISPs. If you deliberately set QoS to favor your
services over a competitor, whom your customers are also paying for
service, you'll be staring down prosecutors, at some point. It's
anti-competitive behavior, as you're taking deliberate actions to degrade
the service of a competitor, simply because you can.
Let's say I sell a premium VoIP offering for an additional fee on my
network. I apply QoS to deliver my VoIP offering to my customers but as a
result all other VoIP service is literally useless during heavy use
times you'd consider this anti-competitive behavior?
Applying QoS to your VOIP traffic at the expense of *all* other traffic 
would be edging against a gray area. Applying QoS to competitive VOIP 
traffic specifically to improve the quality of your service at the expense 
of theirs is likely to be a problem. Again, I am not a lawyer. I would 
strongly suggest consulting one if this is a serious concern.

The Internet is not regulated because operators tend to be effective at 
self policing. Engaging in these kinds of practices is asking for 
regulation.

- billn

Re: public accessible snmp devices?

[vijay gill]

Petri Helenius wrote:
And lately, for reasons undetermined so far there has been instances of 
both vendor C and J where counters suddenly go to zero either 
temporarily (like 1,2,3,4,0,6,7,8,0,10,etc.) or reset altogether without 
any reason.

Pete
I am unclear as to what Vendors "C" and "J" are. Could you clarify please?
thanks
/vijay

RE: Vonage service suffers outage

[Neil J. McRae]

> Companies like Vonage are signing up subscribers because they 
> provide real phone service connecting you to copperline 
> subscribers on the real phone network. That is their business 
> model. Verizon could sell exactly the same sort of service to 
> subscribers in California leveraging the Internet last mile 
> in exactly the same way as Vonage.
> Vonage and Verizon are just phone companies, not VoIP companies.

Michael - you've been drinking way to much coffee today.

Re: Vonage service suffers outage

[Michael . Dillon]

> No, what makes this "newsworthy" is exactly what Om Malik
> says: VoIP is being oversold.

Let's be clear here. Vonage is not a VoIP company.
They do not offer a VoIP service. They are a phone
company that offers a type of phone service which
leverages VoIP to handle the last mile connection
to subscribers. Many other phone companies such as
Verizon or Qwest leverage VoIP in the interLATA or 
international parts of their network. They aren't VoIP
companies either.

For true VoIP companies look at XTen who make a 
VoIP softphone or Grandstream who makes physical
VoIP telephones or Digium who sponsor the Asterisk
PBX software.

VoIP is just a suite of protocols that can run over
anybody's IP network.

Companies like Vonage are signing up subscribers because
they provide real phone service connecting you to
copperline subscribers on the real phone network. That
is their business model. Verizon could sell exactly the
same sort of service to subscribers in California leveraging
the Internet last mile in exactly the same way as Vonage.
Vonage and Verizon are just phone companies, not VoIP
companies.

--Michael Dillon

Re: Vonage service suffers outage

[Fergie (Paul Ferguson)]

No, what makes this "newsworthy" is exactly what Om Malik
says: VoIP is being oversold.

http://www.gigaom.com/2005/03/06/voip-has-serious-problems/

- ferg


-- Randy Bush <[EMAIL PROTECTED]> wrote:


>> Amidst all the hoopla w.r.t. "port blocking" their service,
>> this outage couldn't have come at a worse time, methinks.
>>
>> The outage on Friday "left about half of its 500,000
>> subscribers without phone service for about 45 minutes"
>> and "... was caused by a glitch with a software upgrade
>> on Thursday night."
>>
>> http://www.detnews.com/2005/technology/0503/07/tech-109316.htm
> 
> Nice story, but it doesn't explain why they had a similar looking outage
> at roughly the same time the day before.  Maybe it wasn't quite the "first
> issue" they've ever had related to software upgrades.

of course none of us have ever had customer-affecting 'issues'
with software upgrades, system outages, ...

that's what makes this so newsworthy

randy

Re: Vonage service suffers outage

[Randy Bush]

>> Amidst all the hoopla w.r.t. "port blocking" their service,
>> this outage couldn't have come at a worse time, methinks.
>>
>> The outage on Friday "left about half of its 500,000
>> subscribers without phone service for about 45 minutes"
>> and "... was caused by a glitch with a software upgrade
>> on Thursday night."
>>
>> http://www.detnews.com/2005/technology/0503/07/tech-109316.htm
> 
> Nice story, but it doesn't explain why they had a similar looking outage
> at roughly the same time the day before.  Maybe it wasn't quite the "first
> issue" they've ever had related to software upgrades.

of course none of us have ever had customer-affecting 'issues'
with software upgrades, system outages, ...

that's what makes this so newsworthy

randy

Re: Vonage service suffers outage

[Jon Lewis]

On Mon, 7 Mar 2005, Fergie (Paul Ferguson) wrote:

> Amidst all the hoopla w.r.t. "port blocking" their service,
> this outage couldn't have come at a worse time, methinks.
>
> The outage on Friday "left about half of its 500,000
> subscribers without phone service for about 45 minutes"
> and "... was caused by a glitch with a software upgrade
> on Thursday night."
>
> http://www.detnews.com/2005/technology/0503/07/tech-109316.htm

Nice story, but it doesn't explain why they had a similar looking outage
at roughly the same time the day before.  Maybe it wasn't quite the "first
issue" they've ever had related to software upgrades.

--
 Jon Lewis   |  I route
 Senior Network Engineer |  therefore you are
 Atlantic Net|
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Vonage service suffers outage

[Fergie (Paul Ferguson)]

Amidst all the hoopla w.r.t. "port blocking" their service,
this outage couldn't have come at a worse time, methinks.

The outage on Friday "left about half of its 500,000
subscribers without phone service for about 45 minutes"
and "... was caused by a glitch with a software upgrade
on Thursday night."

http://www.detnews.com/2005/technology/0503/07/tech-109316.htm

- ferg

--
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 [EMAIL PROTECTED] or
 [EMAIL PROTECTED]

RE: US slaps fine on company blocking VoIP

[Network.Security]

Do you also offer premium "80" traffic?  Or guaranteed delivery of UDP?

Unbundled services will give the best price, and good service.  Maybe we
won't get the service anytime soon, but 2 out of the magical 3 isn't
bad.

[EMAIL PROTECTED]

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Adi Linden
Sent: Monday, March 07, 2005 8:46 AM
To: Bill Nash
Cc: Robert Blayzor; [EMAIL PROTECTED]
Subject: Re: US slaps fine on company blocking VoIP


> If VOIP doesn't run on your network because you've oversold your 
> capacity, no amount of QoS is going to put the quality back into your
service.
> People will find better ISPs. If you deliberately set QoS to favor 
> your services over a competitor, whom your customers are also paying 
> for service, you'll be staring down prosecutors, at some point. It's 
> anti-competitive behavior, as you're taking deliberate actions to 
> degrade the service of a competitor, simply because you can.

Let's say I sell a premium VoIP offering for an additional fee on my
network. I apply QoS to deliver my VoIP offering to my customers but as
a result all other VoIP service is literally useless during heavy use
times you'd consider this anti-competitive behavior?

Adi

Re: US slaps fine on company blocking VoIP

[Adi Linden]

> If VOIP doesn't run on your network because you've oversold your capacity,
> no amount of QoS is going to put the quality back into your service.
> People will find better ISPs. If you deliberately set QoS to favor your
> services over a competitor, whom your customers are also paying for
> service, you'll be staring down prosecutors, at some point. It's
> anti-competitive behavior, as you're taking deliberate actions to degrade
> the service of a competitor, simply because you can.

Let's say I sell a premium VoIP offering for an additional fee on my
network. I apply QoS to deliver my VoIP offering to my customers but as a
result all other VoIP service is literally useless during heavy use
times you'd consider this anti-competitive behavior?

Adi

Re: Is current DDoS detecting method effective?

[Kim Onnel]

On Mon, 07 Mar 2005 06:11:35 + (GMT), Christopher L. Morrow
<[EMAIL PROTECTED]> wrote:

> Some of your cflowd gathering should also see these things, but they will
> need data correlation, something Arbor already went to the trouble of
> doing for you... So, define: "attack" and then see if your tool fits that
> definition.

So I can safely say that Detecting DDoS attacks is mostly done using
Netflow data, now the only tool(known) on the market to analyze for
attacks is Arbor, now besides being expensive, which is a problem for
Mid-sizes ISPs, doing that with open-source tools(cflowd,...) isnt
quite easy for a network engineer, who rarely has programming
experience, thats my problem now, we either need to outsource or buy
Arbor,

I've seen open-source Netflow DDoS specific apps. anyone tried them
(Zazu and Panoptis)

-With the small experience i've gained to work out these tools,
- Zazu is still under devel. but some times reports nice results
- couldnt compile panoptis

Any luck with (stager, Silktools, ntop,...)?

I wish there could be a documented ISPs experience for using
open-source tools to detect DDoS, or a homegrown script that uses
flow-tools to report anomalies.

Any news of undergoing projects or papers for the above, there are too
many on Blackholing, but not how to get the IP to blackhole)

Regards

Re: DNS Blackhole attack

[Ketil Froyn]

On Sat, 2005-03-05 at 14:43 -0800, william(at)elan.net wrote:

> Global DNS cache poisoning attack?; Update...

It's a bit frustrating that problems this old and well-known can
actually be used to cause damage.

The easiest way to check if you are vulnerable to DNS poisoning is to
try to poison yourself. Try my "poison yourself" page here:

  http://ketil.froyn.name/poison.html

It tries to redirect www.example.com to a fake IP (the same one as I
host my website on), where I have a virtualhost for www.example.com with
a plain html page. It'll tell you if you were poisoned.

Cheers,
Ketil Froyn

Re: US slaps fine on company blocking VoIP

[Michael . Dillon]

> > and your phone number has to be local to your location.
>   ^^
> 
> Thanks for proving my point.

And who says that a location needs to have only a single
phone number. Many VoIP providers will sell you extra
vanity numbers anywhere in the USA or a number of other
countries:
http://www.telphin.com/numbers.php
http://sipphone.com/virtual/

These are redirected to your phone in the same way that
a personal 800 number gets redirected. A telephone number
is rather more like a domain name than an IP address.

So if the E-911 VoIP service requires that you have
a base phone number that is within your E-911 region
that doesn't seem like a problem to me since you can
have any number of virtual phone numbers in addition
to the base number.

--Michael Dillon

Re: Is current DDoS detecting method effective?

[Joe Shen]

Hi,


> 
> you aren't distinguishing between 'dos attack' and
> 'scan' or 'probe' or
> 'welcome to the Internet!' traffic. The Arbor
> systems may see 'scan'
> traffic (depending upon sample rates and traffic
> loads) and they may
> not... They aren't designed to see that, they are
> designed to: (speaking
> of peakflow SP, peakflow Traffic, peakflow DoS
> only... peakflow X isn't
> really a 'provider' solution as much as a
> 'enterprise' tool)

That's what I think current tool not enough, because
we can not think ongoing traffic is not malicious when
tools are building up 'normal' traffic model in ISP
networks.

But, in enterprise  network this could be achived
because traffic pattern for a enterprise could be
estimated, and load on special server could be
controled by threshhold (but, think about CNN website
on 911 ) 
  

> 
> 1) to watch traffic and alarm against thresholds
> 2) track traffic trends over time
> 3) report traffic trends over time
> 

So, it need to define what should be monitored ( port,
protocol, application data set ...) ? 


> (possibly some other things out of scope of this
> discussion... someone
> from Arbor could/should clarify)
> 
> Some of your cflowd gathering should also see these
> things, but they will
> need data correlation, something Arbor already went
> to the trouble of
> doing for you... So, define: "attack" and then see
> if your tool fits that
> definition.
>  

So, I think current tool is just for enterprise , or
for ISPs who want to provide anti-DoS services. 

regards

Joe

  
 


__
Do You Yahoo!?
Log on to Messenger with your mobile phone!
http://sg.messenger.yahoo.com

Re: public accessible snmp devices?

[Alexei Roudnev]

Cisco drops SNMP requests but not return '0', I saw it (dropped requests
because of _busy_) many times.
- Original Message - 
From: "Petri Helenius" <[EMAIL PROTECTED]>
To: "Jim Popovitch" <[EMAIL PROTECTED]>
Cc: "Alexei Roudnev" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;

Sent: Sunday, March 06, 2005 7:18 AM
Subject: Re: public accessible snmp devices?


>
> Jim Popovitch wrote:
>
> >
> >I think this could be relevant.  a LOT of devices drop snmp requests
> >when they get busy or when too many incoming requests occur.  Are you
> >sure that you were the only one polling that device?  Perhaps someone
> >else put it into a "busy" state.  Too often with SNMP devices and tools
> >a '0' can mean things other than zero.
> >
> >
> So you are saying that it's ok for a Cisco or Juniper router to return
> zero for a counter when they feel "busy" ?
>
> My RFC collection tells a different story.
>
> Pete
>

Re: public accessible snmp devices?

[Alexei Roudnev]

It's OK to see any garbage in SNMP; I never got surprised (as I was not
surprised when I killed firewall by snmpwalk).
No one (in reality) makes good QA on SNMP functions (on routers or
switches).

I already have a few sanity checks in 'snmpstat', may be I should add one
more (ignore answers with 0 counters).


- Original Message - 
From: "Petri Helenius" <[EMAIL PROTECTED]>
To: "Jim Popovitch" <[EMAIL PROTECTED]>
Cc: "Alexei Roudnev" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;

Sent: Sunday, March 06, 2005 7:18 AM
Subject: Re: public accessible snmp devices?


> Jim Popovitch wrote:
>
> >
> >I think this could be relevant.  a LOT of devices drop snmp requests
> >when they get busy or when too many incoming requests occur.  Are you
> >sure that you were the only one polling that device?  Perhaps someone
> >else put it into a "busy" state.  Too often with SNMP devices and tools
> >a '0' can mean things other than zero.
> >
> >
> So you are saying that it's ok for a Cisco or Juniper router to return
> zero for a counter when they feel "busy" ?
>
> My RFC collection tells a different story.
>
> Pete
>