Firewall Monitor How-To Use - 2026-07-10

Small independents, whether individuals or businesses. The inherent factor is trust. This app is of little use, if you do not trust those with access. In an otherwise secure machine, this app is designed to record login-failures, including timestamps, username failed, and originating ip. From these, various counts are derived. The only information unique to this app, are the counts, and the duration records are held for. All other information originates from the system. In a compromise, the data can be compromised, but the point is to avoid being compromised. This data already exists, floating about the system.

This app is not recommended for large corporations, financial interests, large teams, or in matters of distrusted access (it won't help with that).

Server environments are the primary target for this app, as end-users are generally too-small of a target to substantially benefit. That said, this software does work on laptops and workstations as-well.

Interacting with the firewall and event logs is an administrative capacity. Both apps require running as administrator to function.

1. Obtain a copy of the "Client Run Folder" from the downloads page.
2. Note the files FWM_Client_02.exe and FWM_ClientViewer_02.exe. The client is a console application, that can be automated or run manually. The viewer reads information generated by the client.
3. Launch the viewer app first. This ensures a settings file is generated in the data folder that uses safe defaults.
4. Use the "Settings" tab, to make any adjustments. By default, firewall management is turned off. It is recommended to run with firewall management off at-first, until you have had a chance to see what your failed login counts look like.
5. Save any settings changes at the bottom of the tab, and close the Viewer app.
6. Run the Client (console) app, and allow it to finish, which should take anywhere from a few seconds to a few minutes, depending upon how much volume exists, and whether or not you decided to manage the firewall now. Note: if you set "Is Headless?" to false in the Settings tab, the console will remain open so you can see what it posted. Alternatively, you can look in ./Logs/Client to view the same information.
7. Open the Viewer app, and use the Data View tab to view recent login failures. The default query is to look back 30-days, with an option to adjust this. If you were managing the firewall, any new rules generated will be shown on the "Firewall Rules" tab.

• There is a known-bug when viewing firewall rules. The viewer loads data at app start, and only refreshes from memory using the refresh button. To see new changes made by the Client to the firewall, it is necessary to reopen the viewer. i.e. - if you leave the viewer open while the console runs, the Firewall Rules tab will not reflect the changes until relaunching the viewer.

Some help is available in the Viewer app, on the Settings tab. This is a more exhaustive explanation of those settings. If you only want to observe, you can run out-of-the-box, and view the last week of failed logins using defaults. If you want to manage the firewall, by tracking failed logins over a period of 1-week prior, expire the rules used to block them 1-week later, and block any IP with 20 or more failures, you can simply turn Manage Firewall "True" and run or automate, with the understanding the console app must run again to process expired rules (schedule or automate). For other scenarios, see below:

This is where all files and folders for application data, logs, reports, and etcetera are located. The only purpose of base directory, is if you want to store your executables separate from data. Base directory points to the data, and its associated folders.

To be headless, is to lack a monitor. More specifically, being headless, means there is no need to keep the console app open once it is finished. No one is looking. When automating/scheduling, Is Headless must be True, or the console may continue running idle in the background. The only reason to set false, is if you are manually running the Client, and want it to remain open once complete.

The default of 100,000 is normally large enough to handle all events in the original OS file, but this entirely depends upon whether you have a custom EventLog configuration. If your file-size is huge, you can use this setting to limit how many OS events are processed by the Client. Under regular conditions, set high enough to process everything.

Pairs with Multi-Instance. An instance, is the case of you running the app. If you open it again while it is running, you have two-instances. Instance Name is used to further define what an instance actually is. Under normal conditions, it is bad to run the same exact console, on the same exact files, simultaneously. However, if you want to run two copies of the software, on different data, simultaneously, there is no conflict. Under this condition, you can set a different instance name in the settings of one copy, run both, without violating Multi-Instance=False. This is a deliberate work-around, to a common-sense safety railing.

Determines whether multiple copies of the same app, with the same Instance Name, are permitted to run at the same time.

This is a necessary feature, that does not exist yet. In other documents, it is referred to as "Pass List". This is intended to be a list of pre-approved IPs, to prevent internal infrastructure from being blocked, should a misconfigured script fail to login repeatedly.

The most important setting. This is the path where your OS events files are. The app is preconfigured to a common default location on some systems. It is entirely reasonable, to not want to read directly off the running log. If you run a script to copy the Security.evtx file to a working folder, this allows you to point to another path. Regardless, the path must contain the security file you intend to monitor.

Reports are curretly dumped to the ./Reports folder (where ./ is the Base Directory). This prefix allows you to group report files differently by name if required.

The most dangerous setting. When True, the client will automatically generate firewall rules based upon the other firewall settings. IPs are effectively blocked, and traffic halted, on TCP and UDP. If your firewall settings are carelessly configured, it can potentially lead to serious blockages (i.e. employee fails 4 times and gets blocked for a week). Check your settings carefully, and better, run first and know what the risks look like.

How many failures, over a time-span, are you willing to accept before blocking someone? Advice is to consider some failures nominal. Even a low number like 10 can be too low, if you are looking over a week or month.

This is a small piece of text, that leads the firewall name when viewed in Windows Firewall. The rest of the name is currently comprised of the IP itself, and the first character of the protocol being blocked. This setting makes rules autmatically generated by the console easy to locate in the stock OS management tools.

This addresses a logical problem. It would be easy to generate a guid, track it, and name a rule. The problem is human. There is no reason for an admin to go into Windows Firewall, and not know what they are looking at, or be able to make their own changes easily.

How long to look back when counting failed logins. Sorry for the minutes, but it had to be this way. There is a use-case for people, who want to block an offender for 5-10 minutes at a time. There needed to be a timeout that did not last for days, and the minutes to review must be less than Expire After Minutes.

How long should a firewall rule exist, before being unblocked? Also in minutes, and must be greater than Firewall Minutes To Review. It is important to note, rules are not expired from the app, they are removed from the firewall. If the same IP offends again, the known-rule will be restored. In other words, you will still see expired and deactivated rules in the Viewer app, simply as updated records.

This setting may go away, or be managed different. Valid settings are TCP, UDP, and ANY. Honest confession, I test with ANY (which blocks both), and may be blind to TCP and UDP settings. I have not tested heavily with TCP and UDP, particularly in areas of changing back and forth between protocols. Unless you know for sure you only want to block specifically on one, ANY is a good option.