Simple network checks that can prevent major security issues

Certain changes in services or devices can often be overlooked; failure to recognize even subtle changes can later result in unpleasant consequences.
Below are several examples of such incidents; the checks described are rather lightweight and can be run frequently for critical network assets.
The cases below assume that any unexpected change in a device’s current state should be treated as a potential security issue.
Domain names
Although not directly related to domain names themselves, SSL certificates should always be up to date; if a service uses an invalid or expired certificate, it may be rejected by clients, browsers or security-sensitive integrations.
A different kind of check includes comparing domain registration data with the information you have on file. Today this is better described as a WHOIS/RDAP check than a WHOIS-only check. This can be performed by a custom monitor: any unexpected change should be treated as an alarm, including contact details and name server records.
DNS records
DNS (Domain Name Service) is a decentralized and hierarchical system that maps human-readable names to IP addresses. DNS largely determines which devices respond to which symbolic names, so unauthorized changes in DNS responses should always be investigated carefully.
In most situations, a DNS record change may mean a security risk unless it is known that the change was applied by an authorized party. Thus, it is important to alert on DNS record changes. Create DNS monitors using a variety of DNS servers for all records crucial for normal intranet functioning, and validate the expected response values so there are no attempts to redirect communication to third-party IPs. To reduce false alarms caused by transient issues, it is also worth using spike filtering where appropriate.
Open ports
There is a well-known tool for network exploration and security auditing, Nmap. Among other functions, Nmap can scan a host for open ports to determine which ports accept connections and what kinds of services may be present on them.
Under normal circumstances, the set of expected open ports on a critical system should not change significantly over time. If a new open port appears and is not properly justified, it should be treated as a security issue. That is especially important for systems inside the intranet: an unexpected listening port may indicate unauthorized software, a configuration drift, or malicious activity that can threaten other systems on the same network.
A relatively simple script that scans known devices with Nmap from time to time can be used to set up corresponding custom monitors and detect changes in open ports. While it still requires precautions to avoid spurious false alarms, it can serve as an early warning system for possible attempts to compromise the network.
Important: scanning itself can be viewed as a kind of attack; before setting up port-scanning monitors, make sure the source of scans is properly safelisted on every target device and that such scans are only performed from authorized monitoring hosts.
Conclusion
Do you need assistance in setting up the mentioned monitors? Feel free to contact us.