Posts Tagged ‘Security’

Intercepting proxies and spacewalk-repo-sync

Saturday, September 14th, 2013

More and more companies are using intercepting proxies to scan for malware. Those malware scanners can be problematic due to added latency.

If you using spacewalk-repo-sync to synchronize external yum repositories to your custom software channels and experience the famous message [Errno 256] No more mirrors to try in your log files, then you need to configure spacewalk-repo-sync.

Unfortunately the documentation for that is a bit hidden in the man page. You need to create a directory and create a file.

mkdir /etc/rhn/spacewalk-repo-sync/

Create the configuration item:

echo "[main]" >> /etc/rhn/spacewalk-repo-sync/yum.conf
echo timeout=300 >> /etc/rhn/spacewalk-repo-sync/yum.conf

You need to experiment a bit with the value of the timeout setting, 5min should be good enough for most environments.

/etc/rhn/spacewalk-repo-sync/yum.conf has the same options like yum.conf, have a look for more information in the man page.

Have fun :-)

Centrally manage sudoers rules with IPA Part I – Preparation

Thursday, July 25th, 2013

One of the features of IPA is its facility to centrally manage sudoers rules. This rules can be based on user, group memberships etc. and be constrained to one or more servers.

One of the benefits you get is: You are able to define stricter sudoers rules without annoying the users. At the end your systems are more secure and more convenient for the users.

Lets start.

Preparation
Unfortunately, sudoers via LDAP does not just work out of the box, some configuration on the clients needs to be done. Those can be equal on all hosts and distributed via configuration management such as puppet or RHN Satellite.

IPA has a user called “sudo”. We first need to set a password for it:

[root@ipa1 ~]# ldappasswd -x -S -W -h ipa1.example.com -ZZ -D "cn=Directory Manager" uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com
New password: 
Re-enter new password: 
Enter LDAP Password: 
[root@ipa1 ~]# 

We need to set this password later on as the bind password in the LDAP configuration.

Next we need to edit the /etc/nsswitch.conf file:

[root@ipaclient1 ~]# echo sudoers:  files ldap >> /etc/nsswitch.conf

Lets configure the sudoers-ldap file

root@ipaclient1 ~]# cat << EOF > /etc/sudo-ldap.conf
binddn uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com
bindpw redhat
ssl start_tls
tls_cacertfile /etc/ipa/ca.crt
tls_checkpeer yes
uri ldap://ipa1.example.com ldap://ipa2.example.com
sudoers_base ou=SUDOers,dc=example,dc=com
EOF
root@ipaclient1 ~]#

The bindpw (in this example “redhat” is that one you previously set with ldappasswd, change it accordingly. The paramter “uri” should contain two IPA servers (as FQDN, no IP Address or shortname) for redundancy. The “binddn” and “sudoers_base” of course should match your environment.

Remember netgroups? Old school stuff from the time when NIS was used. I thought I’ll never get in touch with NIS anymore. Unfortunately sudo uses netgroups, so we need to set a proper NIS domainname.

cat << EOF >> /etc/rc.d/rc.local
nisdomainname example.com
EOF

Summary
The following files are needed to be configured on each host using IPA for sudoers rules:

  • /etc/nsswitch.conf
  • /etc/sudo-ldap.conf
  • /etc/rc.d/rc.local

Expect part two of this in the next few days.

Have fun :-)

Host based access control with IPA

Saturday, March 2nd, 2013

Host based access control is easy with IPA/FreeIPA, very easy.

Lets assume you want to have a host group called rhel-prod, a usergroup called prod-admins and you want to let them access the servers in the rhel-prod group by ssh from any host that can reach the servers. Lets call the HBAC rule prod-admins.

You can either user the web GUI or use the command line interface.

Lets create the user group:

[root@ipa1 ~]# ipa group-add prod-admins --desc="Production System Admins"
-------------------------
Added group "prod-admins"
-------------------------
  Group name: prod-admins
  Description: Production System Admins
  GID: 1222000004
[root@ipa1 ~]# 

Add some users to the user group:

[root@ipa1 ~]# ipa group-add-member prod-admins --users=luc,htester
  Group name: prod-admins
  Description: Production System Admins
  GID: 1222000004
  Member users: luc, htester
-------------------------
Number of members added 2
-------------------------
[root@ipa1 ~]# 

And the hostgroup

[root@ipa1 ~]# ipa hostgroup-add rhel-prod --desc "Production Servers"
---------------------------
Added hostgroup "rhel-prod"
---------------------------
  Host-group: rhel-prod
  Description: Production Servers
[root@ipa1 ~]#

Add some servers as members of the host group

[root@ipa1 ~]# ipa hostgroup-add-member rhel-prod --hosts=ipaclient1.example.com,ipaclient2.example.com
  Host-group: rhel-prod
  Description: Production Servers
  Member hosts: ipaclient1.example.com, ipaclient2.example.com
-------------------------
Number of members added 2
-------------------------
[root@ipa1 ~]#

Note: the servers are comma separated, without a space after the comma

Lets define the HBAC rule:

