RE: Hackers hijack 300, 000-plus wireless routers, make malicious changes | Ars Technica

[Ian McDonald]

Until the average user's cpe is only permitted to use the resolvers one has 
provided as the provider (or otherwise decided are OK), this is going to be a 
game of whackamole. So long as there's an 'I have a clue' opt out, it appears 
to be the way forward to resolve this issue. Shutting down one set of 'bad 
resolvers' will simply cause a new set to be spawned, and a reinfection run 
round the still-unpatched cpe's of the world.

Thanks

--
ian

Sent from my phone, please excuse brevity and misspelling.

From: Octavio Alvarez
Sent: ‎04/‎03/‎2014 18:09
To: jim deleskie; Andrew 
Latham
Cc: nanog@nanog.org
Subject: Re: Hackers hijack 300, 000-plus wireless routers, make malicious 
changes | Ars Technica

On 03/04/2014 05:28 AM, jim deleskie wrote:
> Why want to swing such a big hammer.  Even blocking those 2 IP's will
> isolate your users, and fill your support queue's.

When the malicious DNS services get shutdown you will still have your
support queue's filled, anyway.

Doing it now will let you identify those affected. Blockage doesn't have
to be all-or-nothing. It can be incremental, selective or all-or-nothing
on some time windows.

Better now than later.

RE: Network Storage

[Ian McDonald]

Hi,
You'll need to build an array that'll random read/write upwards of 200MB/s if 
you want to get a semi-reliable capture to disk. That means SSD if you're very 
rich, or many spindles (preferably 15k's) in a stripe/ raid10 if you're 
building from your scrap pile. Bear in mind that write cache won't help you, as 
the io isn't going to be bursty, rather a continuous stream.

Another great help is scoping what you're looking for and pre-processing before 
writing out only the 'interesting' bits, thus reducing the io requirement. It 
does depend what you're trying to do, as headers can be adequate for many 
applications.

Aligning your partitions with the physical disk geometry can produce surprising 
speedups, as can stripe block size changes, but that's generally empirical, and 
depends on your workload.

--
ian
-Original Message-
From: Maverick
Sent:  12/04/2012, 21:27
To: nanog@nanog.org
Subject: Network Storage

Hello Everyone,

Can you please comment on what is best solution for storing network
traffic. We have been graciously granted access by our network
administrator to capture traffic but the one Tera byte disk space is
no match with the data that we are seeing, so it fills up quickly. We
can't get additional space on the server itself so I am looking for
some external solutions. Can you please suggest something that would
be best for Gbps speeds .


Best,
Ali

RE: DNS poisoning at Google?

[Ian McDonald]

Ahh, but how did it get there in the first place. Matthew, meet can of worms. I 
presume you have an opener.

--
ian
-Original Message-
From: Matthew Black
Sent:  27/06/2012, 08:07
To: Grant Ridder; nanog@nanog.org
Cc: Jeremy Hanmer
Subject: RE: DNS poisoning at Google?

We found the aberrant .htaccess file and have removed it. What a mess!

matthew black
information technology services
california state university, long beach

From: Grant Ridder [mailto:shortdudey...@gmail.com]
Sent: Tuesday, June 26, 2012 11:02 PM
To: Matthew Black; nanog@nanog.org
Cc: Jeremy Hanmer
Subject: Re: DNS poisoning at Google?

It also redirects with facebook, youtube, and ebay but NOT amazon.

-Grant

On Wed, Jun 27, 2012 at 12:57 AM, Matthew Black 
mailto:matthew.bl...@csulb.edu>> wrote:
Our web lead was able to run curl. Thanks.

matthew black
information technology services
california state university, long beach

From: Grant Ridder 
[mailto:shortdudey...@gmail.com]
Sent: Tuesday, June 26, 2012 10:53 PM
To: Matthew Black
Cc: Landon Stewart; nanog@nanog.org; Jeremy Hanmer

Subject: Re: DNS poisoning at Google?

Matt, what happens you get on a subnet that can access the webservers directly 
and bypass the load balancer.  Try curl then and see if its something w/ the 
webserver or load balancer.

-Grant
On Wed, Jun 27, 2012 at 12:40 AM, Matthew Black 
mailto:matthew.bl...@csulb.edu>> wrote:
Thanks again to everyone who helped. I didn't know what to enter with curl, 
because Outlook clobbered the line breaks in Jeremy's original message.

Also, curl failed on our primary webserver because of firewall and load 
balancer magic settings. The Telnet method worked better!

Our team is now scouring for that hidden redirect to couchtarts.

matthew black
information technology services
california state university, long beach

From: Landon Stewart [mailto:lstew...@superb.net]
Sent: Tuesday, June 26, 2012 10:37 PM
To: Matthew Black
Cc: Jeremy Hanmer; nanog@nanog.org
Subject: Re: DNS poisoning at Google?
There is definitely a 301 redirect.

$ curl -I --referer http://www.google.com/ http://www.csulb.edu/
HTTP/1.1 301 Moved Permanently
Date: Wed, 27 Jun 2012 05:36:31 GMT
Server: Apache/2.0.63
Location: http://www.couchtarts.com/media.php
Connection: close
Content-Type: text/html; charset=iso-8859-1
On 26 June 2012 22:05, Matthew Black 
mailto:matthew.bl...@csulb.edu>>>
 wrote:
Google Webtools reports a problem with our HOMEPAGE "/". That page is not 
redirecting anywhere.
They also report problems with some 48 other primary sites, none of which 
redirect to the offending couchtarts.

matthew black
information technology services
california state university, long beach




-Original Message-
From: Jeremy Hanmer 
[mailto:jeremy.han...@dreamhost.com>]
Sent: Tuesday, June 26, 2012 9:58 PM
To: Matthew Black
Cc: 
nanog@nanog.org>
Subject: Re: DNS poisoning at Google?
It's not DNS.  If you're sure there's no htaccess files in place, check your 
content (even that stored in a database) for anything that might be altering 
data based on referrer.  This simple test shows what I mean:
Airy:~ user$ curl -e 'http://google.com' 
csulb.edu  
301 Moved Permanently

Moved Permanently
The document has moved http://www.couchtarts.com/media.php";>here.


Running curl without the -e argument gives the proper site contents.
On Jun 26, 2012, at 9:24 PM, Matthew Black 
mailto:matthew.bl...@csulb.edu>>>
 wrote:

> Running Apache on three Solaris webservers behind a load balancer. No MS 
> Windows!
>
> Not sure how malicious software could get between our load balancer and Unix 
> servers. Thanks for the tip!
>
> matthew black
> information technology services
> california state university, long beach
>
>
>
> From: Landon Stewart 
> [mailto:lstew...@superb.net>]
> Sent: Tuesday, June 26, 2012 9:07 PM
> To: Matthew Black
> Cc: 
> nanog@nanog.org>
> Subject: Re: DNS poisoning at Google?
>
> Is it possible that some malicious software is listening and injecting a 
> redirect on the wire?  We've seen this before with a Windows machine being 
> infected.
> On 26 June 2012 20:53, Matthew Black 
> mailto:matthew.bl...@csulb.edu>>  wrote:
>