Re: Automatic abuse reports

[Hal Murray]

William Herrin  said:
> That's the main problem: you can generate the report but if it's about
> some doofus in Dubai what are the odds of it doing any good?

It's much worse than that.

Several 500 pound gorillas expect you to jump through various hoops to report 
abuse.  Have you tried reporting a drop box to Yahoo or Google lately?

On top of that, many outfits big enough to own a CIDR block are outsourcing 
their mail to Google.  Google has a good spam filter.  It's good enough to 
reject spam reports to abuse@

I wonder what would happen if RIRs required working abuse mailboxes.  There 
are two levels of "working".  The first is doesn't bounce or get rejected 
with a sensible reason.  The second is actually gets acted upon.

If you were magically appointed big-shot in charge of everything, how long 
would you let an ISP host a spammer's web site or DNS server or ...?  What 
about retail ISPs with zillions of zombied systems?


-- 
These are my opinions.  I hate spam.

Re: Automatic abuse reports

[joel jaeggli]

On Nov 12, 2013, at 9:16 PM, Brandon Galbraith  
wrote:

> On Tue, Nov 12, 2013 at 10:03 PM, William Herrin  wrote:
>>> Now it would be trivial to setup syslog and sshd to give only the sessions
>>> that complete the handshake, however I'm also not sure how responsive some
>>> of the abuse contacts may be. I'll keep my restrictive network settings for
>>> the time being.
>> 
>> That's the main problem: you can generate the report but if it's about
>> some doofus in Dubai what are the odds of it doing any good?
> 
> And then we're right back to sending the offending packets to a black
> hole. *sigh*
> 

a packet that you can drop quickly is a packet you don’t have to think about.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Automatic abuse reports

[Brandon Galbraith]

On Tue, Nov 12, 2013 at 10:03 PM, William Herrin  wrote:
>> Now it would be trivial to setup syslog and sshd to give only the sessions
>> that complete the handshake, however I'm also not sure how responsive some
>> of the abuse contacts may be. I'll keep my restrictive network settings for
>> the time being.
>
> That's the main problem: you can generate the report but if it's about
> some doofus in Dubai what are the odds of it doing any good?

And then we're right back to sending the offending packets to a black
hole. *sigh*

Re: Automatic abuse reports

[William Herrin]

On Tue, Nov 12, 2013 at 9:07 PM, Sam Moats  wrote:
> That said the original poster was
> focused on a DOS event,to do that you really don't need the full handshake.

Point. Though not all DDOSes are created equal. The simple packet
flood is, as likely as not, from forged addresses. But I've also seen
DDOSes which make repeated HTTP GET requests. That's tough to do
without control of the source address.


> Now it would be trivial to setup syslog and sshd to give only the sessions
> that complete the handshake, however I'm also not sure how responsive some
> of the abuse contacts may be. I'll keep my restrictive network settings for
> the time being.

That's the main problem: you can generate the report but if it's about
some doofus in Dubai what are the odds of it doing any good?

Regards,
Bill Herrin



-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Automatic abuse reports

[Sam Moats]

Your right they wouldn't get all of the way through. The three way 
handshake is great against blind spoofing attacks. That said the 
original poster was focused on a DOS event,to do that you really don't 
need the full handshake.


I'm not sure if the end goal of whomever we were dealing with was to 
DOS us or if was some screwed up half open syn scans, or my personnel 
guess it was to generate enough bogus log traffic to hide which 
connections were legitimate threats. Either way enough inbound SYN 
connections on port 22 would tip over the servers, this was LONG ago 
circa 97~99, so the traffic we saw was an effective DOS.


We had inetd calling ssh and also telnet (Change comes slowly and 
cyrpto was painful to implement for us at the time). In our setup inetd 
decided to log the sessions both ssh and telnet as soon as the daemon 
was called. So even if we didn't do the full session setup the machine 
would still log an event for each tcp session.


In hindsight we could have cleaned it up so that it wouldn't log before 
completing the handshake or tweaked the perl script to filter them out 
but I was a newbie at that point and placing ACLs in my border router to 
drop inbound ssh traffic that didn't come from netblocks I expected and 
moving off of the default port were the easiest solutions at the time.


Now it would be trivial to setup syslog and sshd to give only the 
sessions that complete the handshake, however I'm also not sure how 
responsive some of the abuse contacts may be. I'll keep my restrictive 
network settings for the time being.


Sam Moats


On 2013-11-12 20:43, William Herrin wrote:

