Re: Tightened DNS security question re: DNS amplification attacks.

[Mark Andrews]

In message <20090128232123.ga66...@redoubt.spodhuis.org>, Phil Pennock writes:
> Sorry to follow up to myself; a few more moments reviewing before
> sending were warranted.
> 
> On 2009-01-28 at 15:11 -0800, Phil Pennock wrote:
> > I'd be perfectly happy to have X list every root server, gTLD server and
> > ccTLD server, as a starting point, on the basis that none of those
> > should ever be sending out RD queries,
> 
> Before I get grilled on this point: it's not strictly true, since
> obviously things like looking up the IPs of secondary servers to send
> NOTIFY requests to may use recursive DNS.

Only if you have configured a forwarder.  Nameserver make non-
recursive queries by default.

> Okay, unless you're running
> a nameserver which secondaries from the gTLD/ccTLD/root servers, you
> have no reason to see RD packets from those servers.  Hopefully that's
> accurate enough to appease people who'll otherwise concentrate on that
> point and lose sight of what I was trying to show -- that *most* people
> could easily make use of such an RBL, if the nameservers supported using
> an external file for ignoring RD queries without dropping all traffic.
> 
> As people upgrade Bind naturally, the number of reflectors that could
> participate in an attack would go down.  Get the OS vendors to use
> default configs which set a Bind option to maintain the file
> automatically and you're getting most of the way there, by sheer number
> of DNS servers.
> 
> -Phil

The most common reason for recursive queries to a authoritative
server is someone using dig, nslookup or similar and forgeting
to disable recursion on the request.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org

Re: Tightened DNS security question re: DNS amplification attacks.

[Mark Andrews]

The bad guys want amplification but will take obscuring
if that's all they can get.

RD=1 is only the signature of the current attack.

RD=0 is equally viable.

Can you cope with "RD=0 NS ." directed to the root servers
from forged addresses?  This is exactly the query name
servers use to prime their caches with.

Stop trying to figure out how to stop the attack of the day
as it really is a waste of time and start trying to figure
out how to get near universal BCP 38 deployment.

Let the world know you are a good you if are deploying BCP
38.

Put up on your front web page what percentage of address
space / links are convered by BCP 38 compliance, where
compliance is defined as "traffic sourced from a arbitary
address will not be passed".  This should be auditable.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org

Re: Tightened DNS security question re: DNS amplification attacks.

[Douglas C. Stephens]

At 09:21 PM 1/27/2009, Paul Vixie wrote:

"Douglas C. Stephens"  writes:

> ...
> I choose the latter, and that is why went to the effort of blocking this
> abusive traffic before it reaches my authoritative-only DNS servers.

this is an odd implementation choice.  the 1PPS query stream is still using
your line even with this defense in place.  the 1PPS response stream and the
CPU cycles it takes to generate that stream isn't a burden on you (compared
to the 1PPS query stream that you can't stop anyway).  so the only reason to
block these appears to be so that you don't participate in the attack, or in
other words to cut down the burden on the victim.  with me so far?

the burden on the victim isn't going to drop materially by what you did since
hundreds of thousands of other servers are not going to block it.  but if the
victim is a recursive nameserver, then your blocking them will mean that they
cannot access the zones you're authoritative for.  so, no positive, but some
negative, for the only person in the whole equation who can be affected by
the blocking you're doing.

i don't get it.  with a cost:benefit matrix like that one, why is anybody
blocking this traffic?  (i note with some alarm that ten years after i shot
it down, i still get queries to rbl.maps.vix.com, so the possibility that the
blocks some folks might put in place to ...manage?... this attack will have a
long term bad effect on our heirs and assigns.  i know your perl script will
expire things 60 seconds after they stop spewing, but i fear that others are
blocking these in hardcode.

(looking for ". IN NS" as the q-tuple pattern is not a solution, since the
bad guys can pretty trivially change the question they ask into one you're
willing to answer.)

(REFUSED is nice because it's small, but the bad guys aren't lacking for bots
to transmit spoofed packets from, they Do Not Need amplification, and all
forms of error rate limiting are also new attack vectors.)

(is there a name-and-shame registry for networks that do/don't implement
BCP38? if not i guess i'll start one and hope that various auditors will use
google and notice me.)
--
Paul Vixie



Paul,

Arrrg.  I checked and you're right about the ACL blocking potentially
legitimate queries from the victim's IP address of authoritative
zones served from my authoritative-only DNS servers.  This is an issue
if the victim is running a recursive DNS server at that IP address.
However, is this really an issue if the victim is running a non-
recursive DNS server or another kind of server at that IP address?  In
the latter case, I think not.  In the former case, maybe, if it is an
authoritative-only DNS server that doesn't call its own system stub
resolver, or if it is a forwarding DNS server configured to query my
authoritative-only servers (though goodness knows why someone would
want to do that).  Obviously my code did not vet the detected IP
address for these cases, and I don't see any way to do so.

The 1 pps query stream is not a burden to my line, nor to my servers.
My goal was to make it more difficult for these perpetrators to relay
this garbage off my authoritative-only servers, and thus reduce the
abusive traffic being reflected towards their target(s).  As you said,
the "bad guys" aren't lacking for bots, and they don't need, nor seem
interested in, amplification.  I hadn't noticed BIND having any handles
to turn for this.  Maybe I'll work on that, or just rebuild my kernels
to include the u32 IPtables module.

As for why to block near the reflector?  Given the cost/benefit you
pointed out, and using my tool or other simpler ACLs, you're right, it
doesn't make sense.  However, using proper DPI tools (which obviously
my tool was not), why shouldn't those who are able to block near the
reflector?  A variation on the IPtables u32 rule I saw posted
elsewhere, or a handle to turn in BIND, based on signatures of known
abusive query patterns would accomplish for DNS attack vector what
anti-virus has been doing for decades for workstation and server
systems, would it not?  (Yes, yes, I know, signature-based tech is
bloated and dying, and behavioral tech is the wave of the future,
but right now signatures are all there is for this attack vector.)

