Understanding fw monitor utility

[Music] yes shall go woman welcome everyone I want to welcome you once again in joining me on checkpoint training bytes checkpoint training bytes is where we're doing advanced training on Chapman products features and blades in this training module we'll be looking at a very important checkpoint utility called the fw monitor the effed-up monitor is a very useful tool that can be used to diagnose and troubleshoot how packets are being processed by the firewall kernel and also in this module we'll be seen how and when to run fw on etre we'll also discuss how to read and how to comprehend def that we monitor output but before we get started let's take a few moments and take a quick look and rundown of the agenda of this training module first we will start this lecture by discussing what after we monitor is what is the purpose of fw monitor and here we will discuss when it will be appropriate to use this tool and how this tool can be used to help diagnose identify the cause of connectivity and connection failures second we will discuss the differences between the traffic flow and packet inspection here will be mostly a review of how a firewall works how a checkpoint file inspects traffic we will look at the flow of the traffic the flow of the traffic from the client to the server and back from the server to the client and here is where we will take a look under the hood of how a check one file inspects traffic with regards and relationship to traffic flow and traffic direction and traffic inspection third we'll talk about the firewall kernel architecture and also discuss the firewall chains here is where we talk about the two inspection points the inbound and outbound chain in these chains is where the final code sits and here we will look at how the firewall treats and inspects packets differently in relationship to packets either being inbound or outbound packets Ford and finally we'll take a look at a few other inspection modules what they are and how in where are these modules process packets we will discuss some pre firewall inspection modules and also some post final inspection modules and here is where we will look at how some of these modules are either running pre or post viral inspection and here we also give you some tips on how to discuss grid of modules are located an inspection chain and how to easily identify where the inspection modules are located in the kernel so now that we viewed the agenda for this training module let's take a look at our first topic what is fw monitor the best way to explain after we monitor is to have a console connection if we type on the console the fw monitor command it's going to do some compilation and then it's going to capture all the data all the data that's going through the firewall kernel all the data that's going either to the firewall or through the firewall at the kernel level the fw monitor is capturing of that information and so we say that the FD monitor is a packet analyzer very similar to a tcp dump and to a wireshark capture you can use after a monitor to capture and help you analyze the traffic flow depth of your monitor captures all the data that is being handled inspected and processed by the firewall kernel by the firewall code in the kernel you can use fw monitor to track packet inspection within the kernel to give you a full picture and breakdown of the data stream inside the kernel you can use the fw monitor utility and use the same syntax on all hardware or operating system that is running to check one firewall you can use it to capture data for all Chuck when Gayo ease I'll check when appliances SMB appliances Marshall appliances quantum appliance and open servers etc you can use after your monitor they capture the packets that are being processed in the final kernel in a pcap format which will allow you to open the files using wireshark program which will help you filter and search for all relevant data with all these points in mind we first need to break down final colonel inspection process before we can dive into the fw monitor utility before we dive into the fw monitor tool let's take a step back just a little bit to refresh your memory on how a firewall works as I mentioned before that the check one firewall always inspects the traffic twice once in the inbound direction and then again the packet is inspected on the second time in the outbound direction now it's important to stress that the inbound and outbound inspection is done in relation to the direction and flow of the packet this is very important so let me repeat that the inbound and outbound inspection is always done in relation to the direction and flow of the packet let me give you an example to help make this point clear let's add a client and a server to help clarify the direction let's say now that the client is communicating to the server so here we have an internal interface with just a Warda client and so this becomes external interface since it's located towards the server side or to be more specific the external face is always towards the intranet and so this perspective does not change regardless where the client and server is this is really always in relationship towards where the Internet is whatever internet is then this becomes the external interface so even if the client is located on external side on the internet side and the server is located on the internal side on inside of your network like a web server or a mail server again this perspective does not change this is still the external network since it's facing towards the internet side and this is still the internal interface since it's facing the internal network and I think this is clear and obvious to you all but our two points that I'm trying to make try to make clear so bear with me for just a little bit and these two points are a minor and a major point I first start with the minor point the minor point is and the point I'm trying to make is that the internal interface and external interface does not change at all regardless of the packet that's coming inbound on the internal interface or coming inbound on external interface this is still and always will be the external interface and this is still and always will be the internal interface regard if the packet is inbound and outbound but the inspection point does change it always changes based on the direction on the direction of the packet flow a packet can be coming inbound on external interface or a packet could be going outbound on external interface and the same thing applies to the internal interface or any other interface for that matter a packet can be coming inbound on internal interface or a packet can be going outbound on internal interface and so if the client is on internal network and the server is on the internet then when the client sends a packet to this server then this is the internal interface inbound interface and and then we have the outbound interface on the external network and so when the server replies back to the client this is now the inbound interface which is on external network and this is now the outbound interface which is now on the internal network the internal phase correct and this is the point I made earlier and I stressed it twice already but I think the third time is the charm is that the in mount and add bone inspection is always done in relation to the direction and flow of the packet so notice how the interfaces do not change in relation to the flow of the traffic but inspection did change in relation to the flow of the traffic and now the major point I need to be made and I'm not sure I've made it yet is that the firewall inspects packets differently in relation to them being inbound packets or outbound packets certain final inspection functionality is done on inbound interface and then certain other functionality is done on the outbound interface let me draw this to give you a different perspective which I think will help me clarify this point a little bit better here we have the inbound inspection and here we have the outbound inspection we call these the inspection chains this is the inbound inspection chain and this is the outbound inspection chain but we more commonly just refer to them as the inbound chain and outbound chain the final inspection code will be enforced on both inbound chain and also on the outbound chain so if a packet is coming in to the internal interface it will be inspected by the final code in the inbound chain and if a packet is leaving the internal interface it will be inspected by the final code on the outbound chain the same thing happens on the external interface if the packet is entering the external phase it will be inspected by the inbound chain inspection chain and if the packet is leaving the external frames now you guessed it you will be inspected by the outbound inspection chain and so as mentioned already and several times is that some functionality is done on the inbound chain and some functionality are done on the outbound chain let me give you a few examples to help clarify and help make this clear if a packet is inbound it will need to be inspected and matched by the rule base and also maybe it may need to be logged that is if logging is turned on for that rule but if the packet is logged on the inbound chain then it will not need to be logged again on the outbound chain you only need to log once either the packets are accepted or dropped and one log is all that is needed there is no need to log again on the outbound chain here is another example let's take Maddie Maddie can happen on either inbound chain or it can happen on the outbound chain he really depends on how I want neither yes labeled or how a complex you have configured your net rules but for simplicity sake in this example when hi NAT is enabled for the source then adding will be done on the outbound chain or when static NAT is enabled for the destination then adding will be done on the inbound chain I don't want to go too deep into nodding in this video but I hope you get the point which is that different functionality can happen to a packet on inbound chain versus the outbound chain now let's take this up a notch is just a little bit not only is a fireable code running on both inbound chain and the outbound chain but we also have some of the products and multiple inspection points on inbound chain and we also have some other inspection points in the outbound chain firewall is just one component that is running on the inbound chain and outbound chain by depending on what products and blades you have enabled you will have a few inspection points for other products before the firewall code and some of the products the inspection code and functionality after the firewall code we call these products that are running in the kernel modules in the kernel we have multiple product modules running and inspecting the packets and so we have some inspection points for products and modules that can happen on both chains on the outbound chain we have some product codes and functionality to inspect packets before the fire inspection code and we also might have also some product code and functionality inspecting packets after the fire code I will show you later in this video exactly what these modules are but for now let's assume that we have some of checkpoints other products enabled like perhaps secure Excel cluster excel IPS VPN etc and so once we've enabled a bunch of checkpoint products and features we will be turning and enabling a bunch of other inspection codes inspection modules for these other products depending on the products or features being enabled some product codes will be loaded in an inbound chain and some product code and functionality will be loaded and running on that outbound chain it really depends on the products your enabled some products and blades my load some code and inspection on both inbound and also outbound chain and also it's possible that some code will be enabled before the final code on the inbound chain and some other products code might be enabled after the final code in the inbound chain and this applies and is also true for the outbound chain as well some inspection code can be enabled before the firewall code on the outbound chain and some inspection code can be enabled after the fire one spectrum code on the outbound chain this really depends on the products that customer has purchased licensed and enabled now let's go on to the next topic which is really a language and lingo that checkpoint and checkpoint savvy users used which will help us identify where things are broken or where things are not working so some code and functionality is broken on not working we can identify it rapidly has pre or post firewall modules if some inspection code is dropping the packet before the fire with inbound chain we call the pre inbound chain or some module code for functionality is dropping the packet after the final code in the inbound chain we call it the post inbound the same thing applies to the outbound chain we refer to any chain inspection code before the firewall code in the inbound chain as pre outbound and after the firewall code as post outbound and so when you're talking to a checkpoint engineer or a checkpoint customer and then when we need to refer a reference some things that are dropping to packet Crean bound we're talking about a product before the firewall code or post outbound we're talking about inspection point after the firewall module on the outbound chain one more time make sure this is clear before we move on anything running before the firewall code we call it the pre inbound anything running here after the firewall code we call it the post inbound anything an outbound chain that's running before the firewall code we call that the creeped out bout anything running after the final code we call it post how about one last single pointer that we often use when talking about D bugs but specifically when we're talking about after a monitor is that sometimes we use a shorthand version instead of saying pre inbound post inbound Creole bounced out bounce we say lil I big I little ol big ol little I refers to a pre inbound big I refers to post inbound little means pre out Bang and Big O means post outbound and this makes sense if you think about it a little bit anything in the inbound is referred to as an i small is pre big is post anything on how about chain we refer to as a no again a small o is pre and the Big O is post so anything small is pre firewall like small I or small oh these inspection points are before the firewall chain module small is pre inbound small o Esprit outbound anything that as big is post big is post inbound Big O is post outbound one final thing is we're drowning engine sits the routing engine the writing session always occurs between inbound chain and outbound inspection chain so going back to my previous example that we used earlier the client sends a packet from the client to the server either request for UDP or a syn packet for a TCP connection the packet arrives on the internal interface of the firewall always remember the final code always sits in between there are 2 layer 3 of the OSI layer the final inspection engine is part of the whole inbound inspection engine packets will inspected by the hull inbound chain it will first be inspected by decree inbound shape module then it will be inspected by the firewall inbound chain module and then we'll inspect it by the post in bow chain module if all the inspection points along the inbound chain module approves or inspects and accepts a packet then the packet is processed moved up to the TCP stack up to layer 3 layer 3 is where that routing engine sits the routing engine makes the routing decision aware throughout the packet in this case the packet is routed to the external interface again we have the fire inspection code that sits in between letter 203 but now this is the outbound inspection code again the packet will need to be processed and handled first by the pre outbound chain module then it will need to be inspected by the outbound firewall inspection module and then finally you will need to be processed by all the other post outbound chain modules before the package can be sent on its way to the external phase and then external interface sends a packet on the wire through its true destination the remote server when the server replies the whole process and inspection is repeated again but notice that now the inbound chain and outbound chain will change in perspective to the direction of the packet the packet arrives on external phase then you'll need to be processed by the inbound chain module pre inbound and post inbound then this packet is routed to the internal phase and now it's inspected by the outbound chain module pre and post pre outbound and then you gain post out BOM before sending the packet to the internal interface which will then send the packet back on the wire towards the client and before we let you go let's do one more demonstration and put all these pieces together to see how they work let's say that the client wants to send a packet to the server the packet will arrive on the internal interface then it needs to be processed by the firewall kernel since it is an inbound packet you will need to be processed by the inbound chain and so at first you will need to process by it up inbound chain modules the little eye then you will need to be processed by the firewall code here is we check the rule base if there was no rule that accepts a packet then the packet will be dropped no further processing will occur on the other hand if there is a rule to accept the packet then the packet will continue on it's adjourned now it will be processed by it a post in bow chain the big eye now it's important to emphasize that packets could be rejected anywhere within the inbound chain but if everything is allowed and process by tianbao chain then we move the packet to the next layer and so the next thing that the packet is moved up to the letters read the letter three is where the routing engine sits here is where the routing engine will make a routing decision based on the entries in its routing table either it finds a route to for the packets to the next hop interface or uses the default gateway has the path of last resort but once the routing decision is made packet is then forward on to the elbow chain this up bone chain will be processing based on the interface that was determined by the routing decision now the outbound chain will process the packets through firewall which we call the pre outbound inspection also known as the level oh and the packet will then be processed by the firewall code this time obviously by the firewall code running on the Alabama chain and again if the packet is accepted it is moved to the post how about to be processed by the post outbound modules what we call the big ole befall flooring the packet on the wire towards its final destination the server the destination in this case being the web server then the server will reply the packet inspection and processing will be done once again but now in the reverse direction the packet will arrive on extra motor phase it will be processed first by the pre inbound chain module the small I then processed again by the inbound firewall inspection code then inspected by the post inbound firewall code the big eye and then the packet is once again forwarded to the layer three for routing the routing engine will make a routing decision and send the packet to the internal interface the internal phase will be the outbound chain the pre outbound chain once again press up the packet again we call this the little hole and then the Alabama firewall code will inspect the packet once again then forward a packet to the post outbound chain module the big ol again if the packet fails anywhere throughout these inspection checks then the packet will be dropped if the packet is not dropped and in allowed through the outbound chain then the packet is forward how the internal interface towards the client again to be sure this is clear if the packet inspection fails anywhere during inspection chain either from the client to the server from the server back to the client if there's any failures or rejections anywhere along the inspection chain then the packet will be dropped and so how do you identify where there is a potential failure this is where we need to run they have to every monitor tool the fw monitor tool will help us isolate where the failure occurs it will help us isolate if it fails on an inbound or outbound chain if it fails an inbound they did fail pre firewall or post firewall again if the failure was determined to be occurring in a LAN chain there the failure occur crude outbound or post outbound and finally I hope this video has helped shed some light on what fw monitor is and how it can be used to identify connection failures that is connection failures that are occurring within inspection chain either the inbound or to outbound inspection chain and so when you are able to identify where the failure is occurring within the chain this knowledge will get you closer to resolving the problem at least this information will help you to focus and narrow down which product or function to focus your attention on which will help you to troubleshoot the issue and hopefully lead you to problem resolution I created this video to discuss fw monitor but we first needed to discuss the foundation of how a fire will process packets with this knowledge it will help us comprehend the fw monitor utility in the next video we will continue to explore the fw monitor and how it captures the packets within the kernel within the inbound and outbound inspection chain before ending this module let's take a few moments to quickly summarize the information discussed in this video we started this video by first discussing what after every monitor is in essence it is a packet analyzer which is very similar TCP dump packet capture and also discussed some differences between them with the main difference being that TCP dump captures the traffic captures the packets on the wire and meaning it captures the packets running on the network whereas I have to ramon etre utility captures the traffic it captures the data that's being processed inspected within the kernel specifically within the firewall inspection kernel and we also discussed how the FD monitor is used to help you to view and then to Phi packet flows and packet direction within the kernel which can help you to locate an isolate where how and when the packets are being processed which can help you identify the issue or a problem within the final kernel all within the perspective of the direction of the traffic flow and then we discuss how packets are being processed we discussed that each packet is being processed twice once in each direction we discussed the differences between external and internal interfaces and how packets are being processed differently but always in regards and in relationship to them being either inbound or outbound traffic and how each packet can be going inbound or outbound on external or the internal interfaces and we also discussed how inspection will be always done differently in relation and in regards to whether they are inbound traffic or outbound traffic and we also discussed how some products or functions will be done either on the inbound or on the outbound inspection and how some products or functions might be done on the inbound direction or sub products and function might be done on the outbound direction we also mentioned that some products or inspection function might be done only on the inbound direction or it might be done only on the outbound direction or both the inbound and outbound direction then we talked about the inspection chain how each and every packet is always processed by the firewall code in each chain how each packet is processed by the final code in the inbound chain and how in turn each packet is also processed by the final code in the AL Bound chain and how each final code in inspection chain process packets differently in regards to whether they are inbound outbound packets we also discussed that the final kernel is made up of multiple products which we call modules or to be more specific kernel modules and how kernel modules are running before the final code and some kernel modules can be running and inspected packets after the final code and how we use specific language and lingual to identify where within the chain that the product module is located in the inbound chain would say that every module running before the final code we call them the pre inbound modules and we also mentioned that the module running after the firewall code we call them the post inbound modules and we also discussed that we have similar terminology to help identify and locate product and inspection that could be used or running in the outbound chain and we call every product or function before the final code on the albo chain has pre outbound modules they recall everything after the final code on the alabone chain has post out bond modules we also discussed a shorthand version to help identify pre and post inspection on the inbound chain there pre inbound inspection modules we call them the little eyes on the post inbound inspection module we called them the big eyes on the outbound chain the pre outbound we call that the little o on the post how about we call that the big ol Pretre post little big your choice and finally we also discussed the running engine the routing decision is always done between the inbound chain and the l-bomb chain if a packet is inspected and accepted by either all the inbound chain modules and the pocketable route it to the outbound chain to be inspected and processed again I hope you found this video informative hope to see you in the next video until then Shalom and bye for now Jack boy we secure the future [Applause] [Music]

Channel: Check Point Training Bytes

Views: 5,754

Keywords: CCSA, CCSE, CCSM, fw monitor, check point firewall, check point inspection, firewall kernel, firewall code, inspection chain, kernel module, check point certified administrator, check point certified expert, check point certified security master

Id: ysyVW24kGK8

Length: 27min 12sec (1632 seconds)

Published: Fri May 08 2020