Hi SSSd team,
I was advised in IRC to send email to the group in order to discuss this functionality.
I am thinking about taking on implementing it as I have a need in such functionality. But I can also see that it would perhaps be interesting to many other users as well.
Preamble:
Now SSSd's LDAP backend only provides ability to have a restriction via host record to restrict access by verifying local hostname of machine (by either explicitly allowing or denying access as hostname) using ldap_access_order=host.
My thought is that it would be good to have ability to perform similar access verification for rhost (IP or via DNS).
Why is it relevant to me - I am (as part of my work) managing 1k+ hosts where we restrict ssh access to specific IP(s) using sshd_config AllowUsers option using (*@ip_address) record to only allow logins from well protected bastion server. It went pretty bad when IDC disaster happened and the bastion was N/A - there was no way to access hosts until access to bastion was restored. Meanwhile we manage ssh users and sudo access with LDAP, so it would be perfect if we could manage this in there as well.
Why is it relevant to others - I've seen many cases when other companies/individuals are doing similar - restrict access to bastion server via either sshd_config or iptables (not even firewall as someone on IRC suggested).
Proposal:
I am thinking of following implementation:
New sssd.conf option for ldap_access_order = rhost, which would enable rhost verification.
New sssd.conf option ldap_user_authorized_rhost, which would carry similar meaning as ldap_user_authorized_host (that is the name of field in LDAP record containing rule).
LDAP entry field I am thinking could also be similar to the current host field format - text Unicode field validated in order: explicit deny (!host), explicit allow (host), allow all (*) ending with deny all (default if no matching rule found).
Validation could happen as follows: If the rhost is an IP address first lookup directly any matching rules, if none found attempt to fetch rDNS record for rhost and lookup match for it. If rhost is a hostname first lookup match directly, if none found fetch forward DNS record (that is A and AAAA records) and try to match all elements from returned list (not sure if sssd may receive hostname as rhost, but assume that as a possibility).
Please let me know if this could be implemented as a part of LDAP backend of SSSD. If this proposal is accepted I could start working on implementation shortly.
Best regards, akamenskiy
On la, 29 huhti 2017, Alexey Kamenskiy wrote:
Hi SSSd team,
I was advised in IRC to send email to the group in order to discuss this functionality.
I am thinking about taking on implementing it as I have a need in such functionality. But I can also see that it would perhaps be interesting to many other users as well.
Preamble:
Now SSSd's LDAP backend only provides ability to have a restriction via host record to restrict access by verifying local hostname of machine (by either explicitly allowing or denying access as hostname) using ldap_access_order=host.
My thought is that it would be good to have ability to perform similar access verification for rhost (IP or via DNS).
Why is it relevant to me - I am (as part of my work) managing 1k+ hosts where we restrict ssh access to specific IP(s) using sshd_config AllowUsers option using (*@ip_address) record to only allow logins from well protected bastion server. It went pretty bad when IDC disaster happened and the bastion was N/A - there was no way to access hosts until access to bastion was restored. Meanwhile we manage ssh users and sudo access with LDAP, so it would be perfect if we could manage this in there as well.
Why is it relevant to others - I've seen many cases when other companies/individuals are doing similar - restrict access to bastion server via either sshd_config or iptables (not even firewall as someone on IRC suggested).
In FreeIPA HBAC rules we used to support source host access control. However, it was disabled and deprecated. While SSSD still supports it, PAM applications like sshd pass rhost information to PAM based on what they received from their own clients.
There is no normalized way to report a trusted rhost value, so you might get both CIDR or host name or fully qualified host name or spoofed host name from PAM application.
In the end, FreeIPA disabled source host access control on its side. SSSD still would try to enforce source host if the rule has it set but unmodified FreeIPA HBAC management command do not add source host attributes into the rules, so they never get matched by SSSD.
Proposal:
I am thinking of following implementation:
New sssd.conf option for ldap_access_order = rhost, which would enable rhost verification.
New sssd.conf option ldap_user_authorized_rhost, which would carry similar meaning as ldap_user_authorized_host (that is the name of field in LDAP record containing rule).
LDAP entry field I am thinking could also be similar to the current host field format - text Unicode field validated in order: explicit deny (!host), explicit allow (host), allow all (*) ending with deny all (default if no matching rule found).
Validation could happen as follows: If the rhost is an IP address first lookup directly any matching rules, if none found attempt to fetch rDNS record for rhost and lookup match for it. If rhost is a hostname first lookup match directly, if none found fetch forward DNS record (that is A and AAAA records) and try to match all elements from returned list (not sure if sssd may receive hostname as rhost, but assume that as a possibility).
I would rather reuse existing HBAC infrastructure for rule evaluation. HBAC rule evaluation is separate from its representation in LDAP (or anywhere else). It would be beneficial to have HBAC rule checking as a separate access provider that either uses the same schema as FreeIPA does or supports a subset of it. This way you'd use existing SSSD infrastructure and only would need to write a code to pull LDAP representation of HBAC rules.
Thank you for your comment, please see below:
On Sun, Apr 30, 2017 at 3:51 AM, Alexander Bokovoy abokovoy@redhat.com wrote:
In FreeIPA HBAC rules we used to support source host access control. However, it was disabled and deprecated. While SSSD still supports it, PAM applications like sshd pass rhost information to PAM based on what they received from their own clients.
There is no normalized way to report a trusted rhost value, so you might get both CIDR or host name or fully qualified host name or spoofed host name from PAM application. In the end, FreeIPA disabled source host access control on its side. SSSD still would try to enforce source host if the rule has it set but unmodified FreeIPA HBAC management command do not add source host attributes into the rules, so they never get matched by SSSD.
Applied to ssh, is the rhost visible to SSSd the one that client reports to ssh server? Apologies if this is a stupid question, but is there any way inside the SSSD to get source IP/fqdn without using rhost set by client? That would help to avoid any spoofing possibility I guess.
On the other hand to even spoof a remote host attacker needs to know which host/IP is allowed to access and also which form is entered into LDAP.
I would rather reuse existing HBAC infrastructure for rule evaluation.
HBAC rule evaluation is separate from its representation in LDAP (or anywhere else). It would be beneficial to have HBAC rule checking as a separate access provider that either uses the same schema as FreeIPA does or supports a subset of it. This way you'd use existing SSSD infrastructure and only would need to write a code to pull LDAP representation of HBAC rules.
This is basically why I wrote on similar approach between this proposal and how host record is evaluated now. If host record evaluation uses HBAC infra, then I would gladly reuse that of course.
-- / Alexander Bokovoy _______________________________________________ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-leave@lists.fedorahosted.org
On su, 30 huhti 2017, Alexey Kamenskiy wrote:
Thank you for your comment, please see below:
On Sun, Apr 30, 2017 at 3:51 AM, Alexander Bokovoy abokovoy@redhat.com wrote:
In FreeIPA HBAC rules we used to support source host access control. However, it was disabled and deprecated. While SSSD still supports it, PAM applications like sshd pass rhost information to PAM based on what they received from their own clients.
There is no normalized way to report a trusted rhost value, so you might get both CIDR or host name or fully qualified host name or spoofed host name from PAM application. In the end, FreeIPA disabled source host access control on its side. SSSD still would try to enforce source host if the rule has it set but unmodified FreeIPA HBAC management command do not add source host attributes into the rules, so they never get matched by SSSD.
Applied to ssh, is the rhost visible to SSSd the one that client reports to ssh server? Apologies if this is a stupid question, but is there any way inside the SSSD to get source IP/fqdn without using rhost set by client? That would help to avoid any spoofing possibility I guess.
OpenSSH bases its decision on the length of a hostname in utmp record, with a catch. At least on Linux, UT_HOSTSIZE is 256 but MAXHOSTNAMELEN in kernel is set to 64. OpenSSH uses the latter, not the former. So if your hostname is shorter than 64 characters, it will be canonicalized and provided to PAM stack as rhost. If not, your IP address will be provided.
On the other hand to even spoof a remote host attacker needs to know which host/IP is allowed to access and also which form is entered into LDAP.
It just need to be able to connect to your system multiple times, that's all.
OpenSSH bases its decision on the length of a hostname in utmp record,
with a catch. At least on Linux, UT_HOSTSIZE is 256 but MAXHOSTNAMELEN
in kernel is set to 64. OpenSSH uses the latter, not the former. So if your hostname is shorter than 64 characters, it will be canonicalized and provided to PAM stack as rhost. If not, your IP address will be provided.
AFAIK (correct me if I am wrong here) in case of OpenSSH it depends on whether UseDNS is on or off. If off then connecting IP address is passed as rhost, if on then it attempts to get rDNS for it and (if successful) pass it further, these length limitations you mention apply already after this.
On the other hand to even spoof a remote host attacker needs to know which
host/IP is allowed to access and also which form is entered into LDAP.
It just need to be able to connect to your system multiple times, that's all.
Can you please elaborate on this one? Not sure I understand exactly what you meant.
On ti, 02 touko 2017, Alexey Kamenskiy wrote:
OpenSSH bases its decision on the length of a hostname in utmp record,
with a catch. At least on Linux, UT_HOSTSIZE is 256 but MAXHOSTNAMELEN
in kernel is set to 64. OpenSSH uses the latter, not the former. So if your hostname is shorter than 64 characters, it will be canonicalized and provided to PAM stack as rhost. If not, your IP address will be provided.
AFAIK (correct me if I am wrong here) in case of OpenSSH it depends on whether UseDNS is on or off. If off then connecting IP address is passed as rhost, if on then it attempts to get rDNS for it and (if successful) pass it further, these length limitations you mention apply already after this.
If UseDNS is on, it resolves the name, if it can, but if that is failing, you'd get string 'UNKNOWN' as your remote hostname. Otherwise you'd get IP address as as string.
This is really badly done if you want to base your decisions on rhost.
On the other hand to even spoof a remote host attacker needs to know which
host/IP is allowed to access and also which form is entered into LDAP.
It just need to be able to connect to your system multiple times, that's all.
Can you please elaborate on this one? Not sure I understand exactly what you meant.
If you have no connection throttling in place, attacker can theoretically connect ad infinitum spoofing your IP address space and DNS.
The mere fact that you can do that to eventually hit a hole in your access control is enough. Connect this to a social engineering to reduce a search space and you'd see how fast it would be exploited.
Since access controls rules will be in LDAP, they will be readable for most authenticated users, including machines. Ability to use a machine account to do LDAP lookup pretty much makes impossible to keep information about the access control rules private.
Sure, this is not a single step attack but nothing is so easy either these days.
sssd-devel@lists.fedorahosted.org
-
Alexander Bokovoy -
Alexey Kamenskiy