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:

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.  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:


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.


> > 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

Reply via email to