Re: Blackworm hunbers

[Simon Waters]

On Wednesday 25 Jan 2006 22:31, Fergie wrote:
>
> "Of course, it’s possible that this URL has gotten out to
> the public, which would increase the count (simply hitting
> the website increments the count by one).  However, to my
> knowledge, this URL is only known in the security community.

The SANS diary suggests that the requests from the worm itself are quite 
distinctive, so it should be possible to spot idle curiousity, search bots, 
and other interested parties from the worm itself.

Of course it may be that the monitoring of the traffic isn't subtle enough to 
distinguish between these two types of traffic.

Occurs to me that 700,000 Windows reinstalls in a day is probably about 
average given market share, and reliability of the OS, so 700,000 thousand 
extra is probably just a busy day. Might be a peak in demand for Windows 
updates afterwards.

The talk of antivirus tools are misplaced, the correct tool to deal with 
something like this is a good back-up, but for too long people have sold PCs 
for end users without any backup service at all. 

My home desktop has a tape backup unit (and RAID 1). I just wish I could be so 
confident about every desktop we use at work.

As Bill Hassell signature said

"There are two types of computer users in the
 world...those that have lost data, and those
 that are going to."(blh, circa 1972)

Re: Martin Hannigan

[Michael . Dillon]

> What is it you do again? Anything what-so-ever?

Martin is the 21st century version of Jim Fleming and
Jeff Williams. He entertains us with his hyperbole.

Does anyone take him seriously anymore?

Re: BlackWorm infected IP's reporting

[Michael . Dillon]

> Trust is earned, it cannot be gained by shouting

Then why are people on the list shouting that their
listed of trusted sources is more trustworthy than 
the other guys?

Seems to me more like marketing than anything else.
Is NANOG now a marketing list where people tell everyone
how great they are?

--Michael Dillon

Re: Martin Hannigan

[Paul Vixie]

> Martin is the 21st century version of Jim Fleming and
> Jeff Williams. He entertains us with his hyperbole.

i don't know if i'd go THAT far.  none of those (fleming, williams, hannigan)
entertains me with their nanog posts.  (and neither does gadi.)  with usenet
gone, we just don't teach our kids entertainment-level hyperbole any more.
-- 
Paul Vixie

Re: So -- what did happen to Panix?

[Daniel Golding]

In terms of the larger question

ConEd Communications was recently acquired by RCN. I'm not sure if the
transaction has formally closed. I suspect there are serious transition
issues occurring. "Financial Stability", "Employee Churn", and "Ownership"
are, unfortunately, tough things to factor into BGP algorithms.

http://investor.rcn.com/ReleaseDetail.cfm?ReleaseID=181194

Internet access has always been a sideline for CEC - they are more of a
provider of transport, and their customers have included some very well
known entities in the NY metro area.

Perhaps someone from RCN would care to comment?

- Dan

Focal Issues?

[Mike Callahan]

Any one else experiencing packet loss on the Focal/Broadwing Network?


=

Target: 192.5.6.30
Date: 1/26/2006 (Thursday), 12:23:23 PM
Nodes: 20
 Node Data
Node Net Reg IP Address  LocationNode Name

   5   3   - 207.148.192.67  Warren  
   6   3   - 207.148.192.181 Warren  
   7   4   1 66.114.196.169  Detroit 66-114-196-169.focaldata.net
   8   4   1 66.114.196.2Detroit core2.dtw.focaldata.net
   9   -   1 66.114.196.50   Detroit 66-114-196-50.focaldata.net
  10   5   - 216.140.15.145  Chicago 
  11   -   2 216.140.15.18   Chicago g2-3.rp0.chcg.broadwing.net
  12   6   3 157.130.109.1   Chicago 
gigabitethernet2-0.gw2.chi13.alter.net
  13   7   3 152.63.71.218   Cleveland   0.so-2-1-0.xl2.chi13.alter.net
  14   7   3 152.63.38.150   WASHINGTON D.C. 0.so-6-0-0.xl2.dca5.alter.net
  15   7   3 152.63.39.65WASHINGTON D.C. pos7-0.gw1.dca5.alter.net
  16   8   3 65.207.91.246   WASHINGTON D.C. 
verisign-gw11.customer.alter.net
  17   9   - 65.205.32.138   39.333N,  77.844W   
  18  10   - 65.205.32.4239.333N,  77.844W   
  19  11   - 198.41.3.25338.983N,  77.378W   
  20  12   4 192.5.6.30  39.333N,  77.844W   a.gtld-servers.net

 Packet Data
Node High Low  Avg  Tot  Lost
   100010
   2601   550
   3   3202   540
   4   3201   540
   5  1710   58   540
   6  15703   540
   7   3704   540
   8   3504   540
   9  231   19   28   540
  10   74   20   46   64   10
  11  203   22   31   553
  12   48   17   25   542
  13   49   16   23   553
  14   77   40   51   576
  15   76   41   54   556
  16  175   44   59   566
  17  255   43   64   555
  18      98   98
  19  150   44   65   502
  20   87   44   74   524


