Another day, another thing to do in my network. I’m currently taking the first steps of increasing my network’s security and preparing for the deployment of a permanent VPN server.
First the VPN server: I’ve already done tests, but I ran into common subnet problems. The current subnet I use is 192.168.0.0/24, and from several other (friend’s) places, connecting works but routing fails, since their local network also uses 192.168.0.0/24 very often. So I’ve migrated my subnet to something less common, e.g. 192.168.168.0/24 to reduce complexity. More on VPN in blog posts to come, when I properly figure out the details.
Second issue: I got tired of typing all those IP addresses over and over everytime I tested or changed something. It’s possible to set up an internal DNS to take care of that, but that’s still on the ‘to do’ list, so for now, I’m using the hosts file. For those who don’t know what the hosts file is: it’s a file in Windows that contains DNS records, in the “C:/Windows/system32/drivers/etc/” directory. It usually contains no records because everything is done by DNS server, but you can add your own records to it. In this case, for example, I added my IP Phone: ‘192.168.168.161 phone’. Now if I type ‘ping phone’ in the command line, it will ping my IP Phone (which of course has a static IP). Might be useful if you have some devices around the house with a static IP but no DNS server. Naturally, it will only work from that computer.
And last: hardening my switch security. I originally accessed my switch remotely by Telnet on port 23. This is about the most insecure thing to do. Time to implement SSH (RFC 4251 for those interested) and access-lists (ACL). First ACL: I want to be able to access the switch, but only from certain locations: the inside network and my workplace. At my office I’m connected behind a NAT device, but this device’s external IP is static, so that makes it simple:
Switch(config)#ip access-list standard remoteACL
Switch(config-std-acl)#10 permit host <ip office>
Switch(config-std-acl)#20 permit 192.168.168.0 0.0.0.255
Switch(config-std-acl)#30 deny any log
Switch(config-std-acl)#exit
The first line is from my work, the second for when I’m at home, and the third line is just to log any unauthorized attempts. The third is optional because of the implicit deny at the end. Next, I configure usernames to log in, and activate aaa services needed for usernames and SSH.
Switch(config)#aaa new-model
Switch(config)#username <user> privilege 15 secret <password>
Switch(config)#aaa authentication login default local
Switch(config)#aaa authentication enable default none
Now, when logging in remotely, I will be asked a username and password. The privilege level is set to 15 because this is the highest level (all rights), and the last two commands are to make sure the device will look at the local user database when a login attempt is made. You can also use an external database using TACACS+ or RADIUS, pointing to a database server, e.g. Windows Active Directory. Not needed for the lab, but again, recommended for use in a company.
Next, the actual SSH configuration. This requires an IOS that supports cryptographic services for this (look for ‘k9’ in the name). You will need to generate a RSA key, but for that key, you will need a domain name, and the device must have a non-default hostname.
Switch(config)#hostname switch01
switch01(config)#ip domain-name local.lan
switch01(config)#crypto key generate rsa
Now you will be asked a key length. Standard is 512 bits, but it’s best to make is more secure using 1024 bits. Many sources, including Cisco, recommend this as a minimum length. The longer the key length the more time it takes to generate. Once the key is generated, your device has a valid certificate. If you change the hostname or domain name afterwards, you can still connect, but the key will be marked as untrusted by any properly working client program. Also, I’m using local certificates, but when managing many devices in the same company, it’s best to set up a central certificate. Yes, that’s on my ‘to do’ list too. Once the key is generated, we apply the configuration. We make sure only the more recent SSHv2 is used, not SSHv1 or Telnet. Also, you may have noticed I didn’t apply the ACL above yet, so I’m doing that too now.
switch01(config)#ip ssh version 2
switch01(config)#line vty 0 15
switch01(config-line)#access-class remoteACL in
switch01(config-line)#transport input ssh
Now we can connect using SSH on port 22. The only thing I would still want to change is the port number. Reason for this is that most automated scanning tools and most attempted unauthorized logins to systems are done on standard ports. Cisco published a very interesting white paper about this, really worth the read. Problem is that my switch does not seem to support these commands, despite having a crypto-IOS. It seems this is only for routers. I’m listing the commands anyway:
Router(config)#ip ssh port 2000 rotary 1
Router(config)#line vty 0 4
Router(config-line)#rotary 1
SSH will now listen on port 2000 as well. Mind the ‘as well’: it still listens on port 22. You’ll need to define an extended ACL with port numbers to deny connections on port 22. Alternatively, you can set op a static port translation in your home router, from port 2000 to port 22. This would be much easier, but my ISP’s router does not permit it, so I’m stuck.
Either way, my security has increased now. Before, anybody could log in on my switch using a password they may have captured earlier when I connected using Telnet, which sends everything in clear text. Now, everything is encrypted, and the ACL restricts connections, so it only works from my workplace.
Reggle 