Sunday, July 17, 2016

Mapping PPP lines to their configuartion

I had an interesting use-case of PPP in my prevision job. We used to have multiple PPP interfaces configured on our Linux(CentOS) servers each connecting to a DSL line. In some cases the PPP configuration of all the interfaces were the same, which was easy to manage. However, In most cases we had PPP configuration different for each interface. This was because we used DSL’s from multiple ISP’s and so on. I won’t go into why we were using multiple ISP’s here.
Add to this we also need to bounce interfaces at certain interval. Also some interfaces will go down due ISP issues.

The problem was how to track the line down to the specific ISP DSL account(in /etc/sysconfig/network-scripts/ifcfg-pppNUM) and open a case with them. Since Linux did dynamic network interface naming the PPP interfaces will take the lowest possible interface number. One way to track the interfaces that were having issues was to shut all the lines and bring one-by-one up and down checking the connectivity.

On searching a lot about this. I found a better way to track it.

The PID file /var/run/ppp-ppp”CURRENT_NUM”.pid where CURRENT_NUM is the PPP interface number currently, always contains a pointer to the original configuration file (/etc/sysconfig/network-scripts/ifcfg-pppNUM).

Also wrote a script to map current interface number to original configuration showing the interfaces that are down.

PPP Mapping Script

Total_PPP=$(ls /etc/sysconfig/network-scripts/ifcfg-ppp* |wc -l)
echo -e “PPP orig. config(ifcfg-pppN)  -> current PPP interface\tIPAddr”
for num in $(seq 0 $((Total_PPP-1)) )
if [ -f /var/run/ppp-ppp”$num”.pid ]
current_ino=$(sed -n ‘2p’ /var/run/ppp-ppp”$num”.pid)
IPAddr=$(/sbin/ifconfig “$current_ino” |awk ‘/inet/ { print $2}’|cut -d: -f2)
echo -e “$num -> $current_ino\t$IPAddr”
echo “$num -> DOWN”

References :

Monday, June 3, 2013

Securing Linux servers

One of the first thing to do on newly built server before deploying the applications and moving the data is to secure the server. Following have been the steps I have been doing to harden our production servers which are mostly RedHat linux. 

This is by no means a comprehensive list. I plan to update it with more stuff as we go on.

Remove unnecessary packages

Since our servers are deployed by data-center, we don't get the option to customize the packages installed. So we remove all packages that are unnecessary to us like X-Windows, Cups, FTP etc. We host a web-based application and don't need GUI or Printer support for our server. We use SFTP/SCP instead of FTP and I would suggest the same as they are more secure.

We can remove the X Window's and related dependencies using the following command.

yum groupremove "X Window System"

You can get the list of all the RPM's installed to a file using following. Go through each on list and remove what is not required.

rpm -qa >/tmp/rpms-installed.txt

rpm -e <Paackage to be removed>

Password policy and Account lockout for shell users

We can then set password policy for the shell users. We can set password ageing and length in /etc/login.defs.

PASS_MAX_DAYS 90    -  Password expires in 90 days.
PASS_MIN_DAYS 1   - Minimum  days required between password changes.
PASS_MIN_LEN    8  -  Minimum length password set as 8.
PASS_WARN_AGE 7 - Password expiration warning are issued 7 days before.

Another step is securing shell accounts is configuring pam_cracklib and pam_tally.
pam_cracklib -  Ensures that the passwords are reasonably strong.
pam_tally - For account lockout.

We can append pam_cracklib settings to /etc/pam.d/system-auth file as given below.

password required retry=3 minlen=8 difok=3

This ensures the following:
  • 3 retries allowed for password change.
  • Length of password should be 8.
  • Number of characters that must be different from the previous password should 3.
Add the following to auth section of /etc/pam.d/system-auth file.

auth    required onerr=fail per_user deny=3 unlock_time=600

This ensures that the account is locked out after 3 wrong password attempts and unlocks only after 10 minutes. 
You can view the password attempts by all users using the following command.


To unlock a particular user use the follwing command.

faillog -r -u <username>

Securing SSH

1. Disable root login
Open the /etc/ssh/sshd_config and look for PermitRootLogin. Set it as following.

PermitRootLogin no

2. Allow access only to required shell users.
AllowUsers max payne
This ensures that only max and payne has SSH access to the server.

3. Chroot the directory of SFTP users.
If not chrooted the users with SFTP access can view other directories like /etc and download the files.
We will first disable the shell access to the SFTP user.

usermod -d /sftphome/sftp_user -s /sbin/nologin sftp_user

We will then edit SSHD config file /etc/ssh/sshd_config. Look for the line "Subsystem      sftp    /usr/libexec/openssh/sftp-server" comment it and add the following "Subsystem       sftp    internal-sftp".  The SSHD config should be as below.

#Subsystem      sftp    /usr/libexec/openssh/sftp-server
Subsystem       sftp    internal-sftp

Now add the following.

Match User sftp_user
        ChrootDirectory /sftphome/%u
        ForceCommand internal-sftp

After all the changes are made in sshd_config restart SSH service.

Make sure that the /sftphome/sftp_user is owned by root user with permission of 755. The folders within /sftphome/sftp_user should be owned by sftp_user.


TCP Wrapper are another useful security feature. We can all the services to accessible only from our required IP ranges using. One of the service we can protect is SSH, since only few people from our office network will need to access it. We also add our VPN address along with office IP address for access from outside office.

The configuartion files are /etc/host.allow and /etc/hosts.deny.
Edit /etc/hosts.deny and add in following format.

sshd : ALL

Then add the IP addresses for which you need the service available to /etc/host.allow.

sshd: 10.

This will make SSHD available only to and the whole 10. range of IP's.