=

Target: yahoo.com
Date: 1/26/2006 (Thursday), 12:24:18 PM
Nodes: 19
 Node Data
Node Net Reg IP Address  LocationNode Name
 
   5   3   - 207.148.192.67  Warren  
   6   3   - 207.148.192.181 Warren  
   7   4   1 66.114.196.169  Detroit 66-114-196-169.focaldata.net
   8   4   1 66.114.196.2Detroit core2.dtw.focaldata.net
   9   -   1 66.114.196.50   Detroit 66-114-196-50.focaldata.net
  10   5   - 216.140.15.145  Chicago 
  11   6   2 216.140.15.141  Indianapolisp5-0.gnwd.broadwing.net
  12   7   2 216.140.15.129  Fort Worth  p4-0.c0.ftwo.broadwing.net
  13   8   2 216.140.4.226   Dallas  s2-2-0.a1.dlls.broadwing.net
  14   9   2 216.140.5.66Austin  ge-3-1.rp0.dlls.broadwing.net
  15  10   - 67.99.65.2  Unknown 
  16  11   3 216.115.101.134 Sunnyvale   so-5-1-0.pat2.pao.yahoo.com
  17  11   3 216.115.106.207 San Jose
ge-4-0-0-p451.msr2.scd.yahoo.com
  18  12   3 66.218.82.217   San Joseten-1-3-bas1.scd.yahoo.com
  19  13   3 66.94.234.13San Josew2.rc.vip.scd.yahoo.com

 Packet Data
Node High Low  Avg  Tot  Lost
   100010
   2200   890
   3   340   32   890
   4   3400   890
   5  20100   890
   6   6500   880
   7   6300   880
   8   3700   891
   9   60   19   36   969
  10   65   21   44   937
  11   58   23   51   927
  12   74   40   64   929
  13   84   41   73   884
  14  222   40  131   929
  15   96   38   65   907
  16  150   74   99   93   12
  17  154   75   96   908
  18  136   76   94   898
  19  147   77   98   909
 

Re: So -- what did happen to Panix?

[Matt Buford]

"Daniel Golding" <[EMAIL PROTECTED]> wrote:

ConEd Communications was recently acquired by RCN. I'm not sure if the
transaction has formally closed. I suspect there are serious transition
issues occurring. "Financial Stability", "Employee Churn", and "Ownership"
are, unfortunately, tough things to factor into BGP algorithms.


I have no idea if this is really related, but the issue was the same weekend 
that ConEd had major network maintenance going on.  My ConEd service was 
down (NYC area) for the entire weekend (about 60 hours) during their planned 
maintenance window to convert their network to MPLS.  I saw their 
maintenance notice and noticed that the window lasted multiple days.  I 
expected the link to go down - but I never imagined they meant it would stay 
down for the entire maintenance window.


So, I'm speculating that even if there weren't organization issues their 
engineers were probably very busy and distracted by the major technical 
changes going on. 

Re: VeriSign

[John A. Kilpatrick]

On Wed, 25 Jan 2006, Martin Hannigan wrote:


I would like to thank all of you for your support while I worked
at VeriSign.


Hi there - what team were you on?  I joined VeriSign about 2 months ago 
and I am on Network West.


Thanks,
John

--
   John A. Kilpatrick
[EMAIL PROTECTED]Email| http://www.hypergeek.net/
[EMAIL PROTECTED]  Text pages|  ICQ: 19147504
 remember:  no obstacles/only challenges

Re: Wifi SIP WPA/PSK Support

[Crist Clark]

Mike Leber wrote:
[snip]


I've had a few people say that there was some sort of conspiracy to keep
US citizens from using secure phones, however I found that laughable
because

[snip]

Because domestically the US gov't (or local LEOs) can just intercept the
calls when they hit the PSTN. They don't bother intercepting between the
phone and its access point.

Now, whether there are LEOs pushing against end-to-end encryption
becoming widely available to consumers is a whole separate issue.
--
Crist J. Clark   [EMAIL PROTECTED]
Globalstar Communications(408) 933-4387

Re: So -- what did happen to Panix?

[Todd Underwood]

Steven, all,

On Wed, Jan 25, 2006 at 03:04:30PM -0500, Steven M. Bellovin wrote:
> 
> It's now been 2.5 business days since Panix was taken out.  Do we know 
> what the root cause was?  It's hard to engineer a solution until we 
> know what the problem was.

