Hello, On Friday, November 1, 2019 12:21:37 PM EST Vojtech Polasek wrote: > Dne 01. 11. 19 v 11:30 Vojtech Polasek napsal(a): > > I am fixing the following bugzilla: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1729222 > > > > Brief summary: as part of several profiles, in this case NCP profile > > in rhel7, we are removing the telnet package containing the Telnet > > client. > > > > But this removal of telnet package causes removal of the > > fence-agents-all package and this causes removal of VDSM.
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 > > So if an user wants to be compliant with NCP, they can't use VDSM nor > > some fence agents at the same time. > > > > I proposed a PR which removes the "package_telnet_removed" rule from > > rhel7, rhel8 and rhv4 profiles. > > > > https://github.com/ComplianceAsCode/content/pull/4958 > > > > I understand that Telnet server introduces a security risk because it > > uses unencrypted traffic, it is a common port attackers scan for etc. > > We are removing the telnet-server package and also making sure that > > the telnet service is disabled in two other separate rules. > > > > But do we really need to explicitly remove also the Telnet client? > > Especially if it prevents features like VDSM from working? I > > understand that it uses unencrypted traffic as well, but is it such a > > high security risk? > > > > Steve, anyone else, could you give an opinion on this please? > > > > Thank you, > > > > Vojta _______________________________________________ Open-scap-list mailing list Open-scap-list@redhat.com https://www.redhat.com/mailman/listinfo/open-scap-list
