jumanjihouse / docker-duoauthproxy Goto Github PK

use --read-only to start container so that it runs read-only

Unable to get container to stay awake after starting the DUO process...

I am using only LDAP in my authproxy.cfg:
`
[ad_client]
host=10.0.0.1 ; IP address of the Active Directory domain controller
service_account_username=ldap
service_account_password=xxxxxxxx
search_dn=DC=xxxxxx,DC=org
; security_group_dn=CN=DuoVPNUsers,OU=Groups,DC=example,DC=com
; transport=starttls
; ssl_ca_certs_file=conf\example_com_ca.pem

; Application Matrix
[ldap_server_auto]
ikey=xxxxx
skey=yyyyyyyyyyyyyyyyyyyyyyy
api_host=api-4xxxxxx1f.duosecurity.com
factors=auto
client=ad_client
failmode=secure
port=1389
;ssl_key_path=server.key
;ssl_cert_path=server.crt
exempt_primary_bind=false
`
I cannot assign a port publishing. However contacting it under the docker IP 172.17.x.x on port 1389 is working.
When I try to publish it in the Container config in Portainer it says "a.ExposedPorts is undefined" and from what I see the container config has an empty "Port:" section.

Hi,

Does not compile in Ubuntu 16.04.
Stops with this error message:

x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -I/usr/include/python2.7 -c OpenSSL/crypto/crl.c -o build/temp.linux-x86_64-2.7/OpenSSL/crypto/crl.o OpenSSL/crypto/crl.c:6:23: error: static declaration of ‘X509_REVOKED_dup’ follows non-static declaration static X509_REVOKED * X509_REVOKED_dup(X509_REVOKED *orig) { ^ In file included from /usr/include/openssl/ssl.h:156:0, from OpenSSL/crypto/x509.h:17, from OpenSSL/crypto/crypto.h:30, from OpenSSL/crypto/crl.c:3: /usr/include/openssl/x509.h:751:15: note: previous declaration of ‘X509_REVOKED_dup’ was here X509_REVOKED *X509_REVOKED_dup(X509_REVOKED *rev); ^ error: command 'x86_64-linux-gnu-gcc' failed with exit status 1 Makefile:14: recipe for target 'pyopenssl' failed make: *** [pyopenssl] Error 1

A simple fix for this or do I need to use an older version of Ubuntu?

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): update centos docker tag to v7.9.2009
• chore(deps): update centos docker tag to v8

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

I'm using duoauthproxy to limit access to a vpn and it's been working great. But I just realized that ldap_filter isn't working properly for me.

The filter looks like this:
ldap_filter=(|(memberOf=cn=site-one,ou=groups,dc=test)(memberOf=cn=site-all,ou=groups,dc=test))

The sense of this filter should be that anyone who's a member of cn=site-one,ou=groups,dc=test or who's a member of cn=site-all,ou=groups,dc=test should be granted access.

But I just created a user who's only a member of site-one and the authentication doesn't succeed:

2018-06-12T21:00:50+0000 [DuoForwardServer (UDP)] Sending AD authentication request for 'test' to 'ldap' 2018-06-12T21:00:50+0000 [duoauthproxy.modules.ad_client._ADAuthClientFactory#info] Starting factory <duoauthproxy.modules.ad_client._ADAuthClientFactory object at 0x7fdbda1975d0> 2018-06-12T21:00:50+0000 [-] C->S LDAPMessage(id=6, value=LDAPStartTLSRequest()) 2018-06-12T21:00:50+0000 [_ADAuthClientProtocol,client] C<-S LDAPMessage(id=6L, value=LDAPExtendedResponse(resultCode=0L)) 2018-06-12T21:00:50+0000 [_ADAuthClientProtocol,client] C->S LDAPMessage(id=7, value=LDAPBindRequest(version=3, dn='cn=readonly,dc=test', auth='*****', sasl=False)) 2018-06-12T21:00:50+0000 [_ADAuthClientProtocol,client] C<-S LDAPMessage(id=7L, value=LDAPBindResponse(resultCode=0L)) 2018-06-12T21:00:50+0000 [_ADAuthClientProtocol,client] C->S LDAPMessage(id=8, value=LDAPSearchRequest(baseObject='ou=users,dc=test', scope=2, derefAliases=0, sizeLimit=0, timeLimit=0, typesOnly=0, filter=LDAPFilter_and(value=[LDAPFilter_or(value=[LDAPFilter_and(value=[LDAPFilter_equalityMatch(attributeDesc=LDAPAttributeDescription(value='objectClass'), assertionValue=LDAPAssertionValue(value='user')), LDAPFilter_equalityMatch(attributeDesc=LDAPAttributeDescription(value='objectCategory'), assertionValue=LDAPAssertionValue(value='person'))]), LDAPFilter_equalityMatch(attributeDesc=LDAPAttributeDescription(value='objectClass'), assertionValue=LDAPAssertionValue(value='inetOrgPerson')), LDAPFilter_equalityMatch(attributeDesc=LDAPAttributeDescription(value='objectClass'), assertionValue=LDAPAssertionValue(value='organizationalPerson'))]), LDAPFilter_equalityMatch(attributeDesc=LDAPAttributeDescription(value='uid'), assertionValue=LDAPAssertionValue(value=u'test')), LDAPFilter_or(value=[LDAPFilter_equalityMatch(attributeDesc=LDAPAttributeDescription(value='memberOf'), assertionValue=LDAPAssertionValue(value='cn=site-one,ou=groups,dc=test')), LDAPFilter_equalityMatch(attributeDesc=LDAPAttributeDescription(value='memberOf'), assertionValue=LDAPAssertionValue(value='cn=site-all,ou=groups,dc=test'))])]), attributes=('uid', 'msDS-PrincipalName'))) 2018-06-12T21:00:50+0000 [_ADAuthClientProtocol,client] C<-S LDAPMessage(id=8L, value=LDAPSearchResultEntry(objectName='cn=test,ou=users,dc=test', attributes=[('uid', ['test'])]) 2018-06-12T21:00:50+0000 [_ADAuthClientProtocol,client] C<-S LDAPMessage(id=8L, value=LDAPSearchResultDone(resultCode=0L)) 2018-06-12T21:00:50+0000 [_ADAuthClientProtocol,client] C->S LDAPMessage(id=9, value=LDAPBindRequest(version=3, dn='cn=test,ou=users,dc=test', auth='*****', sasl=False)) 2018-06-12T21:00:50+0000 [_ADAuthClientProtocol,client] C<-S LDAPMessage(id=9L, value=LDAPBindResponse(resultCode=0L)) 2018-06-12T21:00:50+0000 [_ADAuthClientProtocol,client] C->S LDAPMessage(id=10, value=LDAPUnbindRequest()) 2018-06-12T21:00:50+0000 [_ADAuthClientProtocol,client] http POST to https://api-7f07f81e.duosecurity.com:443/rest/v1/preauth: user=test 2018-06-12T21:00:50+0000 [duoauthproxy.lib.http._DuoHTTPClientFactory#info] Starting factory <_DuoHTTPClientFactory: https://api-7f07f81e.duosecurity.com:443/rest/v1/preauth> 2018-06-12T21:00:50+0000 [duoauthproxy.modules.ad_client._ADAuthClientFactory#info] Stopping factory <duoauthproxy.modules.ad_client._ADAuthClientFactory object at 0x7fdbda1975d0> 2018-06-12T21:00:50+0000 [HTTPPageGetter (TLSMemoryBIOProtocol),client] (('10.0.0.4', 40977), 35): Got preauth result for: u'enroll' 2018-06-12T21:00:50+0000 [HTTPPageGetter (TLSMemoryBIOProtocol),client] (('10.0.0.4', 40977), 35): Returning response code 3: AccessReject

When I use ldapsearch to execute the query with the filter, it works.

I feel sure this used to work so I went back a couple of versions of the docker image but had no luck.

Any ideas what I can do to fix this/help debug it?

ideally, run with --cap-drop=all then add back the absolute minimum capabilities

https://www.openssl.org/news/secadv_20150611.txt has a new openssl release that will likely land in a new duoauthproxy release: https://www.duosecurity.com/docs/authproxy-notes

Per the readme, and per the console output from running the container, the auth proxy version is 3.1.2. However, the latest version available from Duo is 5.0.2.

Are there plans to update the container version to the latest?

libressl

• current: 2.4.3
• bump to: 2.4.4
  • http://git.alpinelinux.org/cgit/aports/commit/?id=04f886c921feaf0f4988d00d356c5bdf2b8b2dd6
  • https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-2.4.4-relnotes.txt

pyopenssl

• current: 16.1.0
• bump to: 16.2.0
  • https://github.com/pyca/pyopenssl/releases/tag/16.2.0

supporting these builds adds time to the build and seems pointless.

• the alpine build is fast, lean, and efficient
• the alpine build does the job
• nobody besides $dayjob uses the centos or ubuntu builds afaict
• in any case, the point of the container is to be an appliance

curious as the duo-proxy code seems to be up to 5.4.1

The /runtime/harden.sh script contains a bunch of deletion of system files, including useful tools like chown and chmod.

Deleting these make it harder to extend your image in another Dockerfile (e.g. to overwrite the authproxy.cfg file).

Finally, this is not hardening the container at all, because these files you are deleting do not contain any binary code, they are simply symlinks to /bin/busybox:

$ docker run -it alpine sh
/ # ls -al /bin/ch*
lrwxrwxrwx    1 root     root            12 Apr  1 18:56 /bin/chgrp -> /bin/busybox
lrwxrwxrwx    1 root     root            12 Apr  1 18:56 /bin/chmod -> /bin/busybox
lrwxrwxrwx    1 root     root            12 Apr  1 18:56 /bin/chown -> /bin/busybox

It is trivial to work around your hardening by calling busybox with the binary name:

$ docker run -it duoauthproxy sh
/ # busybox chown
BusyBox v1.24.1 (2015-12-16 08:00:02 GMT) multi-call binary.

Usage: chown [-RhLHPcvf]... OWNER[<.|:>[GROUP]] FILE...

Or by overriding the process name (python example):

$ docker run -it duoauthproxy sh
/ $ python -c 'import os; os.execl("/bin/busybox", "chown")'
BusyBox v1.24.1 (2015-12-16 08:00:02 GMT) multi-call binary.

Usage: chown [-RhLHPcvf]... OWNER[<.|:>[GROUP]] FILE...

Please consider removing this part of harden.sh as I don't believe they are adding to the security of the image, and make it harder to extend.

details: https://www.duosecurity.com/docs/authproxy-notes

circleci is faster and more reliable so far

currently: we use a volume mount to copy built binary from builder into runtime

should: use docker cp so that we can build against a remote host (via DOCKER_HOST var)

First of all thanks for providing a docker container for duoauthproxy, if I can get this to work I will be greatful! Whenever I try to run the container following your docs for running it in detached mode with this command:

docker run -d --name duoauthproxy -p 1812:1812/udp -p 18120:18120/udp -v /etc/duoauthproxy:/etc/duoauthproxy:ro --read-only --cap-drop=all --cap-add=setgid --cap-add=setuid jumanjiman/duoauthproxy:latest

The container immediately exits and I get the following error when I do a docker logs command:

  File "/opt/duoauthproxy/bin/authproxy", line 21, in <module>
    application = proxy.create_application(args=sys.argv)
  File "/opt/duoauthproxy/usr/local/lib/python2.7/site-packages/duoauthproxy/proxy.py", line 297, in create_application
    server_instance = server_module.Module(server_config, clients[client_name], section_name)
  File "/opt/duoauthproxy/usr/local/lib/python2.7/site-packages/duoauthproxy/modules/radius_server_auto.py", line 434, in __init__
    secrets=parse_radius_secrets(config),
  File "/opt/duoauthproxy/usr/local/lib/python2.7/site-packages/duoauthproxy/lib/radius/server.py", line 443, in parse_radius_secrets
    % (ip_config_key, ip, e),
duoauthproxy.lib.config_error.ConfigError: Invalid IP, network, or range for 'radius_ip_1': '' (invalid IPNetwork )```


Looking at duo docs I tried their suggestion but that didn't fix it, here is what their docs say:

https://help.duo.com/s/article/4085?language=en_US

```If the Duo Authentication Proxy fails to start due to the error ConfigError: Invalid IP, network, or range for 'radius_ip_1': '' (invalid IPNetwork ) ', performing the following process resolves common issues:
Open the authproxy.cfg file in a text editor other than Notepad. Verify you are modifying the correct authproxy.cfg file located in the proper corresponding location:
Windows 64-bit: C:\Program Files (x86)\Duo Security Authentication Proxy\conf
Windows 32-bit: C:\Program Files\Duo Security Authentication Proxy\conf
Linux: /opt/duoauthproxy/conf
Remove any line specifying a radius_ip value and retype it manually. This can be single IP address (e.g. "1.2.3.4"), a specification in CIDR notation (e.g. "1.2.3.0/24"), or an IP address range (e.g. "3.3.3.3-3.3.3.6" for the IPs 3.3.3.3, 3.3.3.4, 3.3.3.5, and 3.3.3.6).
Restart the proxy.```

It'd be great to create ${subject}.