I keep hearing that Con Ed Comm was previously an upstream of of Panix
( http://www.renesys.com/blog/2006/01/coned_steals_the_net.shtml#comments )
and that this might have explained why Con Ed had Panix routes in
their radb as-27506-transit object.  But I checked our records
of routing data going back to jan 1, 2002, and see no evidence of
27506 and 2033 being adjacent to each other in any announcement from
any of our peers at any time since then.  So I can't really verify
that Panix was ever a Con Ed Comm customer.  Can anyone else clear
this up?  So far, it's not making sense.

The supposition was that all of the other affected ASes that are not
currently customers of Con Ed Comm were also previously customers.
Some appear to have been (Walrus Internet (AS7169), Advanced Digital
Internet (AS23011), and NYFIX (AS20282) for sure) but I haven't been
able to verify that all of them were.  

I know that this isn't really a "root cause" that Steven was asking
for, though.  The root cause is that filtering is imperfect and out of
date frequently. This case is particularly intersting and painful
because Verio is known for building good filters automatically.  In
this case, they did so based on out-of-date information,
unfortunately. This is particularly depressing because normally in
cases of leaks like this, the propagation is via some provider or peer
who doesn't filter at all.  In this case, one of the vectors was one
of the most responsible filterers on the net.  sigh. 

So in terms of engineering good solutions, the space is pretty
crowded.  One camp is of the "total solution" variety that involves
new hardware, new protocols, and a Public Key approach where
originations (or any announcements) are signed and verified.  This is
obviously a very good and complete approach to the problem but it's
also obviously seeing precious little adoption.  And in the mean time
we have nothing.

Another set of approaches has been to look at alternate methods of
building filters, taking into account more information about history
of routing announcements and dampening or refusing to accept novel,
questionable announcements for some fixed, short amount of time.  Josh
Karlin's paper suggests that as does some of the stuff that Tom
Scholl, Jim Deleskie and I presented at the last nanog. All of this
has the disadvantage of being a partial solution, the advantage of
being implementable easily and in stages without a network forklift or
a protocol upgrade, but the further disadvantage of being nowhere near
fully baked. 

Clearly more, smarter people need to keep searching for good solutions
to this set of problems.  Extra credit for solutions that can be
implemented by individual autonomous systems without hardware upgrades
or major protocol changes, but that may not be possible.

t.

p.s.:  wrt comments made previously that imply that moving parts of
routing control off of the routers is "Bell-like" or "bell-headed":
although the comments are silly and made somewhat in jest, they're
obviously not true.  anyone who builds prefix filters or access lists
off of routers is already generating policy somewhere other than the
router.  using additional history or smarts to do that and uploading
prefix filters more often doesn't change that existing architecture or
make the network somehow "bell-like".  it might not work well enough
to solve the problem, but that's another, interesting objection.


-- 
_
todd underwood
chief of operations & security 
renesys - internet intelligence
[EMAIL PROTECTED]   http://www.renesys.com/blog

RE: Wifi SIP WPA/PSK Support

[Casey Halverson]

What is the list price for this device?  They do not seem to have any
facility for ordering.
 

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Mike Leber
> Sent: Wednesday, January 25, 2006 10:08 PM
> To: Suresh Ramasubramanian
> Cc: nanog@merit.edu
> Subject: Re: Wifi SIP WPA/PSK Support
> 
> 
> 
> Thank you!  We'll order one immediately and report back.
> 
> Mike.
> 
> On Thu, 26 Jan 2006, Suresh Ramasubramanian wrote:
> 
> > On 1/26/06, Mike Leber <[EMAIL PROTECTED]> wrote:
> > I'm working on finding a Wifi SIP phone that supports 
> WPA/PSK that we 
> > can recommended to VOIP clients.  As everybody knows, 
> currently most 
> > Wifi SIP phones support WEP which is demonstrably insecure.  For 
> > banking and financial customers, or companies that are 
> given passwords 
> > or credit cards over the phone, this is a serious security issue.
> 
> http://www.paesys.com/en/WIFI_wireless_phone_moimstone_Stonehe
> nge_WP150.htm
> 
>Security & Encryption
> WPA-PSK AES, TKIP
> 64/128 bit WEP
> 802.1x certification (Optional)
> 
> Even seems to do v6.
> 
> -srs
> 

RE: Wifi SIP WPA/PSK Support

[Frank Bulk]

I've been tracking the Wi-Fi SIP phone space for some time, and have
documented all the phones that I could find here:
http://www.mtcnet.net/~fbulk/VoWLAN.doc
It's about a 7 MB file because I've included pictures of these devices where
I could find them.

Because we just installed a SIP proxy server on our switch I took the
opportunity to purchase and try out 4 Wi-Fi SIP phones: 
- Hitachi IPC-5000
- UTStarcom F1000
- Pulver WiSIP/ZyXEL P-2000W v1
- ZyXEL P-2000 v2

The last two offer identical user interface and functionality but a
different shell.  

The Hitachi doesn't offer WPA support, but it does do 802.1X (specifically
EAP-MD5, EAP-TLS, PEAP, and EAP-TTLS) with WEP.  That probably means it can
hand out WEP keys, and perhaps perform dynamic WEP.  The only phone to
support WPA from that short list is the F1000 with 3.60 or higher firmware,
and that's only WPA-PSK.

