I don't see a reason to remove the rule in general but: 1) Having the telnet *client* present isn't really a big deal if you have pretty much any scripting language, or modern SSH that allows the NULL cipher 2) All rules are 'unless you need them' at which point you can tailor them out of your profile. You won't pass the default tests but the default tests are just that, defaults. Trevor On Fri, Nov 1, 2019 at 12:21 PM Vojtech Polasek <vpolasek(a)redhat.com&gt; wrote: -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788 -- This account not approved for unencrypted proprietary information --

Hello, On Friday, November 1, 2019 12:21:37 PM EST Vojtech Polasek wrote: Why are they using such an insecure protocol? One thing to consider, is telnet (teletype network) starts at RFC 15. Yes, 15. They did not think about security back then. The reason that telnet is asked to be removed goes all the way back to the RHEL5 SNAC guide which says this: ==== 3.2.2 Telnet Is there a mission-critical reason for users to access the system via the insecure telnet protocol, rather than the more secure SSH protocol? If not, ensure that the telnet server is removed from the system: # yum erase telnet-server The telnet protocol uses unencrypted network communication, which means that data from the login session, including passwords and all other information transmitted during the session, can be stolen by eavesdroppers on the network, and also that outsiders can easily hijack the session to gain authenticated access to the telnet server. Organizations which use telnet should be actively working to migrate to a more secure protocol. 3.2.2.1 Remove Telnet Clients In order to prevent users from casually attempting to use a telnet server, and thus exposing their credentials over the network, remove the telnet package, which contains a telnet client program: # yum erase telnet If Kerberos is not used, remove the krb5-workstation package, which also includes a telnet client: # yum erase krb5-workstation ==== There are also many other problems with telnet. Besides the obvious lack of confidentiality mentioned in the SNAC guide, it is susceptible to brute force attacks. For example, telnet is the infection vector for Mirai malware. It's able to brute force the login because the connection is fast and the server can give away if an account is valid or not by timing. Also, because its unencrypted, it has no integrity. Meaning that telnet is subject to tcp session hijacking: https://www.exploit-db.com/papers/13587 Because telnet is unencrypted, there is no way to verify what it connects to really is what it thinks it is. (No key or certificate validation.) That means arp spoofing, icmp redirects, and other means of poisoning the local network can aid attackers doing a MITM attack. The numbers and problems with telnet are vast and long. -Steve