RHEL 7 Two-Factor SSH Via Google Authenticator

650x300xgoogle-authenticator-header.png.pagespeed.gp+jp+jw+pj+js+rj+rp+rw+ri+cp+md.ic.194erIegOZ.jpg

In this post,  I am going to walk you through the process of installing and configuring two- factor SSH authentication via Google Authenticator. My base system is running a fresh install of RHEL 7.2

Installation Steps

The first step on my system was to install autoreconf, automake, and libtool. These packages are required by the bootstrap.sh script that we will need to in a couple more steps.

# yum -y install autoconf automake libtool

Now, we are going to install Git.

#yum -y install git

One more dependency to knock out. Install pam-devel as shown below.

# yum -y install pam-devel

Next, we clone the google-authenticator Git repo. In this example, I am cloning to /root

# git clone https://github.com/google/google-authenticator.git
Cloning into ‘google-authenticator’…
remote: Counting objects: 1435, done.
remote: Total 1435 (delta 0), reused 0 (delta 0), pack-reused 1435
Receiving objects: 100% (1435/1435), 2.32 MiB | 0 bytes/s, done.
Resolving deltas: 100% (758/758), done.

Now change directory as shown below and run bootstrap.sh.

# cd /root/google-authenticator/libpam

# ./bootstrap.sh

Now run the following commands to finalize the module installs.

# ./configure

#make

#make install

Assuming that you do not run into any errors, the following modules will be installed.

  • /usr/local/lib/security/pam_google_authenticator.so
  • /usr/local/lib/security/pam_google_authenticator.la

Continue reading

Advertisements

Fedora21 – Quick and Dirty with Firewalld

firewall

Hey, are you new to Firewalld like most of us?

Unless you have been using Firewalld in the last few releases of Fedora, as some out there have, then you probably could probably use a few pointers to get you started on your way to configuring your Linux firewalls the “new-fangled fancy way”. This is especially the case if you plan on moving to RHEL7 anytime soon — as Firewalld is the default there. So put on your big boy (or girl) pants and say goodbye to your old friend IPTABLES.

According to this page. Firewalld is…

“The dynamic firewall daemon

1
firewalld

provides a dynamically managed firewall with support for network zones to assign a level of trust to a network and its associated connections and interfaces. It has support for

1
IPv4

and

1
IPv6

firewall settings. It supports Ethernet bridges and has a separation of runtime and permanent configuration options. It also has an interface for services or applications to add firewall rules directly”

Wow, how fancy. So how do we use it? Well let’s take a stab at enabling HTTP access to our Fedora21 workstation.

First thing first, lets figure out what our default done is on our workstation.

$ sudo firewall-cmd –get-default-zone
FedoraWorkstation

Ok, thats a bit strange, in RHEL you should expect PUBLIC to be your default zone.  Now that we know what zone we need to mess with let’s make sure that its applied to the proper interfaces.

$ sudo firewall-cmd –get-active-zone
FedoraWorkstation
interfaces: enp4s0 enp5s4 macvtap0 tun0 virbr0

The first two interfaces above are our physical interfaces, so we are good here. Now lets apply the rule, and make sure its permanent.

$ sudo firewall-cmd –permanent –zone=FedoraWorkstation –add-service http
success

Now lets check our rules. Note HTTP is missing.

$ sudo firewall-cmd –list-services
dhcpv6-client mdns samba-client ssh

Since we have only applied this new rule to our permanent config and not to our running config, we need to restart firewalld to see the updated rule.

 $ sudo firewall-cmd –reload

Now your can view the updated rules…

$ sudo firewall-cmd –list-services
dhcpv6-client http mdns samba-client ssh

RHEL6 – Getting Up Close and Personal With Rsyslog

LogRsyslog has replaced Syslog as the default logging daemon in RHEL6. Rsyslog was designed to complete with syslog-ng and has several enhancements over plain old syslog. This includes but is not limited to more granularity with timestamps, direct database logging,   TCP support, and  relay server names in host fields which makes it easier to track the path a message has taken.

Below we are going to take a look at a few simple rsyslog configuration items.

Configure Rsyslog to Accept Remote Logs.

Within /etc/rsyslog.conf, comment out either the TCP or UDP syslog reception lines below. TCP is more reliable, however UDP is more widely supported.

# Provides UDP syslog reception
#$ModLoad imudp.so
#$UDPServerRun 514

# Provides TCP syslog reception
#$ModLoad imtcp.so
#$InputTCPServerRun 514