If you look in the Word document you'll see there are other phones that
offer WPA support, but there not are readily available in the North American
market.

Kind regards,

Frank

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike
Leber
Sent: Wednesday, January 25, 2006 10:35 PM
To: nanog@merit.edu
Subject: Wifi SIP WPA/PSK Support



I'm working on finding a Wifi SIP phone that supports WPA/PSK that we can
recommended to VOIP clients.  As everybody knows, currently most Wifi SIP
phones support WEP which is demonstrably insecure.  For banking and
financial customers, or companies that are given passwords or credit cards
over the phone, this is a serious security issue.

We recently bought a Hitachi-Cable Wireless IPC-5000 WiFi SIP Phone from
voipsupply.com after finding some web pages that said that phone supported
WPA (the pages were in German), yet once we got the phone all it supported
was WEP even after updating the firmware to the latest version using the
website mentioned in the documentation that came with the phone.

I've had a few people say that there was some sort of conspiracy to keep
US citizens from using secure phones, however I found that laughable
because the potential risk of terrorist or criminal interception from
having all Wifi telephone conversations involving credit cards (let alone
social security numbers, bank account numbers, passwords, what have you)
in the clear would create an attack vector so large as to exceed all other
possible attack vectors... I mean why work on cracking anything when you
can just listen to everybody in the clear (well virtually in the clear
with WEP).

So, back in reality, could anybody in the US that bought their Wifi SIP
phone in the US share a success story at getting Wifi SIP setup with
WPA/PSK?  What model of phone did you buy?  Where did you get it?  Did you
have to upgrade it to any special version of firmware or what?

Mike.

+- H U R R I C A N E - E L E C T R I C -+
| Mike Leber   Direct Internet Connections   Voice 510 580 4100 |
| Hurricane Electric Web Hosting  Colocation   Fax 510 580 4151 |
| [EMAIL PROTECTED]   http://www.he.net |
+---+

ongoing DDoS...

[Barry Shein]

[Feel free to respond with: take it to list XYZZY]

There's been an ongoing DDoS here at world.std.com (The World) tho
it's not quite DoS'ing (you got this, right?) it's getting very tiring
and obviously is affecting many systems "out there".

The MO: (easy to understand but pretty nasty):

What I presume is a zombie army sending out gazillions of emails to
thousands of hosts out there (not ours) with a randomly generated
(usually) return/source address @ our domain(s). The target addresses
are usually also unknown so it just bounces back at us.

Besides the obvious SMTP traffic this also generates a lot of DNS
traffic. At this point the DNS traffic seems to be more of a nuisance
probably because so many target hosts are retrying. At one point we
were doing around 10K pkts/second in DNS traffic, very unusual.

This has been going on for about a week.

I'd hoped some little mitigation tricks here and there and a few days'
patience and the excess mouths would get tired of this and go back to
stuffing neighbors' pets down their garbage disposals for yucks, etc.

So where does one start. It seems a mother ship needs to be shut down
somewhere, etc. Obviously ID'ing a miscreant would be a nice result.


P.S. If you think "get a firewall": The problem traffic is coming from
legitimate hosts in the form of DNS+SMTP, not the bots (not to us
anyhow.) So not so simple, what's the filter?

-- 
-Barry Shein

The World  | [EMAIL PROTECTED]   | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD| Login: Nationwide
Software Tool & Die| Public Access Internet | SINCE 1989 *oo*

Re: Martin Hannigan. He rocks!

[Martin Hannigan]

> 
> 
> > Martin is the 21st century version of Jim Fleming and
> > Jeff Williams. He entertains us with his hyperbole.
> 
> i don't know if i'd go THAT far.  none of those (fleming, williams, hannigan)
> entertains me with their nanog posts.  (and neither does gadi.)  with usenet
> gone, we just don't teach our kids entertainment-level hyperbole any more.


I'm not sure whether to take that as a compliment or an insult, but
I noticed you did forget to say "My employer said" so at least it's
probably not actionable by any latigous, animal crackers.

And in all my years running news, I never came cross fleming or
williams so I wouldn't know. Someone called me and made a Denniger
and an Auerbach reference. I like both Karls so I'll take that as
a compliment. Regardless, it's good to be alive for another day 
on the Internet becayse that's all it is - another day on the
Internet.

Best,

-M<

Re: So -- what did happen to Panix?

[Jared Mauch]

Dislcaimer: I work for AS2914

