Skip to main content

Introduction To Fortigate Firewall

Fortinet security platforms offer complete protection for a wide range of security functions - Stateful Firewall, IPSec VPN, Antivirus, IDS & IPS, Web Content Filtering, Anti-Spam, and Bandwidth Shaping. Functionality is consistent across all FortiGate units ranging from the economical SoHo products to the carrier class service provider and large enterprise systems.


FortiGate Architecture

  •      ASIC Based Purpose-Built Architecture
  •      ASIC Accelerated FW, VPN, AV, IPS
  •      Dedicated Hardened Operating System
  •      Fortinet Software Ownership - no OEM or 3rd Party integrated products

The FortiOS operating system serves as the foundation for the FortiGate® network security platform, and includes the widest range of security technologies of any network security solution: 

  • Firewall, VPN, and Traffic Shaping
  •  Intrusion Prevention System (IPS)
  • Antimalware/Antivirus/Antispyware
  • Integrated Wireless Controller
  • Application Control
  • Data Loss Prevention (DLP)
  • Advanced Threat Protection
  • Contextual Visibility Management
  •  Feature Select with Presets
  •  Vulnerability Management
  •  IPv6 Support
  •  Web Filtering
  •  Antispam
  •  VoIP Support
  •  Layer 2/3 Routing
  • WAN Optimization & Web Caching

A  FortiGate unit screens network traffic from the IP layer up through the application layer of the TCP/IP stack. This chapter provides a general, high-level description of what happens to a packet as it travels through a FortiGate  security system.

The FortiGate unit performs three types of security inspection:

•  stateful inspection, that provides individual packet-based security within a basic
session state
•  flow-based inspection, that buffers packets and uses pattern matching to identify
security threats
•  proxy-based inspection, that reconstructs content passing through the FortiGate unit
and inspects the content for security threats.

Each inspection component plays a role in the processing of a packet as it traverses the
FortiGate unit en route to its destination.

Stateful inspection

With stateful inspection, the FortiGate unit looks at the first packet of a session to make a security decision. Common fields inspected include TCP SYN and FIN flags to identity the start and end of a session, the source/destination IP, source/destination port and protocol. Other checks are also performed on the packed payload and sequence numbers to verify it as a valid communication and that the data is not corrupted or poorly formed. 

The FortiGate unit makes the decision to drop, pass or log a session based on what is
found in the first packet of the session. If the FortiGate unit decides to drop or block the first packet of a session, then all subsequent packets in the same session are also
dropped or blocked without being inspected. If the FortiGate unit accepts the first packet of a session, then all subsequent packets in the same session are also accepted without being inspected.

 

Flow inspection

With flow inspection, the FortiGate unit samples multiple packets in a session and multiple sessions, and uses a pattern matching engine to determine the kind of activity that the session is performing and to identify possible attacks or viruses. For example, if application control is operating, flow inspection can sample network traffic and identify the application that is generating the activity. Flow-based antivirus can sample network traffic and determine if the content of the traffic contains a virus, IPS can sample network traffic and determine if the traffic constitutes an attack. The security inspection occurs as the data is passing from its source to its destination. Flow inspection identifies and blocks security threats in real time as they are identified.

Flow-based inspections typically require less processing than proxy-based inspection, and therefore flow-based antivirus performance can be better than proxy-based antivirus performance. However, some threats can only be detected when a complete copy of the payload is obtained so, proxy-based inspection tends to be more accurate and complete than flow-based inspection.

 

Proxy inspection

With flow inspection, the FortiGate unit will pass all the packets between the source and destination, and keeps a copy of the packets in its memory. It then uses a reconstruction engine to build the content of the original traffic. The security inspection occurs after the data has passed from its source to its destination.

Proxy inspection examines the content contained a content protocol session for security threats. Content protocols include the HTTP, FTP, and email protocols. Security threats can be found in files and other content downloaded using these protocols. With proxy inspection, the FortiGate unit downloads the entire payload of a content protocol sessions and re-constructs it. For example, proxy inspection can reconstruct an email message and its attachments. After a satisfactory inspection the FortiGate unit passes the content on to the client. If proxy inspection detects a security threat in the content, the content is removed from the communication stream before the it reaches its destination. 

For example, if proxy inspection detects a virus in an email attachment, the attachment is removed from the email message before its sent to the client. Proxy inspection is the most thorough inspection of all, although it requires more processing power, and this may result in lower performance.

If you enable ICAP in a security policy, HTTP traffic intercepted by the policy is transferred to the ICAP servers in the ICAP profile added to the policy. The FortiGate unit is the surrogate, or “middle-man”, and carries the ICAP responses from the ICAP server to the ICAP client; the ICAP client then responds back, and the FortiGate unit determines the action that should be taken with these ICAP responses and requests.


FortiOS functions and security layers:

 

 Packet flow:

 

Comments

Post a Comment

Popular posts from this blog

Basic Rules of Checkpoint Firewall

Managing the Firewall Rule Base: Explicit and Implied Rules These are the types of rules in the Rule Base: Explicit rules - Rules that you create to configure which connections the Firewall allows Implied rules - Rules that are based on settings in the Global Properties menu Implied rules allow connections for different services that the Security Gateway uses. For example, the Accept Control Connections option allows packets that control these services: ·          Installing the security policy on a Security Gateway ·          Sending logs from a Security Gateway to the Security Management server ·          Connecting to third party applications, such as RADIUS and TACACS authentication servers Order of Rule Enforcement: Make sure that you understand the importance of the order of rule enforcement to maximize the security of the Firewall. The Firewall always enforces the first rule that matches a connection. It does not enforce later rules tha

ASA TCP Connection Flags

When troubleshooting TCP connections through the ASA, the connection flags shown for each TCP connection provide a wealth of information about the state of TCP connections to the ASA. This information can be used to troubleshoot problems with the ASA, as well as problems elsewhere in the network. Here is the output of the show conn protocol tcp command, which shows the state of all TCP connections through the ASA. These connections can also be seen with the show conn command. ASA# show conn protocol tcp 101 in use, 5589 most used TCP outside 10.23.232.59:5223 inside 192.168.1.3:52419, idle 0:00:11, bytes 0, flags saA TCP outside 192.168.3.5:80 dmz 172.16.103.221:57646, idle 0:00:29, bytes 2176, flags UIO TCP outside 10.23.232.217:443 inside 192.168.1.3:52427, idle 0:01:02, bytes 4504, flags TCP outside 10.23.232.217:5223 inside 192.168.1.3:52425, idle 0:00:10, bytes 0, flags saAUIO TCP outside 10.23.232.57:5223 inside 192.168.1.3:52412, idle 0:00:23, bytes 0, flag

How to Set Up an IPSec Tunnel On PAN-OS - Palo Alto Firewalls

Set Up an IPSec Tunnel  The IPSec tunnel configuration allows you to authenticate and/or encrypt the data (IP packet) as it traverses across the tunnel.  If you are setting up the Palo Alto Networks firewall to work with a peer that supports policy-based VPN, you must define Proxy IDs. Devices that support policy-based VPN use specific security rules/policies or access-lists (source addresses, destination addresses and ports) for permitting interesting traffic through an IPSec tunnel. These rules are referenced during quick mode/IKE phase 2 negotiation, and are exchanged as Proxy-IDs in the first or the second message of the process. So, if you are configuring the Palo Alto Networks firewall to work with a policy-based VPN peer, for a successful phase 2 negotiation you must define the Proxy-ID so that the setting on both peers is identical. If the Proxy-ID is not configured, because the Palo Alto Networks firewall supports route-based VPN, the default values used as Proxy-ID are source