 | |
|
| ||||
|
|
Home | Reviews | Tools | Forums | FAQs | Find Service | ISP News | Maps | About |
|
how-to block ads |
40.0 Security
Cisco Guide to Harden Cisco IOS Devices Recommended Global and Interface Configurations
•Disable all non-essential services and features
Cisco Internet Inbound Access List
Cisco Internet Outbound Access List
Additional Links to Resources
 got feedback?by rolande There is a little discussion of Reflexive Access List, where was considered a sophisticated IOS-based Firewall until CBAC came along. If you wish, you can just skip the Reflexive Access List discussion and go straight to CBAC discussion; since it is recommended to deploy CBAC instead of the "obsolete" Reflexive Access List. Note that with the new Zone-Based Firewall features, Cisco IOS configuration looks similar as ASA 5500 firewall. Therefore now you have option to implement Zone-Based Firewall and IDS/IPS features on your router instead of ACL, CBAC, and IDS/IPS. Please note that some of the features listed may not be supported by your IOS. Ascertain whether your IOS can support the feature that you require or download one from the software upgrade centre at CCO. Also note that this is NOT meant to be a tutorial on network protection but more of an overview on the most common methods of protection. 1. ACL (Access List) Access control lists (ACLs) provide basic filtering capabilities. They can be configured for all routed network protocols (IP, AppleTalk, etc.) to filter the packets of those protocols as the packets pass through a router. ACLs can PREVENT and ALLOW certain traffic from entering or exiting a network. They filter traffic by controlling whether routed packets are forwarded or blocked at the router’s interfaces. Your router examines each packet to determine whether to forward or drop the packet, on the basis of the criteria you specified within the ACLs. Access list criteria could be the source address of the traffic, the destination address of the traffic, the upper-layer protocol (session, presentation or application layer), or other information. Following FAQ utilizes ACL and basic principles of TCP/IP to create simple but quite effective firewall. »Cisco Forum FAQ »Basic Internet Firewall for Routers without IOS image Firewall feature Note that that such firewall is "static" (not flexible) and might not always work in any situation. Reflexive Access Lists Reflexive access lists allow IP packets to be filtered based on session information, which is a layer in the OSI model. The session layer establishes, manages, and terminates communication sessions between presentation layer entities. Communication sessions consist of service requests and service responses that occur between applications located in different network devices. The reflexive access lists are able to filter packets on these request and responses. Reflexive access lists can be used to permit IP traffic for sessions originating from within the local network but to deny IP traffic for sessions that originated outside of the same network. Hence, only if the local network initiated a session or a request, will it be allowed back. When do I configure a reflexive access list? Reflexive access lists are normally configured on border routers, which are routers that stand on the boundary between the internal and external network (internet or another internal network). They are also often routers with the firewall feature set. How does it work? A reflexive access list is activated when a new session is initiated from inside your network, with a packet traveling to the external network. When triggered, the reflexive access list generates a new, temporary entry, which will permit traffic to enter your network if it is part of the session. If the traffic is not part of the session, it will not be permitted to enter your network. For example, if an outbound TCP packet is forwarded outside of your network, and this packet is the first packet of a TCP session, then a new, temporary reflexive access list entry will be created. This entry is added to the reflexive access list, which applies to inbound traffic so the firewall will not block the responding packet. What are the drawbacks of reflexive access lists? Reflexive access lists do not work with some applications that use port numbers that change during a session. For example, if the port numbers for a return packet are different from the originating packet, the return packet will be denied, even if the packet is actually part of the same session. The TCP application of FTP is an example of an application with changing port numbers. With reflexive access lists, if you start an FTP request from within your network, the request will not complete. Instead, you must use Passive FTP when originating requests from within your network. This is where CBAC come to play since the CBAC is considered the more advanced firewall (stateful firewall). 2. CBAC (Context Based Access Control) What is context based access control? Context based access control (CBAC), intelligently filters TCP and UDP packets based on application layer and session layer information. You can configure CBAC to permit specified TCP and UDP traffic through a firewall only when the connection is initiated from within the network you want to protect. CBAC can inspect traffic for sessions that originate from either side of the firewall, and CBAC can be used for intranet, extranet, and Internet perimeters of your network. Without CBAC, traffic filtering is limited to access list implementations that examine packets at the network layer, or at most, the transport layer. However, CBAC examines not only network layer and transport layer information but also examines the application-layer protocol information (such as FTP connection information) to learn about the state of the session. This allows support of protocols that involve multiple channels. Most of the multimedia protocols as well as some other protocols (such as FTP, RPC, and SQL*Net) involve multiple channels. Finding Out Your Internal Private IP Address Even When Behind NAT Box Following is a nice illustration. When your network is behind a NAT/PAT box, then you think that people in the Internet will never know your internal (private) IP address, correct? Wrong! By using Java (HTTP application) people in the Internet are still able to detect and find out your internal IP addresses. Such Java program may be implemented by ISP that do not allow you to NAT/PAT your public Internet address without paying additional fee for each additional PC or machine. The Java program may be also deployed by hackers. Click on this link (and scroll down) to see if this Internet website can reveal your internal private IP address http://www.auditmypc.com/anonymous-surfing.asp Using HTTP option in the CBAC, you can block incoming HTTP traffic (including Java) from unknown or untrusted network. Check out the following thread for detail story. »[HELP] Can't hide internal IP on SOHO 97 How does it work? CBAC inspects traffic that travels through the firewall from the internal network to discover and manage state information for TCP and UDP sessions. This state information is used to create temporary openings in the firewall’s access lists to allow return traffic and additional data connections for permissible sessions. When do I employ CBAC? You can use CBAC when your firewall will be restricting passing traffic consisting of: * Standard TCP and UDP Internet applications * HTTP-based applications including Instant Messaging (i.e. AOL, Yahoo, and MSN IM) * Multimedia applications * Oracle support Please note with the new 12.4 IOS train, more applications are supported. Following is a list that supported under 12.4 IOS train.
