cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
679
Views
0
Helpful
5
Replies

Out-of-band (modem) access to the IDSM2 blade

msmitha
Level 1
Level 1

We are going to have a few IDSM2 blades spread out geographically soon. The security group at my company does not control the Cat 650x switches as such and I'd like to know if there is someway we could get console (modem) access to the IDSM2 blade only (without getting to the switch).

If that is not possible, is there a common-console connection which has to be shared between the infrastructure group and security group? is it possible for us to share the modem/console access along with privilege separation?

Your help is appreciated. Thanks,

2 Accepted Solutions

Accepted Solutions

marcabal
Cisco Employee
Cisco Employee

The IDSM-2 itself does not have a console port.

Options for accessing the IDSM-2:

1) A user could gain console access to the switch, and from the switch CLI the user can session to the IDSM-2. This would require physical connection to the switch through a console port (or terminal server), and passwords for accessing both the switch and IDSM-2.

2) A user could connect to the switch through a modem, and from the switch CLI the user can sesion to the IDSM-2. This would require a modem connection to the switch, and passwords for accessing both the switch and IDSM-2.

3) A user could telnet or ssh to the switch, and from the switch CLI the user can session to the IDSM-2. This would require network connectivity to the ip address of the switch itself, and passwords for both the switch and IDSM-2.

4) A user could SSH directly to the IDSM-2 command and control IP Address. This would require network connectivity to the command and control ip address of the IDSM2, and only requires passwords for the IDSM-2 itself.

5) Similar to number 4 above, the user could telnet directly to the IDSM-2.

6) A user could Web Browse (HTTPS) to the IDSM-2 command and control IP Address to gain access to the IDS Device Manager. This would require network connectivity to the command and control ip address of the IDSM2, and only requires passwords for the IDSM-2 itself.

-------------

On initial installation of the IDSM-2, options 4,5 and 6 can not be used. This is because the IDSM-2 comes with a standard default ip address that is not likely reachable. For initial setup the user will need to session in from a switch CLI.

However, once the "setup" command has been run on the IDSM-2, and the switch configuration for the IDSM-2 to place it in the correct vlan for the IDSM-2 command and control ip address, then the IDSM-2 can be directly accessed across the network through options 4,5 and 6.

Once intial setup is complete, the daily management of the IDSM-2 can be done through direct network access so there is no need to access the switch.

The only time the switch would need to be accessed again is to configure the sending of packets to the IDSM-2 (usually done along with the initial setup and rarely changes), and to reset the module, or reload a new image on the module in case of major issues. (Note standard upgrades can be done through the direct network access without accessing the switch).

So some users choose to work in conjunction with the switch team during initial setup and during times of trouble shootin.

And will just use the direct access through ssh or telnet to the IDSM-2 for day to day activity.

Other groups have used TACACS+ to provide the security team a userid on the switch. Through TACACS+ configuration entries, the userid for the security team can be limited to executing only those commands that are required for maintaining the IDSM-2.

The userid could then be used to login over the network to the switch, or login through the switch console or a modem connected to the switch.

If you are only worried about occasions when network connectivity between your main site and the remote site is down, then have you considered adding a PC to the remote site that would be on the same network as the command and control address of the IDSM-2?

You could put a modem into the PC, and then when needed you could dial into the PC and from the PC be able to telnet or ssh to the IDSM-2's IP address.

View solution in original post

If I properly understand your desire (be able to configure the IDSM2 itself and not the switch), it seems to me that a suitable solution would be to connect the modem to the console port (as you indicated) and simply NOT give those security admins the switch's enable password.

By doing so, those security admins would be unable to enter privileged mode on the switch so they would be unable to alter the switch's configuration. But, they could still session to the IDSM2 (from the switch's non-privileged mode) and do any configuration on the IDMS2 itself via the IDSM2 CLI after logging in to it.

If, however, the security admins want to alter the switch configuration as it relates to the IDSM2, then that would require having privileged mode access on the switch. And then it would be difficult to allow the security admins to alter the config only as it relates to the IDSM2.

View solution in original post

5 Replies 5

marcabal
Cisco Employee
Cisco Employee

The IDSM-2 itself does not have a console port.

Options for accessing the IDSM-2:

1) A user could gain console access to the switch, and from the switch CLI the user can session to the IDSM-2. This would require physical connection to the switch through a console port (or terminal server), and passwords for accessing both the switch and IDSM-2.

