Quantcast
Channel: sys4 AG
Viewing all 268 articles
Browse latest View live

Cyrus SASL sasldblistusers2 man page


Cyrus SASL saslpasswd.conf man page

$
0
0

Description

The optional saslpasswd.conf configuration file controls which authentication backends - sasldb, sql and ldapdb auxprop plugins - the saslpasswd2 command will use to create, modify and disable authentication identities.

To Cyrus SASL saslpasswd2 is like any other server that requests authentication services. The command identifies itself with the application name saslpasswd and libsasl searches for configuration that describes how authentication for that application should take place.

The libary will search in /usr/lib/sasl2 and then in /etc/sasl for a file named saslpasswd.conf. First match wins! If it finds a configuration file in /usr/lib/sasl2 it will not look for another one in /etc/sasl.

Example

The following configuration file /etc/sasl/saslpasswd.conf defines a MySQL server as authentication backend for saslpasswd2:

# GENERIC options
pwcheck_method: auxprop
auxprop_plugin: sql
mech_list: plain cram-md5 digest-md5 ntlm
log_level: 1

# SQL auxprop plugin options
sql_engines: mysql
sql_hostnames: 127.0.0.1
sql_user: sasl
sql_passwd: secret
sql_database: sasl
sql_select: SELECT %p FROM user WHERE username = '%u' AND userrealm = '%r'
sql_insert: INSERT INTO user (id, username, userrealm, %p) VALUES ('', '%u', '%r', '%v')
sql_update: UPDATE user SET `%p` = '%v' WHERE username = '%u' AND userrealm = '%r'

Note

Note sql_insert and sql_update configuration settings - they tell saslpasswd2 how to write to the authentication backend.

Cyrus SASL saslauthd.conf man page

$
0
0

Description

This document describes LDAP configuration options for the Cyrus SASL password verification service saslauthd.

By default saslauthd searches for LDAP configuration options in /usr/local/etc/saslauthd.conf. This location can be overridden if the additional command line option -O specifies an alternative path to the configuration file.

Syntax

