Tango Devlopment

Category: System Administration

  • 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 fail2ban as system user with 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 system user with 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 value is not used by 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. Omit the [Unit] section if you are not using Shorewall.

    [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_Aalias 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 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 logreject, /sbin/shorewall6 reject
    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 fail2ban or a similar application to rotate logs, edit the configuration to create new logs owned by the fail2ban userid.

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

  • WordPress SSH2 configuration

    Instead of the packaged WordPress I run the version provided by WordPress. It is installed using a different userid from the userid the web server runs as.  To enable updates from the Admin Dashboard, I enabled sftp (ssh). This is how I did it.

    Using the sftp option requires the php ssh module. This command installs the php ssh module.

    apt install php-ssh2

    The FTP funtionality includes the sftp (ssh2) option for connectivity.  To enable this the /etc/wordpress/config.php file must be updated to include the following lines. (Use the appropriate directories for your installation.)

    // This value should be ssh2 not ssh
    define('FS_METHOD', 'ssh2');
    define('FTP_BASE', '/var/www/');
    define('FTP_CONTENT_DIR', '/var/www/wp-content/');
    define('FTP_PLUGIN_DIR ', '/var/www/wp-content/plugins/');
    define('FTP_PUBKEY', '/etc/wordpress/.ssh/id_rsa.pub');
    define('FTP_PRIKEY', '/etc/wordpress/.ssh/id_rsa');
    // user that owns wordpress install - should not be root
    define('FTP_USER', 'wordpress');
    // password for FTP_USER username - may be empty
    define('FTP_PASS', 'changeme');
    // hostname:port combo for your SSH/FTP server
    define('FTP_HOST', 'localhost');

    The following script creates and populates the directories required for ssh to work. An ssh key is generated and granted restricted access to the user owning the distribution. The last command verifies the setup.

    # Make the directories
    www-data mkdir -p -m 0755 ~www-data/.ssh /etc/wordpress/.ssh
    sudo chown www-data /etc/wordpress/.ssh
    # Create the known hosts fi
    sudo ssh-keyscan -c "localhost > ~www-data/.ssh/known_hosts"
    sudo chmod 444 ~www-data/.ssh/known_hosts
    # Generate the key file 
    sudo -u www-data ssh-keygen -b 4096 -f /etc/wordpress/.ssh/id_rsa -N changeme
    # Secure the directories
    sudo chown root:www-data /etc/wordpress/.ssh ~www-data/.ssh
    # Authorize the key - with restricted access
    echo -n 'from="127.0.0.1,::1",restrict,pty ' >> ~/.ssh/authorized_keys
    sudo cat /etc/wordpress/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
    # Test the configuration - should be prompted for the key's password.
    sudo -u www-data ssh -i /etc/wordpress/.ssh/id_rsa $(logname)@localhost

    I hope this is useful for you. As always, please change the password used above.

    My original installation used a key without a password. At the time sftp access was not stable. I have not yet done an upgrade with a password on the key.

  • 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 starts them as a non-root user. It also allows the scripts to be run by members of an administration group via sudo. This approach is applicable to other applications. (more…)

  • Geo blocking with tcpwrappers

    i recently had an issue with frequent login attempts against on of my services. These were almost all from countries that should not be accessing my service. To resolve the issue I implemented geo blocking with TCP Wrappers. This is how I went about geo blocking connections. (more…)

  • Shell Scriptlets

    This post will be continually developed. I recently designed some solutions to solve some issues with init.d and setup scripts. These may be of use to others, and I will likely reuse them. (more…)

  • Securing TLS

    A StackExchange question on using HAProxy’s capture feature to pass data from TCP mode to HTTP mode prompted me to update my SSL configuration. This was intended to get an A+ rating from SSL Labs by sending non-SNI capable clients to a server with weaker ciphers. This was to enable clients on WinXP/IE8, Java 6, and an old Android version to connect. I found a solution without having to have two sets of ciphers and handling traffic in both the TCP mode and HTTP mode. I then optimized my settings to a minimal list of cipher specifications.
    (more…)

  • WordPress Tuning

    I’ve done a little tuning to my WordPress setup. In order to keep up to date, I’ve switched from the Ubuntu installation to a downloaded installation under /opt/wordpress. This is owned by my user and served by apache running as www-data. Updates are done using the sftp add-on.

    Securing /opt/wordpress

    I added myself to the www-data group. This allow apache to read any files with group access, but prevents writing if the web-server is compromised.

    I set the group sticky bit on all the directories. If required, setting it on the wp-content/upgrade directory should be sufficient.

    SSH Key

    I generated my key outside the home directory for www-data which is /var/www. The directory I chose is not one I would publish. However, ssh requires a .ssh/known_hosts file in its home directory. This was created and the appropriate security added. The key is password protected.

    Outstanding Issues

    There are some outstanding issues. I’ll look into these as time permits.

    Native ssh

    The WordPress ssh2 modules does not work on my server. I’ve found a couple of issues.

    • Passwords on the key don’t work. This is a known issue with a work-around. The initial connection appears to fail, but a second call should resolve the issue.
    • The is_dir function does not work. Returning true for paths that end in a slash (/) is a workaround. This got me as far as trying to install. This may be a result of how the path is constructed and there is a published workaround.
    • The is_file function appear to fail as WordPress reports the download contains no files. This is likely the same issue as for the is_dir function.

    Theme upgrades

    My modifications to the theme are getting a little old. The theme works reasonably well on mobile devices, but I would like to update to a more streamlined theme. The site statistics I have indicate a surprisingly high percentage of viewers use a mobile device.

  • Tuning Linux CPU Performance

    A recent kernel change broke my CPU performance tuning. I have an AMD processor which presents 4 cores to the kernel. The process in this article should work for Intel processors although the governors and CPU settings tree may be different. Different kernels may also have different settings. The current kernel allows setting the governor per CPU, but for an earlier kernel the setting was global.

    My system is mostly idle, and I want it to be as quiet as possible. However, from time to time it is busy and I want processing to be as fast as possible. I use a small block of shell code to select a governor and ignore niced programs (such as boinc) in selecting processor speed. (more…)

  • Adding SHA-2 to tinyca

    Google has announced a sunset for SHA-1 certificate signatures in Chrome. SHA-2 (aka SHA-256, SHA-384, and SHA-512) is the remaining option for certificate signatures. I decided to upgrade my certificates to SHA-2 (256 bits). However, when I tried to use tinyca2 to generate a SHA-2 certificate, I found it was not supported.

    As tinyca2 is a Perl package, I looked at the code to see how difficult it would be to update. The code is easy to read and well modularized. Adding the SHA-2 involves changes to the GUI, REQ, CERT, and OpenSSL components. I updated six files, although support can be added with fewer.

    Patches are attached at the end of this post.  An additional patch to apply the selected digest when creating sub-CAs (thanks to Cédric Dufour) has been included.
    (more…)

  • Disabling SSLv3 to block Poodle

    The new Poodle vulnerability lead me to disable SSLv3 on my Ubuntu server. I have TLS/SSL enabled on three services: apache2, exim4, and dovecot2. Each service required a different method to disable SSLv3.

    Ubuntu uses configuration files split into small pieces. The method should apply to other distributions, although the configuration files may be arranged differently. (more…)