Re: SSH Disable

Karthikeyan Shanmugam · ‎11-29-2010

Hi,

I would like to disable SSH in AIP SSM 10 ips module since it's showing vaulanrability so please help me.

Thanks.

Panos Kampanakis · ‎11-30-2010

You probably want to disable ssh1 to stop being flagged as insecure. Disabling sshv1 on the sensor is tracked with bug CSCsk84977.

The workaround to disable it is

Create a service account (if one does not already exist) using the CLI, then log in using that account and enter the following commands:

su -

cd /etc/ssh

cp sshd_config sshd_config.old

sed -r '/^#?Protocol /cProtocol 2' sshd_config.old > sshd_config

## to apply the changes do:

/etc/init.d/cids reboot

.

I hope it helps.

PK

mikecrowe4ICS_2 · ‎11-30-2010

Wow!! This has to be one of the most helpful posts I've read in a while. I had no idea SSHv1 could be disabled - thought it just wasn't configurable on the IDSMs. Thanks very much.

Can we use a similar procedure to lock down SSH in other ways? For example, I'd like to set the ssh timeout value to 30 or 60 seconds, as well as limiting the ssh login attempts to a maximum of 3.

Is there a method for implementing that configuration?

Panos Kampanakis · ‎12-01-2010

Note that the changes will not remain after an upgrade.

As for changing the timeouts and retries, I am not sure. If there are corresponding values in the /etc/ssh/sshd_config file you might be able to do it, but I haven't done it in the past.

PK

Karthikeyan Shanmugam · ‎11-30-2010

Thanks for your reponce. please let me know where i have to put the command since i tried from the IPS sensor configuration mode but the command is invalid.

Thanks.

Panos Kampanakis · ‎12-01-2010

You need to create a service type user to be able to use the commands.

Other users will not be able to make these changes.

I hope it helps.

PK

Scott Fringer · ‎12-01-2010

Folks;

I'd like to add some clarification here on the use of the service account available in Cisco IPS sensors. From the IPS configuration guides:

The service account is a support and troubleshooting tool that enables TAC to log in to a native operating system shell rather than the CLI shell. It does not exist on the sensor by default. You must create it so that it is available for TAC to use for troubleshooting your sensor.

Only one service account is allowed per sensor and only one account is allowed a service role.

The service account is not intended to be used for configuration purposes. Only modifications made to the sensor through the service account under the direction of TAC are supported. Cisco Systems does not support the addition and/or running of an additional service to the operating system through the service account, because it affects proper performance and proper functioning of the other IPS services. TAC does not support a sensor on which additional services have been added.

Any changes made via the service account will not survive a software upgrade. Making unsupported changes via the service account may also require re-imaging the sensor to factory defaults to allow effective troubleshooting to occur during a TAC service request.

Scott

mikecrowe4ICS_2 · ‎12-01-2010

Thanks for the heads-up, Scott. I was about to make the changes, but I'm holding off for now.

To clarify, if I make the changes listed by "pkampana", will my IDSM-2 still be supported by the TAC?

I can accept the risk of potential re-imaging for support, as well as the loss of those changes after upgrades. I just want to make sure it won't prevent getting TAC support AT ALL.

Also, by software upgrade, you mean system images, but not signature updates, correct? For example, an upgrade from 7.0(3)E4 to 7.0(4)E4?

Scott Fringer · ‎12-02-2010

Michael;

The module will still be supported; but it will most likely be necessary to revert the module to factory defaults (re-image) early in the process to ensure it is not an unsupported change that is causing issue.

It is possible, depending on the changes implemented, that a signature update could revert a change; that is why the service account should not be utilized for direct or long-term configuration changes. Most changes performed via the service account are under TAC direction, and are usually reverted when the troubleshooting is completed.

Scott