Do not use quotes (\"\') in the parameter values.

Options

The following are available LDAP parameters. The defaults are probably adequate for most installations. Only ldap_servers may need to be specified.

ldap_auth_method (default: bind|fastbind)

The bind method uses the LDAP bind facility to verify the password. The bind method is not available when ldap_use_sasl is turned on. In that case saslauthd will use fastbind.

bind
bind is the default auth method. When ldap_use_sasl is enabled, 'fastbind' is the default.
custom
The custom method uses userPassword attribute to verify the password. Supported hashes: crypt, md5, smd5, sha and ssha. Cleartext is supported as well.
fastbind

The fastbind method - when ldap_use_sasl is no - does away with the search and an extra anonymous bind in auth_bind, but makes two assumptions:

  1. Expanding the ldap_filter expression gives the user's fully-qualified DN
  2. There is no cost to staying bound as a named user
ldap_bind_dn (default: empty)

Specify DN (distinguished name) to bind to the LDAP directory.

Important

Do not specify this parameter for the anonymous bind!

ldap_bind_pw (default: empty)
An alias for ldap_password.
ldap_default_domain (default: empty)
An alias for ldap_default_realm.
ldap_default_realm (default: empty)
The default realm is assigned to the %r token when realm is not available. See ldap_filter for more.
ldap_deref (default: empty)
Specify how aliases dereferencing is handled during search. Should be one of never, always, search, or find to specify that aliases are never dereferenced, always dereferenced, dereferenced when searching, or dereferenced only when locating the base object for the search.
ldap_filter (default: uid=%u)

Specify a filter. The following tokens can be used in the filter string:

%%
This is replaced by a literal ’%’ character.
%u
%u is replaced by the complete user string.
%U
If the string is an address (%u), %U will be replaced by the local part of that address.
%d
If the string is an address (%u), %d will be replaced by the domain part of that address. Otherwise it will be the same as %r.
%1-9
If the input key is user@mail.example.com, then %1 is com, %2 is example and %3 is mail.
%s
%s is replaced by the complete service string.
%r
%r is replaced by the complete realm string.
%D
%D is replaced by the complete user DN (available for group checks)

The %u token has to be used at minimum for the filter to be useful. If ldap_auth_method is bind, the filter will search for the DN (distinguished name) attribute. Otherwise, the search will look for the ldap_password_attr attribute.

ldap_group_attr (default: uniqueMember)
Specify what attribute to compare the user DN against in the group. If ldap_group_dn is not specified, this parameter is ignored. If ldap_group_match_method is not attr, this parameter is ignored.
ldap_group_dn (default: empty)
If specified, the user has to be part of the group in order to authenticate successfully. Tokens described in ldap_filter can be used for substitution.
ldap_group_filter (default: empty)
Specify a filter. If a filter match is found then the user is in the group. Tokens described in ldap_filter can be used for for substitution. If ldap_group_dn is not specified, this parameter is ignored. If ldap_group_match_method is not filter, this parameter is ignored.
ldap_group_match_method (default: attr)
If attr is used the group match method uses ldap_group_attr and if filter is used ldap_group_search will be used as group match method. If ldap_group_dn is not specified, this parameter is ignored.
ldap_group_search_base (default: ldap_search_base)
Specify a starting point for the group search: e.g. dc=example,dc=com. Tokens described in ldap_filter can be used for substitution.
ldap_group_scope (default: sub)
Group search scope. Options are either sub, one or base.
ldap_password (default: empty)
Specify the password for ldap_bind_dn or ldap_id if ldap_use_sasl is turned on. Do not specify this parameter for the anonymous bind.
ldap_password_attr (default: userPassword)
Specify what password attribute to use for password verification.
ldap_referrals (default: no)
Specify whether or not the client should follow referrals.
ldap_restart (default: yes)
Specify whether or not LDAP I/O operations are automatically restarted if they abort prematurely.
ldap_id (default: empty)
Specify the authentication ID for SASL bind.
ldap_authz_id (default: empty)
Specify the proxy authorization ID for SASL bind.
ldap_mech (default: empty)
Specify the authentication mechanism for SASL bind.
ldap_realm (default: empty)
Specify the realm of authentication ID for SASL bind.
ldap_scope (default: sub)
Search scope. Options are either sub, one or base.
ldap_search_base (default: empty)
Specify a starting point for the search: e.g. dc=example,dc=com. Tokens described in ldap_filter can be used for substitution.
ldap_servers (default: ldap://localhost/)
Specify one or more URI(s) referring to LDAP server(s), e.g. ldaps://10.1.1.2:999/. Multiple servers must be separated by space.
ldap_start_tls (default: no)
Use StartTLS extended operation. Do not use ldaps: ldap_servers when this option is turned on.
ldap_time_limit (default: 5)
Specify a number of seconds for a search request to complete.
ldap_timeout (default: 5)
Specify a number of seconds a search can take before timing out.
ldap_tls_check_peer (default: no)
Require and verify server certificate. If this option is yes, you must specify ldap_tls_cacert_file or ldap_tls_cacert_dir.
ldap_tls_cacert_file (default: empty)
File containing CA (Certificate Authority) certificate(s).
ldap_tls_cacert_dir (default: empty)
Path to directory with CA (Certificate Authority) certificates.
ldap_tls_ciphers (default: DEFAULT)
List of SSL/TLS ciphers to allow. See ciphers 1 for a list of all permitted cipher strings and their meanings.
ldap_tls_cert (default: empty)
File containing the client certificate.
ldap_tls_key (default: empty)
File containing the private client key.
ldap_use_sasl (default: no)
Use SASL bind instead of simple bind when connecting to the LDAP server.
ldap_version (default: 3)
Specify the LDAP protocol version - either 2 or 3. If ldap_start_tls and/or ldap_use_sasl are enabled, ldap_version will be automatically set to 3.

Example

The following example configures saslauthd to use an LDAP server as authentication backend and read the configuration from /etc/saslauthd.conf:

$ saslauthd -a ldap -O /etc/saslauthd.conf

The configuration file read by saslauthd:

# Servers
ldap_servers: ldap://localhost/

# Identity
ldap_bind_dn: uid=sasl,ou=services,dc=example,dc=com
ldap_password: secret
ldap_auth_method: bind

# Search
ldap_search_base: ou=people,dc=example,dc=com

Cyrus SASL sql man page

$
0
0

Description

This document describes configuration options for the Cyrus SASL auxiliary property plugin sql.

sql is a generic plugin for various SQL backends. Currently it provides access to either MySQL, PostgreSQL or SQLite databases.

Note

The plugin requires that passwords in the database are stored in plaintext format in order to use shared-secret mechanisms.

Configuration Syntax

The following syntax is mandatory for sql plugin configuration:

  • SQL statements specified with sql_select, sql_select and sql_select must not be enclosed in quotes.
  • Macros, e.g. %u, %r and %v, specified within SQL statements must be quoted individually.

See ? for a valid configuration example.

Options

The following configuration parameters are applicable in the context of the sql plugin:

sql_engine (default: mysql)

Specifies the type of SQL engine to use for connections to the SQL backend. The following types are available:

mysql
Enables the mysql driver for connections to a MySQL server.
pgsql
Enables the pgsql driver for connections to a PostgreSQL server.
sqlite
Enables the sqlite driver for connections to a SQLite 2 database.
sqlite3
Enables the sqlite driver for connections to a SQLite 3 database.
sql_hostnames (default: empty)

A comma-separated list of one or more SQL servers the plugin should try to connect to and query from. Specify servers separated in hostname[:port] format.

Note

Specify localhost when using the MySQL engine to communicate over a UNIX domain socket and 127.0.0.1 to attempt a connection that uses a TCP socket.

Note

This option will be ignored if sql_engine is set to either sqlite or sqlite3.

sql_user (default empty)

Configures the username the plugin will send when it authenticates to the SQL server.

Note

This option will be ignored if sql_engine is set to either sqlite or sqlite3.

sql_passwd (defaults: empty)

Configures the password the plugin will send when it authenticates to the SQL server.

Note

This option will be ignored if sql_engine is set to either sqlite or sqlite3.

sql_database (default: empty)
Specifies the name of the database which contains auxiliary properties (e.g. username, realm, password etc.)
sql_select (default: empty)
Mandatory SELECT statement used to fetch properties from the SQL database.
sql_insert (default: empty)
Optional INSERT statement used to create properties for new users in the SQL database.
sql_update (default: empty)
Optional UPDATE statement used to modify properties in the SQL database.
sql_usessl (default: no)

Specify either yes, on, 1 or true, and the plugin will try to establish a secure connection to the SQL server.

Note

This option is available for MySQL backends only. It will be ignored if sql_engine is set to either sqlite or sqlite3.

Macros

The sql plugin provides macros to build sql_select, sql_select and sql_select statements. They will be replaced with arguments sent from the client. The following macros exist:

%u
The name of the user whose properties are being selected, inserted or updated.
%p
The name of the property being selected, inserted or updated. While this could technically be anything, Cyrus SASL will try userPassword and cmusaslsecret (where MECHNAME is the name of a SASL mechanism).
%r
Name of the realm to which the user belongs. This could be the KERBEROS realm, the FQDN of the computer the SASL application is running on or whatever is after the @ on a username.
%v

Value of the property (generally userPassword) being stored during insert or update operations.

Note

This option will be ignored if sql_engine is set to either sqlite or sqlite3.

Example

The following example shows a typical sql configuration:

# GENERIC options
pwcheck_method: auxprop
auxprop_plugin: sql
mech_list: plain login cram-md5 digest-md5

# SQL auxprop plugin options
sql_engine: pgsql
sql_hostnames: 127.0.0.1, 192.0.2.1
sql_user: username
sql_passwd: secret
sql_database: company
sql_select: SELECT password FROM users WHERE user = '%u'@'%r'

Cyrus SASL libsasl man page

$
0
0

Description

This document describes generic configuration options for the Cyrus SASL authentication library libsasl.

The library handles communication between an application and the Cyrus SASL authentication framework. Both exchange information before libsasl can start offering authentication services for the application.

The application, among other data, sends the service_name. The service name is the services name as specified by IANA. SMTP servers, for example, send smtp as service_name. This information is handed over by libsasl e.g. when Kerberos or PAM authentication takes place.

Configuration options in general are read either from a file or passed by the application using libsasl during library initialization.

File-Based configuration

When an application (server) starts, it initializes the libsasl library. The application passes app_name (application name) to the SASL library. Its value is used to construct the name of the application specific SASL configuration file. The Cyrus SASL sample-server, for example, sends sample as app_name. Using this value the SASL library will search the configuration directories for a file named sample.conf and read configuration options from it.

Note

Consult the applications manual to determine what app_name it sends to the Cyrus SASL library.

Application-Based Configuration

Configuration options for libsasl are written down together with application specific options in the applications configuration file. The application reads them and passes them over to libsasl when it loads the library.

Note

An example for application-based configuration is the Cyrus IMAP server imapd. SASL configuration is written to imapd.conf and passed to the SASL library when the imapd server starts.

Configuration Syntax

The general format of Cyrus SASL configuration file is as follows:

Configuration options

Configuration options are written each on a single physical line. Parameter and value must be separated by a colon and a single whitespace:

parameter: value
Comments, Emtpy lines and whitespace-only lines
Empty lines and whitespace-only lines are ignored, as are lines whose first non-whitespace character is a “#”.

Options

There are generic options and options specific to the password verification service or auxiliary property plugin choosen by the administrator.

The following configuration parameters are generic configuration options:

authdaemond_path (default: /dev/null)
Path to Courier MTA authdaemond's unix socket. Only applicable when pwcheck_method is set to authdaemond.
auto_transition (default: no)

Automatically transition users to other mechanisms when they do a successful plaintext authentication and if an auxprop plugin is used.

Important

When used in conjunction with the ldapdb 5 plugin the user RDN must exist and the schema must contain the attributes cmusaslsecretPLAIN, cmusaslsecretCRAM-MD5, cmusaslsecretDIGEST-MD5, cmusaslsecretOTP and cmusaslsecretSRP.

no
Do not transition users to other mechanisms.
noplain
Transition users to other mechanisms, but write non-plaintext secrets only.
yes
Transition users to other mechanisms.

Note

The mechanisms OTP, SRP. GSSAPI and EXTERNAL don't use plaintext secrets.

auxprop_plugin (default: empty)

A whitespace-separated list of one or more auxiliary plugins used if the pwcheck_method parameter specifies auxprop as an option. Plugins will be queried in list order. If no plugin is specified, all available plugins will be queried.

ldapdb
Specify ldapdb to use the Cyrus SASL ldapdb 5 plugin.
sasldb
Specify sasldb to use the Cyrus SASL sasldb 5 plugin.
sql
Specify sql to use the Cyrus SASL sql 5 plugin.
canon_user_plugin (default: empty)
Specifies the name of the canon_user plugin libsasl should use.
keytab (default: /etc/krb5.keytab)
Specifies the location of the keytab file. This option is used only in combination with the GSSAPI mechanism.
log_level (default: 1)

Specifies a numeric log level. Available log levels are:

0
Don't log anything
1
Log unusual errors
2
Log all authentication failures
3
Log non-fatal warnings
4
More verbose than 3
5
More verbose than 4
6
Traces of internal protocols
7

Traces of internal protocols, including passwords

Important

Cyrus SASL sends log messages to the application that runs it. The application decides if it forwards such messages to the syslog service, to which facility they are sent and which priority is given to the message.

mech_list (default: empty)
The optional mech_list parameter specifies a whitespace-separated list of one or more mechanisms allowed for authentication.
ntlm_server (default: empty)
This option specifies the hostname of a server (WinNT, Win2K, Samba, etc) to which authentication will be proxied if the client requested a NTLM based authentication session.
ntlm_v2 (default: no)
A client using libsasl can tell libsasl to generate NTLMv2 responses in communication with a server.
opiekeys (default: /etc/opiekeys)
Specifies a location where libsasl should look for the opiekeys file.
otp_mda (default: md5)
Sets the message digest algorithm for one-time passwords used by sasl_setpass. Available options are md4, md5 and sha1.
pwcheck_method (default: auxprop)

A whitespace-separated list of one or more mechanisms. Cyrus SASL provides the following mechanisms:

authdaemond
Configures Cyrus SASL to contact the Courier MTA authdaemond 8 password verification service for password verification.
alwaystrue

This plugin always returns a user has been successfully authenticated.

Warning

This plugin must only be used for testing.

auxprop
Cyrus SASL will use its own plugin infrastructure to verify passwords. The auxprop parameter controls which plugins will be used.
pwcheck
Verify passwords using the Cyrus SASL pwcheck 8 password verification service. The pwcheck daemon is considered deprecated and should not be used anymore. Use the saslauthd password verification service instead.
saslauthd
Verify passwords using the Cyrus SASL saslauthd 8 password verification service.
saslauthd_path (default: empty)
Path to saslauthd 8 run directory (including the /mux named pipe)
reauth_timeout (default: 0)
Duration (minutes) that authentication info will be cached for a “fast reauth”. A value of 0 will disable reauth.
srp_mda (default: sha1)
Sets the message digest algorithm for SRP calculations. Available options are md5, sha1 and rmd160.
srvtab (default: /etc/srvtab)
Specifies the location of the srvtab file. This option is used only in combination with the KERBEROS_4 mechanism.

Cyrus SASL saslpasswd2 man page

$
0
0

Description

saslpasswd2 is used by a server administrator to set a user's SASL password for server programs and SASL mechanisms which use the standard libsasl database of user secrets. By default it creates, modifies and disables users in a sasldb 5 database. Given an optional configuration file (see: saslpasswd.conf 5) it can also edit other authentication backends.

Options

The following command line parameters are available:

-p
This option instructs saslpasswd2 to work in pipe mode. It will neither prompt for the password nor verify that it was entered correctly. This is the default when standard input is not a terminal.
-c
Creates an entry for the user if the user doesn't already exist. This is mutually exclusive with the -d option.
-d
Deletes the entry for the user. This is mutually exclusive with the -c option.
-n
Don't set the plaintext userPassword property for the user. Only mechanism-specific secrets will be set (e.g. OTP, SRP)
-u domain (default: system FQDN hostname)
Use domain to set user domain property (realm).
-f file
Create sasldb database at specified location. If not specified the default location (/etc/sasldb2) will be used.
-a appname
Optionally use appname to set the application name property.
-v
Print libsasl 5 version number and exit.

Example

Creating a user:

#

A configuration that lets saslpasswd2 create, modify and disable users in a MySQL server:

# GENERIC options
pwcheck_method: auxprop
auxprop_plugin: sql
mech_list: plain cram-md5 digest-md5
log_level: 1

# SQL auxprop plugin options
sql_engines: mysql
sql_hostnames: 127.0.0.1
sql_user: sasl
sql_passwd: secret
sql_database: sasl
sql_select: SELECT %p FROM user WHERE username = '%u' AND userrealm = '%r'
sql_insert: INSERT INTO user (id, username, userrealm, %p) VALUES ('', '%u', '%r', '%v')
sql_update: UPDATE user SET `%p` = '%v' WHERE username = '%u' AND userrealm = '%r'

The missing Cyrus SASL man pages

$
0
0

I think it must be at least 8 years ago, since I boarded a plane in Munich and flew to meet Alexey Melnikov in London. We spent the weekend going over the Cyrus SASL code, because I was destined to write man pages for this important SASL framework. Writing the missing documentation should be my way to say "thank you for the programs that make my life easier".

Alexey helped me a lot to understand Cyrus SASL better and he dug options from the code known probably only to those who have written the framework. Alexey is one of them. After a few iterations Cyrus SASL man pages became visible and readable. I contacted authors of various plugins and asked for their input.

They helped and then I went to the Cyrus SASL mailing list and announced I would like to contribute them to the project. They just needed a little more brush and probably one more review... No reaction.

So here they are: The missing Cyrus SASL man pages. For posterity, and those who struggle to find their way through security related software that isn't documented. You can read them online or download the Cyrus SASL man pages as tarball containing various in- and output formats:

ldapdb 5, libsasl 5, saslauthd 8, saslauthd.conf 5, sasldb 5, sasldblistusers2 8, saslpasswd2 8, saslpasswd.conf 5, sql 5

Cyrus SASL sasldb man page

$
0
0

Description

This document describes configuration options for the Cyrus SASL auxiliary property plugin sasldb.

sasldb is always loaded by default.

Note

It will be used if explicitly configured, but also if other mechanisms have failed to load e.g. because they haven't been configured properly.

This plugin reads all user data from a database, located at /etc/sasldb2 by default unless changed at compile time or by setting the sasldb_path option.

Note

The plugin can be built to use a gdbm, ndbm or Sleepycat Berkeley database as backend.

Passwords are stored in plaintext format to enable usage of shared-secret mechanisms.

Use the saslpasswd2 8 utility to create and modify sasldb users. The sasldblistusers2 8 command prints a list of existing sasldb users to STDOUT.

Options

The following configuration parameters are applicable in the context of the sasldb plugin:

sasldb_path (default: /etc/sasldb2)
This setting optionally specifies a path to a sasldb database. Setting this option overrides the default path, which is system dependant, but usually /etc/sasldb2.

Example

The following example shows a typical sasldb configuration. The database is located at the default location /etc/sasldb2.

# GENERIC options
pwcheck_method: auxprop
mech_list: plain login cram-md5 digest-md5 ntlm

# SASLDB options
auxprop_plugin: sasldb

Cyrus SASL saslauthd man page

$
0
0

Description

saslauthd is a daemon process that handles plaintext authentication requests on behalf of the SASL library.

The server fulfills two roles: it isolates all code requiring superuser privileges into a single process, and it can be used to provide proxy authentication services to clients that do not understand SASL based authentication.

saslauthd should be started from the system boot scripts when going to multi-user mode. When running against a protected authentication database (e.g. the shadow mechanism), it must be run as the superuser.

Options

Lower-case options configure the server itself. Upper-case options control the behavior of specific authentication mechanisms; their applicability to a particular authentication mechanism is described in the AUTHENTICATION MECHANISMS section.

-a authmech
Use authmech as the authentication mechanism (see ?). This parameter is mandatory.
-O option
A mechanism specific option (e.g. rimap hostname or config file path)
-m path (default: /var/state/saslauthd)

Use path as the pathname to the named socket mux to listen on for connection requests. The pathname must be an absolute path to the directory, and it MUST NOT include the trailing mux.

Note

The socket directory must exist for saslauthd to function.

-n threads (default: 5)

Use threads processes for responding to authentication queries. A value of zero will indicate that saslauthd should fork an individual process for each connection.

Note

This can solve leaks that occur in some deployments.

-s size
Use size as the table size of the hash table (in kilobytes).
-t timeout
Use timeout as the expiration time of the authentication cache (in seconds).
-T
Honour time-of-day login restrictions.
-h
Show usage information.
-c
Enable caching of authentication credentials.
-l
Disable the use of a lock file for controlling access to accept.
-r
Combine the realm with the login (with an ’@’ sign in between). e.g. login: "foo" realm: "bar" will get passed as login: "foo@bar". Note that the realm will still be passed, which may lead to unexpected behaviour.
-v
Print the version number and available authentication mechanisms on standard error, then exit.
-d
Debugging mode.

Logging

saslauthd logs its activities via syslogd using the LOG_AUTH facility.

Authentication Mechanisms

saslauthd supports one or more authentication mechanisms, dependent upon the facilities provided by the underlying operating system. The mechanism is selected by the -aho flag from the following list of choices:

dce (AIX)
Authenticate using the DCE authentication environment.
getpwent (All platforms)
Authenticate using the getpwent library function. Typically this authenticates against the local password file. See your system’s getpwent 3 man page for details.
kerberos4 (All platforms)
Authenticate against the local Kerberos 4 realm (see ? for caveats about this driver).
kerberos5 (All platforms)
Authenticate against the local Kerberos 5 realm.
pam (Linux, Solaris)
Authenticate using Pluggable Authentication Modules (PAM).
rimap (All platforms)

Forward authentication requests to a remote IMAP server. This driver connects to a remote IMAP server, specified using the -O flag, and attempts to login (via an IMAP ‘LOGIN’ command) using the credentials supplied to the local server. If the remote authentication succeeds the local connection is also considered to be authenticated. The remote connection is closed as soon as the tagged response from the ‘LOGIN’ command is received from the remote server.

The option parameter to the -O flag describes the remote server to forward authentication requests to. hostname can be a hostname (imap.example.com) or a dotted-quad IP address (192.168.0.1). The latter is useful if the remote server is multi-homed and has network interfaces that are unreachable from the local IMAP server. The remote host is contacted on the ‘imap’ service port. A non-default port can be specified by appending a slash and the port name or number to the hostname argument.

The -O flag and argument are mandatory when using the rimap mechanism.

shadow (AIX, Irix, Linux, Solaris)
Authenticate against the local "shadow password file". The exact mechanism is system dependent. saslauthd currently understands the getspnam and getuserpw library routines. Some systems honour the -T flag.
sasldb (All platforms)
Authenticate against the SASL authentication database. Note that this is probably not what you want to use, and is even disabled at compile-time by default. If you want to use sasldb with the SASL library, you probably want to use the pwcheck_method of "auxprop" along with the sasldb auxprop plugin instead.
ldap (All platforms that support OpenLDAP 2.0 or higher)
Authenticate against an ldap server. See saslauthd.conf 5 for a list of available configuration parameters.
sia (Digital UNIX)
Authenticate using the Digital UNIX Security Integration Architecture (a.k.a. "enhanced security").

Notes

The kerberos4 authentication driver consumes considerable resources. To perform an authentication it must obtain a ticket granting ticket from the TGT server on every authentication request. The Kerberos library routines that obtain the TGT also create a local ticket file, on the reasonable assumption that you will want to save the TGT for use by other Kerberos applications.

These ticket files are unusable by saslauthd , however there is no way not to create them. The overhead of creating and removing these ticket files can cause serious performance degradation on busy servers. (Kerberos was never intended to be used in this manner, anyway.)

Example

A simple example that configures saslauthd to access a shadow file database:

# saslauthd -a shadow

Cyrus SASL ldapdb man page

$
0
0

Description

This document describes configuration options for the Cyrus SASL auxiliary property plugin ldapdb.

This plugin reads all user data from an LDAP server. It requires configuration of the ldapdb plugin and of the LDAP server. The ldapdb plugin must name a proxy user. The proxy user must (also) SASL authenticate to the LDAP server. The LDAP server must authorize the ldapdb proxy user to access the authenticating users userPassword.

Options

The following configuration parameters are applicable in the context of the ldapdb plugin:

ldapdb_uri (default: empty)
Specifies a whitespace-separated list of LDAP servers (authentication backends). Use ldapi://..., ldap://... or ldaps://... to specify how the servers should be contacted.
ldapdb_canon_attr
A canon_user plugin allows the username that a client sends to be remapped to some other, canonical form. The ldapdb_canon_attr attribute's value provides the canonical name that should be used.
ldapdb_id (default: empty)
Specifies the proxy user name (authentication id) who logs into the LDAP server in order to retrieve the authenticating users userPassword.
ldapdb_mech (default: empty)
Sets the SASL mechanism the ldapdb plugin (client) should use when it SASL connects to the LDAP server.
ldapdb_pw (default: empty)
Specifies the password used by ldapdb_id. The password must be written in cleartext.
ldapdb_rc (default: empty)

Specifies a path to a file that contains configuration options to override system-wide defaults when running LDAP clients.

The main purpose behind this option is to drop transmission of ldapdb_pw in favor of a client TLS certificate specified in ldapdb_rc, so that SASL/EXTERNAL may be used between the ldapdb plugin and the LDAP server.

Note

This is the most optimal way to use the ldapdb plugin when the servers are on separate machines - the connection is encrypted and password transmission is not necessary because the client is identified by its TLS client certificate.

ldapdb_starttls (default: disabled)

Enable encrypted communication using StartTLS. Valid options are:

try
StartTLS encrypted communication is attempted. If it fails the client communicates unencrypted.
demand
StartTLS encrypted communication is required. If it fails the client aborts the connection.

Example

The following example shows a typical ldapdb configuration.

# GENERIC options
pwcheck_method: auxprop
auxprop_plugin: ldapdb
mech_list: plain login cram-md5 digest-md5 ntlm

# LDAPDB settings
ldapdb_uri: ldap://localhost ldaps://ldap.example.com
ldapdb_id: proxyuser
ldapdb_pw: proxypass
ldapdb_mech: DIGEST-MD5

Entwarnung für Postfix und CVE-2015-0235 (GHOST)

$
0
0

Qualys beschreibt in seinem Security Advisory CVE-2015-0235 eine schwerwiegende Sicherheitslücke in glibc. Die Lücke ist ein buffer overflow in der gethostbyname-Funktion, weshalb Qualys die Lücke „GHOST“ genannt hat.

Viele Applikationen nutzen die glibc und deshalb sind potentiell auch viele Dienste auf Servern von der Lücke betroffen. Postfix kann nicht als Einfallstor genutzt werden. Es nutzt die besagte Funktion seit 2002 nicht mehr. In einer E-Mail schrieb Wietse Venema, der Autor von Postfix, hierzu:

Postfix does not use gethostbyname() since 2002. You have to explictly compile Postfix for pre-IPv6 systems with -DNO_IPV6 to enable the gethostbyname() calls.

Some library function might use gethostbyname(). I have no control over that.

—Wietse Venema

Zu diesem Schluss sind auch die Experten bei Qualys gekommen. Sie testeten viele Applikationen und schreiben in http://seclists.org/oss-sec/2015/q1/283:

"Here is a list of potential targets that we investigated (they all call gethostbyname, one way or another), but to the best of our knowledge, the buffer overflow cannot be triggered in any of them:

apache, cups, dovecot, gnupg, isc-dhcp, lighttpd, mariadb/mysql, nfs-utils, nginx, nodejs, openldap, openssh, postfix, proftpd, pure-ftpd, rsyslog, samba, sendmail, sysklogd, syslog-ng, tcp_wrappers, vsftpd, xinetd."

—Qualys Security Advisory

So ziemlich alle Linux-Distributionen stellen mittlerweile Updates zur Verfügung. Nach dem Einspielen müssen betroffene Dienste gestoppt und gestartet werden - ein reload genügt in der Regel nicht. Ein Reboot ist nicht notwendig.

Thunderbird DKIM Plugin mit DNSSEC und DMARC Anzeige

$
0
0

In einem meiner Artikel habe ich das Thunderbird DKIM Plugin bereits vorgestellt. Ab Version 1.3.2 bietet es nun auch DMARC Anzeige und DNSSEC Prüfung mittels libunbound. Unter Linux kann der Pfad zu der Bibliothek direkt eingestellt werden. Je nach Einstellung kann das DKIM Plugin vor einem DKIM Schlüssel der nicht mit DNSSEC abgesichert ist, warnen. Zusätzlich zeigt es die Einhaltung einer DMARC Policy an. Voraussetzung ist immer ein DNSSEC-fähiger DNS Resolver. Es folgen ein paar Bilder zu den möglichen Einstellungen des Plugins.

/media/uploads/dkim-tb-dnssec.jpg
/media/uploads/dkim-tb-dnssec1.jpg
/media/uploads/dkim-tb-dnssec2.jpg
/media/uploads/dkim-tb-dnssec3.jpg
/media/uploads/dkim-tb-dnssec4.jpg
/media/uploads/dkim-tb-dnssec7.jpg
/media/uploads/dkim-tb-dnssec6.jpg

PGP-Schlüssel einfach und sicher verteilen

$
0
0

„PGP ist kaputt!“ So kann man das Editorial und den Artikel Die Schlüssel-Falle, Gefälschte PGP-Keys im Umlauf von Jürgen Schmidt (c't) in einem Satz zusammenfassen. Die Kritik ist berechtigt. Die Schlüsselverteilung ist eine Schwachstelle im PGP-System. PGP selbst (und auch der IETF-Standard OPENPGP) hat die Schlüsselverteilung nie definiert.

PGP-Anfänger und auch langjährige Benutzer sind mit der manuellen Prüfung von Schlüsseln überfordert. Die PGP-Schlüsselserver waren eine „ad-hoc“ Lösung der PGP-Benutzer der ersten Stunden. Sie wälzt die Prüfung der Schlüssel ganz auf die Benutzer ab und gestattet das Einstellen von Schlüsseln für fremde E-Mail-Adressen (im c't Artikel „gefälschte Schlüssel“ genannt).

Dieses System hat mehrere Schwachstellen in der Benutzbarkeit. Es versucht nicht, eine Fehlbedienung durch den Benutzer zu verhindern. In einem Sicherheitsprotokoll wie PGP ist eine Fehlbedienung fatal. Sie bricht die Sicherheit des Systems, ohne dass dies dem Benutzer bewusst wird. In Sicherheitssoftware ist eine solche Möglichkeit einer Fehlbedienung ein schwerer Fehler, und sollte mit der gleichen Priorität behandelt und beseitigt werden wie ein Software-Fehler (z. B. Buffer-Overflow oder schlechte Zufallszahlen).

Das PGP-System ist nicht kaputt. Die Benutzbarkeit muss verbessert werden!

Ein Ansatz, den Schlüsselaustausch im PGP-System sicherer und für den Benutzer einfacher zu gestalten, ist der OPENPGPKEY-Draft der IETF. Mit der dort beschriebenen Methode kann der Besitzer einer E-Mailadresse den zur Adresse passenden (öffentlichen) PGP-Schlüssel im DNS veröffentlichen.

Die DNS-Zone sollte dazu mit DNSSEC abgesichert sein, damit sichergestellt ist, dass die Key-Informationen wirklich vom Schlüsselbesitzer stammen. DNSSEC authentiziert den Domain-Besitzer als Autor der DNS-Daten, hier des PGP-Keys.

Bemerkung

OPENPGPKEY vereinfacht das Finden und Laden eines PGP-Schlüssels in den eigenen Schlüsselring. Die Methode ersetzt aber nicht die Prüfung des Schlüssels. Der Anwender sollte auf jeden Fall den per OPENPGPKEY geladenen Schlüssel mittels des Web-of-Trust oder anderer Verfahren prüfen. Auch bei dieser Prüfung müssen Programme den Benutzer besser unterstützen, als es mit den bisherigen Werkzeugen möglich ist. Dies ist eine weitere „Baustelle“ im PGP-System.

Die Vorteile

Eine Mail-Anwendung die PGP unterstützt kann die PGP-Schlüssel-Informationen über eine DNS-Anfrage ermitteln und die Quelle der Daten über DNSSEC prüfen. Verglichen mit den PGP-Schlüsselservern hat dieses System einige Vorteile:

Eine autorisierte Stelle
Gegenwärtig kann jeder für jeden PGP-Schlüssel publizieren. Genau das war im Fall von Jürgen Schmidt geschehen und wurde zum Anlass den Artikel zu schreiben. OPENPGPKEY verhindert das effektiv. Es macht die DNS-Zone, zu der die E-Mail-Adresse des Empfängers gehört, zur autorisierten Instanz für Auskünfte zu PGP-Schlüsseln. Nur der Besitzer der DNS-Domain kann die PGP-Schlüssel publizieren.
Saubere Schlüsselverwaltung
Der Besitzer der DNS-Domain kann dort aufgeführte PGP-Schlüssel jederzeit entfernen oder ersetzen. Dies ist bei den heute eingesetzten PGP-Schlüsselservern nicht möglich und stellt ein gängiges Problem dar. Alte PGP-Schlüssel ohne Ablaufdatum, deren Passphrase beispielsweise vergessen wurde können nicht entfernt werden. Sie liegen nun für die Ewigkeit auf den PGP-Schlüsselservern. Ein Fehler, den auch der Autor dieses Artikels bei den ersten Gehversuchen mit PGP gemacht hatte….
Bewährte Technologie
Die Abfrage der Schlüssel über DNS ist nicht aufwendig. Sie kann kann einfach in bestehende Anwendungen implementiert werden.

Wie funktioniert OPENPGPKEY?

OPENPGPKEY speichert den vollständigen, öffentlichen Teil des PGP-Schlüssels in einer DNS-Zone. Dieser Teil wird der E-Mail-Adresse des Schlüsselbesitzers über einen OPENPGPKEY Resource-Record (RR) zugeordnet. Die E-Mail-Adresse wird aber nicht einfach so gelistet, sondern nach einem bestimmten Schema.

Das Schema setzt sich zusammen aus:

  • einem SHA224 Hash des local-part der E-Mail-Adresse (dem Teil vor dem "@")
  • dem Sub-Domain Selektor _openpgpkey
  • und der Domain der E-Mail-Adresse

Für die E-Mail-Adresse cs@sys4.de ergibt sich damit z.B. folgender OPENGPGKEY record:

f437b55d4fb40f93bbfa04802a6a2bcf8b69d5ee93d1b53259e6e4fc._openpgpkey.sys4.de.
|                                                       |           |        |
|                       SHA224 Hash                     | selector  | domain |

Der OPENPGKEY record kann einfach mit dem Kommandozeilenprogramm hash-slinger (als Paket in Fedora vorhanden) erstellt werden:

# openpgpkey --create cs@sys4.de

Bemerkung

Debian und Ubuntu-Anwender aufgepasst! Für den Einsatz in diesen Distributionen ist (noch) ein Patch einer Python-Library erforderlich. Näheres beschreibt Paul Wouters im hash-slinger-Repo.

Der ausgegebene DNS-Record wird dann in der DNS-Zone publiziert, und die Zone per DNSSEC signiert.

DNS Record Typ

Für den OPENPGPKEY-Record wurde ein eigener DNS Record Typ verabschiedet. Es ist der DNS-Record-Typ 61. Ältere Nameserver kennen diesen Record-Typ verständlicherweise noch nicht. Benutzer älterer BIND 9 Versionen oder anderer DNS-Server, welche den OPENPGPKEY-Record noch nicht unterstützen, müssen die Daten in der generischen Kodierung für DNS-Records (siehe: RFC 3597 - „Handling of Unknown DNS Resource Record (RR) Types„) in der DNS-Zone eintragen.

Bemerkung

OPENPGPKEY-Records werden von BIND 9 DNS-Server ab den Versionen 9.10.2 und 9.9.7 unterstützt.

Für das Tool von Paul Wouters ist beides kein Problem. Es kann beide Versionen - generic ist Typ 61 und rfc entspricht dem neuen OPENPGPKEY - erzeugen:

openpgpkey --create --output generic cs@sys4.de
; keyid: 38CECA690C6A6A6E
f437b55d4fb40f93bbfa04802a6a2bcf8b69d5ee93d1b53259e6e4fc._openpgpkey.sys4.de. \
    IN TYPE61 \# 3340 <PGPKEY>

openpgpkey --create --output rfc cs@sys4.de
; keyid: 38CECA690C6A6A6E
f437b55d4fb40f93bbfa04802a6a2bcf8b69d5ee93d1b53259e6e4fc._openpgpkey.sys4.de. \
    IN OPENPGPKEY <PGPKEY>

Mit der Erstellung dieser RRs liegen die Informationen passend vor, um PGP nun einfacher zu gestalten.

Bemerkung

Kann man das schon einsetzen? OPENPGPKEY befindet sich auf der Zielgeraden zum IETF Standard. Der sogenannte WGLC (working group last call) steht unmittelbar bevor. Ich erwarte, dass die Arbeiten im ersten Halbjahr 2015 abgeschlossen werden und OPENPGPKEY als RFC-Dokument veröffentlicht wird.

Schlüsselpflege sys4-style

OPENPGPKEY vereinfacht und sichert die Schlüsselverteilung für Nutzer, aber nicht für deren Anbieter. Wir haben OPENPGPKEY bei sys4 in Betrieb. Uns war wichtig, dass die Besitzer der Schlüssel ihre Schlüssel jederzeit selbstständig aktualisieren können. Sie sollten nicht auf einen DNS-Administrator oder ein DNS-Provisionierungssystem angewiesen sein.

Die Zone sys4.de ist eine per statischer Zonen-Datei administrierte Zone. Sie wird auf einem hidden-Master DNS-Server gepflegt. Beide Eckpunkte, statische Administration und hidden-Master, sollten erhalten bleiben. Wir haben deshalb die Sub-Domain _openpgpkey auf einen DNS-Server delegiert. Dort ist sie als dynamische Master-Zone so eingebunden, dass direkt im Internet aktualisiert werden kann.

In der Hauptzone sys4.de steht dazu in der Zonen-Datei:

$ORIGINsys4.de._openpgpkeyINNSdanens1.sys4.de.INNSdanens2.sys4.de.INDS5796182(608C7B2A38C3330AAFD0DC079BDD56362F80C69A68FE9F85304F67C91EF34A85)

Als Master-DNS-Server für die neue Zone _openpgpkey.sys4.de. kommt ein BIND 9 9.10.2 Server, der schon mit den neuen OPENPGPKEY RRs umgehen kann, zum Einsatz. Dort ist die Zone als dynamische Zone eingetragen:

zone"_openpgpgkey.sys4.de"{typemaster;auto-dnssecmaintain;update-policy{grant*._openpgpkey.sys4.de.self*._openpgpkey.sys4.de.;  };file"master/_openpgpkey.sys4.de";};

Die so formulierte update-policy erlaubt einem Besitzer, eines in der BIND 9 Konfiguration hinterlegten TSIG-Schlüssels, einen Record zu ändern. Der Besitzer darf sein eigenen Eintrag, über ein ein dynamisches Update, erstellen, ändern und löschen. Vorausgesetzt er wendet das auf den gleichen Domain-Namen an auf den der TSIG-Schlüssels (self) ausgestellt wurde.

Dazu hat der Administrator der _openpgpkey-Zone für jeden Mitarbeiter einen eigenen TSIG-Schlüssel mit dem Namen des OPENPGPKEY-Records des Mitarbeiters erzeugt (Befehl fuer BIND 9.9.x):

# dnssec-keygen -a HMAC-SHA256 -b 256 -n HOST \
    f437b55d4fb40f93bbfa04802a6a2bcf8b69d5ee93d1b53259e6e4fc._openpgpkey.sys4.de.

oder mit BIND 9.10.x:

# tsig-keygen f437b55d4fb40f93bbfa04802a6a2bcf8b69d5ee93d1b53259e6e4fc._openpgpkey.sys4.de.

TSIG-Schlüssel sind symmetrische Schlüssel, der erstellte Schlüssel wird dem Mitarbeiter auf sicherem Wege zugestellt und in der BIND 9 named.conf eingetragen:

key"f437b55d4fb40f...69d5ee93d1b53259e6e4fc._openpgpkey.sys4.de."{algorithmHMAC-SHA256;secret"<secret-key-data>";};

Bemerkung

Auf Dauer wollen wir die symmetrischen TSIG-Schlüssel durch assymetrische SIG(0)-Schlüssel ersetzen, so dass die Mitarbeiter auch ihre DNS-Update-Schlüssel ohne Zutun des DNS-Administrators selbst verwalten können. Mehr dazu in einem späteren Blog-Post…

Wir können nun mit dem BIND 9 Programm nsupdate (BIND 9.9.7, BIND 9.10.2 oder neuer) die eigenen OPENPGPKEY-Record-Daten ändern. Das folgende Script hilft uns dabei. Es automatisiert den Export des öffentlichen Schlüssels, generiert den OPENPGPKEY RR und führt die Kommandos aus, um den neuen Eintrag an den DNS-Server zu übermitteln:

#!/bin/sh# Usage: openpgpkey-update <email-address> <tsig-key-file># generate the OPENPGPKEY record using the openpgpkey command from# hash-slingeropenpgpkeyrr=$(openpgpkey --create --output rfc $1 | tail -1)# get the domain name of the resource recorddomain=$(echo$openpgpkeyrr | cut -d " " -f 1)# send the DNS update# requires nsupdate 9.9.7, 9.10.2 or newer
nsupdate -k $2<< EOFttl 3600del $domain OPENPGPKEYadd $openpgpkeyrrsendquitEOF

Vorsicht!

Das Kommando nsupdate ist bis zur Version 9.9.6-P2 auf die Übermittlung 4K grosser Einträge limitiert. Weil PGP-Schlüssel aber schnell mal grösser als 4K werden, kommt es hier zu Problemen. Ein Update mit derarte limitierten nsupdate-Versionen schlägt fehl (siehe auch: size limit on RDATA in nsupdate). In BIND 9.10.x und 9.9.7 wurde der Buffer in nsupdate für Records auf 128K vergrössert. Das sollte auch für PGP-Keys mit vielen Unterschriften ausreichen.

Beispiel-Aufruf des Scripts:

./openpgpkey-update cs@sys4.de cs-openpgp.tsig

Die TSIG-Schlüssel-Datei "cs-openpgp.tsig":

key"f437b55d4fb40f93bbfa04802a6a2bcf8b69d5ee93d1b53259e6e4fc._openpgpkey.sys4.de."{algorithmhmac-sha256;secret"<secret-tsig-key>";};

Wir versuchen die DNS-Update Funktion direkt im Befehl "openpgpkey" des "hash-slinger" Paketes zu implementieren, so das ein extra Script und auch "nsupdate" nicht notwendig sind.

OPENPGPKEY benutzen

OPENPGPKEY ist ein Glied in einer Kette verschiedener Maßnahmen, die Nutzung von PGP sicherer und anwenderfreundlicher zu gestalten. Nur wenige Produkte unterstützen OPENPGPKEY heute.

Sicherer ist die Beschaffung des Schlüssels schon heute. Mit dem Befehl openpgpkey kann ein PGP-Schlüssel aus dem DNS gelesen und in GNU-Privacy-Guard eingespielt werden. Dabei prüft der openpgpkey-Befehl, ob die empfangenden Daten erfolgreich per DNSSEC validiert wurden und somit vertrauenswürdig sind:

$ openpgpkey --fetch cs@sys4.de | gpg --import

Wer Verschlüsselung automatisieren möchte, sieht sich den OPENPGPKEY-Milter an. Dieser Milter kann z.B. in einen Postfix- oder Sendmail-Mailserver eingebunden werden. Dort prüft er bei jeder noch nicht mit PGP verschlüsselten E-Mail ob OPENPGPKEY-Daten für die Emfänger der E-Mail vorhanden sind.

Sind OPENPGPKEY-Daten über entsprechende OPENPGPKEY RRs im DNS des Empfängers, lädt der Milter die Daten und verschlüsselt die E-Mail mit den PGP-Schlüsseln der Empfänger. Dies passiert transparent und ohne Eingriffe durch den E-Mail Benutzer. Der Benutzer muss sich nicht um die Verwaltung der PGP-Schlüssel kümmern und kann trotzdem von der Sicherheit des PGP-Systems profitieren.

PGP muss erwachsen werden!

PGP ist nicht tot. PGP mit den bisher vorhandenen Werkzeugen und Schlüssel-Verteil-Protokollen ist nicht benutzerfreundlich. Es ist keine universelle Verschlüsselungslösung. Die Teilnehmer der IETF arbeiten an Protokoll-Erweiterungen, um die Benutzung von PGP zu erleichtern und damit die Sicherheit zu erhöhen.

Damit diese neuen Protokolle und Erweiterungen ein Erfolg werden, müssen diese in möglichst vielen Produkten eingebaut werden. Uns Anwendern kommt die Aufgabe zu, die neuen Funktionen und Verbesserungen bei den Programmierern und Herstellern einzufordern (bzw. bei freier und Open-Source-Software selbst zu Implementieren oder die Projekte zu unterstützen) .

Unbound mit privaten reverse Zonen

$
0
0

Kürzlich wollte ich einen lokalen caching only DNS Resolver mit Unbound in einem Intranet aufsetzen. Es zeigte sich, dass die Einrichtung für private Reverse Zonen nicht ganz einfach ist. Hier nur kurz ein Ausschnitt der dafür relevanten Teile der Konfig.

forward-zone:name:"example.com"forward-addr:ip.ad.re.sseforward-addr:ip.ad.re.sseforward-first:yes#Optionforward-zone:name:"example.org"forward-addr:ip.ad.re.sseforward-addr:ip.ad.re.sseforward-first:yes# Optionserver:local-zone:"168.192.in-addr.arpa."nodefaultstub-zone:name:"168.192.in-addr.arpa."stub-addr:ip.ad.re.ssestub-addr:ip.ad.re.sseserver:local-zone:"10.in-addr.arpa."nodefaultstub-zone:name:"10.in-addr.arpa."stub-addr:ip.ad.re.ssestub-addr:ip.ad.re.sse

Alternativ zu forward-zone lt. Carsten Strotmann:

Um eine Anfrage an einen DNS-Server weiterzuleiten, der authoritativ fuer die Zone ist (also mit einem "AA"-Flag antwortet), sollte eine "stub" Zone verwendet werden. Per "stub" Zone wird die normale DNS-Aufloesung um eine private Delegation ergaenzt. Das ist schneller und sauberer als Forwarding.

stub-zone:name:"example.com"stub-addr:ip.ad.re.ssestub-addr:ip.ad.re.ssestub-prime:yes#Optionstub-zone:name:"example.org"stub-addr:ip.ad.re.ssestub-addr:ip.ad.re.ssestub-prime:yes# Option

Postfix gegen SSL FREAK Attacke sichern

$
0
0

Die SSL FREAK-Attacke betrifft jeden Dienst, der EXPORT-Chiffren innerhalb einer SSL/TLS-Session anbietet. Die Entwickler verschiedener SSL-Libraries arbeiten an Patches, um diese Schwachstelle zu beseitigen. Bis dahin ist es am einfachsten, die Nutzung von EXPORT-Chiffren einfach zu verbieten. Der Server bietet dann keine EXPORT-Chiffre an und die Schwachstelle kann nicht ausgenutzt werden.

In Postfix muss dazu in der Datei main.cf der Parameter smtpd_tls_exclude_ciphers gesetzt sein und mindestens folgende Optionen müssen gegeben werden:

smtpd_tls_exclude_ciphers=EXPORT, LOW

Nach einem postfix reload ist der SMTP-Server gegen FREAK gesichert.


Dovecot gegen SSL FREAK Attacke sichern

$
0
0

Die SSL FREAK-Attacke betrifft jeden Dienst, der EXPORT-Chiffren innerhalb einer SSL/TLS-Session anbietet. Die Entwickler verschiedener SSL-Libraries arbeiten an Patches, um diese Schwachstelle zu beseitigen. Bis dahin ist es am einfachsten, die Nutzung von EXPORT-Chiffren einfach zu verbieten. Der Server bietet dann keine EXPORT-Chiffre an und die Schwachstelle kann nicht ausgenutzt werden.

In Dovecot muss dazu in der Datei /etc/dovecot/conf.d/10-ssl.conf der Parameter ssl_cipher_list aktiviert und editiert werden. Folgende Optionen müssen mindestens gegeben werden:

# SSL ciphers to usessl_cipher_list=ALL:!LOW:!SSLv2:!EXP:!aNULL:!EXPORT

Nach einem doveadm reload ist der IMAP-Server gegen FREAK gesichert.

OPENPGPKEY mit Unix Bordmitteln

$
0
0

Im Artikel "PGP-Schlüssel einfach und sicher verteilen" habe ich beschrieben wie OPENPGPKEY DNS-Records mit dem Tool hash-slinger erstellt werden können. Bei einigen Unix/Linux Systemen ist "hash-slinger" aber nicht vorhanden.

PGP Schlüssel abfragen

OPENPGPKEY Records können auch per Unix Boardmitteln erstellt und abgefragt werden. Das Script "openpgp-fetch" benutzt das Programm "dig" aus dem BIND 9 Paket ("dns-utils" oder "bind9-utils", funktioniert auch mit älteren Versionen des "dig" Programms):

#!/bin/bash# fetches an OPENPGPKEY and pipes the key into gpg# based on a Twitter msg by Paul Wouters (https://twitter.com/letoams/status/560834359981539329)maildomain=$(echo$1 | cut -d "@" -f 2)localmail=$(echo$1 | cut -d "@" -f 1)openpgpkeydomain=$(echo -n $localmail | openssl dgst -sha224 | cut -d "=" -f 2)._openpgpkey.$maildomain
dig +short +vc type61 $openpgpkeydomain | sed "s/ [^ ]*//;s/\W//g" | xxd -r -p | gpg

Als Parameter wird die E-Mail Adresse des PGP-Schlüsselbesitzers angegeben:

# openpgp-fetch cs@sys4.de

OPENPGPKEY Record erstellen

Das zweite Script erstellt einen OPENPGPKEY Record für eine E-Mail Adresse und sendet den Record als dynamischen DNS-Update an den Master-DNS-Server. Bei korrektem SOA-Record in der DNS-Zone für die OPENPGPKEYs wird der Master-Server vom "nsupdate" Programm automatisch ermittelt. Dieses Script funktioniert auch mit älteren Versionen von "nsupdate", solange der PGP-Schluessel in der Hex-Kodierung kleiner als 4 Kilobyte ist. Bei grösseren Schlüssel muss das "nsupdate" aus BIND 9.10.x benutzt werden.

#!/bin/bashmaildomain=$(echo$1 | cut -d "@" -f 2)localmail=$(echo$1 | cut -d "@" -f 1)openpgpkeydomain=$(echo -n $localmail | openssl dgst -sha224 | cut -d "=" -f 2)._openpgpkey.$maildomainkeysize=$(gpg --export --export-options export-minimal $1 | wc -c)keydata=$(gpg --export --export-options export-minimal $1 | hexdump -e '"\t" /1 "%.2x"' -e '/65536 "\n"')# send the DNS update
nsupdate -k $2<< EOFupdate delete $openpgpkeydomain TYPE61update add $openpgpkeydomain 3600 IN TYPE61 \# $keysize $keydatasendquitEOF

Als erster Parameter wird die E-Mail Adresse des PGP-Schlüsselbesitzers angegeben, der zweite Parameter ist ein TSIG-Schlüssel, welcher das dynamische Update der DNS-Zone erlaubt:

# openpgp-create cs@sys4.de cs-tsig.key

Dank an ...

Dank an meine Kollegen (speziell Michael, Florian, Robert, Patrick, Wolfgang) für Feedback und Ideen zu den Scripten.

SNMP Proxy

$
0
0

A very little known feature of SNMP is the proxy. You can configure a good SNMP agent to proxy requests to an other SNMP entity. In this article I want do cast some light on this feature. I use it to request performance data form a switch that speaks only IPv4 while the transport network between the management station and the agents is IPv6.

Motivation

Why would someone proxy SNMP request? There are some good reasons to do this. You need the proxy function always if no direct communication between the manager and the agent is possible. This happens if hosts are located in a network with private RFC 1918 addresses behind a NAT device or a firewall. The management station can only communicate with one proxy host in that network.

In my case I have a network with some routers, switches and servers at home and a network management station (OpenNMS) in the internet. The providers here in Germany reset your internet connection every 24 hours and you get a new IPv4 address when you reconnect. To access all my internal devices I use IPv6. I have a tunnel from sixxs net and a subnet behind that tunnel. All IPv6 addresses are static and so I do not need any dynamic DNS provider.

The only problem is, that some old devices cannot speak IPv6. So my management system cannot communicate directly with these devices. That is when I found out about the SNMP proxy. I can use it not only for accessing devices behind a fireawall or NAT, but the proxy also works as a translator between IPv6 and IPv4.

Sketch of the network setup.

Sketch of the network setup. The NMS talks to the server with IPv6 and the server pxroxies the request of to the switch with IPv4.

But you can do a lot more weired things with a SNMP proxy. For details see the explanation page of SNMP Research International.

Configuration of the net-snmp Agent

On my server at home I use the open source net-snmp agent. Since I want to proxy the complete requests to an other system I need a criterium what requests to process locally and what requests forward to the remote system. SNMP defines to use the context in this case. The web site of net-snmp documents the proxy configuration.

In the agent I configure a full VACM definition for the proxy access in snmpd.conf:

# com2sec6 [-Cn CONTEXT]   SECNAME          SOURCE    COMMUNITY
com2sec6   -Cn oldswitch   notConfigUser6   default   oldpublic

# group    GROUP           {v1|v2c|usm}     SECNAME
group      OLDSWITCH       v2c              notConfigUser6

# view     VNAME           TYPE             OID   [MASK]
view       all             included         .1

# access   GROUP           CONTEXT          {any|v1|v2c|usm}  LEVEL  PREFX  READ WRITE NOTIFY
access     OLDSWITCH       oldswitch        v2c               noauth exact  all  none  none

This defines the context oldswitch whenever the community string oldpublic is used. Now I can use that context to proxy the request to the old switch

# proxy [-Cn CONTEXTNAME]  [SNMPCMD_ARGS]    HOST         OID
proxy   -Cn oldswitch      -v 2c -c public   192.0.2.240  .1.3

This configuration line defines that all incomming requests in the context oldswitch are forwarded to my old switch that does not speak IPv6 and only has a private address. In the example above I use a documentation address. Please note that the OID must be .1.3, not just the .1.

Accessing the SNMP Data

From my management station I can test the proxy function. First I access the agent on my server without the proxy function:

# snmpgetnext -v 2c -c public udp6:2001:db8::10 sysName
SNMPv2-MIB::sysName.0 = STRING: server01

When I use the community string for the old switch, the request is forwarded to the old switch and I get its answer:

# snmpgetnext -v 2c -c oldpublic udp6:2001:db8::10 sysName
SNMPv2-MIB::sysName.0 = STRING: switch02

SNMP Proxy in OpenNMS

Of course you can configure the proxy also in every good monitoring system. I use OpenNMS. The SNMP proxy is configured in the definition file for the SNMP access. My old switch needs a separate entry:

<snmp-config xmlns="http://xmlns.opennms.org/xsd/config/snmp"version="v2c"\read-community="public"timeout="1800"retry="1">
  (...)<definition write-community="private"read-community="oldswitch" proxy-host="2001:db8::10"port="161">
    <specific>192.0.2.240</specific>
  </definition>
</snmp-config>

Now the management system accesses the SNMP data through the proxy and you get all the data needed.

Postfix Gateway with blind carbon copy Multiplicator

$
0
0

Here is an exotic Postfix gateway feature I did. It shows how to setup bcc copy with multiple recipients, while sending to an internal mailserver via a smtp transport.

Some advanced mail admins might wonder about the following lines, so here is the short story what real world scenario was solved with it.

First Postfix was choosen as a typical excellent antispam/antivirus gateway for one internal mailsystem with one maildomain. Over time the customer company absorbed many other companies and renamed them to departments with similar maildomain names leaving existing mailservers at their outside offices in action as a temp solution. Emails to their main maildomain should be passed to their head quarter and cloned to outside departments. So traveling mailusers should have their mails in every office. I only show the clone part here.

Building the multiplicator

Absolutely usual at gateways first declare which domains are allowed in main.cf:

relay_domains=hash:/etc/postfix/relay_domains

In this example relay_domains contains the following domain:

example.comOK

Then declare allowed email addresses using relay_recipients in main.cf:

relay_recipient_maps=hash:/etc/postfix/relay_recipients

The relay_recipients table contains the following entries:

alpha@example.comOKbeta@example.comOKgamma@example.comOK

Now here's the trick. Put these recipients into a virtual_alias' map. First tell Postfix about the map in `main.cf:

virtual_alias_maps=hash:/etc/postfix/virtual_alias

The recipients in a virtual_alias map are:

bcc_duplicator_alpha@example.comalpha@example.orgalpha@example.netbcc_duplicator_beta@example.combeta@example.orgbeta@example.net

Now tell Postfix to BDD to the virtual aliases. Again tell Postfix about the map in main.cf:

recipient_bcc_maps=hash:/etc/postfix/recipient_bcc

Then fill the map with re-routings to the virtual aliases:

alpha@example.combcc_duplicator_alpha@example.combeta@example.combcc_duplicator_beta@example.com

Finally create the transport towards the internal mailserver in main.cf:

transport_maps=hash:/etc/postfix/transport

My example map specifies the following routing:

example.comsmtp:192.0.2.1

Note

You can't specify multiple recipients in the right hand side of the recipient_bcc_maps, so i had to go this way.

Outlook 2016 preview Blog

Viewing all 268 articles
Browse latest View live