On Tue, Nov 12, 2013 at 4:52 PM, Sam Moats  wrote:
We used to use a small perl script called tattle that would parse 
out the
/var/log/secure on our *nix boxes, isolate the inbound ssh exploits, 
lookup
the proper abuse contacts and report them. I haven't seen anything 
similar

in years but it would be interesting to do more than null route IPs.

The problem we had with the automated reporting was dealing with 
spoofed
sources, we see lots of traffic that is obviously hostile but unless 
it

becomes serious enough to impact performance we rarely report it. An
automated system didn't seem to fit anymore due to false positives.


Hi Sam,

Out of curiosity -- how does one get a false positive on an ssh
exploit attempt? Does the origin IP not have to complete a 3-way
handshake before it can attempt an exploit?

Regards,
Bill Herrin

Re: Automatic abuse reports

[William Herrin]

On Tue, Nov 12, 2013 at 4:52 PM, Sam Moats  wrote:
> We used to use a small perl script called tattle that would parse out the
> /var/log/secure on our *nix boxes, isolate the inbound ssh exploits, lookup
> the proper abuse contacts and report them. I haven't seen anything similar
> in years but it would be interesting to do more than null route IPs.
>
> The problem we had with the automated reporting was dealing with spoofed
> sources, we see lots of traffic that is obviously hostile but unless it
> becomes serious enough to impact performance we rarely report it. An
> automated system didn't seem to fit anymore due to false positives.

Hi Sam,

Out of curiosity -- how does one get a false positive on an ssh
exploit attempt? Does the origin IP not have to complete a 3-way
handshake before it can attempt an exploit?

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Automatic abuse reports

[Randy Bush]

> I also would like to start send these abuse report to the ISP of the
> source.

good idea.  we all need more entries in our .procmailrcs

randy

Re: Automatic abuse reports

[Daniël W . Crompton]

On 12 November 2013 22:52, Sam Moats  wrote:

> We used to use a small perl script called tattle that would parse out the
> /var/log/secure on our *nix boxes, isolate the inbound ssh exploits, lookup
> the proper abuse contacts and report them. I haven't seen anything similar
> in years but it would be interesting to do more than null route IPs.


We also used to have a script which did something similar but for more than
just inbound ssh, for the most part this was ineffective.

D.


blaze your trail

-- 
Daniël W. Crompton 




http://specialbrands.net/

   

Re: CPE dns hijacking malware

[Jared Mauch]

Someone has to move. The defaults are really bad in dense deployments of 
1,6,11. Always fun when we went to Japan in the early days and our equipment 
could not see channel 13 :-)

Most need more fhss than single channel stuff. 

Jared Mauch

> On Nov 12, 2013, at 2:18 PM, James Sink  wrote:
> 
> Props on that, but wouldn't it have been easier to simply change your channel 
> setting?

Re: CPE dns hijacking malware

[Tom Morris]

As I recall, the unit in question had a severely flawed "auto" channel
selection algorithm that always, without fail, landed on the first OCCUPIED
channel. It was pretty terrible.


On Tue, Nov 12, 2013 at 4:18 PM, James Sink wrote:

> "Personally I have fond memories of going into my neighbor's router,
> flashing it with dd-wrt which allowed manual channel setting, and moving it
> off of the same wifi channel mine was on That was probably not a great
> idea, but you do what you have to sometimes."
>
> Props on that, but wouldn't it have been easier to simply change your
> channel setting?
> -James
>
> -Original Message-
> From: Tom Morris [mailto:bluen...@gmail.com]
> Sent: Tuesday, November 12, 2013 9:59 AM
> Cc: NANOG list
> Subject: Re: CPE dns hijacking malware
>
> EXTREMELY common. Almost all Comcast Cable CPE has this same login,
> cusadmin / highspeed At least on AT&T U-Verse gear, there's a sticker on
> the modem with the password which is a hash of the serial number or
> something equally unique.
>
> Almost all home routers also tend to have the default credentials.
>
> I'm actually surprised it was this long before XSS exploits and similar
> garbage started hitting them.
>
> Personally I have fond memories of going into my neighbor's router,
> flashing it with dd-wrt which allowed manual channel setting, and moving it
> off of the same wifi channel mine was on That was probably not a great
> idea, but you do what you have to sometimes.
>
>
> On Tue, Nov 12, 2013 at 10:57 AM, Matthew Galgoci  >wrote:
>
> > > Date: Tue, 12 Nov 2013 06:35:51 +
> > > From: "Dobbins, Roland" 
> > > To: NANOG list 
> > > Subject: Re: CPE  dns hijacking malware
> > >
> > >
> > > On Nov 12, 2013, at 1:17 PM, Jeff Kell  wrote:
> > >
> > > > (2) DHCP hijacking daemon installed on the client, supplying the
> > hijacker's DNS servers on a DHCP renewal.  Have seen both, the latter
> > being more
> > > > common, and the latter will expand across the entire home subnet
> > > > in
> > time (based on your lease interval)
> > >
> > > I'd (perhaps wrongly) assumed that this probably wasn't the case, as
> > > the
> > OP referred to the CPE devices themselves as being malconfigured; it
> > would be helpful to know if the OP can supply more information, and
> > whether or not he'd a chance to examine the affected CPE/end-customer
> setups.
> > >
> >
> > I have encountered a family members provider supplied CPE that had the
> > web server exposed on the public interface with default credentials
> > still in place. It's probably more common than one would expect.
> >
> > --
> > Matthew Galgoci
> > Network Operations
> > Red Hat, Inc
> > 919.754.3700 x44155
> > --
> > "It's not whether you get knocked down, it's whether you get up." -
> > Vince Lombardi
> >
> >
>
>
> --
> --
> Tom Morris, KG4CYX
> Mad Scientist and Operations Manager, WDNA-FM 88.9 Miami - Serious Jazz!
> 786-228-7087
> 151.820 Megacycles
>
>


