Security recommendation

Configuration can be stored in several formats (SQL, File, LDAP) but must be shared over the network if you use more than 1 server. If some of your servers are not in the same (secured) network than the database, it is recommended to use SOAP access for those servers.

You can use different type of access: SQL, File or LDAP for servers in secured network and SOAP for remote servers.

Next, you have to configure the SOAP access as described here since SOAP access is denied by default.

By default, the manager is restricted to the user 'dwho' (default backend is Demo). To protect the manager, you have to choose one or both of :

  • protect the manager by Apache configuration
  • protect the manager by LL::NG

You can use any of the mechanisms proposed by Apache: SSL, Auth-Basic, Kerberos,… Example

<VirtualHost *:443>
    # SSL parameters
    # DocumentRoot
    DocumentRoot /var/lib/lemonldap-ng/manager/
    <Location />
        AuthType Basic
        AuthName "Lemonldap::NG manager"
        AuthUserFile /usr/local/apache/passwd/passwords
        Require user rbowen
        Order allow,deny
        Deny from all
        Allow from
        Options +ExecCGI

To protect the manager by LL::NG, you just have to set this in lemonldap-ng.ini configuration file (section [manager]):

protection = manager
Before, you have to create the virtual host manager.your.domain in the manager and set a rules, else access to the manager will be denied.

Rules are applied in alphabetical order (comment and regular expression). The first rule that matches is applied.

The "default" rule is only applied if no other rule match

The Manager let you define comments in rules, to order them:

For example, if these rules are used without comments:

Regular expression Rule Comment
^/pub/admin/ $uid eq "root"
^/pub/ accept

Then the second rule will be applied first, so every authenticated user will access to /pub/admin directory.

Use comment to correct this:

Regular expression Rule Comment
^/pub/admin/ $uid eq "root" 1_admin
^/pub/ accept 2_pub
  • Reload the Manager to see the order that will be used
  • Use rule comments to order your rules

You can write rules matching any component of URL to protect including GET parameters, but be careful.

For example with this rule on the access parameter:

Regular expression Rule Comment
^/index.php\?.*access=admin $groups =~ /\badmin\b/
default accept

Then a user that try to access to one of the following will be granted !

  • /index.php?access=admin&access=other
  • /index.php?Access=admin

You can use the following rules instead:

Regular expression Rule Comment
^/(?i)index.php\?.*access.*access deny 0_bad
^/(?i)index.php\?.*access=admin $groups =~ /\badmin\b/ 1_admin
default accept
(?i) means case no sensitive.
Remember that rules written on GET parameters must be tested.

Some characters are encoded in URLs by the browser (such as space,…). To avoid problems, LL::NG decode them using So write your rules using normal characters.

LL::NG can protect any Apache hosted application including Apache reverse-proxy mechanism. Example:

PerlOptions +GlobalRequest
PerlRequire /var/lib/lemonldap-ng/handler/
<VirtualHost *:443>
    SSLEngine On
    ... other SSL parameters ...
    PerlInitHandler My::Handler
    ProxyPass /
    ProxyPassReverse /
    ProxyPassReverseCookieDomain /

See mod_proxy and mod_rewrite documentation for more about configuring Apache reverse-proxies.

Such configuration can have some security problems:

  • if a user can access directly to the hidden application, it can bypass LL::NG protection
  • if many hidden applications are on the same private network, if one is corrupted (by SQL injection, or another attack), the hacker will be able to access to other applications without using reverse-proxies so it can bypass LL::NG protection

It is recommended to secure the channel between reverse-proxies and application to be sure that only request coming from the LL::NG protected reverse-proxies are allowed. You can use one or a combination of:

  • firewalls (but be careful if more than 1 server is behind the firewall)
  • server based restriction (like Apache "allow/deny" mechanism)
  • SSL client certificate for the reverse-proxy (see SSLProxy* parameters in mod_ssl documentation)

Go in Manager, General parameters » Advanced parameters » Security:

  • Username control: Regular expression used to check user login syntax.
  • Force authentication: set to 'On' to force authentication when user connects to portal, even if he has a valid session
  • Encryption key: key used to crypt some data, should not be known by other applications
  • Trusted domains: domains on which the user can be redirected after login on portal. Set '*' to accept all.
  • Use Safe jail: set to 'Off' to disable Safe jail. Safe module is used to eval expressions in headers, rules, etc. Disabling it can lead to security issues.
  • Check XSS Attacks: Set to 'Off' to disable XSS checks. XSS checks will still be done with warning in logs, but this will not prevent the process to continue.

For block brute force attack with fail2ban

Edit /etc/fail2ban/jail.conf

enabled = true
port    = http,https
filter  = lemonldap
action   = iptables-multiport[name=lemonldap, port="http,https"]
logpath = /var/log/apache*/error*.log
maxretry = 3

and edit /etc/fail2ban/filter.d/lemonldap.conf

# Fail2Ban configuration file
# Author: Adrien Beudin
# $Revision: 2 $


# Option:  failregex
# Notes.:  regex to match the password failure messages in the logfile. The
#          host must be matched by a group named "host". The tag "<HOST>" can
#          be used for standard IP/hostname matching and is only an alias for
#          (?:::f{4,6}:)?(?P<host>[\w\-.^_]+)
# Values:  TEXT
failregex = Lemonldap\:\:NG \: .* was not found in LDAP directory \(<HOST>\)
            Lemonldap\:\:NG \: Bad password for .* \(<HOST>\)

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
ignoreregex =

Restart fail2ban