RE: SSH on the router - was( IT security people sleep well)
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 ->> ->> -> ->
On Mon, 7 Jun 2004, McBurnett, Jim wrote:
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. http://www.cisco.com/warp/public/707/cisco-sa-20040609-catos.shtml IP Permit Lists will not provide any mitigation against this vulnerability. The race is on, who will find your switches first?
On Wed, 9 Jun 2004, Sean Donelan wrote:
On Mon, 7 Jun 2004, McBurnett, Jim wrote:
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.
http://www.cisco.com/warp/public/707/cisco-sa-20040609-catos.shtml
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
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. Peter 301-340-1533
On Wed, 9 Jun 2004, Sean Donelan wrote:
http://www.cisco.com/warp/public/707/cisco-sa-20040609-catos.shtml
IP Permit Lists will not provide any mitigation against this vulnerability.
The race is on, who will find your switches first?
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. -Chris
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.
On Mon, 7 Jun 2004, McBurnett, Jim wrote:
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.
http://www.cisco.com/warp/public/707/cisco-sa-20040609-catos.shtml
IP Permit Lists will not provide any mitigation against this vulnerability.
The race is on, who will find your switches first?
On Wed, 9 Jun 2004, Alexei Roudnev wrote:
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.
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.
On Thu, 10 Jun 2004, Sean Donelan wrote:
On Wed, 9 Jun 2004, Alexei Roudnev wrote:
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.
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. Steve
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? :) URL in Question -> http://www.nanog.org/mtg-0405/pdf/mcdowell.pdf Linked From -> http://www.nanog.org/mtg-0405/mcdowell.html Result: Not Found The requested URL /mtg-0405/pdf/mcdowell.pdf was not found on this server. Apache/1.3.26 Server at www.nanog.org Port 80 -j -- James Jun TowardEX Technologies, Inc. Technical Lead Network Design, Consulting, IT Outsourcing james@towardex.com Boston-based Colocation & Bandwidth Services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net
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... ----- Original Message ----- From: "Sean Donelan" <sean@donelan.com> To: <nanog@merit.edu> Sent: Thursday, June 10, 2004 4:19 AM Subject: Re: TCP-ACK vulnerability (was RE: SSH on the router)
On Wed, 9 Jun 2004, Alexei Roudnev wrote:
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.
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.
Private addressing/non routing of the netblock is only of limited use. I assume here the block is in the IGP.. the more customers/networks you serve the more chance of an attack coming from within. Steve On Thu, 10 Jun 2004, Alexei Roudnev wrote:
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...
----- Original Message ----- From: "Sean Donelan" <sean@donelan.com> To: <nanog@merit.edu> Sent: Thursday, June 10, 2004 4:19 AM Subject: Re: TCP-ACK vulnerability (was RE: SSH on the router)
On Wed, 9 Jun 2004, Alexei Roudnev wrote:
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.
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.
On Wed, 9 Jun 2004, Alexei Roudnev wrote:
This is minor exploit - usually you set up VLAN1 interface with IP addres,
'usually' doesn't cover everyone, and some people didn't think ahead or realize that they might have a problem with this :(
which is filterd out from outside. Moreover, there is not any good way to find switch IP - it is transparent for user's devices.
dns is your friend here :( People love to name things such that they are easy to remember. cat5500.floor2.build3.you.com
On Mon, 7 Jun 2004, McBurnett, Jim wrote:
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.
http://www.cisco.com/warp/public/707/cisco-sa-20040609-catos.shtml
IP Permit Lists will not provide any mitigation against this vulnerability.
The race is on, who will find your switches first?
participants (7)
-
Alexei Roudnev -
Christopher L. Morrow -
James -
McBurnett, Jim -
Pete -
Sean Donelan -
Stephen J. Wilcox