FCNSP/WCSP
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
Iprope -> Group of firewall policies installed into the kernel parsed from cmdb configuration: 'config firewall policy' is mapped to iprope policy group ENC_FWD (0x100004)
'config firewall local-in-policy' is mapped to iprope policy group IN (0x100001)
These iprope group can be listed by: 'diag firewall iprope list'
Each of these policy groups is installed at different nodes of the netfilter chain. The netfilter chain has the following nodes:
NF_INET_PRE_ROUTING, NF_INET_LOCAL_IN, NF_INET_FORWARD, NF_INET_LOCAL_OUT, NF_INET_POST_ROUTING,
NF_INET_AF_ORIGIN, NF_INET_AF_SINK,
The netfilter chain works as the following example cases:
1. A packet arrived at the interface card and the driver copies the incoming data into skb. The skb is processed and eventually reached the netfilter chain node pre-routing. The skb is lookup into the routing table to decide whether it is for local host or forward to another external hosts(based on IP address). If it is destined for local host, the node local in is triggered and iprope in group is processed. If it is destined for forwarding, the node forward is triggered and iprope forward group is processed. Then it reached the post routing node, where the interface card output function is hooked. Then the skb is passed on to the link layer and to another external router. 2. If a local process writes data to a socket using write() system call, the layer 7 application data transition into kernel space. Then the system call function transfer the data to transport layer function, e.g., tcp function. Then the tcp function passed the skb to the network layer, the IP function, which is hooked into netfilter chain local out node. It will be processed and proceed to the next post routing node.
3. There are many functions hooked into the netfilter chain, e.g., firewall rules, interrupt handler input/output,
virtual devices like ipsec, sslvpn, nat64/46, etc. Basically the netfilter chain is like a virtual bus where the individual packet is processed as struct skb data.
For the function iprope_in_check(), it is hooked into local in node.
Inside the function are called 4 ordered groups of iprope (ttl, local, implicit, admin):
ttl -> config firewall ttl policy matching
local -> config firewall local-in-policy
implicit -> hard-coded ports/services like HA, routing, etc.
admin -> seems like ssh, telnet, http services dynamically added based on config
The local-in policy group is triggered before implicit and admin and thus can override them.
For the implicit-in group, it could be moved into external cmdb config instead hard-coded into source code.
But this would cause service interruption if configured incorrectly.
Also this would make it easier to configure which ports to be accessible.
FCNSP/WCSP
Iprope -> Group of firewall policies installed into the kernel parsed from cmdb configuration: 'config firewall policy' is mapped to iprope policy group ENC_FWD (0x100004)
'config firewall local-in-policy' is mapped to iprope policy group IN (0x100001)
These iprope group can be listed by: 'diag firewall iprope list'
Each of these policy groups is installed at different nodes of the netfilter chain. The netfilter chain has the following nodes:
NF_INET_PRE_ROUTING, NF_INET_LOCAL_IN, NF_INET_FORWARD, NF_INET_LOCAL_OUT, NF_INET_POST_ROUTING,
NF_INET_AF_ORIGIN, NF_INET_AF_SINK,
The netfilter chain works as the following example cases:
1. A packet arrived at the interface card and the driver copies the incoming data into skb. The skb is processed and eventually reached the netfilter chain node pre-routing. The skb is lookup into the routing table to decide whether it is for local host or forward to another external hosts(based on IP address). If it is destined for local host, the node local in is triggered and iprope in group is processed. If it is destined for forwarding, the node forward is triggered and iprope forward group is processed. Then it reached the post routing node, where the interface card output function is hooked. Then the skb is passed on to the link layer and to another external router. 2. If a local process writes data to a socket using write() system call, the layer 7 application data transition into kernel space. Then the system call function transfer the data to transport layer function, e.g., tcp function. Then the tcp function passed the skb to the network layer, the IP function, which is hooked into netfilter chain local out node. It will be processed and proceed to the next post routing node.
3. There are many functions hooked into the netfilter chain, e.g., firewall rules, interrupt handler input/output,
virtual devices like ipsec, sslvpn, nat64/46, etc. Basically the netfilter chain is like a virtual bus where the individual packet is processed as struct skb data.
For the function iprope_in_check(), it is hooked into local in node.
Inside the function are called 4 ordered groups of iprope (ttl, local, implicit, admin):
ttl -> config firewall ttl policy matching
local -> config firewall local-in-policy
implicit -> hard-coded ports/services like HA, routing, etc.
admin -> seems like ssh, telnet, http services dynamically added based on config
The local-in policy group is triggered before implicit and admin and thus can override them.
For the implicit-in group, it could be moved into external cmdb config instead hard-coded into source code.
But this would cause service interruption if configured incorrectly.
Also this would make it easier to configure which ports to be accessible.
Thank you very much for sharing this. Very interesting.
Thanks for the tip Mr. Darwin.
Carlitos loves firewalls
NSE4 (5.4,6.0)
NSE5 (Fortimanager 6.0, Fortianalyzer 6.0)
NSE7 (Enterprise Firewall 6.0)
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1696 | |
1091 | |
752 | |
446 | |
228 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.