LoFP LoFP / t1133

t1133

TitleTags
a security group may be created by a system or network administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment. security group creations by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
a vpn ssl web portal can be added for legitimate purposes.
administrative activity
administrators may legitimately add security group rules to allow traffic from any ip address or from specific ip addresses to common remote access ports.
developers may have a legitimate use for nodeports. for frontend parts of an application you may want to expose a service onto an external ip address without using cloud specific loadbalancers. nodeport can be used to expose the service on each node's ip at a static port (the nodeport). you'll be able to contact the nodeport service from outside the cluster, by requesting <nodeip>:<nodeport>. nodeport unlike loadbalancers, allow the freedom to set up your own load balancing solution, configure environments that aren't fully supported by kubernetes, or even to expose one or more node's ips directly.
iot (internet of things) devices and networks may use telnet and can be excluded if desired. some business work-flows may use telnet for administration of older devices. these often have a predictable behavior. telnet activity involving an unusual source or destination may be more suspicious. telnet activity involving a production server that has no known associated telnet work-flow or business requirement is often suspicious.
ipv4-to-ipv6 mapped ips
legitimate logon attempts over the internet
legitimate or intentional inbound connections from public ip addresses on the rdp port.
legitimate usage of teamviewer
legitimate use by administrative staff
network acl's may be created by a network administrator. verify whether the user identity should be making changes in your environment. network acl creations by unfamiliar users should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
public access is a common configuration used to enable access from outside a private vpc. ensure that the instance should not be modified in this way before taking action.
some network security policies allow rdp directly from the internet but usage that is unfamiliar to server or network owners can be unexpected and suspicious. rdp services may be exposed directly to the internet in some networks such as cloud environments. in such cases, only rdp gateways, bastions or jump servers may be expected expose rdp directly to the internet and can be exempted from this rule. rdp may be required by some work-flows such as remote access and support for specialized software products and servers. such work-flows are usually known and not unexpected.
ssh usage may be legitimate depending on the environment. access patterns and follow-on activity should be analyzed to distinguish between authorized and potentially malicious behavior.
this rule may trigger in cases where a user has routine work patterns that result in infrequent authentications.
unknown
unlikely
valid clusters may be created by a system or network administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment. cluster creations by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
vnc connections may be received directly to linux cloud server instances but such connections are usually made only by engineers. vnc is less common than ssh or rdp but may be required by some work-flows such as remote access and support for specialized software products or servers. such work-flows are usually known and not unexpected. usage that is unfamiliar to server or network owners can be unexpected and suspicious.
vpn ssl settings can be changed for legitimate purposes.