Ok back to the previous premise..
Linux with an IPSEC server load..
IPSEC to the Linux box, use Telnet or ???
to connect to the routers on the management VLAN/Net
and your done....
Aside from that, Use ACL's out the wazoo on the VTY lines and limit access to
that to say 1 SSH enabled router or 1 IPSEC enabled router...
Jim
->-----Original Message-----
->From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of
->Rubens Kuhl Jr.
->Sent: Monday, June 07, 2004 8:08 AM
->To: nanog@merit.edu; Michael.Dillon@radianz.com
->Subject: Re: SSH on the router - was( IT security people sleep well)
->
->
->
->
->I'd rather use IPSEC than SSH to connect to routers or to a
->secure gateway
->and then to routers. Flaw history in IPSEC is much better
->than SSH, IPSEC
->can easily be used to move files with FTP or TFTP (does your
->router/client
->suport SCP ? SFTP ?)...
->
->Unfortunately, IOS costs more to have IPSEC.
->
->
->Rubens
->
->----- Original Message -----
->From: <Michael.Dillon@radianz.com>
->To: <nanog@merit.edu>
->Sent: Monday, June 07, 2004 7:39 AM
->Subject: SSH on the router - was( IT security people sleep well)
->
->
->>
->> > complaining that cisco charges extra for such a critical
->component is
->> > exactly the right thing to do; it is fucking scary.
->> >
->> > every damn network device which used to have telnet
->should ship with
->> > ssh, it's free.
->>
->> Why?
->>
->> The typical network architecture of an ISP sees routers located in
->> large clusters in a PoP or on a customer's site directly connected
->> to a PoP. Since it is dead simple to place a 1U Linux box or similar
->> SPARC server in a PoP to act as a secure gateway, why should router
->> vendors encourage laziness and sloppiness? IMHO routers should not
->> have SSH at all and should not accept any packets directed to them
->> unless they are coming from a small set of known addresses on the
->> network operator's management network.
->>
->> Once you open the router to SSH from arbitrary locations on the
->> Internet you also open the router to DDoS from arbitrary
->locations and
->> to attacks from people with inside info (SSH keys stolen or
->otherwise).
->>
->> It makes more sense to funnel everything through secure gateways and
->> then use SSH as a second level of security to allow staff to connect
->> to the secure gateways from the Internet. Of course these secure
->> gateways are more than just security proxies; they can also contain
->> diagnostic tools, auditing functions, scripting capability, etc.
->>
->> Now there is nothing fundamentally wrong with ADDING to that type
->> of architecture by enabling SSH between the routers and the security
->> gateways. But I believe that it is fundamentally wrong to consider
->> SSH on the router to be equivalent to opening the router to
->any staff
->> member, anytime, anywhere on the Internet. There are still possible
->> man in the middle attacks that cannot be protected against by SSH.
->> Consider the case of a staff member lounging in the backyard on a
->> lazy Saturday afternoon with their iBook. They have an
->802.11 wireless
->> LAN at home so they telnet to their Linux box in the kitchen and run
->> SSH to the router. Ooops!
->>
->> The only way to protect against that sort of situation is
->to encourage
->> everyone to be security-minded and not take risks where the
->network is
->> concerned. Funneling all access to routers through a secure
->gateway is
->> part of that security-mindedness and is just plain good practice.
->>
->> --Michael Dillon
->>
->>
->
->
> IP Permit Lists will not provide any mitigation against this
vulnerability.
>
> The race is on, who will find your switches first?
yes, i often wondered why the permit list allows the session to connect
then
gives you a polite message before disconnecting.
anyway this is only on catos..
Steve
I have been up to my ears in UDP-TCP-ACK-SYN Attacks for a couple of weeks
now. And IP Lists are useless when the attacker base exceeds that of the
router's memory, therefore I agree.
Paul Vixie stated earlier that there were/are some "short on work" Cisco
BGP/Router Engineers here or around this channel. If that is in-fact the
case then I could use some paid help and welcome anyone that wants to strike
out on their own and hang up their own shingle.
makes one wonder about all that virus-foo running around splashing packets
at 0/0:80... I wonder if any of that might have triggered these reloads
over the last, how long? Since catos was born?
a good thing, I think, cisco is finding and releasing these
problems/bugs/'features' in their platforms and thus working through
quality control issues. it's nice, other vendors should do the same for
things that get connected to the public network.
This is minor exploit - usually you set up VLAN1 interface with IP addres,
which is filterd out from outside. Moreover, there is not any good way to
find switch IP - it is transparent for user's devices.
> Aside from that, Use ACL's out the wazoo on the VTY lines and limit
access to
> that to say 1 SSH enabled router or 1 IPSEC enabled router...
It doesn't really matter if you use SSH, Telnet or HTTP; if you can send
evil packets to the router/switch and it falls over and dies.
Yeah, port scanners are so rare on the Internet they'll never find your
IP address. Its not as if the switches have an easy to detect banner
signature, and everyone uses out-of-band management for all their network
equipment.
I demonstrated the other approach recently.. we all tend to reserve IP space in
blocks for internal and management use, providing you can find out the block
that a particualr ISP is using (eg from traceroute), you can rDNS to find lots
of interesting and nicely labelled devices that dont show up in traceroutes..
such as loopbacks, switches, other stuff..
Sprint did an interesting presentation at San Francisco, they have successfully
taken p2p addresses out of their IGP and BGP, and are using private addresses
for loopbacks and other things that dont need to be in public space and are
filtering as much as possible.
>
> dns is your friend here People love to name things such that they are
> easy to remember. cat5500.floor2.build3.you.com
>
only if the dns/security/network/whatever admins are stupid enough to
s/stupid/careless/ || s/stupid/unknowing/ || s/stupid/<pick your favorite
reason why users do dumb things>/
let that zone be queried on their public facing dns servers. bind
allows for the filtering of queries, so your noc/engineering/etc address
blocks can query that zone (if it requires that there is an external dns
server for that zone). granted this is only obscuring things a bit, it
right, and as Sean pointed out to ... Alexei earlier: "Worms do this for
you" (maybe he said port scanners/banner-grabbers) point being obscurity
isn't really buying you anything
isn't really all that different that having a (semi-)seperate management
network.
if you don't have it set up like this, or don't know how, then buy
dns/bind (or an equivalent book) and/or hire someone who does.
Sure, you know this, I know this, Sean knows this and apparently Alexei
knows this (other present company of list included probably as well) but
Joe SOHO Networker doesn't necessarily know this, nor does his corporate
'security/secretary' person know this (or even have the power to change
it most times). So, yes, if you think ahead, plan for the worst and make
security part of your initial design you are ok. What percentage does
this? I'd bet less than the AV/Upgrade percentages
Sprint did an interesting presentation at San Francisco, they have successfully
taken p2p addresses out of their IGP and BGP, and are using private addresses
for loopbacks and other things that dont need to be in public space and are
filtering as much as possible.
indeed, and could someone please fix www.nanog.org?
Do you have any (even minimal) need to allocate globally routable IP to the
VLAN1 interface?
Other thing is that, even if I can find your switch, I will not have any
minimal idea, that it is _your_ switch and any minimal need to break it. You
can (easily) allocated all switch and router loopback IP in private network
many years ago, and filtered out this network on all inbound interfaces.
Even if I (if been a hacker) scan your networks and find this switch (and
you did not moved it out of routable P),
I will have not any idea, what is it about, where this switch is, and have
not any reason to break it...
