banshee/windows-collection/windows/winrm/tcp

TCP connections of a Windows, by WinRM

Returns the TCP connections of a Windows, IPv4 and IPv6 together: those established, those waiting to be closed on either side (TIME-WAIT, CLOSE-WAIT), the listening ports and the total. Three watches are proposed, all unchecked: what is normal depends on the role of the server.

How it works

The collector runs one PowerShell script, by WinRM, that reads Get-NetTCPConnection (the CIM class MSFT_NetTCPConnection) and counts the connections by state on the target:

ConvertTo-Json -Compress -InputObject @(Get-NetTCPConnection | Group-Object State -NoElement | Select-Object Name, Count)

WinRM hands the script to PowerShell itself: no shell stands in between, and the script is the one of windows/ssh/tcp, without the powershell -Command "…" that cmd.exe needs there. The default shell of an OpenSSH server does not matter here.
Get-NetTCPConnection, of the module NetTCPIP, ships with every Windows from Server 2012 and Windows 8 on.
One object per state present: its name, in English whatever the language of Windows (Established, TimeWait, CloseWait, Listen…), and its number of connections.
The counting happens on the target, so that a server with a hundred thousand connections returns a few lines.
The total counts every state, Bound and the states of opening and closing included.
Nothing is skipped at the first run: they are counts, not counters.
No connection at all stops the collector as misconfigured: the collector's own WinRM connection is one, and reading none is reading nothing. So does an answer that is not the expected JSON.

Nothing is written to the Windows: the script only reads.

Prerequisites

The WinRM service of Windows listening in HTTPS. The service runs by default on every Windows Server from 2012 on (on a desktop Windows, winrm quickconfig starts it), with an HTTP listener only; the HTTPS listener needs a certificate: - a certificate for server authentication in the store of the computer (Cert:\LocalMachine\My), bearing the name the poller connects to: issued by the authority of the company, or made on the server by New-SelfSignedCertificate -DnsName <name> -CertStoreLocation Cert:\LocalMachine\My from Windows Server 2012 R2 on (Windows Server 2012 does not have this command); - then the listener: winrm quickconfig -transport:https finds a certificate of an authority by itself, but refuses a self-signed one; the command that takes either, on every Windows from Server 2012 on, is winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname="<name>";CertificateThumbprint="<thumbprint>"} in cmd.exe, the thumbprint being the one Windows shows for the certificate.
The Windows firewall open to the poller on TCP 5986, which creating the listener does not do: New-NetFirewallRule -DisplayName "WinRM HTTPS" -Direction Inbound -Protocol TCP -LocalPort 5986 -Action Allow in PowerShell. A listener on another port is set in protocol:winrm:port.
The certificate judged by the poller before the account is sent, by the TLS profile of the probe: issued by an authority the system of the poller knows, by an authority added in protocol:tls:authorities, or pinned in protocol:winrm:fingerprint, the way for a self-signed certificate; the pin is not needed when the Security settings trust the first WinRM fingerprint presented. The fingerprint is sha256: followed by the SHA-256 of the certificate in 64 lower-case hexadecimal characters; from a machine that reaches the port, openssl s_client -connect <name>:5986 </dev/null | openssl x509 -noout -fingerprint -sha256 prints it, in capitals, with colons to take off. A certificate whose name is not the address of the host is judged on the name set in protocol:tls:server-name.
NTLM authentication, which the WinRM service accepts as installed (Negotiate = true in winrm get winrm/config/service/auth): the password never travels, only an answer computed with it. A domain that refuses NTLM is not served.
Windows PowerShell 3.0 or later, as shipped with every Windows from Server 2012 and Windows 8 on (3.0 on Server 2012, 4.0 on 2012 R2, 5.1 from 2016 on).
An account for monitoring, without administrator rights, local or of the domain, set in protocol:winrm:user (account, DOMAIN\account or account@domain) with its password in protocol:winrm:password, member of the local group "Remote Management Users", which opens WinRM to an account that is not an administrator. No other group: Get-NetTCPConnection is open to any account.

Outputs

Name	Label	Unit	Per instance
`established`	Established connections	—	no
`time-wait`	Connections in TIME-WAIT	—	no
`close-wait`	Connections in CLOSE-WAIT	—	no
`listen`	Listening ports	—	no
`total`	TCP connections	—	no

Watches

Name	Title	Kind	Defaults	Checked by default
`too-many`	Too many TCP connections	above a threshold, on `established`	no threshold: to set on the probe	no
`unusual`	Unusual number of connections	off its habit, on `established`	normal sensitivity, no floor	no
`close-wait`	Connections left open	above a threshold, on `close-wait`	warning above 100, for 3 runs; no critical	no

"Unusual number of connections" needs the history of the measure: until the poller has learnt it, the watch says it is learning and raises nothing. CLOSE-WAIT piling up says an application does not close its connections.

Limits

A certificate of the listener that expires, or a pinned one that is renewed, stops every WinRM collector of the host: the network/tls/certificate collector of banshee/web-collection, deployed on port 5986, watches it.
The count is a moment, read once per run: a burst of short connections between two runs is not seen.
Connections are not told apart by port nor by address.
Not yet checked on a real Windows: how long Get-NetTCPConnection takes on a server with many connections.