-- 
--
Tom Morris, KG4CYX
Mad Scientist and Operations Manager, WDNA-FM 88.9 Miami - Serious Jazz!
786-228-7087
151.820 Megacycles

Re: Automatic abuse reports

[Jeroen Massar]

On 2013-11-12 16:58, Jonas Björklund wrote:
> Hello,
> 
> We got often abuse reports on hosts that has been involved in DDOS attacks.
> We contact the owner of the host help them fix the problem.
> 
> I also would like to start send these abuse report to the ISP of the
> source.
> 
> Are there any avaliable tools for this? Is there any plugin for nfsen?

Look at anything related to IODEF, specifically the CIF implementation:
 https://code.google.com/p/collective-intelligence-framework/

Greets,
 Jeroen

Re: CPE dns hijacking malware

[Larry Sheldon]

On 11/12/2013 3:54 PM, Larry Sheldon wrote:

On 11/12/2013 3:24 PM, Larry Sheldon wrote:

On 11/12/2013 12:12 AM, Dobbins, Roland wrote:


On Nov 12, 2013, at 12:56 PM, Mike 
wrote:


It appears that some of my subscribers DSL modems (which are acting
as nat routers) have had their dns settings hijacked and presumably
for serving ads or some such nonsense.


How do you think this was accomplished?  Via some kind of Web exploit
customized for those devices and targeting your user population via
email or social media, which tricked users into clicking on something
that accessed the Web admin interface via default admin credentials
or somsesuch; or via some direct attack on the CPE devices
themselves; or via some other method?


I am less well informed here than in a lot of other things, so please be
gentle.

As a user of such equipment, I don't see or know of anything in the I/F
that I have access-to that mentions DNSish stuff except the servers I am
to use.

But interestingly enough, when I tried to look at it to verify my
belief's just no I got a certificate error that it won't let me past.

That seems odd.



Meant to send this to the list.

The on-line chat to Linksys was subsatisfying, but for want of something
to do I dropped the "s" IN "https" and go on the router just fine. Makes
you wonder if I understand "certificates".

But I do not see anything that looks like I can affect DNS beyond which
servers I use.


And I don't know a way to get on Cox's "cable modem" at all.



--
Requiescas in pace o email   Two identifying characteristics
of System Administrators:
Ex turpi causa non oritur actio  Infallibility, and the ability to
learn from their mistakes.
  (Adapted from Stephen Pinker)

Re: CPE dns hijacking malware

[Larry Sheldon]

On 11/12/2013 3:24 PM, Larry Sheldon wrote:

On 11/12/2013 12:12 AM, Dobbins, Roland wrote:


On Nov 12, 2013, at 12:56 PM, Mike 
wrote:


It appears that some of my subscribers DSL modems (which are acting
as nat routers) have had their dns settings hijacked and presumably
for serving ads or some such nonsense.


How do you think this was accomplished?  Via some kind of Web exploit
customized for those devices and targeting your user population via
email or social media, which tricked users into clicking on something
that accessed the Web admin interface via default admin credentials
or somsesuch; or via some direct attack on the CPE devices
themselves; or via some other method?


I am less well informed here than in a lot of other things, so please be
gentle.

