Re: [policy] When Tech Meets Policy...

2007-08-13 Thread John C. A. Bambenek

That's exactly the problem the goal of tasting is to collect pay
per click ad revenue...

Ten years ago the internet was for porn, now it's for
MLM/Affiliate/PPC scams.  As long as we put up with companies abusing
the Internet as long as they are making a buck, they'll keep doing it.
 The scams will change, but they'll still be scaming.

On 12 Aug 2007 13:41:17 -, John Levine [EMAIL PROTECTED] wrote:

  I'd like to but I don't know of a practical way to measure the
  impact of domain tasting on my services: how can I do 6 million
  whois lookups to analyse a day's logs to find what proportion of our
  email comes from tasty domains?

 Probably not much.  Domain tasting requires a registrar who is willing
 to handle millions of AGP refunds without charging the registrant,
 which effectively rules out anyone who isn't a registrar himself.  The
 goal of tasting is to collect pay per click ad revenue, which requires
 that one have a stable enough identity to have Adsense et al pay you.
 Spam these days all comes from zombies with real but irrelevant return
 addresses, and the target URLs are more likely to be bought with
 stolen credit cards.

 The problems with domain tasting more affect web users, with vast
 number of typosquat parking pages flickering in and out of existence.

 The real way to get rid of tasting would be to persuade Google and
 Yahoo/Overture to stop paying for clicks on pages with no content
 other than ads, but that would be far too reasonable.

 R's,
 John




Re: Why do we use facilities with EPO's?

2007-07-25 Thread John C. A. Bambenek


Funny story about that and the EPO we have here...

We have chilled water cooling in our server rooms.  A couple of years
ago we told the facilities guys there was sand in the lines.  They
didn't believe us.  This went back and forth for a few months until
the lines finally ground to a halt.  They admitted sand was in the
lines.

The bring out an HVAC guy... he closes the valve, opens the pipe,
nothing comes out.  He **opens** the valve, nothing comes out.  He
whacks on the pipes with a wrench, all the sand and lots of water come
out very fast.  By the time I got down there, the ceiling tiles were
drenched and looked more like sponges.  Half the room was soaked.

That would be a good reason to have an EPO right there. :)

j

On 7/25/07, Leo Bicknell [EMAIL PROTECTED] wrote:


I was complaining to some of the power designers during the building
of a major facility that the EPO button represented a single point
of failure, and effectively made all of the redundancy built into
the power system useless.  After all, what's the point of having
two (or more) of anything, if there's one button somewhere that
turns it all off?

What I found interesting is that a single EPO is not a hard and
fast rule.  They walked me through a twisty maze of the national
electric code, the national fire code, and local regulations.
Through that journey, they left me with a rather interesting tidbit.

The more urban an area the more likely it is to have strict fire
codes.  Typically these codes require a single EPO for the entire
structure, there's no way to compartmentalize to rooms or subsystems.
However in more rural areas this is often not so, and they had in
fact built data centers to code WITHOUT a single building EPO in
several locations.  That's to say there was no EPO, but that it may
only affect a single room, or even a single device.

If they can be avoided, why do we put up with them?  Do we really
want our colo in downtown San Francisco bad enough to take the risk
of having a single point of failure?  How can we, as engineers, ask
questions about how many generators, how much fuel, and yet take
for granted that there is one button on the wall that makes it all
turn off?  Is it simply that having colo in the middle of the city
is so convenient that it overrides the increased cost and the reduced
redundancy that are necessitated by that location?

--
   Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org





--
/* [EMAIL PROTECTED] is an alias for all ISC handlers.
   Please include the list in all replies to keep everyone informed.
   You may receive more than one response */

Thanks,
j


Re: DNS Hijacking by Cox

2007-07-22 Thread John C. A. Bambenek


Is there any indication that they've done anything other than make
themselves authoritative for those DNS names and simply sent you to
their IRC server instead?  If so, what they have done is pretty much
legal (mostly because I'm quite sure there is something in their ToS
which you implicitly accepted which allows them to do this).  Under
net neutrality, it might be a different story.

Let's be honest, it's a band-aid lowtech fix for lowtech script
kiddies who right code like a bunch of apes with keyboards.  However,
for anyone with a remote amount of clue, they could get around this
problem in approximately 1.6 seconds with their malware.

But to get straight to the point, Cox sucks, always has.  Maybe it's
time for a real ISP?

j

On 7/22/07, Steven M. Bellovin [EMAIL PROTECTED] wrote:


On Sun, 22 Jul 2007 21:40:05 -0400
Patrick W. Gilmore [EMAIL PROTECTED] wrote:


 On Jul 22, 2007, at 9:29 PM, Steven M. Bellovin wrote:
  On Sun, 22 Jul 2007 14:56:13 -0700
  Andrew Matthews [EMAIL PROTECTED] wrote:
 
  It looks like cox is hijacking dns for irc servers.
 
  And people wonder why I support DNSsec

 Steve,

 One of us is confused.  It might be me, but right now I think it's
 you.

 To be clear, here is the situation as I understand it: Cox has
 configured their recursive name servers such that when an end user
 queries the recursive server for a specific host name (names?), the
 recursive server responds with an IP address the host's owner did not
 configure.

 How exactly is DNSSEC going to stop them from doing this?

If my host expects the response to be signed and it isn't, my host can
scream bloody murder.  The whole point of DNSSEC is to prevent random
changes to DNS replies, whether by hackers or by ISPs.

Yes, they can change it, but they can't change it without being caught.


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




--
/* [EMAIL PROTECTED] is an alias for all ISC handlers.
   Please include the list in all replies to keep everyone informed.
   You may receive more than one response */

Thanks,
j


Re: Boing Boing: Michael Lynn's controversial Cisco security presentat ion

2005-07-29 Thread John C. A. Bambenek

Remind me why I bother with information security when industry and the
government seems to want to ensure things can be pwn3d as easily as
possible...

On 7/29/05, Fergie (Paul Ferguson) [EMAIL PROTECTED] wrote:
 
 
 Now the FBI is investigating Lynn for criminal wrongdoing?
 
 Kim Zetter writes in Wired News this morning that:
 
 [snip]
 
 The FBI is investigating a computer security researcher for criminal conduct 
 after he revealed that critical systems supporting the internet and many 
 networks have a serious software flaw that could allow someone to crash or 
 take control of the routers.
 
 [and]
 
 The FBI declined to discuss the case.
 
 [snip]
 
 http://www.wired.com/news/politics/0,1283,68356,00.html
 
 - ferg
 
 
 
 
 
  Over on Boing Boing:
 
  [snip]
 
  Here's a PDF that purports to be Michael Lynn's presentation
  on Cisco's critical vulnerabilities (The Holy Grail: Cisco
  IOS Shellcode And Exploitation Techniques), delivered at
  last week's Black Hat conference. Lynn's employer, ISS,
  wouldn't let him deliver the talk (they'd been leant on by
  Cisco), so Lynn quit his job, walked onstage and delivered it
  anyway. (See yesterday's post and Scheneier's take for more).
  1.9MB PDF Link
 
  [snip]
 
  http://www.boingboing.net/2005/07/29/michael_lynns_contro.html
 
 
 


Thanks,
j