1. Pare-feu Key things to talk about. Standards Update .A .G .N
Detailed Product Overview
IOS versions etc..
Bridges

2. Critères d'architecture & de choix de pare-feu
Objectifs généraux de sécurité
Applique avec rigueur la stratégie de base du réseau à la périphérie du WAN et du site
Flux de trafic entrants et sortants
De/vers qui, les services, etc.
Site-WAN 1.0 Critères d'intégration et de sélection de pare-feu
Périphérie du WAN privé
Site
WAN Privé  
Transcript:
The firewall design, as I mentioned in the overview session, what we're doing in Phase 1.0 is just some basic network policy enforcements on the network boundaries, so the WAN Edge and the Branch Edge. In the WAN Edge, we're doing IOS firewall in ASR and I'll talk more about actually what that looks like in a moment. And we're similarly doing IOS firewall in the ASR on the typical branch and then the high-performance branch to reinforce the separation of NetOps/SecOps domains, we're using an ASA appliance. That's also relevant for the non-US models where the ASR maybe at the managed and down.
QFP

3. Places in the Network Integrated Adaptive Collaborative
Cisco Integrated Services Routers
Cisco ASA Adaptive Security Appliance
Cisco Intrusion Prevention Systems
Cisco Security Manager
Cisco Security MARS
Cisco Security Agent
Cisco NAC Appliance
Endpoint Security Policy and Posture
Detect and Mitigate Content Security Threats
Centralized Security Management
Internet
Targeted Attack Protection
Encrypted Secure Communications
Public WAN
Integrated
Anomaly detection with in-production learning
Network behavioral analysis
Visibility and mitigation capabilities for blended content-based threats
Real-time security posture adjustment
Adaptive
Cross-solution feedback linkages
Common policy management
Endpoint posture and security policy enforcement
Passive and active fingerprinting
Cisco Security Agent IPS collaboration
Collaborative
Multivector protections at all points in the network and at desktop and server endpoints
Branch infrastructure security that enables end-to-end architecture

