Block Diagram depicting how pfSense process a packet with and without IDS/IPS module on top of it
-
I want to know how pfSense process a packet and what are the core modules that can be represented as a block diagram. If the snort module has been added as a package, where does it actually comes to play in a basic block diagram? If there is any expert that might help.
Regards
-
With either of the IDS/IPS packages, the "location" of the IDS/IPS within the network flow is as follows:
For Inline IPS Mode operation, the traffic comes into the physical NIC, is sent to the IDS/IPS engine, and then packets passed by the IDS/IPS engine are sent on to the pfSense firewall engine.
For Legacy Mode operation, the packets coming from the NIC are copied and the copy of each packet is sent to the IDS/IPS engine while the original packet continues on to the pfSense firewall engine. The IDS/IPS engine uses a custom blocking module compiled into the Snort and Suricata binaries. That module will pull the IP addresses from alerting packets and send either the source IP, destination IP or both (as configured within the IPS) to a pre-existing
pftable in pfSense called snort2c. Any IP address in that table will be blocked by the firewall. The table is essentially a type of built-in alias in pfSense.Legacy Blocking Mode Operation
So one key takeaway from these diagrams is that the IDS/IPS exists on the NIC side of the firewall rules. So to understand the implications of this you have to consider each NIC independently. So on the LAN side, as an example, traffic coming from a LAN host will first hit the IDS/IPS before it hits any firewall rules. On the WAN, traffic coming in from the Internet would first hit the IDS/IPS and then hit the firewall rules.
The final point that differentiates Inline IPS Mode from Legacy Mode is that when using Legacy Mode blocking the IPS is working with a copy of a given packet. The original packet has continued on to the firewall, and if allowed by either existing rules or an established "state", is passed on to the internal host. After analyzing its copy of the packet (or perhaps several packets if a larger stream is required for detection), if the IPS decides to block the traffic it will use the custom module to insert the packet's IP address into the snort2c table. That will result in subsequent blocks of traffic from that host, but ONLY if any pre-existing "state" is cleared. Thus there is an option, set to true by default, on the INTERFACE SETTINGS tab when configuring Legacy Mode Blocking that tells the custom module to also kill any existing "states" for an IP when adding the IP to the snort2c table for blocking.
Inline IPS Mode is different. It uses the kernel
netmapdevice to establish a pipe between the NIC and the rest of pfSense. All packets must traverse that pipe in order to go between the NIC and pfSense. The IDS/IPS inspects all traffic traversing that pipe. Rules can be configured to either just alert or to alert and drop traffic. Dropped traffic is literally just discarded and not forwarded on to pfSense. When using Inline IPS Mode, the admin must explicitly change the action of rules from ALERT to DROP in order to block traffic. There are several tools for doing this with the most popular being the SID MGMT tab. There are other posts here on the forum about using the SID MGMT tab features. -
Thank you for your kind respond. This is very good block diagram for understanding the basics. I am looking towards more in depth knowledge of how the blocks actually works. As an example, if we talk about an Intrusion Detection and Prevention system, there are few basic building blocks that makes the system work. Starting with Packet capturing and followed by Packet Decoder, Pre-processor, Detection engine, Alarming module and then Output module. Now all of these has very important role that makes the complete IDS/IPS work as a system. Any block diagram that can actually summarize the whole process of what is going inside a pfSense will greatly help in visualizing and easy understanding of the product.
-
@Fareed-Jamali said in Block Diagram depicting how pfSense process a packet with and without IDS/IPS module on top of it:
Thank you for your kind respond. This is very good block diagram for understanding the basics. I am looking towards more in depth knowledge of how the blocks actually works. As an example, if we talk about an Intrusion Detection and Prevention system, there are few basic building blocks that makes the system work. Starting with Packet capturing and followed by Packet Decoder, Pre-processor, Detection engine, Alarming module and then Output module. Now all of these has very important role that makes the complete IDS/IPS work as a system. Any block diagram that can actually summarize the whole process of what is going inside a pfSense will greatly help in visualizing and easy understanding of the product.
For the answers to questions at that level of detail, you will need to use Google to search for tutorials on the internal structures of the various IDS/IPS engines. The packages available for pfSense are simply GUI wrappers to aid in the configuration of the two most popular IDS/IPS engines: Snort and Suricata. The actual work of IDS/IPS is done by the compiled binary.
-
I have in depth knowledge of how IDS/IPS works. I want to know the in depth block diagram of pfSense. I want to see the complete functionality of pfSense in a block diagram. Something that might look like https://commons.wikimedia.org/wiki/File:Netfilter-packet-flow.svg
-
pfSense is based on the FreeBSD operating system and uses that networking kernel. The firewall engine is
pf. You can find information about that on Google. The current release version of pfSense is based on FreeBSD 11.3/STABLE. More than anything else, pfSense is really a PHP GUI wrapper to make configuration of thepffirewall engine more user friendly.Have you checked out the offical Netgate documentation for pfSense here: https://docs.netgate.com/pfsense/en/latest/book/?
-
Yes, I have checked the official Netgate documentation and there is too much to go through. Honestly, I lose the grip of actual problem when I start going through it since it is beautifully written. I was wondering if someone had already tried something like this that could help me.
-
I don't understand what you want. You first asked for how traffic flowed through pfSense when Snort had been added as a package (your word was "module", but that is not technically correct for the pfSense environment). I provided you with two diagrams.
Then you said you wanted to know how packets went through the firewall itself. I provided you a link to the official documentation and what is considered the "Bible" for pfSense, the pfSense Book. But then you say it is too hard for you to understand?
I'm confused as to what you actually want. Are you a student whose instructor has assigned you a project of drawing a block diagram and you want someone else to do your project for you?
-
Block Diagram depicting how pfSense process a packet. Let's ignore the IDS/IPS part for time being.
Not really, this is not my project nor any professor has assigned me a project. The purpose of such forums are to discuss the things that are missing in the documentation. Have you found any block diagram in the documentation that is actually depicting the complete pfSense functionality?
-
I don't know that there is such a diagram. I would go search on Google for information about how
pf, the packet filter firewall in FreeBSD, works. That is the firewall engine in pfSense. -
This is probably as close as you'll get from the pfSense docs:
https://docs.netgate.com/pfsense/en/latest/book/nat/ordering-of-nat-and-firewall-processing.htmlYou would need to look at the FreeBSD and Packet Filter (pf) docs to see anything more detailed.
Steve
-
I greatly appreciate the visual and explanation. It helps a lot. Thank you.