To address another critique of the posting of my tool, evolution of
this form of attack is inevitable.  For example, several people have
suggested that the next variation will be to change the query data
from asking for a root referral to asking for some other zone for
which my authoritative-only servers are not authoritative.  I'm not so
sure, though, about the "bad guys" changing their query into something
my authoritative-only servers should answer and not REFUSE.  I think
changing to querying for a zone my servers are authoritative for would
come after simple permutations of their initial static query signature.
Though it may be a recent innovation to use a botnet to carry out these
attacks, the vector itself is not new, and they started with

Re: Tightened DNS security question re: DNS amplification attacks.

[William Allen Simpson]

Paul Vixie wrote:

have been able to bind a reputation to an IP address and act in some way based
on that reputation because TCP more or less requires that a real IP address
be used.  we're seeing cracks at the edges of this model now, because so many
core routers have login: cisco; password: cisco, and it's now trivial for any
spammer to inject BGP that either lights up unallocated space or cuts out a
piece of somebody else's allocated block.  this makes it possible to very
temporarily and untraceably speak TCP from addresses that have no reputation
(if they're unallocated) or that have a good reputation (if they're cutouts).
...
i've pondered whether a network reputation service based on morality rather
than behaviour could possibly work.
...  would anyone be willing to deny service to them -- to paint
them as having a negative reputation even though their "sin" is laziness or
cluelessness rather than malevolent intent?
...

Yes, I've long been an advocate.  Heck, the entire community had to take this
approach temporarily to slow/stop 2 worms (so far), because the damage was so
great that we couldn't operate otherwise.

However, I'd argue semantically that this is "behaviour" as well -- under a
negligence or attractive nuisance doctrine.

My previous solution involved extensive AUPs, but over time I've found AUPs
to be almost entirely unenforcible.  Action turns out to be very expensive,
courts don't understand them, and are reluctant to support the "outsider"
ISP over their small business that belongs to the local chamber.

I was pleased by community action for de-peering this last year, although it
took several years of mounting evidence and national media exposure.

Do we need a law?

Re: Tightened DNS security question re: DNS amplification attacks.

[Phil Pennock]

Sorry to follow up to myself; a few more moments reviewing before
sending were warranted.

On 2009-01-28 at 15:11 -0800, Phil Pennock wrote:
> I'd be perfectly happy to have X list every root server, gTLD server and
> ccTLD server, as a starting point, on the basis that none of those
> should ever be sending out RD queries,

Before I get grilled on this point: it's not strictly true, since
obviously things like looking up the IPs of secondary servers to send
NOTIFY requests to may use recursive DNS.  Okay, unless you're running
a nameserver which secondaries from the gTLD/ccTLD/root servers, you
have no reason to see RD packets from those servers.  Hopefully that's
accurate enough to appease people who'll otherwise concentrate on that
point and lose sight of what I was trying to show -- that *most* people
could easily make use of such an RBL, if the nameservers supported using
an external file for ignoring RD queries without dropping all traffic.

As people upgrade Bind naturally, the number of reflectors that could
participate in an attack would go down.  Get the OS vendors to use
default configs which set a Bind option to maintain the file
automatically and you're getting most of the way there, by sheer number
of DNS servers.

-Phil

Re: Tightened DNS security question re: DNS amplification attacks.

[Phil Pennock]

On 2009-01-28 at 19:30 +, Paul Vixie wrote:
> DNS-oriented attacks are of a completely different kind.  today's attacks were
> precisely described in 
> 
> (which wasn't news in october 2002 but somebody had to write it down so i 
> did).
> the important statement out of that 4-page document is: "Source addresses that
> appear at Border or Interior connections are nonrepudiable by nature..." and
> that statement bears on the question of RBL for DNS-oriented DDoS attacks 
> since
> the address we'd have to assign a reputation to is the victim, so all we can
> do is make an attack worse (by denying service to the victim's real traffic.)

I'd be willing to drop DNS queries, without even sending back a REFUSED
response, if they come in with RD set from an IP in a list X, where X
might be an RBL.

I'd be perfectly happy to have X list every root server, gTLD server and
ccTLD server, as a starting point, on the basis that none of those
should ever be sending out RD queries, so refusing to reply to those
addresses should have no impact.  Perhaps if operators start to do this,
anyone still running critical infrastructure authoritative DNS servers
which perform recursive queries would finally split roles.

Smaller outfits might get away with an auth server which does recursion
too, for a finite set of IPs (eg, "localhost"), if they have issues
obtaining IP addresses.  Anyone providing nameservers for gTLD or ccTLD
zones should not have this problem.  (My personal nameserver is in the
smaller outfit category here).

Now, implementing the RBL against only recursive queries is a separate
issue; without nameserver support, you're obviously down to packet
filtering.  bind supports complete blackholes, but not RD blackholes,
AFAIK, but you'd be in a better position than me to say what's coming in
bind.  iptables can apparently perform payload inspection, but pf
definitely can't (at this time).  By this, I mean filtering on
   udp[10] & 0xf9 = 1
[1]

Regards,
-Phil

[1] That's from the tcpdump rule I'm using to glance at this traffic;
  intf=ifname0# wire ethernet device
  ipv4=192.0.2.1  # local IP
  tcpdump -vvvnpi $intf -Xs 1500 "(
(dst host $ipv4 and dst port 53 and (udp[10] & 0xf9 = 1))
or
(src host $ipv4 and src port 53 and (udp[10:2] & 0xfc80 = 0x8000))
)"
Queries: QR=0, Opcode=0, RD=1
Responses: QR=1, Opcode=0, AA=0

And all assuming that we're only worried about UDP queries, since a
TCP query implies the three-way handshake and if that's susceptible
to spoofing then there are routing issues too.

RE: -48VDC equipment recommendations

[Frank Bulk]

We're using this a product by C&D and happy with it:
http://www.cdstandbypower.com/product/power_sys/system/sageon.html
Runs very quietly, very efficient (compared to what we used to have)

For our smaller sites, we use Valere:
http://www.eltekvalere.com/wip4/telecom/c/detail.epl?cat=11071
It's amazing how compact they've made these units.

Frank

-Original Message-
From: Deepak Jain [mailto:dee...@ai.net] 
Sent: Tuesday, January 27, 2009 5:35 PM
To: nanog list
Subject: -48VDC equipment recommendations


Who does everyone like for -48VDC power systems nowadays (say in the 60A
@48VDC and 6...@48vdc sizes). Something like you'd deploy in a POP or a
10-rack MMR with A&B.

Management/no-management, not a big deal.

Off-list is fine, and I'll be glad to summarize for the list.

Thanks in advance,

Deepak

Re: cogent issues?

[John Martinez]

Ryan Werber wrote:
> That ticket was opened yesterday, and we have been hit very hard with
> it.  This problem started on Monday night - I don't know what they did,
> but we lost all of our Toronto sites in the middle of the night for a
> good bit - so I assume maintenance - Then all h*ll broke loose over the
> last couple days.  
> 
>> https://puck.nether.net/pipermail/outages/2009-January/001101.html
> 
> -wil
> 
> On Jan 28, 2009, at 12:27 PM, John Martinez wrote:
> 
>> http://www.internetpulse.net/
>>
> 
> Ryan Werber
> Sr. Network Engineer
> Epik Networks
> 
> 
Seems like that packet loss is decreasing.

Re: cogent issues?

[John Martinez]

Ryan Werber wrote:
> That ticket was opened yesterday, and we have been hit very hard with
> it.  This problem started on Monday night - I don't know what they did,
> but we lost all of our Toronto sites in the middle of the night for a
> good bit - so I assume maintenance - Then all h*ll broke loose over the
> last couple days.  
> 
>> https://puck.nether.net/pipermail/outages/2009-January/001101.html
> 
> -wil
> 
> On Jan 28, 2009, at 12:27 PM, John Martinez wrote:
> 
>> http://www.internetpulse.net/
>>
> 
> Ryan Werber
> Sr. Network Engineer
> Epik Networks
> 


We saw the issue starting to show up in our monitors at 8:55 EST.

RE: cogent issues?

[Ryan Werber]

That ticket was opened yesterday, and we have been hit very hard with
it.  This problem started on Monday night - I don't know what they did,
but we lost all of our Toronto sites in the middle of the night for a
good bit - so I assume maintenance - Then all h*ll broke loose over the
last couple days.  

>https://puck.nether.net/pipermail/outages/2009-January/001101.html

-wil

On Jan 28, 2009, at 12:27 PM, John Martinez wrote:

> http://www.internetpulse.net/
>

Ryan Werber
Sr. Network Engineer
Epik Networks

Re: Tightened DNS security question re: DNS amplification attacks.

[Leen Besselink]

> - Original Message -
> From: "aljuhani" 
> Subject: Re: Tightened DNS security  question re: DNS amplification
> attacks.
> To: "nanog" 
>
> Well the RBLs, in using dns queries, is another form of legal DDoS attacks, 
> mainly when the
> suddenly cease to respond or re-configure to black-list the entire wold.   
> One should just
> imagine the bandwidth consumption during a
> +given time-frame, RBLs consume as oppose to volume of spam messages.
>

If you folks are really serious about this, can I suggest using BGP for this ? 
Maybe a
multi-hop BGP-session like Team Cymru already has for bogons [0]. With 
different communities
for different types of traffic that should be dropped.

That way you, the network operator, could choose what you what to drop and how.

They are already a pretty trusted party if people actually use these 
bogon-sessions.

Might it actually be a structural solution ? Atleast if I didn't forget 
something important.

[0] http://www.team-cymru.org/Services/Bogons/routeserver.html

> - Original Message -
> From: "Frank Bulk" 
> To: "'Paul Vixie'" ; 
> Sent: Wednesday, January 28, 2009 18:02
> Subject: RE: Tightened DNS security question re: DNS amplification attacks.
>
>
> | Pretty soon we need an RBL for DNS-oriented DDoS attacks. =)
> |

Re: cogent issues?

[John Martinez]

Wil Schultz wrote:
> https://puck.nether.net/pipermail/outages/2009-January/001101.html
> 
> -wil
> 
> On Jan 28, 2009, at 12:27 PM, John Martinez wrote:
> 
>> http://www.internetpulse.net/
>>
> 