Configure a Server to Send Logs to a Remote Host.

To send all messages of info priority or higher to a remote host via udp, use the following format. Note that 10.1.224.34 is the remote server that I want to send logs to.

*.info    @10.1.224.34

To send the same priorities to the remote host via TCP, use two "@@"

*.info    @@10.1.224.34

Note that you can specify the port number on which to send by using IP:PORT. When no port is specified the default port of 514 is used.

Note that depending on your configuration you may need to alter your IPtables configuration on your sending and/or receiving server. In my case I needed to allow UDP on port 514 on my remote syslog server. To accomplish this I used system-config-firewall-tui which added the following line to /etc/sysconfig/iptables.

-A INPUT -m state –state NEW -m udp -p udp –dport 514 -j ACCEPT

Which shows up as what you see below in the output of 'iptables -L'

ACCEPT     udp  –  anywhere             anywhere            state NEW udp dpt:syslog

Testing Your Configuration

Ok lets send a test to our remote syslog server. Note that rsyslog has been restarted on both hosts.

# logger "testing to remote rsyslog server"

Checking the messages file on the remote host we can see that the test message has arrived.

Aug 13 14:55:26 vfatmin02 root: testing to remote rsyslog server

 

RHEL6 – How to Setup an Anonymous FTP Server


tow-truck-driver-cartoon-character-final-coghillToday on the fatmin we are going to setup an ftp server on RHEL6 that accepts anonymous uploads. We are going to do so with SELinux support and will be making modifications to iptables as well. Sounds fun, right?

Installation:

First and formost we need to install vsftpd

# yum -y install vsftpd && service vsftpd start && chkconfig vsftpd on

Our anonymous upload directory will be /var/ftp/anon, and we need to change group ownership to the ftp group and then change permissions so that the members of that group can write to it. Note that no one other than root can read or execute anything under /var/ftp/anon.

# chgrp ftp /var/ftp/anon
# chmod 730 /var/ftp/anon
# ls -ld /var/ftp/anon
drwx-wx—. 3 root ftp 4096 Oct 19 13:34 /v1

SELinux Support:

Next we need to configure SELinux support and assign the correct context to the /v1 directory and its future contents. Note -a is add -t is type.

# semanage fcontext -a -t public_content_rw_t ‘/var/ftp/anon(/.*)’

Now lets go ahead and apply the new context. Note -vv is verbose, -F force and R is recursive

# restorecon -vvFR /var/ftp/anon

Now we need to get and set the allow_ftpd_anon_write boolean

# setsebool -P allow_ftpd_anon_write=1

Now lets check to make sure the setting “stuck”.

# getsebool -a | grep allow_ftpd_anon_write
allow_ftpd_anon_write –> on

Configure Vsftpd:

Now vi /etc/vsftpd/vsftpd.conf and ensure that the following configuration values are set and un-commented. Note that I had to add the last line to my config file.

anonymous_enable=YES

anon_upload_enable=YES

chown_uploads=YES

chown_username=daemon

anon_umask=077

Configure iptables:

Add the following to /etc/sysconfig/iptables-config. In my case I only needed to add the ip_nat_ftp part to the line

IPTABLES_MODULES=”nf_conntrack_ftp ip_nat_ftp”

Now you are going to want to make sure that these two lines exist in /etc/sysconfig/iptables.

-A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p tcp –dport 21 -j ACCEPT

Now restart iptables

Addendum:

Note that I ran into issues with the semanage command below.

# semanage fcontext -a -t public_content_rw_t ‘/var/ftp/anon(/.*)’

It seems that the context assigned to the /var/ftp/anon directory was not changing correctly from public_content_t to public_content_rw_t.

# ls -Zd /var/ftp
drwxrwxrwx. root root system_u:object_r:public_content_t:s0 /var/ftp

However when I checked the file_contexts file all looked correct.

# cat /etc/selinux/targeted/contexts/files/file_contexts.local/var/ftp/anon(/.*)    system_u:object_r:public_content_rw_t:s0

So I ran the chon command seen below and did not run the restorecon command. This worked as afterwards the context on the directory /var/ftp/anon was correct.

# chcon -R -t public_content_rw_t /var/ftp/anon

 

RHEL6 – Simple Iptables How To

Firewall supportYour mother and I were talking last night about how important it is to properly configure Iptables, and how despite that fact, many just choose to disable it. So today we are going to discuss iptables.

Overview:

