Tag: debian

  • Adding sa-exim to Exim

    Until now I have been using SpamAssassin using the spam content scanning built into Exim. This gives me detailed control over what happens to messages. However, I decided I wanted to review the messages that are rejected.  Looking at my options sa-exim appeared to be a simple solution. I found it was as simple as I hoped. This article covers how I implemented it on Ubuntu and should be directly applicable to other Debian-based distributions.

    Read more: Adding sa-exim to Exim

    The eximstats utility includes code to analyze the messages generated by sa-exim. This provides statistics on ham and spam.

    As sa-exim is somewhat obsoleted by the ability to call Spamassassin (and Rspamd) directly, I have replicated the functionality as an inclusion to the Data ACL. It is covered in another post.

    Installation

    As I already had SpamAssassin installed, adding sa-exim was simple. I merely need to run the command sudo apt-get install sa-exim. This installed the package and added it into the split configuration of Exim. If are modifying your configuration, it is much simpler to use the split configuration. Besides the installed changes you are likely going to want to add the ACLs specified here. These are outlined as additions to the split configuration but could be added to the unsplit configuration. (Comments on adapting these changes to the unsplit configuration are specified a the end.) This configuration should work with the default exim-daemon-light package.

    Defining Options and Macros

    The file /etc/exim4/exim4.conf.localmacros contains options and macros for the unsplit configuration file. When using the split configuration these are loaded from the /etc/exim4/conf.d/main directory. By creating a 00_localmacros symlink pointing to /etc/exim4/exim4.conf.localmacros the same configuration can be used for both the split and unsplit configurations.

    # Define macrs to use local check-rcpt and check-data rules
    CHECK_RCPT_LOCAL_ACL_FILE = CONFDIR/acls/30_local-config_check-rcpt
    CHECK_DATA_LOCAL_ACL_FILE = CONFDIR/acls/40_local-config_check-data
    
    # Specify recipients not be to be rejected - default postmaster
    CHECK_RCPT_POSTMASTER = postmaster : spamtrap
    
    # Specify spamd location and allow retry
    spamd_address = 127.0.0.1 783 retry=10s
    

    Enabling sa-exim

    As shipped sa-exim is disabled. The sa-exim.conf file has a default setting indicating that no messages are to be scanned. This file needs to be edited to evaluate conditions enabling scanning and rejection of messages.

    I found three methods that could be used.

    • Creating an if statement to evaluate the remote address to determine if the message should be scanned;
    • Setting the variable acl_m0 to “do_not_scan”, “canreject”, or a third value to cover all conditions; or
    • Adding headers indicating whether scanning or rejection is desired. (This has and advantage of making the settings visible in the headers of the delivered message.)

    I chose to use the extended variable format and set variables if scanning is desired or message rejection is permitted. The configuration treats the variables as false if they are not set. The variables I chose are acl_m_scan and acl_m_canreject. As the variables may not be set, the conditions below may need to be modified if your configuration requires a referenced variable to exist. On older Exim versions variables like acl_m0 and acl_m1 could be used.

    The simplest way to configure sa-exim is to append the desired configuration items to the end of the installed sa-exim.conf file. This makes local settings easy to locate. Commented settings below are set to the default values.

    # Scanning and rejection conditions noted above
    # bool_lax works better than bool
    SAEximRunCond: ${if bool_lax{$acl_m_scan}}
    SAEximRejCond: ${if bool_lax{$acl_m_can_reject}}
    
    # Generic conditions
    SAEximDebug: 0
    SAspamcUser: mail
    #SAmaxbody: 256000
    SAmaxrcptlistlength: 8000
    
    # Thresholds - SAdevnull is commented in the default settings
    #SAdevnull: 25.0
    #SApermreject: 12.0
    
    # Conditions controlling saving a copy of the message
    # Disable these if you are not going to examine the results
    #SAtimeoutSavCond: 1
    #SAerrorSavCond: 1
    #SAdevnullSavCond: 1
    #SApermrejectSavCond: 1

    Extending ACLs

    The default Ubuntu/Debian configuration allows for local additions to the Recipient and Data ACLs by file inclusion. These files survive updates to the default configuration.

    If your configuration does not have the inclusion capability, the inclusions below should be added just before the final accept clauses in the relevant ACL. Alternatively, you can add code to include the additions in the same location. The code used to include the recipient addition is:

      .ifdef CHECK_RCPT_LOCAL_ACL_FILE
      .include CHECK_RCPT_LOCAL_ACL_FILE
      .endif

    I use the directory /etc/exim4/acls to contain the inclusion files. Using file inclusion adds a slight overhead when new Exim processes are started. This is trivial compared to the total overhead of processing a message.

    Extending the Recipient ACL

    This ACL enables rejection of the message with high spam scores. Mail sent only to the postmaster or similar accounts will be flagged and delivered. If the postmaster is one of several recipients (which should not be the case), the message may be rejected. The macro CHECK_RCPT_LOCAL_ACL_FILE points to this file.

    ### /etc/exim4/acls/30_local-config_check_rcpt
    #####################################
    
    #### NOTE: If we get here the sender is remote and unauthenticated
    
      # Not postmaster or local sender so enable spam rejection
      warn
        set acl_m_reject = yes
    

    Extending the Data ACL

    The Data ACL process all SMTP messages after the Data has been received. This is the last ACL called before the sa-exim code is executed. If desired, the Data ACL can be configured as the non-SMTP ACL.

    The Data ACL inclusion marks messages for sa-exim to scan. This setting must be done the scanning will not be done.

    ### acls/40_local-config_check_data
    #####################################
    
      # Scan message if unauthenticted and remote
      warn
        !authenticated = *
        !hosts = : +relay_from_hosts
        set acl_m_scan = yes

    The Data ACL processes messages after the data has been received. It does not process non-SMTP messages in the default configuration.

  • Using SSL Keys

    I recently updated my SSL keys. Several servers are accessed by keys from a few devices. A common authorized_hosts file was created as a template. This post covers the generation and use of SSL keys.

    (more…)
  • HTTP2 on Apache2

    HTTP2 allows web servers to serve multiple content streams on the same connection. This can reduce server and network load. I have updated my Ubuntu Apache servers to enable HTTP2.

    After installing the latest Ubuntu release, I needed to redo the switch to the event Multi-Processing Module (MPM) and switch PHP content delivery back to the php-fpm daemon. I had to repeat the process I originally used as documented here.

    (more…)
  • Banner message for ssh

    Using a pre-authentication banner with ssh can verify identification before a password is entered. This can help prevent leaking passwords. Banners are simple to configure but often disabled in the default configuration.

    (more…)
  • fail2ban non-root startup

    fail2ban runs as root by default. This is unnecessary for its functionality, other than to alter firewall rules. The firewall rules can be safely done, using sudo to enable the required calls. The Debian/Ubuntu init.d file has provisions to start fail2ban as a non-root user, but newer releases use systemd to start and stop the process. This requires a different procedure. This procedure is for my servers which use Shorewall to maintain the firewall. I will document my process for configuring fail2ban in another post. ​First, create the user as a system user with a group(s) required to read the logs. Fail2ban does not need a shell. The home directory is set like similar system users on Ubuntu systems.

    This procedure is for my servers which use Shorewall to maintain the firewall. I will document my process for configuring fail2ban in another post.
    ​First, create the user fail2ban as a system user with the group(s) required to read the logs. Fail2ban does not need a shell. The home directory is set like similar system users on Ubuntu systems.

    useradd --system --no-create-home --home-dir /var/lib/fail2ban \
            --groups adm,www-data --shell /usr/sbin/nologin fail2ban

    If you are using an init.d script to start fail2ban, set the user in /etc/default/fail2ban. This file is not used by the systemd. If you are using systemd, there is no need to alter the /etc/default/fail2ban file.

    If you are using systemd to start fail2ban, create the systemd file /etc/systemd/system/fail2ban.service.d/override.conf. If you are not using Shorewall, omit or edit the [Unit] section.

    [Service]
    User=fail2ban
    Group=adm
    Run ExecStartPre with root-permission
    PermissionsStartOnly=true
    ExecStartPre=/bin/chown -R fail2ban:adm /var/run/fail2ban
    [Unit]
    Requires=shorewall.service
    After=shorewall.service

    Create a sudoers file for fail2ban such as /etc/sudoers.d/fail2ban Ensure required operations are included in the Cmnd_Alias definition. This file is configured to use Shorewall and includes all the actions that could be called. If your sudoers configuration does not use an include directory, add the rules to your sudoers file, or enable the use of an include directory.

    Sudoer rules for fail2ban
    User_Alias FAIL2BAN = fail2ban
    Cmnd_Alias FAIL2BAN = /sbin/shorewall allow, /sbin/shorewall6 allow, \
         /sbin/shorewall logdrop, /sbin/shorewall6 logdrop, \
         /sbin/shorewall drop, /sbin/shorewall6 drop, \
         /sbin/shorewall logreject, /sbin/shorewall6 logreject, \
         /sbin/shorewall reject, /sbin/shorewall6 reject \
         /sbin/shorewall blacklist, /sbin/shorewall6 blacklist
    FAIL2BAN ALL = NOPASSWD: FAIL2BAN
    # EOF

    Change the ownership of existing files.

    chown -R fail2ban /var/log/fail2ban* /var/lib/fail2ban

    Finally, stop and restart fail2ban, check for the fail2ban process, and check your fail2ban log for errors

    systemctl stop fail2ban
    systemctl start fail2ban
    ps -fu fail2ban
    tail -60 /var/log/fail2ban.log | less

    If you are using logrotate or a similar application to rotate logs, edit the configuration to create new logs owned by the fail2ban user id.

  • init.d for Non-root Processes

    When installing third-party applications, they often default to running as root. The server applications for TeamSite/LiveSite are among those. I have applied a simple modification to the init.d scripts that start them as a non-root user. It also allows the scripts to be run by members of an administration group via sudo. This approach applies to other applications.

    (more…)
  • Providing IPv6 DNS resolver data with radvd

    One nagging issue I had with IPv6 was how to distribute DNS server addresses and search lists to my clients. It took a little research to find the solution. On IPv4 I had been using DHCP to do this, but DHCP didn’t seem to be the right approach for IPv6. radvd can be used to distribute both types of data. This article covers setup on Ubuntu and OpenWRT. The Ubuntu (Debian) examples below should work with any distribution using/etc/radvd.conf to configure radvd.

    (more…)
  • Blocking Spam with Exim

    Recent reports indicate that spam is increasing again. I have been using Exim to filter spam for several years. Some recent tuning I have done has decreased the percent of spam that reaches my spam filters. This article provides a discussion of the techniques used and provides implementation examples. Spambots tend to be simple programs that don’t handle slow servers very well. Using a greylist is an effective method of blocking them as they usually don’t retry. My latest changes use delays to cause many spambots to abandon their attempt. Greylisting is used only for poorly configured servers that make it to the Recipient command.

    (more…)
  • Implementing DKIM with Exim

    This article was updated in February 2014 to reflect changes in policy and reporting options. The earlier ADSP (Author Domain Signing Practices) information has been removed.

    DomainKeys Identified Mail (DKIM) provides a method to confirm the origin of an e-mail. DKIM also provides some protection against tampering. Unlike SPF, this validation applies to the contents of the message when it is signed. Like SPF, the information required for validation is added to DNS.

    (more…)
  • Cfengine 2 for Debian and Ubuntu

    Cfengine is a declarative system configuration tool. This helps apply standards to system configuration. The configuration files specify the desired configuration and the engine applies these specifications to the system.  It is useful to:

    • Distribute configuration files;
    • Install standard packages (including on Debian and Ubuntu with code provided here);
    • Cleanup old files; and
    • Ensure certain programs are/are not running.

    This documentation applies to Cfengine version 2. Version 3 has made significant changes to the scripting structure but maintains the capability to run the version 2 format files.

    (more…)