Re: Cisco PIX with SSH enabled on external port for maintenance

[Cory Stoker <cory () clearnetsec com>]

As far as the PIX goes I would try to avoid leaving the management  
functions out in the open.  I personally favor connecting to the PIX  
through IPSec then SSHing or even telneting to the "inside"  
interfaces through the tunnel.  This allows you to also support other  
management items like SNMP, TFTP, and PDM.  Also for PIX versions  
6.x,  SSH 2 is not supported so you have to use SSH 1.  PIX 7.x does  
include SSH version 2 support.

If you must support SSH to the "outside" interface then you should  
try to limit the SSH access to specific IP addresses like so:

"ssh 1.1.1.1 255.255.255.255 outside"

The key to the first solution is the command "management-access" as  
PIX does not allow you to connect to it from a VPN tunnel terminating  
on the PIX by default unless you specify this command.

Thanks,
---
Cory Stoker
ClearNet Security

On Nov 15, 2005, at 10:56 AM, <Steve.Cummings () barclayscapital com>  
<Steve.Cummings () barclayscapital com> wrote:

> It's a firewall do you really want anyone attaching to it?
>
>
> -----Original Message-----
> From: Chris Largret <largret () gmail com>
> To: Cam Fischer <camfischer () gmail com>
> CC: security-basics () securityfocus com <security- 
> basics () securityfocus com>
> Sent: Thu Nov 10 22:02:39 2005
> Subject: Re: Cisco PIX with SSH enabled on external port for  
> maintenance
>
> On Wed, 2005-11-09 at 19:01 -0700, Cam Fischer wrote:
> > I am looking for some reasons why I should not be allowing SSH on the
> > external side of my Cisco PIX firewall. It would be great for
> > management, but what are the risks associated with this?
>
> SSH brute force attacks (and guessing schemes) have been on-going  
> for a
> while. Take a look at http://www.agleia.de/luser2 for a list of
> usernames that were used in one attack.
>
> If you DO allow access to SSH to the outside world, there are a few
> things you can do to make it more secure:
>
> 1. Use a non-standard port
> 2. Use only the strongest algorithms that SSH supports
> 3. Change the passwords regularly
> 4. Allow only strong passwords
> 5. Limit which IP addresses can connect
>
> It is possible to keep an SSH server secure, but it does take work. If
> someone gains access through SSH, it is generally only a matter of  
> time
> until they have full control over the system. If they can get  
> inside the
> firewall, the other computers on the network could be equally
> compromised if your security model doesn't protect computers from  
> others
> on the same network.
>
> --
> Chris Largret <http://daga.dyndns.org>