On Thu, Jan 26, 2006 at 02:39:59PM -0500, Todd Underwood wrote:
> Another set of approaches has been to look at alternate methods of
> building filters, taking into account more information about history
> of routing announcements and dampening or refusing to accept novel,
> questionable announcements for some fixed, short amount of time.  Josh
> Karlin's paper suggests that as does some of the stuff that Tom
> Scholl, Jim Deleskie and I presented at the last nanog. All of this
> has the disadvantage of being a partial solution, the advantage of
> being implementable easily and in stages without a network forklift or
> a protocol upgrade, but the further disadvantage of being nowhere near
> fully baked. 
> 
> Clearly more, smarter people need to keep searching for good solutions
> to this set of problems.  Extra credit for solutions that can be
> implemented by individual autonomous systems without hardware upgrades
> or major protocol changes, but that may not be possible.
> 
> t.
> 
> p.s.:  wrt comments made previously that imply that moving parts of
> routing control off of the routers is "Bell-like" or "bell-headed":
> although the comments are silly and made somewhat in jest, they're
> obviously not true.  anyone who builds prefix filters or access lists
> off of routers is already generating policy somewhere other than the
> router.  using additional history or smarts to do that and uploading
> prefix filters more often doesn't change that existing architecture or
> make the network somehow "bell-like".  it might not work well enough
> to solve the problem, but that's another, interesting objection.

This is something that (as i mentioned to you in private) some others
have thought of as well.  We at 2914 build the filters and such off-the-route
and load them to the router with sometimes quite large configurations.
(they have been ~8MB in the past)

I'd love to see some prefix stability data (eg: 129.250/16
has been announced by origin-as 2914 for X years/seconds/whatnot)
which can help score the data better.  Do we need a origin-as match
in our router policies?  does it exist already?  What about a way to
dampen/delay announcements that don't match the origin-as data
that exists?

I think a solution like this would help out a number of networks
that have these types of problems/challenges.  Obviously noticing an
origin change and alerting or similar on that would be nice and useful,
but would the noise be too much for a NOC display?

- jared

ps. i'm glad our NOC/operations people were able to solve the PANIX
issue quickly for them.

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

RE: Wifi SIP WPA/PSK Support

[Casey Halverson]

I have actually been following this as well, and I have tested several
of these handsets.  Others have been impossible to source.  Typically
startups will attempt to bring a wifi voip handset to the market,
realize there is no demand, and fold.

In the particular discussion of WPA:

Note that the two Senaos listed claim WPA support, but this is not
available in the current firmware.  There also hasn't been any updates
to it in a year or so -- don't expect it anytime soon.

 

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Frank Bulk
> Sent: Thursday, January 26, 2006 12:56 PM
> To: nanog@merit.edu
> Subject: RE: Wifi SIP WPA/PSK Support
> 
> 
> 
> I've been tracking the Wi-Fi SIP phone space for some time, 
> and have documented all the phones that I could find here:
> http://www.mtcnet.net/~fbulk/VoWLAN.doc
> It's about a 7 MB file because I've included pictures of 
> these devices where I could find them.
> 
> Because we just installed a SIP proxy server on our switch I 
> took the opportunity to purchase and try out 4 Wi-Fi SIP phones: 
> - Hitachi IPC-5000
> - UTStarcom F1000
> - Pulver WiSIP/ZyXEL P-2000W v1
> - ZyXEL P-2000 v2
> 
> The last two offer identical user interface and functionality 
> but a different shell.  
> 
> The Hitachi doesn't offer WPA support, but it does do 802.1X 
> (specifically EAP-MD5, EAP-TLS, PEAP, and EAP-TTLS) with WEP. 
>  That probably means it can hand out WEP keys, and perhaps 
> perform dynamic WEP.  The only phone to support WPA from that 
> short list is the F1000 with 3.60 or higher firmware, and 
> that's only WPA-PSK.
> 
> If you look in the Word document you'll see there are other 
> phones that offer WPA support, but there not are readily 
> available in the North American market.
> 
> Kind regards,
> 
> Frank
> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Mike Leber
> Sent: Wednesday, January 25, 2006 10:35 PM
> To: nanog@merit.edu
> Subject: Wifi SIP WPA/PSK Support
> 
> 
> 
> I'm working on finding a Wifi SIP phone that supports WPA/PSK 
> that we can recommended to VOIP clients.  As everybody knows, 
> currently most Wifi SIP phones support WEP which is 
> demonstrably insecure.  For banking and financial customers, 
> or companies that are given passwords or credit cards over 
> the phone, this is a serious security issue.
> 
> We recently bought a Hitachi-Cable Wireless IPC-5000 WiFi SIP 
> Phone from voipsupply.com after finding some web pages that 
> said that phone supported WPA (the pages were in German), yet 
> once we got the phone all it supported was WEP even after 
> updating the firmware to the latest version using the website 
> mentioned in the documentation that came with the phone.
> 
> I've had a few people say that there was some sort of 
> conspiracy to keep US citizens from using secure phones, 
> however I found that laughable because the potential risk of 
> terrorist or criminal interception from having all Wifi 
> telephone conversations involving credit cards (let alone 
> social security numbers, bank account numbers, passwords, 
> what have you) in the clear would create an attack vector so 
> large as to exceed all other possible attack vectors... I 
> mean why work on cracking anything when you can just listen 
> to everybody in the clear (well virtually in the clear with WEP).
> 
> So, back in reality, could anybody in the US that bought 
> their Wifi SIP phone in the US share a success story at 
> getting Wifi SIP setup with WPA/PSK?  What model of phone did 
> you buy?  Where did you get it?  Did you have to upgrade it 
> to any special version of firmware or what?
> 
> Mike.
> 
> +- H U R R I C A N E - E L E C T R I C 
> +-+
> | Mike Leber   Direct Internet Connections   Voice 
> 510 580 4100 |
> | Hurricane Electric Web Hosting  Colocation   Fax 
> 510 580 4151 |
> | [EMAIL PROTECTED]   
> http://www.he.net |
> +-
> --+
> 
> 
> 

