DHCP flows whose first packet is a reply sent by the server (e.g. a unicast
ACK or OFFER, a reply to a relay agent) were recorded with the server as
client, as the direction of UDP flows is never swapped by the ports. The
Unexpected DHCP server check, the DHCP service and the DHCP Server tag relied
on that reversed direction (server = client of the flow using port 67), so
also relay agents got the DHCP service/tag, rogue servers were missed when
the flow started with a request, the alert blamed the client of the flow and
its description named the DHCP client.
Direction (Flow::checkL7Direction()):
* DHCP (v4) flows are decided by the first packet, BOOTREQUEST or BOOTREPLY
(op), as already done for DNS, NTP and ICMP.
* A flow is never swapped when its client would become a non-unicast address
(e.g. a reply sent to broadcast), as in check_swap(): this applies to all
the protocols checked there.
DHCP server of a flow (new Flow::isDHCPServerClient()): the server of the
flow, or its client for the replies sent to broadcast; by the ports only when
the direction has not been decided (e.g. collected flows). Used by
get_dhcp_srv_ip_addr(), by the DHCP service (relay agents talking to a DHCP
server no longer get it) and by the check. The DHCP fingerprint is taken only
from the DHCP client (port 68), not from relay agents.
Unexpected DHCP server check:
* Checks the flows whose DHCP server is a unicast address, on either side.
* Requires a reply from the server: the flows are checked when the protocol
is detected, if the server has already replied, and again when they end
(new has_flow_end parameter of UnexpectedServer), for the replies following
a request. A flow alerted twice keeps the first alert only. A request with
no reply (e.g. a renew to a server that no longer answers) raises no alert.
* The DHCP server is the attacker. UnexpectedServer now gives most of the
score to the attacker set by buildAlert() (unchanged for the DNS, NTP and
SMTP checks, which blame the client).
* The description names the DHCP server (server_ip of the alert), also when
it is the client of the flow.
* Relay agents forwarding to a configured DHCP server are still allowed.
Documentation of the check updated.
DHCPv6 is not changed.
Function codes 0x28 and 0x29 were swapped: 0x28 is PI-Service and
0x29 is PLC Stop. Also name all the known function codes (e.g.
upload/download ones, previously shown as plain numbers), using the
same names of the S7Comm flow details page.
- S7Comm allowed function codes help: use a decimal example (4,5,240);
hex values are not supported and were parsed as 0
- Use the check title for the ModbusTCP unexpected function code alert,
so check and alert share the same name
- Add missing flow_details.s7comm_functions label (empty row/header
in the S7Comm flow details page)
- Remove orphan s7comm_requests/responses/acks/userdata strings: these
counters are not exported by nProbe nor tracked by ntopng
- Use the check title for the S7Comm unexpected function code alert,
so check and alert share the same name
- Add an "errors" field unit, for S7Comm/Profinet error thresholds
