PathMRI

Overview/Features/Application-aware checks

Application-aware checks

Check an application,
not a port number.

Check a port, or check the whole application with one rule. Every application has roles: a server that listens, a client that calls, an agent that reports in. Each role needs its own ports, in its own direction. PathMRI ships that knowledge for 72 applications, so nobody has to rebuild it from a wiki page and a memory. Pick the role each side plays and every port it needs loads into the rule by itself. Run that rule before the install, and let it run on a schedule after it.

Download Read the manual
72
applications in the built-in library
124
components — server, client, agent, database, proxy, manager
328
ports, with direction: 252 inbound, 76 outbound
15
categories, from databases to CI/CD
Step one

Pick the roles, not the ports

Name the source, name the destination, and pick the application role each side plays — a database server, a web tier, an agent. Every port that role needs, inbound and outbound, loads into the rule by itself. Nobody types a port.

Step two

Check before you install

Run the rule while the change window is still open. In a restricted environment every path the application needs is verified before the rollout starts, and when a port is blocked PathMRI names the firewall and the rule that stopped it — instead of a blocked port turning up when the install is already half done.

Step three

Keep checking after

Set a schedule and the same rule runs again on its own. When somebody changes a firewall, a route or a host and a path breaks, you are notified. Nobody checks port by port, and nobody finds out from the users.

Assign the application to its hosts, and the library works a second time. Map a component onto a host or a host group and PathMRI knows which open ports that host is expected to have — so an unexpected listener stands out instead of being lost in a list. Not in the library? Add your own custom application, with its components and ports, and check it the same way.

See it run

Eighty seconds through the console: two hosts get their VMware vCenter roles, one rule picks up all seven ports from those roles, the check runs, and the one blocked port is clicked to see which firewall and which rule stopped it.

Next

Rogue ports and baselines The same mapping tells you which open ports nobody asked for. Path verification What each of those ports is actually checked with. Drift detection Re-run the application’s paths on a schedule and watch for change.