I am not going into IPTABLES rules here. It's recommended to set the default policy for all the chains to DROP and open only the services that need to exposed.

iptables -A INPUT -j DROP
iptables -A OUTPUT -j DROP
iptables -A FORWARD -j DROP

Friday, December 9, 2011

OpenLDAP with ppolicy

Overlays are dynamically configurable modules that provide additional functionality to OpenLDAP. The ppolicy overlay provides some useful functionalities for enforcing a password policy for the domain.

Our requirement was the following
  •  Account should be locked out after 5 failed authentication attempts.
  •  Password expiration on 90 days
  •  Minimum password length of 8
All our Ubuntu desktop's were authenticating the OpenLDAP server( which was setup on a CentOS box. We were able to achieve the 90 day password expiration using the default shadowAccount objectClass as given below.

# user1, People,
dn: uid=user1,ou=People,dc=example,dc=in
uid: user1
cn: user1
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword:: e2NyeXB0fSQxJEMzOxxxxxxxxxx
shadowLastChange: 15299
shadowMax: 90
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 630
gidNumber: 1005
homeDirectory: /data/user1

But we couldn't find any way to implement the password expirartion and password length polcies using the default OpenLDAP configuration. So I started my experiment's with ppolicy overlays. The ppolicy overlays provides enhanced password management capabilities that are applied to non-rootdn bind attempts in OpenLDAP.

The password policy(ppolicy) and other overlays are included in the package openldap-servers-overlays for Redhat/Centos servers. So we nee first install this package assuming openldap server and dependencies are already installed..
yum install openldap-servers-overlays
The ppolicy module file should get installed at /usr/lib64/openldap/ and schema file at /etc/openldap/schema/ppolicy.schema  on a 64 bit CentOS/Redhat server. The module file should be in /usr/lib/openldap directory on an x86 server.

Server Configuartion
We need to configure the ppolicy overlays now. Add the following lines to /etc/openldap/slapd.conf in the respective sections.

include /etc/openldap/schema/ppolicy.schema

modulepath /usr/lib64/openldap

This is assuming that ppolicy overlay files are in respective locations. The ACL's should be set such that clients bind to OpenLDAP server by self-authentication. We should not allow anonymous or rootdn binds to the server. The default configuration is to allow anonymous binds to server. So I added ACL as given below in the ACL section of slapd.conf.

access to attrs=userPassword
by self =xw
by anonymous auth
by * none

access to *
by self write
by * read

Next we need to add default password policy we are going to enforce on the domain. Add the following after the DB section in slapd.conf.

overlay ppolicy
ppolicy_default "cn=default,ou=policies,dc=example,dc=in"

This should complete the configuration of slapd.conf . You should be able to restart the LDAP server without any issues now.

Importing the password policy

Create a LDIF file with following content.

cat password-policy.ldif

dn: ou=policies,dc=example,dc=in
ou: policies
objectClass: top
objectClass: organizationalUnit

# default, policies,
dn: cn=default,ou=policies,dc=example,dc=in
objectClass: top
objectClass: device
objectClass: pwdPolicy
cn: default
pwdAttribute: userPassword
pwdMaxAge: 7776002
pwdExpireWarning: 432000
pwdInHistory: 3
pwdCheckQuality: 1
pwdMinLength: 8
pwdMaxFailure: 5
pwdLockout: TRUE
pwdLockoutDuration: 900
pwdGraceAuthNLimit: 0
pwdFailureCountInterval: 0
pwdMustChange: TRUE
pwdAllowUserChange: TRUE
pwdSafeModify: FALSE

This sets the following policies
  •  password expiration at 90 days
  •  password lockout on 5 failures and lockout duration of 15 mintues
  •  minimum password length of 8
  • 3 earlier password in history

To import the policy run the following command.

ldapadd  -D "cn=Manager,dc=example,dc=in" -W -x  -f password-policy.ldif

This ldapadd command should add to policy on authentication as LDAP administratorWe should be able to see the newly imported policy now when we do a ldapsearch.

 ldapsearch  -x -D "cn=Manager,dc=example,dc=in" -W -b "dc=example,dc=in"

This completes the server configuration. 

Client Side Configuartion
On the LDAP clients in my case Ubuntu desktops we need make the following change in LDAP client configuration file /etc/ldap.conf assuming the client was configured to authenticate to our LDAP server before. Uncomment the pam_lookup_policy line which should be already there in /etc/ldap.conf

pam_lookup_policy yes

Yes !! Now the password policy should be enforced for all non-rootdn authentication attempts !


OpenLDAP server Backup & Restore


To backup the entire LDAP database we can make use of the command slapcat. The slapcat command genetates a LDIF (LDAP Directory Interchange Format) file contianing the dump of entire LDAP database.

slapcat -v -l ldap-backup.ldif

The above command generates a backup file named ldap-backup.ldif in the current directory.

Without the -l option slapcat writes the content to standard output.

The slapcat command reads the ldap configuration file at the default location (/etc/openldap/slapd.conf) and takes the database dump. We can provide a LDAP configuartion file at a different location using -f option as given below.

slapcat -v -f /etc/openldap/slapd.conf -l ldap-backup.ldif


To restore the database from the earlier backup LDIF file we can use slapadd command.

slapadd -l ldap-backup.ldif 

In case files already exist in the LDAP database location we have to clear them before restoring using slapadd while retaining the DB_CONFIG file. The sample DB_CONFIG file should be in /etc/openldap/DB_CONFIG.example.

rm -fr /var/lib/ldap/*

Once the files are cleared you should be able to restore the database using slapadd given above. 

On successful completion of the restoration  restart the LDAP server.

service ldap restart