1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<!-- ntop v3.0 release, Burton Strauss, Dec2004 -->
<html>
<head>
<!-- Validates as HTML 4.01 Transitional with the addition of the following tag -->
<!-- <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> -->
<meta http-equiv="Expires" content="0">
<meta http-equiv="Pragma" content="no-cache">
<meta http-equiv="Content-Style-Type" content="text/css">
<meta http-equiv="Window-target" content="_top">
<meta name="ROBOTS" content="NOINDEX,NOFOLLOW">
<meta name="description" content="ntop (http://www.ntop.org) status for a network.">
<meta name="author" content="ntop">
<meta name="generator" content="ntop v3.1">
<link rel="stylesheet" type="text/css" href="/style.css">
<style type="text/css">
.flagcounter { font-size: 75%; }
</style>
<title>ntop risk flag information</title>
<!--#include virtual="/menuHead.html" -->
</head>
<body background="white_bg.gif">
<!--#include virtual="/menuBody.html" -->
<h1><a href="http://www.ntop.org/" target="_top"><img border="0" src="ntop.gif" width="59" height="49" alt="ntop logo"></a>
ntop Risk flags (
<img src="Risk_high.gif" alt="High risk" width="12" height="14" border="0">,
<img src="Risk_medium.gif" alt="Medium risk" width="11" height="13" border="0">,
<img src="Risk_low.gif" alt="Low risk" width="10" height="11" border="0">
)</h1>
<p>There are a large number of causes for these flags.</p>
<p>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, <b>ntop</b> monitors and reports them for the
systems administrators review.</p>
<p>The specific condition or conditions are indicated by the colored flags and descriptive
text or short tags on the host information report:</p>
<p>Note that many of these warnings can be produced if a mirrored (Cisco span) traffic source is
being monitored and the
<tt>-o | --no-mac</tt> flag is <b>not</b> specified. In this case, the MAC layer address
for packets may be incorrect and that will confuse <b>ntop</b>.</p>
<hr />
<h2><i><img src="Risk_high.gif" alt="High risk" width="12" height="14" border="0">
High risk - problems which are rarely benign</i></h2>
<h3><a name="#2">Duplicated MAC</a></h3>
<p><b>ntop</b> 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:</p>
<ul>
<li>The host legitimately has multiple IPs assigned.</li>
<li>dhcp + sticky-hosts - If <b>ntop</b> is being run with the stick-hosts option and dhcp
addressing is being used, it's possible for a host to receive address a.b.c.d, and then
disconnect from the network. If that address is reassigned to another host, then when
the first host reconnects to the network it will receive a differnent IP address. If
the stick-hosts is not enabled, it's very likely that the first user of a.b.c.d would
be purged as inactive before the dhcp lease is reassigned. This is BENIGN.</li>
<li>MAC spoofing - where a device deliberately changes it's MAC address to 'spoof'
another device. Many home users do this, where their router spoof's the address of
the network card so that their upstread Cable or DSL provider doesn't seen the change
when you install a router. But bad guys also do this to bypass MAC level filters.</li>
<li>Some hardware - notably Sun - use the same MAC address for all of the NICs attached
to the host. If <b>ntop</b> is monitoring these multiple segments, it will see
'spoofed' packets.</li>
<li>Someone is sending spoofed packets. This is probably hostile.</li>
</ul>
<p>It's not normal unless you're using Sun servers, so check it out!</p>
<p class="flagcounter">Flag/Counter: HOST_DUPLICATED_MAC</p>
<br />
<h3><a name="#3">Port Zero Traffic</a></h3>
<p><b>ntop</b> 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 <a href="http://www.iana.org/assignments/port-numbers" title="IANA port number assignments">IANA</a>)
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!</p>
<p class="fontcounter">Flag/Counter: HOST_IP_ZERO_PORT_TRAFFIC</p>
<br />
<hr />
<h2><i><img src="Risk_medium.gif" alt="Medium risk" width="11" height="13" border="0">
Unexpected packets (e.g. traffic to closed port or connection reset)</i></h2>
<h3><a name="#1">Wrong network mask</a></h3>
<p><b>ntop</b> has detected an anomalyous situation with the network mask for a host.
This occurs if <b>ntop</b> determines that the address is a broadcast address, but the
actual packet destination is different.</p>
<p>Among other causes, <b>ntop</b> 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.</p>
<p><i>The most likely cause of this is a misconfiguration, which SHOULD be fixed.</i></p>
<p>Using the wrong netmask is quite common on networks where the
netmask has changed and some of the hosts still use the old netmask.</p>
<p>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.</p>
<p>Note: <b>ntop</b> defines the broadcast address as either zero (0.0.0.0) or an address which
has a host part of 0. Perfectly normal. However, <b>ntop</b> determines the network and host
portions for the monitored packet's address based on the actual configuration of <b>ntop</b>'s
own NIC. So if <b>ntop</b>'s NIC has a different configuration it will tag traffic as having
the wrong mask.</p>
<p class="flagcounter">Flag/Counter: HOST_WRONG_NETMASK</p>
<h3><a name="#4">Too many host contacts</a></h3>
<p><b>ntop</b> 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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p class="flagcounter">Flag/Counter: totContactedSentPeers and/or totContactedRcvdPeers</p>
<h3><a name="#5">(Sent:syn-fin)</a></h3>
<p><b>ntop</b> has seen one or more packets with both the <i>SYN</i> and <i>FIN</i> 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.</p>
<p class="flagcounter">Flag/Counter: synFinPktsSent</p>
<br />
<h3>(Sent:xmas)</h3>
<p><b>ntop</b> 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.</p>
<p class="flagcounter">Flag/Counter: ackXmasFinSynNullScanSent</p>
<br />
<h3>(Sent:Tiny frag)</h3>
<p><b>ntop</b> 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.</p>
<p class="flagcounter">Flag/Counter: tinyFragmentSent</p>
<br />
<h3>(Sent:icmp frag)</h3>
<p><b>ntop</b> 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.</p>
<p class="flagcounter">Flag/Counter: icmpFragmentSent</p>
<br />
<h3>(Sent: overlapfrag)</h3>
<p><b>ntop</b> 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 <b>ntop</b> 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.</p>
<p class="flagcounter">Flag/Counter: overlappingFragmentSent</p>
<br />
<h3>(Rcvd:malformed)</h3>
<p><b>ntop</b> 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.</p>
<p class="flagcounter">Flag/Counter: malformedPktsRcvd</p>
<br />
<hr />
<h2><img src="Risk_low.gif" alt="Low risk" width="11" height="13" border="0">
<a name="#6">Unexpected packets</a> (e.g. traffic to closed port or connection reset)</h2>
<h3>(Rcvd:rejected)</h3>
<p><b>ntop</b> has seen one or more packets with the <i>ACK</i> and <i>RST</i> 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).</p>
<p class="flagcounter">Flag/Counter: rejectedTCPConnRcvd</p>
<br />
<h3>(Sent:udp to closed)</h3>
<p><b>ntop</b> has seen one or more ICMP <i>Destination Unreachable</i> 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.</p>
<p class="flagcounter">Flag/Counter: udpToClosedPortRcvd</p>
<br />
<h3>(Sent:udp to diag)</h3>
<p><b>ntop</b> 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.</p>
<p class="flagcounter">Flag/Counter: udpToDiagnosticPortSent</p>
<br />
<h3>(Rcvd:rst)</h3>
<p><b>ntop</b> has seen one or more packets with the <i>RST</i> 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.</p>
<p class="flagcounter">Flag/Counter: rstPktsRcvd</p>
<br />
<h3>(Sent:closed-empty)</h3>
<p><b>ntop</b> 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. <b>ntop</b> 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.</p>
<p class="flagcounter">Flag/Counter: closedEmptyTCPConnSent</p>
<br />
<h3>(Rcvd:port unreac)</h3>
<p><b>ntop</b> has seen one or more ICMP <i>Port Unreachable</i> 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.</p>
<p class="flagcounter">Flag/Counter: icmpPortUnreachRcvd</p>
<br />
<h3>(Rcvd:hostnet unreach)</h3>
<p><b>ntop</b> has seen one or more ICMP <i>Host Unreachable</i> or <i>Network Unreachable</i>
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.</p>
<p class="flagcounter">Flag/Counter: icmpHostNetUnreachRcvd</p>
<br />
<h3>(Rcvd:proto unreac)</h3>
<p><b>ntop</b> has seen one or more ICMP <i>Protocol Unreachable</i> 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.</p>
<p class="flagcounter">Flag/Counter: icmpProtocolUnreachRcvd</p>
<br />
<h3>(Rcvd:admin prohib)</h3>
<p><b>ntop</b> has seen one or more ICMP <i>Host Administratively Prohibited</i> or
<i>Net Administratively Prohibited</i> 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.</p>
<p class="flagcounter">Flag/Counter: icmpAdminProhibitedRcvd</p>
<br />
<hr />
</body>
</html>
|
