Super-Networking Blog

So if you want to limit one or more of your real servers in a virtual server farm to a certain amount of connections you can do it with the “maxconns” command.

Login to the CSM go into config mode, go into the serverfarm you want to restrict then go into the real server. Type in “maxconns #” replacing the # with the max connections you want to go to that real server. This way if you want to test something under real traffic but don’t want it to get slammed you can.

Also if you specify this command it will send out a syslog when the max has been reached.

%CSM_SLB-6-RSERVERSTATE: Module # server state changed: server X.X.X.X:0 in serverfarm ’serverfarm’ has reached configured max-conns

The CSM will then send the rest of the traffic to the other real servers in that serverfarm.

First you need to know what module your CSM is in, most of you know I am sure but otherwise use this at the enable prompt:

“show module”

Next you need to session into the CSM with the following command replacing the slot number with the module number you found using the command above:

“sessions slot 1 processor 0″

Finally you need to tftp the core dump file off of the CSM with the command:

“tftp core_dump tftp-ip-addr”

You need to replace the tftp-ip-addr with the IP of your TFTP server. Also if you have multiple core dump file you can put the name of the file you want to tftp after tftp-ip-addr.

So like most IT security minded people I want to use SSH on everything I can because with telnet your username and password are sent over the wire in clear text. Now I know most of you say well if you are internal what matters it your password is sent in clear text who would be listening? Well a lot of people could be, your boss, your fellow employee in IT, a rouge server, etc…

One thing that you can do to mitigate the threat to to make sure you are switching all your data since a switch doesn’t broadcast most data like hubs do. That still leaves it open to people who have access to the network switches and can sniff your port or the port you are going to. So you can use SSH since it is encrypted and that will protect you. Now not everything supports SSH, both on the software side and on the hardware side. I can’t help with the hardware, if your switch or router doesn’t support SSH either you have to buy a new IOS for it or stick to telnet at your own risk.

As for the software side if you have a program that needs to connect to your network devices over telnet and it can’t be switched to SSH and you really need it listen up.

You can use the access-class command under line vty 0 4 to lockdown what IPs have access to SSH or Telnet.

Example Commands:

ip access-list extended vty
permit tcp host 10.10.0.5 any eq telnet log
permit tcp any any eq 22 log
deny tcp any any log

line vty 0 4

access-class vty in

transport input telnet ssh

So that ACL would allow 10.10.0.5 to telnet to the network device and anyone to SSH. FYI that older versions of the IOS don’t allow you to use extended ACLs so you would only be able to determine IPs not ports/services.