Packet Flow in Palo Alto Firewall

April 2, 2018 | Author: AshwaniPatel | Category: Ip Address, Transmission Control Protocol, Firewall (Computing), Internet Protocols, I Pv6


Comments



Description

PAN-OS: Day in the life of a packetPacket flow sequence in PAN-OS October 2010 Palo Alto Networks 232 E. Java Dr. Sunnyvale, CA 94089 408.738.7700 www.paloaltonetworks.com ............................................................................................................. 10  Application Identification.......... 8  TCP state check ........................................ 8  Tap ............................................................................................................................................................. 3  Packet Parsing........................................................................... 8  Virtual Wire.................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................. 9  Firewall session fast path .................................................................................................................. 8  NAT policy lookup.................. 8  Layer 2 ........................................................................................................................... 6  Flood and per-packet anomaly detection .......... 8  Layer 3 ....................................................................................................................... 8  Forwarding action................................................................................... 9  Session allocation................................................................................................... 3  Ingress Stage ..................................................................................................................................................................... 10  Summary ..............................................Table of Contents Overview ....... 5  Tunnel decapsulation ................................................. 8  Interface Mode .............................................................................................................. 11  © 2010 Palo Alto Networks Page 2 .................................................................... 9  User ID.................................................................................................................................................................................................................................................................. 8  Forwarding setup .................................................................................................................................................................................................................................................................................................................... 9  Security policy lookup .................................. Ingress Stage Ingress stage receives packet from the network interface. The ingress and forwarding/egress stages handles network functionalities to make packet forwarding decisions on per packet basis. The rest of stages are flow-based security modules highlighted by App-ID and Content-ID. parses the packet and determines whether the given packet is subject to firewalling. a packet may be discarded because of protocol violation. or from a tunneling application to tunneled application.Overview This document describes the packet handling sequence inside of PAN-OS device. In certain cases which are considered firewall attack prevention features the packet maybe discarded without configurable options because those packets will eventually be discarded by the end hosts. and flexibility of deployment topologies. Security policies are always evaluated whenever there is an application change either from unknown to a known one. If the packet is subject to firewalling then continue with firewall session lookup and enter security processing stage. This decoupling offers stateful security functions at application layer. Note: During packet processing. and the resiliency of per-packet forwarding. © 2010 Palo Alto Networks Page 3 . otherwise forward the packet. © 2010 Palo Alto Networks Page 4 . • port zero • invalid combination of TCP flags UDP: The packet is discarded if • UDP header truncated. • truncated extension header Layer 4: TCP: The packet is discarded if • TCP header is truncated. Layer3: The IP header is parsed. 802. and • UDP buffer length less than UDP length field) • Checksum error © 2010 Palo Alto Networks Page 5 . Layer2: The ingress-port.1q tag. • UDP payload truncated (not IP fragment. • truncated IP packet (IP payload buffer length less than IP payload field). • truncated IPv6 header. IPv4: A packet can discarded for any one of the following reasons • Mismatch of Ethernet type and IP version • Truncated IP header • IP protocol number 0 • TTL zero • Land attack • Ping of death • Maritain IP address IPv6: A packet can discarded for any one of the following reasons • mismatch of Ethernet type and IP version. If interface is not found the packet is discarded.Packet Parsing Packet parsing starts with layer2 header of the packet received from interface. destination MAC address is used as key to lookup ingress logical interface. • JumboGram extension (RFC 2675). • data-offset field is less than 5 • Checksum error. The hardware interface counter "receive error" and global counter “flow_rcv_dot1q_tag_err” are incremented. IP Defragmentation IP fragments will be parsed. i. The table below summarizes the packet processing behavior for a given interface operation mode and packet type. then the following sequence is executed: • packet will be decapsulated first.Tunnel Decapsulation Tunnel decapsulation/decryption is also performed at the parsing stage. then packet will be fed back to parsing process. • the tunnel interface associated with the tunnel will be assigned to packet as new ingress interface. A fragment may be discarded due to tear-drop attack (overlapping fragments). SSL-VPN with SSL transport. thus packet parsing (for tunneled packet) starts with IP header. starting with packet header defined by tunnel type. IPSec. Interface Operational Mode Virtual wires Packet type Layer3 IPv4 unicast Inspect and forward Inspect and forward IP limited broadcast drop IP directed broadcast drop Layer 2 Multicast firewalling on IPv6firewalling on Tap Inspect and forward Inspect and forward Inspect and forward Inspect and drop forward ( flood) forward Inspect and forward forward drop forward ( flood) forward Inspect and forward forward drop Default © 2010 Palo Alto Networks Page 6 . Firewall Session Lookup A packet is subject to firewall processing depending on the packet type and the interface mode. Currently all supported tunnel types are IP layer tunneling. discarded if any error. be reassembled by defragmentation process and fed back to the parser starting with IP header. if the packet is determined that it matches tunnel.e. After parsing. • Source and destination addresses: IP addresses from the IP packet. ICMP identifier and sequence numbers are used. • Protocol: The IP protocol number from the IP header is used to derive the flow key • Security zone: This field is derived from the ingress interface at which a packet arrives. for IPSec SPI is used to identify the flow and GRE call ID is used for PPTP. where all client-to-server packets should contains same key as that of C2S flow. In PAN-OS implementation a flow is uniquely identified using a 6-tuple key. Active flows are stored in the flow lookup table. flow lookup is performed on the packet. different field from protocols are used. the 6-tuple flow key is extracted from the packet and flow lookup is performed to match the packet with an existing flow.Interface Operational Mode Virtual wires Packet type Layer3 Martian address drop drop drop IPv6 drop forward Non-IP process if applicable forward Layer 2 IPv6firewalling on Tap drop drop drop forward Inspect if IPv6 firewalling is on Inspect and forward drop forward forward forward drop Default Multicast firewalling on If the packet is subject to firewall inspection. © 2010 Palo Alto Networks Page 7 . and server is receiver of this very first packet. • Source and destination ports: Port numbers from TCP/UDP protocol headers. When a packet is determined to be eligible for firewall inspection. Note: The distinction of client and server is from the firewalls point of view and may or may not be the same from the end hosts point of view. For non-TCP/UDP. A firewall session consists of two unidirectional flows each uniquely identified by 6-tuple key. and so on for S2C flow. Each flow has a client and server component. where client is sender of the first packet of the session from firewall perspective. For ICMP. Based on above definition of client and server there will be a client-to-server (C2S) and server-toclient (S2C) flow . The table below summarizes packet forwarding behavior. • • Note: I. II. Forwarding setup This stage determines packet forwarding path.Firewall Session Setup The following steps are taken to setup a firewall session Flood and per-packet anomaly detection Once the packet arrives on a firewall interface. the ingress interface information is used to determine the ingress zone. If the information is not present the frame is flooded to all interface except the ingress interface in the VLAN Layer 3 Route table lookup is used to determine the next hop © 2010 Palo Alto Networks Page 8 . Interface Mode Forwarding action Tap Egress interface/zone is the same ingress interface/zone. If there are any zone protection profiles configured for that zone. Even though this is not a recommended setting. Packet forwarding depends on the way firewall interface is configured. the packet is subject to evaluation as configured in the zone protection profile. it treats the packet as non-SYN and discards the packet. SYN cookie implementation works as follows: • The seed to encode cookie is generated each time dataplane boots up via random number generator If an ACK packet received from the client does not match cookie encoding. The firewall can be configured to allow the first TCP packet even if it does not have SYN bit set. scenarios with asymmetric flow will require this It is recommended to have firewall set to reject TCP non-SYN when SYN cookies are enabled. If SYN flood settings are configured in the zone protection profile. A session that passes SYN cookies process are subject to TCP sequence number translation as firewall acted as proxy for TCP 3-way handshake. TCP state check For any first TCP packet that does not have SYN bit set will be discarded. then TCP SYN cookie is triggered if the number of SYN matches the activate threshold. The packet is discarded Virtual Wire Egress interface is the peer interface configured in the virtual wire Layer 2 Egress interface for the destination MAC is retrieved from the MAC table. Session allocation failure may occur at this point due to resource constraint • • VSYS session maximum reached. the packet is forwarded out via egress interface. If captive portal is applicable. the packet is redirected to the captive portal daemon Security policy lookup At this stage the ingress and egress zone information is available. and the packet is destined to TCP/80. User ID If the user information is not available for the IP address. a second route lookup for the translated address is performed to determine the egress interface • For source NAT. the IP address is translated as the packet forwarded out via the egress interface. Note: For more information on NAT. If the security policy action is to allow the packet. Note: Security rules are applied to the contents of the original packet. Any intra zone traffic is permitted by default. refer to the document Understanding PAN-OS NAT. or All available sessions are allocated. At this stage the ingress and egress zone information is available. the packet is dropped. even there are NAT rules configured Port scan/ Address sweep protection Port scan and address sweep protection is enforced if zone protection profile is configured on the ingress zone Session allocation A new session entry from the free pool will be allocated once all of the above steps are successfully completed. Once the session allocation is successful • • • Session content will be filled with flow keys extracted from packet and forwarding/policy results Session state changes from INIT (pre-allocation) to OPENING (post-allocation) If the application has not identified. the session timeout value is set to default value of the transport protocol © 2010 Palo Alto Networks Page 9 .NAT policy lookup This is applicable only in layer 3 mode. a captive portal rule lookup is checked to see if the packet is subject to captive portal authentication. If the policy action is deny. NAT rules are applied to the original packet. Any traffic that does not match a security rule is denied. • For destination NAT. refresh session timeout If the packet is a TCP FIN/RST. For application changing from one to another. application identification is performed. buffer out-of-order data and skip TCP retransmission. • • • Packet has TCP/UDP data. there will be a traffic log generated If security policy has associated profile and/or application is subject to content inspection. If the session is active. perform QoS policy lookup and assign matched QoS class If security policy action is allow application is SSL. setup content inspection session If security policy action is allow. the session timeout is changed to timeout-tcpwait value If NAT is applicable. translate the L3/L4 header if applicable. TCP reassembly module will also perform window check. After session application is identified. • • • • • Security policy lookup: The identified application as well as IP/port/protocol/zone/user in the session as keys to find rule match. A packet matching an existing session is subject to layer7 processing if any of the following. This stage starts with Layer2 to layer4 firewall processing. content inspection. then the packet will be discarded. or it is a non-TCP/UDP packet If session application is not detected yet. application is tunneled application. or the security rule has security profile associated. perform SSL decryption policy lookup and setup proxy contexts if there is decryption rule match © 2010 Palo Alto Networks Page 10 . or a threat detected. If security policy has logging enabled at session start. it will be processed by TCP reassembly module before stream data is fed to layer7 module. either because of the application itself requires content inspection. A session that has application identified will be subject to content inspection. is done via protocol decoding in content inspection. Once the application is matched the destination IP/port/ and protocol that identifies the application is stored into App-ID cache to speed up subsequent lookups if applicable. access control. Application Identification (App-ID) Application Identification consists of two cases: a) Session application from undecided to defined one. • • • • If the session is in discard state. If so we have an application. if an ALG is involved. and b) From one defined application to another Application-override policy lookup is done first to see if there is matched rule. If a application uses TCP as transport. A session can be marked as discard state due to a policy action change to deny. then application signature are used to identify the application. traffic management and logging will be setup as configured. condition matches.Firewall session fast path A packet that matches an existing session will enter the fast path. If there is no application override rule. which combines two complementary components-Single Pass software. even while incorporating unprecedented features and technology. Parallel Processing hardware. transaction processing and network security that today’s high performance networks require. Palo Alto Networks solves the performance problems that plague today’s security infrastructure with the SP3 architecture. low-latency network security. The results is the perfect mix of raw throughput. © 2010 Palo Alto Networks Page 11 .Summary Palo Alto Networks next-generation firewalls are based on a unique Single Pass Parallel Processing (SP3) Architecture – which enables high-throughput.
Copyright © 2024 DOKUMEN.SITE Inc.