2) A user could connect to the switch through a modem, and from the switch CLI the user can sesion to the IDSM-2. This would require a modem connection to the switch, and passwords for accessing both the switch and IDSM-2.

3) A user could telnet or ssh to the switch, and from the switch CLI the user can session to the IDSM-2. This would require network connectivity to the ip address of the switch itself, and passwords for both the switch and IDSM-2.

4) A user could SSH directly to the IDSM-2 command and control IP Address. This would require network connectivity to the command and control ip address of the IDSM2, and only requires passwords for the IDSM-2 itself.

5) Similar to number 4 above, the user could telnet directly to the IDSM-2.

6) A user could Web Browse (HTTPS) to the IDSM-2 command and control IP Address to gain access to the IDS Device Manager. This would require network connectivity to the command and control ip address of the IDSM2, and only requires passwords for the IDSM-2 itself.

-------------

On initial installation of the IDSM-2, options 4,5 and 6 can not be used. This is because the IDSM-2 comes with a standard default ip address that is not likely reachable. For initial setup the user will need to session in from a switch CLI.

However, once the "setup" command has been run on the IDSM-2, and the switch configuration for the IDSM-2 to place it in the correct vlan for the IDSM-2 command and control ip address, then the IDSM-2 can be directly accessed across the network through options 4,5 and 6.

Once intial setup is complete, the daily management of the IDSM-2 can be done through direct network access so there is no need to access the switch.

The only time the switch would need to be accessed again is to configure the sending of packets to the IDSM-2 (usually done along with the initial setup and rarely changes), and to reset the module, or reload a new image on the module in case of major issues. (Note standard upgrades can be done through the direct network access without accessing the switch).

So some users choose to work in conjunction with the switch team during initial setup and during times of trouble shootin.

And will just use the direct access through ssh or telnet to the IDSM-2 for day to day activity.

Other groups have used TACACS+ to provide the security team a userid on the switch. Through TACACS+ configuration entries, the userid for the security team can be limited to executing only those commands that are required for maintaining the IDSM-2.

The userid could then be used to login over the network to the switch, or login through the switch console or a modem connected to the switch.

If you are only worried about occasions when network connectivity between your main site and the remote site is down, then have you considered adding a PC to the remote site that would be on the same network as the command and control address of the IDSM-2?

You could put a modem into the PC, and then when needed you could dial into the PC and from the PC be able to telnet or ssh to the IDSM-2's IP address.

Thanks for the helpful information.

I'm interested in option 2 - connecting to the switch through a modem, and from the switch CLI the user can sesion to the IDSM-2. Once connected to the switch via the modem, is it possible to have a very-low privilege level on the switch CLI for the security administrator? This way, security admins can dial-into the switch and session into the IDSM2 blade and not be able to do much with any other aspects of the switch configuration.

Thanks again for the help.

I have never done this, but it should be possible.

It will require alot of setup on your switch to setup per command authorization using TACACS+.

The security team's account would then be authorized only for specific commands applying to IDSM-2 management.

The switch team's account would then be authorized for all switch commands.

I haven't seen a good configuration example for this, but you could read through the following document for using TACACS+ with the switch:

http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_8_1/confg_gd/authent.htm#1021751

TACACS+ is a piece of AAA, so the AAA Forum would be a good place to go for more expertise on this type of configuration on the switch: http://forum.cisco.com/eforum/servlet/NetProf;jsessionid=3pggyn2ch1.SJ1B?page=netprof&CommCmd=MB%3Fcmd%3Ddisplay_messages%26mode%3Dnew%26location%3D.ee6e1fe

If I properly understand your desire (be able to configure the IDSM2 itself and not the switch), it seems to me that a suitable solution would be to connect the modem to the console port (as you indicated) and simply NOT give those security admins the switch's enable password.

By doing so, those security admins would be unable to enter privileged mode on the switch so they would be unable to alter the switch's configuration. But, they could still session to the IDSM2 (from the switch's non-privileged mode) and do any configuration on the IDMS2 itself via the IDSM2 CLI after logging in to it.

If, however, the security admins want to alter the switch configuration as it relates to the IDSM2, then that would require having privileged mode access on the switch. And then it would be difficult to allow the security admins to alter the config only as it relates to the IDSM2.

Yes, I'm only talking about out-of-band access for the IDSM2 CLI if we loose management for some reason. Your solution works for me - if security admins can get to the IDSM2 CLI when they dial-in and session to the IDMS2, that's great. I understand switch configuration itself is not possible, which is the desired scenario.

Thanks for all the help.