As a user of such equipment, I don't see or know of anything in the I/F
that I have access-to that mentions DNSish stuff except the servers I am
to use.

But interestingly enough, when I tried to look at it to verify my
belief's just no I got a certificate error that it won't let me past.

That seems odd.



Meant to send this to the list.

The on-line chat to Linksys was subsatisfying, but for want of something 
to do I dropped the "s" IN "https" and go on the router just fine. 
Makes you wonder if I understand "certificates".


But I do not see anything that looks like I can affect DNS beyond which 
servers I use.

--
Requiescas in pace o email   Two identifying characteristics
of System Administrators:
Ex turpi causa non oritur actio  Infallibility, and the ability to
learn from their mistakes.
  (Adapted from Stephen Pinker)

Re: Automatic abuse reports

[Sam Moats]

We used to use a small perl script called tattle that would parse out 
the /var/log/secure on our *nix boxes, isolate the inbound ssh exploits, 
lookup the proper abuse contacts and report them. I haven't seen 
anything similar in years but it would be interesting to do more than 
null route IPs.


The problem we had with the automated reporting was dealing with 
spoofed sources, we see lots of traffic that is obviously hostile but 
unless it becomes serious enough to impact performance we rarely report 
it. An automated system didn't seem to fit anymore due to false 
positives.


