Chris Paquin

AI, Virtualization, Containers, Infrastructure, Linux

Category: Linux

  • RHEL6 – Simple Crontab Access Control

    12161376021593473697lemmling_Cartoon_goat.svg.medWhile I am in the process of documenting each and every possible method of blocking or allowing a local user or remote user access from a service, I figured that I might as well drop a small little post out there on the subject of cron.allow and cron.deny.  First off you should know that allowing and blocking access to cron is very, very easy as you only need to know two files and there is not a special

    Basically you are working with two files, the /etc/cron.allow and /etc/cron.deny.

    Users are allowed to run cronjobs if:

    • if the user’s name appears in /etc/cron.d/cron.allow.
    • if  /etc/cron/cron.allow does not exist and the user’s name is not in /etc/cron/cron.deny.

    Users are blocked from running cronjobs if:

    • /etc/cron/cron.allow exists and the user’s name is not in it.
    • /etc/cron/cron.allow does not exist and user’s name is in /etc/cron/cron.deny.

    Note that the rules for allow and deny apply to root only if the allow/deny files exist.

    Below is what a blocked user will see if they try to create a crontab entry

    $ crontab -l
    You (fatmin( are not allowed to use this program (crontab)
    See crontab(1) for more information

  • RHEL6 – More Vsftp Configuration Items

    1216139760278927551lemmling_Cartoon_cow.svg.medSo almost a year ago, I put up a post on how to configure an Anonymous FTP Server using vsftp on RHEL6. You can read that post here. Anyway, that post is pretty much just a quick and dirty step-by-step of how to get vsftp up and running on RHEL6. Well today's post is a follow-up to that original post, however now we are going a bit deeper into the vsftpd.conf and some of the additional settings that are worth noting. Without further ado lets get down to business.

    • Anonymous_enable — When enabled, anonymous users are allowed to log in. The usernames anonymous and ftp are accepted.
    • Download_enable — When enabled, file downloads are permitted. The default value is YES.
    • Write_enable=When set to yes, ftp writes are allowed. When disabled no one can write to ftp at all.
    • Anon_upload_enable=When enabled, file uploads are enabled, but only if write_enable is set to yes as well.
    • Local_enable — When enabled, local users are allowed to log into the system. The default value is yes. Change to no to disable vsftp logins for your local users. Useful when running an anonymous ftp server.
    • Userlist_file — Specifies the file referenced by vsftpd when the userlist_enable directive is enabled. The default value is /etc/vsftpd.user_list and is created during installation.
    • /etc/vsftpd.ftpusers – Local users listed in this file are allowed access to when referenced by the directive userlist_file.
    • /etc/vsftpd.user_list – Local users in this file are denied access to ftp
    • Chroot_list_enable — When enabled, the local users listed in the file specified in the chroot_list_file directive are placed in a chroot jail upon log in.
    • Chroot_list_file — Specifies the file containing a list of local users referenced when the chroot_list_enable directive is set to YES. The default value is /etc/vsftpd.chroot_list.
    • Chroot_local_user — When enabled, local users are change-rooted to their home directories after logging in. The default value is NO.
    • Tcp_wrappers=when set to Yes, it enabled tcpwrapper support

     

     

     

     

  • A Simple Introduction to TCP Wrappers

    0993fb024232491eIn the world of Linux there are numerous ways that you can configure a Linux server to allow or deny access to a service, and while many people like to rely solely on Iptables, I wanted to take the opportunity to get my feet wet with TCP Wrappers. Note that this post is not meant to be the be-all end-all post on tcp wrappers. I am not going to review each and every configuration option, and trust me there are quite a few. Rather this is going to be a simple post which explains how to use tcp wrappers.

    TCP Wrappers Configuration Files

    First off you need to know that there are two configuration files for TCP wrappers. They are listed below.

    #/etc/hosts.allow

    #/etc/hosts.deny

    To determine if a remote host is allowed to access a local service, the hosts.allow file referenced first, then the hosts.deny is referenced. Each file is read from the top down.

    Rules in the hosts.allow take precedence over rules in the hosts.deny. Access will be granted for rules in the /etc/hosts.allow, and denied for rules in the /etc/hosts.deny ( note that this is not always the case, however this is how most people use tcpwrappers)

    Basic rules are configured using the format below

    <daemon list> : <client list> [: <option> : <option> ]

    Below is a very simple and basic rule for sshd. In this example we want to allow all hosts in the domain fatmin.com to have access to sshd, and we want to deny sshd access to everyone else.

    So in the /etc/hosts.allow

    sshd : *.fatmin.com

    and in /etc/hosts.deny

    sshd: ALL

    Creating Rule Matching Patterns

    Ok, so what I have shown you above is a very simple example using a very simple matching rule, however there are actually quite a few ways to format a rule lets review a few of the more common ones that you might see.

    Match by Hostname – All hosts below in the domain fatmin.com matched. Vsftpd is specified service

    vsftpd: .fatmin.com

    Match by IP address – All hosts in 192.168.x.x are matched. Vsftpd is specified service

    vsftpd: 192.168.

    Match by IP/Subnet – All hosts in 192.168.0.0/24 are matched. Vsftpd is specified service

    vsftpd: 192.168.0.0/255.255.255.0

    Match All – All Services and Hosts are matched.

    ALL : ALL

    What Services Use TCP Wrappers

    Initially TCP Wrapper only “wrapped” services that were configured as part of inet.d, or xinet.d, but over time more and more processes have been configured to use librap.so. The example below shows how see if a daemon used libwrap, and can therefore be allowed or blocked via tcpwrappers.

    Below we are locating the sshd binary and seeing if it uses libwrap. Which is does.

    # whereis sshd

    # ldd /usr/sbin/sshd | grep wrap
    libwrap.so.0 => /lib64/libwrap.so.0 (0x00007f03f005d000)

    Below we are locating the smbd binary and seeing if it uses libwrap. Which is does not.

    # whereis smbd

    # ldd /usr/sbin/smbd | grep wrap

    Instead of checking one service at a time you can run the command below. Note that if a service is not installed, it will not show up

    # strings -f /usr/sbin/* |grep hosts_access
    /usr/sbin/rpc.mountd: hosts_access
    /usr/sbin/sshd: hosts_access
    /usr/sbin/tcpd: hosts_access_verbose
    /usr/sbin/tcpdmatch: hosts_access_verbose
    /usr/sbin/vsftpd: hosts_access
    /usr/sbin/xinetd: hosts_access

    Note that httpd, samba (smb) and nfs are not configured by default to use tcpwrappers (however it can be done but that is outside the scope of this post)

    Configuration Examples

    Below are are few more configuration examples that might be useful for reference.

    Allow tftpd access from fatmin, and block everyone else.

    #/etc/hosts.allow

    in.tftpd : .fatmin.com

    #/etc/hosts.deny

    in.tftpd : .ALL

    Allow SSH access from fatmin.com, but block from example.com. Also send log to sshd.log

    #/etc/hosts.allow

    sshd: .fatmin.com

    #/etc/hosts.deny

    sshd : .example.com  \
    : spawn /bin/echo `/bin/date` access denied>>/var/log/sshd.log \
    : deny

    Block tfpd access for all of fatmin.com except for server1.fatmin.com. Note that there is no corresponding hosts.allow entry needed.

    #/etc/hosts.deny

    tftpd .fatmin.com EXCEPT server1.fatmin.com

  • RHEL6 – Configuring Apache with TLS/SSL Encryption

    Henery-Hawk-iconDon’t let the acronyms and the word “Encryption” scare you, its actually very easy to enable TLS/SSL in Apache. So basically it sounds more complicated than it is — like these last two sentences for example.

    First you should probably know what TLS and SSL are. Well according to Wikipedia …”Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols that provide communication security over the internet”

    I am going to assume here that you have already installed and started Apache, I will also assume that you have SELinux configured properly, as well as IPTables.

    So next step is to install mod_ssl

    # yum -y install mod_ssl

    Once install a new config file, called ssl.conf will be installed in /var/www/html/conf.d. Inside that file are a couple of configuration items that you need to be aware of.

    # Point SSLCertificateFile at a PEM encoded certificate.  If
    SSLCertificateFile /etc/pki/tls/certs/localhost.crt
    SSLCertificateKeyFile /etc/pki/tls/private/localhost.key

    If you are replacing the test cert with a signed one you will need to drop it in /etc/pki/tls/certs and modify the lines in the section above to point to your new cert and your new key file.

    Now restart apache.

  • RHEL6 – Common Postfix Server Roles

    10736157-a-cartoon-rabbit-with-an-angry-expressionIf you are anything like me you would rather not have anything to do with Sendmail or Postfix, however unfortunately it can be required learning in some circles. That being said this is my second postfix post in what I call my “Postfix: Nasty!” series. The first one can be read here, and  I will be the first to admit that its not very good. However I chock this up to the fact that I really don’t know much about Postfix at all and I’m writing these posts as part of the process of figuring out how to do what with Postfix.

    Specifically this post outlines and defines the standard roles that a postfix server can serve. Below are three common roles and their characteristics. You should get to know each of these and how to configure them.

    Null Client:

    • Only runs Postfix as a local MTA (mail transfer agent… think sendmail and postfix) for the purpose of forwarding to a centralized mail server
    • Does not accept local delivery

    Inbound-Only Mail Server:

    • Handles all inbound mail for a site
    • Passes inbound email to an MDA (mail delivery agent) such as Dovecot or Procmail
    • Forwards outbound mail to a centralized mail server, just like a Null Client Does

    Outbound Mail Relay:

    • Also called a Smarthost
    • Accepts outbound messages
    • Should be configured to forward mail for authorized clients only. Avoid being an Open Relay

  • RHEL6 – Using Semanage and Restorecon to Modify SELinux File Contexts

    Potty TrainingOk, how to keep this simple? Lets see…

    Semanage:

    Ok, semanage, when used with the fcontext argument, is used to define SELinux file contexts for file. It basically adds the new definition to the file,  /etc/selinux/targeted/contexts/files/file_contexts.

    For example lets say that I create a new file called /root/foobar.

    Using the command below I can see the default context that is assigned to a file created in /root

    # ls -lZ foobar
    -rw-r–r–. root root unconfined_u:object_r:admin_home_t:s0 foobar

    Now lets say that I want to change the context of this file to public_content_t.  The first step to accomplish this is to define its new context.

    # semanage fcontext -a -t public_content_t /root/foobar

    Restorecon:

    Now that the context type is defined we need to actually modify the current context of our file. So now you run restorecon against the file to actually make the change. Note: use -v for verbose.

    # restorecon -v /root/foobar

    restorecon reset /root/foobar context unconfined_u:object_r:admin_home_t:s0->unconfined_u:object_r:public_content_t:s0

    Chcon:

    There is also a command called chcon, that can also be used to change the defined context for a file. However I advise against using it as changes made using chcon will not survive a filesystem relabel. What is a filesystem relabel? Well according to wiki.centos.org, a relabel is defined below.

    “Sometimes it is necessary to relabel the complete filesystem although this should only be necessary when enabling SELinux after it has been disabled or when changing the SELinux policy from the default targeted policy to strict.”

     

  • Broadcom (bnx2) Network Adapters Dropping Recieved Packets Under Linux

    VampSo a few weeks ago some of our Centos 5.4 and OEL 5.5 servers started exibiting strange connectivity problems. Monitoring started alerting that hosts were down when they weren't; some boxes could ping target hosts and some couldn't; some boxes became unresponsive when interfaces were failed over, and the strangest of all is that some of the boxes would magically "repair" themselves. Like I said, strange.

    Over the next week or so we ran into the issue a few more times and were able to see a pattern emerge. All the affected servers were running Centos 5.4 or Oracle Linux 5.5 and had broadcom (bnx2) adapters that were on the recieving end of some pretty decent traffic. Most importantly, all had a good number of dropped recieved packets that was continuously, albeit slowly, increasing.

    A bit of google research led us to this bugzilla, which suggested changing the adapter's coalescense settings…. so a bit on coalescense.

    Coalescense

    In your network adapter, coalescence is all about interupts. Traditionally interupt coalescense (or IC) is used to reduce the number of interupts generated by the system by delaying the generating of an interrupt by a very short period of time…think less then a milisecond. In turn more traffic will be recieved by the host and the next interupt generated will be larger in size. You can find out more than you would ever want to know about coalesence here

    The Fix

    So apparently the Broadcom IC settings were not aggressive enough. Packets would come in, fill up the receive queue, and get dropped before they could be sent off for processing via an interrupt. This takes us back to the bugzilla above and the suggested settings below which you set with the ethtool command

     ethtool -C ethX rx-usecs 8 rx-usecs-irq 8 rx-frames 0 rx-frames-irq 0

    Note that this was not an issue on any in Centos 5.6, any server with Intel adapters, or any server with 10g adapters. As a matter of fact, those servers had IC settings even more agressive then those above. See the Intel 82599EB 10-gigabit settings below

    rx-usecs: 1
    rx-frames: 0
    rx-usecs-irq: 0
    rx-frames-irq: 0

    Final Configuration

    So now that we know the fix we need to make it permanent, which is not as easy as editing a config file for the device as the coalescence config is set at boot and it part of the installed driver for the device. Rather than muck around with trying to modify the driver itself, we decided to set and configure our devices at boottime with a rc script that checks the checks the each network interface on the box and modifys their IC settings if they are using the bnx2 (Broadcom) driver.  We dropped the script below into /etc/rc.d and created a symbolic link to it in /etc/rc3.d.

    #!/bin/bash

    case "$1" in
    start)

    IFACE=$(ls /etc/sysconfig/network-scripts/ifcfg-eth*| grep -v bak | cut -d – -f 3)

    for ETH in $IFACE
            do
                    if ( ethtool -i $ETH | grep -qw bnx2 )
                    then
                            echo "$Changing Settings for $ETH"
                            ethtool -C $ETH rx-usecs 8 rx-usecs-irq 8 rx-frames 0 rx-frames-irq 0
                    else
                            echo "$ETH is not a broadcom"

                    fi
            done
    exit 1
    ;;

    stop)

    echo " hammer time"
    ;;

    *)
        echo "usage: $0 (start|stop)"
    ;;
    esac