4. Stateful Inspection Firewalls - Advantages
Examines multiple levels
Very secure
Robust logging
Transparent
Maintains State
High performance
Internet
Permit traffic?
State Table
Existing
connection? ü
Today, most firewalls implement a smarter form of packet filtering known as stateful inspection. It listens to all communications and stores these conversations in memory, so that responses are returned on expected ports from expected IP addresses. Ports are opened only if the firewall determines these packets are part of an internal originating request. If the packet matches a conversation stored in firewall memory, it passes through. When the conversation is completed, the port closes. If a packet is returned without the expected response, the packet is dropped.
More importantly, stateful inspection technologies maintain `state' data, information about past packets. Stateful inspection only needs to compare the first packet in a connection to the rule set, and if the packet is permitted, adds information, the state, to an internal database. This state information permits subsequent packets in that connection to pass quickly through the firewall.
If the rule set for a type of service requires examining application data, then part of each packet must still be examined. As an example, a firewall can react to seeing an FTP PORT command by creating a dynamic rule permitting a connection back from the FTP server.
Logging, or authentication as required by the rule set, occurs at the application layer (OSI layer 7). Although the opportunity for better logging is present, stateful inspection firewalls typically only log the source and destination IP addresses and ports, similar to logging with a router.
Web Server PC
End User

5. Example Flow Flow Interfaces Packet Flow
SRC IP: SRC Port: Protocol: TCP
DST IP: DST Port: 80
Interfaces
Source: Inside Destination: Outside
Client:
Servers
With the Flow Defined, Examination of Configuration Issues Boils Down to Just the Two Interfaces: Inside and Outside
Packet Flow
Inside
DMZ
Eng
Accounting
Partner
Hosting
Outside
Server: 5

6. Stateful Firewall Packet Flow
Packet Arrives
Check Permissions: ACLs / Authentication
Addressing: NAT / PAT / Static
Create XLATE Object (addressing info)
Enter into Connections Table (ports + proto + flags + random seqNum)
To configure the PIX several things have to be done. After the packet arrival the PIX will make some checks on this packet:
1. The addressing has to be configured. The PIX has no global knowledge of addressing space, but it keeps the addressing information on all interfaces separate. This means that an address mapping between interfaces has to be configured, even if this is a static mapping. So either the nat or the static commands have to be used to define how addresses are mapped between interfaces. Note that destination NAT (alias) is optional, but source addresses need to be defined.
2. The permissions have to allow the packet through the firewall (unless it is allowed by default, see earlier slide). For this the conduit, outbound commands or access lists can be used.
If both of these requirements are met and the packet is permitted, an entry will be created in the translation table (xlate). This table specifies the address mapping between interfaces. And for each connection between the hosts of an xlate entry there will be one or more entries in the connections table. See following slides.

7. Stateful Firewall Provides “stateful” connection security
Tracks source and destination ports and addresses, TCP sequences, and additional TCP flags
TCP sequence numbers are randomized
Tracks UDP and TCP session state
Connections allowed out—allows return session back flow (TCP ACK bit)
Supports authentication, authorization, syslog accounting

8. Stateful Firewall Basic Rules
Allow TCP / UDP from inside
Permit TCP / UDP return packets
Drop and log connections from outside
Drop and log source routed IP packets
Deny ICMP packet
Drop and log all other packets from outside

9. Firewall Security Levels
Public Network
nameif ethernet0 outside security0 50
Firewall
DMZ
100
To make the configuration of the PIX easier and thus more secure, each interface carries in addition to the security level a name. The configuration is then based on the interface name rather than a number or designation like “e1”, to make configuration errors less likely. Commands refer thus direclty to “inside” and “outside”, which makes the configuration intuitive.
It is important to understand that the PIX does not have a global notion of the address space. This means that the same address space can be used on various interfaces, with address translation in between. This has as a consequence that for most commands an interface needs to be specified. For example a ping done on a PIX also needs to specify the interface since the target IP address can in theory be on either side of the PIX.
nameif ethernet1 inside security100
nameif ethernet2 DMZ security50
Private Network

10. The Default Rules Higher to Lower: PERMIT Lower to Higher: DENY
Public Network
Default Actions:
Higher to Lower: PERMIT
Lower to Higher: DENY
Between Same: DENY 50
DMZ
100
Note that there can only be one outside and inside interface (security level 0 and 100 respectively). Other security levels can be used more than once.
The Adaptive Security Algorithm™ (ASA) works on the level of the interface: Connections from a lower to a higher level are by default denied, from a higher to a lower level are by default permitted. Between the same security level connections are by default denied.
This makes the default mode of the PIX very secure, meaning that even without a configuration at start-up time the PIX is already secure. See the section on the ASA for more details.
Private Network

11. Only 3 Ways through the Firewall1:
inside to outside;
(Limit with ACL) 2:
user authentication
AAA
Public Network
out side
in side
As opposed to a router, the PIX does not by default forward packets. In fact there is only a small number of defined ways packets can traverse the PIX. Other ways are by default denied. These ways are:
1. Inside to Outside: If a user from the inside starts a connection to the outside (or to be more precise, to an interface with a lower security level), this connection will by default be permitted, and the return packets of this connection too. This can be limited with the “outbound” and “apply” commands.
2. User Authentication: This is the cut-through proxy feature that will be treated in more detail later in the presentation. Typically used from a lower security level to a higher one. Interaction with a AAA server is used for authentication.
3. Conduit: This is a kind of tunnel to allow outside users to access inside resources without defining the outside. Typical application is giving access to a web server to the Internet.
Since version 5.0 there is an additional way through the PIX, namely access lists. The functionality is similar to conduits. The reason that this command has been added is IPSec, it does on this level strictly speaking not add functionality, but only in conjunction with IPSec, where access lists are used to define traffic to be secured by IPSec. 3:
Access List
(outside to inside)
Private Network

12. NAT Key things to talk about. Standards Update .A .G .N
Detailed Product Overview
IOS versions etc..
Bridges

13. NAT Example Inside Outside Internet Inside Local IP Address
Source Addr
Inside
Outside
Destination Addr
Source Addr
Destination Addr
Source Port
Source Port
Destination Port 23
Destination Port 23
Internet
Inside Local IP Address
Global IP Pool
Translation table

14. IOS Firewall Key things to talk about. Standards Update .A .G .N
Detailed Product Overview
IOS versions etc..
Bridges

15. Zone-Based Policy Firewall (ZFW)
Introduced in Cisco IOS 12.4(6)T
ZFW is the strategic solution going forward
Interfaces assigned to zones and inter-zone polices control access between zones
Similar in concept to security levels on ASA/PIX
Uses Class-Based Policy Language (CPL)
Cisco Classic Firewall (CBAC)
Introduced in Cisco IOS 12.0
Cisco IOS Software Classic Firewall will be maintained in the future but will not significantly enhanced with new features

16. Zone-Based Policy Firewall (ZFW)
Features
Combines features of ACLs, CBAC, NBAR into one policy
Additional protocol support for deep packet inspection e.g. IM, IMAP and P2P application
More actions – inspect, drop, pass and police
Inspection action allows TCP Intercept like functionality e.g. max session limits, idle times, flood protection
Traffic to or initiated from the router allowed by default
Traffic between zones denied by default

17. Zone-Based Policy Firewall (ZFW)
Sample Config – Basic Setup, 2 interfaces
class-map type inspect match-any private-allowed-class
match protocol tcp
match protocol udp
match protocol icmp
class-map type inspect match-all http-class
match protocol http !
policy-map type inspect private-allowed-policy
class type inspect http-class
inspect my-parameters
class type inspect private-allowed-class
inspect
zone security private
zone security public
zone-pair security priv-pub source private destination public
service-policy type inspect private-allowed-policy
interface fastethernet 0
zone-member security public
Interface VLAN 1
zone-member security private

18. IOS ZBFW Design: Typical Branch
Private WAN
VPN Zone
Infrastructure Zone
VPN
Transcript:
So, in both cases, we're using the zone-based firewall implementation. If you're familiar with the IOS firewall, that's what they call the classic firewall and the zone-based firewall. Zone-based firewall is the method that's going to be used moving forward, and so that is the approach that you should be taking when implementing firewall in an IOS now. It's not currently supported in (inaudible) and is planned for 3.3, which is coming up in the next few months. So just something to bear in mind as an interim. Try to show you very simply the concept so we really need to start by looking at the security policy in identifying zones which will allow you to have four different levels of policy. So, the model that we've chosen is since we're doing centralized policy enforcement, if you remember, all of the traffic is going back to the corporate site. There is no local access on the branches. So, in order to do that enforcement, that with the zoning on the IOS firewall, we're able to say that all the client traffic has to go through the PIN, there is no local Internet access. And vice versa, the Internet and the WAN connections are not allowed to access our branches. That's probably one of the most simplest things, and another thing we will be able to do as well was to have an infrastructure zone. Again, one specific policy so that the clients can't actually access our infrastructure -- it's again about protecting that. Obviously allowing our infrastructure to access the client, so that we can do troubleshooting and identifying problems.
Internet
WAN Zone
Client Zone
No CSM support for ZBFW planned till 3.3

19. IOS ZBFW Design: Private WAN Edge
SP1
VPN Zone
Private WAN Edge
VPN
Transcript:
Similarly, if we look at the same concepts on the private WAN Edge, obviously, we don't have any clients. So, it's a much simpler model, but basically you're enforcing the same thing -- centralized policy enforcements. All the corporate access is going out through the Internet Edge, so there is no access out into the WAN links on the private WAN Edge. It's all for the VPN's at the branches and that is the only traffic that is allowed, and then obviously enforcing all traffic coming from the VPN that branches out to the corporate network.
QFP
Private WAN SP2
WAN Edge Zone
WAN Zone

20. Cut-through Proxy Key things to talk about. Standards Update .A .G .N
Detailed Product Overview
IOS versions etc..
Bridges

21. Cut-Through Proxy Operation
1. User makes a request to an IS resource
2. Firewall intercepts connection
Internal/
External
User
3. Firewall prompts user for username and password, authenticates user and checks security policy on RADIUS or TACACS+ server 3.
PIX Firewall
Username and Password Required
Enter username for CCO at
User Name:
Password: OK
Cancel
student
IS Resource
Cisco Secure
4. Firewall initiates connection from Firewall to the destination IS resource
5. Firewall directly connects internal/external user to IS resource
Authenticates once at the application layer (OSI Layer 7) for each supported service
Connection is passed back to the firewall engine, while maintaining session state

22. 100% Transparent
No proxy configuration required

23. User Authentication: Cut-Through-Proxy
Addressing and ACL must Exist!
FTP, HTTP, Telnet can be proxied
Other ports can be authorised after authentication
Watch Out: Timeout for authorisation! -> Other connections will be cut after primary timed out
As with all features on the PIX, addressing and permissions must exist before the user authentication can happen.
There are three protocols that can be proxy authenticated: HTTP, FTP, and telnet. (These are the standard protocols that have an authentication mechanism buit in.) Other protocols can be authorised to traverse the PIX from this authenticated user.
Note: If one of the three proxy protocols are used to authorise further protocols, and whilst some other protocol is being used a timeout for the authentication occurs, the user has to re-authenticate with one of the three main protocols (HTTP, FTP or telnet).