By far the easiest way to setup a simple firewall using Iptables is to use system-config-firewall, or system-config-firewall-tui. I prefer this method as iptables can be a bit confusing on the command line and in its config file (/etc/sysconfig/iptables) is not exactly user friendly. At the very least you can create a basic set of rules and then customize by hand. Lets take a look at the file in its default form on my RHEL 6 box.

But before we do that, lets review a couple of terms that we need to know.

  1. INPUT – are inbound packets
  2. OUTPUT are outbound packets
  3. FORWARD – packets from another machine that the firewall should forward (like to a vm on the host).
  4. ACCEPT – the packet is accepted
  5. DROP – the packet is dropped as if it never existed
  6. REJECT – the packed is rejected and and error message is returned to sender
  7. RULE – the basic building block — tells the firewall what to do with a packet
  8. CHAIN – a list of all rules which will be checked in order from first to last
  9. POLICY – the default action, like accept, drip, reject, forward

Now that you have memorized the list above, here is my /etc/sysconfig/iptables.

# Firewall configuration written by system-config-firewall
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state –state NEW -m tcp -p tcp –dport 22 -j ACCEPT
-A INPUT -j REJECT –reject-with icmp-host-prohibited
-A FORWARD -j REJECT –reject-with icmp-host-prohibited.

Now lets run system-config-firewall tui and enable apache and ftp, plus we want to configure our box to respond to ICMP ping requests. This process is pretty self explanitory once you start.

Once that is done lets view /etc/sysconfig/iptables again.

# Firewall configuration written by system-config-firewall
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -m icmp –icmp-type echo-request -j REJECT –reject-with icmp-host-prohibited
-A INPUT -p icmp -m icmp –icmp-type echo-reply -j REJECT –reject-with icmp-host-prohibited
-A INPUT -p icmp -m icmp –icmp-type destination-unreachable -j REJECT –reject-with icmp-host-prohibited
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state –state NEW -m tcp -p tcp –dport 22 -j ACCEPT
-A INPUT -m state –state NEW -m tcp -p tcp –dport 80 -j ACCEPT
-A INPUT -m state –state NEW -m tcp -p tcp –dport 21 -j ACCEPT
-A INPUT -m state –state NEW -m tcp -p tcp –dport 443 -j ACCEPT
-A INPUT -j REJECT –reject-with icmp-host-prohibited
-A FORWARD -j REJECT –reject-with icmp-host-prohibited
COMMIT

Iptables Command:

The iptables command can be used in several different ways.

List the current rules in use, similar to viewing the /etc/sysconfig/iptables file

#iptables -L

To set a default policy use iptables -P, in the example below we are setting the default INPUT policy to DROP.

#iptables -P INPUT DROP

Now lets say we want to delete all our existing rules, note that i did not say policy

#iptables -F

To add a rule use iptables -a, for example lets say you have a default policy of INPUT DROP but we want to accept all established and related packets. Note that -m must be used when adding rules to a chain as it forces modprobe to load any necessary modules.

#iptables -A INPUT -m state –state ESTABLISHED, RELATED

Now lets say that we want to reject all packets from 192.168.10.10. Note -j specifies the action that the rule is to take — in the case below, REJECT

#iptables -A INPUT -s 192.168.10.10 -j REJECT

Now lets say we want to ACCEPT all ICMP traffic from our local subnet. The -p is protocol

#iptables -A INPUT -p ICMP -s 192.168.1.0/24 -j ACCEPT

Please note that under RHEL you can use following commands to save firewall rules.Make sure that you do this before you restart iptables.

#service iptables save

ESX Post Install – Enable NTP and SNMP

FirewallThis post is the first in what I suspect will be a semi-long list of post-install hints and tips as I go through and start rebuilding my cluster as Vsphere 4. Hopefully I will learn a lot along the way… like for example the fact the ntp and snmp traffic is not allowed by default by the ESX Firewall.

But before we go there we first need to make sure that our services are starting at boot.

>chkconfig ntp on, … do the same for snmp

Then lets fix the firewall. First lets fix ntp.

esxcfg-firewall -e ntpClient

Then lets verify that all is well with…

esxcfg-firewall -q ntpClient

This command returns…

Service ntpClient is enabled

Ok now lets fix snmp using the same commands above, but specific for snmp.

esxcfg-firewall -e snmp and esxcfg-firewall -q snmpd.

While you are at it add the following to you snmp.conf

dlmod SNMPESX /usr/lib/vmware/snmp/libSNMPESX.so

Then restart snmp and ntp and you should be good.