ntop Risk flags (
,
,
)
ntop Risk flags (
,
,
)There are a large number of causes for these flags.
Very few of these can be explicitly identified as hostile activity, but rather can occur from a variety of causes (with network misconfiguration being the most common). However, because the conditions COULD result from 'hostile' activity or serious network configuration problems, ntop monitors and reports them for the systems administrators review.
The specific condition or conditions are indicated by the colored flags and descriptive text or short tags on the host information report:
Note that many of these warnings can be produced if a mirrored (Cisco span) traffic source is being monitored and the -o | --no-mac flag is not specified. In this case, the MAC layer address for packets may be incorrect and that will confuse ntop.
High risk - problems which are rarely benignntop will report this problem for hosts where a single MAC address (layer 2) is found on packets from several IP (layer 3) addresses. There are a number of possible causes:
It's not normal unless you're using Sun servers, so check it out!
Flag/Counter: HOST_DUPLICATED_MAC
ntop will report this problem for those hosts that produced traffic on ports where we should see no traffic (e.g. port zero). Port 0 is a reserved port in tcp/ip networking, (see IANA) so that it should not be used by the tcp or udp protocols. It's not normal and has been used in hostile attempts to map networks (as many devices do not block it, even if the device blocks everything else), so check it out!
Flag/Counter: HOST_IP_ZERO_PORT_TRAFFIC
Unexpected packets (e.g. traffic to closed port or connection reset)ntop has detected an anomalyous situation with the network mask for a host. This occurs if ntop determines that the address is a broadcast address, but the actual packet destination is different.
Among other causes, ntop detects this problem when a host sends a packet to a broadcast address where the destination MAC address is not FF:FF:FF:FF:FF:FF. This could simply indicate that the host is a bridge.
The most likely cause of this is a misconfiguration, which SHOULD be fixed.
Using the wrong netmask is quite common on networks where the netmask has changed and some of the hosts still use the old netmask.
Most hosts use the netmask to determine the gateway router address, by setting the host portion of the address to 0x1 (i.e. the gateway for 192.168.1.1/24 is 192.168.1.1). If problems do occur, selecting the wrong gateway for non-local packets usually leads to apparent failure of the entire non-local network (support call: "The network is down"). It can also cause high packet loss, collisions, ttl expiration and other network problems.
Note: ntop defines the broadcast address as either zero (0.0.0.0) or an address which has a host part of 0. Perfectly normal. However, ntop determines the network and host portions for the monitored packet's address based on the actual configuration of ntop's own NIC. So if ntop's NIC has a different configuration it will tag traffic as having the wrong mask.
Flag/Counter: HOST_WRONG_NETMASK
ntop keeps tabs on the number of hosts contacted by each host being monitored, called 'peers'. Usually a host contacts a limited number of hosts in a short amount of time. This flag indicates that the flagged host has contacted a large number of hosts.
If the number of peers contacted - either sending to or receiving from - exceeds a configurable constant (globals-defines.h, CONTACTED_PEERS_THRESHOLD, default value of 1024), this is reported.
This is not always a problem - some servers (e.g. DNS/SMTP servers) may routinely contact 100s or 1000s of hosts in performance of their function. Hosts running P2P applications, often contact many different hosts to resolve a request.
However, this behavior - contacting many different hosts in a short period - is also indicative of a worm. If you see this flag, you should carefully analyze the host in order to see whether it is infected.
Flag/Counter: totContactedSentPeers and/or totContactedRcvdPeers
ntop has seen one or more packets with both the SYN and FIN flags set. This violates the tcp/ip protocol and is most often part of a port scan or denial of service attack. The flagged host is the SENDER of these malformed packets and should be investigated.
Flag/Counter: synFinPktsSent
ntop has seen one or more packets with unusual combinations of flags. This is usually seen as part of a port scan. The flagged host is the SENDER of these packets is the machine performing the port scan.
Flag/Counter: ackXmasFinSynNullScanSent
ntop has seen one or more tiny fragments (that is 128 or fewer octets) SENT from the flagged host. This is not normal and can indicate a misconfigured router or other device, or can be part of an attack (tiny fragments have been used to slip hostile packets past firewalls). Check it out.
Flag/Counter: tinyFragmentSent
ntop has seen one or more fragmented ICMP packets SENT by the flagged host. ICMP packets are small and under normal operations should never be fragmented. This is either a misconfigured router/device or hostile. Check it out.
Flag/Counter: icmpFragmentSent
ntop has seen one or more packets SENT by the flagged host where the fragments overlap. It's possible, but rare, to see this on network links which have problems, where lost packets are causing retransmission errors - perhaps ntop is seeing a fragment that never makes it to the end station. But it should be very, very, rare. This has also been used to crash Intrusion Detection Systems (IDS) prior to an attack.
Flag/Counter: overlappingFragmentSent
ntop has seen one or more malformed packets, that is packets where the length field indicates a length less than the minimum header length for that type of packet. This may be set for TCP, UDP and/or ICMP packets. The flagged host is the RECEIVER of these packets, which often indicate a failing router or bad network connection.
Flag/Counter: malformedPktsRcvd
Unexpected packets (e.g. traffic to closed port or connection reset)ntop has seen one or more packets with the ACK and RST flags set. This usually means that the contacted host has rejected the tcp session initiation and does not indicate a problem. A high count should be looked at - perhaps a machine is attempting to contact a host which used to provide a service (e.g. ntp).
Flag/Counter: rejectedTCPConnRcvd
ntop has seen one or more ICMP Destination Unreachable replies. This means that the flagged host has SENT a packet to a remote host's port that is not accepting these connections. It is usually seen when there is a misconfiguration of the sending host, such as the wrong dns server address.
Flag/Counter: udpToClosedPortRcvd
ntop has seen one or more packets SENT by the flagged host to the 'diagnostic' ports, that is to/from port 7 or to ports 9, 13 or 19. When the internet was a smaller, friendlier place, these provided trivial information and ways to check if a remote machine was operational. These are rarely seen today and so are flagged.
Flag/Counter: udpToDiagnosticPortSent
ntop has seen one or more packets with the RST flag set. This can be normal, although should be rare. A large number of RST packets is also seen as part of a port scan. The flagged host is the RECEIVER of these packets and is the machine being scanned.
Flag/Counter: rstPktsRcvd
ntop has seen one or more sessions established by the flagged host where no data was actually sent or received. This can happen, but is most often part of a attempt to map a network. ntop does not differentiate between the host performing the scan and the host being scanned, so it should be investigated with the understanding that your user might have been the target, not the perpetrator.
Flag/Counter: closedEmptyTCPConnSent
ntop has seen one or more ICMP Port Unreachable messages. These are perfectly legal, although optional according to the standard. It means that the packet sent FROM the flagged host reached it's intended destination, but there was no process configured on that host to accept it. The remote process could have died or something else could have happened. However, most machines don't return this and many routers filter it out since it can be used to map remote networks.
Flag/Counter: icmpPortUnreachRcvd
ntop has seen one or more ICMP Host Unreachable or Network Unreachable messages. Again, perfectly legal although often filtered. Means that the host the flagged machine was attempting TO connect to doesn't exist. Large numbers of these can sometimes indicate a worm program attempting to spread by contacting random IP addresses.
Flag/Counter: icmpHostNetUnreachRcvd
ntop has seen one or more ICMP Protocol Unreachable messages. These are perfectly legal, although optional according to the standard. It means that the packet sent FROM the flagged host reached it's intended destination, but there was no process configured on that host to accept the protocol it used. However, most machines don't return this and many routers filter it out since it can be used to map remote networks.
Flag/Counter: icmpProtocolUnreachRcvd
ntop has seen one or more ICMP Host Administratively Prohibited or Net Administratively Prohibited messages. These are obsolete and shouldn't be seen (there's a newer, rarely used code that indicates the request was filtered). Since it's unusual, you should investigate.
Flag/Counter: icmpAdminProhibitedRcvd