Re: So -- what did happen to Panix?

[Josh Karlin]

The noise of origin changes is fairly heavy, somewhere in the low
hundreds of alerts per day given a 3 day history window.  Supposing a
falsely originated route was delayed, what is the chance of identifying
and fixing it before the end of the delay period?  Do operators
commonly catch misconfigurations on their own or do they usually find
out about it from other operators due to service disruption?

Current Blackworm numbers

[Fergie]

Given all the noise that this issue has caused on the list, I
thought I'd take a moment this afternoon and forward a URL that
good folks over at LURHQ have made available with more realistic,
and current, statistics on the BlackWorm cruft:

 http://www.lurhq.com/blackworm-stats.html

Thanks to Joe Stewart at LURHQ.

Cheers,

- ferg



-- Martin Hannigan <[EMAIL PROTECTED]> wrote:

[snip]

The point I was trying to make before the thread went, East?, was 
that there is a perceived problem in the security community with 
approrpriate response. I'd tell you how I think that could have
been avoided, but then my name would go up in the subject again.
*cough full disclosure* 

[snip]

--
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 [EMAIL PROTECTED] or [EMAIL PROTECTED]
 ferg's tech blog: http://fergdawg.blogspot.com/

Re: Martin Hannigan. In my pants!

[Matt Ghali]

On Thu, 26 Jan 2006, Martin Hannigan wrote:


And in all my years running news, I never came cross fleming or
williams so I wouldn't know. Someone called me and made a Denniger
and an Auerbach reference.


Whoa. What ever happened to Karl Denninger anyway?

[EMAIL PROTECTED]<
  The only thing necessary for the triumph
  of evil is for good men to do nothing. - Edmund Burke

Re: Martin Hannigan. In my pants!

[Chris Owen]

On Thu, 26 Jan 2006, Matt Ghali wrote:

> On Thu, 26 Jan 2006, Martin Hannigan wrote:
>
> > And in all my years running news, I never came cross fleming or
> > williams so I wouldn't know. Someone called me and made a Denniger
> > and an Auerbach reference.
>
> Whoa. What ever happened to Karl Denninger anyway?

http://genesis3.blogspot.com/

Chris

--
~~~
Chris Owen~ Garden City (620) 275-1900 ~  Lottery (noun):
President ~ Wichita (316) 858-3000 ~A stupidity tax
Hubris Communications Inc ~   www.hubris.net   ~
~~~

Re: Martin Hannigan. In my pants!

[matthew zeier]

Matt Ghali wrote:


On Thu, 26 Jan 2006, Martin Hannigan wrote:


And in all my years running news, I never came cross fleming or
williams so I wouldn't know. Someone called me and made a Denniger
and an Auerbach reference.



Whoa. What ever happened to Karl Denninger anyway?


Oh wow... MCSNet.  I used to work at a local competing ISP and have "fond" 
memories of those days. Google shows http://www.denninger.net/ .

Re: Martin Hannigan. In my pants!

[Matt Ghali]

On Thu, 26 Jan 2006, Chris Owen wrote:

On Thu, 26 Jan 2006, Matt Ghali wrote:


Whoa. What ever happened to Karl Denninger anyway?


http://genesis3.blogspot.com/


Now I really wish I hadn't asked.

matto

[EMAIL PROTECTED]<
  The only thing necessary for the triumph
  of evil is for good men to do nothing. - Edmund Burke

Re: So -- what did happen to Panix?

[Jared Mauch]

