Windows Firewall: Logging/Notifying on Outgoing Request Attempts

I was trouble shooting an app I was developing a while back and ran into a brick wall. Essentially, I was having issues with an "Entity framework" being used when telecommuting. Looks like there was a connection being dropped thereby impacting an event handler for an asynch call the app was making. Well, I needed to find out what the problem was and the first thing to check was connectivity issues.

My initial inclination was a FIREWALL setting or some subnetting stuff. In *nix environments, it is pretty easy to log and view inbound/outbound connections but under Windows, you need to be a C++ or C# specialist to write an under the hood HOOK or interface to do that. Anyway, I thought there should be a way within Window FireWall app to do this, but the Devil is in the details - no documentation or better still - no pointer to any documentation on how to do this.

OK - no documentation anywhere but there is "Google" - so, nothing to worry about. I googled a phrase close to what I was looking for and it returned a couple of hits. One thing that is really annoying about some of the help sites - is that - most times, the same "hint" or help is pasted from another site without any attempt whatsoever to break it down into anything meaningful. So, if the original poster made a mistake, subsequent clones of the same hint will persist or inherit the original defect.

Fast forward, i eventually came across a link/site that attempted to explain what to do but again one or two crucial steps were missing. The basic thing steps with viewing "inbound/outbound" connections are these :

  1. Fire up Windows FireWall application. Click on the "root node" ( Windows Firewall with Advanced settings) of the Tree View on the left panel. There are three panels displayed. The middle panel will show the various profiles and the rules in place for each one of them. At the bottom of the "Overview" Group box in the middle panel, there is a link - "Windows Firewall Properties", click on it.



  2. The popped up window for "Windows FireWall Properties will display tabbed panels for the various profiles. Click on the appropriate tab and then click on the button -"customize" in the "Logging" group box at the bottom of the panel for the profile being viewed. This will bring up another popped up window from where you can toggle the options to log either or both of the inbound or outbound connections packets. Within the popped up window, is a displayed path to the log file. You will most times, need an administrative access in order to view its content.
  3. Another way of viewing the contents of the logged actions is to use the Event Viewer - again, administrative rights are required to do this. You will need to create a custom view for the events you want to view. Fire up Event Viewer. In the left panel, navigate to the "Application and Services" node. Expand on it and then select/expand the "Microsoft" sub node. Select the "Windows" node from there and finally click on the "Windows FireWall and Advanced Security". On the left hand side panel,you can create a view and filter the appropriate connection attempts you are interested in.



Comments

Post a Comment

Popular posts from this blog

Decompiling Delphi - 3

I came across this on delphi.about.com web site and thought it useful to add it a a reference here. continued from part two The art of reverse engineering has traditionally been the land of technical wizards, familiar with assembly language and debuggers. Several Delphi decompilers have appeared that allow anybody, even with limited technical knowledge, to reverse engineer most Delphi executable files. If you are interested in reverse engineering Delphi programs I suggest you to take a look at the following few "decompilers": IDR (Interactive Delphi Reconstructor) A decompiler of executable files (EXE) and dynamic libraries (DLL), written in Delphi and executed in Windows32 environment. Final project goal is development of the program capable to restore the most part of initial Delphi source codes from the compiled file but IDR, as well as others Delphi decompilers, cannot do it yet. Nevertheless, IDR is in a status considerably to facilitate such process. In co...
Read more

Decompiling Delphi - 2

I came across this on delphi.about.com web site and thought it useful to add it a a reference here. continued from part one For the moment, Borland does not offer any product capable of decompiling an executable (.exe) file or the "Delphi compiled unit" (.dcu) back to the original source code (.pas). Delphi compiled unit: DCU When a Delphi project is compiled or run a compiled unit (.pas) file is created. By default the compiled version of each unit is stored in a separate binary-format file with the same name as the unit file, but with the extension .DCU. For example unit1.dcu contains the code and data declared in the unit1.pas file. This means that if you have someones, for example, component compiled source all you have to do is to reverse it and get the code. Wrong. The DCU file format is undocumented (proprietary format) and may change from version to version. After the compiler: Delphi Reverse Engineering If you would like to try to decompile a Delphi e...
Read more

Artificial Intelligence, Oxymoron and Natural Intelligence

Image
I posted this question to a couple of online AI engines and to my surprise, none came up with the correct anwser. This is the question - "Two Americans were crossing a bridge on a bright summer morning, one was the father of the other and the other wasn't the son. So, what was their relationship?" This is a classic IQ question - supposedly, employed by Microsoft in the easrly 90s in the recruitment of top talent for its work pool. Essentially, this is a mis-direction fixation challenge. On the surface - it is a fairly straight forward question with the requisite hint at solving it. For whatever reason, most people asked this question are always fixated on the "father and son" narative, which in reality - is the hint to solving the question, but always end up getting it wrong. My point really is - the so called AI engines got the answer to the question wrong as well. The real poser is - should we still be referring to the encompassing ecosystem...
Read more