[root@ipa1 ~]# ipa hbacrule-add --srchostcat=all prod-admins
-----------------------------
Added HBAC rule "prod-admins"
-----------------------------
  Rule name: prod-admins
  Source host category: all
  Enabled: TRUE
[root@ipa1 ~]#

Add the user group to the rule:

[root@ipa1 ~]# ipa hbacrule-add-user --groups prod-admins prod-admins
  Rule name: prod-admins
  Source host category: all
  Enabled: TRUE
  User Groups: prod-admins
-------------------------
Number of members added 1
-------------------------
[root@ipa1 ~]#

Add the service to the rule:

[root@ipa1 ~]# ipa hbacrule-add-service --hbacsvcs sshd prod-admins
  Rule name: prod-admins
  Source host category: all
  Enabled: TRUE
  User Groups: prod-admins
  Services: sshd
-------------------------
Number of members added 1
-------------------------
[root@ipa1 ~]#

And finally add the host group to the rule

[root@ipa1 ~]# ipa hbacrule-add-host --hostgroups rhel-prod prod-admins
  Rule name: prod-admins
  Source host category: all
  Enabled: TRUE
  User Groups: prod-admins
  Host Groups: rhel-prod
  Services: sshd
-------------------------
Number of members added 1
-------------------------
[root@ipa1 ~]#

Of course you can enhance the rule by adding other services or restrict the access from particular hosts and so on.

Have fun :-)

How to recover from a lost Kerberos password for admin

Saturday, December 8th, 2012

Ever lost your password for the admin principle on your Linux Kerberos server? It is quite easy to recover by just setting a new one.

You just need to log in to your KDC and proceed as follows:

[root@ipa1 ~]# kadmin.local
Authenticating as principal admin/admin@EXAMPLE.COM with password.
kadmin.local:  change_password admin@EXAMPLE.COM
Enter password for principal "admin@EXAMPLE.COM": 
Re-enter password for principal "admin@EXAMPLE.COM": 
Password for "admin@EXAMPLE.COM" changed.
kadmin.local: q
[root@ipa1 ~]#

Now enter kinit to get a Kerberos ticket.

Have fun :-)

Identity Management with IPA Part II – Kerberized NFS service

Sunday, December 25th, 2011

In part one I was writing how to set up an IPA server for basic user authentication.

One reason NFSv4 is not that widespreaded yet, is it needs Kerberos for proper operation. Of course this is now much easier thanks to IPA.

Goal for the part of the guide

  • Configure IPA to serve the NFS principle
  • Configure NFS to use IPA
  • Configure some IPA clients to use Kerberos for the NFS service

Requirements

  • A runing IPA service like discussed in Part I of this guide.
  • A NFS server based on RHEL6.2
  • One or more IPA-Client

Lets doit
First you need to add the NFS server and its service principal to the IPA server. On ipa1.example.com run:

[root@ipa1 ~]# ipa host-add nfs.example.com
[root@ipa1 ~]# ipa service-add nfs/nfs.example.com

Next, log on to you NFS server, lets call it nfs.example.com and install the needed additional software packages:

[root@nfs ~]# yum -y install ipa-client nfs-utils

You need to enroll you NFS-server on the IPA domain. Run the following on nfs.example.com:

[root@nfs ~]# ipa-client-install -p admin

The next step is to get a Kerberos ticket and fetch the entries needed to be added in the krb5.keytab

[root@nfs ~]# kinit admin
[root@nfs ~]# ipa-getkeytab -s ipa1.example.com -p nfs/nfs.example.com -k /etc/krb5.keytab

Before you proceed to your clients, you need to enable secure NFS, create an export and restart NFS:

[root@nfs ~]# perl -npe 's/#SECURE_NFS="yes"/SECURE_NFS="yes"/g' -i /etc/sysconfig/nfs
[root@nfs ~]# echo "/home  *(rw,sec=sys:krb5:krb5i:krb5p)" >> /etc/exports
[root@nfs ~]# mkdir /home/tester1 && cp /etc/skel/.bash* /home/tester && chmod 700 /home/tester1 && chown -R tester1:ipausers /home/tester1
[root@nfs ~]# service nfs restart

Assuming you already have set up one or more IPA-client(s), it is stright forward to enable kerberized NFS on your systems. Log in to a client and run the following:

[root@ipaclient1 ~]# yum -y install nfs-utils
[root@ipaclient1 ~]# perl -npe 's/#SECURE_NFS="yes"/SECURE_NFS="yes"/g' -i /etc/sysconfig/nfs
[root@ipaclient1 ~]# 

Lets have a look if you have been successful. First look up the users UID.

[root@ipaclient1 ~]# getent passwd tester1
tester1:*:1037700500:1037700500:Hans Tester:/home/tester1:/bin/bash
[root@ipaclient1 ~]# 

Lets mount that users home directory manually on a client:

mount -t nfs4 nfs.exmaple.com:/home/tester1 /home/tester1

To check if is working as expected, issue

[root@ipaclient1 ~]# su - tester1

Fire ls -lan and see if the UID matches the UID you got from getent. If you see UID 4294967294, then something went wrong, this is the UID for the user “nobody” when using NFSv4 on 64 bit machines.

Whats next?
You will figure out when I post part III of this guide :-)

Have fun!