Thank you all.

Re: cogent issues?

[Wil Schultz]

https://puck.nether.net/pipermail/outages/2009-January/001101.html

-wil

On Jan 28, 2009, at 12:27 PM, John Martinez wrote:


http://www.internetpulse.net/

Re: cogent issues?

[Ray Sanders]

>From the outages list:

Cogent is currently experiencing problems on their backbone in Chicago,
manifesting as packet loss and latency. The master ticket # is 853582.


On Wed, 2009-01-28 at 12:27 -0800, John Martinez wrote:
> http://www.internetpulse.net/
> 
-- 
"Prediction is very difficult, especially about the future." Niels Bohr
--
Ray Sanders
Linux Administrator
Village Voice Media
Office: 602-744-6547
Cell: 602-300-4344

Re: cogent issues?

[Brandon Galbraith]

On 1/28/09, John Martinez  wrote:
>
> http://www.internetpulse.net/
>
>
Sent to "outages" a bit ago:

Cogent is currently experiencing problems on their backbone in Chicago,
manifesting as packet loss and latency. The master ticket # is 853582.

-brandon




-- 
Brandon Galbraith
Voice: 630.400.6992
Email: brandon.galbra...@gmail.com

cogent issues?

[John Martinez]

http://www.internetpulse.net/

Re: Tightened DNS security question re: DNS amplification attacks.

[Jack Bates]

Paul Vixie wrote:


note, i'm speaking as a concerned internet citizen here, not as an ARIN
trustee or as ISC's president.  i really want to know if folks would be
willing to shun eachother not on the basis of evil but rather complacency.



The real question is, would the endpoints be willing to shun each other 
not based on the other endpoint, but complacency of the endpoint's 
provider. I believe such traffic changes would quickly find themselves 
to "net-neutrality" lawsuits.


From things I've seen in the past, it is appropriate to say "my server, 
my rules" but not appropriate to say "my network, my rules". ie, if I 
wanted to shape/block/alter p2p, block vontage, etc.



Jack

Re: DNS DDoS

[Wil Schultz]

If anyone is interested, here's what things look like from here for  
the past 3 days.


dns2:~ wschultz$ gzcat /var/log/named.log.01262009.gz |awk '/\.\/NS\/ 
IN.*denied/{print $6}' |sed -e 's/#.*//g' |sort |uniq -c |sort -n

  6 150.69.136.10
1387 76.9.16.171
2759 63.217.28.226
98680 206.71.158.30

dns2:~ wschultz$ gzcat /var/log/named.log.01272009.gz |awk '/\.\/NS\/ 
IN.*denied/{print $6}' |sed -e 's/#.*//g' |sort |uniq -c |sort -n

  6 150.69.136.10
1387 76.9.16.171
2753 63.217.28.226
5521 206.71.158.30

dns2:~ wschultz$ cat /var/log/named.log |awk '/\.\/NS\/IN.*denied/ 
{print $6}' |sed -e 's/#.*//g' |sort |uniq -c |sort -n

  2 150.69.136.10
279 67.192.144.0
296 76.9.16.171
6519 64.57.246.123
17207 64.57.246.146
20646 70.86.80.98

-wil

On Jan 28, 2009, at 8:07 AM, Andrew Fried wrote:


Targeted victims, beginning 28-Jan-2009, as seen from my DNS server.
GeoIP data for top two sites also below:

++-++
| host   | count(host) | Percentage |
++-++
| 202.104.106.49 |  51 | 0.1109 |
| 210.21.218.138 |  51 | 0.1109 |
| 64.57.246.123  |3561 | 7.7421 |
| 64.57.246.146  |   29530 |64.2026 |
| 67.192.144.0   | 991 | 2.1546 |
| 70.86.80.98|   11276 |24.5157 |
| 76.9.16.171| 535 | 1.1632 |
++-++

GeoIP Location Information for IP: 64.57.246.146
   Located in: Suwanee, GA (US)
   Latitude: 34.0535
   Longitude: -84.0659
   Area Code: 770
   Postal Code: 30024

ARIN information for: 64.57.246.146
   DNS PTR Record:
   Registrar: arin
   ASN Number:AS20141
   Country:   US
   Ip Starting Block: 64.57.240.0
   IP Ending Block:   64.57.255.255
   IP Block Size: 4096
   Date Registered:   20051012
   Block Status:  allocated

BGP Peering Information for ASN20141:

PEER_AS | IP   | BGP Prefix  | CC | Registry |
Allocated  | AS Name
6983| 64.57.246.146| 64.57.240.0/20  | US | arin |
2005-10-12 | ITCDELTA - ITC^Deltacom
14745   | 64.57.246.146| 64.57.240.0/20  | US | arin |
2005-10-12 | INTERNAP-BLOCK-4 - Internap Network Services Corporation




GeoIP Location Information for IP: 70.86.80.98
   Located in: Houston, TX (US)
   Latitude: 29.7523
   Longitude: -95.3670
   Area Code: 713
   Postal Code: 77002

ARIN information for: 70.86.80.98
   DNS PTR Record:62.50.5646.static.theplanet.com.
   Registrar: arin
   ASN Number:AS21844
   Country:   US
   Ip Starting Block: 70.84.0.0
   IP Ending Block:   70.87.255.255
   IP Block Size: 262144
   Date Registered:   20040729
   Block Status:  allocated

