[nsp-sec] creative lying

Johnson, Ron RJohnson at newedgenetworks.com
Tue Sep 2 17:45:09 EDT 2008


Typically, I don't trust my customer. Anything that they have physical
access to is not really fully under my company's control. For the most
part customers stay out of the CPE. However, there are a few folks that
know how to console override a Cisco and get at the config. We have
walked customers through doing this as well in order to perform an
emergency recovery processes. Rather than having them out of service
while a replacement overnight delivers. I consider the uber paranoid "no
service password-recovery" option a bad practice. (See Terry Childs for
example).

Clever hacker types are going to meddle with the CPE without drawing
attention that they have done so. In effort to combat the possibility of
customer nefarious activity without reliance on the CPE to do this
function. I install RPF on their interface on our side of the
connection. 

It's a pretty easy template addition to make sure the following installs
on each customer interface.

 ip verify unicast reverse-path allow-self-ping
 no ip directed-broadcast
 no ip proxy-arp
 no ip mroute-cache
 no cdp enable

I used to have the inbound/outbound Bogon filters on the external
interfaces towards our peers and transit, but these filters have become
unmanageable due to constraints in changing them as often as they need
changing. Management does not like a lot of changes to otherwise
operation equipment. Since my AS is kind of Podunk compared to others, I
can operation ACL's on my peering and transit. However, these filter are
now are reduced to the unchanging Bogons such as 1918 addresses.
Filtering at transit points can be unfeasible for most providers due to
bit rates. However, rather than installing filters at transit and
peering point. Y'all can install them at lower bit rate uplinks, like
between agg/border or border/core interconnections. 

Since I am small, and don't use the Routing registry to automatically
build prefix filter lists for my downstream customers. I use a very
specific prefix filter on customer BGP interfaces to prevent the
announcement of unauthorized address space via BGP.

I have seen many other providers only installing the Bogon prefix
filters against a downstream and letting them announce what ever. This I
feel is a bad practice, and leads ease of high-jacking of more specific
address space, for nefarious purposes. 


Regards,
Ron Johnson


-----Original Message-----
From: nsp-security-bounces at puck.nether.net
[mailto:nsp-security-bounces at puck.nether.net] On Behalf Of Chris Morrow
Sent: Tuesday, September 02, 2008 1:36 PM
To: Smith, Donald
Cc: nsp-security at puck.nether.net
Subject: Re: [nsp-sec] creative lying

----------- nsp-security Confidential --------



On Tue, 2 Sep 2008, Smith, Donald wrote:

> ----------- nsp-security Confidential --------
>
> No problem at all except who owns/manages the CPE (customer provided
> equipment) and what is their payout for doing this?
>
> I agree its a good idea how do we get our customers to perform that 
> filtering?
> In many cases the guy setting up an enterprises router has never heard

> of cymru or seen cisco's security blue prints or read a juniper manual

> about security. They simply want to router to work and once it begins 
> working they leave it alone.

and.. for whatever reason, managed CPE (routers) is not a huge business
in the US. It seems like it's huge business in EMEA/APAC though, which
always made me a little confused.

-Chris


_______________________________________________
nsp-security mailing list
nsp-security at puck.nether.net
https://puck.nether.net/mailman/listinfo/nsp-security

Please do not Forward, CC, or BCC this E-mail outside of the
nsp-security community. Confidentiality is essential for effective
Internet security counter-measures.
_______________________________________________



More information about the nsp-security mailing list