CBAC can be used to allow the application’s traffic through the firewall but only when it is initiated from the protected network. CBAC is often configured in one direction on a single interface, which will validate the traffic, ensuring it is part of a valid session. This configuration is employed to protect the local network from the Internet. CBAC can also be used in two directions on one or more interfaces. This method is often employed when networks on both sides of the router needs to be protected. For example, if the firewall is situated between two departments’ networks, CBAC can restrict the traffic of one department’s applications in one direction and restrict traffic in the opposite direction for the other department’s applications. What are the drawbacks of CBAC? "If you don’t ask, you don’t get" is the paradigm here. CBAC does not provide intelligent filtering for ALL protocols. It only works for the protocols that you SPECIFY, hence if a protocol is not specified, the ACL will determine its fate. CBAC is available only for IP protocol traffic. Only TCP and UDP packets are inspected. Other IP traffic, such as ICMP, cannot be inspected with CBAC and should be filtered with basic access lists instead. If you reconfigure your access lists when you configure CBAC, be aware that if your access lists block TFTP traffic into an interface, you will not be able to netboot over that interface. Packets with the firewall as the source or destination address are not inspected by CBAC. CBAC ignores ICMP Unreachable messages. To let specific ICMP traffic to enter, you need to configure the ACL to allow. H.323 V2 and RTSP protocol inspection supports only the following multimedia client-server applications: Cisco IP/TV, RealNetworks RealAudio G2 Player, Apple QuickTime 4. However with there are more application supported when running 12.4 IOS train as shown previously. With FTP, CBAC does not allow third-party connections (three-way FTP transfer). Further; when CBAC inspects FTP traffic, it only allows data channels with the destination port in the range of 1024 to 65535. Also, CBAC will not open a data channel if the FTP client-server authentication fails. Therefore when there is a need to have FTP traffic, create ACL to permit such traffic. CBAC uses less than approximately 600 bytes of memory per connection. There is also a slight amount of additional processing that occurs whenever packets are inspected. Because of the memory and processing usage, you should use CBAC only when your router can handle such work. Sometimes CBAC must evaluate long access lists, which might have presented a negative impact to performance. However, this impact is avoided, because CBAC evaluates access lists using an accelerated method (CBAC hashes access lists and evaluates the hash). CBAC does not protect network attacks initiated from within the local network unless the packets travel through the router that employs CBAC for protection. CBAC can only protect against intrusions/attacks that travel through the router. When you need to protect such network attacks, then you need implement additional security perimeter such as deploy necessary ACL on inside interfaces of the router. Basic logic is that open only necessary ports and protocol; and close others. For the "necessary open" protocol or port guarding, you then need to run IDS/IPS. What is required for me to undertake reflexive access list and context based access control? Reflexive access lists can be configured on most IOS feature sets. CBAC requires the firewall feature set. 3. Zone-Based Firewall The new Zone-Based Firewall is replacing the previous Stateful IOS-Based Firewall (the CBAC). Zone-Based Firewall is pretty much similar to PIX/ASA OS 7.0 firewall configuration. Check out the following links for details. Cisco IOS Zone-Based Policy Firewall Zone-Based Policy Firewall Design and Application Guide Zone-Based Policy Firewall Design Guide Cisco IOS Firewall Q&A Zone-Based Policy Firewall - Introduction and Implementation 4. IDS/IPS (Intrusion Prevention System) There are prerequisites to properly run Cisco IOS IPS on routers * Your router IOS version should be at least 12.3(8)T * Your router IOS feature should be either Advanced Enterprise, Advanced IP Security, or IP Security with IPS * Your router DRAM is at least 128MB * There is Signature Detection File (*.sdf) stored in your router, either in flash memory, PCMCIA inside one of the router's slot, Compact Flash, or similar SDF (Signature Detection File) * SDF is basically a reference point for router to perform the IPS function * The IPS functions available are atomic (IP and TCP inspections), service (HTTP, Mail, etc.) * Detail description on each IPS function is available on the Cisco links below (the SDF and Configuring Cisco IPS) * You have a choice to either create your own SDF or download from Cisco * Should you decide to download from Cisco, you need to have proper Smartnet contract * When you download from Cisco, you can choose either the 128MB.sdf for Basic IPS or the 256MB.sdf for Advanced IPS features * 128MB.sdf requires at least 128MB DRAM and 256MB.sdf requires at least 256MB DRAM * In case your router is 870, 1800, 2800, 3800, or other current router models, there should be the 128MB.sdf already stored on the router's flash memory Note: * Make sure that the router CPU and memory can handle the workload * As illustration, 2610XM router with 256MB DRAM and 48MB Flash can jump from 0-1% normal CPU utilization to 99% CPU utilization when running Advanced 256MB.sdf * For small network environment, the minimal router should be 1841 or similar to properly run Cisco IOS IPS * You can check out the following FAQ to verify your router CPU power »Cisco Forum FAQ »Cisco Equipment Performance (per pps and Mbps) Sample Configuration ip ips sdf location flash:256MB.sdf ip ips name MYIPS ! interface GigabitEthernet0/1 ip address 10.1.1.16 255.255.255.0 ip ips MYIPS in duplex full speed 100 media-type rj45 no negotiation auto Assumption: * There is 256MB.sdf on the router flash memory * The IPS will investigate incoming traffic under such router interface Check out the following link for more info 1. General Info Cisco IOS IPS Supported Signature List in 5.x Signature Format 2. SDF and Configuring Cisco IPS Cisco IOS IPS Configuration Guide SAMPLE CONFIGURATION 1. CBAC Combination Configuration »Cisco Forum FAQ »Sample IOS Firewall (CBAC) router configuration »Cisco Forum FAQ »Sample Configuration of ACL-CBAC-IDS/IPS-IPSec VPN on router 2. Official Cisco IOS IDS/IPS Deployment Guide Cisco IOS IPS Signature Deployment Guide 3. IDS/IPS Configuration in Action Configuring Cisco IOS IPS Using Cisco SDM and CLI 4. More IOS Firewall Sample Configuration Configuration Examples and TechNotes 5. Official Cisco IOS Firewall Design Guide and Sample Implementation Cisco IOS Firewall Design Guide 6. Zone-Based Firewall Sample Configuration »Cisco Forum FAQ »Zone-Based Firewall Sample Configuration This FAQ brought to you by: LoneBandit & Rhodium_uk Disclaimer: The above is a summary of Reflexive Access Lists and CBAC. For more information on the capabilities, limitations and syntax of the commands, please consult the CCO. The authors do not hold any responsibility for any decisions or actions that may arise from this FAQ. This document is not endorsed by CISCO.
got feedback?by Covenant In smaller network environment, pretty much anybody can log into network devices such as routers, switches, and firewalls to make configuration changes. To provide further network access protection, some username and password is stored locally within the network devices. A downside of such localized credential is that there is minimum or no control of such credential integrity. As illustration, someone could just login and changes password without telling others. Then others can no longer login without knowing the new password. The best practice to have more control is to have centralized AAA (Authentication, Authorization, Accounting) server that keeps all usernames and passwords for user login authentication. Further, the AAA server can authorize certain tasks or commands that certain users are able to perform. When such users try to do tasks or issue commands that are unauthorized, those tasks or commands will be rejected. In addition, the AAA server can run report which users are accounted for which tasks or command issues on some network devices. Various Privilege Level and Centralized AAA server Let's say there are network engineers and network analysts as people who have authorized access to routers. The network engineers have full access to routers from issuing show, ping, traceroute commands for troubleshooting; to issuing configure terminal command to configure the routers. The network analysts have partial access to routers. These analysts are only allowed to troubleshoot and are not allowed to configure routers. Only the engineers have such authorization. Typically these network analysts are only allowed to issue show, ping, traceroute commands for troubleshooting. They are not allowed to issue configure terminal command since such command is part of configuration command which only network engineers have privilege of. As you can see, there is a need to have different privilege level between network engineers and network analysts. In AAA world, there is something called Privilege Level 0, 1, 2, all the way up to 15 when somebody (a user) access router or any network device. The Privilege Level 0 is the lowest privilege level a user can have where the Privilege Level 15 is the highest privilege level. On Cisco router, by default a user can only issue simple commands such as show version, ping (not extended ping), and traceroute (not extended traceroute) when such user is authenticated as Privilege Level 0 user. A user can issue full commands when such user is authenticated as Privilege Level 15 user. Using the illustration, let's decide that the network analysts are set as Privilege Level 0 users and the network engineers are set as Privilege Level 15 users Note that on Cisco router, a user can issue commands like show configuration or show running-config when such user is authenticated as Privilege Level 15 user by default. In this case, the network analysts need to issue such commands. To make this possible, there are several approaches you can use. One approach is to define local credential by creating a list of commands on the router itself for Privilege Level 0 users. In this case, the show command set including show configuration and show running-config is within the list. Note that this approach is only feasible as the only platform of network access security and monitoring when there are only handful of routers. Once there are more and more routers, this approach is not scalable. Another approach is to utilize external authentication server such as TACACS+ to keep this list of authorized commands for Privilege Level 0 users. By utilizing such TACACS+ server, there is no need to keep list of commands on the router itself. All authorized commands for any users (including network analyst and network engineers) are centralized within the TACACS+ server database. Therefore regardless of the router quantity, there are minimum to no changes needed when more routers or any network devices are deployed into the network. In typical production network, both local and external authentication server utilization are implemented. The authentication server which stores centralized credentials is used primarily. The local credentials are used as backup in case there is an event where the authentication server is unreachable or non-working. By using this approach, there are several platforms of network access security and monitoring (centralized and local credentials) which from network management perspective is more secure, scalable, and practical. TACACS+ server Management Let's say now there is a centralized TACACS+ server to regulate which commands specific users can issue. Depending of TACACS+ server software capabilities, there are some TACACS+ servers that are unable to keep specific command set. Certain TACACS+ servers are only able to keep a list of command itself without its following parameters. As illustration, some TACACS+ servers are only able to keep show command but not show running-config or show configuration commands. When you have to deal with these kind of TACACS+ servers, there is one approach to provide those show running-config or show configuration commands for Privilege Level 0 users. This one approach is to set those Privilege Level 0 users to have Privilege Level 15. However only handful commands that these users can issue such as show (including show running-config or show configuration), ping (both standard and extended), and traceroute (both standard and extended). When these users try to issue unauthorized command such as configure terminal, the command will be rejected as failed to authorize. This way, you can even have further control of which commands specific users can issue beyond a simple Privilege Level 0 and 15 distinction. You can also configure TACACS+ servers to do further advancement. One is to authorize certain users to have access to only some network devices and to reject access to other network devices. When these users only come from certain IP subnet, then you also can utilize ACL (i.e. access-class command under line vty on Cisco routers) to restrict such access. Another functionality is to grant full Privilege Level 15 to only some network device and to grant partial Privilege Level 15 to other network devices. This is applicable when you have wider network team such as Network Analyst, Network Engineer, and Advanced Network Engineer team; where Network Analysts can only troubleshoot, Network Engineer can troubleshoot and modify configuration on certain network devices only (typically edge network devices), and where Advanced Network Engineers have full access to all network devices. Following is example of implementing such restriction Cisco Secure ACS: Network Access Restrictions with AAA Clients for Users and User Groups Between TACACS+ and RADIUS server Beside TACACS+ server, there is another type of AAA server which is RADIUS server. Typically you implement TACACS+ server for network device access management such as routers, switches, and firewall. To have centralize management of others, you may need RADIUS server instead since RADIUS functionality is more of general purposes. In addition, typically you need TACACS+ server to do AAA (Authentication, Authorization, Accounting) of user credentials, which Privilege Level the user will be as, which command the user can issue on certain network device, and to record all commands such user issues on certain network device. Since RADIUS is more of general purpose AAA server, RADIUS is typically only capable to either permit or deny access of certain network resources, and to record which users have been logging in from specific IP address to which device. Last but not least, TACACS+ is Cisco implementation where it towards to more of network device centralized access management where RADIUS is IETF implementation for general purpose AAA functionality. Check out following discussion for illustration. »Problem in ACS4.1 and user monitoring When to Implement TACACS+ and RADIUS server You may wonder when you should implement TACACS+ and when you should implement RADIUS. One good example is remote VPN management access. In this example you provide IPSec VPN service to users that need to remotely access network resources from anywhere securely. The VPN device you use is PIX Firewall. In general, there are two remote access management concerns. One is the PIX Firewall device management itself and another is the IPSec VPN service management. You basically need to centrally manage who has authorization to modify PIX Firewall configuration, to troubleshoot any connection passing through PIX Firewall, and any related issues. You also need to centrally manage who has authorization to remotely access network resources from anywhere, which network resource that such remote users are authorized to access, and any related issues. TACACS+ technology (with proper AAA command set) is designed to provide greater control of CLI-based appliances. As mentioned previously, you can control which CLI commands (such as show, ping, and traceroute) that specific users can or cannot issue. RADIUS technology (also with proper AAA command set) is pretty much designed to provide general control of CLI- and non-CLI-based appliances. RADIUS technology cannot really control which CLI commands that specific users can or cannot issue on CLI-based command unlike TACACS+ as mentioned previously, however RADIUS can still be able to provide basic and/or general control of some appliance usage and management. You may notice in the above example of remote access using PIX Firewall as the VPN device that the PIX Firewall is CLI-based appliance where other network resources in general are non-CLI-based appliances. Therefore you may want to implement TACACS+ server for the PIX Firewall device management itself (the CLI-based appliance management) and to implement RADIUS server for network resource remote access (the non-CLI-based appliance management). Check out the following FAQ for sample configuration. »Cisco Forum FAQ »Configure PIX/ASA as both Internet Firewall and VPN Concentrator There are other situations when certain network devices or applications only support RADIUS authentication for management such as Cisco MARS. In these situations, then you obviously have no choice but to implement RADIUS authentication instead of TACACS+ one. AAA Command Set Implementation As mentioned previously, there are in general two types of AAA accounts; local and centralized in either TACACS+ or RADIUS server. The local accounts are sets of username and password stored locally within network devices. The centralized accounts are sets of username and password stored in some TACACS+ and/or RADIUS server. In addition, it is also typical practice to define which commands specific accounts or users are able to issue, especially when TACACS+ server is implemented. Similar to the account storage, this list of authorized commands can be either defined locally or centralized within the TACACS+ server. Check out the following FAQ for details. »Cisco Forum FAQ »Securing access to routers with AAA commands »Cisco Forum FAQ »Securing access to switches with AAA commands »Cisco Forum FAQ »Securing access to ASA/PIX Firewall with AAA commands AAA Server Implementation As mentioned, AAA server can act as either TACACS+, RADIUS, or both. For further control and security, it is also common practice to integrate AAA server with external authentication server such as MS Active Directory Domain Controller (Windows Database) and RSA SecurID Token. Using Domain Controller as external authentication of the AAA server, the Domain Controller can be the authentication center when log into either Windows machines or non-Windows machines such as router, switches, and firewall. For network that requires greater control and security, typically electornic token ID server such as RSA SecurID or Vasco DigiPass Token authentication server is used as the authentication center instead of just the Domain Controller or the AAA server alone. This type of electronic token ID authentication involves communication between the Token server and the Token ID itself. This electronic Token ID changes typically every 15 seconds or so. With token authentication, someone needs to log into a machine (Windows or non-Windows) using the regular credential (either the Domain Controller credential, the AAA credential, or both) and the token ID that currently shows on the token display. With this great control, it will be harder for hackers to break into machines. Following is more info on token system RSA SecurID Vasco DigiPass Go Check out the following links for sample implementation. »Cisco Forum FAQ »Are there Free TACACS+ or RADIUS authentication software to secure my router? Implement RSA SecurID Token Authentication within Cisco ACS (AAA) server Some discussions »TACACS+ problems »[Config] user account on cisco router 2611 »[Config] Hhow to configure Cisco IOS for students »IOS and Active Directory intergration using Radius
got feedback?by aryoba
For those Windows administrators that try to integrate these UNIX-based authentication software with Active Directory, you need to run Samba. Check out the following link for sample configuration. FreeRADIUS PEAP Authentication + Cisco AP + Windows XP + Windows AD Authentication This FAQ courtesy of rolande  .
got feedback?by nozero When there are no AAA commands implemented into routers, there must be a password set under the vty line in addition of login command to have the router remotely accessible via (let's say) telnet and ssh. With the proper implementation of AAA command set, the router no longer need password set under the vty line to be telnet or ssh-able. With proper AAA command set implementation, all login attempt from telnet, ssh, http, https, SNMP, console in via either Console or AUX port will be authenticated using the same credential. In addition, implementing AAA command set is more secure approach especially when the router has to authenticate with external TACACS+ or RADIUS server. Note: Check out the following FAQ for more info on TACACS and RADIUS »Cisco Forum FAQ »Secure and Monitor Network Access with AAA (TACACS/RADIUS) and Privilege Level The following AAA commands are applicable not only to routers, but any Cisco gears that are running IOS image (IOS-based gears) such as switches and wireless AP devices. These AAA command set has been tested in various situation; including automatic failover from TACACS+ server to local credential or local enable password during unreachable TACACS+ server situation due to down server or down network. Note that the router (or any IOS-based gears) might need to run IOS image that has Security feature such as IP Base, IP Services, or IP Advanced Services with K9 (Security) to support the AAA command. As mentioned, there will be no need to have passwords under line console, aux, and vty once these AAA command set are in place. All login attempt will be controlled by the AAA command set. If the router happen to have passwords under line console, aux, and vty; these passwords should be removed since the AAA command set will take over all login authentication anyway. In other words, those passwords are no longer in effect once the AAA command set are in place. At first AAA command set to authenticate using local credential only is introduced to provide preliminary understanding. Then external TACACS+ server utilization is introduced to provide greater security perimeter. AAA command set using local credential Sample #1: username [ENTER USERNAME HERE] secret 0 [ENTER YOUR PASSWORD HERE] enable secret 0 [ENTER ENABLE MODE PASSWORD HERE] aaa new-model Behavior Description With this AAA command set, there will be dedicated password for each username. There will be however single enable password that all usernames share to log into enable mode. In other words, password for username and password for enable mode are in general different. When there is only single username defined, password for username and password for enable mode could be set as the same. With either case, this approach is considered insecure since the idea of having "shared password" as the only enable password is unreliable. To login, enter the local username and password. To enter the privilege mode, enter the enable password. Sample #2: username [ENTER USERNAME HERE] secret 0 [ENTER YOUR PASSWORD HERE] enable secret 0 [ENTER ENABLE MODE PASSWORD HERE] aaa new-model aaa authentication login default group local enable aaa authentication enable default enable aaa authorization console aaa authorization exec default local if-authenticated aaa authorization commands 15 default local if-authenticated Behavior Description Similar to previous AAA command set, there will be dedicated password for each username with this AAA command set. You may note that there will be single enable password that all usernames could at one time share to log into enable mode. By default, the shared enable password is not used. Each username has to use its own password to log into enable mode. If for some reason all of defined username is removed along with the password, then you may use the shared enable password to log into enable mode. However this condition may never occur since both username and shared enable password are defined locally. Further, there is no need to enter separate enable password since the user will be granted Privilege Level 15 once correct username and password is entered due to if-authenticated command parameter. Compared to previous sample configuration, this approach is more secure since the shared password in reality may never be used at anytime. With those in mind, note that in general password to login and to enter privilege mode is the same. Therefore you may never use the enable password to enter the privilege mode. AAA command set with external TACACS server Sample #3: username [ENTER USERNAME HERE] secret 0 [ENTER YOUR PASSWORD HERE] enable secret 0 [ENTER ENABLE MODE PASSWORD HERE] tacacs-server host [ENTER TACACS SERVER IP ADDRESS HERE] tacacs-server key 0 [ENTER THE SECRET KEY HERE] aaa new-model aaa authentication login default group tacacs+ local aaa authentication enable default group tacacs+ enable aaa authorization console aaa authorization exec default group tacacs+ local aaa authorization commands 15 default group tacacs+ local aaa accounting exec default start-stop group tacacs+ aaa accounting commands 15 default start-stop group tacacs+ aaa accounting connection default start-stop group tacacs+ Behavior Description Similar to previous AAA command set, there will be dedicated password for each username with this AAA command set. By default, the router uses whatever password the username has as defined in the TACACS+ server database. If for some reason the TACACS+ server is unreachable or unusable, the router uses local credential (local username and associated password) to authenticate users. This approach should be considered most secure compared to the previous two sample configurations since a centralized authentication system (in this case the TACACS+) is in place and is used as primary resource while the local authentication is just for backup. Sample #4: username [ENTER USERNAME HERE] secret 0 [ENTER YOUR PASSWORD HERE] enable secret 0 [ENTER ENABLE MODE PASSWORD HERE] tacacs-server host [ENTER TACACS SERVER IP ADDRESS HERE] tacacs-server key 0 [ENTER THE SECRET KEY HERE] aaa new-model aaa authentication login default group tacacs+ enable aaa authentication enable default group tacacs+ enable aaa authorization console aaa authorization exec default group tacacs+ if-authenticated aaa authorization commands 15 default group tacacs+ if-authenticated aaa accounting exec default start-stop group tacacs+ aaa accounting commands 15 default start-stop group tacacs+ aaa accounting connection default start-stop group tacacs+ Behavior Description Similar to previous AAA command set, there will be dedicated password for each username with this AAA command set. By default, the router uses whatever password the username has as defined in the TACACS+ server database. If for some reason the TACACS+ server is unreachable or unusable, the router uses local credential (only local enable password) to authenticate users. You may note that a user will not be asked for enable password for Privilege Level 15 access (to enter enable mode) unlike previous sample configuration due to if-authenticated command parameter. With this approach, the user will be granted Privilege Level 15 once correct username and password is entered at the first user login. This behavior in some organizations might not be acceptible since those organizations may require separate password between "regular login" and "privileged login", not to mention different behavior compared to the previous sample configuration as will be described later. Setting local account privilege level and authorized command list Referring to this FAQ »Cisco Forum FAQ »Secure and Monitor Network Access with AAA (TACACS/RADIUS) and Privilege Level there is a discussion of setting up certain Privilege Level 15 commands to Privilege Level 0 users. Let's say the following commands are authorized to use for those Privilege Level 0 users in addition to the default Privilege Level 0 authorized command list. traceroute traceroute ip (extended traceroute) ping ping ip (extended ping) show (i.e. show version, show ip route, etc.) show configuration As discussed in the FAQ link, there should be a centralized TACACS+ server to regulate those commands on the list. However in case of down network or unreachable TACACS+ server, those Privilege Level 0 users should still be able to issue those commands. When the TACACS+ server is unreachable from the router perspective, then one way to keep those Privilege Level 0 users be able to issue those commands is to locally define those commands as additional authorized commands for Privilege Level 0 users. To make that happen, following should be on the router configuration in addition to the above AAA command set of your choice. username [ENTER Privilege Level 0 USERNAME HERE] privilege 0 secret 0 [ENTER YOUR PASSWORD HERE] privilege exec level 0 traceroute ip privilege exec level 0 traceroute privilege exec level 0 ping ip privilege exec level 0 ping privilege exec level 0 show configuration privilege exec level 0 show and either one of the following AAA command set Option 1 (suitable when you implement Sample Configuration #2) aaa authorization commands 0 default local if-authenticated Option 2 (suitable when you implement Sample Configuration #3) aaa authorization commands 0 default group tacacs+ local aaa accounting commands 0 default start-stop group tacacs+ Option 3 (suitable when you implement Sample Configuration #4) aaa authorization commands 0 default group tacacs+ if-authenticated aaa accounting commands 0 default start-stop group tacacs+ Some Discussion on Cisco website: How to Assign Privilege Levels with TACACS+ and RADIUS How router behaves with specific AAA command set Referring to this FAQ »Cisco Forum FAQ »Secure and Monitor Network Access with AAA (TACACS/RADIUS) and Privilege Level there is a discussion of how to specify which commands that Privilege Level 0 users can issue eventhough on the TACACS+ server these users are set as Privilege Level 15 users. Let's say there are such Privilege Level 0 users in place. When the router is configured to implement if-authenticated parameter, then the parameter overrides the TACACS+ server command setting. With if-authenticated parameter, Privilege Level 0 users can issue unauthorized command such as configure terminal. Therefore when there is a need to have Privilege Level 0 users that are able to issue certain Privilege Level 15 user commands only, then you might want to implement the AAA command set without the if-authenticated parameter to let the TACACS+ server has the total control. Some discussions »[HELP] TACACS Switch Configuration »AAA Authorization problems on 2811 router »[Config] cisco tacacs »tacacs config issue »[Config] Cisco ACS Shell command authorization sets »AAA Accounting on Routers/Firewalls... »[HELP] Remote Access ...
got feedback?by Covenant »Cisco Forum FAQ »Secure and Monitor Network Access with AAA (TACACS/RADIUS) and Privilege Level Notice If the switches are IOS-based ones, then you can implement AAA command set in the following FAQ since the sets are applicable to any IOS-based Cisco devices including switches. »Cisco Forum FAQ »Securing access to routers with AAA commands When the switches are Catalyst-OS based, then you can implement the following command set that would provide similar effect to the Sample #3 of the FAQ. AAA command set with external TACACS server set password [ENTER LOGIN PASSWORD HERE] set enablepass [ENTER ENABLE PASSWORD HERE] ! #Local User set localuser user [ENTER USERNAME HERE] password [ENTER YOUR PASSWORD HERE] privilege [ENTER PRIVILEGE LEVEL HERE] ! #tacacs+ set tacacs server [ENTER TACACS+ SERVER IP ADDRESS HERE] primary set tacacs key [ENTER TACACS+ SERVER AUTHENTICATING KEY HERE] ! #authentication set authentication login tacacs enable console primary set authentication login tacacs enable telnet primary set authentication login tacacs enable http primary set authentication enable tacacs enable console primary set authentication enable tacacs enable telnet primary set authentication enable tacacs enable http primary ! #authorization set authorization exec enable tacacs+ none console set authorization exec enable tacacs+ none telnet set authorization commands enable enable tacacs+ none console set authorization commands enable enable tacacs+ none telnet ! #accounting set accounting exec enable start-stop tacacs+ set accounting connect enable start-stop tacacs+ set accounting commands enable enable stop-only tacacs+ Notes: * When the TACACS+ server fails or is unreachable, local credential is used as backup. * The sample configuration uses the "telnet" parameter which applies to both telnet and ssh remote access since there is no specific "ssh" parameter
got feedback?by aryoba When there are no AAA commands implemented into routers, there must be a login and enable password set to have the PIX or ASA remotely accessible via telnet. Using more secure remote access method such as ssh is sometimes preferable or even required. Unlike routers that have no requirement of AAA implementation for ssh accessible, PIX or ASA requires such proper AAA implementation. With proper AAA command set implementation, all access attempt via telnet, ssh, http, https, SNMP, console in via Console port will be authenticated using the same credential. Similar to router, PIX or ASA can use either local credential or remote credential stored on external AAA server such as TACACS+ and RADIUS. Using such external servers for authentication are highly recommended to provide more secure approach. Check out the following FAQ for more info on TACACS and RADIUS. »Cisco Forum FAQ »Secure and Monitor Network Access with AAA (TACACS/RADIUS) and Privilege Level These AAA command set has been tested in various situation; including automatic failover from TACACS+ server to local credential or local enable password during unreachable TACACS+ server situation due to down server or down network. At first AAA command set to authenticate using local credential only is introduced to provide preliminary understanding. Then external TACACS+ server utilization is introduced to provide greater security perimeter. PIX Firewall running OS version 6.3 1. Using Local Credential Sample #1: username [ENTER USERNAME HERE] password [ENTER ADMIN PASSWORD HERE] privilege 15 enable password [ENTER ENABLE MODE PASSWORD HERE] aaa-server LOCAL protocol local aaa authentication http console LOCAL aaa authentication telnet console LOCAL aaa authentication ssh console LOCAL Behavior Description With this AAA command set, there will be dedicated password for each username. There will be however single enable password that all usernames share to log into enable mode. In other words, password for username and password for enable mode are in general different. When there is only single username defined, password for username and password for enable mode could be set as the same. With either case, this approach is considered insecure since the idea of having "shared password" as the only enable password is unreliable. To login, enter the local username and password. To enter the privilege mode, enter the enable password. Sample #2: username [ENTER USERNAME HERE] password [ENTER ADMIN PASSWORD HERE] privilege 15 enable password [ENTER ENABLE MODE PASSWORD HERE] aaa-server LOCAL protocol local aaa authentication http console LOCAL aaa authentication telnet console LOCAL aaa authentication ssh console LOCAL aaa authentication enable console LOCAL aaa authorization command LOCAL Behavior Description Similar to previous AAA command set, there will be dedicated password for each username with this AAA command set. You may note that there will be single enable password that all usernames could at one time share to log into enable mode. By default, the shared enable password is not used. Each username has to use its own password to log into enable mode. If for some reason all of defined username is removed along with the password, then you may use the shared enable password to log into enable mode. However this condition may never occur since both username and shared enable password are defined locally. Compared to previous sample configuration, this approach is more secure since the shared password in reality may never be used at anytime. With those in mind, note that in general password to login and to enter privilege mode is the same. Therefore you may never use the enable password to enter the privilege mode. 2. Using External TACACS+ Server Sample #3: username [ENTER USERNAME HERE] password [ENTER ADMIN PASSWORD HERE] privilege 15 enable password [ENTER ENABLE MODE PASSWORD HERE] aaa-server TACACS+ protocol tacacs+ aaa-server TACACS+ max-failed-attempts 3 aaa-server TACACS+ deadtime 10 aaa-server TACACS+ (inside) host [ENTER TACACS+ SERVER IP ADDRESS HERE] [ENTER SECRET KEY HERE] timeout 10 aaa-server LOCAL protocol local aaa authentication http console TACACS+ LOCAL aaa authentication telnet console TACACS+ LOCAL aaa authentication ssh console TACACS+ LOCAL aaa authentication enable console TACACS+ LOCAL aaa authorization command TACACS+ LOCAL Behavior Description Similar to previous AAA command set, there will be dedicated password for each username with this AAA command set. By default, the ASA/PIX Firewall uses whatever password the username has as defined in the TACACS+ server database. If for some reason the TACACS+ server is unreachable or unusable, the ASA/PIX Firewall uses local credential (local username and associated password) to authenticate users. You may note that with this sample configuration, the TACACS+ server is located toward Inside interface from the ASA/PIX Firewall perspective. There can be maximum of three attempts to log into the ASA/PIX Firewall using correct username and password. When user is not entering username or password within ten seconds, the login session will be timed out. This approach should be considered most secure compared to the previous two sample configurations since a centralized authentication system (in this case the TACACS+) is in place and is used as primary resource while the local authentication is just for backup. ASA or PIX Firewall running OS version 7.0 or newer The AAA command set for OS version 6.3 and for OS version 7.0 or newer is pretty much identical as follows. 1. Using Local Credential Sample #4: username [ENTER USERNAME HERE] password [ENTER ADMIN PASSWORD HERE] privilege 15 enable password [ENTER ENABLE MODE PASSWORD HERE] aaa-server LOCAL protocol local aaa authentication http console LOCAL aaa authentication telnet console LOCAL aaa authentication ssh console LOCAL Behavior Description With this AAA command set, there will be dedicated password for each username. There will be however single enable password that all usernames share to log into enable mode. In other words, password for username and password for enable mode are in general different. When there is only single username defined, password for username and password for enable mode could be set as the same. With either case, this approach is considered insecure since the idea of having "shared password" as the only enable password is unreliable. To login, enter the local username and password. To enter the privilege mode, enter the enable password. Sample #5: username [ENTER USERNAME HERE] password [ENTER ADMIN PASSWORD HERE] privilege 15 enable password [ENTER ENABLE MODE PASSWORD HERE] aaa-server LOCAL protocol local aaa authentication http console LOCAL aaa authentication telnet console LOCAL aaa authentication ssh console LOCAL aaa authentication enable console LOCAL aaa authorization command LOCAL Behavior Description Similar to previous AAA command set, there will be dedicated password for each username with this AAA command set. You may note that there will be single enable password that all usernames could at one time share to log into enable mode. By default, the shared enable password is not used. Each username has to use its own password to log into enable mode. If for some reason all of defined username is removed along with the password, then you may use the shared enable password to log into enable mode. However this condition may never occur since both username and shared enable password are defined locally. Compared to previous sample configuration, this approach is more secure since the shared password in reality may never be used at anytime. With those in mind, note that in general password to login and to enter privilege mode is the same. Therefore you may never use the enable password to enter the privilege mode. 2. Using External TACACS+ Server Sample #6: username [ENTER USERNAME HERE] password [ENTER ADMIN PASSWORD HERE] privilege 15 enable password [ENTER ENABLE MODE PASSWORD HERE] aaa-server TACACS+ protocol tacacs+ aaa-server TACACS+ max-failed-attempts 3 aaa-server TACACS+ deadtime 10 aaa-server TACACS+ (inside) host [ENTER TACACS+ SERVER IP ADDRESS HERE] [ENTER SECRET KEY HERE] timeout 10 aaa-server LOCAL protocol local aaa authentication http console TACACS+ LOCAL aaa authentication ssh console TACACS+ LOCAL aaa authentication telnet console TACACS+ LOCAL aaa authentication enable console TACACS+ LOCAL aaa authorization command TACACS+ LOCAL aaa accounting enable console TACACS+ aaa accounting ssh console TACACS+ aaa accounting telnet console TACACS+ aaa accounting command TACACS+ Behavior Description Similar to previous AAA command set, there will be dedicated password for each username with this AAA command set. By default, the ASA/PIX Firewall uses whatever password the username has as defined in the TACACS+ server database. If for some reason the TACACS+ server is unreachable or unusable, the ASA/PIX Firewall uses local credential (local username and associated password) to authenticate users. You may note that with this sample configuration, the TACACS+ server is located toward Inside interface from the ASA/PIX Firewall perspective. There can be maximum of three attempts to log into the ASA/PIX Firewall using correct username and password. When user is not entering username or password within ten seconds, the login session will be timed out. This approach should be considered most secure compared to the previous two sample configurations since a centralized authentication system (in this case the TACACS+) is in place and is used as primary resource while the local authentication is just for backup. FYI, the aaa accounting command set against TACACS+ credential is available starting at OS version 7.0 or newer. With accounting command, the TACACS+ server can keep track of what commands are issued by specific user during specific time. Setting local account privilege level and authorized command list Referring to this FAQ »Cisco Forum FAQ »Secure and Monitor Network Access with AAA (TACACS/RADIUS) and Privilege Level there is a discussion of setting up certain Privilege Level 15 commands to Privilege Level 0 users. Let's say the following commands are authorized to use for those Privilege Level 0 users in addition to the default Privilege Level 0 authorized command list. show arp show interface show ip (i.e. show ip address, show ip audit count) show route show crypto (i.e. show crypto isakmp, show crypto ipsec) show conn show cpu show memory show xlate clear xlate ping As discussed in the FAQ link, there should be a centralized TACACS+ server to regulate those commands on the list. However in case of down network or unreachable TACACS+ server, those Privilege Level 0 users should still be able to issue those commands. When the TACACS+ server is unreachable from the ASA or PIX Firewall perspective, then one way to keep those Privilege Level 0 users be able to issue those commands is to locally define those commands as additional authorized commands for Privilege Level 0 users. To make that happen, following should be on the ASA or PIX Firewall configuration in addition to the above AAA command set of your choice. username [ENTER Privilege Level 0 USERNAME HERE] password [ENTER YOUR PASSWORD HERE] privilege 0 privilege show level 0 command arp privilege show level 0 command interface privilege show level 0 command ip privilege show level 0 command route privilege show level 0 command crypto privilege show level 0 command conn privilege show level 0 command cpu privilege show level 0 command memory privilege show level 0 command xlate privilege clear level 0 command xlate privilege level 0 command ping
got feedback?Really excillent document ... 2009-10-16 07:30:46 by aryoba »Cisco Forum FAQ »Setting Up Private Site-To-Site Connections Introduction IPSec VPN tunnel is one way of setting up private site-to-site connection by utilizing public network (the Internet). Since it is utilizing public network, there would be no need to have dedicated physical circuit to interconnect the sites, hence requiring low cost to setup while maintain private and secure connection. With site-to-site IPSec VPN, there is a IP routing in place to interconnect multiple subnet. This IP routing could be static routing or dynamic routing. In a small network where there is only one path connecting two sites, then static routing should be sufficient. When there are multiple paths connecting two sites, then dynamic routing (i.e. EIGRP, OSPF) and/or load balancing (either per-packet or per-destination) should be used to have optimal connection. Note that IPSec tunneling technology is only able to support static routes and basic IP interconnection. When there are more advance IP interconnections needed; such as running Novell IPX, dynamic routing, and load balancing between the sites; then IPSec tunneling itself is unable to support. For such advance IP interconnections, GRE tunneling is the choice. The downside of GRE tunneling is that GRE tunnel is less-secure tunnel compared to IPSec tunnel. Should you decide to have advance IP interconnection support while maintain secure connection over public network, the workaround is to run GRE over IPSec. IPSec will then be encrypting the GRE tunnel securely and GRE tunnel will be providing the advance IP interconnection support. Some Discussions said by Gramzster: -------------------------------------------------------------------------------- I do have a quick question, When I was looking through the example configurations on the Cisco site, it seemed that GRE was what I wanted to try to configure, since it supported routing protocols. Does this type of IPSEC tunnel also support routing protocols? (basically, what's the difference between a GRE tunnel, and this type of tunnel?) -------------------------------------------------------------------------------- In a nutshell, the VPN tunnel never forwards the routing broadcasts through the tunnels. Neither do they send the routing updates. To send the routing updates (so that the remote location can learn the network on the local side) you must use GRE over IPSec. With this feature, the routing updates are first encapsulated over a new GRE packet and then forwarded through the VPN (IPSec) tunnel. This is useful and required if you are using OSPF, RIP, EIGRP in your internal network and need to build a routing tunnel. -------------------------------------------------------------------------------- Here's some more detail and links/differences between a pure IPSec VPN tunnel and a GRE over IPSec tunnel: Pure IPSec vpn tunnel ===================== In a pure IPSec vpn tunnel, only ip traffic is encrypted/decrypted. If you have non ip traffic, example, ipx, then it is not able to go into the vpn tunnel. OSPF, EIGRP, are not transferred in the tunnel. The url below might be helpful for you about IPSec, An Introduction to IP Security (IPSec) Encryption GRE over IPSec vpn tunnel ========================= In a GRE over IPSec vpn tunnel, the original packet whether ip, ipx, etc... is first going to be GRE encapsulated and then this packet is then subjected to IPSec encapsulation. Therefore, in a GRE over IPSec tunnel, all routing traffic (ip and non ip) can be routed through because when the original packet (ip/non ip) is GRE encapsulated, then it will have an ip header (as defined by the GRE tunnel (normally the tunnel interface ip addresses)) then the IPSec protocol can understand the ip packet and and can therefore be able to encapsulate the GRE packet to make it GRE over IPSec. please visit the urls below for more info., Which VPN Solution is Right for You? How Virtual Private Networks Work -------------------------------------------------------------------------------- Implementation 1. Network Devices that support GRE tunnel terminations Since GRE tunnel involves routing and routing protocols, by nature GRE tunnel is supported by routers and not firewall or IPSec VPN Concentrator. IPSec VPN tunnel on the other hand involves encryption, therefore by nature IPSec VPN tunnel is supported by IPSec VPN Concentrator. In vendor implementation, some firewall and router also support IPSec VPN tunnel creation. On Cisco implementation, Cisco routers use Tunnel interfaces as the GRE tunnel. The procotol used is industry-standard GRE (Protocol 47). You can check out more info about GRE protocol on RFC 2784 As to IPSec VPN tunnel implementation on Cisco devices, there are crypto ipsec and crypto isakmp statements on any commands that relate to IPSec VPN tunnel configuration on either Cisco router, PIX, or ASA. The protocol used is combination of industry-standard ESP (Protocol 50), AH (Protocol 51), UDP port 500 (standard ISAKMP), and UDP port 4500 (non-standard ISAKMP). You can check out more info about those protocols on RFC 2460: ESP, RFC 4302: AH, and RFC 2408: ISAKMP. 2. MTU Size Regardless of IPSec VPN tunnel presence, there is typically a need to adjust MTU size once you consider to implement GRE tunnel within your network since GRE tunnel takes up about 24 bytes. In Ethernet network where MTU size is 1500 bytes, you need to configure the router Ethernet interfaces to have MTU maximum size of 1476 bytes (1500 - 74). Check out the following link for details. Why Can't I Browse the Internet when Using a GRE Tunnel? Illustration Following is a list of sample configurations as illustrations on Cisco implementation of either just IPSec VPN tunnel or GRE over IPSec VPN tunnel. Sample Configurations »Cisco Forum FAQ »Various Site-to-Site IPSec VPN: Cisco, Juniper, Checkpoint, Sonicwall, Zywall »Cisco Forum FAQ »Private Routing over VPN: NAT/PAT, GRE, IPSec Sample Configurations Hope that helps. This FAQ was brought to you by this post http://www.dslreports.com/forum/remark,8108888~root=equip,cis~mode=flat#8176897 by Covenant .
got feedback?by nozero There may times that someone needs to remotely connect to routers, switches, ASA/PIX Firewall, or just any network device that is part of private network via The Internet. Typically the person connects using either telnet or ssh. When the person connects sourcing from previously known or static IP address, then one secure way to provide connection is to lock down the source IP address or subnet within the router, switch, or firewall. Following is an illustration. Let's say the person always connect from Outside (the Internet) of 4.1.53.4 IP address and from Inside (LAN) of 192.168.100.1 IP address. The lock down the source IP address within a router, switch, or any IOS-based devices, the configuration looks like the following. access-list 10 remark Permitted Subnet for Remote Access access-list 10 permit 4.1.53.4 access-list 10 permit 192.168.100.1 ! line vty 0 4 access-class 10 in transport input ssh telnet ! Now let's visit different situation. When the person is unsure of the source IP address but knows the source IP subnet which is 4.1.53.0/24 as the Outside (the Internet) IP subnet and is 192.168.100.0/24 as the Inside (LAN) IP subnet, then the configuration looks like the following to lock down the source IP subnet within a IOS-based device. access-list 10 remark Permited Subnet for Remote Access access-list 10 permit 4.1.53.0 0.0.0.255 access-list 10 permit 192.168.100.0 0.0.0.255 ! line vty 0 4 access-class 10 in transport input ssh telnet ! Some discussions »blocking telnet and http-server access to a port Following is the list of equivalent configurations on ASA/PIX Firewall IP Address ssh 4.1.53.4 255.255.255.255 outside ssh 192.168.100.1 255.255.255.255 inside telnet 192.168.100.1 255.255.255.255 inside IP Subnet ssh 4.1.53.0 255.255.255.0 outside ssh 192.168.100.0 255.255.255.0 inside telnet 192.168.100.0 255.255.255.0 inside Between Telnet and SSH In general, accessing router, firewall, or any network device by SSH is considered more secure than by telnet. In theory, some hackers could tap into telnet session easier than ssh session since telnet uses clear text while SSH uses encryption. Note that in order for those hackers to be able to tap, the hackers must know exactly few things beforehand such as source and destination IP addresses (IP address you use to connect via either telnet or ssh and the network device IP address you connect to), when and how to connect, etc. In reality, it is impractical for hackers to just target random connections from anybody. Therefore, it is arguable that using ssh might not be more secure than telnet in real world. By locking down source IP address such as shown previously, using telnet to remote access network devices should be secure enough at some point. Remote Access Using IPSec VPN Previous illustration showed sample configurations when the source IP address or subnet is known. When neither is known, then different approach is needed. Common way to securely remote connect router or firewall via The Internet is by IPSec VPN. Using specific IPSec VPN Client software, the person connects to a IPSec VPN Concentrator. Once connection is established, the person then can connect to pretty much any network devices within the private network including router and ASA/PIX Firewall via telnet or ssh. You can use either router or ASA/PIX Firewall as the IPSec VPN Concentrator. Following is the list of sample configurations to configure router or ASA/PIX Firewall as the IPSec VPN Concentrator »Cisco Forum FAQ »Configure router as both Internet router and VPN Concentrator »Cisco Forum FAQ »Configure PIX/ASA as both Internet Firewall and VPN Concentrator Is Setting Up IPSec VPN Concentrator Secure Enough? Keep in mind that since you are dealing with real world, there is nothing that is "secure enough". There are always ways to go around the perimeter and to hack into something. The analogy is like securing your house. You can lock and chain doors (even setting up automatic security system) in addition to standard lock and key. Is it secure enough? Maybe. Is it still possible to have burglar entering the house? Yes. But is it then harder to break in? Yes. The above analogy is pretty much showing how network security should be viewed and implemented. The whole idea is to make it harder to be hacked by setting up multiple security layers. In the world of AAA (Authentication, Authorization, and Accounting) such as accessing router or ASA/PIX Firewall remotely from the Internet, following is the list of technologies that can be implemented to have such multiple security layers. * IPSec VPN instead of Windows VPN technology since IPSec VPN is based on more secure specialized protocols * VPN Group Authentication (as shown in above sample configurations) * External AAA server such as TACACS+ and RADIUS (as shown in above sample configurations) * Certified-based and/or RSA-Token-Authentication-based VPN credential for remote access VPN users in addition to the AAA server Following is the list of sample configurations Configuring IPSec Between Cisco IOS Routers and Cisco VPN Client Using Entrust Certificates IPSec Between PIX and Cisco VPN Client Using Smartcard Certificates »Cisco Forum FAQ »Secure and Monitor Network Access with AAA (TACACS/RADIUS) and Privilege Level
got feedback?by Phraxos To increase security, there might be need to intercept (proxy) any typical outbound Internet traffic such as web (http), https/ssl, ftp, IM (Instant Messenger), and Bittorrent (P2P or Peer-to-Peer). One way to setup such interception is to introduce proxy server or similar appliance. Traditionally, such proxy server or appliance is setup as (physical) inline, or bridge mode like the following.
With introduction of WCCP (Web Cache Communication Protocol) technology from Cisco, there is an alternate setup as following which is typically called Transparent mode.
Between WCCP or Bridge Mode As you may notice, bridge mode requires direct physical connection between the Internet and the LAN. In some network topology where there are redundancies of a lot of things (either routing or physical devices), this bridge mode design is undesirable. Therefore typically only small or simple network topology implement bridge mode design. This FAQ discusses WCCP implementation as noted on FAQ title. WCCP Support on Routers and Switches Since WCCP is Cisco technology, typically Cisco routers are needed to redirect the outbound Internet traffic to the proxy server or proxy appliance. When the network has Catalyst 6000/6500 switch MSFC, you can also utilize these MSFC as the WCCP redirect routers. There are some WCCP support on lower-end switches such as Catalyst 4500 and 3550. However, these switches only support ip wccp redirect in command. There is no support of ip wccp redirect out command on those lower-end switches unlike routers or MSFC. This command support is essential in how the WCCP mechanism work on specific network topology, especially those with multiple VLAN or multiple broadcast domains. With ip wccp redirect in command implementation, there might be a complex WCCP design since you need to consider both internal inter-VLAN traffic and outbound Internet traffic. With ip wccp redirect out command implementation, the WCCP design would be much simpler. Sample Configuration On this sample configuration, the proxy appliance used is Blue Coat ProxySG running SGOS firmware version 5.2.4.8. The WCCP redirect device is Cisco router. The network setup is the Dual Firewall and Dual Router/MSFC as either Active/Standby or as Active/Active as shown above. Following is setup list * WCCP version used is version 2 * GRE tunnel is used to deliver the WCCP session between Router 1, Router 2, and the ProxySG appliance; as indicated on the forwarding-type GRE command * ProxySG port 0 (interface 0:0) terminates at Router 1 and ProxySG port 1 (interface 1:0) terminates at Router 2 * The ProxySG has two service group ID, which are 10 and 20 as indicated on the service-group commands. This ID must match with what the Router 1 and Router 2 use, as indicated on the ip wccp commands. * ProxySG Home Router 1 IP address is 192.168.66.1 (Router 1 interface Loopback0 IP address) and ProxySG Home Router 2 IP address is 192.168.66.2 (Router 2 interface Loopback0 IP address) * Intercepted protocol is Protocol number 6 which is TCP as indicated on protocol command * Intercepted ports are 80, 21, 443, 554, 5004, 5005, 1755, and 8554 as indicated on ports command. In other words, the intercepted outbound Internet traffic are TCP port 80 (web), TCP port 21 (FTP), TCP port 443 (https/ssl), TCP port 554 (Real Time Streaming Protocol or RTSP), TCP port 5004 (RTP media data), TCP port 5005 (RTP control protocol), TCP port 1755 (MS streaming), and TCP port 8554 (RTSP Alternate). The objective of the sample configuration is to maintain stable WCCP session between the Router 1, Router 2, and the ProxySG appliance. The key of maintaining a stable WCCP session is to keep the same Home Router IP address for every WCCP session. This way, any WCCP session initiated from Router 1 always use Router 1 as the Home Router. Similarly, any WCCP session initiated from Router 2 always use Router 2 as the Home Router. Blue Coat ProxySG configuration 1. Interface
2. WCCP wccp enable wccp version 2 service-group 20 assignment-type mask mask-scheme destination-ip priority 1 protocol 6 ports 80 80 80 80 80 80 80 80 interface 0:0 interface 1:0 home-router 192.168.66.1 home-router 192.168.66.2 forwarding-type GRE end service-group 10 assignment-type mask mask-scheme destination-ip priority 1 protocol 6 ports 80 21 443 554 5004 5005 1755 8554 interface 0:0 interface 1:0 home-router 192.168.66.1 home-router 192.168.66.2 forwarding-type GRE end 3. Static Routes for Home Router IP Address Reachability 192.168.66.1 255.255.255.255 172.17.101.2 192.168.66.2 255.255.255.255 172.17.102.2 WCCP Router configuration Router 1 ip wccp version 2 ip wccp 10 ip wccp 20 ! interface Loopback0 description Blue Coat ProxySG Home Router 1 ip address 192.168.66.1 255.255.255.255 ! interface FastEthernet0 description Facing Internet Firewall Primary ip address 172.17.0.2 255.255.255.0 ip wccp 10 redirect out ip wccp 20 redirect out ! interface FastEthernet1 description Blue Coat ProxySG interface 0:0 gateway ip address 172.17.101.2 255.255.255.0 ! interface FastEthernet2 description LAN ip address 172.17.5.2 255.255.255.0 ! router rip version 2 network 172.17.0.0 default-information originate no auto-summary ! ip route 0.0.0.0 0.0.0.0 172.17.0.4 name Internet_Firewall_Primary_IP_Address Router 2 ip wccp version 2 ip wccp 10 ip wccp 20 ! interface Loopback0 description Blue Coat ProxySG Home Router 2 ip address 192.168.66.2 255.255.255.255 ! interface FastEthernet0 description Facing Internet Firewall Secondary ip address 172.17.0.3 255.255.255.0 ip wccp 10 redirect out ip wccp 20 redirect out ! interface FastEthernet1 description Blue Coat ProxySG interface 1:0 gateway ip address 172.17.102.2 255.255.255.0 ! interface FastEthernet2 description LAN ip address 172.17.5.3 255.255.255.0 ! router rip version 2 network 172.17.0.0 default-information originate no auto-summary ! ip route 0.0.0.0 0.0.0.0 172.17.0.5 name Internet_Firewall_Secondary_IP_Address Apply WCCP-based Interception Only On Specific Subnet Typically you want all LAN machines or everything behind the Internet firewall to be intercepted by the proxy server or appliance. In some cases, there might be some LAN machines that should not be intercepted or cached by the proxy. You can accomplish the intercept/cache exception through either the proxy server itself or WCCP. When you decide to have the proxy server to do the intercept/cache exception, typically you need to create some kind of intercept/cache policy that contains all machine IP addresses to be intercept/cache excluded while other policy intercepts/caches all other machines. Should you decide to let WCCP to do the intercept/cache exception, you can accomplish it by applying ACL on the ip wccp commands as following. Router 1 ip wccp version 2 ip wccp 10 redirect-list 60 ip wccp 20 redirect-list 60 ! interface Loopback0 description Blue Coat ProxySG Home Router 1 ip address 192.168.66.1 255.255.255.255 ! interface FastEthernet0 description Facing Internet Firewall Primary ip address 172.17.0.2 255.255.255.0 ip wccp 10 redirect out ip wccp 20 redirect out ! interface FastEthernet1 description Blue Coat ProxySG interface 0:0 gateway ip address 172.17.101.2 255.255.255.0 ! interface FastEthernet2 description LAN ip address 172.17.5.2 255.255.255.0 ! router rip version 2 network 172.17.0.0 default-information originate no auto-summary ! ip route 0.0.0.0 0.0.0.0 172.17.0.4 name Internet_Firewall_Primary_IP_Address ! access-list 60 remark WCCP interception/cache exception access-list 60 deny 10.0.0.0 0.255.255.255 access-list 60 permit any In the above sample configuration, all machine IP addresses of 10.x.x.x will be WCCP interception/cache excluded while other machines IP addresses will be intercepted/cached. Further Info ProxySG TechBrief – Implementing WCCP With ProxySG How to Configure a Cache Engine for Reverse-Proxy Caching Using WCCP with Layer 3 GRE Configuring WCCP Layer 2 Redirects on a Cisco Content Engine and Catalyst 6000 Switch WCCP Troubleshooting for Transparent Caching Troubleshooting Reverse Transparent Caching for WCCP
got feedback?Awesome!!! after a day of struggling with a pair of 6509s and a S510 following your guide on using the router identifier IP and explicit routes solved my WCCP woes!
Thanks,
Gav. 2009-06-03 11:40:06 does redirecting outbound have a negative performance impact on the traffic and/or the 6500 switch?
cisco recommends redirecting inbound, however like you mentioned, that can be complex or not feasible in certain environments.
i'd be curious to hear any thoughts, experiences, etc regarding redirecting outbound on a 6500 2011-04-21 18:37:12 by aryoba »Anyone use Cisco IronPort got feedback?by aryoba | ||||||||||||||||
| Wednesday, 23-May 18:29:13 | Terms of Use & Privacy | feedback | contact | Hosting by nac.net - DSL,Hosting & Co-lo over 12.5 years online © 1999-2012 dslreports.com. |
