adding SSG list.
Dne 01. 11. 19 v 11:30 Vojtech Polasek napsal(a):
Hello all,
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.
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
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@redhat.com wrote:
adding SSG list.
Dne 01. 11. 19 v 11:30 Vojtech Polasek napsal(a):
Hello all,
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.
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
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
On Fri, Nov 1, 2019 at 10:46 AM Trevor Vaughan tvaughan@onyxpoint.com wrote:
I don't see a reason to remove the rule in general but:
- 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
IIRC as of one of the OpenSSH 7.6 releases, a cipher of `none` is no longer allowed.
- 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.
This is for a layered product anyway which is starting to go through the security evaluation process, and tickets haven't been filed yet for them to remove their dependency on telnet.
Trevor
On Fri, Nov 1, 2019 at 12:21 PM Vojtech Polasek vpolasek@redhat.com wrote:
adding SSG list.
Dne 01. 11. 19 v 11:30 Vojtech Polasek napsal(a):
Hello all,
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.
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
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788
-- This account not approved for unencrypted proprietary information -- _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
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
If you are concerned about telnet, then you might want to lock down the interpreters. :)
From: vpolasek@redhat.com Sent: November 1, 2019 12:21 PM To: open-scap-list@redhat.com; scap-security-guide@lists.fedorahosted.org Reply to: scap-security-guide@lists.fedorahosted.org Cc: sgrubb@redhat.com Subject: Re: removing telnet client breaks fence agents
adding SSG list.
Dne 01. 11. 19 v 11:30 Vojtech Polasek napsal(a):
Hello all,
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.
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
_______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor... THIS MESSAGE IS FOR THE USE OF THE INTENDED RECIPIENT(S) ONLY AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, PROPRIETARY, CONFIDENTIAL, AND/OR EXEMPT FROM DISCLOSURE UNDER ANY RELEVANT PRIVACY LEGISLATION. No rights to any privilege have been waived. If you are not the intended recipient, you are hereby notified that any review, re-transmission, dissemination, distribution, copying, conversion to hard copy, taking of action in reliance on or other use of this communication is strictly prohibited. If you are not the intended recipient and have received this message in error, please notify me by return e-mail and delete or destroy all copies of this message.
scap-security-guide@lists.fedorahosted.org
-
Brent Kimberley -
Gabe Alford -
Steve Grubb -
Trevor Vaughan -
Vojtech Polasek