BGP Peering Information for ASN21844:

PEER_AS | IP   | BGP Prefix  | CC | Registry |
Allocated  | AS Name
2914| 70.86.80.98  | 70.84.0.0/14| US | arin |
2004-07-29 | NTT-COMMUNICATIONS-2914 - NTT America, Inc.
3356| 70.86.80.98  | 70.84.0.0/14| US | arin |
2004-07-29 | LEVEL3 Level 3 Communications
3549| 70.86.80.98  | 70.84.0.0/14| US | arin |
2004-07-29 | GBLX Global Crossing Ltd.
4565| 70.86.80.98  | 70.84.0.0/14| US | arin |
2004-07-29 | MEGAPATH2-US - MegaPath Networks Inc.
6461| 70.86.80.98  | 70.84.0.0/14| US | arin |
2004-07-29 | MFNX MFN - Metromedia Fiber Network

--
Andrew Fried
andrew.fr...@gmail.com

Re: Tightened DNS security question re: DNS amplification attacks.

[Paul Vixie]

> Pretty soon we need an RBL for DNS-oriented DDoS attacks. =)

in the classic sense, you're wrong.  in a neoclassic sense: "maybe".  let me
explain.  the original RBL was designed to reject TCP/25 (SMTP) transactions
based on source address reputation.  we had a false start where we blackholed
these addresses as destinations, figuring that if they couldn't hear our ACK
then we would never get into TCP with them.  then we decided to reject inside
the SMTP server and that's what the world has settled on.  but throughout, we
have been able to bind a reputation to an IP address and act in some way based
on that reputation because TCP more or less requires that a real IP address
be used.  we're seeing cracks at the edges of this model now, because so many
core routers have login: cisco; password: cisco, and it's now trivial for any
spammer to inject BGP that either lights up unallocated space or cuts out a
piece of somebody else's allocated block.  this makes it possible to very
temporarily and untraceably speak TCP from addresses that have no reputation
(if they're unallocated) or that have a good reputation (if they're cutouts).

DNS-oriented attacks are of a completely different kind.  today's attacks were
precisely described in 
(which wasn't news in october 2002 but somebody had to write it down so i did).
the important statement out of that 4-page document is: "Source addresses that
appear at Border or Interior connections are nonrepudiable by nature..." and
that statement bears on the question of RBL for DNS-oriented DDoS attacks since
the address we'd have to assign a reputation to is the victim, so all we can
do is make an attack worse (by denying service to the victim's real traffic.)

i've pondered whether a network reputation service based on morality rather
than behaviour could possibly work.  in other words an RBL-like entity that
did not prevent attacks, but rather, which denied service to collaborators.
if someone claims they can't deploy BCP38 and if their network or nameserver
is then used as a launch point for spoofed packets toward reflectors and
amplifiers, then would anyone be willing to deny service to them -- to paint
them as having a negative reputation even though their "sin" is laziness or
cluelessness rather than malevolent intent?  and if someone claims they can't
turn off open recursion and they get used as an amplifier, would anyone here
be willing to deny that recursive server access to their authority server, not
on the basis that it might attack them, but strictly to pressure an upgrade?

note, i'm speaking as a concerned internet citizen here, not as an ARIN
trustee or as ISC's president.  i really want to know if folks would be
willing to shun eachother not on the basis of evil but rather complacency.

Re: google logo

[Michael Holstein]

Anyone else noticing Google's logo has been scrambled?


Did you notice what happens when you mouse-over it (same thing that 
happens anytime they do a "doodle", btw).

http://www.google.com/search?q=Jackson+Pollock&hl=en&ct=pollock09&oi=ddle

http://en.wikipedia.org/wiki/Google_logo

Re: google logo

[Suresh Ramasubramanian]

On Wed, Jan 28, 2009 at 10:38 PM, J. Oquendo  wrote:
> On Wed, 28 Jan 2009, Dozens of Overpaid Engineers wrote:
>
>> That's a Jackson Pollock.
>>
>
> Question should be - How does this affect route patterns,
> traffic, policies, etc.?

Suspected global case of bitrot leading to the logo being scrambled, maybe? :)

Re: google logo

[Leigh Porter]

"the site" is an interesting phrase to use with Google.

What is the google site anyway? Does it exist in any one place in
space-time?

--
Leigh



Antonio Querubin wrote:
> On Wed, 28 Jan 2009, Peter A. Friend wrote:
>
>> Look closely. It's Jackson Pollock's birthday.
>
> Heh.  My first thought was the site might have been hacked.  The logo
> looks cool though.  Thanks for the reply :)
>
> Antonio Querubin
> whois:  AQ7-ARIN

Re: google logo

[Antonio Querubin]

On Wed, 28 Jan 2009, Peter A. Friend wrote:


Look closely. It's Jackson Pollock's birthday.


Heh.  My first thought was the site might have been hacked.  The logo 
looks cool though.  Thanks for the reply :)


Antonio Querubin
whois:  AQ7-ARIN

Re: google logo

[J. Oquendo]

On Wed, 28 Jan 2009, Dozens of Overpaid Engineers wrote:

> That's a Jackson Pollock.
> 

Question should be - How does this affect route patterns,
traffic, policies, etc.? 


=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
J. Oquendo
SGFA, SGFE, C|EH, CNDA, CHFI, OSCP

"Enough research will tend to support your
conclusions." - Arthur Bloch

"A conclusion is the place where you got
tired of thinking" - Arthur Bloch