On Thu, Jan 26, 2006 at 04:22:29PM -0700, Josh Karlin wrote:
> The noise of origin changes is fairly heavy, somewhere in the low
> hundreds of alerts per day given a 3 day history window.  Supposing a
> falsely originated route was delayed, what is the chance of identifying
> and fixing it before the end of the delay period?  Do operators
> commonly catch misconfigurations on their own or do they usually find
> out about it from other operators due to service disruption?

Are the origin changes for a small set of the prefixes
that tend to repeat (eg: connexion as planes move), or is it a different
set of prefixes day-to-day or week-to-week?

I suspect there are the obvious prefixes that don't change
(eg: 12/8, 18/8, 35/8, 38/8)  but subparts of that may change, but
for most people with allocations in the range of 12-17 bits, I suspect
they won't change frequently.

- jared

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

Re: So -- what did happen to Panix?

[Josh Karlin]

I unfortunately don't have answers to those questions, but you've
piqued my interest so I will try to look into it within the next
couple of days.

Josh



On 1/26/06, Jared Mauch <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 26, 2006 at 04:22:29PM -0700, Josh Karlin wrote:
> > The noise of origin changes is fairly heavy, somewhere in the low
> > hundreds of alerts per day given a 3 day history window.  Supposing a
> > falsely originated route was delayed, what is the chance of identifying
> > and fixing it before the end of the delay period?  Do operators
> > commonly catch misconfigurations on their own or do they usually find
> > out about it from other operators due to service disruption?
>
> Are the origin changes for a small set of the prefixes
> that tend to repeat (eg: connexion as planes move), or is it a different
> set of prefixes day-to-day or week-to-week?
>
> I suspect there are the obvious prefixes that don't change
> (eg: 12/8, 18/8, 35/8, 38/8)  but subparts of that may change, but
> for most people with allocations in the range of 12-17 bits, I suspect
> they won't change frequently.
>
> - jared
>
> --
> Jared Mauch  | pgp key available via finger from [EMAIL PROTECTED]
> clue++;  | http://puck.nether.net/~jared/  My statements are only mine.
>

Re: So -- what did happen to Panix?

[Randy Bush]

jared,

i may have missed the answer to my question.  but, as verio was
the upstream, and verio is known to use the irr to filter, could
you tell us why that approach seemed not to suffice in this case?

randy

Re: Wifi SIP WPA/PSK Support

[Suresh Ramasubramanian]

On 1/27/06, Casey Halverson <[EMAIL PROTECTED]> wrote:
> What is the list price for this device?  They do not seem to have any
> facility for ordering.
>

They're based out of Seoul .. http://www.moimstone.com/Contactus/contactus.html

Got some other nice looking IP phone / VOIP products available.

No online ordering that I can see.

Re: So -- what did happen to Panix?

[Jared Mauch]

On Thu, Jan 26, 2006 at 05:41:10PM -0800, Randy Bush wrote:
> jared,
> 
> i may have missed the answer to my question.  but, as verio was
> the upstream, and verio is known to use the irr to filter, could
> you tell us why that approach seemed not to suffice in this case?

Sure, what I saw by going through the diffs, etc.. that I have
available to me is that the prefix was registered to be announced
by our customer and hence made it into our automatic IRR filters.  it was
no longer in there by the time that I personally looked things up in
our registry, but saw diffs go through removing that prefix later in
the day (night) from the acl.

Someone that has a snapshot of the various IRR data from 
those days can likely put this together better than I can explain.

- jared

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

Re: Current Blackworm numbers

[Gadi Evron]

Fergie wrote:

Given all the noise that this issue has caused on the list, I
thought I'd take a moment this afternoon and forward a URL that
good folks over at LURHQ have made available with more realistic,
and current, statistics on the BlackWorm cruft:

 http://www.lurhq.com/blackworm-stats.html

Thanks to Joe Stewart at LURHQ.


Indeed! Joe Stewart (at LURHQ) and his work are both amazing.

He took the information we at the TISF BlackWorm task force got from RCN 
(.com/.net - I have never seen a more whitehat ISP in my life) with the 
FBI's help, and spent days working on the worm and the data, de-duping, 
removing the hosts trying to poison the logs data or DDoS, etc.


He deserves the credit!

There are so many other people working day and night on this:

The incredible Johannes Ullrich at SANS ISC and tireless Prof. Randy 
Vaughn at Baylor EDU, as well as many others...


Many from the net-ops community.
The SANS handlers (ALL OF THEM), who are always there when called.

The FBI, US-CERT, DoD-CERT, REN-ISAC, KrCERT, FortiNet, MessageLabs... 
... .. and many many others around the globe who still work on this and 
invest a ton of effort. They deserve the credit.


Like Joe wrote:
"Even so, 300,000 infected users worldwide is not a terribly large 
amount when compared to previous worms like Sober or Mydoom. However, 
with this worm it isn't the quantity of infected users, it is the 
destructive payload which is most concerning."


Gadi.

Re: ongoing DDoS...

[Jason Frisvold]