A number of providers who aren't exactly interested in the overall good 
health of the net do a poor job of network ingress filtering that unless 
I closely examine the traffic and it's origins. Without being able to 
trust the source address information in the DDOS traffic I run the risk 
of crying wolf to a provider who is just as much a victim as I am. 
(Think of my ACK packets piling in his network in response to the bogus 
SYN packets I'm getting). So we reserve complaints for when there is an 
actual impact and try to keep the signal to noise ratio in our reports 
decent.


I'm not really happy with this approach and I'm open to ideas!

Thanks
Sam Moats

On 2013-11-12 16:58, Jonas Björklund wrote:

Hello,

We got often abuse reports on hosts that has been involved in DDOS 
attacks.

We contact the owner of the host help them fix the problem.

I also would like to start send these abuse report to the ISP of the 
source.


Are there any avaliable tools for this? Is there any plugin for 
nfsen?


Do I need to write my own scripts for this?

/Jonas

Automatic abuse reports

[Jonas Björklund]

Hello,

We got often abuse reports on hosts that has been involved in DDOS attacks.
We contact the owner of the host help them fix the problem.

I also would like to start send these abuse report to the ISP of the source.

Are there any avaliable tools for this? Is there any plugin for nfsen?

Do I need to write my own scripts for this?

/Jonas

RE: CPE dns hijacking malware

[James Sink]

"Personally I have fond memories of going into my neighbor's router, flashing 
it with dd-wrt which allowed manual channel setting, and moving it off of the 
same wifi channel mine was on That was probably not a great idea, but you 
do what you have to sometimes."

Props on that, but wouldn't it have been easier to simply change your channel 
setting?
-James

-Original Message-
From: Tom Morris [mailto:bluen...@gmail.com] 
Sent: Tuesday, November 12, 2013 9:59 AM
Cc: NANOG list
Subject: Re: CPE dns hijacking malware

EXTREMELY common. Almost all Comcast Cable CPE has this same login, cusadmin / 
highspeed At least on AT&T U-Verse gear, there's a sticker on the modem with 
the password which is a hash of the serial number or something equally unique.

Almost all home routers also tend to have the default credentials.

I'm actually surprised it was this long before XSS exploits and similar garbage 
started hitting them.

Personally I have fond memories of going into my neighbor's router, flashing it 
with dd-wrt which allowed manual channel setting, and moving it off of the same 
wifi channel mine was on That was probably not a great idea, but you do 
what you have to sometimes.


On Tue, Nov 12, 2013 at 10:57 AM, Matthew Galgoci wrote:

> > Date: Tue, 12 Nov 2013 06:35:51 +
> > From: "Dobbins, Roland" 
> > To: NANOG list 
> > Subject: Re: CPE  dns hijacking malware
> >
> >
> > On Nov 12, 2013, at 1:17 PM, Jeff Kell  wrote:
> >
> > > (2) DHCP hijacking daemon installed on the client, supplying the
> hijacker's DNS servers on a DHCP renewal.  Have seen both, the latter 
> being more
> > > common, and the latter will expand across the entire home subnet 
> > > in
> time (based on your lease interval)
> >
> > I'd (perhaps wrongly) assumed that this probably wasn't the case, as 
> > the
> OP referred to the CPE devices themselves as being malconfigured; it 
> would be helpful to know if the OP can supply more information, and 
> whether or not he'd a chance to examine the affected CPE/end-customer setups.
> >
>
> I have encountered a family members provider supplied CPE that had the 
> web server exposed on the public interface with default credentials 
> still in place. It's probably more common than one would expect.
>
> --
> Matthew Galgoci
> Network Operations
> Red Hat, Inc
> 919.754.3700 x44155
> --
> "It's not whether you get knocked down, it's whether you get up." - 
> Vince Lombardi
>
>


--
--
Tom Morris, KG4CYX
Mad Scientist and Operations Manager, WDNA-FM 88.9 Miami - Serious Jazz!
786-228-7087
151.820 Megacycles

Re: Do you obfuscate email headers when reporting spam issues to clients?

[Landon]

Hello NANOG,

Just a quick note thanking those that responded to me on and off list.  I
appreciate the input!

-- 
Landon Stewart 

Re: CPE dns hijacking malware

[Tom Morris]

EXTREMELY common. Almost all Comcast Cable CPE has this same login,
cusadmin / highspeed
At least on AT&T U-Verse gear, there's a sticker on the modem with the
password which is a hash of the serial number or something equally unique.

Almost all home routers also tend to have the default credentials.

I'm actually surprised it was this long before XSS exploits and similar
garbage started hitting them.

Personally I have fond memories of going into my neighbor's router,
flashing it with dd-wrt which allowed manual channel setting, and moving it
off of the same wifi channel mine was on That was probably not a great
idea, but you do what you have to sometimes.


On Tue, Nov 12, 2013 at 10:57 AM, Matthew Galgoci wrote:

> > Date: Tue, 12 Nov 2013 06:35:51 +
> > From: "Dobbins, Roland" 
> > To: NANOG list 
> > Subject: Re: CPE  dns hijacking malware
> >
> >
> > On Nov 12, 2013, at 1:17 PM, Jeff Kell  wrote:
> >
> > > (2) DHCP hijacking daemon installed on the client, supplying the
> hijacker's DNS servers on a DHCP renewal.  Have seen both, the latter being
> more
> > > common, and the latter will expand across the entire home subnet in
> time (based on your lease interval)
> >
> > I'd (perhaps wrongly) assumed that this probably wasn't the case, as the
> OP referred to the CPE devices themselves as being malconfigured; it would
> be helpful to know if the OP can supply more information, and whether or
> not he'd a chance to examine the affected CPE/end-customer setups.
> >
>
> I have encountered a family members provider supplied CPE that had the
> web server exposed on the public interface with default credentials still
> in place. It's probably more common than one would expect.
>
> --
> Matthew Galgoci
> Network Operations
> Red Hat, Inc
> 919.754.3700 x44155
> --
> "It's not whether you get knocked down, it's whether you get up." - Vince
> Lombardi
>
>


-- 
--
Tom Morris, KG4CYX
Mad Scientist and Operations Manager, WDNA-FM 88.9 Miami - Serious Jazz!
786-228-7087
151.820 Megacycles

Re: CPE dns hijacking malware

[Dobbins, Roland]

On Nov 12, 2013, at 10:57 PM, Matthew Galgoci  wrote:

> It's probably more common than one would expect.

Concur 100%.



---
Roland Dobbins  // 

  Luck is the residue of opportunity and design.

   -- John Milton

Re: CPE dns hijacking malware

[Matthew Galgoci]

> Date: Tue, 12 Nov 2013 06:35:51 +
> From: "Dobbins, Roland" 
> To: NANOG list 
> Subject: Re: CPE  dns hijacking malware
>
>
> On Nov 12, 2013, at 1:17 PM, Jeff Kell  wrote:
>
> > (2) DHCP hijacking daemon installed on the client, supplying the hijacker's 
> > DNS servers on a DHCP renewal.  Have seen both, the latter being more
> > common, and the latter will expand across the entire home subnet in time 
> > (based on your lease interval)
>
> I'd (perhaps wrongly) assumed that this probably wasn't the case, as the OP 
> referred to the CPE devices themselves as being malconfigured; it would be 
> helpful to know if the OP can supply more information, and whether or not 
> he'd a chance to examine the affected CPE/end-customer setups.
>

I have encountered a family members provider supplied CPE that had the
web server exposed on the public interface with default credentials still
in place. It's probably more common than one would expect.

-- 
Matthew Galgoci
Network Operations
Red Hat, Inc
919.754.3700 x44155
--
"It's not whether you get knocked down, it's whether you get up." - Vince 
Lombardi