227C 5D35 7DCB 0893 95AA  4771 1DCE 1FD1 5CCD 6B5E
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E

RE: google logo

[Bailey Stephen]

That will be because of Jackon Pollock's Birthday

http://www.jacksonpollock.org/

Stephen Bailey - Senior Lead Systems Engineer
Network Operations - ISP & DSL
 
FUJITSU
+ Infinity House, Mallard Way, Crewe Business Park, Crewe, Cheshire, CW1
6ZQ 
( Tel: +44 (0) 870 325 3457  or Internally: 7225 3457
( Fax: +44 (0) 870 325 3622  or Internally: 7225 3622
: E-mail: stephen.bai...@uk.fujitsu.com 
" Web: http://services.fujitsu.com/ 
 

Fujitsu Services Limited, Registered in England no 96056, Registered
Office 22 Baker Street, London, W1U 3BW
 
This e-mail is only for the use of its intended recipient.  Its contents
are subject to a duty of confidence and may be privileged.  Fujitsu
Services does not guarantee that this e-mail has not been intercepted
and amended or that it is virus-free.

_
From: Tim Nowaczyk [mailto:ta...@virginia.edu] 
Sent: 28 January 2009 16:48
To: Antonio Querubin; na...@merit.edu
Subject: Re: google logo

* PGP Bad Signature, Signed by an unverified key: 01/28/09 at 16:47:45



On 1/28/09 11:45 AM, "Antonio Querubin"  wrote:

> Anyone else noticing Google's logo has been scrambled?
>
It was done in honor of Jackson Pollock's birthday.

Cheers,
Tim Nowaczyk

-- 
Timothy Nowaczyk
Network Systems Engineer
University of Virginia - ITC
ta...@virginia.edu


* Timothy Allen Nowaczyk 70 
* Issuer: University of Virginia - Unverified

Re: google logo

[Peter A. Friend]

On Jan 28, 2009, at 8:45 AM, Antonio Querubin wrote:


Anyone else noticing Google's logo has been scrambled?

Antonio Querubin
whois:  AQ7-ARIN



Look closely. It's Jackson Pollock's birthday.

Re: google logo

[Zach]

That's one hell of a captcha..

On Wed, Jan 28, 2009 at 10:47 AM, Tim Nowaczyk  wrote:

>
>
> On 1/28/09 11:45 AM, "Antonio Querubin"  wrote:
>
> > Anyone else noticing Google's logo has been scrambled?
> >
> It was done in honor of Jackson Pollock's birthday.
>
> Cheers,
> Tim Nowaczyk
>
> --
> Timothy Nowaczyk
> Network Systems Engineer
> University of Virginia - ITC
> ta...@virginia.edu
>
>

Re: google logo

[Chris Grundemann]

On Wed, Jan 28, 2009 at 09:45, Antonio Querubin  wrote:
> Anyone else noticing Google's logo has been scrambled?

If you click on it you will see that it is a Jackson Pollack inspired
image, most likely a tribute to his birthday today.
~Chris

>
> Antonio Querubin
> whois:  AQ7-ARIN
>
>



-- 
Chris Grundemann
www.chrisgrundemann.com

Re: google logo

[Marshall Eubanks]

That's a Jackson Pollock.

Marshall

On Jan 28, 2009, at 11:45 AM, Antonio Querubin wrote:


Anyone else noticing Google's logo has been scrambled?

Antonio Querubin
whois:  AQ7-ARIN

RE: google logo

[Murphy, Jay, DOH]

Yea, it is Jackson Pollack's B-day art...


Jay Murphy 
IP Network Specialist 
NM Department of Health 
ITSD - IP Network Operations 
Santa Fe, New Mexico 87502 
Bus. Ph.: 505.827.2851

"We move the information that moves your world." 





-Original Message-
From: Antonio Querubin [mailto:t...@lava.net] 
Sent: Wednesday, January 28, 2009 9:46 AM
To: na...@merit.edu
Subject: google logo

Anyone else noticing Google's logo has been scrambled?

Antonio Querubin
whois:  AQ7-ARIN


__
This inbound email has been scanned by the MessageLabs Email Security
System.
__
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. If 
you have received this email in error please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail.

Re: google logo

[Shaun Bryant]

It is Jackson Pollock's birthday

http://en.wikipedia.org/wiki/Jackson_Pollock

Shaun

On Wed, Jan 28, 2009 at 8:45 AM, Antonio Querubin  wrote:
> Anyone else noticing Google's logo has been scrambled?
>
> Antonio Querubin
> whois:  AQ7-ARIN
>
>

Re: google logo

[Tim Nowaczyk]

On 1/28/09 11:45 AM, "Antonio Querubin"  wrote:

> Anyone else noticing Google's logo has been scrambled?
>
It was done in honor of Jackson Pollock's birthday.

Cheers,
Tim Nowaczyk

-- 
Timothy Nowaczyk
Network Systems Engineer
University of Virginia - ITC
ta...@virginia.edu



smime.p7s
Description: S/MIME cryptographic signature

RE: google logo

[Mark Kimble]

Jackson Pollock's Birthday -
http://en.wikipedia.org/wiki/Jackson_Pollock

-Original Message-
From: Antonio Querubin [mailto:t...@lava.net] 
Sent: Wednesday, January 28, 2009 11:46 AM
To: na...@merit.edu
Subject: google logo

Anyone else noticing Google's logo has been scrambled?

Antonio Querubin
whois:  AQ7-ARIN

google logo

[Antonio Querubin]

Anyone else noticing Google's logo has been scrambled?

Antonio Querubin
whois:  AQ7-ARIN

DNS DDoS

[Andrew Fried]

Targeted victims, beginning 28-Jan-2009, as seen from my DNS server. 
GeoIP data for top two sites also below:

++-++
| host   | count(host) | Percentage |
++-++
| 202.104.106.49 |  51 | 0.1109 |
| 210.21.218.138 |  51 | 0.1109 |
| 64.57.246.123  |3561 | 7.7421 |
| 64.57.246.146  |   29530 |64.2026 |
| 67.192.144.0   | 991 | 2.1546 |
| 70.86.80.98|   11276 |24.5157 |
| 76.9.16.171| 535 | 1.1632 |
++-++

GeoIP Location Information for IP: 64.57.246.146
Located in: Suwanee, GA (US)
Latitude: 34.0535
Longitude: -84.0659
Area Code: 770
Postal Code: 30024

ARIN information for: 64.57.246.146
DNS PTR Record:   
Registrar: arin
ASN Number:AS20141
Country:   US
Ip Starting Block: 64.57.240.0
IP Ending Block:   64.57.255.255
IP Block Size: 4096
Date Registered:   20051012
Block Status:  allocated

BGP Peering Information for ASN20141:

PEER_AS | IP   | BGP Prefix  | CC | Registry |
Allocated  | AS Name
6983| 64.57.246.146| 64.57.240.0/20  | US | arin |
2005-10-12 | ITCDELTA - ITC^Deltacom
14745   | 64.57.246.146| 64.57.240.0/20  | US | arin |
2005-10-12 | INTERNAP-BLOCK-4 - Internap Network Services Corporation




GeoIP Location Information for IP: 70.86.80.98
Located in: Houston, TX (US)
Latitude: 29.7523
Longitude: -95.3670
Area Code: 713
Postal Code: 77002

ARIN information for: 70.86.80.98
DNS PTR Record:62.50.5646.static.theplanet.com.
Registrar: arin
ASN Number:AS21844
Country:   US
Ip Starting Block: 70.84.0.0
IP Ending Block:   70.87.255.255
IP Block Size: 262144
Date Registered:   20040729
Block Status:  allocated

BGP Peering Information for ASN21844:

PEER_AS | IP   | BGP Prefix  | CC | Registry |
Allocated  | AS Name
2914| 70.86.80.98  | 70.84.0.0/14| US | arin |
2004-07-29 | NTT-COMMUNICATIONS-2914 - NTT America, Inc.
3356| 70.86.80.98  | 70.84.0.0/14| US | arin |
2004-07-29 | LEVEL3 Level 3 Communications
3549| 70.86.80.98  | 70.84.0.0/14| US | arin |
2004-07-29 | GBLX Global Crossing Ltd.
4565| 70.86.80.98  | 70.84.0.0/14| US | arin |
2004-07-29 | MEGAPATH2-US - MegaPath Networks Inc.
6461| 70.86.80.98  | 70.84.0.0/14| US | arin |
2004-07-29 | MFNX MFN - Metromedia Fiber Network

-- 
Andrew Fried
andrew.fr...@gmail.com

Re: Tightened DNS security question re: DNS amplification attacks.

[Suresh Ramasubramanian]

This, in a thread where paul vixie is posting .. and on a list where
there are several people who do run professional blocklists.

Well, I dare say there'll be some difference of opinion. Cant help that.

On Wed, Jan 28, 2009 at 8:48 PM, aljuhani  wrote:
>
> Well the RBLs, in using dns queries, is another form of legal DDoS attacks, 
> mainly when the suddenly cease to respond or re-configure to black-list the 
> entire wold.   One should just imagine the bandwidth consumption during a 
> given time-frame, RBLs consume as oppose to volume of spam messages.
>

Re: Tightened DNS security question re: DNS amplification attacks.

[aljuhani]

Well the RBLs, in using dns queries, is another form of legal DDoS attacks, 
mainly when the suddenly cease to respond or re-configure to black-list the 
entire wold.   One should just imagine the bandwidth consumption during a given 
time-frame, RBLs consume as oppose to volume of spam messages.

- Original Message - 
From: "Frank Bulk" 
To: "'Paul Vixie'" ; 
Sent: Wednesday, January 28, 2009 18:02
Subject: RE: Tightened DNS security question re: DNS amplification attacks.


| Pretty soon we need an RBL for DNS-oriented DDoS attacks. =)
| 
| -Original Message-
| From: Paul Vixie [mailto:vi...@isc.org] 
| Sent: Tuesday, January 27, 2009 9:21 PM
| To: na...@merit.edu
| Subject: Re: Tightened DNS security question re: DNS amplification attacks.
| 
| "Douglas C. Stephens"  writes:
| 
| > ...
| > I choose the latter, and that is why went to the effort of blocking this
| > abusive traffic before it reaches my authoritative-only DNS servers.
| 
| this is an odd implementation choice.  the 1PPS query stream is still using
| your line even with this defense in place.  the 1PPS response stream and the
| CPU cycles it takes to generate that stream isn't a burden on you (compared
| to the 1PPS query stream that you can't stop anyway).  so the only reason to
| block these appears to be so that you don't participate in the attack, or in
| other words to cut down the burden on the victim.  with me so far?
| 
| the burden on the victim isn't going to drop materially by what you did
| since
| hundreds of thousands of other servers are not going to block it.  but if
| the
| victim is a recursive nameserver, then your blocking them will mean that
| they
| cannot access the zones you're authoritative for.  so, no positive, but some
| negative, for the only person in the whole equation who can be affected by
| the blocking you're doing.
| 
| i don't get it.  with a cost:benefit matrix like that one, why is anybody
| blocking this traffic?  (i note with some alarm that ten years after i shot
| it down, i still get queries to rbl.maps.vix.com, so the possibility that
| the
| blocks some folks might put in place to ...manage?... this attack will have
| a
| long term bad effect on our heirs and assigns.  i know your perl script will
| expire things 60 seconds after they stop spewing, but i fear that others are
| blocking these in hardcode.
| 
| (looking for ". IN NS" as the q-tuple pattern is not a solution, since the
| bad guys can pretty trivially change the question they ask into one you're
| willing to answer.)
| 
| (REFUSED is nice because it's small, but the bad guys aren't lacking for
| bots
| to transmit spoofed packets from, they Do Not Need amplification, and all
| forms of error rate limiting are also new attack vectors.)
| 
| (is there a name-and-shame registry for networks that do/don't implement
| BCP38? if not i guess i'll start one and hope that various auditors will use
| google and notice me.)
| --
| Paul Vixie
| 
| 
| 
| 

RE: Tightened DNS security question re: DNS amplification attacks.

[Frank Bulk]

Pretty soon we need an RBL for DNS-oriented DDoS attacks. =)

-Original Message-
From: Paul Vixie [mailto:vi...@isc.org] 
Sent: Tuesday, January 27, 2009 9:21 PM
To: na...@merit.edu
Subject: Re: Tightened DNS security question re: DNS amplification attacks.

"Douglas C. Stephens"  writes:

> ...
> I choose the latter, and that is why went to the effort of blocking this
> abusive traffic before it reaches my authoritative-only DNS servers.

this is an odd implementation choice.  the 1PPS query stream is still using
your line even with this defense in place.  the 1PPS response stream and the
CPU cycles it takes to generate that stream isn't a burden on you (compared
to the 1PPS query stream that you can't stop anyway).  so the only reason to
block these appears to be so that you don't participate in the attack, or in
other words to cut down the burden on the victim.  with me so far?

the burden on the victim isn't going to drop materially by what you did
since
hundreds of thousands of other servers are not going to block it.  but if
the
victim is a recursive nameserver, then your blocking them will mean that
they
cannot access the zones you're authoritative for.  so, no positive, but some
negative, for the only person in the whole equation who can be affected by
the blocking you're doing.

i don't get it.  with a cost:benefit matrix like that one, why is anybody
blocking this traffic?  (i note with some alarm that ten years after i shot
it down, i still get queries to rbl.maps.vix.com, so the possibility that
the
blocks some folks might put in place to ...manage?... this attack will have
a
long term bad effect on our heirs and assigns.  i know your perl script will
expire things 60 seconds after they stop spewing, but i fear that others are
blocking these in hardcode.

(looking for ". IN NS" as the q-tuple pattern is not a solution, since the
bad guys can pretty trivially change the question they ask into one you're
willing to answer.)

(REFUSED is nice because it's small, but the bad guys aren't lacking for
bots
to transmit spoofed packets from, they Do Not Need amplification, and all
forms of error rate limiting are also new attack vectors.)

(is there a name-and-shame registry for networks that do/don't implement
BCP38? if not i guess i'll start one and hope that various auditors will use
google and notice me.)
--
Paul Vixie

Re: Tightened DNS security question re: DNS amplification attacks.

[Graeme Fowler]

Hi

On Wed, 2009-01-28 at 13:16 +0100, fredrik danerklint wrote:
> At 12:07:16 local time here in sweden, I saw a new address 70.86.80.98.
> At 12:09:36 another new address 64.57.246.123 
> At 12:20:10 the address 70.86.80.98 started to ask for funny domain name like:
> "pjphcdfwudgaaabaaacboinf". This ended at 12:55:01 when it was back 
> to 
> just ask for the .NS records again.

Same here - times different, though, in that it appeared at 1120 UTC and
disappeared at 1159 UTC. There were 194 entries.

Every query was the same format - a 32-byte lower case alphanumeric
string, differing at the following positions marked with a period:

..fw.d.aaabaaa..

I expect that others will have seen similar patterns with differing
fixed strings.  I'm also starting to wonder if this is something to with
the downadup/conficker worm, or another botnet.

Graeme

Re: Tightened DNS security question re: DNS amplification attacks.

[Charles Morris]

You all may wish to check your logs for 202.108.12.112, it could be a
new target; although I only saw two requests from it.


--
Charles Morris
   cmor...@cs.odu.edu,
   cmor...@occs.odu.edu

Network Security Administrator,
Software Developer

Office of Computing and Communications Services,
CS Systems Group  Old Dominion University
http://www.cs.odu.edu/~cmorris

Re: Tightened DNS security question re: DNS amplification attacks.

[fredrik danerklint]

At 12:07:16 local time here in sweden, I saw a new address 70.86.80.98.
At 12:09:36 another new address 64.57.246.123 
At 12:20:10 the address 70.86.80.98 started to ask for funny domain name like:
"pjphcdfwudgaaabaaacboinf". This ended at 12:55:01 when it was back to 
just ask for the .NS records again.

-- 
//Fredrik Danerklint
//Fredan