On 1/26/06, Barry Shein <[EMAIL PROTECTED]> wrote:
> What I presume is a zombie army sending out gazillions of emails to
> thousands of hosts out there (not ours) with a randomly generated
> (usually) return/source address @ our domain(s). The target addresses
> are usually also unknown so it just bounces back at us.

Some sort of a user check should mitigate most of this..  ie, drop at
the smtp level, don't bounce.

> Besides the obvious SMTP traffic this also generates a lot of DNS
> traffic. At this point the DNS traffic seems to be more of a nuisance
> probably because so many target hosts are retrying. At one point we
> were doing around 10K pkts/second in DNS traffic, very unusual.

10K/s is a lot..  I would expect a lot less..  Presumably the source
of the DNS requests would be another DNS server who should be caching
the result.

Try increasing the TTL for the "offending" records...  I see it's at
24 hours at the moment though.

Can you do some sniffing to determine the source of the lookups? 
Perhaps a broken dns server or two out there?

> P.S. If you think "get a firewall": The problem traffic is coming from
> legitimate hosts in the form of DNS+SMTP, not the bots (not to us
> anyhow.) So not so simple, what's the filter?

Throttle on the gateway?  Specifically, throttle DNS traffic to start
if that's doing the most damage, and then throttle smtp if necessary..
Depend on the remote retry to handle any timeouts..

> --
> -Barry Shein


--
Jason 'XenoPhage' Frisvold
[EMAIL PROTECTED]

A request for your support of:hutzler-spamops-05.txt

[Dave Crocker]

Folks,

Howdy.

Carl Hutzler, Pete Resnick, Robert Sanders, Eric Allman and I pulled together a
BCP (Best Current Practices) draft document as a result of a number of
discussions between some ASRG members and the old ASTA (antispam technical
alliance) group. The latest version of the document is published on the MIP
Association site and has been submitted to the IETF. We have gone through 5 
drafts now with reasonable review during each stage.


Document locations:

   http://mipassoc.org/spamops/draft-hutzler-spamops-05.txt
   http://ietfreport.isoc.org/all-ids/draft-hutzler-spamops-05.txt

If you are not familiar with the document, the main ideas expressed are how:

1) To improve lines of *accountability* for controlling abusive uses of the
Internet mail service. (when abuse happens, which party is responsible)

2) To provide recommendations for *constructive operational policies* between
independent operators of email transmission services including the submission
(or posting) of email into the transmission network (certainly very relevant to
the deployment of DKIM and other email authentication type technologies)

We are at a stage in the life cycle of this document where it would be helpful
to see a renewed support from the technical community.


*  So how can you help?  Simple!

Just reply back to me or any of the authors (email addresses available in the
document itself) with a couple of words of support:

- how this document might help you justify doing the right thing (maybe to your
management)

- how this document helps establish inter-isp best practices and breakdown of
responsibilities for abuse situations

- how this document helps establish important operational practices in the area
of Email Authentication deployment

- other?

We will pull together the words of support and provide them to Bert Wijnen as a
way to show the level of interest in getting this thing through. (FYI, Bert
Wijnen is the Operations and Management Area Director we have been working with
on this final stage.)

Thank you in advance,
Dave (on behalf of all of the authors)

--

Dave Crocker
Brandenburg InternetWorking

Re: ongoing DDoS...

[Suresh Ramasubramanian]

On 1/27/06, Barry Shein <[EMAIL PROTECTED]> wrote:
> Besides the obvious SMTP traffic this also generates a lot of DNS
> traffic. At this point the DNS traffic seems to be more of a nuisance
> probably because so many target hosts are retrying. At one point we
> were doing around 10K pkts/second in DNS traffic, very unusual.
>
> This has been going on for about a week.

At least some broken resolvers will keep re-querying you so see if you
cant throttle or rate limit dns queries from problem IPs for a while. 
That, and increase TTLs a bit.

As for the smtp -

* Dont accept email for catchall aliases - try to reject all you can
at the gateway

* Bounces and backscatter - RFC violation or not, accepting bounces
takes a backseat to keeping your mail system up and running.
TEMPORARILY turn off accepting mail from:<>, especially if you're
seeing far, far more bounce traffic to nonexistent addresses on your
site than valid bounces.

Long term - see if you can't use http://www.mipassoc.org/batv/
especially if all your users send email through your smtp server from
outside (say using AUTH) or ssh in and use pine / elm or whatever on
your shell servers.

>
> So where does one start. It seems a mother ship needs to be shut down
> somewhere, etc. Obviously ID'ing a miscreant would be a nice result.
>

You sure its just one botnet hitting you?  Shutting off a mothership
often means that the zombies become even more zombied and keep
pounding on your server long after the mothership is dead.

--srs

--
Suresh Ramasubramanian ([EMAIL PROTECTED])