Cisco Secure Integrated Software
|
|
IOS FW vs. PIX
We tested a router updated to IOS FW to check how it would perform as an
alternative to setting up two devices, a router and a firewall. We used a 1601R
and a 1700 which we upgraded to IOS 12.x that support firewall and IPsec features.
We used release 3.5.1 of the Windows client. The two Ciscos were connected with
a DTE-DCE cross-over cable to simulate serial connections.
Here are the advantages and disadvantages of using IOS FW as opposed to a
dedicated tool like PIX:
Advantages
- Routing and stateful firewalling in a single box
- Single set of commands as opposed to using IOS and PIX OS
- Moving the firewall inside routers allows for easier access by NTT support
teams
- IOS FW is available for a whole range of Cisco routers, so performance
and fault-tolerance can be taken of by choosing a higher-end router if the
customer needs that kind of support
- VPN also available as extra feature of IOS
- Just like PIX, IOS FW can also be configured through GUI-based
applications
- IOS FW can work with third-party tools such as IDS or content filtering
Disadvantages
- By default, IOS FW is "allow all" as opposed to PIX's "block
all", so extra-care is required when deploying IOS FW
- IOS FW requires use of ACLs, CBAC (Context-based access control), Dynamic Access Lists,
and Reflexive Access Lists to achieve the same level of security provided
by full-fledged firewalls
- VPN requires using specific versions of IOS to be compatible with the
VPN client (the latest release, 12.2.10, wouldn't work against the 3.5.1
Windows VPN client, so we had to downgrade to an older release of IOS.)
- Security-conscious customers might prefer to keep routing and firewalling
separate
Tests performed
Setup
Tests were performed with Cisco 1601R, 1720, and 2501. The latter was replaced
in the last test to check VPN tunnelling between two routers.
- Use the 1601R with standard IOS, including ACLs and NAT. Check that
NAT alone does not a firewall make
- Upgrade 1601R to IOS FW (this unit did not have enough RAM to support
FW and IPsec), and check that the configuration settings still work with
no change
- Check that ACLs and NAT allow inside hosts to connect to a web server
sitting on a host on the other end, while access to a web server running
on a host in the private network is granted or disabled through ACLs
- Activate VPN on the 1720, and check that a VPN connection is possible
from a Windows host located in the public network on the remote end
- Replace IOS on the 1601R to a version supporting VPN, and connect it
to a 1720 to achieve VPN tunneling
Issues
Using IOS 12.2.(8)T running on a 1720 and the VPN Client 3.5.2 running on
W2K, I can connect, but cannot PING or access web site from either host. I used
the following sample as seen on Cisco's site:
- aaa new-model
- aaa authentication loging userauthen local //What are userauthen
and groupauthor?
- aaa authorization network groupauthor local
-
- username cisco password 0 cisco
-
- crypto isakmp policy 3 //Link between 3 and 10 below? No md5 hashing?
- encr des //Original sample said 3des, but
we're using a 56-bit/des version of IPsec
- authentication pre-share
- group 2 //What is this for?
-
- crypto isakmp client configuration group 3000client
- key cisco123
- pool ippool
-
- crypto ipsec transform-set myset esp-des esp-sha-hmac
-
- crypto dymamic-map dynmap 10
-
- set transform-set myset
-
- crypto map clientmap client authentication list userauthen
- crypto map clientmap isakmp authorization list groupauthor
- crypto map clientmap client configuration address respond
- crypto map clientmap 10 ipsec-isakmp dynamic dynmap
-
- interface Serial0
- crypto map clientmap
-
- ip local pool ippool 10.1.1.1 10.1.1.254
Clues
- DES?
- NAT?
- Pool of dynamic addresses to be handed to remote VPN client?
- Access-list on VPN router?
- Due to two routers hooked by sharing the same network number instead
of using a specific network just for this P2P connection?
- Any need to set up routes on either or both ends (client or VPN router?)
- Settings in VPN client: "Local LAN Access=Disabled" (remains
although tried to check it out), and "Transparent tunneling: Inactive"?
- On the VPN router, "sh debug" doesn't display anything
- When entering "encr des" and "hash md5" infos in
crypto isakmp policy 3 section, one of them is removed every time, ie. can't
get both infos to stick
- When connected, "ipconfig" and "route print" on
W2K client doesn't show anything related to VPN (dynamic IP address, routes)
- From VPN client, while connected, cannot ping anything besides host
itself, ie. not eth0 on local router, serial0 on remote router, host in
private remote network through its private IP address
Questions
- Split-tunneling: Does it mean sending data either as-is (possibly
through NAT) or encrypted through VPN tunnel depending on remote network
address?
- x-auth?
- wild card?
- (no) mode-config?
- aggressive mode?
Tips
- Host authentication != user authentication
- NAT is an issue: Packets meant to go through the VPN tunnel must not
be NATed as NAT occurs after signing, which causes an error on the other
end when checking packet integrity
- pre-shared key: symetric keys, instead of asymetric, certified public
keys
- A connection occurs in two steps: Phase 1 (ISAKMP SA) is the actual
authentication, while Phase 2 (IPSEC SA) involves sending encryption keys
and setting up data channels
Trying out 1700
- Check if 12.2.10 FW IPsec supports Windows VPN client 3.x
- On default IOS, activate NAT, and check that routing still works
- Upgrade to IOS FW 12.2.10, and check if still OK
- Activate NAT, and check that routing still works
- Install WWW on both computers, and check access:
- Check that internal host can access server on external host
- Check that external host can access internal host if authorized
by ACL
- Check that external host cannot access internal host if banned by
ACL
- DMZ
- Logs
- Different levels available?
- Outsource to remote syslogd? Install syslogd locally if no remote
host available
- Possible to log results of ACL activity to remote syslogd?
- VPN
- Remote windows client host
- Tunnel (router-to-router) if remote VPN-capable router available
Features to check
- NAT (dynamic/static)
- DMZ
- Logs
- IPsec remote users and tunneling
- Differences with Cisco PIX, regular IOS, Check Point Firewall 1
What is IOS FW?
A.k.a. Cisco Secure IS, formerly known as Cisco IOS Firewall. Enhanced version of IOS with firewalling and IPsec
features. It is no different from run-of-the-mill IOS, and it offers additional
features like firewalling and VPN. Note that support for remote VPN users is
edgy (Windows client not compatible with all version of Windows, and will only
connect to such and such versions of IOS FW.) Available for a whole range of Cisco routers (800, 1700, 2600, 3600,
and 7000). Configuration through either CLI or GUI tools: ConfigMaker, CiscoSecure Policy Manager,
Cisco VPN/Security Management Solution (VMS; available for models
1700, 2600, 3600, 7100/7200), Solsoft NP.
IOS FW instead of regular IOS?
Feature |
IOS FW |
IOS |
Network address translation
| Yes
| Yes
|
Stateful packet filtering
| Yes
| No
|
Application-layer access control
|
Yes (CBAC)
|
No?
|
IPsec VPN
| Yes
|
Yes?
|
Dynamic, per-user authentication and authorization for LAN-Based and dial-in communications
| Yes
| Yes?
|
Content filtering
| Yes
| No?
|
GUI-based Management
| Yes
| Yes
|
Redundancy/failover
| Yes (hardware-dependent)
| Yes (hardware-dependent)
|
DMZ
| Yes
| N.A.?
|
Support for multimedia applications
| Yes
| N.A.?
|
Attack detection and prevention
| Yes
| No?
|
Intrusion Detection System (IDS)
| Yes
| No?
|
Radius/Tacacs(+) Centralized Authentication
|
Yes?
|
Yes?
|
URL Filtering
|
No
|
No?
|
QoS
|
Yes
|
Yes?
|
Logs sent to centralized syslog
|
?
|
?
|
NAT Access Default Behavior
|
Allow all
|
Allow All
|
Advantages
- Stateful firewall with static/dynamic NAT and Context-based access control (CBAC)
in addition to ACLs, while regular IOS only offers NAT and ACLs
Disadvantages
- Administrators may be more comfortable working with either a router
or a firewall, but not an appliance that performs tasks in one box
- Higher RAM and CPU requirements, especially if VPN is used in addition
to NAT/firewalling
IOS FW instead of PIX?
Feature
| IOS FW
|
PIX
|
|
|
Network address translation
| Yes
| Yes
|
|
|
Stateful packet filtering
| Yes
| Yes
|
|
|
Application-layer access control
|
Yes (CBAC)
|
No?
|
|
|
IPsec VPN
| Yes
|
Yes
|
|
|
Dynamic, per-user authentication and authorization for LAN-Based and dial-in communications
| Yes
| Yes
|
|
|
Content filtering
| Yes
| Yes
|
|
|
GUI-based Management
| Yes
| Yes
|
|
|
Redundancy/failover
| Yes (hardware-dependent)
| Yes
|
|
|
DMZ
| ?
| Yes
|
|
|
Support for multimedia applications
| Yes
| Yes
|
|
</td> |
Attack detection and prevention
| Yes
| Yes
|
|
|
Intrusion Detection System (IDS)
| Yes
| Yes
|
|
|
Radius/Tacacs(+) Centralized Authentication
|
?
|
Yes
|
|
|
URL Filtering
|
No
|
Yes
|
|
|
QoS
|
Yes
|
?
</TD> |
|
|
Logs sent to centralized syslog
|
?
|
?
|
|
|
NAT Access Default Behavior
|
Allow all
|
Block All
|
|
|
Advantages
- Simplified configuration and maintenance by using one appliance instead of two,
and a single set of instructions. No need to learn PIX's idiosyncracies
Disadvantages
- Lower throughput, especially if used to perform VPN in additino to routing
and firewalling
- No access to some third-party add-ons such as NetPartner's WebSENSE URL management
software
- Security-conscious customers might prefer to separate routing and firewalling
- More configuration required to achieve same protection as PIX (must
use ACLs, CBAC)
- CBAC only handles IP traffic, TCP/UDP. Other traffic like ICMP
is only handled by ACLs. Other restrictions are visible here
IOS FW instead of Check Point Firewall-1?
To be done later.
Configuration
NAT
- For each interface, specify if it resides in the inside or outside network
("ip nat inside/outside")
- Address translation
- Dynamic: define a pool
- Static: specify the public-private address mappings
- PAT: use the overload term to convert all private addresses to a
single public address
Dynamic NAT
- ip nat pool iga 140.16.1.1 140.16.1.253 netmask 255.255.255.0
- ip nat pool ola 192.168.1.1 192.168.1.253 netmask 255.255.255.0
- ip nat inside source list 1 pool iga
- ip nat outside source list 2 pool ola
- access-list 1 permit 10.2.17.0 .255.255.255.0
- access-list 2 permit 10.0.0.0 255.0.0.0
Note: destination translation is also available for load balancing
("the pool should be rotary-type), along with
Static NAT
- ip nat inside source static 10.1.1.10 140.16.1.254
- ip nat outside source static 10.1.1.10 192.168.1.254
Sample
- interface Ethernet0
- ip address 10.0.1.1 255.255.255.0
- no ip directed-broadcast
- ip nat inside
- interface Serial0
- ip address 193.0.0.1 255.255.255.0
- no ip directed-broadcast
- ip nat outside
- encapsulation ppp
- no ip mroute-cache
- clockrate 64000
- ip nat inside source list 1 interface Serial0 overload
- ip classless
- ip route 195.0.0.0 255.255.255.0 193.0.0.2
- access-list 1 permit 10.0.1.0 0.0.0.255
- line con 0
- transport input none
- line vty 0 4
- login
- end
VPN
Router
- aaa new-model
- aaa authentication login userauthen local
- aaa authorization login userauthen local
- aaa authorization network groupauthor local
-
- username cisco password 0 cisco
-
- crypto isakmp policy 3
- encr 3des
- authentication pre-share
- group 2
-
- crypto isakmp client configuration group 3000client
- key cisco123
- dns 1.1.1.1
- wins 1.1.1.2
- domain acme.com
- pool ippool
-
- crypto ipsec transform-set myset esp-3des esp-sha-hmac
-
- crypto dynamic-map dynmap 10
- set transform-set myset
-
- crypto map clientmap client authentication list userauthen
- crypto map clientmap isakmp authorization list groupauthor
- crypto map clientmap client configuration address respond
- crypto map clientmap 10 ipsec-isakmp dynamic dynmap
- interface ethernet0
- ip address 1.1.1.1 255.255.255.0
- crypto map clientmap
- ip local loop ippool 1.1.1.50 1.1.1.55
Windows Client
Available for download by registered users at http://www.cisco.com/cgi-bin/software/crypto/crypto_main.pl
Documentation says the VPN client can only connect to routers running IOS
12.1(1)T, 12.1(2)T, or above. We found that running IOS 12.2.10 didn't work,
and had to downgrade to 10.2.8T.
Lock-and-key (Dynamic Access Lists)
When lock-and-key is configured, designated users whose IP traffic is normally
blocked at a router can gain temporary access through the router. When triggered,
lock-and-key reconfigures the interface's existing IP access list to permit
designated users to reach their designated host(s). Afterwards, lock-and-key
reconfigures the interface back to its original state.
IP Session Filtering (Reflexive Access Lists)
Reflexive access lists have significant differences from other types of access
lists. Reflexive access lists contain only temporary entries; these entries
are automatically created when a new IP session begins (for example, with an
outbound packet), and the entries are removed when the session ends. Reflexive
access lists are not themselves applied directly to an interface, but are "nested"
within an extended named IP access list that is applied to the interface.
CBAC
Context-based access control is used in addition to ACLs. Traffic blocked
by the access list is not inspected by CBAC. 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 TCP or UDP session. Remember that protocols unknown to CBAC will only be
handled by ALCs.
The general format to create a ruleset is:
ip inspect name inspection-name protocol, where inspection-name
is a name given to this ruleset, and protocol is a specific protocol
you wish to allow or deny through the firewall, eg. ftp, realaudio, etc.
To apply a ruleset to a given interface, enter configuration mode for this
interface, and type:
To view a given ruleset: show ip inspect name
To view the complete CBAC configuration: show ip inspect config
To disable CBAC, run the global command no ip inspect
The audit-trail command enables the delivery of specific CBAC messages through
the syslog notification process.
ip inspect audit-trail
Establish the time-out values for DNS queries. When this idle-timer expires,
the dynamic ACL entries that were created to permit the reply to a DNS
request will be removed and any subsequent packets will be denied.
ip inspect dns-timeout 10
Examples to create a rule:
- ip inspect name inspect1 smtp timeout 300
- ip inspect name inspect1 udp timeout 300
- ip inspect name inspect1 tcp timeout 300
-
- interface Ethernet0/0
- description HR_Server Ethernet
- ip address 172.16.110.1 255.255.255.0
- ip access-group 110 out //ACL
- no ip directed-broadcast
- no ip proxy-arp
- ip inspect inspect1 out
- no cdp enable
- no ip forward-protocol udp netbios-ns
- no ip forward-protocol udp netbios-dgm
- no ip forward-protocol udp tacacs
- no ip forward-protocol udp tftp
- logging 192.168.55.131
- snmp-server community <elided> ro 13
- tacacs-server host 192.168.55.2
- tacacs-server key <elided>
Sample
- ip inspect name test cuseeme timeout 30
- ip inspect name test ftp timeout 30
- ip inspect name test h323 timeout 30
- ip inspect name test realaudio timeout 30
- ip inspect name test rpc program-number 100000
- ip inspect name test streamworks timeout 30
- ip inspect name test vdolive timeout 30
-
- access-list 105 deny TCP any any
- access-list 105 deny UDP any any
- access-list 105 permit icmp any any echo-reply
- access-list 105 permit icmp any 192.168.1.0 0.0.0.255 time-exceeded
- access-list 105 permit icmp any 192.168.1.0 0.0.0.255 packet-too-big
- access-list 105 permit icmp any 192.168.1.0 0.0.0.255 traceroute
- access-list 105 permit icmp any 192.168.1.0 0.0.0.255 unreachable
- access-list 105 deny ip any any
-
- interface Ethernet0
- ip address 10.0.1.1 255.255.255.0
- ip access-group 105 in
- ip inspect test out
- no ip directed-broadcast
- no shutdown
-
- interface Serial0
- ip address 192.168.0.253 255.255.255.252
- no ip directed-broadcast
- encapsulation ppp
- clockrate 64000
-
- ip classless
- ip route 10.0.0.0 255.255.255.0 192.168.0.254
-
- line con 0
- transport input none
- line vty 0 4
- login
Troubleshooting
Commands
NAT
- To show static xlation: sh ip nat translation
- To remove all static xlations: clear ip nat translation *
- To remove a static xlation: clear ip nat translation <global-ip>
- To view NAT statistics:
clear ip nat statistics
show ip nat statistics
- To view logs: show log
- debug ip nat
- debug ip packet
VPN
- debug crypto engine - Display debug messages about crypto engines, which
perform encryption and decryption
- debug crypto isakmp - Display messages about IKE events
- debug crypto ipsec - Display IPSec events
- show crypto isakmp sa - View all current IKE security associations (SAs)
at a peer
- show crypto ipsec sa - View the settings used by current security associations
- clear crypto isakmp - Clear all active IKE connections
- clear crypto sa - Delete all IPSec security associations
VPN Client
- The VPN Client 3.x will work with Windows 2000 and all Cisco VPN
devices (PIX, VPN concentrators etc) excpet for routers. This will
be fixed apparently in IOS 12.2.7T which is slated for release sometime
in the first half of 2002. Since the current IOS is 12.2.6 I gues we are
not far off now.
Questions
Even with ACLs, I can't stop foreign hosts from accessing
internal hosts
Could it be that linking a "access-list" line
with a "ip nat inside source list" is not what it looks like, ie.
this is used just as a way to limit which internal hosts/networks are allowed
to use NAT when connecting to the outside network? -> try to add access-group
statements to the external interface
When not using the NAT/firewalling commands, does
IOS FW act like regular IOS?
Does IOS FW support DMZ if extra ethernet port available?
How does logging compare between IOS FW and PIX?
Any restriction for VPN when using NAT/firewalling
<font color="#FF3300">How does VPN compare on IOS FW and regular IOS (road
warrior, site-to-site tunnelling connection)
Waiting for 1700 because 1601R doesn't have enough
RAM to run IOS 12.2.x which is needed to use the Windows 3.x client currently
available from Cisco.
Why deploy firewalls at customer's premises
instead of NTT premises?
Currently, little demand from customers.
On IOS FW, by default, is a host accessible
when using static mapping
ie. must protect host with ACLs?
When NAT/firewalling is set up on IOS FW, what's
the point of using ACLs?
Is IOS FW with NAT/firewalling "connect
by default" or "block by default"?
On which type of Cisco HW do we intend to run
IOS FW?
As smaller appliances like the 1600/1700 may
not be as reliable as the more expensive models, we might want to deploy IOS
FW on higher-end routers to avoid losing money by having to send personel to
replace faulty routers running IOS FW.
With NAT and ACLs available on IOS, why bother
with firewalls at all (either IOS FW or PIX)?
Stateful firewall and context-based access control
are only available on firewall-capable devices.
Is NTT currently using VPN on routers, or stand-alone
VPN appliances?
Yes.
Resources