You don't want to enable the
dgram (UDP) one.
That allows an attacker to make your machine send UDP packets with any content, and if attackers are able to have packets with spoofed source address delivered to you, that means any UDP packet to any destination.
For instance if the attacker does:
packit -t UDP -s 10.10.10.10 -S 7 -d 10.10.10.11 -D 7 -p have-fun-with-that
Where 10.10.10.11 is your IP address and 10.10.10.10 is the IP address of another machine in your network that also has the dgram/UDP
echo service enabled, then that will start a continuous ping-pong between those two (note that UDP
daytime (among the services built in most
inetd implementations) have the same problem and should be avoided as well).
So by sending just one packet (and he can inject a few more to make matters worse), the attacker is managing have the whole bandwidth between the two victims used up, with minimal effort.
It becomes even more interesting when your start to use broadcast messages.
Even if your network will not allow spoofed packet to get to you (and they can't really do that for packets coming from the internet), others may not. So you may still be tricked into that ping-pong game with them as well (acting as victim and unwilling attacker).
Enabling the UDP
echo service (and especially if you expose it over the internet) is a bit like willingly joining a botnet (with the botnet actions limited to have arbitrary UDP packets sent).
The fact that it allows anyone with access to your
echo service to have you send any UDP packet anywhere also means they can do something reprehensible in your name (and for instance have your IP address banned for abuse) or possibly by-pass some firewalling mechanism.
For instance, if your machine has several interfaces (and reverse path filtering not enabled), for instance, one with address 10.0.0.1/24 and another one with 192.168.1.123/24, an attacker on host 10.0.0.2 could forge a NAT-PMP packet with source 192.168.1.1:5351 and destination 10.0.0.1:7. And your
echo would be sent to 192.168.1.1 and if that's a router/firewall accepting NAT-PMP, the attacker could effectively punch holes in that firewall using your machine as a proxy (and instead of a NAT-PMP packet, that could also be a SNMP PUT packet or anything else like that ping-pong starter packet evoked above).
The problem with that
echo is that it replies with the same data as it receives. That UDP echo has been superseded by ICMP
echo (as sent by the
ping command) where you have different
ECHO_REPLY packets and those are different from UDP packets. So one cannot do much harm with a spoofed
ECHO_REQUEST (see the Smurf attack though).
More reading at: